結(jié)合團(tuán)隊(duì)知識庫與落地實(shí)踐, 輸出一份當(dāng)前階段的 AI Coding 全景總結(jié)

從傳統(tǒng)工程到 AI 團(tuán)隊(duì)負(fù)責(zé)人

2025 年末我還覺得 AI 寫代碼只是玩具, 半年過去, 我已經(jīng)很少親自打開 IDE 手敲業(yè)務(wù)代碼了。

不是 AI 突然變聰明了——是我們對 AI 的用法徹底變了。從最初的"讓它寫個函數(shù)試試", 到如今用 OpenSpec 拆需求、用 Skills 定規(guī)范、用子 Agent 并行干活, 這個轉(zhuǎn)變發(fā)生在不到 6 個月的時間里。

回頭看, 核心轉(zhuǎn)變只有一個：角色切換。不再是"自己把代碼寫對", 而是"讓 AI 把代碼寫對"。你的精力從 80% 編碼 + 20% 設(shè)計(jì), 反轉(zhuǎn)為 80% 需求拆解、規(guī)范制定、架構(gòu)設(shè)計(jì)和結(jié)果審核。

工具鏈: CLI 優(yōu)先, IDE 輔助

參考 [[aicoding-tools-eval-2026]]

我們選擇了 OpenCode 作為主力 CLI 工具, 搭配 VS Code 做代碼審查。原因很簡單：

• CLI 輕量、可多開、一個項(xiàng)目能并行多個任務(wù)
• CLI 界面信息清晰, 容易跟蹤 AI 的思路, 方向跑偏時能隨時打斷糾正
• IDE 用于審代碼、做文件操作和 Git 管理

工具搭配上, 底層模型選用 GLM-5.1 和 Kimi K2.6 作為主力, MiniMax M2.7 做性價比補(bǔ)充。模型變化太快, 基本一代版本一代神, 保持關(guān)注就好。

Bash is All You Need

CLI 工具的核心操作——文件檢索、關(guān)鍵字查找、API 調(diào)試——都依賴 Bash 生態(tài)里的 glob、grep、curl、jq 等工具。Claude Code 核心工程師說的 "Bash is All You Need" 不是玩笑。

我們實(shí)踐下來發(fā)現(xiàn), 給 AI 準(zhǔn)備好 Bash 環(huán)境 (Fish Shell + 國內(nèi)鏡像源 + 常用工具鏈) 能讓任務(wù)成功率提升一大截。Windows 同學(xué)用 WSL2 是最佳選擇。

制定項(xiàng)目"憲法": AGENTS.md

參考 [[aicoding-practice]]

項(xiàng)目根目錄的 AGENTS.md 是整個 AI Coding 的最高指導(dǎo)規(guī)范。怎么寫？

想象團(tuán)隊(duì)招了一個資深工程師, 技術(shù)上沒問題, 但對業(yè)務(wù)和技術(shù)架構(gòu)一無所知。為了讓他能上手干活, 你會培訓(xùn)什么？

但注意：不要把所有東西都塞進(jìn)去。我們采用漸進(jìn)式披露原則：

• AGENTS.md 只放核心規(guī)則和索引
• API 文檔、數(shù)據(jù)庫 Schema、術(shù)語表放到獨(dú)立文檔, 在 AGENTS.md 里引用查詢方式
• 高頻知識做成 Skills, 按需激活

這樣 AI 在需要時自然會去查, 而不是一開始就被上下文塞滿。

Spec Driven > Vibe Coding

團(tuán)隊(duì)實(shí)踐中最深刻的體會：Vibe Coding（對話式迭代）只適合個人原型和小腳本。企業(yè)級項(xiàng)目必須用 Spec Driven。

我們引入了 OpenSpec 工作流: explore → propose → apply → archive。每個變更先寫 proposal, 再出 design, 拆 tasks, 然后交給 AI 執(zhí)行。這個流程讓代碼質(zhì)量從"隨緣"變成了"可控"。

