前言：當「程式碼」不再等於「意圖」
在過去幾十年的軟體工程實踐中，「我們的程式碼」就是「我們意圖」的直接體現。我們親手設計架構、定義介面、編寫邏輯、除錯邊界。每一行程式碼都是思維的具象化。即便存在溝通偏差，也主要發生在人與人之間。一旦進入編碼階段，意圖便牢牢錨定在程式碼之中。
因此，傳統意義上的「意圖對齊」，往往止步於需求理解的一致性。然而，在 Vibe Coding 與 Harness Engineering 等新興典範橫捲開發流程的今天，這一等式被徹底打破。
程式碼不再是意圖的載體，而是 AI 對你意圖的「翻譯結果」。
這意味著，「意圖對齊」的矛盾點，從「人與人」轉移到了「人與 AI」之間。而且要求更高、容錯更低。你不能再依賴「邊寫邊想」或「程式碼即文件」的模糊默契，而必須近乎 100% 精確地向 AI 傳達以下資訊：
- 執行順序：先做什麼？後做什麼？哪些步驟不可並行？
- 技術選型：用什麼框架？依賴哪個版本？是否允許引入新函式庫？
- 架構規約：模組邊界在哪？哪些是禁區？資料流如何約束？
- 開發方式：一般開發方式，還是測試驅動開發（TDD）？
- 上下文資產：知識庫存放在哪？已有介面契約是什麼？
- 環境限制：執行時資源上限？網路策略？安全合規紅線？
- 驗證標準：如何才算「完成」？測試覆蓋哪些路徑？失敗語義如何定義？是否需要 E2E？
缺失任何一環，AI 都可能基於其訓練資料中的「常見模式」進行合理但錯誤的推斷。這正是早期 Vibe Coding 最為詬病的：自以為是，自作主張。而這些缺失的資訊，正是「意圖與結果差距」的根源。
意圖與結果的差距：諸多因素都會導致不好的產出
在 Vibe Coding 的實踐中，我們常常陷入一種錯覺：只要把想法「說」出來，AI 就能「懂」並「做對」。但現實是：意圖 ≠ 指令，指令 ≠ 實現，實現 ≠ 正確。
模糊不清的自然語言
自然語言擅長傳遞情緒與方向，卻極度缺乏工程所需的精確性。畢竟自然語言本來就是用於高效的「人與人溝通」，沒人會喜歡事無鉅細地描述，例如早餐的配料、火候、口感及其對身體的長期影響。
「優化一下效能」、「讓程式碼更清晰」、「處理得更穩健些」。這類表述在人類協作中倒是挺常見的，但在人機互動中卻是災難的起點。AI 無法感知你的潛台詞，只能依據機率選擇「最可能」的解釋（來自訓練資料）。而這個解釋，往往與你的真實意圖南轅北轍。
匱乏的上下文知識
AI 對你的系統一無所知，除非你明確告訴它：
- 哪些服務是核心鏈路，哪些是邊緣功能？
- 欄位的意義是什麼，哪些是不能修改的，禁區在哪裡？
- 這個介面的 RPC 呼叫路徑是什麼？
- 快取失效後，是降級，還是返回錯誤？
- 快取的過期時間是否要加入 20% 隨機浮動，避免快取擊穿？
這些「組織內部常識」，如果你不「顯式」地注入上下文，AI 便會用過去訓練它的通用模式填補空白。結果往往是錯誤的降級策略、越權的資料存取，或與現有契約衝突的介面變更，最終污染架構、埋下隱患。
沒有反饋，沒有澄清，沒有調查，沒有驗證
「模糊的自然語言」和「匱乏的上下文」並不是最嚴重的問題。真正危險的是缺乏人機協同的驗證閉環。當前的 AI 並不會主動反饋不確定性，也不會自行查閱知識庫。這一切依賴開發者主動設計互動流程：
- 強制澄清：有些模糊的、拿不準的地方，是選擇 A 方案還是 B 方案，不能擅自作主，必須詢問我們。
- 上下文補全：我們告知 AI 的資訊一定是不全面的，AI 必須能夠自己去指定位置進行調查。
- 自我驗證：當資訊足夠多時，它們能不能夠串聯起來，形成合理的方案呢？需要 AI 能夠去自我驗證。
過長的上下文，導致「腐化」產生幻覺
前面我們提到，上下文資訊的匱乏會導致意圖理解出現偏差。但過度冗長的資訊，反而可能造成意圖理解的錯誤。大模型的上下文容量是有限的，資訊處理能力也是有限的。隨著資訊量的增多，AI 的注意力機制開始「失焦」。早期的關鍵約束被稀釋，後期的臨時補充被過度強調。你會發現一個很明顯的問題：最早告訴他的規則，到後面卻被他「遺忘」了。同時，如果過多的上下文，大模型也會進行壓縮，必定會導致資訊的進一步失真。
控制好信噪比，我們要做的是：
- 上下文資訊的 精準 > 堆砌
- 結構化 的描述
- 聚焦的重點是什麼？
結語：實踐
我們首先就要在上下文中，定義一個基礎規範。你甚至可以把它加入你的 skill 中：
- 需求有歧義就先問，不要根據「常見做法」擅自添加用戶未要求的任務。
- 如果用戶描述存在多種理解方式，必須先詢問澄清，不要替用戶亂猜。
- 50 行能解決的問題，就別寫成 200 行。程式碼不要過度封裝、過度抽象。
- 盡量只做局部修改，不要一開始就大面積重構，不要把一個小任務改成大手術。
- 如果任務非常複雜，分步驟實施，控制上下文總量，避免出現「腐化」。
更多關於從提示詞到工程約束的典範轉變，請參閱我的文章 Vibe Coding：Harness Engineering。想了解上下文腐化如何影響 AI 程式設計會話，可以看看 我的 GSD 體驗。關於 Vibe Coding 的實用工作流，請參閱 Vibe Coding 時代的 Git Worktree。而關於規範驅動開發的實踐，請閱讀 我的 OpenSpec 體驗。