AI Coding 实践总结 (2026-04-28)

结合团队知识库与落地实践, 输出一份当前阶段的 AI Coding 全景总结

从传统工程到 AI 团队负责人

2025 年末我还觉得 AI 写代码只是玩具, 半年过去, 我已经很少亲自打开 IDE 手敲业务代码了。

不是 AI 突然变聪明了——是我们对 AI 的用法彻底变了。从最初的"让它写个函数试试", 到如今用 OpenSpec 拆需求、用 Skills 定规范、用子 Agent 并行干活, 这个转变发生在不到 6 个月的时间里。

回头看, 核心转变只有一个：角色切换。不再是"自己把代码写对", 而是"让 AI 把代码写对"。你的精力从 80% 编码 + 20% 设计, 反转为 80% 需求拆解、规范制定、架构设计和结果审核。

工具链: CLI 优先, IDE 辅助

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

我们选择了 OpenCode 作为主力 CLI 工具, 搭配 VS Code 做代码审查。原因很简单：

• CLI 轻量、可多开、一个项目能并行多个任务
• CLI 界面信息清晰, 容易跟踪 AI 的思路, 方向跑偏时能随时打断纠正
• IDE 用于审代码、做文件操作和 Git 管理

工具搭配上, 底层模型选用 GLM-5.1 和 Kimi K2.6 作为主力, MiniMax M2.7 做性价比补充。模型变化太快, 基本一代版本一代神, 保持关注就好。

Bash is All You Need

CLI 工具的核心操作——文件检索、关键字查找、API 调试——都依赖 Bash 生态里的 glob、grep、curl、jq 等工具。Claude Code 核心工程师说的 "Bash is All You Need" 不是玩笑。

我们实践下来发现, 给 AI 准备好 Bash 环境 (Fish Shell + 国内镜像源 + 常用工具链) 能让任务成功率提升一大截。Windows 同学用 WSL2 是最佳选择。

制定项目"宪法": AGENTS.md

参考 [[aicoding-practice]]

项目根目录的 AGENTS.md 是整个 AI Coding 的最高指导规范。怎么写？

想象团队招了一个资深工程师, 技术上没问题, 但对业务和技术架构一无所知。为了让他能上手干活, 你会培训什么？

但注意：不要把所有东西都塞进去。我们采用渐进式披露原则：

• AGENTS.md 只放核心规则和索引
• API 文档、数据库 Schema、术语表放到独立文档, 在 AGENTS.md 里引用查询方式
• 高频知识做成 Skills, 按需激活

这样 AI 在需要时自然会去查, 而不是一开始就被上下文塞满。

Spec Driven > Vibe Coding

团队实践中最深刻的体会：Vibe Coding（对话式迭代）只适合个人原型和小脚本。企业级项目必须用 Spec Driven。

我们引入了 OpenSpec 工作流: explore → propose → apply → archive。每个变更先写 proposal, 再出 design, 拆 tasks, 然后交给 AI 执行。这个流程让代码质量从"随缘"变成了"可控"。

另外, Glue Coding（胶水编程） 也是我们的核心实践：不让 AI 从零写, 而是给 AI 优秀的代码模板让它"复制粘贴"。4 层材料体系——开发规范、代码骨架、领域知识、任务规格——让代码采纳率从 50% 提升到 90% 以上。

Skills: 基础设施而非提示词

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

我们把团队积累的规范和工作方法封装为可复用的 Skills, 目前已有 10 个：

• wiki-backend-quality-standard - Go 后端质量交付标准
• wiki-go-zero-grpc-workflow - gRPC 服务开发流程
• wiki-go-zero-api-workflow - BFF 层 HTTP API 开发流程
• wiki-deployment-standard - 生产部署标准
• wiki-code-templates - 代码模板 (proto/单测/gorm gen/错误码/中间件)
• wiki-bitbff-mock - Mock 数据生成与 API 一致性检查
• wiki-flow - 云效流水线触发
• wiki-system-context - 系统上下文维护
• wiki-aicoding-training - 实训内容生成
• metersphere - 持续测试平台操作

Skills 是基础设施, 不是提示词。它们可以在不同工具间复用, 是团队工程资产的硬编码。

