AI專家楊夕凱現(xiàn)任職高德地圖擔(dān)任智能應(yīng)用與基建平臺(tái)負(fù)責(zé)人先后負(fù)責(zé)動(dòng)態(tài)數(shù)據(jù)、AI 導(dǎo)航、智能應(yīng)用及基建平臺(tái)等業(yè)務(wù)方向。其長期深耕地圖數(shù)字孿生、空間智能、AR/數(shù)字人及 AI 導(dǎo)航算法模型等領(lǐng)域并參與建設(shè)支撐千億級數(shù)據(jù)的端云一體化基礎(chǔ)設(shè)施與工業(yè)級 AI 研發(fā)體系。以下內(nèi)容梳理自高德技術(shù)團(tuán)隊(duì)發(fā)布的超級應(yīng)用 AI 原生研發(fā)模式工程實(shí)踐系列。透過這些技術(shù)分享可以清晰看到當(dāng) AI 深度參與代碼生成并由人工進(jìn)行關(guān)鍵兜底時(shí)多 Agent 并行場景下的統(tǒng)一規(guī)范與倉庫級真源控制是應(yīng)對 AI 代碼熵增的核心路徑。一、AI 代碼熵增多 Agent 并行生成的核心風(fēng)險(xiǎn)在 Agentic Coding 場景中AI 生成代碼的速度顯著提升但如果沒有統(tǒng)一規(guī)范約束系統(tǒng)復(fù)雜度也會(huì)同步上升。命名風(fēng)格不一致、架構(gòu)模式混用、隱式依賴蔓延、重復(fù)代碼堆積都會(huì)隨著生成次數(shù)增加而累積。這類現(xiàn)象可以概括為 AI 代碼熵增代碼產(chǎn)出變快但系統(tǒng)的可維護(hù)性、可理解性和可測試性下降。對于超級應(yīng)用而言這一問題更明顯。超級應(yīng)用通常具備數(shù)億用戶、數(shù)百萬行代碼、數(shù)十個(gè)團(tuán)隊(duì)協(xié)同的特征。單個(gè) Agent 生成一段代碼可能沒有問題但多個(gè) Agent 在不同時(shí)間、不同會(huì)話、不同任務(wù)中并行生成時(shí)如果缺少統(tǒng)一執(zhí)行標(biāo)準(zhǔn)產(chǎn)出物很容易偏離既有架構(gòu)約束。從工程落地的客觀規(guī)律來看控制 AI 代碼熵增的關(guān)鍵不是限制 AI 生成能力而是讓 AI 在明確的規(guī)則邊界內(nèi)生成。規(guī)范需要從寫給人看的文檔轉(zhuǎn)變?yōu)?AI 可讀取、可執(zhí)行、可驗(yàn)證的工程約束。二、倉庫唯一真源把隱式知識轉(zhuǎn)化為 AI 可讀事實(shí)控制 AI 代碼熵增的第一步是建立倉庫唯一真源。傳統(tǒng)研發(fā)中架構(gòu)設(shè)計(jì)可能存在于設(shè)計(jì)文檔中業(yè)務(wù)規(guī)則可能散落在 Wiki、注釋或工程師經(jīng)驗(yàn)里接口約定也可能依賴口頭溝通。這些信息對人類工程師尚且需要反復(fù)確認(rèn)對 AI 則更難穩(wěn)定獲取。在楊夕凱的推動(dòng)下高德技術(shù)團(tuán)隊(duì)在 AI-Native 研發(fā)模式中將代碼倉庫作為系統(tǒng)事實(shí)的唯一來源。其核心思路包括三點(diǎn)結(jié)構(gòu)即架構(gòu)系統(tǒng)架構(gòu)通過目錄結(jié)構(gòu)、模塊劃分和依賴關(guān)系顯式表達(dá)。AI 可以通過閱讀倉庫結(jié)構(gòu)理解系統(tǒng)層級而不是依賴外部設(shè)計(jì)文檔。代碼即規(guī)則業(yè)務(wù)規(guī)則、校驗(yàn)邏輯和狀態(tài)流轉(zhuǎn)盡量通過類型系統(tǒng)、接口契約和代碼實(shí)現(xiàn)表達(dá)減少散落在注釋或外部文檔中的隱式約定。文檔即約束AGENTS.md、README.md、API 契約等文檔與代碼共存于同一倉庫并作為 AI 的補(bǔ)充說明書。文檔不是孤立說明而是與代碼實(shí)現(xiàn)共同接受校驗(yàn)。這種設(shè)計(jì)的價(jià)值在于減少 AI 的信息缺口。AI 不再需要在多個(gè)來源之間拼接上下文而是以倉庫為基準(zhǔn)獲取事實(shí)。當(dāng)答案始終存在于倉庫中時(shí)AI 生成結(jié)果的一致性才有基礎(chǔ)。三、Spec-Driven Development從修改代碼到演進(jìn)規(guī)范倉庫唯一真源解決的是事實(shí)從哪里來Spec-Driven Development 解決的是 AI 如何基于事實(shí)執(zhí)行。規(guī)范驅(qū)動(dòng)開發(fā)的核心是把軟件維護(hù)的重點(diǎn)從直接修改代碼轉(zhuǎn)向維護(hù)產(chǎn)生代碼的規(guī)范。在楊夕凱及其團(tuán)隊(duì)的實(shí)踐中規(guī)范被拆成三層遞進(jìn)結(jié)構(gòu)Spec定義做什么Spec 層描述需求目標(biāo)、接口契約和數(shù)據(jù)模型。它是 AI 理解任務(wù)的起點(diǎn)。對于服務(wù)端接口Spec 需要明確字段語義、參數(shù)約束、錯(cuò)誤碼和狀態(tài)流轉(zhuǎn)對于端側(cè)能力Spec 需要說明組件職責(zé)、調(diào)用前提和平臺(tái)差異。Plan定義怎么做Plan 層描述技術(shù)方案包括架構(gòu)決策、技術(shù)選型和模塊拆分。它讓 AI 在生成代碼前知道應(yīng)該遵循哪條實(shí)現(xiàn)路徑而不是自由發(fā)揮。Task定義做到什么程度Task 層描述驗(yàn)收標(biāo)準(zhǔn)、測試要求和輸出格式。它讓 AI 的交付結(jié)果可檢查、可驗(yàn)證而不是停留在看起來完成了的狀態(tài)。這種三層結(jié)構(gòu)使 AI 生成過程具備可追溯性。當(dāng)結(jié)果不符合預(yù)期時(shí)修正對象不只是代碼本身而是產(chǎn)生錯(cuò)誤代碼的 Spec、Plan 或 Task。規(guī)范因此成為可持續(xù)演進(jìn)的工程資產(chǎn)。四、三級分層規(guī)范全局一致與局部靈活兼顧統(tǒng)一規(guī)范并不意味著所有項(xiàng)目使用同一套細(xì)則。為了兼顧全局一致性和局部靈活性楊夕凱團(tuán)隊(duì)采用三級分層規(guī)范模型全局規(guī)范層、項(xiàng)目規(guī)范層和模塊規(guī)范層。4.1 全局規(guī)范層跨項(xiàng)目基線標(biāo)準(zhǔn)全局規(guī)范層定義跨項(xiàng)目、跨團(tuán)隊(duì)的基線標(biāo)準(zhǔn)是所有 AI Agent 的公共知識。其物理載體包括全局 Skills 和公用配置主要內(nèi)容包括編碼風(fēng)格規(guī)范統(tǒng)一命名約定、格式化規(guī)則和目錄規(guī)范。架構(gòu)約束規(guī)范明確分層依賴規(guī)則、模塊邊界和跨模塊通信協(xié)議。安全基線規(guī)范約束密鑰管理、輸入校驗(yàn)和權(quán)限檢查等最低安全要求。API 設(shè)計(jì)規(guī)范要求接口遵循 RESTful 標(biāo)準(zhǔn)并統(tǒng)一錯(cuò)誤碼、版本策略和請求響應(yīng)格式。全局規(guī)范的作用是讓不同 Agent、不同項(xiàng)目、不同任務(wù)共享同一套基礎(chǔ)標(biāo)準(zhǔn)避免每個(gè)團(tuán)隊(duì)重復(fù)定義基礎(chǔ)規(guī)則。4.2 項(xiàng)目規(guī)范層倉庫級操作手冊項(xiàng)目規(guī)范層繼承全局規(guī)范并針對具體項(xiàng)目做定制。其物理載體是倉庫根目錄下的規(guī)范文件集合核心文件包括AGENTS.md項(xiàng)目全景地圖作為 AI 的導(dǎo)航入口。內(nèi)容控制在較短篇幅內(nèi)包含項(xiàng)目說明、工作規(guī)則、模塊索引和輸出格式要求。README.md面向人類的項(xiàng)目說明同時(shí)為 AI 提供項(xiàng)目背景。docs/architecture/存放架構(gòu)總覽、層級依賴規(guī)則、核心數(shù)據(jù)模型和接口契約。.agents/存放 AI 歷史決策、錯(cuò)誤修復(fù)記憶和自進(jìn)化信息。項(xiàng)目規(guī)范層的關(guān)鍵設(shè)計(jì)是AGENTS.md是地圖而不是手冊。它只做索引和指路詳細(xì)內(nèi)容通過鏈接按需加載避免一次性塞入過多上下文。4.3 模塊規(guī)范層就近參考的局部上下文模塊規(guī)范層聚焦單一模塊負(fù)責(zé)提供局部上下文。典型文件包括模塊級AGENTS.md描述模塊職責(zé)邊界、內(nèi)部依賴和特殊約束。模塊README.md說明模塊公共 API、使用示例和配置參數(shù)。AI 在執(zhí)行任務(wù)時(shí)按照從近到遠(yuǎn)的優(yōu)先級參考規(guī)范先看模塊規(guī)范再看項(xiàng)目規(guī)范最后參考全局規(guī)范。這樣既能保證整體一致性也能保留模塊級靈活性。五、AGENTS.mdAI 的項(xiàng)目入口文件在多 Agent 協(xié)同場景中AGENTS.md承擔(dān) AI 入口文件的角色。它可以理解為面向 AI Agent 的 README用于告訴 AI 當(dāng)前倉庫是什么、有哪些模塊、應(yīng)該遵循哪些規(guī)則、輸出格式是什么。在楊夕凱主導(dǎo)的實(shí)踐中AGENTS.md有幾個(gè)明確設(shè)計(jì)原則短小清晰項(xiàng)目級AGENTS.md控制在約 100 行以內(nèi)避免占用過多上下文窗口。導(dǎo)航優(yōu)先不堆疊全部細(xì)節(jié)而是提供模塊導(dǎo)航索引和關(guān)鍵規(guī)則入口。按需加載詳細(xì)架構(gòu)、接口契約和測試要求通過鏈接指向具體文檔AI 根據(jù)任務(wù)需要讀取。與代碼同倉維護(hù)AGENTS.md與代碼一起演進(jìn)避免文檔長期落后于實(shí)現(xiàn)。這種設(shè)計(jì)讓 AI 進(jìn)入倉庫后能夠快速建立項(xiàng)目認(rèn)知。對于多 Agent 并行生成場景統(tǒng)一入口文件還能減少不同 Agent 因理解路徑不同而產(chǎn)生的輸出差異。六、端云同倉讓 AI 具備全棧上下文端云一體是楊夕凱團(tuán)隊(duì)規(guī)范體系中的另一個(gè)關(guān)鍵設(shè)計(jì)。傳統(tǒng)研發(fā)中客戶端與服務(wù)端往往分屬不同倉庫、不同技術(shù)棧和不同團(tuán)隊(duì)。對人類工程師而言這種拆分可以通過溝通和文檔彌補(bǔ)但對 AI Agent 而言跨倉庫上下文缺失會(huì)直接影響生成質(zhì)量。端云同倉的目標(biāo)是將客戶端能力、云端服務(wù)、共享類型定義和基礎(chǔ)設(shè)施配置納入同一個(gè)工程體系中。這樣 AI 可以在一次上下文中理解完整鏈路而不是只看到局部代碼。端云同倉帶來的工程收益主要包括AI 可以跨越端云邊界追蹤類型定義和接口契約。AI 在修改服務(wù)端接口時(shí)可以同步感知客戶端調(diào)用邏輯。AI 可以發(fā)現(xiàn)并消除端云之間的冗余定義和不一致性。AI 能夠基于全局視角進(jìn)行接口設(shè)計(jì)和影響面分析。對于超級應(yīng)用來說端云同倉不是簡單地把代碼放進(jìn)一個(gè)目錄而是要求統(tǒng)一構(gòu)建工具鏈、依賴管理、測試框架和發(fā)布流程。只有工程治理也統(tǒng)一AI 才能用一套規(guī)則操作整個(gè)系統(tǒng)。七、自文檔化代碼降低 AI 的理解成本規(guī)范最終要落到代碼層面。為了讓 AI 生成結(jié)果穩(wěn)定代碼本身需要具備自文檔化能力即通過命名、類型、接口和依賴表達(dá)清晰語義。該團(tuán)隊(duì)在代碼級規(guī)范中強(qiáng)調(diào)幾個(gè)要點(diǎn)7.1 語義化命名變量、函數(shù)和類型名稱需要完整表達(dá)意圖避免縮寫和模糊命名。例如calculateOrderTotalPrice()優(yōu)于calcOTP()PaymentTransaction優(yōu)于DataObj。AI 依賴名稱理解語義命名越清晰生成和修改的確定性越高。7.2 類型安全優(yōu)先強(qiáng)類型系統(tǒng)是 AI 的重要約束工具。該實(shí)踐要求公共 API 具備完整類型簽名避免使用寬泛類型并通過聯(lián)合類型和字面量類型約束取值范圍。類型系統(tǒng)可以在 AI 生成階段提前暴露錯(cuò)誤減少運(yùn)行時(shí)不確定性。7.3 接口契約標(biāo)準(zhǔn)化接口需要遵循統(tǒng)一規(guī)范包括明確的 HTTP 方法語義、標(biāo)準(zhǔn)化錯(cuò)誤響應(yīng)格式、版本化策略和完整的接口定義。接口契約越標(biāo)準(zhǔn)AI 越容易生成正確的調(diào)用代碼和測試用例。7.4 零隱式依賴模塊依賴必須顯式聲明不依賴全局狀態(tài)、環(huán)境變量魔法或運(yùn)行時(shí)注入。AI 應(yīng)能通過閱讀模塊聲明和配置文件理解依賴關(guān)系。這一要求是組件可獨(dú)立測試、可復(fù)用的基礎(chǔ)。7.5 函數(shù)職責(zé)單一長函數(shù)會(huì)增加 AI 定位問題和理解邏輯的難度。職責(zé)單一的小函數(shù)更容易被 AI 正確理解、修改和測試。對于長時(shí)程 Agent 任務(wù)清晰的函數(shù)邊界也有助于降低上下文消耗。八、自動(dòng)化門禁讓規(guī)范可驗(yàn)證規(guī)范如果只依賴人工審查很難匹配 AI 高速生成的節(jié)奏。因此團(tuán)隊(duì)將規(guī)范約束接入自動(dòng)化門禁讓不符合規(guī)則的產(chǎn)出在進(jìn)入倉庫前被攔截。自動(dòng)化門禁主要覆蓋幾類檢查架構(gòu)合規(guī)性檢查驗(yàn)證代碼變更是否突破模塊邊界、是否違反依賴方向、是否兼容既有接口契約。格式化與結(jié)構(gòu)校驗(yàn)檢查目錄結(jié)構(gòu)、文件命名、模板字段和文檔引用是否符合標(biāo)準(zhǔn)。安全掃描對新增代碼進(jìn)行安全漏洞掃描并識別潛在風(fēng)險(xiǎn)。性能回歸檢測對關(guān)鍵路徑變更執(zhí)行性能基準(zhǔn)測試防止性能劣化。文檔一致性檢查驗(yàn)證文檔引用鏈接、接口索引和示例代碼是否完整存在。這些門禁讓規(guī)范從建議變成約束。AI 生成的代碼不僅要寫出來還要通過統(tǒng)一標(biāo)準(zhǔn)檢查后才能進(jìn)入主倉庫。這有助于在源頭控制熵增而不是等問題積累后再治理。九、自進(jìn)化機(jī)制規(guī)范不是靜態(tài)文檔統(tǒng)一規(guī)范還需要持續(xù)演進(jìn)。AI Agent 在執(zhí)行過程中會(huì)遇到新的錯(cuò)誤模式、新的架構(gòu)決策和新的工程約束這些信息如果只停留在單次任務(wù)日志中價(jià)值有限。團(tuán)隊(duì)通過.agents/memory-session/等目錄沉淀執(zhí)行經(jīng)驗(yàn)其中包含兩類典型內(nèi)容ERRORS.md記錄 AI 執(zhí)行中的典型錯(cuò)誤和解決方案避免同類錯(cuò)誤重復(fù)發(fā)生。LEARNINGS.md記錄關(guān)鍵架構(gòu)決策包括背景、取舍和最終選擇幫助 AI 理解為什么這樣設(shè)計(jì)。這些經(jīng)驗(yàn)會(huì)反饋到規(guī)范體系中。當(dāng)某類問題反復(fù)出現(xiàn)時(shí)團(tuán)隊(duì)可以將其轉(zhuǎn)化為新的規(guī)則、模板或門禁檢查。規(guī)范因此從靜態(tài)文檔變成動(dòng)態(tài)工程系統(tǒng)能夠隨著 AI 生成規(guī)模和頻率的提升持續(xù)優(yōu)化。十、抗熵架構(gòu)的工程價(jià)值從工程治理角度看Spec as AIOS 的核心價(jià)值不是增加文檔而是把規(guī)范變成 AI 可執(zhí)行的操作系統(tǒng)。倉庫唯一真源提供事實(shí)基礎(chǔ)Spec-Driven Development 提供執(zhí)行路徑三級分層規(guī)范提供治理結(jié)構(gòu)AGENTS.md 提供入口導(dǎo)航端云同倉提供全棧上下文自動(dòng)化門禁提供質(zhì)量約束自進(jìn)化機(jī)制提供持續(xù)改進(jìn)能力。這套體系解決的是多 Agent 并行生成下的一致性問題。不同 Agent 可以在同一套規(guī)范下工作不同任務(wù)可以在同一套倉庫事實(shí)中追溯不同生成結(jié)果可以通過同一套門禁驗(yàn)證。AI 生成速度越快規(guī)范體系的重要性越高因?yàn)樗俣缺旧聿粫?huì)自動(dòng)帶來工程效率只有可控的速度才能轉(zhuǎn)化為穩(wěn)定交付能力。需要明確的是從工程落地的客觀規(guī)律來看這一方案在標(biāo)準(zhǔn)化、新建模塊的場景下效果顯著但對于高度定制化、缺乏標(biāo)準(zhǔn)化的歷史遺留復(fù)雜代碼AI 重構(gòu)成本依然較高“先治理基建、再釋放 AI”是使其生效的必要前提。同時(shí)當(dāng)前的 AI 研發(fā)模式并非完全無人化工程師仍需基于完整的 PR 與測試報(bào)告進(jìn)行最終審查人機(jī)協(xié)同仍是核心邊界。十一、未來方向從規(guī)范約束到深度托管隨著 AI Agent 能力增強(qiáng)軟件研發(fā)正在從人機(jī)協(xié)作走向 AI 深度參與、人工關(guān)鍵兜底的深度托管模式。統(tǒng)一規(guī)范是這一過程中的基礎(chǔ)設(shè)施它讓人類定義規(guī)則和邊界讓 AI 在規(guī)則內(nèi)執(zhí)行編碼、構(gòu)建、測試和修復(fù)。未來規(guī)范體系還可能進(jìn)一步與生產(chǎn)線、評測系統(tǒng)和經(jīng)驗(yàn)記憶深度結(jié)合。規(guī)范不再只是項(xiàng)目文檔而是持續(xù)學(xué)習(xí)的工程治理系統(tǒng)。它會(huì)根據(jù)真實(shí)任務(wù)反饋調(diào)整約束會(huì)根據(jù)不同場景驗(yàn)證適用范圍也會(huì)根據(jù) Agent 執(zhí)行數(shù)據(jù)優(yōu)化生成質(zhì)量。對于超級應(yīng)用而言控制 AI 代碼熵增不是一次性工程而是長期演進(jìn)過程。只有當(dāng)規(guī)范、倉庫、門禁和生產(chǎn)線形成閉環(huán)AI 原生研發(fā)才能從快速生成走向穩(wěn)定交付。