可切換喚醒 Provider：STT / Manual

🎛️本輪 · Provider switch 實作與驗收

Plan 與範圍

設計與施工依據： 2026-09-02-switchable-wake-provider-design.md、 2026-09-02-switchable-wake-provider.md。 本輪只交付 stt / manual；未來 iGo / DSpotter acoustic authority、generation/sample clock 與 One-shot 音訊裁切仍屬後續 cycle。

Architecture 與 frame flow

本輪 acceptance 與 Feature-first traceability

🔖累積基線（2026-08-31）· 代號說明

本報告引用四個代號家族。讀者手上只有這一份檔案，所以每一個都在這裡定義。 本輪只採用 #3；其餘代號出現，是因為它們被評估過並判定不做（理由在各自的小節）， 或是從前幾輪的累積表承接下來的。

🎯1 · 目標與承接

上一輪（2026-08-18-multiuser-concurrency）把 SW 流程設計（面向 B）優化到接近極限——M1 背景解碼把共用 frame 路徑佔用率從 65–78% 壓到 2–4%——並把八個「換掉模型之後還算不算數」的候選整理成清單，判給面向 A（模型推理能力）交下一輪。本輪要回答的就是那張清單：哪個先做、代價多少、做完有沒有達到預期。

沿用前輪的 SW_id（累積 ledger，只增不減）

本段承接 2026-09-01 當時的最新累積表；依 CLAUDE.md §6 第 2 點與 SW-DOC-02，須涵蓋歷輪聯集的所有 SW_id。下列各條不是本輪驗證的—— 本輪未觸及其行為，故沿用前輪結果，並指向規格與其測試；本輪自己的追溯在上方各表。

🧪2 · 實驗方法

§2.1–2.4 沿用上一輪、內容未改（重繪內嵌而非放連結，見 docs/spec.md 附錄 A 的規範）；§2.5 是格點表裡「逾時」的判準。

這節寫下本報告每個數字是怎麼產生的，包含失敗過的做法。它們不是流程細節：本輪已經因為 違反其中幾條而撤回過結論（單次量測就下判斷、比較基準沒對齊、聚合把效應抹掉），而下面的 「量測缺陷」小節裡有三個缺陷，若沒被抓到，整份報告會建立在系統性偏差的數字上。

本節多處提到「組態」。兩個組態（SW 整體優化／＋#3）的定義見 §4.1，與它們的對比結果放在一起。

2.1 · 數字從哪裡來：server 自己量自己

主數據一律由 server 量測自己，client 端讀數不作為結論依據。要回答的問題是「server 的 能力」，而 client 收到 final 的時刻混了兩個與 server 無關的東西：client 自己的 CPU 排程，以及 client 與 server 同機時互搶 CPU。client 只負責產生刺激。

[Seg] 的 Seg 取自 segment：一次 interim 就是把成長中的 segment buffer整段重解一遍，這行印的是那一次重解的分段耗時。[SegF] 刻意用同一個字首，所以 grep '\[Seg' 一次抓到兩者、grep '\[Seg\]' 只抓 interim——兩行的欄位集合不同（[Seg] 有 seg_lock／occ，[SegF] 有 itn），分析腳本靠這個分流。這三個標籤是量測期間 log 的原字串，本報告照抄以便重跑時 grep 得到；那次量測用的 logger.debug patch 已還原，現行程式碼裡沒有這幾行 log。後續已把同一批欄位（prep／seg_lock／rec_lock／decode／post／itn／audio_lag／occ）改記在既有的 Perfetto trace（debug.profile_dbg，不開時零額外行為），取代「量測時 patch 原始碼、量完再還原」的做法——見 tests/test_cost_trace.py（純觀測工具，依使用者裁定不掛 SW_id，同 test_live_uri.py 的處理方式）。本機以真實 server 產生過一份 trace 驗證：事件名稱／數量互相對得上／uid 正確路由到座位／數值量級合理。

哪一個數字用在哪

同一個量有 server 端與 client 端兩個讀數，兩者適用的場合不同，本報告的分工固定如下：

2.2 · 指標與欄位定義

本節是全篇的命名依據。下面第一張表是數據圖與總表用的指標，第二張是單次解碼內部的分段欄位。 報告其他地方一律用第一張表的指標名稱，不再出現同義的別名。

active 是整句期間看到的最大同時說話人數，不是 log 當下的人數——在 final 那一刻計算會低估， 因為那時其他座位多半已經講完，4 人的格點會被標成 1 人，單人與多人兩節就會混在一起。

