Goal Engineering: 如何用 Goal+Rider 駕馭 AI 自動化寫 Code

原始來源與檔名：2026-05-21T093209+0800-Goal Engineering.md

NAPKIN | 餐巾紙

餐巾紙公式

Agent Work Round = Goal (Spine, ≤4000 chars) + Rider (Detail, Unbounded, 11 Phases) + Architecture Closure

公式說明：單純的 Prompt 無法應付長時間的自動化 Agent 執行。一回合 (Round) 的工作應該由兩份納入版控的文件組成：精簡的 Goal 定義大方向與邊界，無限長的 Rider 定義具體的 11 個實作階段與測試。結束時更新架構文件。

一句話

不要把 Agent 當成聊天機器人，把它當作一個需要嚴格 PR 審核的開發者。透過撰寫 Goal+Rider 文件，你在 Agent 寫下第一行 Code 之前，就已經定義好驗收標準 (Tests) 與絕對不能碰的底線 (Posture)，這能將 AI 的除錯成本降到零。

餐巾紙草圖

[ The Goal Engineering Loop ]
1. Trigger: One-sentence idea.
2. Skill Pre-work: Agent reads Architecture & prior Riders.
3. Draft Pair: Generates `goal.md` (≤4000 chars) & `rider.md` (11 phases).
4. Commit: `git add docs/goals/...`
5. Execution: Agent executes P1 to P11 (Write Test -> Fail -> Implement -> Green -> Commit).
6. Closure: Update AS-BUILT-ARCHITECTURE.md.

ROUND 1: SKELETON | 骨架掃描

「這篇文章在說什麼」

核心問題: 當開發者使用 Cursor 或 Claude Code 時，起初進展飛速，但隨著專案變大，Prompt 開始失控，Agent 開始偏離方向或破壞原有架構。
核心答案: 提出 “Goal Engineering” 框架。放棄單次對話 (Turn) 的 Prompt，改以回合 (Round) 為單位。每回合產出一組包含在 Git 中的 Markdown 文件 (goal.md 和 rider.md)，強制 Agent 遵循測試驅動開發 (TDD) 與明確的架構邊界。
論證結構: 介紹工作流概觀 -> 比較 Prompt/Context/Compound/Goal Engineering 的差異 -> 深入解剖 Goal (限制與 Posture) -> 深入解剖 Rider (11 個階段與深度測試) -> 以 deadreckon 和 findunmet 兩個真實專案為例 -> 釋出自動產生 Goal+Rider 的 Claude Skill 腳本。

章節骨架

引言與流程圖: 一個 Trigger，兩個檔案，11 個階段，一次架構更新。
Prompt 的侷限: Prompt 無法被 Git 追蹤，無法 Code Review，也無法設定「不該做什麼 (Out-of-scope)」。
The Goal: 強制 4,000 字元上限。必須包含：Read first, Posture (防禦性邊界), Headline word (驗收標準)。
The Rider: 無字數限制。定義資料模型、11 個開發階段 (Phases)。強制要求「先寫深度測試 (Depth Tests)，再寫實作」。
V1-CANDIDATES.md: 溢流閥。在開發中發現但不屬於本次回合的工作，強制寫入此檔案，防止 Agent 自作主張擴張範圍。
實戰範例 (Coherence & Liveness): 展示如何透過 Rider 鎖定 UI 的位元組級細節，以及如何制定穩健的錯誤重試架構。
Skill 實作: 提供可直接複製使用的 goal-rider-author 技能腳本。

ROUND 2: DISSECTION | 血肉解剖

「憑什麼這麼說」

論證鏈

長時間運行的 Agent 會在遇到壓力時「發明」解決方案 (例如隨意修改資料庫 Schema) --> 傳統的 Prompt 缺乏對邊界 (Posture) 的約束力 --> 解決方法是將需求實體化為版本控制的 Goal+Rider 文件 --> 強制 Agent 在每回合 (Round) 中嚴格執行 11 個階段 (TDD: 寫測試->實作->綠燈->Commit) --> 讓 Agent 的產出具有可預測性、可驗證性，並持續累積為專案的知識基底。

關鍵證據

