可复制的 AI Coding 全栈实战：比 OpenSpec 更轻量、更丝滑

本文整理自淘宝闪购高级技术专家邓立山在 QCon 全球软件开发大会 2026 北京站的分享，经 InfoQ 编辑。作者带领 60+ 成员团队推进 AI 编码落地，曾获首届阿里&蚂蚁联合最佳 AI 实践案例奖。

核心命题：AI 编码"差点意思"的三个维度

团队在生产实践中复盘出三个结构性问题：

1. AI / 工具的天然短板：AI 编码本质是概率推测，携带幻觉基因，与需求交付的确定性存在结构性矛盾。模型训练完成后知识固化，不了解具体业务上下文和现有工程完整功能结构——能写通用增删改查，却无法自动理解订单状态流转规则与团队沉淀多年的编码约定。

2. 人机协同的工程缺失：编程语言从汇编/高级语言（语义高确定性，可编译确认）变为自然语言（语气语调微妙变化即导致表意偏差）。如何将自然语言需求转化为 AI 能稳定识别执行的"确定语言"是全新难题。同时，AI 一次生成成百上千行代码，质量保障机制必须从人工逐行审查重构。

3. 认知固化：两类阻力——因幻觉不敢放手 / 担心技能退化产生"那我干什么"困惑。更深层的问题是许多人习惯做确定性可执行工作，缺少"如何驾驭 AI"的真正思考。

编辑点评：这三个维度的框架值得借鉴。第一维度是技术属性，第二维度是工程方法论，第三维度是组织心智——很多团队卡在第三层，技术方案再好也推不动。

本质思考：规范约束对象从人变为 AI

关键认知转变：以前规范约束人，现在规范必须约束 AI。

软件工程要交付确定性和可维护性软件的目标从未改变，真正改变的是生产关系。以前架构和规范存在于开发者脑海里，AI 时代写代码的不是人，AI 不知道你脑子里的架构原则和质量标准。因此需要将隐性知识显性化表达，让 AI 理解并遵守。

编辑点评：这个判断对前端工程化尤其有启发——React 组件库和构建工程中大量"约定大于配置"的隐性规范（目录约定、命名约定、构建产物约定），在 AI 编码场景下都需要显式文档化。

五个方面的系统性实践

1. 减少大模型幻觉：输入端 + 输出端控制

与大模型交互可抽象为三环节：输入 → 内部思考 → 输出。可控的是两端。

• 输入端：区分新增类需求（侧重架构设计，从零定义模块边界、数据流向、接口契约）与修改类需求（侧重影响分析：改动点、波及上下游、隐藏技术债），分别定义规范模板。明确要求——AI 在需求分析中有不清楚的地方必须集中列出等待人工确认，不允许自由发挥和随意猜测。
• 输出端：为需求分析、代码编写、代码质量检查分别建立不同层次的规范约束。以业务逻辑层编码规范为例，涵盖代码组织要求、编码质量注意事项、异常处理统一方式——本质是把优秀工程师的隐性经验显性化，交给 AI 严格执行。

2. 工程结构宪法性约束

先让 AI 描述整个工程结构（架构模式、目录结构、技术栈、编码风格），作为后续所有编码行为的"宪法性约束"。技术实现手段：rules 机制、claude.md 顶层文件结构。

一旦工程架构宪法确立，AI 在编码任何阶段都必须遵守，不会出现乱放位置、随意破坏分层的问题。这个过程本身也是重新审视现有架构合理性的契机——长期迭代中模块职责可能已偏离设计意图。

3. 编码颗粒度：七个等级

将编码颗粒度划分为七个等级：

• 越往上：颗粒度越小，可控性越强但效率提升有限
• 越往下：颗粒度越大，效率越高但质量可控性越差

当前团队整体实践颗粒度是单工程级别——一个需求只需在一个工程内实现，AI 可一次性完整生成所有相关代码。随着模型能力增强，可向更粗颗粒度持续探索。

4. 任务拆分机制

解决大模型上下文"挤爆"问题：AI 先将整体任务拆分为若干子任务，以任务为单位记录编码状态。即使中途会话中断，也可方便恢复上下文无须重新开始。

真实线上案例：整个需求涉及 66 个文件编码，共计超过 5000 行代码。全程只在中间输入过两个字——"继续"，就接续完成了剩余全部工作。

