AI coding agent 能在幾小時內完成過去需要幾天的實作，不代表功能也能同樣快地進入 production。需求仍可能含糊，review queue 仍由人排隊處理，安全政策仍藏在文件裡，部署後的問題也不會自動變成下一輪測試。
這正是 AI Native SDLC 想處理的落差：不是在既有流程每一格加上一個 AI 按鈕，而是重新設計從意圖、實作、驗證到生產回饋的整條價值流。
Google、OpenAI、Anthropic 與 LangChain 最近分別從開發範式、團隊分工、企業流程與 Agent 產品生命週期切入。四份材料並不是同一套標準，也都帶有供應商立場；但把它們交叉閱讀，可以看出幾個比產品功能更穩定的共同方向。
加速實作，只會把瓶頸往兩側推
Google 的《The New SDLC with Vibe Coding》把 AI-assisted development 放在一條從 vibe coding 到 agentic engineering 的光譜上。差別不在有沒有使用模型，而在輸出周圍有多少規格、context、測試、限制與人工判斷。
Anthropic 的 AI-Native SDLC Playbook則直接指出：當 build 階段縮短後，plan、review／test 與 deploy 仍以人的速度運作，新的瓶頸就出現在實作之前與之後。若安全團隊與 review 能力沒有同步擴張，結果不是變更塞車，就是程式碼在較少檢查下進入 production。
因此，程式碼行數、Agent 完成次數或 PR 數量都不是好指標。真正該問的是：一個意圖到達可驗證、可部署的結果要多久？中間返工幾次？需要多少人工注意力？部署後又增加多少維護成本？
四份材料各自補上一塊
這四個來源的重點可以分成四個層次：
| 來源 | 主要問題 | 提出的工程重點 |
|---|---|---|
| 如何從臨時 prompting 走向 production engineering | context、harness、驗證與依風險調整自治程度 | |
| OpenAI | 工程團隊如何重新分配人機責任 | Delegate、Review、Own，以及把 Agent 用到完整 SDLC |
| Anthropic | 企業流程如何讓 Agent 接續工作並留下稽核軌跡 | 版本化制品、Skills、hooks、approval gates 與回饋閉環 |
| LangChain | Agent 產品如何反覆發布並改善 | Build、Test、Deploy、Monitor，以及 eval、trace 與治理 |
OpenAI 的 Building an AI-native engineering team把工作分成 Delegate、Review 與 Own。Agent 可以先做範圍清楚、可驗證的分析與實作；人負責檢查完整性；產品意圖、核心架構、風險接受與 production 責任仍必須有人擁有。這比籠統地說「human in the loop」更具體，因為它要求團隊說清楚人究竟在哪裡作判斷。
Anthropic 則把每個階段的輸出變成下一階段可讀的版本化制品：intent.md、spec、plan、程式碼與測試、PR 與審查紀錄，再到 production 事件。檔名不是重點；重點是意圖不只存在會議或聊天記錄裡，而且每次轉換都有可追溯輸入、產物與核准者。
LangChain 的 Agent Development Lifecycle處理的是另一種情況：正在開發的產品本身就是 Agent。它把流程整理成 Build → Test → Deploy → Monitor，並讓 production trace 回到下一輪資料集與 eval。傳統監控只能告訴你服務有沒有回傳錯誤；Agent 監控還要回答它是否用了正確工具、遵循必要步驟、取得正確 context，並真的完成任務。
新的主線是可接續的制品鏈
當自然語言成為主要輸入，意圖就不能只是一句「幫我做好」。一個能被 Agent 與人共同使用的最小意圖，至少要說明：
- 要改變哪個可觀察結果；
- 誰受到影響，以及為什麼值得做；
- 哪些限制、風險與非目標必須保留；
- 什麼證據能證明結果可接受。
接下來的 spec 與 plan 不是為了增加文件，而是要在大量程式碼產生前，先暴露依賴、架構衝突、安全邊界與驗證方式。此時修正方向通常比 review 一個巨大 diff 便宜。
@shao__meng 的原始貼文以 Anthropic 的 AI-Native SDLC 為線索，將這個轉換整理成一條 artifact chain。把它落到 repository 時，可先收斂成六個可追溯階段，而不是為每個階段另建一套 Agent：
| 階段 | 下一階段必須接收到的制品 | 最小驗證 |
|---|---|---|
| Intent | 目標、非目標、風險與接受條件 | 需求擁有者確認問題沒有被改義 |
| Spec | 可觀察行為、介面與邊界條件 | 以案例或 acceptance criteria 消除歧義 |
| Plan | 受影響模組、依賴、遷移與驗證命令 | 在動工前檢查範圍與高風險決策 |
| Build | 最小 diff、測試與變更說明 | 靜態檢查與單元／整合測試通過 |
| Review | 意圖、計畫、diff 與證據的對照 | 獨立 reviewer 核對偏離是否被說明 |
| Operate | 部署紀錄、指標、事故與使用者回饋 | production 訊號回寫成 issue、測試或下一輪 Intent |
六階段不是 Anthropic 產品的固定 API，也不是每個小改動都要填滿六份文件；它是一個責任檢查表。文件或結構化資料的具體名稱可沿用團隊既有慣例。重點是任何人或 Agent 都能回答：這個 diff 要解決什麼、憑什麼通過、上線後由什麼訊號證明它仍然正確。這與 Anthropic 對長時間 Agent harness 的建議一致：讓新 session 從明確進度、版本歷史與可執行驗證接手，而不是只依賴上一段對話。Effective harnesses for long-running agents
<defs>
<marker id="sdlc-arr" viewBox="0 0 10 10" refX="6" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
<path d="M 0 1 L 8 5 L 0 9 z" fill="#58a6ff"/>
</marker>
</defs>
<rect x="10" y="25" width="75" height="36" rx="4" fill="#1f242c" stroke="#58a6ff"/>
<text x="47" y="48" fill="#58a6ff" font-size="11" font-weight="700" text-anchor="middle">Intent</text>
<path d="M 85 43 L 105 43" stroke="#58a6ff" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="105" y="25" width="75" height="36" rx="4" fill="#161b22" stroke="#388bfd"/>
<text x="142" y="48" fill="#58a6ff" font-size="11" font-weight="700" text-anchor="middle">Spec</text>
<path d="M 180 43 L 200 43" stroke="#58a6ff" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="200" y="25" width="75" height="36" rx="4" fill="#241b35" stroke="#bc8cff"/>
<text x="237" y="48" fill="#d2a8ff" font-size="11" font-weight="700" text-anchor="middle">Plan</text>
<path d="M 275 43 L 295 43" stroke="#bc8cff" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="295" y="25" width="75" height="36" rx="4" fill="#1b2e23" stroke="#238636"/>
<text x="332" y="48" fill="#3fb950" font-size="11" font-weight="700" text-anchor="middle">Build</text>
<path d="M 370 43 L 390 43" stroke="#3fb950" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="390" y="25" width="75" height="36" rx="4" fill="#1b2e23" stroke="#238636"/>
<text x="427" y="48" fill="#3fb950" font-size="11" font-weight="700" text-anchor="middle">Verify</text>
<path d="M 465 43 L 485 43" stroke="#3fb950" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="485" y="25" width="75" height="36" rx="4" fill="#161b22" stroke="#d29922"/>
<text x="522" y="48" fill="#e3b341" font-size="11" font-weight="700" text-anchor="middle">Review</text>
<path d="M 560 43 L 580 43" stroke="#d29922" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="580" y="25" width="80" height="36" rx="4" fill="#2d1d24" stroke="#da3633"/>
<text x="620" y="48" fill="#f85149" font-size="11" font-weight="700" text-anchor="middle">Deploy</text>
<path d="M 660 43 L 685 43" stroke="#da3633" stroke-width="1.5" marker-end="url(#sdlc-arr)"/>
<rect x="685" y="25" width="95" height="36" rx="4" fill="#161b22" stroke="#8b949e"/>
<text x="732" y="48" fill="#c9d1d9" font-size="11" font-weight="700" text-anchor="middle">Observe</text>
<path d="M 732 61 L 732 95 L 47 95 L 47 61" fill="none" stroke="#3fb950" stroke-width="1.5" stroke-dasharray="4 2" marker-end="url(#sdlc-arr)"/>
<text x="390" y="90" fill="#3fb950" font-size="10" font-weight="700" text-anchor="middle">事故、回饋、指標 ➔ 持續注入下一輪 Intent 閉環</text>這條鏈也改變 code review 的問題。Reviewer 不只檢查語法與局部實作，而是比較「原始意圖、接受的計畫、實際 diff 與驗證證據」是否一致。若實作偏離計畫，偏離本身就應被說明，而不是讓 reviewer 從程式碼反推原因。
大型現代化要先決定正確的證據
Anthropic 的兩位 Forward Deployed Engineer 在 2026 年 9 月 23 日發表的程式現代化準備指南，把這條責任鏈帶進大型舊系統專案。@shao__meng 的貼文整理了指南的六步準備法；其中最值得先做的，是在 Agent 開始改檔前，讓所有人同意「目標是什麼、什麼證據算通過、通過後由誰核准」。
先選定現代化的目標
指南將現代化分成三種。分類方式會改變驗收基準，不能等到看到 diff 才決定：
- Uplift：保留技術棧，只升級版本，例如把已停止維護的 runtime 升級到受支援版本。原有測試通常可以作為主要基準。
- Transform：改用另一種技術棧，但保留既有行為，例如 COBOL 遷移到 Java。除了測試，還需要重播流量、比對新舊輸出，或讓新舊系統並行運作。
- Reimagine：更換技術棧，也改變系統行為。團隊必須先寫下並確認行為規格，再由規格建立測試；規格未說清楚的地方會成為待決策事項，不能交給 Agent 默默補完。
如果團隊沒有先選定路徑，生產負責人可能期待行為不變，熟悉舊系統的人卻期待順便清掉技術債，業務方又加入新需求。這些差異最後會變成「這項變更到底算不算正確」的審查爭論。先定義範圍會增加啟動成本，卻能避免把需求協商藏進每個變更裡。
把「完成」寫成每批變更都能攜帶的證據
指南把每項變更要通過的條件稱為 certificate。它不是密碼學憑證，也不是模型自評信心，而是一組可由工作流檢查的證據：原有與新增測試、覆蓋率門檻、效能界線、新舊輸出比對、持久化狀態與傳輸格式往返、安全掃描，以及預備環境中的錯誤率與延遲。不同專案只應選用與目標相符的檢查。
這份證據清單要和 reviewer、開發者、使用者代表及業務負責人一起定義。實際檢查點是：審查者是否願意依據這些證據接受變更？ 若舊系統缺少測試、流量回放或遙測，缺口本身就是現代化的前置工作；讓 Agent 快速產生更多 diff 不會補上這些證據。
讓核准速度跟上產出速度
機器檢查通過只代表變更達到約定條件，並不表示每種風險都能自動合併。指南建議預先設定晉升策略：按影響範圍與 Agent 信心分級，關鍵路徑保留完整人工審查，並把領域專家的時間留給高風險或被標記的決策。專家應在流程設計時參與 certificate 與輸出格式；若相同問題反覆出現，就修正工作流或檢查條件，別要求 reviewer 每次手動攔截同一類錯誤。
試跑也要涵蓋完整核准與部署路徑，而不只是確認 Agent 能改程式。先挑一個小分區端到端執行，準備足夠的測試與預備環境，限制 Agent 只能寫入現代化分支且不提供 production 存取憑證，並將 Agent 工作紀錄連到 PR 和檢查證據。只有當團隊能用這些證據完成核准，才有條件擴大批次。這是把人從逐行檢查中釋放出來的方式；風險接受與 production 責任仍要由組織明確承擔。
普通軟體需要 tests，Agent 產品還需要 evals
一般軟體的核心行為多半可以用確定性測試描述：給定輸入後，輸出與狀態是否正確。Agent 產品除了最終答案，還有非確定性的執行路徑；同一任務可能有多種合理結果，也可能在回傳 HTTP 200 時選錯工具或跳過審批。
因此 LangChain 建議先用少量代表性任務建立資料集，在發布前比較 prompt、model、retrieval、tool schema 與 workflow；上線後再從 trace、人工回饋與已知失敗補強資料集。多輪 Agent 還需要模擬完整互動，而不只測單次回答。
不論普通軟體或 Agent 產品，都不該讓同一個生成者成為唯一驗證者。可執行測試、CI gate、獨立 review 與 production observation 各自提供不同證據；生成速度愈快，這些回饋面愈重要。
建議性知識與強制性控制要分開
Anthropic 的 playbook 區分了 Skills 與 hooks。Skill 告訴 Agent 應該怎麼完成安全審查、API 設計或發布流程；hook、sandbox、CI、身份系統與 branch protection 則限制它不能做什麼。
這個邊界不能只靠 Prompt 取代。不可讀取的憑證、不可修改的路徑、受限網路、production 部署核准與 audit log，都需要由模型之外的系統執行。Agent 可以準備變更、執行測試與提出部署建議，但高風險動作是否被授權，不能由同一個模型自行決定。
先修一條真實工作流，不必重做整家公司
AI Native SDLC 不需要一次建立多 Agent 平台。最小起點可以是一類低風險、常重複而且已有驗證方式的工作，例如文件更新、小型 bug fix 或依賴維護：
- 把目標、限制與驗收條件寫成可版本控制的輸入。
- 讓 Agent 先提交 plan，再依 plan 實作並執行既有 checks。
- 只允許它建立 branch 或 PR，不直接跨越 production gate。
- 記錄人工修改、失敗原因與 review 等待時間。
- 把重複失敗變成測試、規則或新的工作項目。
這個切片若不能降低從意圖到可接受變更的時間，就先修 context、驗證或流程，不要急著增加 Agent 數量。並行只會增加在制品；真正的吞吐量仍受限於團隊能可靠驗證多少結果。
AI Native SDLC 的成熟度，不在於 Agent 能寫多少程式碼，而在於它出錯時，團隊能否及時發現、限制影響、追溯原因，並把同類失敗轉成下一輪不再重複的工程證據。若把這條流程往 AI 研發上游延伸，問題還包括模型能否選擇研究方向、驗證證據並建造後繼模型；可接著讀AI 能自己打造下一代嗎？遞迴自我改進的四道門檻。