Posture (姿態/邊界): Goal 中最重要的一環是定義「不做什麼」。例如：No schema changes. No new deps. No rebuild. 這是防止 Agent 產生幻覺 (Hallucination) 並擅自更改架構的最強防線。
Depth Tests (深度測試): Rider 要求 Agent 在實作前，先寫出如 stallguard_kills_after_no_output_growth 這樣極度具體行為的測試。只有在測試寫出並確認 Fail 後，才允許實作。這是嚴格的 TDD (測試驅動開發) 實踐。
Files, not fields (檔案優於欄位): 為了確保狀態在崩潰後依然存活，作者要求 Agent 將狀態寫入實體檔案 (如 /tmp/run/stage.current)，而非記憶體中的 struct field。這顯示了作者對於系統韌性 (Liveness) 的深刻理解。

隱形假設與邊界

隱形假設:
- 專案本身已經具備完善的 CI/CD 或本地編譯/測試命令 (如 cargo test, go test)，否則 Agent 綠燈 (Green) 的驗收循環無法閉環。
- 使用者了解並願意採用這套極度嚴格、甚至略顯繁瑣的儀式感 (Ritual)。
邊界條件:
- 作者坦承這套方法適用於「一個功能，2 到 5 個檔案，需要半天到一天 Agent 執行時間」的中大型任務。對於只需 15 分鐘的 CSS 微調，使用 Goal Engineering 是牛刀殺雞。

ROUND 3: SOUL | 靈魂提取

「還能怎麼用」

知識連接: 本文提到的 V1-CANDIDATES.md 溢流閥，完美呼應了軟體工程中的「技術債管理」與上一篇提到的「不要讓模型處理跳脫字元 (降低認知負載)」。Goal+Rider 就是作者為 Agent 設計的 ACI (Agent-Computer Interface)。
行動觸發: 在開始下一個中型功能開發前，不要直接對 Cursor 說 “幫我做 XXX”。先建立一個 docs/goals/ 資料夾，寫下你的 Headline word 與 Posture，明確告訴 AI 什麼「絕對不能碰」。

從 Prompt 到規格化工程 (Architectural Deep Dive)

前言

這篇文章是目前關於 Agentic Coding (智能體寫程式) 領域中，最具工程深度的實戰指南。它標誌著人類使用 AI 的方式，從「對話式的祈使句 (Conversational Imperative)」正式邁入「宣告式的狀態機合約 (Declarative State-Machine Contracts)」。

核心架構洞察

1. 消除 Agent 的發明權 (Constraining Agent Invention)

Agent 的天性是為了完成目標而不擇手段 (Reward Hacking)。如果你叫它修復一個 UI 狀態，它可能會順手幫你把資料庫 Schema 給改了。

防禦性編程 (Defensive Programming) 在這裡被提升到了 防禦性 Prompting。
Posture 區段的本質，就是在設定 Agent 搜索空間 (Search Space) 的剪枝規則 (Pruning Rules)。明確宣告 No DB schema changes，等於在路徑規劃的演算法中封鎖了那條分支。

2. 測試驅動的 AI 迴圈 (Test-Driven AI Loop)

作者在 Rider 中強制的 11 個 Phases，是將軟體工程的最佳實踐 (TDD) 強加於 AI。

Write Test -> Watch Fail -> Implement -> Green -> Commit
這解決了 LLM 常見的「自圓其說」問題。如果讓 LLM 先寫 Code 再寫 Test，它會寫出剛好能通過該 Code 的廢物測試。強制先寫出 Failing Test，是利用編譯器 (Compiler) 這種決定性 (Deterministic) 系統，來牽制 LLM 的非決定性 (Non-deterministic) 產出。

3. 可延續的認知基底 (Compound Cognitive Substrate)

Prompt Engineering 的單位是 Turn (單次對話)，結束即消失。
Goal Engineering 的單位是 Round (回合)，產出的 goal.md 和更新的 AS-BUILT-ARCHITECTURE.md 會成為 Git 歷史的一部分。
當下一個回合開始時，Agent 讀取的是上一回合留下來的精煉知識。這就是為什麼作者說這套系統是「累積承諾 (Compounds promises)」。這完美解決了長專案中 Context Window 被雜亂對話塞滿導致的「失憶症」。

總結

真正的 Senior Developer 不在於寫 Code 的速度，而在於控制系統複雜度的能力。Goal Engineering 是一套讓 AI 乖乖遵守軟體工程紀律的韁繩。未來，開發者的核心價值不再是打字，而是撰寫精準無誤的 Goal 與 Rider。