概念位置

BNF 是 grammar 的一種表示法，特別適合描述 context-free grammar。規則左邊是非終結符，右邊是它可以展開成的符號組合；終結符是實際會出現在字串中的 token，非終結符是中間抽象節點。

1<expr> ::= <term> | <expr> "+" <term>
2<term> ::= <number> | "(" <expr> ")"

這段規則表示 expression 可以是 term，也可以是 expression 加 term；term 可以是 number，也可以是括號包住的 expression。

可觀察訊號與例子

看到 ::=、<name>、多個展開選項，就是 BNF 或 BNF-like grammar。LLM structured output 文章裡提到 BNF，通常是在說「把合法輸出格式寫成形式語法，推論時用它限制生成」。llama.cpp 的 GBNF、部分 grammar engine 與 parser 文件都會使用類似記法。

BNF 的限制是它描述語法，不描述語意。它能表示「括號必須成對」「欄位順序合法」，但不能直接表示「日期必須晚於今天」「使用者必須有權限讀這筆資料」這類外部約束。

設計責任

BNF 適合拿來讀懂 grammar-constrained sampling 的規則形狀。實作時要確認你使用的引擎支援的是標準 BNF、EBNF、GBNF，還是自家 dialect；不同 dialect 的 optional、repeat、token escaping 寫法會不同。下一步路由是 Grammar 與 Lark Grammar。

概念位置

Lark 是 Python 生態的 parsing toolkit，Lark grammar 是它的規則語言。它比傳統 BNF 更接近實作格式，常見元素包含 rule、terminal、literal、repeat、optional、ignore whitespace 與 start rule。

1start: query
2query: FIELD OP VALUE
3FIELD: "status" | "owner"
4OP: "=" | "!="
5VALUE: ESCAPED_STRING
6%import common.ESCAPED_STRING
7%ignore " "

這段規則描述一個很小的查詢語言，只允許固定欄位、固定運算子與 quoted string。

可觀察訊號與例子

看到 start:、大寫 terminal、%import common.*、%ignore，通常就是 Lark grammar 或受它影響的格式。LLM 場景常用它描述 JSON 子集、SQL-like query、指令 DSL、分類輸出或固定格式報告。

Lark grammar 的風險是把 parser 格式誤當跨引擎標準。某些 constrained decoding 工具支援 Lark-like 語法，某些只支援 JSON Schema、regex、GBNF 或自家格式；搬規則前要確認目標 server 能不能解析同一套語法。

設計責任

Lark grammar 適合需要清楚描述自訂格式、且工具鏈支援 Lark dialect 的場景。設計時先把合法範圍縮到應用真的需要的語法，再補 validator 處理外部狀態與權限。下一步路由是 Grammar 與 DSL。

代表性問題的案例

