AI 原生 SDLC 怎麼落地：代碼變快以後，工程師該重做哪條流程

大家好,我是為什麼叫QQ? 一個很常見的場面 Agent在夜裡接了一個任務 讀完倉庫,改完接口,補上頁面 然後連續提交十幾個PR 第二天早上,代碼已經躺在代審列表裡 但沒有人急著合併 產品同學要確認它有沒有偏離需求 測試要判斷關鍵路徑有沒有漏 安全同學要看權限和數據邊界 值班工程師還得知道出了問題怎麼回退 這就是AI原生開發要解決的起點 它要處理的是團隊能否把這些候選改動 穩定地變成上線後仍然可信的功能 代碼出現只是一次生成 真正的交付從有人準備點下 合併按鈕時才開始變得複雜 AI原生SDLC是一套圍繞 Agent重寫的軟件交付流程 人和Agent從需求開始協作 經過設計實現測試部署和維護 每一步留下可追溯的輸入和輸出 關鍵風險仍由人判斷 Anthropic將這條鏈路概括為Plan Design Build, Test, Deploy, Maintain六個階段 並為各階段保存意圖規格計劃測試和事故記錄 重點在於讓工作流本身能被Agent讀取 執行和驗證 你把需求寫清楚 Agent才能計劃 你把驗收條件寫清楚 測試才能判斷 你把生產信號接回來 下一次任務纔有一句 模型只是執行層 流程纔是系統的骨架 很多人現在的使用方式 還是把AI當作一個更聰明的代碼補全工具 寫函數時問一句 報錯時貼日誌評審時讓他解釋一段代碼 這當然有價值 但它沒有改變軟件交付的主要結構 AI原生SDLC再往前走了一步 讓Agent參與一個有邊界的任務閉環 讀規格提出計劃在受限環境裡修改 運行檢查提交證據 等待人或規則批准 兩種方式的差別落在責任交接上 助手給的是建議工程師 自己把建議帶進流程 流程成員要對明確的輸入 產出明確的工件 你可以查看他使用的上下文改了哪些文件 跑了哪些測試在哪一步失敗 任務變得可觀察 團隊纔有條件逐步把更多執行工作交出去 AI原生流程依賴幾份很樸素的工程工件 intent.md記錄這次要解決的用戶問題和邊界 spec.md寫輸入輸出約束和驗收條件 plan.md列出準備修改的模塊和執行順序 測試結果部署記錄和事故復盤則留在後面 成為下一次任務的上下文 這些文件不需要長 一個退款入口的一圖可以只寫清決策權限 金額上限審計要求密等語意和回滾方式 Agent有了這些約束 就少靠猜測補全業務邏輯 評審者也能直接對照需求查看改動 文檔在這裡記錄決策不重複代碼 它讓人和Agent站在同一份事實之上工作 GitLab提出過一個很實用的衡量單位 叫被接受的變更 它指的是改動經過環境準備 自動檢查人工複合上限觀察和責任確認後 被團隊接受進入系統這個說法 能幫我們校準目標 用戶不為PR數量付費 業務也不為代碼行數付費 大家需要的是可靠的解決一個問題 因此AI原生SDLC的總成本包括需求澄清 生成環境驗證評審修復治理和維護 代碼生成只是其中一項 而且正在變得更便宜 團隊若只盯住生成速度 很容易忽略後面那些耗時更久 出問題代價更高的環節 後面要講的案例都會落回這條成本鏈 編碼速度上來以後 軟件交付不會自動按同樣比例提速 Agent可以並行處理多個任務 CI執行器測試環境人類 評審和發佈窗口卻有固定容量 生成端一旦跑得比驗證端快 代審PR代跑測試和代確認的風險就會開始排隊 更麻煩的是 速度會同時放大好需求和壞需求 原先一個含糊需求需要幾天才會造成反攻 現在它可能在半天內變成一批看似完整的改動 團隊沒有在前面寫清業務語意 也沒有在後面把正確性寫進測試 生成能力越強錯誤積累的越快 AI原生SDLC的價值 就在於給這種速度加上可驗證的約束 Amplitude在公開復盤中提到 接入AI開發工作流六個月後 PR數量提高到原來的三倍 PR週期從5.2小時降到44分鐘 前端CI也從約30分鐘縮短到3至4分鐘 閱讀bug報告從715降到319 這些數字來自公司字數 團隊正在擴容整條交付管線 候選改動增加驗證和評審馬上會頂在前面 CI沒有提速模型就會等 預覽環境沒準備好 產品和設計就無法盡早確認行為 所有改動都進同一條審批對列 低風險任務也會拖慢高風險任務 AI給了團隊更大的進水量 流程得有足夠大的出水口 Stripe介紹過內部的Minions系統 這些Agent每週產生並合併超過 1000個完全由Agent編寫的PR 但仍由人類評審 他們運行在隔離且預熱的開發環境中 確定性執行GitLint測試 還能從300多萬項測試中 選擇與改動相關的檢查 隔離環境減少任務互相污染 預熱減少啟動等待 大規模測試庫提供驗證素材 相關性選擇控制執行時間 人類評審保留業務判斷 基礎設施不足時 批量提交會把團隊帶進反攻和排隊 Stripe的經驗說得很直白 高吞吐的Agent背後 站著一套高吞吐的環境測試和審查系統 Spotify的Hunk已生成超過 1500個合併到生產環境的PR 部分遷移任務節省了60%到90%的時間 他們也記錄了限制 上下文不完整時 Agent會交出無法合併的結果 代碼庫缺少統一標準時 同類錯誤會反復出現 缺少自動化測試的區域 驗證仍要回到業務團隊手裡 遺留系統帶著歷史概念 分散在多個倉庫 舊接口還被邊緣服務調用 文檔和線上狀態有偏差 報警規則也許幾年沒人動過 Agent能替你做重複勞動 卻無法補上團隊沒有結構化記錄的知識 Spotify的實踐提醒我們 上下文工程和反饋回錄屬於流程能力 模型參數無法替代 把幾家公司的經驗放在一起 能看到AI原生開發最常碰到的四個瓶頸 需求不清楚時 Agent會高效實現錯誤目標 驗證不足時通過編譯的 代碼也無法證明業務正確 環境和上下文混亂時 任務匯卡在依賴權限和歷史約定裡 治理缺位時團隊無法放心 讓Agent接觸高風險操作 這些瓶頸來自軟件系統 也來自組織怎樣保存知識和分配責任 好消息是這些工作都可以被工程化 你不必一開始建設一套龐大平臺 可以先從一條任務鏈開始 逐步補足規格上下文驗證和權限 接下來我們按這個順序講具體做法 每次交給Agent的任務 都先從一份足夠短的意圖說明開始 它要回答五件事 要服務使用戶在什麼場景遇到問題 改動允許碰哪些模塊 哪些行為絕對不能發生 怎樣算任務完成 這裡的驗收標準要能被測試或人工觀察 不要直寫體驗更好性能更高這類詞 比如優化推款流程太寬 你可以改成 運營角色可在30天內發起推款 金額不得超過原支付金額 重複請求只能生效一次 所有操作要寫審計日誌失敗時提示人工處理 這樣Agent才能據此規劃接口數據和測試 評審者也有一把明確的尺子 意圖質量決定了生成的起點 別急著讓Agent直接改倉庫 讓他先交一個計劃 他認為哪些服務會受影響準備改哪些文件 依賴哪些接口打算跑哪些檢查最大風險在哪裡 計劃偏了工程師用幾分鐘就能拉回 代碼改完才發現方向錯清理成本會高得多 Plan階段的價值 就是把昂貴的反攻提前到最便宜的時候 團隊可以把計劃當成一次輕量設計評審 對於小改動計劃可能只有十幾行 涉及數據遷移權限變更或跨服務協議時 計劃應該補上灰度方式和回滾步驟 Anthropic by Plan和Design放在Build之前 理由也在這裡 先讓意圖設計和執行範圍對齊 再讓Agent進入高速度的生成階段 Agent做不好 常常因為他拿不到判斷所需的上下文 工程團隊要把最有價值的信息 從聊天記錄和個人記憶裡拿出來 放進能檢索能更新能引用的地方 包括服務邊界接口契約領域詞彙代碼 規範依賴關係和安全規則 實踐中可以從一個服務地圖開始 這個服務依賴誰 哪些API對外承諾兼容 核心數據怎麼流 哪些測試覆蓋關鍵路徑 哪個團隊負責 再把倉庫級規則寫進固定文件 讓Agent每次執行都能讀取 Spotify提到的上下文不完整問題 靠的就是這類基礎工作環節 你不需要讓模型記住全部歷史 但要讓它在任務發生時找到關鍵事實 Agent需要的上下文還包括環境 依賴版本啟動腳本測試數據 臨時憑證模擬服務日誌入口和網絡限制 最好能用代碼或配置付現出來 否則Agent可能在本地跑通一份偶然成立的結果 到了CI或生產預覽環境又失敗 環境隔離同樣重要 每個任務儘量在獨立工作區和短視憑證裡運行 避免多個Agent覆蓋同一份狀態 也避免測試意外訪問真實數據 Stripe的Minions採用隔離預熱環境 正是在壓低這類啟動與幹擾成本 先讓一次任務可以穩定復跑 再談同時跑100個任務 可付現性是規模化自動化的最低門檻 Agent很擅長寫出像樣的實現 也能補一批表面完整的測試 團隊要在更早的位置定義正確性 尤其是業務不變量 訂單金額不能重複扣 租戶之間不能互相讀取數據 庫存不能變成負數 遷移前後關鍵字段要保持一致 把這類規則落進單元測試 契約測試集成測試或端到端測試還要分層 改一個純函數時快速單元測試就夠 改一個服務接口時需要驗證契約 觸及支付權限數據遷移時 再加完整鏈路和人工批准 這樣既能給低風險改動快反饋 也不會因為每次都跑全量測試拖垮CI 驗證能力決定了團隊能放多快的 讓Agent的前進 AI原生CI要讓每個PR獲得與風險匹配的證據 系統可以根據改動文件依賴範圍和標籤 選擇不同檢查路徑 文案和樣式改動走快速檢查 公共API變化跑契約測試 支付權限刪除和數據遷移再進入更嚴格的對列 並要求部署前的人工確認 你還要盯住排隊時間 CI的排隊時間失敗 重跑和測試穩定性 都會影響Agent的有效吞吐 Amplitude把前端CI從約30分鐘壓到3-4分鐘 說明流程優化本身能釋放大量生成能力 模型提交的再快 也繞不過一個慢到讓所有任務排隊的驗證系統 評審方式也該更新 Agent的產出的PR可能更長更密集 逐行讀完每個改動並不經濟 一個可評審的PR應該自帶證據 它關聯哪條意圖和規格影響了哪些接口 跑過哪些測試哪些檢查還沒有覆蓋 風險等級如何如何發布 出了問題怎樣回滾 評審者先看這些信息再進入真正需要判斷的差異 低風險任務可以由規則和抽樣評審覆蓋 高風險任務需要業務負責人 安全負責人或資深工程師參與 這種分級把人的注意力放在機器難以確認的業務例外 跨系統影響和責任邊界上 人類評審沒有推出流程 它從代碼朗讀轉向證據判斷和風險批准 在AI原生SDLC裡 模型能力和執行權限必須分開看 Agent可以有讀取倉庫 運行測試創建草稿PR的權限 合併主幹修改基礎設施訪問生產數據 觸發支付操作則應該放在更嚴格的規則下面 權限越高所需的日製審批和回滾能力就越強 Antropic的安全實踐提到確定性檢查Agent的審查 權限隔離和重要節點的人類門控 把這套思路放到普通團隊裡就是最小權限 短時憑證完整審計和高風險人工批准 每一次工具調用都應該留下誰發起 做了什麼依據是什麼結果如何的記錄 出了問題團隊據此復盤並修正規則 也能還原模型當時的輸入和動作 部署完成後任務還沒有結束 用戶行為錯誤率延遲 業務指標告警和事故復盤 都會告訴團隊這次改動的假設是否成立 AI原生SDLC需要把這些生產信號回寫到規格 測試和知識庫中 下次Agent接到類似任務時 也能讀取系統在真實流量中的反饋 舉個例子 退款入口上線後除了看接口成功率 還要觀察重複請求人工介入比例和異常金額 如果發生一次重複退款事故 修復代碼只是第一步 更重要的是補上密等測試調整審批條件 更新任務模板 Spotify強調反饋循環 因為維護階段會影響後續開發質量 閉環跑起來自動化才會越用越穩 推動這套流程時 別拿代碼行數或PR數量當核心成績 更有參考價值的是 一項變更從提出到被接受需要多久 CI和評審各等了多久 線上缺陷和回滾率有沒有變化 高風險任務的證據是否完整 GitLab所說的每個被接受變更的成本 可以作為團隊討論效率時的共同單位 落地時從一個邊界清除 測試叫全回滾容易的任務類型開始 例如依賴升級靜態規則修復 穩當同步或低風險遷移 連續跑幾週記錄 Agent缺了哪些上下文 哪些檢查最常失敗 評審者把時間花在哪裡 試點的目的是用真實任務找出 下一筆基礎設施投資該放在哪裡 現在再回頭看開場那一批PR問題已經具體了 團隊不該只問Agent寫得快不快 還要問他收到的意圖夠不夠清楚 計劃有沒有過審 環境能否復現 測試能否證明關鍵行為 PR是否帶著足夠證據 全線和上線回滾是否受控 生產信號會不會回到下一輪任務 AI原生SDLC的目標是讓Agent在一個能學習 能驗證能追責的流程裡工作 這樣工程師才能把時間從重複實現中騰出來 放在定義問題設置約束判斷風險和改進系統上 你所在團隊最先賭注Agent的環節是什麼 需求上下文CI測試評審還是上線後的反饋 把答案留在評論區 也可以當成你們下一次流程改造的起點 如果覺得本期內容不錯 可以一鍵三連 我是為什麼叫QQ 我們下期見