目前身分：吳品叡（管理員） ，可查看 6 / 6 個專案的成本
14 筆用量紀錄Cartesia 已用字數
776
中文字
音檔生成次數
10
次
快取命中
1
次 · 省下 $0.05
預估總費用
$0.60
USD
重試次數
5
2 個專案接近上限
成本分佈
依服務供應商拆解；費用為 $0 的服務（快取命中、自架運算）只列在下方清單
- Cartesia 語音6 次／776 中文字$0.4575%
- LLM 腳本3 次／25,240 token$0.1321%
- Whisper 轉錄3 次／237 秒$0.024%
- YouTube 取得1 次／1 次$0.000%
- FFmpeg 合成1 次／2 次$0.000%
依專案用量
重試上限：單段 2 次、全案 4 次；用掉一半就先示警
| 專案 | 主持人 | 狀態 | 字數 | 生成次數 | 快取命中 | 重試 | 費用 | 最後更新 |
|---|---|---|---|---|---|---|---|---|
| 比特幣 ETF 單週淨流入創今年新高proj_01｜負責人 簡珮甄 | 林知遠 | 已完成 | 312 | 4 | 1 · 省 $0.05 | 2 / 4 | $0.20 | 2026/07/23 03:20 |
| 以太坊升級三個重點proj_02｜負責人 簡珮甄 | 陳博宇 | 主持人影片待審 | 235 | 3 | 0 | 1 / 4 | $0.20 | 2026/07/28 02:15 |
| 穩定幣法案三讀後交易所要面對什麼proj_03｜負責人 柯昱翔 | 蘇雨桐 | 等待 Higgsfield | 229 | 3 | 0 | 0 / 4 | $0.15 | 2026/07/29 06:14 |
| 資金從比特幣輪動到生態代幣proj_04｜負責人 柯昱翔 | 周曉薇 | 腳本待審 | 0 | 0 | 0 | 2 / 4 | $0.05 | 2026/07/30 03:40 |
| 降息預期下的比特幣位置proj_05｜負責人 簡珮甄 | 高鎮宇 | 轉錄中 | 0 | 0 | 0 | 0 / 4 | $0.00 | 2026/07/31 00:23 |
| 迷因幣熱潮退燒了嗎proj_06｜負責人 柯昱翔 | 鄭立群 | 失敗 | 0 | 0 | 0 | 0 / 4 | $0.00 | 2026/08/01 07:12 |
重試額度告警
- proj_01「比特幣 ETF 單週淨流入創今年新高」 已用 2 / 4 次 —— 已用掉一半額度，建議先人工檢查失敗原因
- proj_04「資金從比特幣輪動到生態代幣」 已用 2 / 4 次 —— 已用掉一半額度，建議先人工檢查失敗原因
呼叫明細
每一次外部服務呼叫都會留下 request_id，可追溯與重現
| 時間 | 專案 | 服務 | 單位 | 費用 | request_id | 說明 |
|---|---|---|---|---|---|---|
| 2026/08/01 07:12 | 迷因幣熱潮退燒了嗎 | YouTube 取得 | 1 | $0.00 | req_ingest_xg8s | 來源取得失敗（HTTP 403），未產生費用 |
| 2026/07/30 03:02 | 資金從比特幣輪動到生態代幣 | LLM 腳本 | 9,640 | $0.05 | req_llm_5ad9 | 腳本生成 + seg_0403 字數自動重寫 2 次 |
| 2026/07/29 06:14 | 穩定幣法案三讀後交易所要面對什麼 | Cartesia 語音 | 229 | $0.15 | req_cartesia_proj03_batch | 三段音檔批次生成，合計 229 字 |
| 2026/07/27 07:24 | 以太坊升級三個重點 | Cartesia 語音 | 235 | $0.15 | req_cartesia_proj02_batch | 三段音檔批次生成，合計 235 字 |
| 2026/07/27 07:05 | 穩定幣法案三讀後交易所要面對什麼 | Whisper 轉錄 | 47 | $0.0047 | req_whisper_b204 | 逐字稿轉錄 47 秒 |
| 2026/07/25 01:52 | 以太坊升級三個重點 | LLM 腳本 | 7,180 | $0.04 | req_llm_c47a | 雙版本腳本生成 |
| 2026/07/25 01:40 | 以太坊升級三個重點 | Whisper 轉錄 | 88 | $0.0088 | req_whisper_1f9b | 逐字稿轉錄 88 秒 |
| 2026/07/23 02:40 | 比特幣 ETF 單週淨流入創今年新高 | FFmpeg 合成 | 2 | $0.00 | req_render_01 | 成片合成 2 個版本（自架運算，不計外部費用） |
| 2026/07/22 10:05 | 比特幣 ETF 單週淨流入創今年新高 | Cartesia 語音 | 78 | 快取命中 $0 | req_cartesia_0103_v2 | seg_0103 重新生成 — text_hash 相同，快取命中，本次 $0 |
| 2026/07/22 09:44 | 比特幣 ETF 單週淨流入創今年新高 | Cartesia 語音 | 76 | $0.05 | req_cartesia_0104_v1 | seg_0104 音檔生成，76 字 |
| 2026/07/22 09:42 | 比特幣 ETF 單週淨流入創今年新高 | Cartesia 語音 | 78 | $0.05 | req_cartesia_0103_v1 | seg_0103 音檔生成，78 字（含 1 次自動重試） |
| 2026/07/22 09:40 | 比特幣 ETF 單週淨流入創今年新高 | Cartesia 語音 | 80 | $0.05 | req_cartesia_0101_v1 | seg_0101 音檔生成，80 字 |
| 2026/07/21 02:20 | 比特幣 ETF 單週淨流入創今年新高 | LLM 腳本 | 8,420 | $0.04 | req_llm_b93c | 雙版本腳本生成（含 1 次 schema 自動修復） |
| 2026/07/21 02:12 | 比特幣 ETF 單週淨流入創今年新高 | Whisper 轉錄 | 102 | $0.01 | req_whisper_7a41 | 逐字稿轉錄 102 秒 |
待客戶確認的暫定值
spec 只寫「要限制」沒有給數字的地方，Demo 先填了一個值才跑得動；下列每一項都還沒定案
| 項目 | Demo 暫定值 | 推導依據 | spec 現況 |
|---|---|---|---|
Higgsfield 單段長度門檻HIGGSFIELD_MAX_SEGMENT_SEC | 15 秒 | 對應 78 字（78 ÷ 5.2 = 15.0），落在 75–80 字區間上半段，超過即示警但不阻擋生成 | spec 第 7 節只寫「避免超過可承受長度」，未給數字 |
單段音檔重生上限MAX_REGENERATIONS_PER_SEGMENT | 3 次 | 首次生成 + 3 次重生 = 單段最多 4 個版本，足夠展示版本比較 | spec 第 10 節只寫「限制單段重試次數」，未給數字 |
全案音檔生成上限MAX_GENERATIONS_PER_PROJECT | 12 次 | 4 段口播 × 單段上限 3 次；全案額度不會比單段額度先耗盡 | spec 第 10 節只寫「限制全案重試次數」，未給數字 |
單段重試上限SEGMENT_RETRY_LIMIT | 2 次 | 對齊 spec 第 11 節已寫死的「字數不合格自動重寫最多 2 次」，全站只留一個數字 | spec 第 10 節只寫「限制單段重試次數」，未給數字 |
全案重試上限PROJECT_RETRY_LIMIT | 4 次 | 4 段 × 每段 1 次的預算；只影響成本頁徽章顏色，不阻擋操作 | spec 第 10 節只寫「限制全案重試次數」，未給數字 |
口播重疊比對單位OVERLAP_NGRAM_N | 4 字 | 2 字詞在中文財經語料幾乎必然命中、3 字仍偏高、5 字以上會漏掉「改一兩個字的複述」；4 字對應四字短語或半個子句，逐字複述才會連續命中 | spec 只要求「口播不得複述原片」，未定義比對方式 |
口播重疊率上限（阻擋核准）OVERLAP_MAX_RATIO | 25% | 78 字口播共 75 個 4-gram，連續 k 字複述貢獻 k − 3 個命中；25% 對應連續逐字複述約 22 字，即「複述超過段落長度的四分之一」 | spec 只要求「口播不得複述原片」，未給量化門檻 |
口播重疊率示警門檻OVERLAP_WARN_RATIO | 18% | 同一推導代入約 16 字（約兩個短句），在還沒超標前先給黃燈，示警不阻擋 | spec 只要求「口播不得複述原片」，未給量化門檻 |
中文語速估算基準ZH_CHARS_PER_SECOND | 5.2 字/秒 | 既有假設，定義位置仍在 lib/textValidation.ts；口播段的預估時長與成片總時長閘門都由它推導（字數 ÷ 5.2 = 秒數） | spec 定義了 75–80 字/段，但從未定義中文語速 |
PIP 段的段長判準PIP_SEGMENT_DURATION_RULE | 以口播長度為準 | PIP 段畫面是原片、聲音是主持人，主持人說完話這一段才能結束；原片剪輯區間只決定「播原片的哪一段」，不決定段長（長於段長則裁切、短於段長則定格） | spec 第 6 節只說 PIP 段「原片為主、主持人右下角」，沒說段長怎麼算 |
Match Score 五項權重MATCH_WEIGHTS | 品類 30％／受眾 25％／粉絲 15％／預算 15％／成效 15％ | 品類是最硬的條件（美妝案找 3C 網紅沒有意義），受眾次之；粉絲數、預算、成效在真實媒合中是「可談的」，各佔 15％。五項加總為 1.0，分數天然落在 0–100，不需要再正規化 | kol-agent-demo §5.1 加權公式 |
品類命中的三段給分MATCH_CATEGORY_FIT | 主品類 1／次要品類 0.7／不命中 0.15 | 不命中仍給 0.15 而不是 0：硬過濾已擋掉地區與平台，品類不合者仍可能因受眾與成效值得一談；給 0 會讓這一群人的分數塌成同一個值，失去排序意義 | kol-agent-demo §5.1 categoryFit |
粉絲數偏離的對數衰減常數MATCH_FOLLOWER_DECAY | 0.6 | log10(4) ≈ 0.602，即與區間邊界差 4 倍時 fit 歸零、差 2 倍時 fit ≈ 0.50；用對數而非線性，避免粉絲數跨三個量級時大帳號的偏離永遠比小帳號嚴重 | kol-agent-demo §5.1 followerFit |
Reels 觀看率滿分基準MATCH_VIEW_RATE_FULL | 45% | mockup 11 的示範資料落在 22.1%–41.3%，取 45% 為滿分上界，讓最好的那一位不會剛好頂格 | kol-agent-demo §5.1 performanceFit |
Reels 互動率滿分基準MATCH_ENGAGEMENT_FULL | 6% | 既有網紅庫的互動率落在 1.5%–8.9%，取 6% 為滿分基準，使多數網紅落在 0.3–1.0 之間才有鑑別力 | kol-agent-demo §5.1 performanceFit |
審稿字數容差REVIEW_CHAR_TOLERANCE_PCT | 10% | 對 320 字上限而言是 32 字（約兩三句）：這個量級順手就能刪，不值得退件所以給黃燈；再多就是結構問題，給紅燈 | kol-agent-demo §5.3 第 6 項 CHAR_RANGE |
Brief 預設 Hashtag 總數下限REVIEW_MIN_HASHTAGS_DEFAULT | 3 個 | 品牌標 ＋ 案件標 ＋ 至少一個自由標；指定 hashtag 通常兩個，下限訂 3 才逼得出網紅自己的內容標 | kol-agent-demo §5.2 requirements 預設值 |
Brief 預設產品露出張數下限REVIEW_PRODUCT_SHOTS_DEFAULT | 6 張 | IG 單則貼文上限 10 張，扣掉情境照與人像後產品實拍約佔六成；此項比對的是**提交時宣告的張數**，不是影像內容 | kol-agent-demo §5.3 第 1 項 PRODUCT_SHOTS |
Brief 預設貼文字數區間BRIEF_CHAR_RANGE | 150–320 字 | 150 字約為「情境 → 感受 → 特色」三段結構的下限；320 字接近 IG 貼文在手機上「展開更多」之前的可讀長度上界 | kol-agent-demo §5.2 requirements 預設值 |
Brief 交付天數BRIEF_DELIVERY_DAYS | 7 天 | 收到商品後拍攝 ＋ 剪輯 ＋ 四輪審稿，一週是實務上最短但仍可執行的節奏 | kol-agent-demo §5.2 交付時程段 |
Match Score 的凍結時點MATCH_SCORE_SNAPSHOT_RULE | 分享給品牌方時凍結 | 品牌方看到的分數必須與代理商分享當下一致；分享之後代理商再調條件，不應該讓品牌方那一頁的數字跟著跳。代理商端（候選與初篩）一律現算，品牌方端一律讀快照 | kol-agent-demo §5.1 分數快照 |
這 21 個常數集中在 src/config/demoAssumptions.ts，確認後改該檔一處即可全站生效。
這道檢查抓得到什麼、抓不到什麼
「口播僅補充」規則的能力邊界 —— 交付時請一併向客戶說明
目前比對的是字面重疊：口播與原片逐字稿之間連續相同的中文字。它抓得到「把原片整句搬過來」，抓不到「換句話說的重複」—— 同一件事用不同措辭再講一次，字面重疊率會很低。那一層在真實系統靠兩件事把關：產生腳本時的 LLM 提示詞（明確要求只寫補充），以及送 Cartesia 之前的人工核准閘門。
- 抓得到最常見的失誤是開場 Hook 直接複述原片的第一段。腳本頁的 proj_04 / seg_0401 就是這種案例： 它的重疊率遠高於上限，該段標紅、核准鍵停用，並在閘門面板上指名是哪一段。
- 抓不到換句話說的重複這一層 Demo 不做，也不假裝做得到； 超標時也沒有「自動改寫成補充」的按鈕，只能人工改寫。
- 真實系統Demo 保留了人工核准閘門這一道； 產生腳本時的 LLM 提示詞不在 Demo 範圍（Demo 不接真實 LLM）。
附帶一提：成片總時長的上下限沒有列在上表 —— 那是客戶已經定案的規格常數， 不是 Demo 暫定值；要調整它需要走規格變更，而不是改這一頁的表格。
網紅專案 Agent 的能力邊界
Match Score、Brief 產生與 AI 審稿三個點的實際做法 —— 交付時請一併向客戶說明
本模組的三個「AI 點」全部是前端規則運算，不呼叫任何外部服務、不做語意判斷、不做影像判斷。 它們是真的在算（改條件當場重算），但算的是規則不是理解。
- Match Score五項加權算術：品類 30／受眾 25／粉絲數 15／預算 15／成效 15。權重與兩個滿分基準（觀看率、互動率）都在上表， 改一個數字全站跟著變，不需要改程式邏輯。
- 審稿抓得到AI 審稿比對的是 Brief 裡宣告的結構化要求（必提關鍵詞、禁用詞、指定 Hashtag、標註帳號、字數區間）。 因此它抓得到「漏標 Hashtag、寫了禁用詞、忘記標註品牌帳號、字數超標、 關鍵賣點沒提到」—— 實務上最常見的退件原因。
- 審稿抓不到語氣是否符合品牌調性、圖片與影片的實際內容、有沒有換句話說地踩到雷 —— 這一層 Demo 不做，也不假裝做得到。真實系統靠兩件事把關：產生 Brief 時的 LLM 提示詞，以及人工第二層確認（Demo 保留了後者，而且它是真的會擋）。
- 產品露出此項比對的是提交時宣告的張數，不是影像內容；真實系統需要影像模型判定。