5. 复用性与扩展性设计

• 复用性：解耦业务逻辑与编码规范——规范文件完全不包含具体业务逻辑，只定义规则和约束，整套方案可低成本推广到整个团队。
• 扩展性三维度：
  1. 研发流程组件化：将需求分析、编码等不同研发阶段包装为独立 skills
  2. 场景文件化隔离：新增类需求和修改类需求对应不同规范文件
  3. 编码内容结构化：每条规范可清晰归属到某个流程、场景和模块

质量保障闭环：AI 自审 + 人工终审

AI 一次性生成成千上万行代码后，通过闭环机制保障质量：

AI 自我审查四维度：

• 业务逻辑与代码实现是否一致
• 整体代码设计是否合理
• 代码是否存在明显质量缺陷
• 是否符合团队编码规范

为 code review 专门编写 spec 规范，定义四个审查维度：功能逻辑、代码设计、代码质量、代码规范。

实践效果：

• 通常迭代 3-5 次产生高质量代码
• 人工做最终"切壳检查"——聚焦高风险、线上止损关键细节、边缘 case、安全敏感点
• 后端实战案例：首次 AI 自审约 70 分 → 按 CR 报告优化后第二次 96 分 → 本地编译一次性通过

方案演进时间线

• 2024 年 8 月：行业掀起智能补全热潮
• 2024 年下半年：团队开始系统性探索，坚持质量优先
• 2025 年 2 月：第一版方案，通过 prompt 技术封装整套思路，可一次性生成领域服务全部方法和业务逻辑（如门店管理增删改查）。规范手动选择后交给 AI，未实现自动化
• 2025 年 7-8 月：spec coding 兴起，引入 rules 机制升级方案，增加 AI 自动生成技术方案能力和修改类需求支持
• 2026 年：综合运用 skills + rules + spec，从研发流程规范和编码规范两个维度重构。开箱即用，用户几乎感知不到规范存在——skills 由模型根据语义自动识别加载

OpenSpec vs Spec-Kit 实践反思

调研两类业界流行方案后，最初选择基于 OpenSpec 集成自有编码规范，深度实践后效果不理想：

OpenSpec 优势（恰好是 Spec-Kit 短板）：学习上手成本低、自动化程度高

OpenSpec 不足（恰好是 Spec-Kit 优势）：

1. 汉化不够：生成文件中英文混杂，同质化参差不齐
2. 层级混淆：未清晰区分 requirement 和 scenario——将"添加门店""删除门店"作为 scenario，但按正确规范它们应属 requirement（功能点），scenario 应是"成功删除门店""取消删除门店"等具体用例
3. 前后端混合拆分：前端需求关注交互，后端需求关注业务逻辑，强行放在一起增加协作负担
4. 拆分顺序不符研发习惯：实际开发通常先定义接口文档→底层数据层→应用层，OpenSpec 缺乏清晰依赖关系
5. 扩展困难：尝试集成自有规范时流程变臃肿；六个模块需求被拆成六个独立 spec 文档，跨文件逐一确认效率低

编辑点评：requirement vs scenario 的层级混淆是 spec 工程的常见坑。前端场景同理——"添加组件"是 requirement，"在暗色主题下添加组件"才是 scenario。这个区分对生成代码的组织逻辑影响很大。

Rules / Prompt / Skills 职责定位

基于实践反馈重新定位主流技术要素：

• Rules：整体 AI 规范的约束承载，告诉 AI"不要踩的红线"，没有商量余地的硬约束
• Skills：把具体业务流程和 spec 打包在一起，实现全流程自动化编排，模型根据语义自动识别加载

法治体系类比：

用户侧只需将方案拷贝到本地工程目录下，使用过程中完全无感。

四个 Skills 模块

1. 工程结构分析：梳理当前工程架构全貌
2. 需求分析：将需求结构化描述清楚
3. 编码规范：覆盖不同层次代码编写约束
4. Code review 规范：定义审查维度和标准

编码过程中将相关过程文档统一管理（包括数据库 DDL 脚本等），一次性生成。开发者编码完成后无需回头补文档，直接拿生成文件与协作方对接。

后端研发流程（五部分）