2.3 · 環境

2.4 · 網格與統計

2.5 · 「逾時」是什麼意思

格點表裡的逾時不是「等一下就放棄」——判準是工具寫死的 timeout = max(120 秒, 音檔長度 × 15)，而且從 VAD-stop（講完）那一刻才開始計時：

門檻寬鬆是刻意的：正常情況 final 在講完後 100–300 ms 回來，而多人塞車時排隊本來就是要量的現象。上限設得緊會把「慢但仍有效」誤判成「壞掉」，就分不出劣化與失效——所以逾時代表該組態在該負載下不會回 final，那是結果，不是量測失敗。

🧠3 · 面向 A：模型推理

3.1 · 候選清單：承接的八項 ＋ 本輪追加的兩項

上一輪把八項候選留給本輪，判準是「換掉模型之後這一項還算不算數」——只在「用 offline 模型定期重解整段」這個策略下才存在的手段，都不屬於 SW 流程設計。本輪處理了其中五項，另加兩項使用者提出的延伸方向。這張表只回答「有哪些候選、各自想做什麼、去哪一節看」；每一項的量測與判定在它自己的小節裡。

3.2 · 成本結構：為什麼先動 prep

單次 interim 的成本會隨句子變長而上升，prep 與 decode 兩者都在漲—— 差別在漲的幅度。10 秒句、比較句首 ¼ 與句尾 ¼ 這兩段的同一項成本：

decode 也在漲（1.21×），但 prep 漲了 4.16×——句子越長，成本的增量越是由 prep 貢獻的。 再把 prep 拆開（上一輪的微基準）：create_stream 是常數、波形串接可忽略， prep 的 98% 是 fbank，且嚴格線性（約 5.5 ms／每秒音訊）；對照 decode 的 1.5 ms／秒， 斜率差 3.7 倍。所以 10 秒句上特徵抽取（55.4 ms）已經比模型推理（51.2 ms）還貴。

這就是把 #3 排在最前面的理由：兩項都值得優化，但 prep 是隨句長漲得最兇的那一項—— 打它拿到的是斜率，打 decode 拿到的只是截距；而且它是唯一不用拿準確度去換的（特徵逐 bit 相同）。 decode 那一側的斜率要打，就得動窗口化（§3.3.2），那才需要用準確度換。

3.3 · 逐項的量測與判定

下面六節依 §3.1 表格的順序展開，每節的結構相同：機制 → 效益 → 代價 → 判定。判定與依據摘要已在 §3.1 的表上，這裡是它們背後的量測。

3.3.1 · #3 prep 增量化　已採用

一 · 機制：把「每次重算整段」換成「只算新增那一段」

差別只在「每次 interim 餵給特徵抽取器的是什麼」（圖 1）：

為什麼原本做不到，以及為什麼改動成本很小：OfflineStream 的 AcceptWaveform() 內部立刻呼叫 InputFinished()，fbank 一旦 finish 就不能再收音訊——所以只能一次性餵。但真正做增量的引擎（knf::OnlineFbank）早就在串流路徑上跑產線，OfflineStream 只是沒把它的增量能力暴露出來。改動是拆開「收音訊」與「宣告結束」兩件事，不是新寫演算法——這也是特徵能逐 bit 相同的原因。

二 · 效益（1/3）　prep 本身：從隨句長成長，變成與句長無關

k8s（T4）同機交替實測，依該次 interim 的 buffer 累積長度分層（圖 2）——分層才看得到斜率，而斜率才是這個優化的性質（打平），倍率只是它在某個長度上的截面。

二 · 效益（2/3）　整通 interim 呼叫：效益隨句長放大，而且買到「不崩」

2×2 四條線 × 15–90 秒 × 16 個長度點，單人、真實流速。加「固定 500 ms」那一軸是為了排除排程這個共變因——否則反應式排程「少解幾次」會偽裝成「每次變快」。所以主證據是total latency（推論時間總和） ÷ interim 更新次數＝解一次的錢（下表；四指標全貌見圖 3）：