另外, Glue Coding（膠水編程） 也是我們的核心實(shí)踐：不讓 AI 從零寫, 而是給 AI 優(yōu)秀的代碼模板讓它"復(fù)制粘貼"。4 層材料體系——開發(fā)規(guī)范、代碼骨架、領(lǐng)域知識、任務(wù)規(guī)格——讓代碼采納率從 50% 提升到 90% 以上。

Skills: 基礎(chǔ)設(shè)施而非提示詞

參考 [[skills-agent-architecture-2026]]

我們把團(tuán)隊(duì)積累的規(guī)范和工作方法封裝為可復(fù)用的 Skills, 目前已有 10 個：

• wiki-backend-quality-standard - Go 后端質(zhì)量交付標(biāo)準(zhǔn)
• wiki-go-zero-grpc-workflow - gRPC 服務(wù)開發(fā)流程
• wiki-go-zero-api-workflow - BFF 層 HTTP API 開發(fā)流程
• wiki-deployment-standard - 生產(chǎn)部署標(biāo)準(zhǔn)
• wiki-code-templates - 代碼模板 (proto/單測/gorm gen/錯誤碼/中間件)
• wiki-bitbff-mock - Mock 數(shù)據(jù)生成與 API 一致性檢查
• wiki-flow - 云效流水線觸發(fā)
• wiki-system-context - 系統(tǒng)上下文維護(hù)
• wiki-aicoding-training - 實(shí)訓(xùn)內(nèi)容生成
• metersphere - 持續(xù)測試平臺操作

Skills 是基礎(chǔ)設(shè)施, 不是提示詞。它們可以在不同工具間復(fù)用, 是團(tuán)隊(duì)工程資產(chǎn)的硬編碼。

上下文管理: L0/L1/L2 三層架構(gòu)

模型上下文 200K 看起來很長, 但項(xiàng)目長期記憶、工具調(diào)用結(jié)果、對話記錄都要塞進(jìn)去, 很容易占滿。我們采用三層上下文架構(gòu)：

• L0 項(xiàng)目級: AGENTS.md + 核心規(guī)則
• L1 架構(gòu)級: 系統(tǒng)上下文知識庫 (術(shù)語表、路由規(guī)則、數(shù)據(jù)平臺等)
• L2 開發(fā)級: 當(dāng)前任務(wù)相關(guān)文檔

關(guān)鍵原則：

• 任務(wù)完成后開新會話, 不在舊會話里持續(xù)聊
• 關(guān)鍵節(jié)點(diǎn)后主動壓縮上下文
• 用 rtk 工具降低 token 消耗 (可省 80%)

度量: 從"感覺有效"到"數(shù)據(jù)證明"

參考 [[ai-coding-metrics]]

我們參考了天貓的 AI Coding 度量體系的三層結(jié)構(gòu)：

1. 質(zhì)量層: 業(yè)務(wù)測試用例 + 復(fù)雜度矩陣 (業(yè)務(wù)復(fù)雜度 × 組件成熟度, 9 宮格分類)
2. 管道層: "調(diào)用 → 命中 → 采納"漏斗, 四象限分析知識有效性
3. 結(jié)果層: AI 參與率、代碼采納率、Token 成本

關(guān)鍵指標(biāo)：知識庫采納率從 18% 提升到 35%。這不是模型變強(qiáng)了, 而是上下文工程做扎實(shí)了。

組織落地: 流程重構(gòu)而非人員替換

參考 [[aicoding-org-team-2026]]

AI 替代的不是人, 是流程。真正的問題是管理, 不是 AI。

我們的團(tuán)隊(duì)落地策略：

• Q2-Q4 三步走: 10% → 20% → 30% 提效目標(biāo)
• 人員升級: 碼農(nóng) → 工程師, 懂業(yè)務(wù)成為護(hù)城河
• AI-First 團(tuán)隊(duì): 指標(biāo) = AI 初稿準(zhǔn)確率, 底座 = 上下文工程, 載體 = Skill-as-Code
• 實(shí)訓(xùn)體系: 持續(xù)aicoding培訓(xùn) (快速入門 → go-zero 開發(fā) → 內(nèi)部實(shí)訓(xùn)每周進(jìn)行)

