AI agent 接手寫 code：團隊點重整 spec、review 同 CI/CD
由拆細需求、驗收閘口到人手問責，五個實際改法
iThome 報道嘅系列個案顯示，AI coding 已經由補全幾行 code，走到幫手拆需求、寫程式、跑測試同除錯。產出一快，原本排喺後段嘅 code review、安全掃描同部署批核就容易塞車。團隊亦會收到更多「測試過晒，但方向錯咗」嘅改動。對 startup、freelancer 同企業 IT team 嚟講，工具識寫幾多 code 固然重要，但點驗收、邊個負責，先至決定可唔可以放心上線。
Spec 要拆細，驗收條件要先定
iThome 報道嘅受訪個案曾經寫出一份約 5,000 行嘅大 spec，交畀 AI 一次過砌完整系統，結果出錯後好難追查。較穩陣嘅做法係按模組拆開，每張任務講清楚輸入、輸出、錯誤處理、權限限制、唔包咩範圍，同埋完成後要通過邊啲例子。每次改動細啲，工程師先容易睇得晒個 diff，亦較易追返係邊個改動出問題。
測試亦唔可以全部交畀同一個 agent 自問自答。佢一旦誤解需求，生成嘅 code 同測試可能沿用同一個錯誤假設，最後自然全部變綠。產品負責人或者工程師應該先審核驗收例子，重要功能再加獨立測試，包括權限邊界、失敗情況、資料遷移同回復舊版本。Agent 可以補大量測試案例，不過啲測試係咪真係驗到需求，仍然要由人判斷。
Code review 要按風險分流
當 agent 一晚開出十幾個 pull request，review 人手唔會跟住倍增。團隊可以限制每個 PR 嘅改動範圍，要求附上設計假設、實際跑過嘅測試、未解風險同 rollback 方法，再按影響分級。文件、測試補漏可以快線處理；登入、付款、權限、資料刪除同 database migration 就要指定資深工程師批核。**AI review 適合做第一層過濾，合併權仍然要落喺有名有姓嘅負責人手上。**GitHub 自家 coding agent 嘅安全設計同樣保留人手 review，agent 冇權自行批核或者合併 PR。
CI/CD 要變成硬閘，agent 權限亦要收窄
Lint、type check、單元測試、整合測試、端對端測試、secret scanning、dependency review 同靜態安全掃描，都應該喺合併前自動跑。高風險服務仲要有 staging、逐步推出、監察告警同一鍵 rollback。NIST 嘅 SSDF 一直強調保護開發環境、追蹤安全要求同設計決定，去到 agent 可以自行改檔、裝套件同執行指令，呢啲基本功只會更重要。Agent 最好困喺隔離環境，預設接觸唔到 production credential，網上存取同可寫入範圍亦按任務逐項開放。
生產力唔好淨係數生成咗幾多行
AI 工具廠商鍾意講接受率同完成速度，但呢兩個數字睇唔到 review 排隊、返工修正同上線事故。METR 喺 2025 年嘅隨機研究曾發現，熟悉大型開源項目嘅工程師用當時嘅 AI 工具後，完成任務慢咗 19%；佢哋到 2026 年更新研究時，原始數據開始見到加速跡象，不過參加者篩選同多 agent 同時運作令結果難以準確解讀。DORA 2025 報告亦指出，AI 會一併放大團隊本身嘅強項同弱點。較實際嘅指標包括交付時間、review 等候、逃過測試嘅 defect、回滾率、事故數量、token 與雲端成本。
工程師要守住架構、風險同責任
Agent 擅長處理邊界清楚、可以自動驗證嘅任務；架構取捨、模糊需求、跨系統故障、私隱要求、威脅模型同商業優先次序，仍然靠工程師掌握全局。團隊亦要避免初級工程師淨係按接受鍵，因為簡單實作全交晒畀 AI，佢哋會少咗學除錯同理解系統嘅機會。可以刻意安排佢哋審 diff、重現問題、寫驗收案例同解釋 agent 點解改，等技能成長跟得上工具速度。
實際引入時，可以先揀低風險 repository 或內部工具，保留 branch protection、指定每個 PR 嘅人手負責人，再連續比較交付速度、品質同成本。數據穩定後先逐步加大 agent 權限，會易控制過一開始就畀佢直入 production。
參考來源
- iThome — AI Coding掀起軟體開發革命 — original report
- AI 如何改寫開發流程？別只想寫完美 Spec — 提供大型 spec 失效、拆模組、測試同除錯個案，正文已清楚列明由 iThome 報道。
- 開發成本壓低後，工程師角色點改變 — 補充 code review、CI/CD、監察同工程師責任分工觀點。
- DORA State of AI-assisted Software Development 2025 — Google Cloud DORA 嘅研究入口，用嚟核實 AI 會放大團隊既有強項同弱點。
- METR：We are Changing our Developer Productivity Experiment Design — 交代 2025 生產力實驗結果、2026 更新數據同研究限制，避免將單一效率數字過度演繹。
- NIST Secure Software Development Framework — 核實安全開發環境、要求追蹤、軟件保護同持續改善等基本做法。
- GitHub Copilot cloud agent：Risks and mitigations — GitHub 官方列出 branch 限制、人手 review、權限同敏感資料風險等安全設計。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