上下文管理: L0/L1/L2 三层架构

模型上下文 200K 看起来很长, 但项目长期记忆、工具调用结果、对话记录都要塞进去, 很容易占满。我们采用三层上下文架构：

• L0 项目级: AGENTS.md + 核心规则
• L1 架构级: 系统上下文知识库 (术语表、路由规则、数据平台等)
• L2 开发级: 当前任务相关文档

关键原则：

• 任务完成后开新会话, 不在旧会话里持续聊
• 关键节点后主动压缩上下文
• 用 rtk 工具降低 token 消耗 (可省 80%)

度量: 从"感觉有效"到"数据证明"

参考 [[ai-coding-metrics]]

我们参考了天猫的 AI Coding 度量体系的三层结构：

1. 质量层: 业务测试用例 + 复杂度矩阵 (业务复杂度 × 组件成熟度, 9 宫格分类)
2. 管道层: "调用 → 命中 → 采纳"漏斗, 四象限分析知识有效性
3. 结果层: AI 参与率、代码采纳率、Token 成本

关键指标：知识库采纳率从 18% 提升到 35%。这不是模型变强了, 而是上下文工程做扎实了。

组织落地: 流程重构而非人员替换

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

AI 替代的不是人, 是流程。真正的问题是管理, 不是 AI。

我们的团队落地策略：

• Q2-Q4 三步走: 10% → 20% → 30% 提效目标
• 人员升级: 码农 → 工程师, 懂业务成为护城河
• AI-First 团队: 指标 = AI 初稿准确率, 底座 = 上下文工程, 载体 = Skill-as-Code
• 实训体系: 持续aicoding培训 (快速入门 → go-zero 开发 → 内部实训每周进行)

最新一期实训 (2026-04-27) 覆盖战略落地、度量体系、组织适配、实战项目四个模块。综合实战完成率 55%, 平均分 68——还在爬坡阶段, 但方向是对的。

编码规范与红线

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

7 条编码规范 + 16 条不可违反的红线：

规范:

1. 先思考再编码
2. 简单优先
3. 精准变更
4. 目标驱动执行
5. 子 Agent 策略
6. 自我改进循环
7. 自主 Bug 修复

红线示例:

• 唯一性约束必须加
• 关键业务操作必须事务包裹
• 金额必须增量更新
• 接口必须幂等重试
• err 必须判, 不能 _
• 敏感数据脱敏

这些红线是代码评审的必查项, 也是 AI 犯错时回溯规则文件补充的依据。

出错了怎么办

AI 犯错是常态。按这个顺序排查：

1. 判断根源: 模型智能不够, 还是上下文信息不足？
2. 模型问题: 换更强的上位模型, 或者人工拆解任务, 给明确路径指引
3. 信息缺失: 补充关键信息 (API 文档等), 让 AI 先确认信息是否足够
4. 重复犯错: 补充 AGENTS.md, 添加约束规则
5. 总结文档: 复杂问题排查后让 AI 整理过程, 下次直接参考

关键心态：尽可能坚持让 AI 自己处理问题, 你只给提示和指导。和 AI 结对写代码需要磨合, 你要学会做一个 Leader, 而不是手下人一出错就亲力亲为。

案例参考

• 一天重写 JSONata: 用 50 万的 K8s 集群, Go 旧引擎替换
• 天猫 AI Coding: 97.9% 采纳率, 核心实践就是胶水编程
• 54 万行 PHP 重构: 两周, 4 人 + 9 个 Cursor 账号, $1800, 零回滚零 P0 事故
• 核心后端系统 AI Coding: 约束清楚、边界明确、验收方式可执行, 就能参与真实交付

总结

AI Coding 带给我们的不是"程序员被替代"的焦虑, 而是一次角色升级的机会。

你不再需要把大量精力消耗在机械的编码和调试上, 而是可以把更多时间放在真正有创造性的工作里：架构设计、需求拆解、规范制定、质量把控。

输入质量决定输出质量。AI 是协作对象, 需要约束、验证和管理。做好上下文工程、建立规范体系、沉淀 Skills 资产——这些才是当前阶段 AI Coding 落地的真正瓶颈, 也是最有杠杆效应的投入点。

日期: 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]] | 内部aicoding项目实战