最新一期實(shí)訓(xùn) (2026-04-27) 覆蓋戰(zhàn)略落地、度量體系、組織適配、實(shí)戰(zhàn)項(xiàng)目四個模塊。綜合實(shí)戰(zhàn)完成率 55%, 平均分 68——還在爬坡階段, 但方向是對的。

編碼規(guī)范與紅線

參考 rules/CODING.md 和 docs/coding-standards-index.md

7 條編碼規(guī)范 + 16 條不可違反的紅線：

規(guī)范:

1. 先思考再編碼
2. 簡單優(yōu)先
3. 精準(zhǔn)變更
4. 目標(biāo)驅(qū)動執(zhí)行
5. 子 Agent 策略
6. 自我改進(jìn)循環(huán)
7. 自主 Bug 修復(fù)

紅線示例:

• 唯一性約束必須加
• 關(guān)鍵業(yè)務(wù)操作必須事務(wù)包裹
• 金額必須增量更新
• 接口必須冪等重試
• err 必須判, 不能 _
• 敏感數(shù)據(jù)脫敏

這些紅線是代碼評審的必查項(xiàng), 也是 AI 犯錯時回溯規(guī)則文件補(bǔ)充的依據(jù)。

出錯了怎么辦

AI 犯錯是常態(tài)。按這個順序排查：

1. 判斷根源: 模型智能不夠, 還是上下文信息不足？
2. 模型問題: 換更強(qiáng)的上位模型, 或者人工拆解任務(wù), 給明確路徑指引
3. 信息缺失: 補(bǔ)充關(guān)鍵信息 (API 文檔等), 讓 AI 先確認(rèn)信息是否足夠
4. 重復(fù)犯錯: 補(bǔ)充 AGENTS.md, 添加約束規(guī)則
5. 總結(jié)文檔: 復(fù)雜問題排查后讓 AI 整理過程, 下次直接參考

關(guān)鍵心態(tài)：盡可能堅(jiān)持讓 AI 自己處理問題, 你只給提示和指導(dǎo)。和 AI 結(jié)對寫代碼需要磨合, 你要學(xué)會做一個 Leader, 而不是手下人一出錯就親力親為。

案例參考

• 一天重寫 JSONata: 用 50 萬的 K8s 集群, Go 舊引擎替換
• 天貓 AI Coding: 97.9% 采納率, 核心實(shí)踐就是膠水編程
• 54 萬行 PHP 重構(gòu): 兩周, 4 人 + 9 個 Cursor 賬號, $1800, 零回滾零 P0 事故
• 核心后端系統(tǒng) AI Coding: 約束清楚、邊界明確、驗(yàn)收方式可執(zhí)行, 就能參與真實(shí)交付

總結(jié)

AI Coding 帶給我們的不是"程序員被替代"的焦慮, 而是一次角色升級的機(jī)會。

你不再需要把大量精力消耗在機(jī)械的編碼和調(diào)試上, 而是可以把更多時間放在真正有創(chuàng)造性的工作里：架構(gòu)設(shè)計(jì)、需求拆解、規(guī)范制定、質(zhì)量把控。

輸入質(zhì)量決定輸出質(zhì)量。AI 是協(xié)作對象, 需要約束、驗(yàn)證和管理。做好上下文工程、建立規(guī)范體系、沉淀 Skills 資產(chǎn)——這些才是當(dāng)前階段 AI Coding 落地的真正瓶頸, 也是最有杠桿效應(yīng)的投入點(diǎn)。

日期: 2026-04-28
來源: [[aicoding-practice]] | [[aicoding-org-team-2026]] | [[aicoding-tools-eval-2026]] | [[ai-coding-metrics]] | [[ai-coding-patterns]] | [[harness-engineering-2026]] | [[skills-agent-architecture-2026]] | [[openspec-repowiki-2026]] | 內(nèi)部aicoding項(xiàng)目實(shí)戰(zhàn)