從開發到部署全都交給 AI：實作 AI 驅動的自動化流程

寫程式交給 AI，已經不是新聞。但如果 AI 還能自己做 Code Review、自己根據 Review 意見修正、CI/CD 流程報錯時自己修到綠燈呢？

這場工作坊要帶你實作的，不是「用 AI 寫程式」這麼簡單的事，而是一條從開發、Review、到部署幾乎全自動的 AI 驅動流程。

開發者只需要介入兩個環節 — 開頭對齊方向，結尾做最終把關，中間全部交給 AI 自動迭代。

前 20 分鐘：拆解 AI 驅動開發的完整循環

我們會先走過一條完整的自動化流程：AI 根據你的需求產出執行計畫、實作程式碼、自動重構與安全掃描、發 PR 後觸發 AI Code Review、AI 讀取 Review 意見自動修正並重新提交、CI/CD 流程報錯時 AI 自動診斷並修復。你會看到在這條流程中，開發者真正需要動手的地方只有兩處，其餘全是 AI 在跑。這段會用實際的 PR 案例展示整個循環怎麼運作，讓你在動手前就有清楚的全貌。

中間 60 分鐘：從零跑完一輪完整流程

這是工作坊的核心。你會從一個實際需求出發，親手走過每一個階段：用 AI 產出執行計畫，反覆問答直到方向對齊。讓 AI 動手實作，體驗監督而非手寫的開發方式。執行自動化的程式碼優化與安全掃描。發 PR，觸發 AI Code Review，再讓 AI 自動讀取意見、修正、重新提交，看著 Review 留言一輪一輪歸零。最後，我們會刻意製造 CI/CD 流程報錯的情境 — 讓你看到 AI 如何自動讀取錯誤日誌、定位問題、修正程式碼、重新觸發流程，直到 Pipeline 全部通過。

最後 10 分鐘：帶回你自己的團隊

我們會回顧整場實作的成果，討論這套流程在不同團隊規模和工具鏈下如何落地，以及如何透過自訂 AI Agent Skill 持續擴充自動化的覆蓋範圍。

https://devopsdays.tw/2026/session/4706

Transcript