「不崩」的門檻可以引用哪一半：順序是穩定的（開 #3 撐得比關 #3 久），絕對門檻不是——§3.3.2 那輪同組態的 f0（#3 ＋ 固定 500 ms）在 90 秒仍未崩潰（RTF 0.473、最大間隔 2.79 s），而本輪同組態的 l3 在 80 秒就失控。差異在量測條件（本輪帶 cpu request 1200m 且四臂共用同一時段負載）。所以「80 秒」是那次條件下的數值，不是組態的性質。
其他量測限制：單人，所以這裡看不到 §4 的多人排隊效應；每個長度點 1 輪，不重複取樣（16 點同向已足以定方向，個別點仍有 ±10% 級的機器雜訊）。l4 在 60–70 秒兩次逾時後放棄，75–90 秒未量——那不是缺資料，是該組態在那個長度不會回 final。

二 · 效益（3/3）　連別人的 decode 一起變快：M1 引入的 CPU 競爭砍半

M1 把 prep 移出 frame 路徑後，四座位的 fbank 變成真的併發，於是互搶 CPU（2026-08-18 §附錄 D.1 量到 prep 33.8 → 62.1 ms）。#3 把每次 prep 從「整段成長中的 buffer」縮成「新增的 0.5 秒」，所以它應該連那個競爭一起縮小——這是先前沒量過的二階效益，也是三個尺度裡唯一「效益落在別人身上」的一個。

三 · 代價：把「零準確度風險」變成可執行的檢查

#3 的代價欄之所以能寫「零」，不是因為改動看起來安全，而是因為「零」在這裡剛好是一個可以直接測的命題： 增量餵入與一次性餵入算出的特徵必須逐 bit 相同。這一節就是那個命題被拆成哪些檢查、每個檢查在防哪一種失效 （依 CLAUDE.md §2.5 Rule 2：有門檻的驗收條件必須有可執行的檢查，否則只是願望）。

3.3.2 · #4 滑動窗口　三種切法都不做

A · 滑動窗口要怎麼實作

「滑動窗口」的意思是不要每次都從句首重解——只把「最近這一段」送去解碼。但「只解最近一段」本身還不是一個做法： 要落地必須回答兩個彼此獨立的問題，兩個答案組合起來才是一個具體實作。 第二個（合併）最容易被漏掉，而它正是本輪量出來影響最大的那一個—— 固定視窗曾經量到的 89% CER，量的其實是合併實作，不是切法。

軸 1 · 切法：左緣由秒數決定，還是由內容決定

逗號的秒數從哪裡來：token 時間戳

軸 1 的「標點切」有一個前提：知道文字上有逗號沒有用，要知道它在第幾秒，才切得動音訊。 那個秒數來自 OfflineStream 的 token 時間戳，所以先把它講清楚——它是什麼、數字怎麼產生、 逗號為什麼也有一個。這不是第三個軸，是軸 1 能不能落地的先決條件。

實際的一次解碼長什麼樣

拿本報告一路在用的那句 base phrase（10.495 秒、51 個 token）真的解一次，把前 14 個 token 與它的時間戳列出來：

SenseVoice 是怎麼知道要加逗號的

整個標點切建立在「模型會自己吐逗號、而且那個逗號有時間戳」上，所以先講清楚這件事怎麼成立的—— 它不是外掛一顆標點模型（FunASR 那條線是另外接 ct-punc），而是標點本來就在 SenseVoice 的輸出詞彙表裡。

軸 2 · 合併：切完之後，新解出來的字怎麼接回已經固定的字

兩種切法各自有一份已寫成程式碼的合併實作。主訊號是同一個——最長文字重疊； 真正的差別是比對不到的時候做什麼，以及為此需要幾個額外機制。

兩個軸與動態排程在哪裡相遇

B · 成本／效能分析

同一顆 image、同一時段、同一顆 T4，四臂一起跑（基準＋三種切法），所以圖 6 的線可以互相比較。

這一節只看一個量：total latency——整句話所有 interim 解碼的內部時間加總。 理由是 interim 路徑本來就是「把成長中的 buffer 重解很多次」，所以一句話真正花掉伺服器多少推論，就是那些次數的總和； 單看「一次多貴」會漏掉「跑了幾次」。它同時是唯一能跨輪對照的成本量：2026-07-29 的 RTF 定義就是 total latency ÷ 音檔長度，乘回音訊秒數即可換算成同一個軸（見 §2.2 跨輪對照表）。

為什麼 §3.3.1 用的是「解一次的錢」而這裡用總和：那一節的四條線刻意跑不同排程 （反應式 vs 固定 500 ms），解碼次數本來就不同（90 秒 90 次 vs 115 次），用總和會把「少解幾次」讀成「每次變快」。 這一節的四臂共用同一個排程，次數落在 123–140 之間，總和才是可以直接比的。兩節的選擇不同，是因為要排除的混淆不同。

