工具-讓LLM產出可驗證的產物

🎯 什麼情境該想到我

當你「要 LLM 產一個有結構的東西（圖、設定檔、報表、SQL、IaC），但沒辦法用肉眼一個一個檢查」的時候。

核心是一句話：不要讓模型產最終產物，讓它產 typed IR，最終產物由確定性的程式編出來。

模型 → typed IR（有 schema 的中介表示）→ 確定性編譯器 → 最終產物
                    ↓
              驗證閘（失敗回結構化診斷）

切開「判斷」與「計算」。把需要語義判斷的部分留給模型（該有哪些節點、誰接誰、什麼是主路徑），把可以精確算的部分交給程式（座標、間距、繞線、渲染）。模型不擅長的算術，就不要讓它算。
給 IR 一份 schema。有 schema 才能自動驗、才能明確告訴模型「欄位長什麼樣」，也才能給它一份範例——但要講清楚「範例是給你看欄位形狀，不是給你抄內容的」。
設分級的驗證閘，並明講哪一級才算通過。
例：4 項檢查＝基本驗證，9 項全過＋ 0 錯誤＋ 0 警告＝可交付。不明講的話，模型會拿低標當通過。
失敗要回「修復收據」，不是堆疊追蹤。一份好的診斷要有三件事：
- subject——出問題的確切那一項
- evidence——量到的數值（不是「看起來怪怪的」）
- supportedFixes——可用的修法清單（而不是讓模型自由發揮）
然後在指令裡限制：只改被診斷的那一項、一次只套一個修正。
寫死收斂條件。例：「持續修正，只要客觀錯誤數還在創新低；若連續兩輪沒有刷新最佳值，就停下來、如實回報未解決的診斷。」
通過即凍結、交付要原子。驗證通過的產物不准再編輯；交付時先在私有快照上渲染檢查，通過才原子替換目標檔案，並回報 SHA-256 與 byte count。

一次性、給人看一眼就丟的東西不值得這樣搞。這套的成本在寫 schema、編譯器與驗證器，要重複產出、且錯了有代價才划算。
驗證閘只能擋「可機器判定」的錯。版面好不好看、措辭恰不恰當，機器驗不了——不要讓自動收據去宣稱它沒驗的事（見工具-防止agent造假通過驗收）。
schema 太鬆等於沒有。如果驗證器只檢查 JSON 合法性、不檢查語義約束，模型照樣產出合法但錯誤的東西。
別把中介表示做成第二個最終格式。IR 的價值在「好驗、好改、好局部修」；設計得跟輸出一樣複雜就失去意義了。
這套解決的是**「產出正不正確」，不是「產出好不好」**。後者要靠對照評測 → 工具-AI改動的AB對照評測。