1. DEVOPSDAYS TAIP EI 2 026 HANDS-ON WORKSH OP · 90 MIN // agentic devops 從開發到部署 全都交給 AI 實作一條 AI 驅動的自動化流程 $ git init → AI takes it from here Bo-Yi Wu @appleboy 2026.06.26 · Taipei
2. // ABOUT THE SPEAKER 講者介紹 appleboy 後端架構工程師 · Backend Architect GitHub github.com/appleboy Blog blog.wu-boy.com 現任後端架構工程師，負責公司內部 Technology Platform 開發與維運。擅長以 Go 構建微服務 架構，熱衷導入 DevOps 與自動化流程，改善團隊協作效率。長期貢獻 Open Source，曾任多 場技術研討會講師。目前專注於 AI 工具導入，探索 AI 能為軟體團隊加速多少開發流程與決策效 率。 Go 微服務架構 DevOps · 自動化 Open Source AI 工具導入 帶領三個小團隊 01 Backend 02 Kubernetes 03 CI / CD 2
3. // THE NUMBERS · 半年內團隊數據 AI 已經是程式碼的主要作者 AI 產出佔總新增行數 90.7% AI 12.74M 開發者 1.31M 總計 14.05M 程式碼 Code 86.6% AI 6.86M · 人 1.06M ≈ 6.5× 文件 Docs 95.7% AI 4.97M · 人 0.22M ≈ 22.5× 測試 Tests 96.4% AI 0.92M · 人 0.03M ≈ 27× 最常被犧牲的文件與測試，反而被 AI 補得最滿 3
4. // THE SHIFT · 月度趨勢 人寫得越來越少，產出卻越來越多 AI 開發者 每月新增行數 · AI 佔比 (%) 66% 08 80% 09 80% 10 80% 11 88% 12 91% 01 94% 02 91% 03 95% 04 96% 05 AI 佔比變化 66% → 97% 開發者手寫行數 逐月下降 ↓ 總產出卻翻了數倍——人不再是 產線 * 06 為當月尚未結算數據 4 97% 06*
5. // WHAT IT MEANS · 指標的含義改變 同一組數字，意思已經不一樣了 LOC（行數）代表 過去 開發者的生產力 → 現在 AI 的產能規模，不再等於人的努力 文件 / 測試 過去 趕進度時最先被犧牲，覆蓋不全 → 現在 AI 自動補齊，幾乎 100% 跟上 工程師的價值 過去 寫了多少行 = 貢獻多少 → 現在 定義方向 + 審查把關 >_ 別再用「行數」評估人。該問的是——你讓 AI 產出了什麼，又把關了什麼？ 5
6. // THE LIFECYCLE · SDLC 全流程分工 哪些交給 AI，哪些更要專注 → 02 Develop 開發 AI 主導 → 03 Testing 測試 AI 主導 → 04 Docs 文件 AI 主導 → → AI 大量協助 Develop · Testing · Documentation 繁重的實作、測試與文件，幾乎全交給 AI 一次補滿，人不再是產 線。 >_ 繁重的交給 AI，方向與品質的把關留給人 6
7. // PLAN STAGE · plan-feature skill 寫程式之前， 先把計畫講清楚 多數 AI coding 失敗，不是因為模型不夠強，而是人沒給足夠的 context。plan- feature 用約 15 分鐘把你變成 Claude 的產品經理，大幅提升實作成功率。 $ /plan-feature → 產出 plan.md 投入時間 ~15 min 動程式碼前的規劃成本 產出物 plan.md 一份可交接給全新 AI 對話的契約 文件 >_ 把使用者變成 Claude 的 PM，而不是讓模型瞎猜 7
8. // WHEN TO USE · 何時使用、何時略過 什麼情況該 plan，什麼情況直接做 略過 · 真正瑣碎的改動 – 錯字修正、單行設定變更 – 單純的重新命名 – 使用者已經給了完整規格 >_ 有疑慮時，就 plan（When in doubt, plan） 8
9. // THE WORKFLOW · 八步驟工作流程 照順序走完八個步驟 STEP 1–5 · 思考與設計（先別寫程式） 01 釐清目標 Clarify goal 02 探索程式庫 Explore code 03 界定範圍 Identify scope 04 驗證策略 Verification 05 畫設計圖 Sketch diagram STEP 6–8 · 寫成文件、核可、交接 06 撰寫 plan.md Draft the plan 08 建議交接 Recommend handoff >_ 驗證設計先於實作設計——可驗證的檢查點原則 9
10. // STEP 1–4 · 動程式碼前的思考 先想清楚，再畫設計圖 01 釐清目標 Clarify the goal · 用 1–3 個問題問清楚 · 誰用？做完長怎樣？已知限制？ → 產出一段使用者確認過的問題陳述 02 探索程式庫 Explore the codebase · Read · Grep · Glob 先看再設計 · 找 1–2 個結構相似的既有功能當範本 · 記錄命名 / 測試慣例、共用工具 → 釐清 core 與 leaf 的邊界 03 界定範圍 Identify scope · 可修改的檔案 / 模組清單 · 絕不可改的核心程式碼清單 → 會碰到 core 就明講，拆成人主導 + leaf 功能 04 驗證策略 Verification · 3 個端到端測試：1 正常 + 2 錯誤 · 使用者可觀察層級，非實作細節 · 壓力 / 長跑測試、可觀測性（log/metric） → 驗證設計先於實作設計 10
11. // STEP 5 · 把設計畫成 Mermaid 圖 一張圖，讓設計可被審查 錯的邊界、漏掉的呼叫，在圖上一眼看出，在文字裡容易漏掉。用 Mermaid 畫——可在 plan.md 原生渲染、隨計畫一起 diff。 依功能本質選圖型 時間上的互動 / 握手 auth 流程、請求生命週期 Sequence sequenceDiagram 控制流程 / 管線 分支邏輯、資料轉換、工作步驟 Flowchart flowchart TD 新增 / 重接模組、服務 結構性依賴關係 Component flowchart LR + subgraph 狀態機 狀態轉換、token / job 生命週期 State stateDiagram-v2 四條保持誠實的規則 1 每個節點對應 scope 裡真實的檔案 / 模組 2 用 style 標出新 vs 既有，邊界清楚 3 控制在 15–20 個節點內，否則該拆 4 寬則用 TD、不用 click 互動 11
12. // STEP 6 · 撰寫 plan.md 把一切寫成一份 plan.md plan.md # Plan: <feature name> ## Goal — 問題陳述 ## Architecture / flow — Mermaid ## Scope ### May modify ### Must not modify ## Existing patterns to follow ## Constraints ## Verification — 3 e2e tests ## Done definition — [ ] checklist ## Risks & rollback ## Open questions Goal · 一段就好 誰用、做完長怎樣、回傳什麼——具體到實作者不必再猜 Scope · 兩份清單 明確列出可改與不可改，守住核心程式碼 Verification + Done 3 個測試 + 可勾選的完成定義 checklist >_ 當成給 junior 的 onboarding 文件，不是填空表 12
13. // STEP 7–8 · 核可、交接給乾淨對話 先核可，再交接執行 08 建議交接 ① 壓縮目前對話，或開一個新對話 ② 用下面這句開場 ↓ $ Execute the plan in plan.md. Do not deviate from scope. Stop and ask if you find ambiguity. i 規劃常累積 80k+ token，壓縮後剩幾千 → 執行對話乾淨聚焦 13
14. // ANTI-PATTERNS · 要避免的五個陷阱 別把好計畫做壞了 01 過度約束提示 別規定每個變數名——給重要限制，其餘交給模型，當 onboarding 而非填空表 02 跳過程式庫探索 沒讀過既有程式碼，寫出的計畫產出的程式碼不會合身——一定先看 03 模糊的驗證 「它能動」不算驗證——一個正常路徑 + 兩個錯誤情境的具體測試才算 04 悄悄動到核心程式碼 碰 core 要人來負責、單獨決策——明講，別埋起來 05 畫一張對不上 scope 的圖 不會真的去蓋的理想架構圖，比沒有圖更糟——重新對齊或拆小 >_ 計畫不是官僚流程，是把你變成 PM，讓 AI 一次做對 14
15. // HANDS-ON · 動手練習中斷點 BREAK · 10–15 MIN 換你動手跑一次 拿一個自己手上的真實案例——一個正在做、或接下來要做的功能、端點、重構都行。 打開 AI coding 工具，善用 /plan-feature，照八步驟跑到產出 plan.md。 01 選一個真實的題目，別挑玩具範例 02 執行 /plan-feature，讓它問你、釐清目標 03 跑到產出 plan.md，你看過並核可 ✋ 卡住就舉手 等一下挑一兩個案例一起看 $ /plan-feature 15
16. // CODE QUALITY · Claude Code 獨有 Skill 指令 三個 Skill 指令，讓 AI 產出的品質穩定 不是貼程式碼給 chatbot 看——這些 Skill 會在你的 repo 上跑工具、讀整個 codebase、直接動手修。 01 / simplify 收掉過度設計 把 AI 容易寫出的重複邏輯、過度抽象收 乾淨，降低複雜度，讓程式碼更好維護。 02 / security-review 自動安全審查 掃一遍安全面向，揪出注入、密鑰外洩、 權限漏洞，趁上線前補掉。 >_ 每一輪 AI 產出後自動掛上一道品質護欄——這是 Claude Code 獨有的 Skill 指令 16
17. // EXECUTION ORDER · 三個指令的建議順序 順序也有講究——先收斂與把關，最後才總體審查 我的習慣是 /simplify 和 /security-review 都跑過之後，最後才跑 /code-review max --fix。 STEP 01 / simplify 先縮小範圍 把過度設計、重複邏輯收乾淨，要審查的 面積先變小，後面每一輪都更省、更準。 → STEP 02 / security-review 再排除風險 在已經精簡的程式碼上掃安全，雜訊少、 定位準，注入、密鑰、權限趁早補掉。 → >_ 先縮小範圍、再排除風險、最後總體把關——最貴的那一輪留到最後跑，每一步都在替下一步減負 17
18. // COMMIT & PR · 兩個 Skill ，各司其職 Commit 與 PR，拆成兩個 Skill commit 是一顆顆原子變更，PR 是一個完整故事——關注點不同，拆開才能各自做到最好。 SKILL 02 / pr-prepare 把整條分支收攏成一份 PR · 自動生成標題、摘要、變更重點、測試方式 · 補上對應 issue 連結與 reviewer 提示 → 審查者一打開就知道在做什麼、該看哪 >_ 一個 Skill 一件事——各司其職，才能各自做到最好、單獨調整 18
19. // SKILL DEEP-DIVE · /commit-message 　1/2 · 讀懂變更 先讀懂變更，再寫出摘要 1 暫存並取得 diff 只 stage 相關檔、不盲目 git add -A；取 --staged --stat + 完整 diff，沒有變更就停 2 比對既有 commit 風格 git log --oneline -20，沿用 repo 慣例——內建規則只是預設值 3 分析 diff、寫摘要 條列式、可讀性優先、寧少勿多；不放檔名、不抄程式碼註解 4 生成標題 祈使句（kernel 風格） 、單一主題、首字小寫、無句點；<50 字元 讀取階段的內建防呆 · diff > 2000 行 → 聚焦 --stat 與 重點 hunk · 跨 10+ 檔 / 不相關 → 建議拆成多 個 commit · 沒有 staged 變更 → 直接停下並告 知 不確定 stage 哪些檔？ 先給你看 git status，由你決定 >_ 先看懂這次到底改了什麼，摘要才會準 19
20. // SKILL DEEP-DIVE · /commit-message 　2/2 · 成型與提交 組成 Conventional Commit，直接提交 5 決定 prefix 與 scope feat / fix / docs / refactor / chore… 擇一 破壞性變更加 ! + body 補 BREAKING CHANGE scope 取最具體共同目錄，找不到可省略 6 建立 commit 用 HEREDOC 帶多行訊息，直接 commit、不再問你確認 7 處理附加指令 「commit 然後 push / 開 PR / 打 tag」——成功後才依明確要求執行 產出的 commit 結構 feat(openai): add completions endpoint - Implement an OpenAI API endpoint - Relocate octokit init to a file BREAKING CHANGE: … 遷移方式 prefix(scope): title　·　header < 72 字 元 空行 → 條列摘要 破壞性變更才有 footer >_ 把「寫 commit」從隨手動作，變成可重現、貼合 repo 慣例的流程 20
21. // NEXT UP · 換手到第二個 Skill Commit 講完了，接著把分支收攏成 PR commit 是一顆顆原子變更，PR 是一個完整故事——下半場，焦點換到 /pr-prepare。 SKILL 01 · 已講完 ✓ commit-message 寫出講得出「為什麼」的 commit · 讀 staged diff，對照 repo 慣例 · 組成 Conventional Commit，直接提交 → 一顆顆原子變更，已經就緒 >_ 下半場，把 /pr-prepare 拆開來看——它怎麼讀懂、把關、產出 21
22. // PR STAGE · pr-prepare skill 開 PR 之前，先說清楚誰寫的 多數含 AI 的 PR，省略了 reviewer 正確評估所需的揭露。pr-prepare 把 AI 作者身分、 變更分類、驗證狀態攤在明處，再用一張圖畫出變更。 $ /pr-prepare → 可貼上 GitHub 的 PR 描述 產出物 PR 描述 結構化、含一張 Mermaid 變更圖 帶來的 分配審查精力 哪裡逐行細看、哪裡 spot-check 就好 >_ 隱瞞 AI 作者身分，是壞 review 最大的來源 22
23. // WHEN TO USE · 何時觸發、何時略過 什麼時候叫出 pr-prepare 略過 · 只有兩種情況 – 使用者明說「我自己寫 PR」 – 只想要原始 diff 輸出 >_ 連「我功能做完了」都算——他們幾乎一定需要一份 正式 PR 描述 23
24. // THE WORKFLOW · 八步驟工作流程 一條八步管線：讀懂 → 把關 → 產出 STEP 1–5 · 讀懂變更與把關 01 讀變更 Read diff 02 問 AI 作者 AI authorship 03 分類 leaf·core Classify 04 偵測驗證 Verification STEP 6–8 · 畫圖、產出、交付 06 畫 Mermaid 圖 Map the change 07 產出 PR 描述 Produce PR body 08 交接 Hand off >_ 把關沒過，就停下、不產出 PR 描述 24
25. // STEP 1–4 · 讀懂變更、判斷風險 先讀懂，再判斷風險 01 讀變更 Read the change · git status · log · diff --stat · diff · 小檔讀完整 diff，大 diff 抽樣重點 → 記下變更的「形狀」 ，當畫圖的原料 02 問 AI 作者身分 AI authorship · 明確問、不推測 · 記錄 AI 寫的檔 / 人類逐行 review 的檔 / 工具·模型 → 使用者說「不記得」本身就是警訊 03 分類 leaf / core Classify · Leaf：沒東西依賴它，壞了只是局部 · Core：很多東西依賴，壞了全系統受影響 → 兩者都碰算 core；問「失敗會擴散多遠？」 04 偵測驗證 Detect verification · 數測試、看 e2e vs 實作耦合 · 長跑程式有無壓力測試、重要路徑有無 log/metric → core 或測試 < 3 個，先警告使用者 25
26. // STEP 5 · 送出前的檢查關卡 過不了這關，就不該開 PR PRE-SUBMIT CHECKLIST ✓ 有計畫：plan.md 或至少一段書面目標 + 範圍（leaf 也要） ✓ PR 有界線：< 500 行可人工審查；更大需事先協調 ✓ 所有測試本地通過 ✓ diff 裡沒有 secret / API key / 憑證 ✓ 尊重 plan 的 must not modify 邊界 ✓ 碰 auth / payment / 外部 API → 額外安全審查 STOP 任何一項沒過 → 停下、把問題 surface 給使用 者，不要替還不該開的 PR 產出描述。 i 只問從 diff 看不出是否滿足的項目 26
27. // STEP 6 · 把變更畫成 Mermaid 圖 一張圖，讓 reviewer 先看懂結構 看懂結構遠比讀檔案清單快。Mermaid 在 PR 描述裡原生渲染、不需圖床，隨架構一起 diff。 依「變更本質」選圖型 服務間互動 / 握手 auth 流程、請求生命週期、client↔server Sequence sequenceDiagram 控制流 / 管線 分支邏輯、資料轉換、CI 步驟 Flowchart flowchart TD 新增 / 重接模組、服務 結構性依賴關係 Component flowchart LR + subgraph 狀態機 狀態轉換、token / job 生命週期 State stateDiagram-v2 四條讓圖誠實的規則 1 每個節點對應 diff 真實改到的東西 ——不畫架構虛構 2 標出新 / 改：per-node style，別用 %%{init}%% 3 控制在 15–20 節點，超出就是該拆的 訊號 4 寬用 TD、不用 click；瑣碎變更直 接跳過圖 27
28. // STEP 7 · 產出 PR 描述 套進一份結構化的 PR 描述 PR description ## Summary — 做了什麼、為什麼 ## Architecture / flow — Mermaid ## AI Authorship — 工具· 檔案· 誰 review ## Change classification — leaf / core ## Plan reference ## Verification — 3 e2e (1+2) ## Verifiability check ## Security check — 碰外部介面才有 ## Risk & rollback ## Reviewer guide — 細看 / spot-check 形狀放最前 Summary 後緊接 Mermaid，reviewer 先看結構再看細節 對 AI 作者身分誠實 reviewer 據此分配審查精力；core 仍需逐行 Reviewer guide 明講哪些細看、哪些 spot-check 就夠 >_ 把風險放前面——reviewer 一眼看出該 scrutinize 什麼 28
29. // ANTI-PATTERNS · 產出前先攔下這些 看到這些，先別急著開 PR 01 core 路徑有 AI 程式碼，卻沒註記人類逐行 review 02 沒測試，只有「我本地測過」 03 AI 作者身分未揭露 04 改到了 plan 宣告範圍以外的檔案 05 跨模組龐雜 diff——暗示該拆成多個 PR 06 圖裡有對應不到改動的節點（架構虛構）——先修圖 交接 ↘ 貼到 GitHub PR body · reviewer：leaf 1 / core 2+（含模組 owner） · 先到 Mermaid Live 確認能 render · gh pr create --body-file >_ 整個 skill 三句話：具體 · 展示形狀 · 對 AI 誠實 29
30. // HANDS-ON · 換你跑一次 動手練習：/commit-message → /pr-prepare STEP 1 / commit-message 在自己的 repo 上做一筆有意義的改動，stage 之後讓它幫你寫出 commit。 STEP 2 / pr-prepare 把整條分支收攏成 PR，看看它生成的標題、摘要與變更重點。 ⚠ 先 review 下指令之前，先自己看過代碼確認沒問題再執行——AI 幫你寫訊息、收攏 PR，但不替程式正確性負責；沒看過就執行， 等於把沒驗證的東西直接送出去。 >_ 流程：讀 diff → 自己 review → /commit-message → /pr-prepare 30
31. // THIRD-PARTY REVIEW · PR 開出後，三選一 發完 PR，先挑一個 AI 幫你 review 一輪 01 GitHub Action Claude Code Review Anthropic 的 claude-code-action，在 PR 上跑 Claude，貼出逐行 review 與整體摘要。 >_ @claude review 02 原生整合 GitHub Copilot Review 原生整合進 GitHub，把 Copilot 指派為 reviewer，直接在 diff 上給 inline 建議。 >_ Reviewers → 指派 Copilot 03 OpenAI Codex Review OpenAI Codex，自動或手動觸發，產出審查 意見與具體的修正建議。 >_ @codex review >_ 三者擇一即可——目的是在人類 reviewer 介入前，先讓 AI 抓一輪明顯問題與風險。 >_ 就拿選項 02 的 Copilot Review 來說——它還能用 /loop 自動跑 31
32. // COPILOT-REVIEW · 把選項 02 變成自動迴圈 一道指令跑一輪 查 → 修 → 再審，交給 /loop 重複 >_ /loop 3m /copilot-review /loop 每 3 分鐘呼叫一次 /copilot-review，每次只跑「一輪」check-fix，自己收斂 ——不用守在電腦前。 01 查留言 抓出 Copilot 未解的 review threads → 02 逐條修 讀懂、判斷脈絡，再動手改 → 03 push 跑測試、commit，推上去 → 04 resolve 把已處理的 thread 標記解 決 ↻ 05 再審 重新指派 @copilot，等下 一輪 >_ 迴圈只有在 Copilot 回報 generated no new comments 時才停——其餘狀況都只是「結束這一輪」 。 >_ 一輪做什麼、什麼時候停——先看骨架，下一頁拆八步 32
33. // THE WORKFLOW · 一輪 check-fix 的八個步驟 一輪八步：讀懂 → 修 → 收尾 01 偵測 PR auto-detect 當前分支，或直接指定 number / repo 02 確認 review 狀態 用 GraphQL 確認 Copilot 審完、且涵蓋最新 push 03 取出未解留言 過濾 copilot-pull-request-reviewer 的 unresolved threads 04 修正程式碼 逐條讀懂、判斷脈絡再修——不盲從每一條建議 05 跑測試 commit 前先綠燈；壞了先修，衝突就 revert 該建議 06 Commit & Push 用 /commit-message 產生 conventional commit 07 Resolve threads 把已處理的 thread 用 GraphQL mutation 標記解決 08 重新觸發 review 重新指派 @copilot，並記錄 lastSeenReviewAt 讀懂 · 修 · 收尾 ——一輪結束，/loop 再來一次 33
34. // LOOP CONTROL · 「結束這一輪」≠ 「整個迴圈停」 分清楚 return 和 stop the loop return 結束這一輪，迴圈繼續 這三種狀況只是等下一次，不會停迴圈： ① 還沒有 Copilot review → 先觸發，等下一輪 ② review 早於最新 push → 等它審最新 push ③ 重新觸發的 review 還沒到 → 用 lastSeenReviewAt 判斷，繼續等 stop the loop 整個迴圈結束 唯一能讓迴圈停的條件： review body 出現 "generated no new comments" 或 "generated 0 comment" ✕ thread 全 resolved、或沒推新 code，都不算停的理由 上限 10 輪——再多通常是架構分歧，請人工介入 Copilot review 是 Comment 型——不 approve、不 擋 merge 開源 repo 免費——不需 Copilot 訂閱 >_ 掛上 /loop 3m /copilot-review，剩下的交給它自己收斂 34
35. // HANDS-ON · 掛上自動迴圈，去喝杯咖啡 ⏱ 10–15 min 動手練習：掛上 /loop 3m /copilot-review >_ /loop 3m /copilot-review 下完就放著——每 3 分鐘跑一輪 check-fix，自己收斂，不用守在電腦前。 STEP 1 指派 Copilot 拿剛開好的 PR（或前面 /pr-prepare 那 支） ，把 Copilot 指派成 reviewer。 STEP 2 掛上 /loop 下 /loop 3m /copilot-review，中途 別插手，先讓它跑一到兩輪。 STEP 3 盯著它收斂 回頭看 PR：review comment 被一條條自 動修掉並 resolve，直到 no new comments。 你會看到 查留言 → AI 自動修 → 自動 close / resolve comment → 重新觸發 ↻ ⚠ 下 /loop 前，PR 的程式碼你要心裡有底——AI 照建議修，對不對還是你負責 35
36. // REAL CASE · 一個真實、已經 merged 的 PR 今天講的每一步，都在這個 PR 上跑過一遍 >_ 整支 PR 的程式碼 100% 由 AI 撰寫——人類只在頭尾各介入一次。 >_ 題目是 OAuth redirect_uri 驗證——安全邊界，改錯就是開放重定向 36
37. // GATE 1 + AI BUILD · 開頭對齊，中間交給 AI 開頭寫一份 plan.md，其餘交給 AI 人 · 開頭那一關 寫 plan.md（commit 在 repo 根目錄） 定義目標與邊界，附一份「絕不可改動」清單——token endpoint 的 exact binding 名列其中，整個安全模型的底線先釘死。 AI · 中間全包 Claude Opus 4.8 via Claude Code，依 plan.md 執行 diff 中 17 個檔案全部由 AI 撰寫——含 OAuth 驗證器、matcher、 handler、模板、測試與文件。 >_ 方向對了，AI 才走得遠——plan 是這一切的源頭 37 PR AI Authorship
38. // THE LOOP · 中間的迭代迴圈，沒有人逐行介入 AI 自己 review、自己修，跑到沒問題 b823189 feat: origin-locked path-prefix matching /simplify + /code-review（9 角度對抗式）自己抓出並修掉 trailing-slash 正 規化的真實 bug df222d4 fix: allow IPv6-literal redirect URI patterns 回應 Codex review 留言而補上 770f3e0 fix: reject encoded slashes in patterns 回應 Codex review 留言而補上 codex ▸ 「Didn't find any major issues. Chef's kiss.」 >_ 三個 commit、兩輪修正——全在沒有人逐行 review 的情況下收斂 38 Codex review
39. // GATE 2 · 結尾最終把關 人類只剩最後一個動作——按下 Merge ✓ build ✓ unit + integration tests ✓ 3 e2e tests（含 origin-smuggling 對抗式） ✓ config test（flag default-off） ! codecov/patch · 84.81%（低於 target——唯一沒過的那一項） ✓ 22 of 23 checks passed appleboy merged 5862836 into main · 刪除分支 >_ 從 plan 到 merge，人只做了兩件事：對齊方向、最終把關。中間的開發、review、修錯、綠燈，全是 AI 的自動迴圈。 >_ go-authgate/authgate#249 · 這就是今天那條流程的完整證據 39
40. // THE COMMAND MAP · 一張圖看完整條流程 從 plan 到 merge，整條流程的指令地圖 人為把關 AI 主導 → ↺ AI 自動迭代迴圈 — 中間沒有人逐行介入 → → → → → >_ 人只在頭尾兩端把關，中間整條鏈交給 AI 一路跑到綠燈 40
41. SECTION · PM VI EW MANAGING ENGINE ERI N G P R OGR E SS // 給專案經理 · for the project manager 工程細節這麼多，PM 不可能全程參與—— 那要怎麼 Manage 所有進展？ 不是去追二十個步驟，而是守住兩個介入點——中間交給 AI 與看板自動流動。 01 開頭 · 對齊方向 建 Epic · 拆 Task · 寫驗收條件 02 結尾 · 最終把關 驗收成果 · 結案 Epic $ pm --intervene → 2 gates, not 20 steps 41
42. // PM VIEW · 用 Jira 追進度，不進開發流程 你的 Jira Epic + Task，由 AI 流程自動回寫狀態 smart commit $ git commit -m \ "feat(auth): 加入 OTP 驗證 PROJ-142 #code-review" ✓ Jira PROJ-142 → Code Review 01 Commit / PR 帶上 PROJ-142 這個 issue key 02 GitHub ↔ Jira 整合偵測事件，自動轉換卡片狀態 03 工程師、甚至 AI 都不必手動更新 Jira AI 認領 Task · 進入開發 Open AI 第一個 commit · 實作中 In Progress AI /pr-prepare 開 PR · copilot 迴圈 Code Review ↺ AI CI 跑自動化測試 Under Test AI CI 綠燈 · Merge · 自動部署 Resolved >_ PM 只在頭尾兩端動 Jira，中間狀態由 AI 流程自己推著走 42
43. // THE BOARD · PM 看到的只是卡片在流動 一個 Epic 的所有 Task，看板自己往右走 BACKLOG 3 人 · PM 建立 OPEN 2 ↺ AI 自動 IN PROGRESS 2 ↺ AI 自動 CODE REVIEW 2 ↺ AI 自動 UNDER TEST 2 ↺ AI 自動 RESOLVED 2 ↺ AI 自動 CLOSED 3 人 · PM 驗收 >_ PM 一整天不碰程式碼，瞄一眼看板就知道每張卡走到哪 43
44. // THE PROBLEM · 卡片不會自己動 看板會自己往右走——但那一步，工程師到底要做什麼？ 七個 Stage 看起來很順，但每個工程師的分支策略、commit 顆粒度、開 PR 與 CI 的節奏都不一樣。要讓卡片精準 對上「我現在做到哪一步」 ，得先面對三個很實際的痛點。 01 狀態對映對不齊 七個欄位要對上每個人不同的工作流，靠口頭 約定，到底哪個 commit 算進了 Code Review？永遠對不齊。 02 手動更新太繁瑣 一天幾十次狀態變更，沒人想一直回 Jira 拖卡 片。一忘記更新，看板立刻和真實進度失真。 03 規則寫死很脆弱 把流程硬編成固定腳本，換一個 repo、換一套 分支策略，寫死的自動化就壞給你看。 >_ 不是「記得去更新看板」 ，而是讓開發行為本身就觸發狀態轉換 44
45. // THE SOLUTION · 讓 CI 幫你移卡片 你只管開發，CI 自動把卡片移到對應 Stage 用 Gitea Action + appleboy/jira-action 監聽原生 Git 事件，由 Gitea 主動呼叫 Jira API 轉換狀態——不是靠人記 得更新看板，而是讓開發行為本身觸發。 .gitea/workflows/jira.yml on: [create, push, pull_request] uses: appleboy/jira-action with: transition: "Finish Coding" ref: <PR 標題 / commit 訊息> ✓ Jira PROJ-142 → Code Review 01 監聽原生 Git 事件：branch / push / pull request 02 由 Gitea 主動寫進 Jira，Jira 不需碰原始碼——安全又快 03 開發者只在 commit / PR 標題標上 PROJ-142 on: create 建立新分支開發 · 自動指派給你 → In Progress on: push commit 帶議題編號 · 議題自動留言 → In Progress PR: opened 開 PR 送審 · Finish Coding → Code Review PR: merged PR 合併 · Merge and Deploy · Fixed → Resolved >_ 團隊完全專注在開發流程，看板自己跟著真實進度走 45
46. // WRAP-UP · 今天的總結 用 AI 打造全新的 SDLC——但真正撐起它的，是後面完整的 CI/CD 「完整的 CI/CD」是過去我們很少真正做到的事——測試、review、修綠燈、文件、看板，總有環節被犧牲。藉由 AI 的協助， 每一格缺口都被補上，CI/CD 比以前任何時候都更完整。 以前的缺口 AI 補完之後 自動化測試常被犧牲 常略過 → ✓ AI 補齊 Code Review 人力不足被省略 常省略 → ✓ 自動 review CI 紅燈卡很久沒人修 卡很久 → ✓ 修到綠燈 文件 / commit / PR 隨便寫 不一致 → ✓ 規格化 看板 / 狀態靠人手動更新 易漏更 → ✓ 自動回寫 // 人類只守頭尾兩關 開頭 對齊方向 結尾 最終把關 >_ 中間整條 pipeline，交給 AI 跑完 >_ 謝謝大家——讓 AI 把 CI/CD 跑到綠燈 46
47. END OF WORKSHOP THANK YOU // 謝謝大家參與這場 Workshop 謝謝大家。 回去之後，請想想——該怎麼用 AI 改善你團隊的 SDLC 流程？ $ improve-your-sdlc --with ai → start with one gap 47