1. 功能结构分析（一次性工作，整个工程复用同一套描述）
2. 需求分析：生成结构化 spec 文档 + 任务拆分。新增类需求产出功能清单、模块详细分析、待澄清列表；修改类需求先分析现有功能链路，再给改动点，最后分析潜在影响范围
3. 需求澄清：集中收集 AI 分析中的不确定项，形成待确认列表等待人工裁决——极其关键，需求分析不清晰后续所有工作可能推倒重来。可一次性提交所有待确认问题，避免逐个澄清（每轮分析 2-3 分钟，交互效率低）
4. 编码实现：只需对 AI 说"帮我实现编码"几个字，按既定规范完成全部代码及过程文件产出
5. 代码质量检查：借助 skills 多维度 review，根据审查报告驱动优化迭代

编码实现 + 质量检查构成小循环，通常迭代 3-5 次产出高质量代码。

前端编码流程

与后端整体框架一致，但拆分思路不同：

• 前端：需求 → 整体页面 → 业务组件 → 组件交互逻辑
• 后端：需求 → 功能模块 → 功能点 → 业务规则

三类需求实践：

1. 完整 PRD 文档需求：页面元素交互逻辑还原度高
2. 一句话想法型需求：适合技术驱动提效，AI 辅助分析设计整体技术方案，但组件交互逻辑缺失需后期多轮补充
3. 管理类接口页面（后端工程师常用）：直接把结构文档给 AI，还原度高

前端 AI 审查初始评分 4.3/5 分，通过代码生成与 CR 迭代循环逐步收敛到高质量状态。

编辑点评：前端"一句话想法型需求"的痛点很真实——React 组件的交互逻辑（受控/非受控、状态提升、副作用时序）很难从一句话推导出来。这也提示前端 AI 编码更需要结构化的交互逻辑描述规范，而非仅靠 PRD。

推广运营机制

不选择 KPI 强推，通过营造编码氛围驱动自驱力：

• 技术分享：定期邀请最佳实践者分享经验，形成"用出成效的人教想学的人"的良性带动
• 月度评审：邀请 HR、leader、大部门负责人参与，每月评选团队和个人编码先锋
• 推广策略：先小范围试点打磨 → 每个团队选 1-2 个需求、1-2 个人一对一辅导走完全流程 → 实践成功者回团队当布道师 → 形成分享-实践-沉淀-再分享飞轮

硬性指标：

• AI 编码率：2025 年 4 月 9.0% → 9 月 89.2%（9 倍增长）
• 代码质量：千行代码 Bug 率、发布回滚率始终保持在预期范围
• 累计产出 24 篇高质量 ATA 文章，获阿里&蚂蚁联合最佳 AI 实践奖 + 年度最佳专题奖

未来演进方向

端到端持续交付闭环，包含三个层级的循环：

1. 研发阶段小循环：编码 → 优化 → CR → 单元测试，确保编码阶段锁定质量
2. 测试-研发小循环：编码完成后进入自动化测试，测试报告反馈驱动下一轮迭代
3. 大循环：从需求阶段延伸到线上运营，形成完整反馈链路

程序员价值重塑：从编码执行者走向架构决策者 + 质量守门员的复合角色。从过去涉及模块细节设计和逐行编码，转变为承担整体架构设计及 AI 运行环境设计。从"代码即规范"进入"规范即代码"时代——未来可能不再把大量时间花在逐行阅读代码上，而是在设计和迭代规范本身。

编辑点评："规范即代码"的提法值得前端工程化借鉴。React 组件库的 design tokens、构建工程的配置约定、monorepo 的包边界规则，这些本来就是"规范"，现在需要以 AI 可读的形式（rules / skills / spec）固化下来。这对资深工程师意味着——架构能力和抽象能力溢价会继续上升，而纯实现执行的价值会持续被 AI 稀释。作者最后一句总结很到位：AI 不是银弹，但它是超级杠杆，用好它需要更清晰的架构思维、更严谨的规范意识、更深刻的软件工程哲学。

作者介绍

邓立山，淘宝闪购高级技术专家。作为团队架构师主导架构整治与演进，使人均应用数从 1.3 降至 0.62，每年研发资源降本上百万元；作为稳定性负责人多次主导双 11 大促保障。2025 年 2 月末即开始体系化践行 SDD 编码，较业界同类方案更早探索并沉淀可复用方法。