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

【書籍簡介】

AI 已經能讀程式庫、修改檔案、呼叫工具、執行測試，甚至在多輪工作中持續往前推進。真正困難的問題也跟著改變：當 AI 說「完成」，人要拿什麼重新確認？當一個變更跨過需求、設計、實作與驗收，誰負責定義邊界、誰有權接受結果，失敗後又怎麼回到可信狀態？

這本書不押注某一套工具，也不把提示詞寫成魔法公式。它從 Prompt、Context 與 Spec 開始，把需求說清楚；再用 Harness、Evidence 與 Authority 約束變更、保存證據；最後進入代理分工與有界 Loop，讓長任務能停止、接手與恢復。

書中用兩個真實專案的開發紀錄拆解判斷與證據，也保留尚未完成的關卡；另有一套可重跑的本機實驗室、完整交付包與恢復手冊。你會看到的不只是 AI 做了什麼，還包括哪些結果不能接受、證據缺在哪裡，以及人最後為什麼放行或停下。

如果已經開始用 AI 寫程式，卻不想把品質交給一句「測試通過」；如果正準備把個人技巧變成團隊流程，這本書要留下的是一套換了模型仍然能用的工程判斷。

【適合讀者】

．已經使用 AI 程式開發工具，想把「能跑」提升為「能驗、能交付」的開發者。

．想把個人用法整理成可交接流程的 Tech Lead、工程主管與產品團隊。

．需要理解 AI 如何進入需求、設計、開發、測試與交付流程的 PM、Designer 與 QA。

【推薦語】

我相信，本書能讓既有開發者與已有 Vibe Coding 經驗的讀者，重新思考自己的工作方式：AI不只是讓我們更快寫程式，也迫使我們更嚴謹地面對規格、驗證、責任與協作。這正是本書最值得閱讀的理由。（節錄）

Arm Taiwan Staff Application Engineer　葉奕成

當 AI 從回答問題進入執行工作，它說「我完成了」，你憑什麼相信它？這本書處理的正是這道工程門檻。

正美集團 數位發展部 經理　戚務漢 Caesar Chi

我一向認為：工程的重點是「能不做什麼」。一旦做了，就要將其變成一種資產。若是不分風險去把人塞進 AI 流程，加審核、加確認，看似每道工序都有人把關，其實只是把注意力消耗殆盡。把判斷寫下來變成資產，人才離得開。

企業架構師　後端里長伯

Vibe Coding 讓我們看見 AI 寫程式的強大，但系統越複雜，越需要工程底蘊。真正要補上的，是判斷與方法；這本書正是一個很好的開始。

AI 賦能教練　溫力

軟體工程師，投入軟體開發十餘年，專注 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-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 參考資料

參考資料

我寫軟體十幾年了，也有六年的團隊開發經驗。這些年，我看過不少傳統開發流程如何運作。需求、設計、開發、測試與交付各有明確分工，但每次交接都需要時間，也可能讓原本的意圖慢慢失真。

AI 開始進入開發現場後，這條路徑正在改變。PM 可以用AI 快速做出互動原型（Prototype），提早驗證市場；UI／UX 設計師完成體驗設計後，可以進一步產出前端元件，縮短設計到實作的距離；工程師則能用AI 加速開發，也讓它協助測試、審查與驗證。許多原本要在不同角色之間來回處理的工作，現在可以先由AI 產生候選，再由專業角色判斷。

在我眼前，單一職責的角色邊界正在變薄。能跨領域理解問題、往前完成一段交付，又知道何時交回專業角色的人，會變得更重要。敏捷開發強調的短迭代與快速回饋仍然重要，實現它們的方式卻已經改變；當AI 能進入每一個環節，團隊也得重新安排角色、交接與驗收。

我曾在前公司做 AI 導入開發流程，現在也持續協助團隊導入 AI 驅動開發。這些經驗讓我把注意力從「AI 能不能寫程式」移到另一個問題：當它接進整段產品交付，速度變快了，品質、責任與可驗證性能不能跟上？

我曾用鐵人賽把 AI 開發工作流一步步整理下來。把這些紀錄和我實際參與的導入經驗放在一起，我愈來愈在意的，不只是程式能不能跑，而是每一次加速有沒有留下可驗證、能回復、也有人負責的結果。這是全書的主線。

AI 寫出能跑的程式，早已不稀奇。Simon Willison 的實作指南指出一個轉折：程式開發代理不只產生一段程式碼，還會讀程式庫、呼叫工具、執行測試，再依結果繼續修正。人的工作也跟著往上移：定義問題、準備環境、限制權限，並判斷最後的結果是否值得接受。

OpenAI 與 Anthropic 公開的內部工程做法，同樣把重點放在環境、意圖與回饋。這些都是供應商對特定案例的自述，不能直接外推成每個團隊都會得到相同效果。它們仍說明了一件事：當代理能完成的步驟變多，工程問題就從「能不能生成程式碼」往「怎麼讓整段工作可信」移動。

OpenAI 公開的一項長時程模型內部部署經驗，更把這個問題說得很具體：既有的上線前評估沒有抓到部分失敗，團隊因此暫停存取，加入整段工作軌跡的監看、介入、暫停與回復能力，再恢復有限使用。這份資料談的是長時程模型安全，不是一般程式開發代理的成效；它留下的工程提醒卻很耐用：只檢查單一步驟，已不足以理解一段持續很久的行動。

我不想留下一份離開特定工具版本就失效的技巧清單。我想留下的，是一組遇到新模型時仍然能問的工程問題：它根據什麼動手？哪裡不能越界？留下什麼證據？出錯後能不能接回來？

從一段答案，到一整段工作。

早期的AI 程式開發很像問答：人提出問題，模型回傳一段程式碼，接著再由人複製、執行與修正。程式開發代理把這段流程接了起來。它可以找檔案、修改內容、跑測試、看到失敗後再試一次，也可能操作瀏覽器、建立變更請求或呼叫外部服務。

方便之處很明顯，新的風險也跟著出現。代理可能把模糊需求補成自己的產品決定；既有測試可能全數通過，卻沒有涵蓋真正的驗收條件；某一步看起來合理，連續十步後卻已偏離原目標。最後那句「完成了」只是一項回報，還不是完成的證據。

我在書裡把AI 驅動開發看成一整段可控、可驗、可恢復的工作。一次委託要先說清楚這回要做什麼，動手時要知道哪些資料可信，工作環境則負責執行規則與檢查。代理若會自行推進，還要安排人與代理怎麼分工；工作跨越多輪時，進度、停止點與回復方式也要留得下來。

全書還會反覆追問三件事：想做成什麼樣、憑什麼接受、誰有權決定。系統可控，不表示模型永不犯錯；我的要求是，越界前有地方會停，交付時有東西能重查，中斷後也找得回進度。這些部分後面都有正式名稱，Ch1 會先把一般開發流程攤開，再逐一放回同一張地圖。現在不必先背。

我希望你讀完後，手邊留下的不只是一套名詞，還有一個真的能接回工作

的環境。哪怕最先只多了一張可驗收的任務卡、一個能重跑的驗證入口，也比

收藏完整的工具清單更接近可靠。（節錄）

作者　楊騏Ci Yang