AI 驅動開發 - 從 Prompt 到 Loop，建立可控、可驗、可恢復的工程系統

楊騏（Ci Yang）

軟體工程師，投入軟體開發十餘年，專注 AI 驅動開發的落地：把 AI 導入企業開發流程，並把個人用法變成團隊能接手的流程。

以《AI-Driven Development 實戰篇》獲 2025 iThome 鐵人賽「佛心分享」佳作。曾於 HWDC、JSDC、DevOpsDays Taipei、Agentic Automation Day 與 COSCUP 分享 AI 流程導入與 SDD 自動化開發的實戰經驗。

長期以真實專案、版本紀錄與驗證結果，整理 Prompt、Context、Spec、Harness、Evidence、Agentic 與 Loop 的開發流程。相信真正稀缺的不是讓 AI 多寫一點，而是知道怎麼定義工作、驗收結果，並承擔最後的決定。

第1章 AI 驅動開發全景：三面、一軸、一環
1-1 開始之前：一個功能怎麼走到交付 
1-2 從「做完」追到「可以交付」 
1-3 全書會反覆問的三件事 
1-4 第一面：Prompt，把當下任務寫成合約 
1-5 第二面：Context，只載入此刻需要的真相 
1-6 第三面：Harness，讓約束和證據真的發生 
1-7 一軸：Agentic，安排分工而不是堆代理 
1-8 一環：Loop，讓長任務可停、可接、可退 
1-9 一個最小閉環 
1-10 看懂一次最小閉環 
1-11 先搭一條能重查的工作路徑 
1-12 風險不同，控制強度也跟著變 
1-13 何時不要用完整控制模型 
1-14 先做一張自己的系統盤點 
1-15 這張全景圖能說到哪裡 
第2章 Prompt Engineering：把需求變成可測的任務合約
2-1 先把成功寫清楚 
2-2 任務合約的八欄 
2-3 從模糊需求到可測合約 
2-4 把範例當成介面測試 
2-5 把可核對的中間物留下 
2-6 資料與指令分開，安全邊界還在後面 
2-7 讓輸出接得上下一道關卡 
2-8 看懂任務合約怎麼被驗收 
2-9 先留下一張可重用任務卡 
2-10 當任務卡開始跨人流動 
2-11 完整任務合約有它的使用邊界 
2-12 把第一張真實任務卡留下來 
2-13 任務卡能做到什麼 
第3章 Context Engineering：只給此刻需要的真相
3-1 把 Context 當成工作記憶 
3-2 模型升級後，Context 應該放在哪裡 
3-3 先分清五種Context 
3-4 三層漸進揭露 
3-5 「最新檔案」不一定是唯一事實來源 
3-6 RAG 只是取得Context 的一種手段 
3-7 壓縮與摘要都是有損轉換 
3-8 Context 污染：錯的資料比沒有更危險 
3-9 用量測決定Context 要放多少 
3-10 不靠聊天紀錄，也能讓下一個工作階段接手 
3-11 先畫一張最小Context 地圖 
3-12 Context 開始跨人流動時 
3-13 Context Engineering 也要節制 
3-14 留下一份可恢復的Context 套件 
3-15 Context 的邊界在選擇 
第4 章 第一次可信任變更：改動小、可重現、可回復
4-1 可信任，指的是另一位工程師能重建判斷 
4-2 檢視：先看現況，不急著改 
4-3 計畫：先縮小意圖，再決定檔案 
4-4 編輯：讓變更差異只承擔一個意圖 
4-5 執行：確認程式真的接得起來 
4-6 測試：先對準要求，再看整體回歸 
4-7 審查：確認這次真的測對了 
4-8 提交：釘住可回復狀態 
4-9 從最近一次小改動開始 
4-10 把七步壓成一條能回去的路 
4-11 當這條路不再只屬於一個人 
4-12 七步可以依風險縮短 
4-13 可信來自一條能回去的路 
第5章 Spec：把意圖外化成可演進的合約
5-1 Spec 比一張任務卡活得更久 
5-2 Spec 強度跟風險走 
5-3 既有系統先寫現況，再寫願望 
5-4 用可觀察結果寫驗收 
5-5 機器可讀只能覆蓋部分語意 
5-6 未決問題不能讓模型自行結案 
5-7 向前串接：從意圖一路連到Evidence 
5-8 證據回流：證據推翻想像時，回寫Spec 
5-9 工具可以替換，產出物要留下 
5-10 先替既有功能留一份可演進規格 
5-11 讓Spec 與實作一路對得回去 
5-12 當Spec 進入團隊 
5-13 有些改動只需要一張任務卡 
5-14 Spec 留住的是決定 
第6章 Harness Engineering：把重複失敗寫回環境
6-1 Harness 讓文字規則真的發生 
6-2 Feedforward 與Feedback 要成對 
6-3 最小可行Harness 
6-4 從失敗升級成護欄 
6-5 Harness 合約：先定環境，再交工作 
6-6 Authority：把能力拆成不同動詞 
6-7 狀態、Evidence 與恢復 
6-8 代理Harness 與Eval Harness 各有責任 
6-9 Harness 也會腐化 
6-10 從一個重複錯誤補第一道護欄 
6-11 用一次拒絕看懂Harness 
6-12 當Harness 不再只屬於一個人 
6-13 何時不要增加Harness 
6-14 Harness 要薄到有人維護 
第7章 Evidence、Eval 與 Observability：讓完成可被證明
7-1 先看一個假想失敗：測試綠了，功能還是錯的 
7-2 Evidence 必須能被重新檢查 
7-3 先寫Evidence 合約，再讓代理動手 
7-4 Eval 到底在評什麼 
7-5 評分器也需要被驗證 
7-6 Eval 環境也是結果的一部分 
7-7 Observability：只留下能幫助判斷的訊號 
7-8 分清通過、失敗與根本沒執行 
7-9 當Evidence 要跨人重查 
7-10 不是每個任務都需要完整評測系統 
7-11 真正要留下的是判定起點 
7-12 證據只能回答它驗過的事 
第8章 Agentic Engineering：從下指令到專業委派
8-1 先看一個假想失敗：六個代理，一個盲點 
8-2 Agentic 的核心：把路徑選擇權交出去 
8-3 單代理就是預設選項 
8-4 拓樸要跟著任務選 
8-5 委派合約：委派前先寫清楚 
8-6 代理團隊的新失敗面 
8-7 審查量能才是真正上限 
8-8 第一次分工，只練「做」與「驗」 
8-9 當代理分工進入團隊 
8-10 代理與多代理都有使用邊界 
8-11 一次真的會退件的委派 
8-12 六種委派失敗，先分型再處理 
8-13 委派失敗後，怎麼交回一個人接手 
8-14 多一個代理，也多一份責任 
第9章 Loop Engineering：讓工作持續，也知道何時停
9-1 先看一個假想失敗：每輪都更接近錯答案 
9-2 Loop 要有明確狀態 
9-3 跨輪狀態只保存可核對事實 
9-4 把全新Context 當成可測選項 
9-5 預算：Loop 的燃料表 
9-6 無進展偵測器：抓出看似忙碌的迴圈 
9-7 檢查點、續跑與回復是同一組設計 
9-8 驗證器必須有權讓Loop 停下 
9-9 METR「慢19%」為何不能脫離2025 年初工具 
9-10 審查量能：Loop 的外部斷路器 
9-11 第一次只驗三輪 
9-12 長任務進入團隊之後 
9-13 Loop 有它的使用邊界 
9-14 合約先回答六個問題 
9-15 看一次正常停止與正常升級 
9-16 六個常見卡點，別用重試混在一起 
9-17 重設、回復、續跑不要互相代替 
9-18 能停下來，Loop 才值得開始 
第10章 把AI 串成一條產品交付線
10-1 先拿一個需求切片走完全程 
10-2 一次真實交接，讓問題提早浮上來 
10-3 七份交接物就夠開始 
10-4 當這條交付線進入團隊 
10-5 這條交付線也有使用邊界 
第11章 滴水金：讓一個Story 穿過 SDD、Harness 與Loop
11-1 先看懂滴水金在做什麼 
11-2 開發開始前，先固定AI 無權更改的事
11-3 跟著US-002 走一次 
11-4 SDD 的產出物，是下一個人的工作介面 
11-5 Harness 讓每個新工作階段找得回現場 
11-6 Loop 一次只推一個可驗證的決定 
11-7 第一個全綠，其實少跑了23 項測試 
11-8 驗收者有權說：功能能用，仍然沒有符合Spec 
11-9 遇到產品判斷，Loop 要會把問題交回來 
11-10 早期Loop 也暴露了自己的限制 
11-11 團隊還要補上哪些控制 
11-12 何時不要用Loop 
11-13 案例的證據停在哪裡 
第12章 Gloaming：當Loop 沒有啟動，方法如何接手
12-1 先看產品，再看那一層看不見的地基 
12-2 先把一個產品切成這次能完成的範圍 
12-3 從七條需求走到二十項工作 
12-4 一條需求如何一路長成Evidence 
12-5 Harness 先問能不能動，再問要怎麼動 
12-6 Loop 的前置檢查為什麼要拒絕這次任務 
12-7 手動接手，仍然沿用同一份開發合約 
12-8 Context 只跟著當前決定進來 
12-9 實作回饋規格：連線不該在匯入時偷讀機密值 
12-10 驗證器也會犯錯 
12-11 Evidence 應該跟主張一起縮小 
12-12 個人專案也需要Authority 
12-13 Loop 在這個案例裡的邊界 
第13章 從個人Harness 到團隊AI 治理
13-1 先看一個假想失敗：沒有人違規，資料還是出去了 
13-2 Authority：不只管能不能寫檔 
13-3 借NIST 當治理地圖 
13-4 Prompt 注入和過度代理權限是兩個問題 
13-5 風險分級：把自治拆成多個維度 
13-6 治理決策要把速度和代價放在一起 
13-7 先把正在運行的工作流程列出來 
13-8 機密資訊與資料邊界 
13-9 核准：讓人看到真正要決定的東西 
13-10 分階段上線、緊急停止與事故 
13-11 個人開發者先做最小治理 
13-12 退場要清掉整條作用路徑 
13-13 完整治理流程有它的使用邊界 
13-14 章程先記六個決定 
13-15 把治理讀成一次可逆決定 
13-16 七種「看起來有治理」的失敗模式 
13-17 從個人環境交給團隊前，先讓別人接得住 
13-18 責任不能被工具吞掉 
第14章 讓另一個人接得住：知識、狀態與 Evidence 的工作記憶
14-1 先做一次不靠聊天紀錄的接手 
14-2 四種工作記憶不能混成一疊 
14-3 先固定這次交的是哪一版 
14-4 一次真實事故：知識版本與活動狀態被一起同步 
14-5 兩座第二大腦教我的新鮮度 
14-6 接手不是閱讀，而是重新取得判定能力 
14-7 個人先從一個可中斷任務開始 
14-8 當工作記憶開始跨人與跨程式庫 
14-9 第二大腦也有使用邊界 
14-10 章末產出：一份版本化接手包 
14-11 把完成延伸到下一個人 
第15章 結語
15-1 把判斷留在自己手上 
15-2 最後看一個假想失敗：能合併，沒人敢接 
15-3 現有研究能說到哪裡 
15-4 理解在於能解釋、預測與接手 
15-5 四個理解護欄 
15-6 接下來30 天，先把一個小任務做完整 
15-7 讓30 天計畫可以中斷，也可以回來 
15-8 真正練習時，只留下差距 
15-9 30 天的畢業作業：交給一個不知道過程的人 
15-10 團隊如何保護理解 
15-11 什麼時候應該刻意不用AI
15-12 最後留下什麼 
15-13 把理解留在自己手上 
後記
致謝
附錄A 從乾淨環境啟動ai-dev-lab
A.1 先定義完成畫面 
A.2 執行前檢查：確認工具與工作位置 
A.3 複製練習環境，建立自己的基準 
A.4 建立虛擬環境並安裝開發依賴 
A.5 跑第一條可信基準 
A.6 跑通 Task Board 的正常路徑 
A.7 把章節概念對回產出物 
A.8 產生兩份不可覆寫的Evidence 
A.9 失敗演練1：看守門機制真正拒絕 
A.10 失敗演練 2：讓Loop 正常完成，也正常升級 
A.11 重設、指定範圍還原與換全新副本重新開始 
A.12 常見問題對照表 
A.13 完成檢查清單 
A.14 來源、快照與不可越界 
附錄B 把全書產出物移植到自己的程式庫
B.1 先決定要移植到哪一層 
B.2 在動任何檔案前，先留基準 
B.3 建立目錄，但不要先抄內容 
B.4 AGENTS.md：先做一張程式庫地圖 
B.5 任務合約：把這一次改動關起來 
B.6 Spec：固定行為，不固定實作答案 
B.7 Context 清單：少載一點，但知道少了什麼 
B.8 交接：讓下一個人從產出物接手 
B.9 Authority：把能力縮到任務需要的尺寸 
B.10 verify.sh：只保留一個標準入口 
B.11 Evidence：保存「跑了什麼」，不是保存一句成功 
B.12 Loop 合約：先證明單次執行，再考慮重跑 
B.13 從ai-dev-lab 改名，保留語意，不保留殼 
B.14 導入順序：一週只收一種新承諾 
B.15 完成清單：最小AI 開發環境 
附錄C 故障診斷與恢復操作手冊
C.1 先記住：紅字不是分類 
C.2 前15 分鐘：先保住現場 
C.3 五類分流診斷 
C.4 決策表：同一個結束碼，不同處置 
C.5 故障演練1：受Git 追蹤的非乾淨基準 
C.6 故障演練2：未受Git 追蹤檔案擋住Evidence 
C.7 故障演練3：缺少開發工具 
C.8 故障演練4：pytest 驗收失敗 
C.9 故障演練5：守門機制拒絕未授權動作 
C.10 故障演練6：重複的RUN_ID 
C.11 故障演練7：執行期JSON 損壞 
C.12 故障演練8：Spec 衝突，但測試仍綠 
C.13 故障演練 9：檢查者嘗試寫受Git 追蹤檔案 
C.14 故障演練10：Evidence 清單不完整或損壞 
C.15 故障演練11：Loop 同一失敗升級 
C.16 故障演練12：工作階段中斷 
C.17 故障演練13：Loop 狀態損壞或互相衝突 
C.18 故障演練14：指定範圍回復 
C.19 事故紀錄模板 
C.20 中斷交接模板 
C.21 完成驗收 
附錄D 一份完整填好的AI 變更交付包
D.1 適用讀者與先備 
D.2 案例邊界：這份交付到底交什麼 
D.3 交付包封面 
D.4 需求與驗收：先把兩種AC 分開 
D.5 Context：這次真的載入了什麼 
D.6 Authority：可以做什麼，不能做什麼 
D.7 計畫與觸碰面 
D.8 實作摘要：最後交付的行為 
D.9 Evidence manifest：填好的交付快照 
D.10 獨立檢查者判定 
D.11 Traceability matrix：從要求一路追到決定 
D.12 交接：下一位接手者現在知道什麼 
D.13 Recovery：這份成功交付要怎麼回去 
D.14 如何縮成低風險版 
D.15 如何升成團隊版 
D.16 常見誤讀 
D.17 附錄末可帶走的產物 
附錄E 讀者版術語與問題回查表
E.1 三個跨章控制詞
E.2 角色與判定
E.3 狀態詞不要互相冒充
E.4 理解債與四種理解護欄
E.5 本書刻意不用的說法
附錄F 參考資料
參考資料