# 臺灣商務對話系統完整方案 v2

更新日期：2026-09-13｜目標市場：臺灣｜文件與產品語言：繁體中文

本版完整整合五項功能、臺灣華語與臺語選型、語音模型與語言模型分工、開源參考、Codex 開發流程、團隊安排、工期及費用試算。取代前版的語言與市場假設；前版留存供追溯。本文件是待討論的開發提案，並非已建置或已驗收的系統。

## 1. 建議結論

做成「一個工作臺、三種錄音方式、舊資料匯入、會議與方案整理」，共用客戶資料、逐字稿及音檔。底層採現有開源模型與程式，不從零訓練語音模型，也不自行重寫通話協定。

1. 臺灣華語優先比較 Breeze-ASR-25 與 Whisper large-v3；臺語加入 Breeze-ASR-26 實驗路線。
2. 辨識文字使用 ASR 語音模型，不必額外呼叫聊天型大型語言模型。
3. 依時間排列、說話者改名、搜尋、匯出可不用 LLM；智慧摘要、決議、待辦與方案草稿建議使用 LLM。
4. 開發與產品執行分開：Codex 負責寫程式與驗證，Breeze／Whisper 負責聽音檔，TAIDE／Qwen 等文字模型負責整理。產品使用者不需擁有 Codex 帳號。
5. 第一版 2～4 週完成現場錄音／匯入、逐字稿校對及整理；五功能試用版估 5～9 週。臺語品質列獨立驗證，不能把「模型可執行」當成「臺語已準確」。
6. API 計價等值：混合開發模型標準情境約 NT$9,265～16,941；建議以 NT$9,300～17,000 規劃。Codex 訂閱實際收費另算，不能直接當成這個數字。

工期與 token 量是尚未實測的工程預算，價格有官方來源；計算公式見第 13～15 節。臺幣換算採預算假設 US$1＝NT$32，並非即時匯率。

## 2. 臺灣市場與語言規格

已確認：使用者與客戶在臺灣；全部使用者介面、提示、紀錄、說明與方案輸出採繁體中文，使用臺灣用語。時區採 Asia/Taipei。適用於一般商務訪談，不只限於保險。

語言優先序：

| 類型 | 本案定位 | 不能混為一談的事 |
| --- | --- | --- |
| 臺灣華語／國語 | 首版主要驗收語言 | 支援一般中文不代表對臺灣口音、人名、產品名同樣準確 |
| 華語夾英文 | 首版測試項目 | 英文品牌及縮寫不強制音譯為中文 |
| 臺語 | 加入候選，品質通過後才正式標示支援 | 臺語不是粵語，也不能只靠簡轉繁處理 |
| 華語／臺語混用 | 獨立測試類別 | 支援兩種單語不代表一句中切換也能準確 |
| 客語、粵語及其他語言 | 保留通用開源參考與可替換介面 | 不列本次首版已支援範圍 |

介面預設繁體，不表示可以改寫客戶原話。系統保留三層：原始音檔與模型原始輸出、繁體校對稿、AI 整理稿。地名、姓名、公司名、金額、日期、否定語意需保護；業務詞彙表能輔助辨識，但不是強制把相近發音換成指定商品。