C · 準確度分析

這一節是怎麼量的

量的是使用者在句子講完前的最後一瞬間，螢幕上實際看到的那串字——最後一次 interim—— 拿它跟該段音訊自己的 final 逐字比對。

四種做法，全部量完

但「插入 0.84%」這個數字說不出插進去的是什麼字，而那才是使用者看到的東西。 下表把每一列插入的字抓出來數——本節語料每段是一次 TTS 合成、沒有任何拼接點 （gen_corpus/make_texts.py），所以這裡出現的字都是切法造成的，不是音檔本身的瑕疵。

逐字對照：實際長什麼樣

數字說有多少錯，說不出是哪一種。下面是實際字串，每一個編輯都標出來。

D · 總分析：能不能做

B 與 C 各自都不足以定案——效能最好的可能準確度最差。兩軸並排，答案就出來了。 C 節的結論是：準確度不再區分這三種切法（四列落在 1.2 pt 之內，錯誤都由模型自己的替換主導）。 所以判定實際上由效能與實作複雜度決定，而不是由 CER。

E · prep 的行為：左緣多久移動一次，決定 prep 長什麼樣

本節有兩個用途，都與已採用的 #3 直接相關。 其一：它量出 #3 自己的 prep 會隨句長成長（90 秒爬到 18.73 ms）—— 原因是 get_frames() 每次都複製 stream 從第 0 幀到現在的全部幀，而 stream 累積整句話。 這是 #3 已知的成本形狀，也是判斷「什麼手段能壓掉它」的依據。 其二：#4 判定不做，但若日後重開（§5 的重開條件）， 「切法會不會把 #3 的增量性毀掉」是必須先答的問題——這裡把答案量了出來。

方法：把三種左緣行為各跑一遍完整的 interim 迴圈（0.5 秒一次，與服務的 fed_s 中位數 0.52 秒一致）， 量每次 interim 的 prep：#3 單獨（左緣不動）、固定 3 s 視窗（左緣每次 interim 都動）、 標點切 ＋ #3（左緣只在逗號跳一步）。

直接把三種策略各跑一遍完整的 interim 迴圈（0.5 秒一次，與服務的 fed_s 中位數 0.52 秒一致），量每次 interim 的 prep： #3 單獨（左緣不動）、固定 3 s 視窗（左緣每次 interim 都動）、標點切 ＋ #3（左緣只在逗號跳一步，其餘時間走 #3）。

三條線為什麼長這樣：把 prep 拆成「餵入」與「取出幀」

一次 interim 的 prep 做兩件事：把音訊餵進 fbank，以及在解碼前把已算好的幀取出來（get_frames()）。 這兩件事的成長方式完全不同，三條線的差異全部由它們解釋。同一顆節點量的：

3.3.3 · #5 final 重用最後一次 interim　不做

機制：VAD 宣告停止前的靜音期間伺服器是閒著的，而最後一次 interim 已解過幾乎全部音訊。若 VAD-stop 到達時新增的只有靜音，就直接用該結果走 HR → ITN，跳過 prep 與 decode。

效益：~94 ms，已被 #3 稀釋一半

上一輪估「317 → 約 150 ms」（省 167 ms），實測只有 95 ms——因為 #3 已經先把 prep 壓下去了，#5 的效益被自己人吃掉一塊。

代價：7.4%，而緩解手段已驗證不可行

A2 量到最後一次 interim 與 final 不一致 7.4%（27 句中 2 句），兩句形狀完全一樣：final 比 interim 多收句尾一兩個字（「風量。」→「風量開。」）。這看起來可以用「新增的音訊是不是靜音」擋掉——本輪直接驗證這個推論，結果是推翻。

方法：對 28 個真實 WAV 模擬「最後一次 interim 在結尾前 gap 秒處切斷」，分別解碼切斷版與完整版，問 (a) 剩下那段的 RMS 是否低於閾值 (b) 重用是否真的正確。gap 取 0.2／0.4／0.8／1.5 秒，共 112 組：

3.3.4 · 縮短 leading_pad_secs　不做

每次解碼都在音訊前面補 0.5 秒靜音，理由寫在 config 註解：「讓模型前端有左側脈絡，第一個音素不被切掉」。這個值從未被驗證過，而多數語句開頭正是喚醒詞，所以縮短它會直接打到專案最敏感的指標。用產線相同設定（同模型、HR lexicon ＋ rule FST、use_itn）對 28 支真實 WAV 逐一比對：

