一次故障歸因會后所有人都沉默了上個月我們做了一件事把過去半年的線上故障拉出來做了個完整歸因。結(jié)果出來的那天會議室里安靜了好幾秒。不是故障數(shù)量有多嚇人。說實話故障數(shù)跟去年同期比差不多甚至還略少一點。但有一個數(shù)字讓所有人都坐不住了。那 60% 的 bug都能追溯到同一種錯誤模式。同一種。放在以前這是不可能的。十個開發(fā)十種寫法你就算想犯一樣的錯都難。張三漏判空值是張三的風(fēng)格李四忘加事務(wù)是李四的習(xí)慣各有各的坑。修一個是一個不會批量傳染。但現(xiàn)在不一樣了。自從團隊全面用上 AI Coding 之后代碼產(chǎn)出速度翻了兩三倍功能上線快了很多。但 bug 也變了。它們不再是零散的、個人化的而是成體系的、批量化的。AI 喜歡復(fù)用歷史模式代碼庫里怎么寫的它就學(xué)一個不好的寫法沒被攔住它能又快又穩(wěn)地把錯的東西復(fù)制一千份。這才是真正讓人后背發(fā)涼的地方。以前你怕的是哪個地方又出了個問題現(xiàn)在你怕的是這個模式是不是在十個地方都埋了雷。這篇文章想聊的就是這件事。我們的訂單系統(tǒng)花了一年多做了三階段改造從穩(wěn)定性到模塊化都搞得差不多了按傳統(tǒng)研發(fā)的標準看已經(jīng)相當健康。結(jié)果 AI 一來整個研發(fā)流程都接不住了。然后我們是怎么把一套給人設(shè)計的研發(fā)流程重構(gòu)成一套給 AI 用的流水線的。先說說訂單系統(tǒng)這一年多都干了啥在聊 AI 之前得先鋪墊一下背景。訂單系統(tǒng)不是憑空冒出來的它已經(jīng)跑了好幾年前面還有三輪大的改造。這些改造打下的底子是后面所有事情的基礎(chǔ)。第一階段筑牢穩(wěn)定底線訂單系統(tǒng)是交易鏈路的核心命脈所有下單和支付行為都要經(jīng)過這里。它穩(wěn)不穩(wěn)直接關(guān)系到業(yè)務(wù)賺不賺錢。第一階段的目標很實在SLA 要做到 99.99%絕對不能跌單。怎么做到的梳理所有下游依賴搞了三級保障規(guī)范。什么意思呢就是把下游按重要程度分級核心的下游掛了怎么辦非核心的掛了能不能降級弱依賴的直接熔斷不影響主鏈路。這一步的核心思想是不能讓下游的抖動把主鏈路拖垮。做交易系統(tǒng)的都懂最怕的不是自己出問題是別人出問題把你帶崩了。第二階段剝離核心鏈路穩(wěn)定底線筑牢了接下來要做的是隔離。以支付節(jié)點為分界線把訂單創(chuàng)建、支付回調(diào)這些最核心的能力從老舊的大應(yīng)用里獨立拆出來單獨部署單獨保障。核心鏈路用獨立的機器、獨立的線程池、獨立的數(shù)據(jù)庫連接池跟非核心功能物理上隔開。為什么要這么做因為老應(yīng)用里什么都有運營后臺、數(shù)據(jù)報表、各種管理功能混在一起。哪天運營導(dǎo)個報表把數(shù)據(jù)庫打慢了核心下單也跟著受影響。拆出來之后核心鏈路有自己的資源池別人再怎么折騰也影響不到它。第三階段模塊化重構(gòu)鏈路前兩步做完系統(tǒng)穩(wěn)是穩(wěn)了但代碼還是一大坨。加個新功能要改好幾個地方牽一發(fā)動全身。所以第三階段是按業(yè)務(wù)語義重構(gòu)執(zhí)行序列把每個環(huán)節(jié)都做成模塊化分層再配齊全鏈路埋點。改哪個環(huán)節(jié)就動哪個模塊不會牽連其他地方。出了問題也能快速定位到是哪個環(huán)節(jié)出的。三階段走完訂單系統(tǒng)可以說脫胎換骨了。穩(wěn)定性有兜底核心鏈路有隔離架構(gòu)是模塊化的整條鏈路可觀測。按傳統(tǒng)研發(fā)的標準來看這已經(jīng)是一個相當健康的系統(tǒng)了。但 AI 來了。AI 來了之后舊流程為什么不夠用了前面三階段的改造解決的都是系統(tǒng)本身的問題。但 AI Coding 普及之后問題不在系統(tǒng)里而在寫代碼的過程里了。我們遇到的挑戰(zhàn)總結(jié)下來有這么幾個。錯誤模式變了以前出問題大多是個人手誤。張三漏判了一個空值李四忘記加事務(wù)。這類問題有個特點零散不成規(guī)模。修一個是一個不會批量傳染。AI 來了之后不一樣。AI 喜歡復(fù)用歷史模式你代碼庫里以前怎么寫的它就學(xué)怎么寫。如果歷史代碼里有一個不好的寫法AI 會在十個新功能里把這個寫法復(fù)制十遍。錯誤從個人手誤變成了系統(tǒng)性偏差。一個錯誤模式?jīng)]被及時攔住能在代碼庫里開花結(jié)果。知識是散的AI 看不見每個團隊都有自己的規(guī)約和最佳實踐。有的寫在 confluence 上有的寫在某個 README 里有的藏在老員工腦子里還有的就是大家默認這么寫但誰也沒寫下來過。對人來說這些規(guī)約是活的。新人來了看代碼問同事慢慢也就學(xué)會了。但對 AI 來說規(guī)約散落在各處就等于沒有。你不主動喂給它它就是看不見。團隊積累了好幾年的知識AI 根本不知道存在。代碼量和審查力的失衡這個最直觀。AI 讓每個人的產(chǎn)出速度提高了兩三倍代碼變更量是以前的好幾倍。但 CR 的人還是那些人時間還是那么多。以前一個 PR 改 300 行認真看半小時能看完?，F(xiàn)在一個 PR 改 1000 行AI 生成的代碼看起來還都挺合理的。你怎么辦逐行看時間不夠大概掃一眼又怕漏東西。缺陷逃逸的風(fēng)險被放大了。故障回溯變難了以前出了問題git blame 找到寫代碼的人問一句當時怎么想的大概就能定位根因?，F(xiàn)在不一樣了。代碼是人跟 AI 一起寫的。出了問題你去問寫代碼的人他可能也說不清楚當時是 AI 生成的他覺得沒問題就合了。根因到底是知識庫沒覆蓋到還是 skill 寫得有問題還是 prompt 沒說清楚還是規(guī)約本身就寫錯了一團漿糊。單點提效整體熵增這是最隱蔽也最要命的一個問題。AI 把編碼這一步變快了但前后的步驟沒變快。需求澄清還是那么慢方案設(shè)計還是那么慢測試和上線也還是那么慢。編碼變快之后各階段之間的信息折損反而變大了。需求沒說清楚AI 就開寫寫出來一堆不對的東西返工的時間比省下來的還多。整條鏈路的熵不是在減少而是在增加。你會發(fā)現(xiàn)這些問題的根源都不是AI 不會寫代碼。AI 寫代碼的能力其實挺強的。問題在于我們的整個研發(fā)流程還是按人理解人的模式設(shè)計的。需求文檔是寫給人看的CR 是人與人之間的審查故障復(fù)盤也是人與人之間的溝通。要讓 AI 真正穩(wěn)定地產(chǎn)出高質(zhì)量代碼不能只盯著 AI 本身要改的是它工作的流水線。我們做的事情說起來也簡單就是把整個研發(fā)流程重構(gòu)成了五道標準化的關(guān)口。每一道關(guān)口解決一類問題把風(fēng)險擋在源頭。下面就一道一道說。第一道關(guān)口需求澄清把方向釘死很多人覺得寫代碼的第一步是打開 IDE。其實不是。寫代碼的第一步是把需求搞清楚。在需求澄清這一步我們不產(chǎn)出任何代碼甚至不討論代碼。只做一件事讓業(yè)務(wù)意圖被精確地、結(jié)構(gòu)化地記錄下來。拿一個真實的例子來說出海下單支持禮品卡支付。禮品卡的金額等于禮品卡面值加上出海服務(wù)費。這個算錯了就是資損而且有一個跨環(huán)節(jié)的約束確認訂單和創(chuàng)建訂單兩處都要算禮品卡金額漏改一處就會出現(xiàn)確認時和下單時金額對不上。在需求澄清關(guān)口我們要釘死的就是兩件事算什么以及什么情況算錯了要阻斷。BDD 場景驅(qū)動驗收標準從第一天就是可執(zhí)行的傳統(tǒng)的需求文檔是給人看的文章。產(chǎn)品寫一篇 PRD開發(fā)讀完后猜要做什么測試再猜要測什么。兩次傳遞兩次折損。最后做出來的東西是不是產(chǎn)品想要的全靠溝通。我們不這么干。我們強制在需求階段就產(chǎn)出 Gherkin 場景用 Given-When-Then 的格式寫出來。這是需求和測試之間的硬契約機器可讀可執(zhí)行。放到出海禮品卡這個例子上場景是這樣寫的# 正常路徑 Scenario: 出海下單禮品卡金額計算正確 Given 出海下單選擇禮品卡支付面值 100 元出海服務(wù)費 10 元 When 用戶確認訂單 Then 禮品卡金額 110 元 # 異常邊界 Scenario: 禮品卡金額異常時阻斷下單 Given 禮品卡面值 服務(wù)費計算后金額 ≤ 0 When 用戶提交訂單 Then 阻斷下單并提示金額異常 And 不創(chuàng)建異常金額的訂單 # 優(yōu)先級標記 P0 Scenario: 確認訂單與創(chuàng)建訂單金額一致 ...每條場景都有優(yōu)先級P0 的必須通過才能發(fā)布。后面的 BDD 驗收 Agent 會把每條 Gherkin 場景一對一映射到 TDD 測試用例逐條驗收。需求、測試、實現(xiàn)三者一一對齊。不存在我以為是這樣的這種灰色地帶。統(tǒng)一模板禁止技術(shù)語言需求文檔最怕的是什么寫著寫著就開始討論技術(shù)實現(xiàn)了。產(chǎn)品說這里加個字段開發(fā)說那個接口要改聊著聊著需求和方案混在一起最后誰也說不清需求到底是什么。我們的 Spec 模板有六節(jié)是固定死的文檔基本信息業(yè)務(wù)目標與用戶價值核心業(yè)務(wù)流程邊界條件與異常場景業(yè)務(wù)規(guī)則與協(xié)作邊界優(yōu)先級與驗收方法每一節(jié)都要求用業(yè)務(wù)語言寫技術(shù)術(shù)語一律屏蔽。字段類型、表結(jié)構(gòu)、接口簽名、上下游系統(tǒng)名一律不許出現(xiàn)在需求文檔里。這些是技術(shù)方案階段的事提前說只會添亂。模板由獨立的子 Agent 渲染不注入主會話上下文保證產(chǎn)出格式穩(wěn)定一致。不會因為換了個人寫結(jié)構(gòu)就變了。結(jié)合知識庫做現(xiàn)狀對齊寫需求不能憑空寫得知道現(xiàn)狀是什么。需求澄清開始前插件會自動觸發(fā)知識庫查詢。傳入 PRD 里的業(yè)務(wù)場景關(guān)鍵詞從知識庫和代碼現(xiàn)狀里拉取一份現(xiàn)狀分析報告。這份報告是需求澄清的事實底座。它的作用有三個。第一避免憑印象描述現(xiàn)狀。AI 不會覺得某個功能現(xiàn)在是怎么工作的而是基于代碼和文檔的事實。第二避免新增能力和已有邏輯撞車。寫新需求前先知道這塊之前是怎么設(shè)計的別重復(fù)造輪子。第三澄清過程可回溯。每個判斷都能溯源到知識庫或代碼而不是拍腦袋。提問管理該問的問不該問的別瞎問需求澄清少不了問問題。但問問題也是有講究的。我們把問題分成三類該問的、不該問的、可以跳過的。該問的必須問清楚不該問的別浪費用戶時間可以跳過的就基于現(xiàn)有信息判斷后面再驗證。這個分類是怎么來的是從歷史對話里慢慢攢出來的。什么問題 AI 自己能解決什么問題必須問人積累多了就有規(guī)律了。需求澄清這道關(guān)口核心就是四件事。BDD 釘死驗收標準模板屏蔽技術(shù)語言知識庫兜住現(xiàn)狀提問管理把該問的問清楚。目的只有一個讓做什么和怎么算做完在起點就被精確記錄。方向不錯后面的努力才有意義。第二道關(guān)口技術(shù)方案不讓 AI 臨場發(fā)揮需求澄清把做什么釘死了技術(shù)方案這一步要回答的就是怎么改和算錯了怎么兜。核心思想一句話不讓 AI 在編碼時臨場發(fā)揮。所有設(shè)計決策在編碼之前就被鎖定。從整體架構(gòu)拆到五段式拿到需求 Spec 之后技術(shù)方案階段不會直接跳進代碼細節(jié)。先做自上而下的模塊拆解。第一步解析服務(wù)清單。從需求規(guī)格的整體架構(gòu)和跨服務(wù)總覽章節(jié)解析這次涉及哪些服務(wù)。第二步逐服務(wù)拆到模塊粒度。每個涉及的服務(wù)按場景拆解每個場景下面固定五個子部分。就是我們說的五段式場景詳細設(shè)計 ├── 模塊詳情五段式結(jié)構(gòu) │ ├── 目標這個模塊要達成什么 │ ├── 變更位置改哪個類、哪個方法 │ ├── 字段/配置變更加什么字段、改什么配置 │ ├── 構(gòu)建/處理邏輯核心處理流程 │ └── 阻斷/兜底行為異常時怎么處理 ├── 異常與邊界邊界條件清單 ├── 新增清單新增的類/方法/配置 └── 上下游協(xié)作表格形式 ├── 上游依賴項 ├── 下游影響項 ├── 是否需要對方改動 └── 聯(lián)合設(shè)計狀態(tài)為什么要拆這么細因為拆得越細后面編碼的時候 AI 就越不會跑偏。每一塊要做什么、改哪里、怎么處理異常都寫得明明白白。編碼就變成了按圖施工而不是自由創(chuàng)作。放到出海禮品卡的例子上五段式是這樣寫的。目標是計算禮品卡應(yīng)付金額變更位置是 GiftCardCalculator 類的 calcAmount 方法字段變更增加一個 overseasServiceFee 字段處理邏輯是面值加服務(wù)費阻斷行為是金額小于等于 0 時拋出異常。每個模塊都長這樣清清楚楚。從知識庫拉取模塊規(guī)約讓方案知道歷史光有模板還不夠方案設(shè)計得符合團隊已有的規(guī)約。出海禮品卡這個需求拉取知識庫的時候會命中一條關(guān)鍵的跨環(huán)節(jié)不變約束確認訂單要算禮品卡金額包含出海服務(wù)費創(chuàng)建訂單也要算兩處算法必須一致。命中的約束不會自動生效而是逐條讓用戶選擇納入還是明確排除。排除必須填理由理由在門禁階段會被強制復(fù)查防止有人為圖省事把關(guān)鍵約束排除了。納入的約束就作為場景詳細設(shè)計的輸入方案從一開始就長在規(guī)約上。而且這個關(guān)聯(lián)會像影子一樣跟到編碼和門禁階段入口拉了哪些規(guī)約出口就查哪些規(guī)約形成完整的證據(jù)鏈。CLI 不可用的時候怎么辦降級跳過但會在產(chǎn)物里明確標注。不會靜默漏掉也不會因為工具不可用就卡住整個流程。統(tǒng)一技術(shù)方案模板章節(jié)全部硬約束所有技術(shù)方案走統(tǒng)一模板五大核心章節(jié)固定順序。一、業(yè)務(wù)用例分析二、整體架構(gòu)三、場景詳細設(shè)計四、數(shù)據(jù)結(jié)構(gòu)設(shè)計五、穩(wěn)定性設(shè)計。穩(wěn)定性設(shè)計是第五章專門的一章。按三個維度展開可灰度、可監(jiān)控、可回滾。弱依賴模塊在這里補全熔斷和降級鏈路。除了層面二的穩(wěn)定性設(shè)計每個模塊詳情的第五段也要求寫阻斷/兜底行為。這是層面一的兜底。每個模塊必須明確具體動作是阻斷、降級還是用默認值不能只寫一句模糊的兜底處理。兩層兜底模塊層和全局層。小問題模塊自己兜大問題全局有預(yù)案。技術(shù)方案這道關(guān)口說白了就是一件事把所有設(shè)計決策前置。編碼之前就把怎么改、改哪里、異常怎么處理、用什么規(guī)約全部定死。編碼的時候就只剩一件事照方案寫代碼。第三道關(guān)口TDD 實施用測試卡住做完沒技術(shù)方案把怎么算鎖死后編碼就變純粹了。照方案翻譯成代碼再用 TDD 卡住做完沒。任務(wù)拆分每個任務(wù)都有獨立驗證點技術(shù)方案先要被拆解成任務(wù)列表。每個任務(wù)有三個硬約束。第一足夠小可獨立完成。一個任務(wù)的產(chǎn)物應(yīng)該是可獨立 review 的最小單元。太大的任務(wù)拆小不然不好驗證也不好回退。第二有明確的 RED/GREEN 驗證點。先寫測試讓測試失敗這是 RED。再寫實現(xiàn)讓測試通過這是 GREEN。沒有例外。第三可獨立回退。任務(wù)失敗了可以單獨回退不影響其他任務(wù)。不會因為一個任務(wù)卡殼整個需求都推進不了。這樣拆解的目的是什么呢把寫一段大代碼這件事變成完成 N 個小任務(wù)。每個小任務(wù)都有明確的入口和出口入口是失敗的測試出口是通過的測試。AI 不再有自由發(fā)揮的空間。想寫代碼先證明你想清楚了它該怎么測。架構(gòu)預(yù)檢編碼前先卡方向正式開始編碼之前還有一道預(yù)檢架構(gòu)檢測。檢查什么呢分層有沒有越界比如 Controller 層直接調(diào) DAO 層跳過了 Service 層。依賴方向有沒有反轉(zhuǎn)比如領(lǐng)域?qū)臃聪蛞蕾嚵嘶A(chǔ)設(shè)施層。模塊邊界有沒有穿透比如訂單模塊直接調(diào)用了支付模塊的內(nèi)部類。這一步的設(shè)計意圖是避免實現(xiàn)跑偏后再返工。方向錯了代碼寫得再快也沒用。架構(gòu)預(yù)檢是事前防比事后查成本低得多。RED-GREEN-REFACTOR 循環(huán)TDD 的核心就是三步循環(huán)。第一步 RED先寫測試。這個測試應(yīng)該是失敗的因為功能還沒實現(xiàn)。如果測試一上來就通過了說明測試寫得不對沒測到點上。第二步 GREEN寫最少的代碼讓測試通過。怎么簡單怎么來先跑通再說。第三步 REFACTOR重構(gòu)。測試通過了說明功能是對的這時候再把代碼整理干凈該抽公共方法的抽該改命名的改。因為有測試兜底重構(gòu)的時候不怕改壞。放到出海禮品卡的例子上三步循環(huán)是這樣跑的。RED先寫測試。禮品卡面值 100出海服務(wù)費 10預(yù)期金額是 110。這時候 GiftCardCalculator.calcAmount 方法還沒實現(xiàn)測試跑失敗。GREEN實現(xiàn) calcAmount 方法就一行代碼面值加服務(wù)費。測試通過。REFACTOR把這個算法抽成公共方法確認訂單和創(chuàng)建訂單兩處都調(diào)用同一個方法保證算法一致。為什么 TDD 在 AI 時代格外重要因為 AI 寫代碼最大的問題不是寫不出來是它太自信了。它會在沒有測試的情況下寫一段看起來很合理的實現(xiàn)然后自信地告訴你完成了。TDD 的價值就在于先有一個失敗的測試擺在那里。AI 必須讓這個測試通過。這是一個客觀的、不可糊弄的錨點。沒有 TDDAI 的完成是主觀判斷。有了 TDDAI 的完成是測試通過?？陀^、可驗證、不可糊弄。第四道關(guān)口門禁卡控機器判定為主人工決策為輔編碼過了 TDD最后還有一道關(guān)口門禁。但審核不是只在最后一步發(fā)生。每個階段產(chǎn)物落地的時候都有對應(yīng)的審核 Agentgate-check 只是最終匯總。門禁的設(shè)計遵循四個核心原則。機器判定為主人工決策為輔所有結(jié)論落本地磁盤數(shù)據(jù)可回溯失敗必須回退到具體階段。一個一個說。機器判定為主每個審核 Agent 輸出的都是結(jié)構(gòu)化的 JSON。門禁讀 JSON 來判斷 PASS 還是 FAIL。不靠 LLM 主觀總結(jié)。為什么要這么設(shè)計因為 LLM 做總結(jié)太容易和稀泥了。十個檢查項里九個過了一個沒過LLM 可能給你總結(jié)成基本通過建議關(guān)注。機器判定就不一樣過了就是過了沒過就是沒過沒有中間態(tài)。人工決策為輔不是所有事情都適合機器判。比如回退方向怎么選排除某個規(guī)約的理由合不合理這些關(guān)鍵決策點才需要人來確認。大部分檢查都由機器自動完成人只在真正需要決策的地方介入。這樣人的精力才用在了刀刃上。所有結(jié)論落本地磁盤數(shù)據(jù)可回溯每一步的審核結(jié)果都結(jié)構(gòu)化地存在磁盤上。不是憑印象覺得沒問題而是有實實在在的證據(jù)。出了問題翻回去查當時門禁查了哪些項每項的結(jié)果是什么哪個 Agent 做的判斷一清二楚。這也為后面的埋點監(jiān)控提供了數(shù)據(jù)基礎(chǔ)。失敗必須回退到具體階段門禁 FAIL 不是簡單打回重來。而是定位到具體是哪個階段出的問題回退到那個階段去修。比如技術(shù)方案漏了一個異常場景那就回退到技術(shù)方案階段補方案而不是讓開發(fā)在編碼階段自己補上。問題出在哪就在哪解決保證每個階段的產(chǎn)物都是完整的。全流程的審核分布審核機制貫穿全流程不只是最后一步。需求澄清有需求的審核技術(shù)方案有方案的審核編碼有編碼的審核。放到出海禮品卡這個需求上門禁會查這些東西。invariant-reviewer 查不變約束。技術(shù)方案階段納入的確認訂單和創(chuàng)建訂單都要算禮品卡金額這條約束兩處調(diào)用點是不是都同步改了。只改一處就 FAIL。delta-guard 查增量風(fēng)險。新增的出海服務(wù)費查詢是外部調(diào)用有沒有登記有沒有降級。命中了外部調(diào)用檢查項沒降級就高亮提醒。bdd-acceptance 查 BDD 驗收。需求 Spec 里寫的禮品卡等于 110 元金額小于等于 0 阻斷這兩條 Gherkin 場景必須有對應(yīng)測試而且全部通過。門禁檢查是三層 DAG 結(jié)構(gòu)層內(nèi)并行層間串行。同一層的檢查可以并行跑提高效率。不同層之間有依賴關(guān)系必須等上一層過了才能跑下一層。增量代碼體檢合入前的快速拍片除了正式的門禁審核我們還有一個輕量級的工具增量代碼檢測。它的定位是代碼準入檢查的工具主要用于合并代碼前的自動審查和開發(fā)者本地自查。用九個維度掃描本次改動的代碼比如有沒有引入新的外部調(diào)用有沒有新的線程池錯誤碼有沒有重復(fù)關(guān)鍵調(diào)用鏈上有沒有動到不該動的節(jié)點。掃描完生成一份飛書報告直接發(fā)到項目組的知識庫下。這個工具有三個特點?？蓴U展每條規(guī)則是獨立的小目錄一個配置加一個掃描腳本新增規(guī)則不動其他地方還預(yù)留了大模型判斷的擴展位?？蓮?fù)用解析代碼差異、查代碼作者、生成飛書文檔這些基礎(chǔ)動作下沉為共用工具代碼差異只解析一次九條規(guī)則讀同一份數(shù)據(jù)。輕量級純文本掃描60 秒超時秒級返回。流水線有三級兜底單條規(guī)則掛了不拖累其他規(guī)則飛書發(fā)不出也會留本地文件。這個工具的定位很清楚就是快速拍片。有問題先篩出來要不要進一步處理再看人。第五道關(guān)口全流程埋點把改進變成數(shù)據(jù)前四道關(guān)口都是閘門告訴你什么能過什么不能過。這第五道關(guān)口是儀表盤告訴你改進到底有沒有效果。埋點監(jiān)控把研發(fā)過程變成數(shù)據(jù)。這次需求花了多少人力成本哪個階段最耗時知識庫調(diào)用成功率高嗎門禁通過率在變好還是變差回退了兩次根因是需求沒寫清還是方案設(shè)計漏了。有了數(shù)據(jù)改進才有據(jù)可依。不是拍腦袋說我覺得流程變順了而是拿數(shù)據(jù)說話需求澄清的回退率降了多少門禁通過率提了多少平均交付周期短了多少?？窗宸秩龑訌男枨蟮酱a逐層下鉆。最上層是需求維度的概覽中間層是階段維度的明細最下層是單個任務(wù)的執(zhí)行細節(jié)。想看粗的看粗的想看細的看細的。指標按問什么問題歸成五個維度。這里就不展開了重點說說埋點數(shù)據(jù)怎么驅(qū)動改進三個典型場景。場景一知識庫該補什么怎么判斷知識庫夠不夠用看三個信號。知識庫調(diào)用成功率低引用的知識條目少用戶問答多。三個信號湊在一起說明知識庫要么內(nèi)容少要么命中率低。高頻被問到的問題清單就是知識庫該補充的內(nèi)容清單。用戶反復(fù)問什么就把什么寫進知識庫。寫進去之后再看這個問題是不是就不問了。這是一個正向循環(huán)。問題越多補充的內(nèi)容越多知識庫越好用問題就越少。場景二流程哪里設(shè)計得不好怎么判斷某個流程階段設(shè)計得好不好看耗時和對話輪數(shù)。耗時高不一定是問題可能就是這個階段事情多。但耗時高加上對話輪數(shù)異常高就一定是流程設(shè)計有問題不是模型慢。比如技術(shù)方案階段來回改了十輪才定下來說明要么需求澄清沒做好方案階段還在反復(fù)改需求要么方案模板有問題AI 理解不了來回調(diào)整。找到異常的階段針對性地優(yōu)化模板或者補充知識庫效率就上去了。場景三哪個子 Agent 在白干子代理和工具調(diào)用也是一樣的道理。某個子 Agent 被調(diào)用了很多次但產(chǎn)出很少或者反復(fù)調(diào)用同一個工具拿不到有用的結(jié)果說明這個子 Agent 的設(shè)計有問題或者工具不夠用。把這些白干的地方找出來該收斂的收斂該加工具的加工具。埋點監(jiān)控這道關(guān)口是前四道關(guān)口的反饋回路。沒有它前面的改進都是憑感覺。有了它每一步改進都能量化才能持續(xù)優(yōu)化。五道關(guān)口串起來就是一條 AI Native 的流水線到這里五道關(guān)口就都講完了。我們把它們串起來看看。最開始是需求澄清BDD 釘死驗收標準解決做什么的問題。然后是技術(shù)方案五段式拆解加上規(guī)約對齊解決怎么做的問題。接著是 TDD 實施任務(wù)拆分加紅綠色循環(huán)解決做完沒的問題。再然后是門禁卡控機器判定加結(jié)構(gòu)化證據(jù)解決能不能上的問題。最后是全流程埋點數(shù)據(jù)驅(qū)動持續(xù)改進解決有沒有用的問題。五道關(guān)口一道接一道把風(fēng)險一層一層往下篩。每一道關(guān)口都有明確的輸入和輸出產(chǎn)出物是結(jié)構(gòu)化的、可驗證的。整個流水線的架構(gòu)自底向上分了五層。最底層是基礎(chǔ)設(shè)施層統(tǒng)一埋點定義和階段性產(chǎn)出規(guī)范通過 Hook 自動采集和 SKILL 顯式采集雙通道實現(xiàn)全鏈路數(shù)據(jù)采集。往上是 Agent 系統(tǒng)層設(shè)計 Agent、意圖工程、上下文工程通過鏈式調(diào)用、并行協(xié)作、反饋修正、結(jié)果匯總來編排。再往上是開發(fā)流程層就是我們說的五階段核心研發(fā)流程。第四層是度量層全鏈路可觀測量化數(shù)據(jù)采集、分析、報告與可視化。最頂層是治理層把 spec、code、arch、BDD 四維并行審查的能力內(nèi)嵌到前四層。五層架構(gòu)從基礎(chǔ)設(shè)施到治理每一層支撐上面一層治理層又反過來貫穿下面所有層。最后說幾句AI Coding 發(fā)展到今天比拼的早就不是誰的模型更強了。模型能力大家都差不多你用 GPT 我用 Claude差距能有多大真正拉開差距的是誰能把 AI 的產(chǎn)出變成可驗證、可度量、可負責(zé)的研發(fā)生產(chǎn)方式。可驗證、可度量、可負責(zé)這七個字才是 AI Native 研發(fā)范式的核心。模型能力是變量今天這個模型強明天那個模型出來又更強了。你沒法控制。流程設(shè)計是常數(shù)你怎么組織需求、怎么設(shè)計方案、怎么保證質(zhì)量、怎么度量效果這些是你能說了算的。變量決定上限常數(shù)決定底線。交易核心系統(tǒng)的底線不能交給變量。所以我們花了這么大力氣做這五道關(guān)口搭這條流水線。不是因為 AI 不夠好恰恰是因為 AI 太好了好到如果沒有合適的流程去約束它它能把好的壞的都放大十倍。用好 AI 的前提是給它一個好的工作環(huán)境。就像一個優(yōu)秀的工程師你得給他清晰的需求、明確的規(guī)范、合適的工具、及時的反饋他才能發(fā)揮出最大的價值。AI 也是一樣。流水線搭好了AI 的效率才能真正轉(zhuǎn)化為團隊的產(chǎn)能而不是更多的技術(shù)債和線上故障。這條路我們也是摸著石頭過河走了不少彎路。但方向是明確的AI 不會讓研發(fā)流程變得不重要它只會讓好的流程和壞的流程之間的差距變得越來越大。