app_tunnel 的 ANSI parser 有 18 個 test，全部通過。測試資料是手寫的 SGR 色彩碼（\x1B[31mhello\x1B[0m），parser 正確解析這類序列。

真實 zsh 啟動後送出的控制序列包含 OSC 標題設定、CSI private mode、字元集指定等至少 5 種類型。Parser 只認識 SGR，其他全部透傳為亂碼（T.C3）。

18 個 test 覆蓋了 1 種序列類型。測試資料的代表性假設（「SGR 就是主要的序列類型」）和真實環境不符。

三種測試資料來源

手寫

開發者根據對輸入格式的理解手動建構測試字串。

優點：精確控制、容易理解、可以針對特定邊界條件設計。

缺點：受限於開發者對輸入分佈的認知。如果開發者不知道真實環境有哪些輸入類型，手寫的測試資料就是開發者認知的子集 — T.C3 就是這個模式。

適合場景：格式規格明確且有限（JSON schema、固定格式的設定檔）、邊界條件測試（空值、最大長度、特殊字元）。

錄製

從真實環境擷取實際的輸入資料，作為 test 的輸入。

優點：直接反映真實環境的輸入分佈，包含開發者不知道的輸入類型。

缺點：錄製的資料可能包含敏感資訊（需要脫敏）、資料量可能大（需要挑選代表性樣本）、真實環境的輸入可能隨時間改變（錄製的資料可能過時）。

適合場景：輸入格式複雜且規格不完整（終端機 escape 序列、網路封包、使用者產生的內容）、parser 類的功能（需要知道「真實輸入長什麼樣」）。

T.C3 如果用錄製的真實 zsh 啟動輸出作為測試資料，OSC 和 CSI private mode 會自然出現在輸入中。即使 parser 仍然不處理這些序列，test 至少能讓開發者看到「有 5 種序列類型，我只處理了 1 種」。

生成（Property-based testing）

用 generator 自動產生大量隨機或半隨機的輸入，驗證 parser 的行為是否符合通用性質（不崩潰、輸出長度 <= 輸入長度、冪等性）。

優點：覆蓋人類想不到的 edge case、發現意外的崩潰或無限迴圈。

缺點：不針對特定功能驗證（驗證的是通用性質，不是「OSC 序列是否被正確處理」）、generator 本身需要維護。

適合場景：parser、serializer、codec 等輸入格式複雜的功能。和手寫 test 互補 — 手寫驗證特定行為正確性，生成驗證通用穩定性。

兩類 test 的分工

T.C3 的策略建議是把 test 分成兩類：

功能正確性 test：用手寫乾淨字串驗證 parser 對已知序列的處理正確性。\x1B[31mhello\x1B[0m 應該產生紅色 token — 這是功能規格的驗證。

環境相容性 test：用錄製的真實輸出驗證 parser 在真實環境中的表現。不斷言「每個序列都被正確處理」，而是斷言「沒有崩潰」「沒有未處理序列殘留在可見輸出中」。

兩類 test 回答不同問題。功能正確性回答「parser 的邏輯對不對」，環境相容性回答「parser 在真實環境中夠不夠用」。

下一步路由

• Assertion 的品質判斷 → Assertion 品質三問
• Mock 邊界的判斷 → Mock 邊界判斷決策表
• Protocol integration test 用真實服務輸出 → testing 模組三 WebSocket 協議測試

觀察

app_tunnel 的 AnsiParser 負責解析終端機輸出的 ANSI escape 序列，轉換為帶色彩的文字 token。unit test 用手寫字串驗證：

1// 測試資料範例 — 乾淨的 SGR 色彩碼
2test('紅色文字', () {
3  final tokens = parser.parse('\x1B[31mhello\x1B[0m');
4  expect(tokens.first, isA<TextToken>());
5});

真實 zsh prompt 啟動後送出的控制序列（擷取自實機 log）：

1\x1B]0;user@host: ~\x07          ← OSC：設定終端機視窗標題
2\x1B[?2004h                      ← CSI private mode：啟用括號貼上模式
3\x1B[?1h                         ← CSI private mode：啟用應用程式游標鍵
4\x1B(B                           ← 字元集指定：選擇 ASCII
5\x1B[?25l                        ← CSI private mode：隱藏游標

Parser 只認識 \x1B[{數字;數字}{字母} 格式的標準 CSI，其他全部殘留在輸出中。

判讀

1. 測試資料的代表性是隱性假設。18 個 test 的斷言都正確 — \x1B[31m 確實應該產生紅色 token。但「測試輸入能代表真實輸入」是一個未經驗證的假設。真實 zsh 的輸出包含 5+ 種 escape 序列類型，測試只覆蓋了 1 種。

2. Parser 的行為對未知序列是「透傳」而非「報錯」。這是合理的設計 — 不認識的序列不應該讓 parser 崩潰。但透傳的後果是亂碼靜默出現在畫面上，不觸發任何錯誤或 log，開發者在 unit test 環境完全不會察覺。

3. 手寫測試資料 vs 錄製真實資料。如果測試資料是從真實 shell session 錄製的（capture 一次真實 zsh 啟動輸出），OSC 和 CSI private mode 會自然出現在測試輸入中，parser 的透傳行為會在 test 階段就被看到。

策略

1. 從真實環境錄製測試資料：用 script 命令或 WebSocket log 錄一次真實 shell session 的完整輸出，作為 integration test 的輸入。即使不改 parser 邏輯，至少能看到「哪些序列被透傳了」。
2. Parser 對未知序列記 warning log：透傳是合理的 fallback，但加一行 developer.log('Unknown escape: ${escape.codeUnits}') 讓開發者知道有未處理的序列。
3. 測試分兩類：「功能正確性」用手寫乾淨字串；「環境相容性」用錄製的真實輸出。兩類測試回答不同問題。

下一步路由

• 想理解測試資料代表性 → Test data 代表性
• 想建 protocol integration test 用真實 ttyd 輸出 → 模組三：協議整合測試
• 類似案例（mock 遮蔽） → T.C1 WS frame type mock 遮蔽