好消息是那個 pad 保護的東西沒有失守：即使 pad=0，沒有任何一支音檔掉了第一個音素，所有「你好鴻華」都完整。差異幾乎全是標點（你好，鴻華 → 你好鴻華、逗號變句號），而喚醒比對本來就是逐字拼音、不看標點。甚至有一支是短 pad 反而更準（multiuser-10s：pad=0.5 少了「大」字，pad=0.3／0 都正確）。

但省不到東西：2–4%，落在雜訊內。而它換到的是一個安全邊際的消失，以及文字會隨 pad 長度擾動這件事本身（模型對前導靜音長度是敏感的）。

3.3.5 · 調整 num_threads　維持 2

num_threads=2 是寫死在 batch_asr_manager.py 的預設值、不能從 config 調，所以從沒有人變動過它。兩個懷疑它的理由：部署節點只有 2 vCPU，而 onnxruntime 在解碼期間自旋等待（2026-08-18 §附錄 D.1），加上 prep 刻意放在共用鎖外面、四座位真的併發——這些加起來會嚴重超訂那台機器。用 taskset 把行程綁在 2 核上模擬該節點：

三個值的差異都在 7% 以內，判為無差別。原因清楚：decode 跑在 GPU 上，ORT 的 intra-op 執行緒不是瓶頸，所以調它幾乎沒有作用。

3.3.6 · M5 跨座位批次解碼　不做

要解決的是搶鎖排隊，不是解碼速度。四個座位共用一個辨識器鎖，interim 同時到期時它們被一個一個服務—— 第四個座位得等前面三次解碼跑完，自己才開始。sherpa-onnx 的 decode_streams() 可以把多條 stream 折成一次呼叫， 所以搶到鎖的人可以把已經排在後面的人一起解掉。鎖沒有變多，變的是一次拿鎖做多少事。

兩條線：decode_stream 對 decode_streams

M5 換掉的就是這一次呼叫，所以先只看這一次呼叫：四個座位同時到期時，把它們全部解完要多久。 decode_stream 是今天的行為（各自拿鎖、各自解一次），decode_streams 是把四條折成一次。 只計時 decode——建 stream 與抽特徵在兩臂是相同的工作，放進計時器只會稀釋要量的比值。

#4 與 M5 一起做，效益比兩者相加更大

先說量在哪：以下全部是本機 4090 的隔離實測（experiments/m5_batch/bench_batch.py， 25 次中位數、每個 shape 先暖機、只計時 decode 呼叫）。k8s T4 的交叉確認列在最後一列。 選在 4090 先量是因為它快、可反覆重跑；方向確認後才拿去 T4 驗，而 T4 的翻負點更早——結論的方向兩台一致。

M5 的加速由兩件事決定，而 #4 同時改善了這兩件：

機制：先掛佇列，再搶鎖

能做到上圖下半的關鍵只有一行的位置——掛佇列發生在拿鎖之前：

排隊的代價

表格裡每一格是「毫秒」：從辨識器空出來的那一刻算起，到那個座位拿到自己的解碼文字為止。 四個座位在同一瞬間到達（interim 同時到期）。

3.4 · 小結

