81天的 AI Agent 軟體開發團隊治理實務分享

Transcript

1. AI 驅動的軟體開發 從 Prompt、Context、Harness 到 Loop 的工程化實踐 81 天的真實歷程｜2026/11/9
2. 81 天，從一個服務長成一個平台 81 15,651 46 14 天 次提交 份平台 ADR 個代理角色 2026/8/17 ～ 11/5 12 個版控庫 PADR-001 ～ 046 由一位協調者調度 一位委託人＋一位協調者，帶著 14 個代理角色，從一個身分驗證服務起步，長成擁有 11 個子專案版控庫的平 台。 URL Shorten Service：一天內從 RFP 走到九份細部設計 AI 驅動的軟體開發 Lite Portal：開庫三天就有可運作的實作 2
3. 速度不是重點：錯誤也會一樣快 「AI 讓寫程式變快」 「AI 讓錯誤也變快」 最容易被看見，也最容易誤導人的指標 錯誤、漏接、規則衝突，用同樣的速度產生 8,386 次 角色收工，每一次都要通過完成檢核才會自動簽入；沒有這道機制，速度只會變成更快的混亂。 AI 驅動的軟體開發 3
4. 今天的主軸 AI 寫程式不難， 難的是讓一群 AI Agent在規則與回饋迴圈中穩定地交付。 AI 驅動的軟體開發 今天分享的是 先誠實交代 建立「生產系統」的經驗，而不是產品已經成 功上市的故事 截至 11/5，子專案都尚未合併到主幹，也還沒 有正式的 demo 驗收紀錄 4
5. 今日路線：九個主題 1 AI 與軟體開發流程 6 開發過程中的管理 2 Prompt→Context→Harness→Loop 7 多專案治理與平台化 3 AI Agent 與調度 8 PDCA 的運用 4 AI SDLC 與 SDD 9 未來發展方向 5 構建 AI 開發團隊 ★ 結語與 Q&A AI 驅動的軟體開發 5
6. 第一部 AI 與軟體開發流程 AI 沒有讓流程消失，它讓瓶頸換了位置 6
7. 三個階梯：人從流程中間，退到流程兩端 第三階 代理 第二階 協作 第一階 輔助 在編輯器裡補完一行、一個函式 在對話中幫你寫、幫你解釋 自己讀檔、跑測試、修正，最後自 己提交 人的位置 退到兩端：定義與判斷 人的位置 在每一步的中間 人的位置 在每一步的中間 AI 驅動的軟體開發 7
8. 三個速度樣本 隔天 1天 3天 Auth service URL Shorten service Lite Portal 開工隔天，以測試驅動交出第一批 後端、前台與資料庫遷移實作 一天內完成需求分析、PRD、高階 設計、10 份 ADR、架構規格、測 試計畫與 9 份細部設計 11/3 開庫，隔天完成需求到測試 計畫，第三天打下三個元件的第一 個版號 產出的成本趨近於零之後呢？請看另一面。 AI 驅動的軟體開發 8
9. 瓶頸轉移：產出變便宜，四件事變貴 AI 驅動的軟體開發 1 需求是否講清楚 2 驗證是否可靠 代理會忠實執行含糊的需求，然後很快交出 一個錯的東西 提交訊息不合伺服器端檢核，事後改寫 199 筆；十月再改寫 38 筆 3 環境是否健康 4 誰來做決定 測試變慢，對照實測查出是防毒驅動所致； 解除後延遲回到 6～9 ms 授權條款能否接受、合規要做多深，不是代 理能自己決定的事 9
10. AI 對開發流程的四個結構性改變 回合變短 文件變成介面 驗證必須機具化 人的角色上移 交辦到交付，從以天計變 成以分鐘計；回饋迴圈必 須跟著變短 文件不只給人看，它是代 理之間交接的唯一媒介 人工看不完，檢核必須由 hook、閘門、腳本自動 執行 從執行者變成定義者、裁 決者與規則維護者 這四個改變，就是後面八個主題要回答的問題 AI 驅動的軟體開發 10
11. 第二部 由 Prompt、Context、Harness 到 Loop Engineering Prompt 決定怎麼問，Context 決定給什麼看，Harness 決定能做什麼、在 哪裡做，Loop 決定做完之後怎麼被驗證與修正 11
12. 四個階段不是取代，而是一層包住一層 LOOP ENGINEERING 做完之後怎麼被驗證、回饋與修正 HARNESS ENGINEERING Prompt 讓代理聽懂 解決意圖誤解、輸出格式不穩 代理能做什麼、在什麼環境裡做 CONTEXT ENGINEERING 給什麼看、看多少、靠什麼記得 Context 讓代理看對 解決不共享記憶、上下文膨脹 PROMPT ENGINEERING 怎麼問 Harness 讓代理做得到也做得安全 設計單位：單次輸入 設計單位：上下文視窗＋外部記憶（檔案） 設計單位：執行環境＋工具＋權限＋掛點 解決權限失控、同樣的錯一再重犯 Loop 讓代理做錯時被抓到 解決規模化後的可靠性 設計單位：回饋迴圈（閘門、檢核、量測、規則修訂） AI 驅動的軟體開發 12
13. 四階段對照：各自要解決什麼問題 階段 核心問題 預期解決的問題 典型手法 停在這一階的極限 Prompt 怎麼問 意圖誤解、輸出格式不穩、角 色不明 角色設定、範例、格式指定、逐 步推理 一次性；無法跨回合累積 Context 給什麼看、看多少、靠 什麼記得 代理不共享記憶、上下文膨脹 、token 成本 檔案交接、拆檔、正文歷程分離 、長度預算、用量量測 看對了，但能做什麼沒有 約束 Harness 能做什麼、在什麼環境 裡做 工具與權限失控、環境不一致 、同樣的錯一再重犯 權限逐筆核可、獨立節點、hook 掛點、腳本化、模型分級 能做也受約束，但做完沒 人驗證 Loop 做完之後怎麼驗證與修 正 規模化後的可靠性、無人值守 時的品質 完成檢核、合併前閘門、變異注 入、重評條件 迴圈本身也會壞，需被監 測 四者不是取代，而是疊加：停在任何一階，規模一大就會失控 AI 驅動的軟體開發 13
14. Prompt：從手寫的一段話，變成制度化的範本 完成回報固定四區塊 STATUS 狀態 DELIVERABLES 交付物 INPUTS 輸入 VERIFIED 已驗證 0 10 月中在派工單加入固定格式句後，「 輸入不完整」與「交接不清」兩類退件歸 零——沒有改任何 hook 讓協調者可以機械式地檢查每一次交付 Prompt 的價值沒有消失，但必須寫成範本、放進流程，才會穩定生效。 AI 驅動的軟體開發 14
15. Context：代理不共享記憶，交接一律靠檔案 先天限制：上下文有上限、子代理不共享記憶 → 交接一律靠檔案，派工自帶完整上下文 08-31 09 月 10-07 11-02 實測 1,095 行超過 1,500 字元 ，最長一行 33,322 字元 一個識別字一個檔；訂出平台 文件形態預算 正文與歷程分離；規範檔移出 版次紀錄 token 用量彙整、登記簿分卷 、狀態一律落檔 誠實的讀數：10/7 觀察到 token 消耗持續上升，單純降低讀取量效果不顯著 → 11 月改為「先量測，用讀 數取代印象」 AI 驅動的軟體開發 15
16. Harness：代理能做什麼、在什麼環境裡做 Agent ＝ Model ＋ Harness Harness：包在模型外面的工具、權限、執行環境、掛點與狀態；同一個模型，換一套 harness，表現可以差很多 工具與權限 執行環境 掛點（hook） 腳本化 角色與會談 權限逐筆核可、定期 檢視；規範層逐字授 權寫入 PowerShell 7 統一、 暫存集中、子專案分 散到獨立節點 完成檢核、提交訊息 檢核、伺服器端 hook ：迴圈掛在這裡 三步以上須成腳本： 從「靠代理記得」到 「靠機具執行」 14 個角色、模型分級 、同庫只容一個協調 者 骨架產生器把整套 harness 打包：新子專案一開庫就全部接上，harness 本身成為平台的產品 AI 驅動的軟體開發 16
17. Harness 不是裝好就沒事 「代理每犯一次錯，就改 harness，讓它 不再犯同一個錯」 環境也是 harness Mitchell Hashimoto 的說法；與案例專案「每一次事故 都要變成一條規則」是同一個精神 工具換版，迴圈會斷 九月底測試變慢，查出是防毒驅動；解除後延遲 回到 6～9 ms 開發工具一次更新，退件訊息就送不到（下一階 詳述） Context Harness Loop 代理「看到什麼」 代理「能做什麼、在哪裡做」 「做完之後怎麼被檢查與修正」 AI 驅動的軟體開發 17
18. 為什麼我們沒有用 MCP 與 Skill 原則不變：每個機制都要說得出驅動來源——熱門技術也一樣 MCP（Model Context Protocol） Skill（SKILL.md） 是什麼 是什麼 開放標準：代理透過 MCP server 連接外部工具與資料 說明與腳本的資料夾；平時只有描述常駐，相關時才載入 我們的作法 我們的作法 GitLab、PowerShell 等整合以命令列與腳本完成 規範層的規則檔承載規範；作業卡與腳本承載作法 沒採用的原因 沒採用的原因 沒有驅動來源：沒量到需要 MCP 才能解決的失效 規範層已涵蓋；由模型決定是否載入；沒有驅動來源 立場：目前不用，保留重評——量到現有機制解決不了、而它們能解決的失效時，再重新評估 AI 驅動的軟體開發 18
19. Loop：錯誤是當場被抓到，還是三天後被發現 內迴圈（任務層）：做 → 驗 → 修 每個角色收工都要通過完成檢核 hook，通過才自動簽入：「已簽入」＝「已 驗證」 中迴圈（交付層） commit-msg 檢核、合併前閘門、pre-receive、gitleaks、SAST；推送前全 套由小模型背景執行 8,386 次自動簽入 每一次都先通過完成檢核 外迴圈（治理層） 規則本身的提出、驗證、修訂與撤回——第八部的 PDCA AI 驅動的軟體開發 19
20. 迴圈本身也會壞，所以迴圈也要被監測 09-30 暫行措施 10-01 開發工具更新，退件訊息無法送 達角色與協調者：迴圈斷了，表 面照常 委託人裁定以 checkpoint 與日 誌做暫行驗收 定出「交回前檢核」平台規則， 迴圈補回 守衛宣告有效前，先做變異注入 故意種一個錯，確認它真的會變紅，並用 diff 證明變異確實落檔。 「擋下 0 次」可能代表品質很好，也可能只是根本沒掃到。 AI 驅動的軟體開發 20
21. 四句話收束第二部 Prompt Context Harness Loop 讓代理聽懂 讓代理看對 讓代理做得到也做 得安全 讓代理做錯時被抓 到 沒有它，代理聽不懂 沒有它，代理看錯東西 沒有它，代理做不到或做 過頭 沒有它，前三者再好，規 模一大就失控 一層包住一層：Prompt ⊂ Context ⊂ Harness ⊂ Loop AI 驅動的軟體開發 21
22. 第三部 AI Agent 與調度 (Orchestration) 多代理的難處不在單一代理多聰明，而在誰做、怎麼交接、怎麼並行、用哪 個模型 22
23. AI Agent ＝ 模型＋工具＋迴圈＋目標 + + + 模型 工具 迴圈 目標 理解與推理 讀寫檔、執行指令、呼叫 API 自己判斷下一步 朝目標前進，直到完成 一個Agent很好管理；十幾個Agent同時在動，就需要調度與編排（Orchestration） AI 驅動的軟體開發 23
24. 調度架構：協調者只調度，交接只靠檔案 委託人（人） 方向裁示｜豁免權｜規範層維護 RFP、方向裁示 個案紀錄上呈裁決 協調者 (Orchestrator) 拆任務、派工、收回報、判斷退件；不代寫 派工單（自帶完整上下文） 完成回報四區塊 14 個代理角色｜每次派工選定模型等級 需求與設計 PRD、ADR、細部設計 實作與測試 測試驅動、自主提交 推送前全套 小模型 Haiku 背景執行 版控中的檔案 機具：只照規則擋 需求書、設計、追蹤紀錄、完成回報；代理不共享記憶 完成檢核 hook、commit-msg、pre-receive、gitleaks、SAST AI 驅動的軟體開發 24
25. 原則一與二：協調者不代寫；交接只靠檔案 原則一：協調者只調度，不代寫 做什麼：拆任務、派工、收回報、判斷退件 原則二：交接只靠檔案 子代理不共享記憶，一切經由版控中的需求書、設計 文件、追蹤紀錄、完成回報交接 為什麼不代寫：一旦下場寫，上下文被細節塞滿、失 去全局判斷；交付物也跳過完成檢核，等於繞過迴圈 AI 驅動的軟體開發 狀態 輸入 交付物 已驗證 25
26. 原則三：並行要有互斥 1 2 檔案層 10-08 多會談並行事故 同一個檔案同一時間只派給一個角色 角色實例層 回復時把另一個會談進行中的搬移誤當成半成品暫 存，內容遺失 同名角色不同時開兩個實例 之後的規則 3 提交層 只提交自己改的檔案，不帶走別人的半成品 • 開工前先查同庫有無其他會談 • 同一個庫只容一個協調者 • 閘門執行期間，同機其他會談停派建置與測試 九月起，有命令列權限的角色須自行以 Conventional Commits 格式提 交 AI 驅動的軟體開發 26
27. 原則四：模型要分級 大模型 依任務選級 需求、設計、資安等重推理任務 10-08 推送前全套檢查交給 Haiku 在背景執行 10-12 每次派工都要明確選定模型等級 實作與測試 效果：省成本，也縮短等待 小模型 推送前固定全套（Haiku 背景執行） 調度的本質：把人與人之間的協作規範，翻譯成代理讀得懂、機具擋得住的規則 AI 驅動的軟體開發 28
28. 第四部 AI SDLC 概念 不是跳過階段，而是把每個階段壓縮、文件化，並給它一個機器可檢查的完 成定義 29
29. 文件變多了，因為文件就是代理之間的介面 91 常見誤解 「有了 AI，就不需要設計文件了」 份 ADR 實際上：文件變多了，而且多很多 Auth 一個子專案累積的架構決策紀錄 在 AI SDLC 裡，文件就是代理的輸入，也是代理之間的介面。 一份模糊的設計，對人是溝通成本；對代理是錯誤的放大器。 AI 驅動的軟體開發 30
30. AI SDLC：每個階段都有機器可檢查的完成判準 設計 3 委託人提出，代理分析 代理撰寫，委託人裁示 代理 代理（測試驅動） 完成判準 完成判準 完成判準 完成判準 需求可追溯到 PRD 條目 每個決策有 ADR，每個元件 有細部設計 每個威脅都有對應的測試 完成檢核通過才自動簽入 1 5 需求 驗證 2 6 發行 7 測試規劃 部署與維運 4 8 實作 驗收 機具 代理 平台 委託人 完成判準 完成判準 完成判準 完成判準 閘門只判可歸因的新增發現 版號 tag 跨庫全域唯一 部署後可回讀 /version 委託人簽核（案例專案尚無 ） AI 驅動的軟體開發 31
31. AI SDLC 的三個重點 重點 1 重點 2 重點 3 機器可檢查的完成定義 決策必須落檔，包括撤回的 閘門判「可歸因的新增」 檔案存在、格式正確、測試全綠、 閘門通過、版號可回讀——因為驗 收者常常是另一個代理或一支腳本 9/5 有人提議把提交訊息改成中文 ，當天提出、當天撤回；撤回也記 錄下來，以免下週另一個代理再提 一次 10/21 起，部分閘門只判本次變更 可歸因的新增發現；否則舊問題讓 每次提交都失敗，最後只好關掉閘 門 AI 驅動的軟體開發 32
32. SDD：讓規格成為代理的真相來源 GitHub Spec Kit（2025-09 開源） 三個層次（Böckeler） constitution specify clarify tasks analyze implement plan 規格只用來啟動這次任務，之後常不再維護 AWS Kiro requirements.md spec-first spec-anchored design.md tasks.md 案例專案最接近 規格在任務後保留，隨功能一起維護 需求以 EARS 句型撰寫：WHEN［條件］THE SYSTEM SHALL［行為］ spec-as-source 核心主張：寫下來的規格是真相來源，代理依規格產生並檢查程式碼 AI 驅動的軟體開發 人只改規格，程式完全由機器產生 33
33. 我們的作法 vs. SDD 面向 典型 SDD（Spec Kit、Kiro） 我們的作法（案例專案） 真相來源 功能規格：spec／plan／tasks（Kiro：requirements／ design／tasks） 規格加規則：PRD、設計、ADR，外加 46 份平台 ADR 與規範層 專案層原則 Spec Kit 的 constitution 檔 平台規範層：委託人維護、AI 逐字授權寫入、由閘門強制 驗證 多數工具的驗證步驟為選用；規格不是可執行的測試 完成檢核才簽入（8,386 次）、閘門、威脅對測試追溯、變異注入 規格漂移 spec-first 下，程式產生後規格常不再維護 決策落檔（含撤回）、正文歷程分離；無自動同步，靠 ADR 與閘門 執行者 多半是單一代理依序執行任務 協調者調度 14 個角色，交接靠檔案，模型分級 範圍 單一功能、單一版控庫 多專案平台：三層存放、單向引用、骨架產生器 文件量 被批評大量 markdown，小改動也走全流程 同樣面臨；以上下文預算、分卷、專案類型減輕 人的位置 在每個檢查點審閱規格 人在兩端：方向、豁免與裁決；例行檢查交給機具 AI 驅動的軟體開發 34
34. SDD 強化 Context，我們補上 Harness 與 Loop 我們補上的：Harness、Loop 與平台治理 共同的問題：文件量 SDD 強化的：Context 把規格寫對、拆好，放進我們的「需求」與「設計」階段 RFP／PRD ≈ specify HLD／ADR ≈ plan LLD ≈ tasks Kiro 把一個小 bug 展開成 4 個使 用者故事、16 條驗收準則；Auth 一個子專案就有 91 份 ADR 最接近 spec-anchored SDD 的重心：把規格寫對、拆好。我們的重 心：規格寫完後如何被遵守、如何隨規模治理 。 權限與環境 AI 驅動的軟體開發 hook 掛點 閘門與檢核 PDCA 平台規範層 35
35. 誠實的一頁：壓縮的是前段，卡住的是最後一哩 AI 壓縮了生產 需求 沒有自動變快的最後一哩 設計 實作 Stream Delivery 一天就從 RFP 走到第一個實作；需 求到實作從數週壓到數天 驗收 上線 合規 截至 11/5：各子專案尚未合併主幹，也還沒有 demo 驗收紀錄 需要人做決定的環節，不會自動變快——這是下一段「團隊」要處理的問題 AI 驅動的軟體開發 36
36. 第五部 構建 AI 軟體開發團隊 人決定方向與豁免，代理負責執行與自證，機具負責強制 37
37. AI 開發團隊的四層結構 AI 驅動的軟體開發 委託人（人） 提出需求、方向性裁示、擁有豁免權、維護規範層 協調者 拆任務、派工、收回報、判斷退件；只調度不代寫 代理角色（14 個） 各自執行一類工作，並以完成回報自證 機具 hook、閘門、守衛腳本、骨架產生器：不需要被說服，只照規則擋 38
38. 商業分析 商業 business-analyzer 產品經理 產品 product-manager 專案 專案經理 服務體驗設計 project-manager service-experience-designer 解決方案架構 架構 solution-architect 資安 顧問 先後順序不可違反 information-security-consultant 14 個角色依 DAG 交棒：先後順序不可違反 上游交付物就是下游開工的輸入 兩條線在設計會合 架構線（專案 → 架構）與體驗線 資安 工程 設計 系統工程 測試設計 軟體設計 介面設計 system-engineer test-designer software-designer ui-designer 測試工程 前端工程 test-engineer frontend-engineer 實作 API 聯調 後端工程 security-engineer 兩個匯流點 測試工程承接測試設計與後端；前 後端以 API 聯調 資安雙角色橫向貫穿 顧問：商業 → 架構；工程：架構 → 實作；可與主工作並行 backend-engineer AI 驅動的軟體開發 39
39. 原則一：豁免與方向，只能由人決定 角色不得自行裁減交付範圍，豁免權在委託人 紅線閘門的豁免限縮到「單筆指紋」，不能一次豁免 一整類 「這個檢查可以跳過」 代理會很有說服力地這樣告訴你。 制度的設計，就是讓它沒有機會自 己決定。 規範層只能逐字授權寫入；工具權限逐筆核可、定期 檢視 AI 驅動的軟體開發 40
40. 原則二：每個角色都要有輸入、輸出與完成定義 角色卡 職責 輸入 交付物 完成檢核 只做一類事，不跨界 需要哪些檔案才能開工 角色類型 主要交付物 建議模型等級 需求分析 需求分析、PRD 高 架構與設計 高階設計、ADR、細部設計 高 實作 程式碼與單元測試 中至高 測試 測試計畫、整合與 demo 腳本 中 資安 威脅模型、威脅對測試追溯 高 發行與維運 版號、部署腳本、環境檢查 中 固定程序執行 推送前全套、格式檢查 低（小模型） 產出哪些檔案、放在哪裡 用什麼機制證明做完了 起步參考配置：建議，非案例專案原始名單 AI 驅動的軟體開發 41
41. 原則三：角色要有驅動來源；人的技能往上移 人的工作重心往上移 要不要設審查角色？ 10/18 討論後決定「暫不設」：還沒有量 到需要它的失效。為了看起來完整而設的 角色，只會增加交接成本。 寫清需求 審關鍵設計 維護規則與機具 讀數據做裁決 10/29 委託人原則 合規依組織規模調整；人力、預算與客戶答覆，一律不作為開發與上線的前置條件 AI 驅動的軟體開發 42
42. 第六部 開發過程中的管理 用讀數管理，不用印象管理 43
43. 管理的四個抓手 派工 輸入 範圍 變更 量測 讀數 事故 例外 好的派工單就是好的上 下文 每件順便發現的事，都 要有去處 先量、再定、附重評條 件 每一次事故都要變成一 條規則 管理 AI 團隊：用讀數管理，不用印象管理 AI 驅動的軟體開發 44
44. 派工與範圍：每件「順便發現的事」都要有去處 派工單的固定欄位 完整上下文 範圍外事項：四問分級 1 當下處理 2 上呈裁決 3 排入排程 4 只登記 428 22 項押後事項已登記 份個案紀錄承載裁決往返 輸出格式句 模型等級 預估工時 限制條款 連續三步以上的固定操作，必須寫成腳本 AI 驅動的軟體開發 45
45. 量測：一個 75 倍的落差 75 倍 5.92 倍 0列 人日估算 ÷ 實耗代理時數 改為分鐘兩欄（代理／機器） 沒有任何一列低估 10 月初回頭比對：傳統估算幾 乎沒有意義，人工實績登錄停掉 Lite Portal 試行 170 列；實作類 為 10.31 倍 11/5 依讀數定出估算係數，附 四款重評條件，寫入全域指示 先量 → 再定 → 附重評條件 同樣的邏輯用在成本：11/2 起彙整本機 token 用量，以讀數取代「最近好像很耗」的印象 AI 驅動的軟體開發 46
46. 事故：每一次事故都要變成一條規則 日期 事故 形成的規則 10-01 清理暫存時以萬用字元誤刪他人目錄 一律逐一以全名刪除；刪不掉即停、具名回報 10-08 回復時誤把他會談進行中的搬移當半成品，內容遺 失 開工先查同庫會談；同庫只容一個協調者 10-17 兩個磁碟根目錄遺留約 13 GB 暫存 暫存集中於單一根目錄 「刪不掉就停，不要換一種寫法重試。」 代理遇到失敗的本能是換方法再試；在破壞性操作上，這個本能是危險的 AI 驅動的軟體開發 47
47. 第七部 擴充到多專案：專案治理與平台化 把重複出現的規則上收成平台；新專案一開庫就接上全部機具 48
48. 81 天、四個治理階段 一 單庫萌芽 二 平台化 三 規模化之痛 四 治理外延 08-17 ～ 09-05 09-06 ～ 09-28 09-29 ～ 10-17 10-18 ～ 11-05 • 與 Auth 同庫起步 • 分庫、規範層獨立 • 七個子專案同日開庫 • 主機維運、授權合規 • 完成檢核自動簽入 • 引用方向單向化 • 退件不達、會談衝突 • 合規依組織規模調整 • 合併前閘門雛形 • 骨架產生器上線 • 交回前檢核、模型分 級 • 三天從開庫到實作 2026-08-17 開工 AI 驅動的軟體開發 11-05（第 81 天） 49
49. 平台化的三個關鍵決定 09-05 09-06 09-16 三層存放 引用只有一個方向 骨架產生器 規則分成全域、平台規範層、各專 案三層，並訂出「上收清單」 分庫後，平台不得引用子專案；子 專案引用平台是唯一合法方向 新專案一建立就接上全部 hook、 閘門與守衛；並定義純文件型、 API 服務型等類型 成果：10/2 七個子專案同一天建立骨架；Lite Portal 開庫三天就走到實作與部署腳本 AI 驅動的軟體開發 50
50. 平台承接什麼，又該拒絕什麼 平台承接什麼 一致性 後台介面一致性規範成為平台合約；版號 tag 跨庫全域唯一 合規 第三方授權以「義務是否擴及我方程式碼」為判準；子專案 自查，10/25 收齊，全部 0 列 平台要懂得說不 • 合規強度依組織規模調整，且不得阻擋 開發與上線 • 三次法則：同一問題第三次被問到才重 評；交付條款維持由子專案自擬 • 例外走正式程序：暫行服務自建登入， 以一份 ADR 記錄豁免 維運 主機側腳本、硬配額、更新來源、URL Rewrite、憑證續期 ；子專案分散到獨立節點 AI 驅動的軟體開發 51
51. 第八部 PDCA 的運用 多數改進不是先規劃出來的：先量到失效，才有規則，再有機具 52
52. 六個改進循環，五個由檢核發現啟動 循環 起點 C：檢核發現了什麼 A：改善 工具更新使退件不達 交回前檢核規則；派工格式句使兩類退件歸零 交回驗收 ★ C 觸發 上下文預算 ★C 1,095 行超長，最長 33,322 字元 正文歷程分離、分卷、用量彙整 工時估算 ★C 人日估算約為實耗 75 倍 定出係數並附四款重評條件 暫存與清理 ★C 萬用字元誤刪；遺留約 13 GB 集中單一根目錄；刪不掉即停、具名回報 多會談並行 ★C 他會談的搬移被誤處理而遺失 開工先查同庫會談 第三方授權 P 自查回報收齊，皆 0 列 第三次被問到才重評，維持現狀 比起事先想到所有問題，更重要的是能不能及早量到失效 AI 驅動的軟體開發 53
53. 讓 PDCA 真正轉起來：規則的生命週期 提出 寫下 掛上機具 變異注入 生效 量測 修訂或撤回 修訂或撤回之後，回到下一輪的提出 1 2 3 4 寫明驅動來源 已寫下≠已生效 守衛做變異注入 以重評條件取代定論 已發生的失效或已確認的 需求；寫不出來就不加 生效判準：機具已交付、 已掛上、已驗證；之前照 舊作法 故意種一個錯確認會變紅 ，並用 diff 證明變異落檔 如「第三次被問到」「讀 數再增 50 件」；不定死 也不擱置 AI 驅動的軟體開發 54
54. 三層迴圈，就是三層同時轉動的 PDCA 規則 內迴圈：任務的 PDCA 以分鐘計：做 → 驗 → 修，完成檢核通過才簽入 交付 中迴圈：交付的 PDCA 以版本計：閘門、交回前檢核 任務 外迴圈：規則的 PDCA 以週計：81 天產出 46 份平台 ADR 會自我修正的系統＝三層同時轉動的 PDCA AI 驅動的軟體開發 55
55. 第九部 未來發展方向 治理要走出研發部門，也要讓人一眼看得見；工具入口從「打開全部專案」 走向「單一入口」 56
56. 讓更多部門加入迴圈：從審查者變成規則提供者 PMO 資安部門 行政部門 已有基礎 已有基礎 已有基礎 押後事項 428 項、個案紀錄 22 份 、分鐘級工時讀數、各子專案版號 gitleaks、SAST、伺服器端 hook 、威脅對測試追溯、單筆指紋豁免 第三方授權規則與子專案自查、交 付條款裁定 未來角色 未來角色 未來角色 以讀數做跨專案組合管理：排程、 資源、優先序；進度不再靠週報 政策寫進規範層與閘門、持有閘門 豁免權；稽核直接讀 ADR 與閘門 紀錄 提供授權、合約與採購的判準；代 理產出自查表，由人裁決 AI 驅動的軟體開發 57
57. 人類的專案治理可視化：一眼知道哪裡需要我 即時態 哪個代理正在工作、哪個卡住在等人、哪個已完成 進度態 各子專案的 SDLC 階段、版號、閘門結果、預備環境 版本 治理態 ADR 狀態、待裁決個案、押後事項、生效中的豁免 量測態 估算與實耗比、token 用量、退件數與類型 AI 驅動的軟體開發 兩條原則 • 資料來自機具讀數，不靠人工填 報 • 每個儀表板都說得出驅動來源： 回答誰的哪個決策 今天引用的「大事紀」與「治理演進」兩份 頁面，就是可視化的第一步 58
58. 工具入口：從「打開全部」到「單一入口」 方向：herdr，專為 AI 編碼代理設計的終端工作區 現況 VS Code 開啟全部子專案 好處 以背景伺服器保持真實終端會談，斷線或闔上筆電也不中斷 代理狀態一眼可見（工作／卡住／閒 置／完成） 即時態可視化 SSH 連到遠端，代理在遠端持續執行 子專案分散到獨立節點 CLI 與 socket API，可被代理驅動 協調者的調度 git worktree 對應獨立工作區 並行派工的檔案互斥 一眼看到所有程式碼、可以跨庫搜尋 限制 代理狀態散在各終端，人要輪流檢查誰在等輸入 ；看不到其他會談在做什麼（10/8 事故的根源 之一） AI 驅動的軟體開發 59
59. 逐次演進的四步 第一步｜現況 第二步 第三步 第四步 多專案編輯器 代理會談單一入口 入口接上治理讀數 部門治理儀表板 VS Code 開啟全部子專案 ；跨庫搜尋，但狀態分散 如 herdr：狀態一眼可見， 遠端節點、持續會談 閘門、押後事項、工時在 同一處檢視 PMO、資安、行政各取所 需的讀數 AI 驅動的軟體開發 逐次：每一步都走 PDCA 導入前的關卡 先在一個子專案試行，量測退件與等待時間是 否下降，附重評條件後再擴大 herdr 是第三方工具：先通過第三方授權規則（ Apache-2.0），以及資安對資料流向的確認 60
60. 案例專案沉澱出的六條治理原則 1 已寫下不等於已生效 每條規則附生效判準：機具已交付、 已掛上、已驗證 4 以重評條件取代永久定論 記下何時重議，不一次定死也不無限 擱置 AI 驅動的軟體開發 2 說得出驅動來源 寫不出已發生的失效或已確認的需求 ，就不加 5 豁免與方向由人決定 代理不得自我豁免、不得修改規範層 3 移除守衛前先做變異注入 「擋下 0 次」可能只是掃不到 6 交接只靠檔案，引用只有一 個方向 子專案引用平台，平台不引用子專案 61
61. 下週一就能開始的三件事 1 2 3 定一份完成回報格式 開一本押後事項登記簿 挑一個指標開始量 再用一個 hook 讓「沒通過檢核 就不能提交」 讓Agent「順便發現的事」都有 去處 工時、token、退件數都可以— —用讀數取代印象 從一個專案、一個 hook、一份回報格式開始 AI 驅動的軟體開發 62
62. 我們真正在建造的，是一套會自我修正的系統 Prompt 讓它聽懂，Context 讓它看對，Harness 讓它做得到也做得 安全，Loop 讓它犯錯時被抓到，PDCA 讓系統本身一起成長 謝謝聆聽｜Q&A
63. 附錄｜案例專案關鍵數據（截至 2026-11-05） 項目 數值 說明 期間 81 天 2026-08-17 開工至 11-05 提交 15,651 次 12 個版控庫，分庫前共有者只計一次 自動簽入 8,386 次 通過完成檢核後自動簽入；已扣除分庫前共有的 872 筆 平台 ADR 46 份 平台層架構決策紀錄 001～046 代理角色 14 個 由一位協調者調度 子專案版控庫 11 個 含 4 個僅有骨架者 個案紀錄 22 份 承載需人裁決的往返 押後事項 428 項 已登記於押後事項登記簿 工時估算落差 75 倍 → 5.92 倍 試行 170 列後：實作類 10.31 倍、0 列低估 AI 驅動的軟體開發 65
64. 附錄｜參考資料 herdr 介紹（TecMint） https://www.tecmint.com/herdr-run-ai-coding-agents-in-linux-terminal/ herdr 功能整理（innFactory，2026-09-20） https://innfactory.ai/en/ai-harness/herdr/ herdr 功能說明（mer.vin） https://mer.vin/2026/07/herdr-explained-terminal-multiplexer-for-running-multiple-ai-coding-agents/ Understanding Spec-Driven-Development（Böckeler，2025-10-15） https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html Spec-Driven Development in 2026（CodeMySpec） https://codemyspec.com/blog/spec-driven-development GitHub Spec Kit 指南（CodeMySpec） https://codemyspec.com/blog/github-spec-kit-guide Kiro Specs 概念說明（kiro.dev） https://kiro.dev/docs/specs/concepts Harness engineering: What makes AI coding agents work in 2026（Faros AI） https://www.faros.ai/blog/harness-engineering Prompt vs Context vs Harness vs Loop Engineering（AI Builder Club） https://www.aibuilderclub.com/blog/prompt-context-harness-evolution Connect Claude Code to tools via MCP（Claude Code 文件） https://code.claude.com/docs/en/mcp Extend Claude with skills（Claude Code 文件） https://code.claude.com/docs/en/skills AI 驅動的軟體開發 67