我理解的 AI 軟件工程不是讓 AI 寫代碼而是讓系統(tǒng)變成 AI 能工作的環(huán)境從一條 Spec 講起把需求分析、架構(gòu)設(shè)計、Coding、測試、發(fā)布重新串一遍 ——附一條真實需求的完整走查范例一、從一個特別典型的翻車現(xiàn)場說起「業(yè)擴(kuò)預(yù)受理增加一個校驗」——AI 很快就寫出了代碼能編譯測試也能跑架構(gòu)師一看改錯地方了。這個場景我太熟悉了。我們在推進(jìn) AI 研發(fā)工具鏈的過程中被問得最多的一句話就是模型都能寫代碼了為什么還要折騰這么多規(guī)范和流程我的答案是不是模型不夠強(qiáng)是我們沒給它一個能工作的環(huán)境。給 AI 一個全新項目它往往表現(xiàn)不錯——沒有歷史包袱技術(shù)棧公開架構(gòu)簡單規(guī)?？煽?。但把它扔進(jìn)一個跑了十幾年的存量系統(tǒng)里它不知道這個頁面是不是業(yè)務(wù)入口不知道這個接口屬于哪個服務(wù)、能不能跨中心調(diào)用不知道這個字段來自哪張表更不知道這條規(guī)則是全國通用還是只適用于某個省。所以我習(xí)慣把 AI 軟件工程拆成三層來看缺任何一層AI 都只會「表現(xiàn)得像會寫代碼」而不是「像一個懂系統(tǒng)的人」層次回答的問題對應(yīng)手段規(guī)范 SpecAI 要做什么、做到什么程度SDD需求 → 規(guī)范 → 方案 → 任務(wù) → 實現(xiàn) → 驗證上下文 ContextAI 工作時應(yīng)該知道什么業(yè)務(wù)規(guī)則、架構(gòu)邊界、數(shù)據(jù)模型、私有技術(shù)棧、存量代碼環(huán)境 HarnessAI 能不能可靠地工作技能、工具、護(hù)欄、評測、反饋回路很多人把精力全砸在第一層把 Prompt 寫得更長更細(xì)卻忽略了后兩層——這恰恰是企業(yè) AI Coding 的分水嶺。下面這條需求我會在后面的每一層里都拿它當(dāng)例子你可以一路看它是怎么被走完的。貫穿全文的范例需求 M-2026-0930業(yè)務(wù)方原話就是這么一句話交給我們的「低壓居民新裝預(yù)受理的時候如果這個客戶名下已經(jīng)有一塊在用的低壓表就不讓他再受理了提示他已有用電戶號?！箍雌饋硎且痪湓拰嶋H上是三個坑什么叫「在用」提示幾條攔在哪一層二、把工具鏈攤開看五個階段人和 AI 各干什么我一直反對把 AI 軟件工程講成「一個更聰明的編程助手」。它真正的樣子是把研發(fā)流程重新切一遍并且明確每一段里人和 AI 的分工階段工具鏈動作人決策與把關(guān)AI生成與執(zhí)行① 需求分析/constitution/clarify定目標(biāo)與動機(jī)What / Why、澄清歧義、確認(rèn)邊界結(jié)合輸入提問、起草規(guī)范初稿② 架構(gòu)設(shè)計/specify/plan評審方案、拍板取舍、確認(rèn) Spec 與驗收口徑融合知識與規(guī)則生成 Spec、出技術(shù)方案、拆任務(wù)③ Coding/tasks/implement定接口與規(guī)范約束、Code Review 把關(guān)按規(guī)范生成代碼、同步產(chǎn)出測試與文檔④ 測試/analyze/test定驗收標(biāo)準(zhǔn)與質(zhì)量門禁、判斷是否可發(fā)布自動跑回歸與驗證、比對規(guī)范一致性⑤ 發(fā)布/implement· 上線決策上線與灰度范圍、異常時決定回滾執(zhí)行部署與監(jiān)控、回流數(shù)據(jù)、報告偏差這張表里有一條分界線我認(rèn)為是整套方法能跑通的關(guān)鍵人負(fù)責(zé)「做什么、做到什么程度」AI 負(fù)責(zé)「怎么生成、怎么執(zhí)行」。決策權(quán)和事實裁決權(quán)在人手上生成和執(zhí)行的工作量交給 AI。這一條守住了團(tuán)隊就不會陷入「AI 寫了一大堆、沒人敢負(fù)責(zé)」的窘境守不住就會出現(xiàn)最危險的一句話——「AI 檢查全部通過」。Checklist 全綠不等于事實正確我見過 AI 自檢全過、人工抽查時序圖和接口字段后仍然發(fā)現(xiàn)語義丟失的案例。這一條需求落在五個階段里各自要交付什么后面第三節(jié)會展開階段交付物誰簽字① 需求分析一句話需求 → 澄清清單 邊界定義業(yè)務(wù)方 需求負(fù)責(zé)人② 架構(gòu)設(shè)計Spec 段落 影響范圍 改動文件清單架構(gòu)師③ Coding代碼改動 單元測試 API 契約變更開發(fā) Code Reviewer④ 測試用例集 四層驗證結(jié)論測試 質(zhì)量門禁⑤ 發(fā)布灰度策略 監(jiān)控指標(biāo) 回流知識條目研發(fā)負(fù)責(zé)人三、范例走查這條需求是怎么一步步被走完的這一節(jié)是全篇最想讓你看的部分。同一條需求分別在五個階段留下了什么樣的真實產(chǎn)物——你會發(fā)現(xiàn)「AI 軟件工程」不是概念而是一串可以照著抄的文件。階段 ① 需求分析把一句話拆成可驗證的規(guī)則先落項目憲法/constitution它是這個項目所有需求的共同約束寫一次、長期生效# .ai-sdd/constitution.md節(jié)選 ## 架構(gòu)約束 - C1 業(yè)務(wù)校驗必須落在服務(wù)層禁止只做前端校驗。 - C2 跨域數(shù)據(jù)必須通過對方域提供的接口獲取禁止直連對方庫表。 - C3 對外錯誤碼統(tǒng)一 MKT-XXXX新增錯誤碼需在錯誤碼表登記。 ## 流程約束 - C4 未通過 /clarify 澄清歧義的需求不得進(jìn)入編碼。 - C5 每個需求必須附帶驗收口徑與回滾方案。然后是/clarify——AI 提問人來裁決這是全流程里我認(rèn)為最值錢的一段對話AI需求里的在用包含哪些狀態(tài)系統(tǒng)里計量點(diǎn)狀態(tài)有待裝 / 在用 / 暫停 / 已銷戶 / 已拆表。 人算在用和暫停不含待裝和已銷戶。 AI同一證件號碼下有多塊在用表時提示幾條 人最多列 3 條多余的提示等共 N 戶不能撐爆頁面。 AI攔截位置是提交受理還是校驗按鈕 人點(diǎn)校驗就攔不要等到提交才發(fā)現(xiàn)。 AI老用戶走增容的場景要不要一起攔 人只攔新裝業(yè)務(wù)類型 低壓居民新裝增容放行——這正是我們要引導(dǎo)他去辦的。 AI這條規(guī)則全國通用還是分省 人全國通用。分省的重復(fù)戶規(guī)則另有一條本需求不涉及。五輪問答下來一句話需求變成了 5 條可驗證的判定條件。這五條不是我拍的是人確認(rèn)過的——注意最后兩個問題的價值如果沒有 ContextAI 根本不知道有「增容」這個兄弟流程也不知道規(guī)則有分省口徑。階段 ② 架構(gòu)設(shè)計Spec 定下來再談怎么做/specify把澄清結(jié)果固化成 Spec/plan結(jié)合 Context 出技術(shù)方案。產(chǎn)物大概是這樣# Spec: 低壓居民新裝預(yù)受理-重復(fù)用電戶校驗M-2026-0930 ## 業(yè)務(wù)規(guī)則 R1 業(yè)務(wù)類型 低壓居民新裝 時才執(zhí)行本校驗。 R2 取證件號碼名下計量點(diǎn)狀態(tài) ∈ {在用, 暫停} 視為已有用電戶。 R3 命中則攔截返回 MKT-3021攜帶已有用電戶號最多 3 條 總數(shù)。 R4 觸發(fā)時機(jī)受理頁點(diǎn)擊校驗。 R5 全國通用不區(qū)分省份。 ## 驗收口徑 A1 命中 1 戶提示含該戶號受理不可繼續(xù)。 A2 命中 3 戶提示前 3 個 等共 N 戶。 A3 證件號名下僅有已銷戶記錄放行。 A4 業(yè)務(wù)類型 增容不觸發(fā)本校驗。 A5 客戶域接口超時放行并記錄告警不阻斷受理。# Plan: M-2026-0930 ## 影響范圍 - acceptance-service AddrAcceptServiceImpl校驗入口 - acceptance-web 受理頁校驗按鈕錯誤碼映射 - 配置 rule_config RULE_LOWVOLT_DUP_CHECK開關(guān) 上限條數(shù) ## 復(fù)用而非新寫 - 客戶域已有接口 queryMeterPointsByCertNo(certNo, statusSet) v2 已支持狀態(tài)集合入?yún)?→ 直接復(fù)用不要新開接口避免 C2 違規(guī)。 ## 風(fēng)險 - 存量受理高峰期該接口 QPS 上升需確認(rèn)客戶域限流閾值 - 狀態(tài)集合口徑若與計費(fèi)側(cè)不一致可能出現(xiàn)同戶不同判 → 需與計費(fèi)確認(rèn)。 ## 任務(wù)拆分 T1 配置項與錯誤碼登記 T2 服務(wù)層校驗實現(xiàn) T3 前端提示 T4 單測與用例這里最典型的一幕是「復(fù)用而非新寫」AI 沒有去寫一條新的查詢 SQL而是先在 Context 里找到客戶域已有的 v2 接口。這就是有 Context 和沒 Context 的差別——沒有它AI 八成就直連庫表了代碼能跑但違反了 C2。階段 ③ Coding照規(guī)范生成不是憑空發(fā)揮/implement產(chǎn)出的改動大致長這樣示意--- a/acceptance-service/src/main/java/.../AddrAcceptServiceImpl.java b/acceptance-service/src/main/java/.../AddrAcceptServiceImpl.java // R1 僅低壓居民新裝觸發(fā)A4 增容放行 if (!BizType.LOW_VOLT_RESIDENT_NEW.equals(req.getBizType())) { return PreCheckResult.pass(); } // R2 復(fù)用客戶域接口禁止直連C1/C2 ListMeterPoint points customerClient.queryMeterPointsByCertNo( req.getCertNo(), MeterStatus.IN_USE, MeterStatus.SUSPEND); if (points.isEmpty()) { return PreCheckResult.pass(); // A3 } // R3 最多展示 3 條 總數(shù) return PreCheckResult.reject( ErrorCode.MKT_3021, metersPreview(points, 3));同步產(chǎn)出錯誤碼MKT-3021登記、RULE_LOWVOLT_DUP_CHECK配置項、單測 4 條對應(yīng) A1–A4。注意第 ③ 階段 AI 的產(chǎn)出里已經(jīng)帶了測試這是它和人最大的差別——寫代碼和寫測試一步完成但「測試是否覆蓋了該覆蓋的」仍然由人判。階段 ④ 測試四層驗證最后一層最容易漏/analyze/test跑完驗收口徑 A1–A5 全綠。但我們的門禁要求多問四句驗證層問題本例結(jié)論能不能編譯/跑起來構(gòu)建與單測通過需求是否實現(xiàn)A1–A5 逐條比對 Spec R1–R5通過有沒有違反系統(tǒng)邊界是否直連庫表、是否跨域、錯誤碼是否登記通過復(fù)用 v2 接口Context 與實際是否一致客戶域接口簽名、狀態(tài)枚舉是否變了發(fā)現(xiàn)偏差v2 接口新增了待裝狀態(tài)Context 事實卡未更新第四層就是我們踩過的坑功能全過但 Context 已經(jīng)悄悄過期。如果這次不修下一次 AI 拿著舊事實卡做需求就會再錯一次。階段 ⑤ 發(fā)布灰度、監(jiān)控、然后回流灰度先放開 5% 受理量觀察 24 小時關(guān)注命中率與客戶域超時率監(jiān)控MKT-3021觸發(fā)次數(shù)、客戶域接口 P99、放行告警A5 分支計數(shù)回滾RULE_LOWVOLT_DUP_CHECK一鍵關(guān)閉無需回滾代碼——把開關(guān)做進(jìn)配置是這類校驗需求的標(biāo)配回流Harvest本次確認(rèn)了兩條可復(fù)用的知識 → ①「跨域查詢客戶計量點(diǎn)一律走 queryMeterPointsByCertNo」②「狀態(tài)口徑需與計費(fèi)側(cè)對齊含待裝狀態(tài)」。它們被寫回 Context供下一個需求使用。一條需求走完系統(tǒng)里多了三樣?xùn)|西一段受規(guī)范約束的代碼、一份被校正的 Context、兩條能復(fù)用的知識。這才是我說的「知識跟著真實需求生長」。四、Spec 是唯一事實來源但它需要三類輸入我們那套流程里最重要的一句話是規(guī)范Spec是唯一事實來源。需求、設(shè)計、代碼、測試、文檔全部對著它對齊而不是各說各話。但 Spec 不會憑空長出來。它需要三類輸入缺一類就會寫偏用戶的 Prompt——意圖、邊界、驗收期望。這是人給的方向決定「做什么」。本體 / 行業(yè)知識——領(lǐng)域模型、術(shù)語體系、合規(guī)要求。它決定了 AI 用的詞和業(yè)務(wù)對得上不會把「更名過戶」和「換表增容」當(dāng)成同一類流程。內(nèi)部知識庫 Wiki——業(yè)務(wù)規(guī)則與系統(tǒng)現(xiàn)狀。哪條規(guī)則是全國通用、哪條只在某個省生效這個接口屬于哪個域、允不允許跨中心調(diào)用。同一個需求只給 Prompt 和給三類輸入差別有多大拿上面那條需求做個對照只給 Prompt做法 A三類輸入齊全做法 B輸入「低壓新裝預(yù)受理加個校驗客戶已有在用表就不讓受理」同一句話 項目憲法 領(lǐng)域術(shù)語表 受理/客戶域 ContextAI 理解「在用表」 任意狀態(tài)未刪除的計量點(diǎn)「在用」 在用 暫停排除待裝/已銷戶R2改動位置前端預(yù)校驗看起來最快服務(wù)層校驗符合 C1數(shù)據(jù)來源自行拼 SQL 查計量點(diǎn)表復(fù)用客戶域 v2 接口符合 C2遺漏增容被誤攔超時直接報錯阻斷受理增容放行A4超時放行告警A5返工架構(gòu)評審打回重做一次通過評審差別不在于 AI 聰明不聰明而在于它有沒有可能知道這些事。這里必須說清楚一個誤區(qū)把文檔堆給 AI ≠ 給了 AI 知識。很多團(tuán)隊一上手就是建目錄、瘋狂寫 Markdown業(yè)務(wù)規(guī)則一份、架構(gòu)一份、接口一份、數(shù)據(jù)庫一份攢出幾百份文檔說「你都看看」。這只是把企業(yè) Wiki 搬到了 AI 面前。真正的做法是讓正確的信息在正確的時間、以正確的粒度進(jìn)入模型——給 Agent 一張地圖而不是一本一千頁的說明書。五、Context 怎么組織決定這套東西是資產(chǎn)還是負(fù)擔(dān)我把企業(yè) Context 拆成五層指令什么不能做、工具能做什么、技能開發(fā) SOP、項目知識業(yè)務(wù)規(guī)則、架構(gòu)、數(shù)據(jù)模型、API 契約、代碼模式、私有技術(shù)棧、運(yùn)行時當(dāng)前需求、對話歷史、已驗證的證據(jù)。其中第四層「項目知識」是絕大多數(shù)企業(yè)最缺的一層也是最值得投入的一層。它適合按三檔來組織地圖 → 目錄 → 事實。地圖context-index.yaml# .ai-sdd/context/context-index.yaml節(jié)選 version: 1 modules: acceptance: # 業(yè)擴(kuò)受理域 catalog: business/acceptance/README.md facts: - id: rule-dup-meter-point file: business/acceptance/rules/rule-dup-meter-point.md level: A # 證據(jù)等級 state: current # 當(dāng)前狀態(tài) or 目標(biāo)狀態(tài) load_when: [預(yù)受理, 計量點(diǎn)校驗, 重復(fù)戶] - id: arch-call-boundary file: system/arch/call-boundary.md level: A state: current load_when: [跨域調(diào)用, 新增對外接口] customer: facts: - id: api-query-meter-points-v2 file: system/api/customer/query-meter-points-v2.md level: A load_when: [按證件號查計量點(diǎn), 客戶域]地圖本身不解釋知識它只說三件事有哪些知識、在哪、什么時候該加載。AI 拿到「預(yù)受理加校驗」這個需求命中l(wèi)oad_when自然只加載受理域和客戶域這兩小塊而不是把整個系統(tǒng)吃進(jìn)去。事實一條業(yè)務(wù)規(guī)則長什么樣# .ai-sdd/context/business/acceptance/rules/rule-dup-meter-point.md id: rule-dup-meter-point title: 低壓居民新裝預(yù)受理——重復(fù)用電戶校驗 level: A state: current rule: | 業(yè)務(wù)類型 低壓居民新裝時按證件號碼查詢計量點(diǎn) 狀態(tài) ∈ {在用, 暫停} 視為已有用電戶命中則攔截返回 MKT-3021 攜帶已有用電戶號最多 3 條 總數(shù)不含待裝、已銷戶。 全國通用不區(qū)分省份。 evidence: - 源碼: AddrAcceptServiceImpl.java:214原有復(fù)用邏輯 - 配置: rule_config.RULE_LOWVOLT_DUP_CHECK - 接口: customer/queryMeterPointsByCertNo v2 reuse: 增容、更名過戶等流程可引用本規(guī)則的狀態(tài)口徑 last_verified: 2026-09-30 verified_by: 張XX架構(gòu)師注意這幾個字段——它們才是讓 Context 可信的東西level證據(jù)等級、state當(dāng)前還是目標(biāo)、evidence憑什么這么說、verified_by誰簽的字。沒有這幾項一條知識就只是「有人這么寫過」。證據(jù)分級同一條知識寫法天差地別等級來源可以怎么用對應(yīng)寫法示例A源碼、配置、接口實測事實基線可直接作為規(guī)則「接口 v2 支持狀態(tài)集合入?yún)⒃创a sign 確認(rèn)」B注釋、目錄結(jié)構(gòu)、文件名需交叉驗證后才可用「包名暗示屬于受理域待確認(rèn)」C / D命名推斷、泛化規(guī)律只能當(dāng)假設(shè)禁止寫入事實層「猜測暫停狀態(tài)也應(yīng)攔截未驗證」X密鑰、賬號、生產(chǎn)地址絕對禁入—AI 很容易把「我猜這個接口應(yīng)該是這樣」寫成「系統(tǒng)就是這樣」這兩者根本不是一回事。狀態(tài)邊界Current 與 Target 不能混回到我們的例子。這次需求本身沒有改變「在用」的定義所以事實卡是state: current。但假設(shè)這次需求就是要重新定義「在用」比如把暫停也算作可用那么正確的做法是context/business/acceptance/rules/rule-dup-meter-point.md # state: current現(xiàn)狀 context/changes/2026-0930-dup-check/rules/rule-dup-meter-point.md # state: target本次目標(biāo)文檔寫電費(fèi)計算是同步調(diào)用、代碼里其實是異步不能簡單地把文檔刪掉說「代碼才是真理」——因為這次需求本身可能就是要從同步改成異步。兩套狀態(tài)分開放AI 才不會把「目標(biāo)方案」誤當(dāng)成「現(xiàn)狀」。還有一個容易忽視的細(xì)節(jié)別為了「好讀」把 Context 壓縮壞了。很多人嫌文檔長壓一壓結(jié)果壓掉的往往是分支條件、接口字段、異步關(guān)系、異常路徑這些最要命的地方。Context 工程追求的是最小必要 Context而不是最短 Context——提煉不等于精簡。六、閉環(huán)的關(guān)鍵AI 提出人確認(rèn)然后回寫知識不會因為「整理過一次」就永久可用。我的做法是讓它跟著真實需求生長四個動作循環(huán)。每個動作都產(chǎn)生一份看得見的輸出① Discover找缺口——需求來了先別寫代碼讓 AI 說清「我還缺什么」需求 M-2026-0930 的知識缺口清單 [已有] 受理流程主鏈路、業(yè)務(wù)類型枚舉來自 business/acceptance/README.md [缺失] ① 計量點(diǎn)狀態(tài)枚舉的完整取值與業(yè)務(wù)含義 ② 按證件號查計量點(diǎn)的合法接口是否已有 v2 ③ 該規(guī)則是否分省是否有省份差異配置 [待確認(rèn)] ④ 與計費(fèi)側(cè)在用口徑是否一致可能影響判定結(jié)果過去是人告訴 AI 該看什么現(xiàn)在是 AI 自己說清它缺什么——這張清單直接交給了架構(gòu)師十分鐘就回填完畢。② Update補(bǔ)知識——AI 提出、人確認(rèn)、再入庫產(chǎn)出一份變更報告Context 變更報告 #C-2026-0930-02 新增: system/api/customer/query-meter-points-v2.md level A已驗證 修訂: business/acceptance/rules/rule-dup-meter-point.md 補(bǔ)充待裝狀態(tài)說明 索引: context-index.yaml 新增 2 條映射 確認(rèn)人: 張XX 依據(jù): 客戶域負(fù)責(zé)人確認(rèn) 源碼 sign不是 AI 說什么就寫什么而是走一遍「AI 提出 → 人確認(rèn) → 制定合并方案 → 寫入 → 同步索引 → 變更報告」。因為錯誤的 Context 比沒有 Context 更危險。③ Harvest做回流——PR 合并后問一句「這次有沒有發(fā)現(xiàn)新知識」本次開發(fā)發(fā)現(xiàn)的新知識2 條 - 跨域查詢客戶計量點(diǎn)一律走 queryMeterPointsByCertNo v2禁止直連庫表 - 計量點(diǎn)狀態(tài)口徑需與計費(fèi)側(cè)對齊當(dāng)前含待裝 建議提升為通用 Context是涉及所有受理類需求的跨域查詢④ Review定期體檢——每周只讀體檢只給建議、不改知識庫Context 體檢報告 2026-W40 - 時效性: 3 條事實卡 last_verified 超 90 天建議復(fù)核 - 沖突: 計費(fèi)域與受理域?qū)和５拿枋霾灰恢? 處 - 冗余: 2 處重復(fù)的調(diào)用鏈說明建議合并 - 分離性: 通過通用知識與 change 臨時知識未混放這跟代碼治理的思路是一樣的。 對應(yīng)到圖里這條回流線我特意標(biāo)成「**人確認(rèn)后回寫**」。規(guī)范的生命周期里變更決策權(quán)始終在人這邊——AI 可以高效地掃描代碼、分析調(diào)用鏈、執(zhí)行修改、跑測試、出報告但它不適合獨(dú)立判斷業(yè)務(wù)事實是什么、兩套架構(gòu)描述哪個對、一條規(guī)則是不是全局規(guī)則、一個高風(fēng)險改動能不能上線。 ## 七、反過來看六個不要做 1. **不要把模型當(dāng)外包**只丟一個 Prompt不給系統(tǒng)知識然后抱怨它改錯地方。 2. **不要成立專項組一次性整理完系統(tǒng)**抽代碼、寫文檔、畫架構(gòu)圖幾個月后交出一套厚厚的「AI 知識庫」真正寫代碼時 AI 還是找不到代碼。脫離真實需求整理出來的知識抽象層次不一致、容易過期還會把單次需求誤認(rèn)成通用規(guī)則。 3. **不要把 Prompt 寫成小說**從一句話堆成幾十頁開發(fā)規(guī)范問題通常不在「說得不夠多」而在「該知道的它不知道」。 4. **不要為了好讀壓壞 Context**如上。 5. **不要把「AI 檢查全部通過」當(dāng)質(zhì)量結(jié)論**AI 擴(kuò)大檢查覆蓋面人做最終裁決。 6. **不要把人從關(guān)鍵節(jié)點(diǎn)上撤掉**需求和驗收標(biāo)準(zhǔn)、方案取舍、上線與回滾這三個節(jié)點(diǎn)的簽字權(quán)必須在人手上。 ## 八、想開始就按這五步走 這套東西不需要一上來就建「企業(yè)級 AI 知識中臺」也不用先成立十幾人的專項組。照著下面這張**第一周清單**抄一遍就能起步 markdown # 試點(diǎn)啟動清單第一周 [ ] 選定 1 個真實需求業(yè)務(wù)真實、馬上要開發(fā)、驗收標(biāo)準(zhǔn)明確、有中等復(fù)雜度 → 范例低壓居民新裝預(yù)受理-重復(fù)用電戶校驗 [ ] 寫 1 份項目憲法constitution.md3–5 條架構(gòu)約束 2 條流程約束 → 范例C1 校驗必須落服務(wù)層、C2 禁止直連他人庫表、C3 錯誤碼登記 [ ] 建 1 張地圖context-index.yaml 2 個域目錄受理域、客戶域 [ ] 填 5 條事實1 條業(yè)務(wù)規(guī)則 1 張架構(gòu)圖 1 條調(diào)用鏈 1 個 API 1 個代碼模式 [ ] 走完一次 DiscoverAI 缺口清單→ 人確認(rèn) → 補(bǔ) Context [ ] 走完五階段產(chǎn)出Spec、代碼、用例、四層驗證結(jié)論、灰度與回滾方案 [ ] 做一次 Harvest把本次知識回流成通用 Context目標(biāo) ≥ 2 條對應(yīng)到方法上就是這五步挑一個真實需求當(dāng)起點(diǎn)業(yè)務(wù)真實、馬上要開發(fā)、有明確驗收標(biāo)準(zhǔn)、有一定復(fù)雜度。先做 Context Discover再補(bǔ) Context讓 AI 說清涉及哪些業(yè)務(wù)規(guī)則、哪些系統(tǒng)、哪些服務(wù)、要確認(rèn)哪些 API、當(dāng)前知識庫缺什么。第一版不用多一條業(yè)務(wù)規(guī)則、一張架構(gòu)圖、一條調(diào)用鏈、一個 API 說明、一個代碼模式夠用就行。先出設(shè)計確認(rèn)后再 Coding需求理解、影響范圍、方案、要改的文件、調(diào)用關(guān)系、數(shù)據(jù)變化、風(fēng)險、測試方案確認(rèn)完再寫代碼。這時 AI 手上的上下文已經(jīng)不是「你是一名高級程序員」而是「這是我們的系統(tǒng)、這是當(dāng)前需求、這是正確的調(diào)用鏈、這是不能越過的架構(gòu)邊界、這是應(yīng)該改的代碼位置」。驗證要過四層能不能編譯、需求是否實現(xiàn)、有沒有違反系統(tǒng)邊界、Context 里的知識和實際代碼是否還一致。最后一層最容易被忽略但它決定了下一次 AI 還能不能繼續(xù)相信這些 Context。Harvest 新知識回流成通用 Context能被后續(xù)需求復(fù)用的就從一次性的改動結(jié)論提升為通用知識。回頭看我們那張工具鏈圖里其實只講清楚了四件事把規(guī)則寫清楚、從規(guī)范自動生成、漸進(jìn)式改造、知識沉淀。對應(yīng)的收益也很樸素——項目延期少一點(diǎn)、返工少一點(diǎn)、文檔準(zhǔn)確率高一點(diǎn)、風(fēng)險可控、知識不隨人員流失。九、最后變的是工程師的活過去兩年我們習(xí)慣比較哪個模型寫代碼更強(qiáng)、哪個 Agent 跑分更高、哪個工具更快。這些都重要但進(jìn)入企業(yè)之后還有一個變量經(jīng)常被忽略你的系統(tǒng)到底是不是一個 AI 可以理解和工作的環(huán)境。如果架構(gòu)知識都在某個架構(gòu)師腦子里業(yè)務(wù)規(guī)則散落在微信群里接口說明堆在各種文檔里代碼沒有清晰邊界測試跑不起來歷史決策無處追溯——那么就算換上最強(qiáng)的模型AI 也很難穩(wěn)定工作。反過來如果業(yè)務(wù)知識、系統(tǒng)架構(gòu)、數(shù)據(jù)模型、代碼模式、工具、技能、規(guī)則、測試和歷史決策能逐漸變成 AI 可以發(fā)現(xiàn)、讀取、調(diào)用和驗證的工程資產(chǎn)那么模型每提升一次能力整個團(tuán)隊都會一起受益。所以我的結(jié)論是AI 軟件工程不是讓 AI 替你寫代碼而是把「懂業(yè)務(wù)和架構(gòu)的人 一套 AI 能理解的工程環(huán)境 一組 Agent 一套驗證和治理機(jī)制」組裝起來。設(shè)計環(huán)境、明確意圖、建立反饋回路——這三件事做好AI 才真正成為系統(tǒng)里的工程師。