八項候選全部裁決完畢（＋兩個延伸方向）。#3 是唯一「零準確度風險 × 效益最廣」的候選，已落地並驗證；#4 依兩軸（效能／準確度）交叉裁決，三種切法都不做——三種之間分不出高下（90 秒句彼此只差 0.44 pt：固定 8 s 3.10%、標點切 3.15%、固定 3 s 3.54%），但三種對「不切」的真實服務下限 2.42% 都是退化，而退化的長相是使用者看得到、且永久不可修的：標點切每 90 秒句多貼 3.84 字（不切 0.00），其中 哎×50 啊×21 是語助詞，成因是鎖定後第一個視窗只有約 0.5 秒且開頭就是那個停頓（實測該情況 19% 會吐，1 秒降到 3%）；句首英文詞會被鎖成殘字（podcastcast → pt）；固定視窗則漏 4.1–4.5 字／段。好處那一側只證明在 total latency（產能指標，非體感）上，而 interim 最大間隔 的逐長度形狀是單輪雜訊（15–20 秒看起來好一倍，30／50 秒方向相反），「省下的算力會不會變成更新變密」本輪沒有量到可用的結論。features.punct_window 設為 false。 timestamp 對齊已退出候選（方向隨語料翻轉、成本一致更貴）；#5 代價高於效益，判定不做；M5 判定不做——加速依賴 buffer 夠短，而 #4 不做之後長句 buffer 是 30–60 秒，批次在那個區間是負的（k8s T4 四座位 30 秒 0.91×、60 秒 0.95×；decode_streams 把每條 stream 補齊到最長那條）；程式碼與測試已從樹上移除。重開條件：任何機制把送去解碼的音訊壓到 10 秒以內（四座位同時到達時最慢座位 1.64–2.20×，批次結果與逐一解 8 組逐字相同；4 座位加速 0.5 s 3.49×、20 s 僅 1.30×，而標點切之後四座位不等長的實際樣子是 5.37×——#4 把輸入壓短，M5 才吃得到紅利。批次由鎖爭用自然形成，不形成時沒有效益也沒有代價，上線後以 trace 的 batch_size 分布追蹤）；兩個延伸（leading_pad、num_threads）量了都判定維持現況。M4／M6／#6／M7 判定不做——判準是使用者感覺到的凍結時間（相鄰 interim 最大間隔）：更新密度變低且每次更新等更久就不做，會被讀成卡頓。四者的淨效果都是把凍結時間拉長（M6 是唯一有翻案空間的，但要量出淨縮短，本輪沒量）。見 §3.1。

📊4 · 整體格點總表：這一系列優化的進度

本輪是這一系列優化的最後一輪，所以本節量的是整體：把 2026-07-29 的反應式排程、 2026-08-14 的 ITN 數字守門、2026-08-18 的 M1 背景解碼、以及本輪的 #3 全部關掉，對上全部打開。兩條線，其他什麼都不比。

4.1 · 兩條線的定義與對齊

4.2 · 量測條件與限制

• 「逾時」不是資料缺漏，是結果。某格點所有座位都沒拿到 final 時，表格記 0/12、圖上畫 ✕， 不是把那一點丟掉。優化前有兩個格點全滅（15 秒 × 4 人、20 秒 × 4 人）。
• 三輪取中位數，避免單輪離群值主導；優化前長句多人的展幅本來就大，中位數是保守的選擇。
• 本節是組態級對照，不是單一優化的歸因。#3 自己的歸因在 §3.3.1 （同機交替、固定排程對照軸）。
• 沒有量 CER。兩臂的模型與後處理完全相同，#3 的特徵逐 bit 相同，所以輸出文字不變。
• 兩臂都在收完數據後才修掉的那個競態上跑（交棒撞上 interim 餵入，見 §5）。 這對本節無影響——該競態造成的是文字重複，而本節量的是延遲／RTF／凍結時間，不量文字。 修正後的唯一差別是約 1/17 的句子 final 會多抽一次 fbank（毫秒級）， 相對於表上的秒級數字可忽略，而且兩臂同時受影響。

4.3 · 數據圖

六個面板 ＝ 六個句長，面板內的橫軸是座位數（1–4 人）。要看的是「座位堆上同一顆辨識器時會發生什麼」， 所以比較一律在面板內沿人數軸進行——面板裡除了人數，其他條件全部固定。 四張圖都是同一批資料：24 格點 × 兩臂 × 三輪取中位數。

4.4 · 總表（24 格點，三輪中位數）

4.5 · 逐指標分析

4.6 · 總判定

📋5 · 待辦（本輪已知未完項）

依 CLAUDE.md §6 第 6 點，這一節是 current-state：完成的項目從表中移除，不留紀錄列。

🏗️附錄 A · STT SW Stack 架構與資料流

#3 的 stream 生命週期是本輪唯一改變資料流的東西，所以它的重置點必須列全：一條 stream 絕不可跨 utterance（fbank 的內部狀態會汙染下一句），所以每一個「buffer 被清空」或「新 utterance 開始」 的地方都要把它設回 None。

Frame I/O 契約表

✅附錄 B · 測試（累積）

Feature 總覽

每個 PRD Feature 是否有 STT SW_id 與測試。

📐附錄 C · Feature / 驗收覆蓋檢查

本附錄沿用 2026-08-18 那一輪（覆蓋檢查是累積的），所以列內的「§n」節號指的是該輪報告的節號，不是本報告的。本輪自己的追溯在 §3 各小節與附錄 B。