簡繁字形可用 OpenCC，這是詞典轉換，不是聊天 LLM。逐字稿以字形整理為主；臺灣常用詞的改寫只用於另存的閱讀版／方案，不把客戶說的用語偷偷換掉。OpenCC 不負責臺語語音辨識或臺語翻譯。[OpenCC 與臺灣字形／詞彙設定](https://github.com/BYVoid/OpenCC)

介面金額可使用 NT$ 格式；如果客戶只說「兩萬」而未交代幣別，逐字稿與需求仍標示幣別待確認，不能因市場在臺灣就補成已確認的新臺幣報價。民國日期若換算為西元，保留原說法與換算值。

## 3. 語音轉文字究竟需不需要語言模型？

需要先區分「AI 模型」和「聊天型大型語言模型」。

ASR 是自動語音辨識模型，輸入聲音、輸出文字。Whisper、Breeze-ASR 都是 AI 模型，本身含有從語音推斷文字序列的能力；但不需要再串接 ChatGPT、TAIDE 或 Qwen 才能轉寫。某些新型 ASR 本身結合 LLM 架構，所以不能一概說語音辨識與語言建模完全無關。本案主路線採可獨立執行的 ASR。[Whisper 官方程式](https://github.com/openai/whisper)、[Breeze-ASR-25 官方範例](https://github.com/mtkresearch/Breeze-ASR-25)

| 工作 | 需要什麼 | 是否需要額外聊天型 LLM？ |
| --- | --- | --- |
| 錄音、雙軌儲存、通話 | 音訊／WebRTC 程式 | 不需要 |
| 判斷哪裡有人聲 | VAD 語音活動偵測 | 不需要 |
| 將語音轉成文字 | ASR 語音模型 | 不需要額外 LLM |
| 混合錄音區分說話者 | 語者分段、聲紋特徵與分群模型 | 不需要聊天 LLM |
| 將可信音軌對應到參與者 | 音軌來源與身分資料 | 不需要 |
| 繁體字形、搜尋、排序、匯出 | 詞典／一般程式 | 不需要 |
| 日期、參與者、逐段發言格式 | 固定範本＋既有欄位 | 不需要，可產生紀錄版 |
| 從原文挑幾句重點 | 擷取式摘要演算法 | 可以不需要，但不等於可靠理解決議 |
| 整理討論重點、決議、負責人、待辦 | 理解上下文的文字模型 | 建議使用 |
| 自動產生客製化商務方案 | 文字模型＋確認過的需求＋商品／服務資料 | 本案採用；固定套版則可不使用 |

因此提供兩個清楚分開的按鈕：「匯出逐字紀錄」不啟用摘要 LLM；「產生智慧會議紀錄／方案草稿」才啟用文字模型。辨識失敗時不能交給 LLM 自由補成流暢內容。

## 4. 臺灣語音開源候選

### 4.1 臺灣華語主候選：Breeze-ASR-25

聯發科研究團隊提供，基於 Whisper-large-v2 微調，針對臺灣華語及華語夾英文最佳化。官方有 GitHub 程式、模型權重及音檔轉寫／字幕範例；程式標示 MIT、模型 Apache-2.0。將其列為臺灣華語優先測試項，不直接宣稱一定勝過其他模型。[官方程式](https://github.com/mtkresearch/Breeze-ASR-25)、[官方模型卡](https://huggingface.co/MediaTek-Research/Breeze-ASR-25)

### 4.2 臺語候選：Breeze-ASR-26

官方模型卡以臺語辨識為主要目標，權重標示 Apache-2.0。重要限制是目前輸出主要為華語文字，不是臺語正字；訓練主要使用合成語音，真實口語、地方口音及專有名詞效果需另外測試。它不是全面取代 25 的升級版，兩者目標不同。[官方模型與限制](https://huggingface.co/MediaTek-Research/Breeze-ASR-26)

已有人做出可操作的開源包裝：thc1006/breeze-asr-taigi，提供網頁介面、音檔匯入、時間戳記與 SRT／VTT／TXT／JSON 輸出。其 LICENSE 本文是 MIT，另註明模型授權獨立；GitHub 自動辨識曾回傳 NOASSERTION，本次已另外讀取 LICENSE 內容確認。這是可試跑的社群專案，不是本團隊已驗證的成品。[專案](https://github.com/thc1006/breeze-asr-taigi)、[授權本文](https://github.com/thc1006/breeze-asr-taigi/blob/main/LICENSE)

臺語輸出規格：使用上述模型得到的結果標示「臺語轉華語文字／待核對」，不得直接叫「臺語原文逐字稿」。未來若加入臺語正字模型，正字原稿和華語閱讀版分欄。華臺混用先讓使用者選擇模式、保留可重跑片段，再評估語言自動路由；不把一般 language=zh 設定當成臺語支援證據。

另保留 ChineseTaiwaneseWhisper 作為華語／臺語訓練與應用參考，但在未核定可下載權重、版本和實測成果前，不列為首選產品引擎。[社群程式](https://github.com/sandy1990418/ChineseTaiwaneseWhisper)

### 4.3 持續保留的通用開源

| 元件 | 在本案中的用途 | 注意事項 |
| --- | --- | --- |
| Whisper large-v3 | 多語音檔辨識對照基線 | 不直接宣稱原生臺語品質達標 |
| faster-whisper | CTranslate2 推論引擎，加速相容模型 | 它是執行引擎，不是另一個語言能力更強的模型 |
| WhisperX | 時間對齊、語者歸屬流程參考 | 換成 Breeze 權重後仍須測試相容性；不承諾臺語逐字對齊 |
| pyannote Community-1 | 混合音檔語者分段 | 與文字辨識分開；模型需接受下載條件 |
| FunASR＋CAM++ | 中文辨識及語者流程對照 | 函式庫與模型授權分開；不能以方言支援泛稱臺語 |
| VibeVoice-ASR | 長音檔整合辨識、時間與語者對照 | 模型較新，部署資源與臺灣口音效果需測試 |

來源：[Whisper](https://github.com/openai/whisper)、[faster-whisper](https://github.com/SYSTRAN/faster-whisper)、[WhisperX](https://github.com/m-bain/whisperX)、[pyannote](https://huggingface.co/pyannote/speaker-diarization-community-1)、[FunASR](https://github.com/modelscope/FunASR)、[VibeVoice](https://github.com/microsoft/VibeVoice)。

## 5. 整理與方案也有開源實作

### 5.1 不使用聊天 LLM 的紀錄模式

一般程式即可用會話日期、參與者、時間戳記和逐段發言產生文件，保留搜尋、篩選、匯出。需要自動選出重點句時，可參考 Sumy 的 LexRank 等擷取式摘要：從原文挑句，而非生成新敘述。繁體斷詞與臺語轉譯內容仍須測試，摘句不能保證正確理解「誰承諾了什麼」。[Sumy 開源實作](https://github.com/miso-belica/sumy)

### 5.2 使用 LLM 的智慧紀錄模式

Meetily 開源社群版提供語音轉寫、Ollama／其他模型供應端的摘要流程，可參考錄音後整理與操作介面。其 PRO 與社群版不是相同程式，不能把付費版的語者功能全算成已開源。[Meetily](https://github.com/Zackriya-Solutions/meetily)

jdevto/audio-transcriber 更小，將 transcribe.py 與 summarize.py 分開：先用 faster-whisper 轉寫，再把文字交給本機 Ollama 產生會議紀錄。已核對部分摘要程式，存在長文分段、局部摘要、合併重點、決議與待辦的處理。適合拿來參考最小流程，不直接照搬英文提示詞。[程式](https://github.com/jdevto/audio-transcriber)、[摘要程式](https://github.com/jdevto/audio-transcriber/blob/main/summarize.py)

### 5.3 文字模型選擇

| 候選 | 使用理由 | 授權／定位 |
| --- | --- | --- |
| Llama-3.1-TAIDE-LX-8B-Chat | 臺灣文化、繁體中文與摘要任務優先對照 | 開放權重，採 TAIDE 自訂授權且需接受條款；不當作無限制 MIT 模型 |
| Qwen3-8B | 通用中文與結構化整理對照；不因非臺灣團隊而排除 | 官方模型卡 Apache-2.0 |
| Breeze-7B-Instruct-v1_0 | 繁體中文模型研究對照 | Apache-2.0；較早期版本，不因在地就認定優於其他候選 |

Ollama 是執行模型的工具，不是模型本身。是否能直接載入某一權重／量化格式，及所需記憶體，開發初期先確認。TAIDE 最大上下文長度也不代表這臺電腦能在該長度下順暢執行。[TAIDE](https://huggingface.co/taide/Llama-3.1-TAIDE-LX-8B-Chat)、[Qwen3-8B](https://huggingface.co/Qwen/Qwen3-8B)、[Breeze 文字模型](https://huggingface.co/MediaTek-Research/Breeze-7B-Instruct-v1_0)、[Ollama](https://github.com/ollama/ollama)

### 5.4 有原文依據的方案

參考 LlamaIndex 的 CitationQueryEngine 與來源節點流程，將轉寫片段及使用者提供的商品資料切成可引用區塊。第一版資料少時可直接按客戶與會話選取，不急著加向量資料庫。只有需要跨大量文件檢索時才加入檢索／嵌入模型。[引用查詢實作](https://developers.llamaindex.ai/python/examples/query_engine/citation_query_engine/)

目前找到的是可重用的轉寫、摘要、引用與通話元件；沒有證據表明某個開源倉庫已完整做好本案全部五功能與臺灣商務流程。客戶欄位、資料串接、確認機制和畫面仍需開發。引用 ID 存在也不保證模型解讀正確，必須檢查內容是否支持結論。

## 6. 既有商品怎麼拿來參考

| 商品 | 借鏡項目 | 本案用途 |
| --- | --- | --- |
| 雅婷逐字稿 | 臺灣團隊、中英臺語轉錄、多人語者、匯入與摘要 | 新增為臺灣主要商品對照；用同一音檔比品質 |
| PLAUD | 一鍵錄音、會後轉寫、說話者標籤與摘要 | 面談採集體驗及既有資料匯入 |
| Notta Desktop | 麥克風／系統輸出獨立處理 | 電腦雙軌錄音操作參考 |
| 訊飛聽見 | 說話者統一改名、音文對照 | 校對流程參考，保留先前研究 |
| 騰訊會議、飛書妙記 | 邀請、發言時間軸、紀錄與摘要 | 通話與會議紀錄體驗參考，非臺灣必用平台 |

雅婷官方已公開列出中、英、臺語等轉錄、多人語者、匯入及後續摘要。這能證明臺灣已有相關商品，但不代表它的模型或整套平台開源；也不直接採信宣傳的準確率為本案測試成績。[雅婷官方](https://studio.yating.tw/intro/zh-TW/transkribera)

其他參考：[PLAUD](https://www.plaud.ai/pages/plaud-ai-plan-pricing)、[Notta 分軌原理](https://support.notta.ai/hc/en-us/articles/48345161234203-What-is-Bot-Free-Recording)、[訊飛功能](https://www.iflyrec.com/helpCenter_features_xftj/helpCenter_features_xftj.html)、[騰訊智能錄製](https://meeting.tencent.com/support/topic/2077/index.html)、[飛書妙記](https://www.feishu.cn/content/article/7578773484596153570)。品牌原有名稱與網站保留，本文介面設計使用繁體臺灣用語。

## 7. 五功能的使用流程

### 功能一：現場錄音與逐字稿

選擇客戶／臨時會話 → 選語言 → 麥克風試錄 → 開始／暫停／結束 → 轉寫 → 語者區分 → 試聽確認「我／客戶」→ 校對／匯出。

單麥克風錄音是混合聲音，不假裝已有乾淨雙軌。支援預計兩人但允許修正人數；第三人插話不強制塞入 A 或 B。同一人被拆成多個編號可合併，誤合併則可局部拆分。

手機網頁先支援前景錄音；鎖屏、切換 APP、來電可能中斷。長時間外出錄音可先用系統錄音工具或專用設備，再走功能四。要穩定背景錄音，另做原生手機端。

### 功能二：既有電腦通話的雙軌錄音

打開桌面採集器 → 選麥克風與播放裝置 → 確認兩邊有聲音 → 使用原 LINE／會議軟體聊天 → mic 與 system 分別儲存 → 各自轉寫 → 按時間合併。

Windows 優先採 WASAPI；保留 Reco 與 Cadence 的開源參考。macOS 後續參考 ScreenCaptureKit 與 mac-audio-recorder。耳機優先測試；外放需處理客戶聲音漏進本機麥克風的回聲。system 也可能包含提示音和音樂；本機／遠端各有多人時，仍需在該音軌內區分人物。[Reco](https://github.com/dosxnjos/reco)、[Cadence](https://github.com/bykcyc/Cadence)、[Mac 參考](https://github.com/jftuga/mac-audio-recorder)

### 功能三：邀請客戶進入本系統通話

業務登入 → 建立雙人語音房 → 手動分享邀請連結 → 客戶以邀請憑證及稱呼進入 → 顯示錄音說明 → 確認錄製就緒 → 通話 → 產生雙方各自音軌及逐字稿。

主選 LiveKit Meet＋LiveKit Egress：通話使用現成 WebRTC 元件，依參與者與音軌分別錄製。不是抓手機其他 APP 的聲音，而是雙方直接在本系統內通話，因此手機及電腦能走同一架構。先做語音，不增加必要性不足的視訊、虛擬人或語音合成。[Meet](https://github.com/livekit-examples/meet)、[Egress](https://github.com/livekit/egress)、[官方逐軌錄製](https://docs.livekit.io/transport/media/ingress-egress/egress/)

客戶先用限定房間的邀請登入，不必註冊永久帳號；稱呼不等於實名驗證。客戶不能看到別人的資料，也不預設能看業務的內部方案。重連須映射回同一參與者，保留斷線缺口；不能把兩個獨立錄音都從 00:00 疊起來。手機前景通話先驗收，背景／鎖屏另測。

### 功能四：舊資料匯入與客戶歷程

支援 WAV／MP3／M4A、影片音軌與 TXT／SRT／VTT；保留來源、原檔、說話者、時間與版本。已有商品匯出的逐字稿可沿用，不必全部重跑 ASR。只有文字的資料標示未對照音檔，沒有時間戳記就使用段落引用，不編造可播放位置。

資料依客戶與會話歸檔。重複檔案用內容雜湊提示；同名不直接視為同一人。全文搜尋可以先用一般資料庫，不必用 LLM。

### 功能五：會議紀錄與方案草稿

提供三種輸出：不使用聊天 LLM 的逐字紀錄；使用 LLM 的會議重點／決議／待辦；依確認後需求與產品資料產生的方案草稿。

每個重要結論保留來源片段、發言人與時間；區分客戶原話、業務建議、AI 推論、待確認。客戶說「再考慮」不等於同意，業務報價不等於客戶預算。商品條款與報價要有使用者提供的有效資料；沒有就列待補，不用模型記憶補成正式內容。

臺語華語轉譯片段的引用仍標明是轉譯，不能用引號假裝客戶當時講的是同一句華語。人工確認後才儲存為正式摘要；提供複製／匯出，不自動傳送給客戶。原始逐字稿不能被潤飾版本覆蓋。

## 8. 跨裝置能力邊界

| 環境 | 自己錄音 | 抓其他 APP 的雙方聲音 | 本系統內通話 |
| --- | --- | --- | --- |
| Windows 原生桌面端 | 可做 | 首選，需實測播放裝置與常用軟體 | 可做 |
| macOS 原生桌面端 | 可做 | 系統版本／權限適配後可做 | 可做 |
| 電腦網頁 | 前景可做 | 限瀏覽器實際提供的分頁／螢幕音訊 | 可做 |
| Android | 前景可做 | 不能保證任意通話 APP；音訊共享受限制 | 可做，背景另測 |
| iPhone | 前景可做 | 不承諾通用第三方通話雙錄 | 可做，背景另測 |

這是方案可行性分級，不是所有機型已實測。Windows 有 WASAPI 回環；瀏覽器即使要求 systemAudio 也可能沒有音軌；Android 受對方 APP 採集策略和麥克風共享規則限制；Apple 音訊會話在其他 APP 已通話時可能因優先權不足無法錄音。使用者授權不能保證解除這些限制。[Windows](https://learn.microsoft.com/en-us/windows/win32/coreaudio/loopback-recording)、[瀏覽器](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia)、[Android 播放](https://developer.android.com/media/platform/av-capture)、[Android 麥克風](https://developer.android.com/media/platform/sharing-audio-input)、[Apple](https://developer.apple.com/documentation/AVFAudio/AVAudioSession/setActive(_:options:))

## 9. 共用架構、資料與可靠性

```mermaid
flowchart TD
  A[現場錄音] --> R[會話與原始音檔]
  B[電腦雙軌錄音] --> R
  C[本系統邀請通話] --> R
  D[舊資料匯入] --> R
  R --> S[語音辨識 ASR 與語者歸屬]
  S --> T[繁體校對稿與原音回放]
  T --> E[不使用聊天 LLM：逐字紀錄／搜尋／匯出]
  T --> L[可選文字 LLM：摘要／決議／待辦]
  L --> P[結合有效產品資料：方案草稿]
```

建議前端採 React／TypeScript 響應式工作臺；Windows 採集器可用 Electron 或獨立原生輔助程式，依開源採集測試決定，不讓框架選擇阻礙試錄。語音後端以 Python 使用既有模型；FastAPI 提供任務介面；LiveKit＋Egress 提供通話與錄製。初期單機文字資料可用 SQLite；遠端多人使用再規劃服務端資料庫與私有檔案儲存。

保留三條處理路徑：混合音訊做 ASR＋語者分段＋時間對齊；可信分軌各自 ASR 後按來源歸屬；已存在逐字稿直接進校對。不要先將雙軌混成單聲道，失去已有的身分資訊。

基本欄位包含 session_id、participant_id、track_id、language_mode、start/end、text、speaker_id、transcript_version、source_segment_ids、review_status。臺語原文／華語轉譯另標 output_kind。部分模型無可靠逐字時間時先採句級，不編造精確到每字的位置。

錄音分塊持續落盤；每軌記錄起點與樣本數以修正漂移。暫停、重連、裝置切換、權限撤銷、磁碟不足都有事件紀錄。兩路音量試錄、缺軌提示、原音回放是必要功能。錄音失敗、轉寫失敗、摘要失敗分開處理；後兩者失敗可用原音重試，不能反覆重新錄音。

狀態分成錄製中、已儲存、上傳中、待處理、轉寫中、待校對、完成／部分完成／失敗。檔案存在或 API 回傳成功不代表雙方音訊完整，需檢查解碼、時長與音軌。重試採穩定任務 ID，避免重複處理和計費。

部署分清楚：桌面錄音先落本機；跨裝置與邀請通話需要受控服務、HTTPS 和必要的 TURN 中繼。可先讓本機工作機執行 ASR／LLM，以減少雲端 GPU 費，但需處理工作機離線時的佇列。若送外部 API，不能宣稱整個系統完全離線。服務端可讀錄音的架構也不能同時宣稱服務端無法解密。[LiveKit 網路需求](https://docs.livekit.io/transport/self-hosting/ports-firewall/)

## 10. 與既有專案及授權的界線

本輪沿用先前讀過的 README 與交接：現有保險工具箱客戶資料以瀏覽器文字記錄為主，不是音訊平台。新系統建議獨立開發，後續再用「將已確認摘要加入指定客戶」串接。不要把大音檔塞進 localStorage，也不要順便更改既有錢包、登入、客戶同步或部署。

建議新專案路徑為 F:\商務對話助手（尚未建立）；避免直接在已有未提交變更的保險專案內大量開發。若最後選擇沿用原專案，先鎖定變更範圍與隔離工作樹。

程式、權重、資料集、商業 API 是不同授權對象。Breeze-ASR 模型、Whisper、pyannote、TAIDE 各自核對；TAIDE 的自訂條款不能當成寬鬆開源條款。TranscriptionSuite 的 GPL-3.0 可作現成試用與介面參考，但不預設直接整包納入閉源發行。正式採用鎖定提交版本並建立依賴清單，本輪沒有進行商用發行審查。

## 11. Codex 開發方式與模型安排

### 11.1 三種不同的模型

| 層次 | 工作 | 建議候選 |
| --- | --- | --- |
| 開發助手 | 設計、寫程式、測試、除錯、審查 | Codex 中的 Astra／Sol／Terra／Luna |
| 產品語音 | 把錄音變成文字、辨識誰發言 | Breeze-ASR、Whisper、pyannote |
| 產品文字 | 整理會議、抽取需求、生成草稿 | TAIDE、Qwen；必要時可選付費文字 API |

產品上線後不需要每次轉寫都呼叫開發用的 Astra。開發 token 成本與產品執行 token 成本各有自己的帳。

### 11.2 推薦 Codex 分工

| 開發工作 | 建議模型／推理程度 | 理由 |
| --- | --- | --- |
| 整體設計、難解的錄音同步問題、重要審查 | GPT-6 Astra／high，必要時 xhigh | 用在歧義多、跨模組與高返工風險的工作 |
| 複雜功能整合、測試失敗定位 | GPT-5.6 Sol／medium 或 high | 多步驟實作與驗證 |
| 已明確規格的 API、前端、一般測試 | GPT-5.6 Terra／medium | 平衡成本與能力，作日常主力 |
| 窄範圍文件、格式、詞彙清單檢查 | GPT-5.6 Luna／low 或 medium | 重複且規則明確的工作；重要結論仍審查 |

以上是本案建議，不是同一工作必然哪個模型更便宜的實測結論。較強模型可能用更少輪數完成工作。預設不開 Fast、Max 或 Ultra；遇到明確難題才提高推理程度。可用模型取決於帳號和當時選單，不因出現在 API 文件就保證訂閱方案一定有權限。[官方模型選擇](https://developers.openai.com/api/docs/models)、[Codex 模型](https://learn.chatgpt.com/docs/models)

### 11.3 是否安排團隊？

建議先「一個主代理＋你負責產品驗收」。完成樣本驗證與共用資料格式後，才視需要加 1～2 個平行代理：語音與採集、前端與資料、獨立審查。最多約 3 個同時運作即可，不把五功能一開始分給五個代理。

平行工作要有不同檔案範圍或 Git worktree；資料結構、資料庫遷移、鎖檔、整合與部署由主代理串行處理。審查者以讀取與測試為主；若要修正，交回責任人或明確移交，避免互改同檔。AI 團隊會增加上下文及 token，用途是縮短可獨立工作的等待，不是免費增加人力。[官方子代理指引](https://learn.chatgpt.com/docs/agent-configuration/subagents)、[工作樹](https://learn.chatgpt.com/docs/environments/git-worktrees)

不需要先聘大型工程團隊；但真實臺語校對需懂臺語的人，手機與跨網路通話需兩端實測。AI 代理不能代替這些真人樣本驗收。

### 11.4 是否建立新任務？

建議方案確認後建立一個獨立的「臺灣商務對話助手—主開發」Codex 任務，先只執行 P0。之後每個里程碑有獨立的工作項目與交接，可留在主任務下；只有需要隔離長歷史或並行工作時再新增任務，不按每個小功能開一個聊天。

本輪只是規劃，沒有建立新任務、啟動代理團隊、排程自動化或設定持續執行目標。一般任務不等於背景排程，不能把「建立任務」解讀成關閉視窗後仍保證持續工作。

### 11.5 每個里程碑的開發循環

讀交接與限制 → 寫清楚本次輸入／輸出與驗收 → 在隔離分支實作最小功能 → 跑必要測試 → 用真音檔／真裝置驗收 → 查看差異與獨立審查 → 記錄版本、結果及用量 → 你確認後進入下一里程碑。

專案中建立簡短 README、AGENTS.md、任務清單、變更紀錄與 handoff。交接至少包含目前版本、已通過項目、失敗樣本、下一步、不要重做的事、已用 token／credits 和費用口徑。不要每次重貼整份文件或整個 repository；讀相關段落即可。

## 12. 開發流程、時程與交付物

假設：一名熟悉開發的主代理，由你配合每日約 4～6 小時的開發／觀察／驗收時段，每週 5 天；測試錄音與另一端裝置可及時提供；已有可用電腦，不含採購等待。這是工作日曆估算，不是模型連續運算時數，也不是從今天起已開始倒數。

| 階段 | 工作 | 估計工作日 | 通過才往下的交付物 |
| --- | --- | --- | --- |
| P0 | 臺灣樣本、硬體、ASR／LLM／雙軌可行性驗證 | 2～3 | 同樣本比較報告、候選版本、實際用量與修正版預算 |
| P1 | 共用會話／客戶資料、匯入及前景錄音 | 3～5 | 可保存、回放與重新開啟的會話 |
| P2 | 臺灣華語轉寫、語者、時間與繁體校對 | 3～5 | 可修改與匯出的逐字稿；臺語另列測試狀態 |
| P3 | 紀錄模式、智慧摘要、原文引用與方案草稿 | 2～4 | 三種輸出互不覆蓋，結論可核對 |
| P4 | Windows 雙軌採集、回聲與中斷處理 | 3～5 | LINE／常用軟體實測兩路音檔與對話稿 |
| P5 | LiveKit 邀請房、逐軌錄製、重連 | 4～7 | 手機與電腦雙方通話及完整錄製 |
| P6 | 跨裝置整合、錯誤復原、權限、打包與試用部署 | 3～5 | 五功能試用版、測試報告、交接與回復方式 |
| 合計 | 未含緩衝 | 20～34 | 不能將個別階段尚未驗證的功能提前標成完成 |

前四階段合計 10～17 工作日，約 2～4 週可得到第一個可用版本；全部加 25% 時程緩衝約 25～43 工作日，約 5～9 週。若每天只能投入 1～2 小時、等待權限／音檔、或臺語需要持續試錯，日曆時間增加。

臺語先作有標示的候選功能；達不到品質門檻就保留原音及人工核對，不以增加一週工期保證研究問題一定解決。macOS 桌面採集另估 3～7 工作日；原生 Android／iOS 的背景錄音與通話合計另估 15～30 工作日，均不含商店審查，且不承諾突破其他 APP 的錄音限制。

代理團隊在 P4 與 P3／P5 的獨立部分可能節省等待，但不先在預算中承諾工期減半；P0 得到真實速度與相依性後才修正。

## 13. Codex token 與訂閱費：分開計算

### 13.1 官方 API 標準單價

單位：每 100 萬 token 的美元價格，查核日 2026-09-13。

| 模型 | 一般輸入 | 快取輸入 | 輸出 |
| --- | ---: | ---: | ---: |
| GPT-6 Astra | $10.00 | $1.00 | $50.00 |
| GPT-5.6 Sol | $4.00 | $0.40 | $20.00 |
| GPT-5.6 Terra | $2.00 | $0.20 | $12.00 |
| GPT-5.6 Luna | $0.20 | $0.02 | $1.20 |

來源：[Astra](https://developers.openai.com/api/docs/models/gpt-6-astra)、[Sol](https://developers.openai.com/api/docs/models/gpt-5.6-sol)、[Terra](https://developers.openai.com/api/docs/models/gpt-5.6-terra)、[Luna](https://developers.openai.com/api/docs/models/gpt-5.6-luna)。可能涉及快取寫入、長上下文與速度加價；下述算式特別列出預留。價格可能改動，Sol 當前價格包含官方標明的促銷時段。

### 13.2 本案 token 假設

全案 token 分配以 Astra 20%、Sol 20%、Terra 50%、Luna 10% 試算；為方便重算，假設輸入和輸出都採同一比例，並不是硬性的實際派工比例。

輸入包括重複讀取的程式、工具結果、文件與對話歷史，不是只計你打的字。輸出預算包含可能計費的推理 token，不是只計可見程式碼。小組工作、測試後修正與重讀資料都會增加用量。

| 情境 | 累積輸入 token | 累積輸出 token | 適用解讀 |
| --- | ---: | ---: | --- |
| 精簡 | 2,000 萬 | 200 萬 | 元件整合順利、範圍固定；不能視為完整專案保證上限 |
| 標準 | 6,000 萬 | 600 萬 | 本案五功能試用版主要預算情境 |
| 反覆修正 | 1 億 5,000 萬 | 1,500 萬 | 相容性問題多、多輪代理與變更需求 |

這些數字尚未來自此專案的帳單。以 100／300／750 個開發回合、每回合平均 20 萬輸入及 2 萬輸出，可得到上述三組預算；實際回合長短不同，只是用來呈現量級。

### 13.3 API 等值費用計算

混合模型一般輸入單價＝$3.82／百萬、快取輸入＝$0.382／百萬、輸出＝$20.12／百萬。為保守預留快取寫入費，所有未命中輸入一律先按一般單價的 1.25 倍，也就是 $4.775／百萬計算；這是預算規則，不表示每筆未命中都一定收寫入費。

下界假設 70% 輸入命中快取，上界假設 0% 命中；70% 不是已測得命中率。兩者再加 30% 修正預備金。

計算式：

`美元預算＝[輸入百萬數 × ((1－命中率) × 4.775＋命中率 × 0.382)＋輸出百萬數 × 20.12] × 1.30`

`臺幣預算＝美元預算 × 32，向上取整`

| 情境 | 70% 快取、含預備金 | 無快取、含預備金 | 臺幣預算區間 |
| --- | ---: | ---: | ---: |
| 精簡 | US$96.51 | US$176.46 | NT$3,089～5,647 |
| 標準 | US$289.53 | US$529.39 | NT$9,265～16,941 |
| 反覆修正 | US$723.82 | US$1,323.47 | NT$23,163～42,351 |

建議先為標準情境保留約 NT$9,300～17,000 的 API 等值 token 預算。未含訂閱費、模型下載／伺服器、稅金、信用卡匯差、搜尋等額外工具費。API 與 Codex 的 Fast 加價規則不同，本表不啟用 Fast；單次請求盡量低於 272K 輸入，跨門檻需重新套用該模型費率。

只用 Astra 可能減少來回輪數，但同樣 token 數通常單價較高；不要直接把混合模型的總額當成全程最高模型的預算。

### 13.4 如果你是 Codex 訂閱使用者

上表是 API 等值試算，不是 Codex 訂閱會自動逐 token 向你扣這筆臺幣。官方目前列 Plus US$20／月、Pro 5x US$100／月、Pro 20x US$200／月；包含用量與模型權限依方案，不能只用訂閱金額推算能做完幾個功能。[官方 Codex／ChatGPT 定價](https://learn.chatgpt.com/docs/pricing)

以 2 個帳期的預算示例、US$1＝NT$32：Plus 約 NT$1,280；Pro 5x 約 NT$6,400；Pro 20x 約 NT$12,800。若跨 3 個帳期則各乘 3 個月，稅費另計。這只是訂閱費，不保證額度足夠，也沒有確認你目前訂閱哪一種。已付訂閱且額度足夠時，這項開發的額外現金支出可能為零；總體訂閱成本仍存在。

官方另列 credits 費率，可用來估算追加用量，而不是把 API 美元價格硬換成帳單：

| 模型 | 每百萬一般輸入 credits | 快取輸入 credits | 輸出 credits |
| --- | ---: | ---: | ---: |
| Astra | 250 | 25 | 1,250 |
| Sol | 100 | 10 | 500 |
| Terra | 50 | 5 | 300 |
| Luna | 5 | 0.5 | 30 |

沿用同樣模型比例、70%～0% 快取及 30% 預備量，精簡情境約 2,227～3,791 credits，標準約 6,680～11,373 credits，反覆修正約 16,699～28,431 credits。此處用官方 credits 表直接計算，不套用上面為 API 設的 25% 寫入預留；實際需購買數量還須扣除適用的內含用量。credits 的現金售價／折扣依帳號與方案，不在未查看購買頁前臆測。

務必避免重複加總：使用訂閱內含額度的工作，不再同時計一份 API 費；使用 API 金鑰跑的工作，才依 API 帳單計；超過內含量購買 credits，另依實際購買金額記帳。本輪沒有查你的帳單或購買任何額度。

## 14. 分階段預算與用量控制

標準 token 情境可先按比例分配；以下臺幣是 API 等值預算的大約分攤，合計因四捨五入可能略有差異。

| 階段 | 預算比重 | API 等值約 NT$ |
| --- | ---: | ---: |
| P0 驗證 | 10% | 930～1,700 |
| P1 共用骨架 | 15% | 1,400～2,550 |
| P2 ASR／校對 | 20% | 1,860～3,400 |
| P3 紀錄／方案 | 15% | 1,400～2,550 |
| P4 Windows 雙軌 | 15% | 1,400～2,550 |
| P5 邀請通話 | 15% | 1,400～2,550 |
| P6 整合驗收 | 10% | 930～1,700 |

先只投入 P0 的額度和時間。記錄實際模型、輸入、快取、輸出／推理、credits、失敗重試和 elapsed time；用 P0 成績修正後續預算，避免將本表當成保證價格。

預算到 70% 提醒檢查、90% 時整理剩餘工作與增額原因；計畫中的限額需由執行程式或帳號能力實作，不能只寫一句提示詞就宣稱有硬性支出上限。若當前工具拿不到 token，明確記「未提供」，不能拿訊息數推算成實際帳單。

省用量方式：少量主代理、只在獨立工作上開子代理；固定接口後再平行；不要重讀整個 repository；長紀錄轉成精簡交接；保留失敗案例避免重試同樣錯誤；模型按任務選擇；不用最大推理等級處理繁體詞彙或一般表單。不要為省 token 跳過雙方錄音與事實引用驗證。

## 15. 產品上線後的費用

### 15.1 本機開源執行

本機跑 Breeze／Whisper 轉寫、pyannote、TAIDE／Qwen 整理，沒有供應商逐 token 收費；仍有電力、電腦／GPU、儲存、維護與時間成本。開源不等於零總成本。硬體未診斷前不承諾一小時錄音幾分鐘完成，也不因社群宣稱 4GB 可跑就認定適合本案長錄音。

### 15.2 可選付費文字 API

只把文字摘要／方案改用付費 API 時，以每一小時對話的整套整理共計 30,000 輸入＋5,000 輸出 token 試算。這是所有摘要／方案步驟的累積假設，不是每小時語音固定等於這麼多 token；產品文件多、重做或長篇推理會增加。

| 文字模型 | 每小時對話的文字處理費 | 每月 100 小時對話 |
| --- | ---: | ---: |
| Luna | US$0.012，約 NT$0.38 | 約 NT$38.40 |
| Terra | US$0.12，約 NT$3.84 | 約 NT$384 |
| Sol | US$0.22，約 NT$7.04 | 約 NT$704 |
| Astra | US$0.55，約 NT$17.60 | 約 NT$1,760 |

此表用一般輸入與輸出標準費率，未加快取寫入、工具、稅金或額外重試，也不含 ASR／通話／存檔。建議以 Terra 作付費對照，Luna 只在品質通過的窄任務使用；本機 TAIDE／Qwen 可以完全不走這個 API 費。不要因文字整理費低就推論整個系統每月只要幾十元。

### 15.3 音訊、伺服器與容量

商業 ASR 若要用雅婷或其他 API，正式接口、臺語輸出、語者功能及每分鐘費率需以供應商方案另核實，本版不編造報價。本機 ASR 的輸出 token 不等於上述付費文字 token。

單人試用可先預留每月 NT$1,000～3,000 作網站／API、通話、私有儲存與備份的工程預算額度；這不是已取得的主機報價。前提為每月約 100 小時、一對一低並發，語音與本機 LLM 用自有工作機，未含雲端 GPU、硬體、維護人工或付費 ASR。若服務節點、TURN 流量或地區價格不符合，需重估，不承諾固定包月。

每軌 48 kbps 一小時約 21.6 MB；雙軌約 43.2 MB，100 小時約 4.32 GB，暫存 WAV、備份與版本另加。雙人通話一小時是 120 參與者分鐘；兩條完整音軌分別送付費 ASR，可能是 120 音訊分鐘。以供應商實際規則計，不直接都當成 60 分鐘。

## 16. 驗收：以臺灣真實談話為準

建立至少四類樣本：臺灣華語、華語夾英文、臺語、華臺混用；另覆蓋兩人輪流、插話／同時說話、年長口音、咖啡店背景、耳機與擴音。先用短樣本篩選，再用 30～60 分鐘驗證漂移與遺漏。測試資料由使用者提供或使用可合法測試的公開資料，正式原音保留。

| 項目 | 驗收方法 |
| --- | --- |
| 華語文字 | 人工建立參考稿，按同一繁體正規化口徑算 CER；清晰雙人樣本初始候選目標 CER≤10%，不把它當成既有成績 |
| 語者歸屬 | 單獨算非重疊有效發言時間的歸屬正確率，初始候選目標≥95%；重疊段另外報告 |
| 臺語正字 | 若測真正臺語原稿，使用臺語參考稿與臺語能力校對者 |
| 臺語轉華語 | 檢查語意、金額、人名、否定、承諾有無遺漏；不能直接與臺語正字稿算 CER 比高低 |
| 時間與音軌 | 兩軌可獨立播放；檢查重連／暫停和長錄音；參考點偏移目標≤300 ms，不達標列限制 |
| 重要事實 | 被引用的金額、幣別、日期、產品名與同意／拒絕全部人工確認 |
| 摘要／方案 | 每個關鍵結論有正確來源，不能把建議變成決議、轉譯變成原句 |
| 復原 | 斷網、來電、關閉頁面、拔耳機、權限撤銷、儲存不足時不假報完整 |
| 權限 | 不同客戶資料隔離、邀請失效、未授權者不能下載原音 |
| 成本 | 每階段與每次處理有用量及計價口徑，未拿到 usage 就不寫成精確帳單 |

不同模型的「信心分數」不可直接互比；先以人工標註結果篩選。尚未驗證的臺語可標為測試模式，不能用國語測試結果替臺語背書。

## 17. 開始開發時的任務指令範本

以下是可複製的未執行指令；需要建立新任務時再明確下達。

> 請建立「臺灣商務對話助手—主開發」任務，承接本 v2 方案，先只做 P0。先確認專案目錄與硬體，讀交接後比較 Breeze-ASR-25、Whisper large-v3，以及 Breeze-ASR-26 的臺語轉華語結果；摘要比較 TAIDE 與 Qwen。保留通用開源參考，全部回覆和介面用繁體中文。此階段先用單一代理，不啟動代理團隊，不部署、不發送客戶訊息。交付同樣本報告、音軌與語者驗證、實際 token／credits、耗時及修正版預算；通過後再提出 P1 的具體範圍。

主代理初始可選 Astra／high 完成 P0 的選型與資料邊界；規格確定後，明確實作轉交 Terra／medium，複雜整合用 Sol；後續真要平行時，再下達有責任範圍與指定模型的代理指令。

## 18. 本版交付與未確認事項

已完成：市場調整為臺灣；全篇繁體；五功能完整保留；新增臺灣華語／臺語模型、臺語原文與轉譯區別；整理功能的無 LLM／有 LLM 路線；開源與商品證據；Codex 模型／代理／任務規劃；工期、API 等值、訂閱及 credits 的分開試算。

已核對官方模型卡、原始專案說明、部分摘要程式與 LICENSE，並以程式重算費用。未安裝模型、未用使用者錄音實測、未確認目前硬體與訂閱、未建立開發任務、未變更業務程式或部署。以上開源選型仍需 P0 實測後凍結版本。

後續若有新結果，更新本文件的版本與假設，不把未測項目改寫成已完成，也不因找到一個臺灣模型而丟掉其他開源候選。