在大语言模型能力持续跃迁、AI 编码工具从 Copilot 向 Agent 形态快速演进的当下，一个核心问题逐渐浮出水面：AI 写代码很快，但在生产环境的工程化落地中，它为什么总显得“差那么点意思”？
本文整理自淘宝闪购高级技术专家邓立山在 QCon 全球软件开发大会 2026 北京站的分享《可复制的 AI Coding 全栈实战：比 OpenSpec 更轻量、更丝滑》。邓立山从一线实践者视角出发，系统分享了该团队在 AI 编码领域长达一年多的全栈实战经验、方法论的沉淀过程以及对未来演进的判断。演讲主题聚焦于“可复制的 AI Coding 全栈实战”，围绕 AI 编码可控性的本质、一套分层可扩展的规范体系、代码生成后的质量保障闭环以及团队层面的推广运营机制展开，同时回应了程序员角色在 AI 时代价值重塑这一深层命题。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
AI 编码为什么总差点意思
自 ChatGPT 爆火以来，Devin、Copilot 等 AI 编码工具接连引爆舆论，媒体关于“程序员是否即将失业”的讨论此起彼伏。这种焦虑并非毫无根据——从模型层面看，无论参数量还是上下文窗口，都发生了三个数量级以上的增长；从工具层面看，从 Copilot 到各类 Agent，能力边界也在持续扩展；从资本层面看，某公司在不到一年时间内估值从低点飙升至八千六百多亿美元，增长近五十倍。我们有充分理由相信 AI 具备写好代码的能力。然而，当我们真正将 AI 编码引入生产实践时，遇到的问题却远比宣传中复杂得多。
我们在实践中遇到的典型问题包括：AI 看似写得很快，但输出的往往只是一个代码框架，具体的业务逻辑要么空白，要么明显错误；即使代码本身能跑通，在整个应用工程中放置的位置也可能完全不对，目录结构混乱，与现有架构格格不入。这些现象反复出现之后，我不得不思考一个根本问题：到底是 AI 写不好代码，还是我们没有用好 AI？
经过系统复盘，我认为问题出在三个维度。
第一个维度是 AI /工具的天然短板。AI 编码的本质是概率推测，这就决定了它天然携带幻觉基因。但我们的业务需求交付是确定的——需求文档里规定的是什么，产出就必须是什么。这种“概率性”与“确定性”之间的张力，是 AI 编码无法回避的结构性矛盾。与此同时，大模型在训练完成后知识就固化了，它并不了解我们具体的业务上下文和现有工程的完整功能结构。它可以写出一个通用意义上的增删改查，却无法自动理解你的订单状态流转规则与团队沉淀多年的编码约定。
第二个维度是人机协同的工程缺失。在传统编程时代，无论汇编语言还是高级语言，其语义都具有高度确定性——一条语句的执行结果可被编译确认。但到了 AI 时代，编程语言变成了自然语言。自然语言的特点是，语气和语调的微妙变化就可能导致表意偏差。如何将自然语言描述的需求转化为 AI 能够稳定识别并准确执行的“确定语言”，成为了一个全新的难题。此外，过去代码质量由人工逐行审查来保障，AI 一次生成成百上千行代码之后，质量保障机制也必须随之重构。
第三个维度是我们自身认知的固化。在团队推广 AI 编码的过程中，我们发现有两类典型的阻力。一类是有同学因为 AI 存在幻觉就不敢放手尝试，宁可维持原有的纯手写模式。另一类同学则担心把编码工作交给 AI 后，自己的技能会退化，甚至会产生“那我干什么”的困惑。在实际工作中，我们还观察到一个更深层的现象：许多人更习惯做确定性的可执行工作，而缺少真正的思考——不是思考一行代码怎么写，而是思考怎么驾驭 AI，让它更好地为我的效率服务。
可以看到，整个编码范式正在经历系统性的进化。从最早的智能补全，到 vibe coding 模式，再到 SDD 规范驱动编程，以及最近广受关注的 Harness 编程，这些探索本质上都是在逐步回应上述三个维度的问题。
AI 编码可控的本质思考
让 AI 高效写出可控的生产级代码，本质上是软件工程核心思想的强化。无论是当前热门的 Harness 还是各种 IDE 集成方案，从软件工程的视角来看，追求的核心目标都不是新鲜事物。软件工程本质上一直要交付的就是具有确定性和可维护性的软件，这个目标从未改变。真正改变的是什么？是生产关系。以前代码由人来写，架构和规范约束的是人，这些规范存在于每个开发者的脑海里。到了 AI 时代，写代码的不再是人了，而是 AI。AI 并不知道你脑子里的那些架构原则和质量标准，因此我们需要将这些隐性的知识显性化地表达出来，让 AI 能够理解并遵守。这就是问题的关键：以前规范约束人，现在规范必须约束 AI。
基于这一认知，我们从五个方面展开了系统性的实践。
首先是减少大模型幻觉。与大模型的交互过程可以抽象为三个环节：给大模型的输入、大模型的内部思考、大模型的最终输出。我们能控制的是两端——输入端和输出端。在输入端，核心任务是把需求描述清楚。我们根据需求的不同特点，区分了新增类需求和修改类需求，分别定义了不同的需求规范和模板。与此同时，我们给出一个明确要求：如果 AI 在需求分析中有任何不清楚的地方，必须集中列出来等待人工确认，不允许自由发挥和随意猜测。在输出端，我们为不同开发阶段建立了不同层次的规范约束：需求分析阶段应该遵守什么规范、代码编写阶段应该遵守什么规范、代码质量检查阶段又应该遵守什么规范，每个环节都有明确的规则可依。
我们认为新增类需求和修改类需求的侧重点天然不同。新增需求的重心在于整体的架构设计，需要从零开始定义模块边界、数据流向和接口契约；而修改需求的重心则在于对现有代码的影响分析——改动点在哪里，可能波及哪些上下游，是否存在隐藏的技术债。因此我们制定了差异化的分析方案和模板，AI 会按照这些规范产出结构化的输出。
在代码执行的各个阶段，我们也分别定义了不同层次的规范，覆盖需求分析、功能结构生成、代码生成和 code review 四个关键环节。以一个典型的业务逻辑层编码规范为例，我们会把代码的组织要求、编码质量的注意事项、异常处理的统一方式都明确写在规范中。本质上，我们就是在把优秀工程师写代码时的隐性经验显性化，然后交给 AI 去严格执行。这样，在输入端需求是明确的，在输出端规范是有章可循的，产出的代码质量就具备了可预期的保障。
在多人协作的团队实践中，AI 生成的代码如何与现有工程系统兼容，是一个容易被忽略却容易留下大量技术债的地方。我们的解决方案是：先让 AI 把整个工程结构描述出来，再以此作为后续所有编码行为的“宪法性约束”。
具体来说，整个工程维度的描述包括架构模式和目录结构、适应的技术栈以及团队的编码风格。这个过程本身也是一个很好的契机，让我们重新审视现有架构的合理性。在长期需求迭代和时间推移中，很多工程模块的职责其实已经偏离了当初的设计意图。在 AI 时代，我们正好可以趁此机会梳理清楚，然后把这些经过确认的架构信息作为顶层约束交给 AI。在技术实现层面，我们有多种手段来承载这一约束，比如 rules 机制、claude.md 这类顶层文件结构。一旦工程架构宪法确立，AI 在编码的任何阶段都必须遵守，生成的代码就不会出现乱放位置、随意破坏分层的问题。
接下来是一个更为棘手的问题：代码质量和编码效率如何平衡。我们将编码颗粒度划分为七个等级。越往上，颗粒度越小，可控性越强但效率提升有限；越往下，颗粒度越大，效率越高但质量可控性越差。值得注意的是，随着模型能力的不断增强，我们完全可以向更粗的颗粒度持续探索。当前我们团队的整体实践颗粒度是单工程级别的，如果一个需求只需要在一个工程内实现，AI 可以一次性完整生成所有相关代码，而且整体效果相当不错。
大模型的一个广为人知的问题是上下文容易被“挤爆”，尤其是在大规模代码生成场景中。我们通过任务拆分机制来解决：在编写项目代码时，AI 会首先将整体任务拆分为若干子任务，以任务为单位记录编码状态。这样即使中途会话中断，也可以很方便地恢复上下文而无须重新开始。
分享一个真实的线上需求案例。整个需求涉及六十六个文件的编码，共计超过五千行代码。在整个生成过程中，我只在中间输入过两个字——“继续”，就让它接续完成了剩余的全部工作。这个案例充分说明，只要任务编排和状态管理做得好，AI 已经能够承担相当大规模的单工程编码工作。
在团队推广时，我们面临另一个关键问题：这套方案能否复用？显然我们不可能期望每个团队成员都重新调试自己的一套 prompt 和规范。但凡有过调 prompt 经验的人都知道，这个过程非常耗费时间和心力，而且也不存在一套通用的 prompt 能解决所有问题。我们在设计时重点考虑了方案的复用性，其核心逻辑是解耦业务逻辑与编码规范——规范文件中完全不包含任何具体的业务逻辑，只定义规则和约束，因此整套方案可以以较低成本推广到整个团队。
在扩展性方面，我们设计了三个维度的扩展。第一，研发流程组件化，将需求分析、编码等不同研发阶段包装为独立的 skills。第二，不同场景的文件化隔离，例如新增类需求和修改类需求对应不同的规范文件。第三，编码内容的结构化，让每一条规范都可以清晰地归属到某个流程、某个场景和某个模块。这种结构化设计使得问题定位变得非常容易：一旦出现问题，我们可以迅速判断是哪个流程、哪个文件的哪个规范需要调整，然后批量修改，而不需要动及整个体系。
当 AI 一次性生成成千上万行代码时，随之而来的最大挑战就是质量审查和保障。我们通过构建一个 AI 自我审查、自我优化迭代与人工终审相结合的闭环机制，来解决这一问题。
AI 自我审查会从多个维度检查代码质量，包括：业务逻辑与代码实现是否一致、整体代码设计是否合理、代码是否存在明显的质量缺陷、是否符合团队的编码规范。我们为 code review 专门写了一份 spec 规范，定义了四个审查维度：功能逻辑维度检查什么，代码设计维度关注哪些方面，代码质量维度覆盖哪些问题，代码规范维度要求什么标准。
在实践中，这套审查机制通常迭代三到五次，就能产生比较高质量的代码。人工要做的是最终的“切壳检查”——重点关注那些高风险、容易产生线上止损的关键细节，而不是逐行审查全部代码。这种方式让我们可以把有限的精力聚焦在 AI 相对容易忽略的边缘 case 和安全敏感点上，大幅提升了人工审查的效率和有效性。
AI 编码方案及实战
这套编码规范体系的演进本身也经历了多个阶段。回顾整个时间线：2024 年 8 月前后，行业掀起智能补全的热潮，到 2025 年上半年大多数团队仍然停留在智能补全的模式中。我们是在 2024 年下半年开始系统性探索的，但始终坚持质量为优先的原则。2025 年 2 月，我们形成了第一版方案，通过 prompt 技术将整套思路进行了封装，并发布了技术方案模板，要求大家按照模板来描述业务需求。当时编码方式还比较原始，但已经可以做到一次性生成整个领域服务的所有方法和业务逻辑——例如门店管理的增删改查及其相关业务逻辑都能一次性产出。不过当时规范是手动选择后再交给 AI 的，还没有实现自动化。
到了 2025 年七八月份，spec coding 开始兴起，同时 rules 技术也进入了我们的视野。我们利用 rules 机制对方案进行了升级，增加了 AI 自动生成技术方案的能力以及对修改类需求的支持——在此之前我们主要聚焦于新增类需求，对修改类需求的覆盖有所顾虑。进入 2026 年后，我们发现 skills 技术能很好地解决手动选择规范的问题，于是综合运用 skills、rules 和 spec，从研发流程规范和编码规范两个维度对整个技术方案进行了重构。现在，这套方案已经做到了开箱即用，用户在使用过程中几乎感知不到规范的存在——因为 skills 本身就是大模型根据语义自动识别和加载的。当我们回头来看 Harness 工程的理念时，发现自己的方案与 Harness 的核心理念是高度一致的，只是我们的范围更聚焦于编码阶段。
在制定具体方案时，我们调研了两类业界较流行的 spec 方案，发现各有优劣。open spec 的突出优势在于学习上手成本低、自动化程度高，而这恰好是 spec-kit 方案的短板；但 open spec 的明显不足是缺乏统一的宪法机制和需求澄清阶段——而这又恰好是 spec-kit 的优势所在。我们最初的选择是基于 open spec，然后将其与我们已有的编码规范集成在一起。但深度实践下来，效果并不理想。
具体问题出在几个方面。首先，open spec 的汉化程度不够，生成的文件中既有中文段落也有英文段落，同质化程度参差不齐。其次，在需求拆分阶段，它没有清晰区分 requirement 和 scenario 的层级关系，导致后续编码时无法准确还原整个业务逻辑。第三，它将前后端任务混合拆分在一起，但在实际研发中，前端需求和后端需求的关注点差异很大，强行放在一起反而增加了理解和协作的负担。第四，任务拆分的顺序不符合我们的研发习惯——我们在实际开发中通常先定义接口文档，然后从底层数据层逐步向上到应用层实现编码，而 open spec 的拆分缺乏这种清晰的依赖关系。最后，当我们尝试将自有规范集成到 open spec 时，发现扩展起来相当困难，反而让整个流程变得更加臃肿。
举个具体的例子。open spec 拆分的需求中，将“添加门店”和“删除门店”都作为 scenario 列出来，但实际上按照正确规范，它们应该属于 requirement 这一层，即功能点；正确拆分的 scenario 应该是例如“成功删除门店”、“取消删除门店”这样的具体用例。这种层级混淆会导致后期编码的组织逻辑出现偏差。此外，我们的需求包含六个模块，按照 open spec 的做法就会拆分成六个独立的 spec 文档，需要跨文件逐一确认，检查效率很低。
基于这些实践反馈，我们决定对 AI 编码的主流技术要素进行重新定位。我们梳理了 rules、prompt 和 skills 各自应承担的职责：rules 作为整体 AI 规范的约束承载，告诉 AI 那些“不要踩的红线”，是没有商量余地的硬约束；skills 则把具体的业务流程和 spec 打包在一起，实现全流程的自动化编排。
如果把整套方案类比为一个法治体系，那么软件工程中的工程结构、架构模式和技术栈信息就是宪法，时刻约束 AI 的行为不偏离既定轨道。在各个开发环节，我们定义了不同的 spec 文档作为一般法规——需求分析有需求分析的 spec，代码编写有代码编写的 spec，code review 有 code review 的 spec。而 skills 就是执法机构，它做什么事就参考对应的规范。这样一套机制运转起来之后，整体治理体系就有了结构性的保障。另外，skills 是模型根据语义自动识别的，所以在用户侧，只需要将这套方案拷贝到本地工程目录下即可，使用过程中完全无感。
我们的整套 skills 规范主要包括四个模块。第一个模块是工程结构分析，负责梳理清楚当前工程的架构全貌。第二个模块是需求分析，将需求结构化地描述清楚。第三个模块是编码规范，覆盖不同层次的代码编写约束。第四个模块是 code review 规范，定义审查的维度和标准。我们会在编码过程中将相关的过程文档统一管理起来，包括数据库执行的 DDL 脚本等，在编码过程中一次性生成。这样开发者在编码完成后不需要再回头补文档，直接拿生成的文件去和协作方对接即可。
后端的整体研发流程分为五个部分。第一部分是功能结构分析，这是一次性工作，整个工程可以复用同一套功能结构描述。第二部分和第三部分围绕需求展开：需求分析阶段会生成结构化的 spec 文档并进行任务拆分，需求澄清阶段则集中收集 AI 在分析过程中产生的不确定项，形成待确认列表等待人工裁决。这个澄清环节极其关键——需求分析不清晰，后续所有工作都可能需要推倒重来。第四部分是编码实现，在这个阶段只需要对 AI 说“帮我实现编码”几个字，它就会按照既定规范完成全部代码及相关的过程文件产出。第五部分是代码质量检查，借助 skills 进行多维度 review，然后根据审查报告驱动优化迭代。
代码实现和代码质量检查构成一个小循环，通常迭代三到五次，就能产出质量相当高的代码。
这里展示一个具体的后端实战案例。我只需要下达一个指令，AI 就会自动加载功能分析 skills，将整个工程的功能结构和架构模式分析出来。分析完成后，人工审视一遍架构描述，确认没问题后就进入下一步。在需求分析阶段，系统会自动识别需求类型——是新增还是修改——并加载对应的规范。对于新增类需求，它会产出包含需求功能清单、模块详细分析和待澄清列表的结构化文档。对于修改类需求，它会先分析现有功能链路，再给出改动点，最后分析潜在影响范围，同样附带待澄清列表。我们实践下来，产出的质量相当高。
需求澄清阶段，可以一次性将所有待确认问题提交给 AI，而不用逐个澄清——否则每轮分析都要两到三分钟，交互效率会明显下降。随后下达编码指令，系统自动加载编码 skills 和相应规范开始工作。这个案例中，AI 一次性生成了六十六个文件、超过五千行代码，业务逻辑和异常处理都比较完整。不过也有不足之处：在异常处理时，它将异常码和异常消息拼接在了一起，但按我们的团队规范其实是需要分开的。面对这种情况，我们不需要去修改代码本身，而是回到研发规范中去调整对应的异常处理规则。这样一来，规范会越积累越厚，也越来越好用。
编码完成后的 review 环节同样值得关注。在我们第一次不做任何交互、直接让 AI 自我审查的情况下，得分大约在七十分左右。可以看到部分需求逻辑的实现还不够完整。随后让 AI 根据 CR 报告进行优化迭代，第二次 review 时那些比较严重的问题基本被解决，得分上升到九十六分，只在一些细节上还有优化空间。经过两到三轮的迭代循环，就能获得一份质量相当可靠的代码了。在本地编译时，这套代码也是一次性通过的。
前端编码的流程与后端整体框架一致，但在具体实践中呈现出了不同的特点。我们认为前后端研发的差异很大：前端更注重交互逻辑，后端更侧重业务逻辑，拆分思路也因此不同。对前端来说，合理的拆分路径是从需求到整体页面，再从页面到业务组件，最后到组件的交互逻辑；对后端来说，则应该是从需求到功能模块，再到功能点，最后到业务规则。我们针对前端研发特点制定了一套规范，保持了同样从功能结构分析到需求分析再到编码的整体流程。
在实际应用中，我们处理三类需求。第一类是有完整 PRD 文档的需求，这类需求 AI 在页面元素交互逻辑上的还原度都比较高。第二类是一句话想法型需求，适合技术驱动的提效场景，AI 可以辅助分析和设计整体技术方案，但缺点是组件交互逻辑会比较缺失，需要后期比较多轮地补充。第三类是后端工程师常用的管理类接口页面，直接把结构文档给 AI，还原度也很高。前端代码的 AI 审查同样给出了详细的问题列表，初始评分满分五分只得到四点三分，但通过代码生成与 CR 迭代的循环，也能逐步收敛到高质量状态。
AI 编码方案的推广及运营
整套方案的推广和运营并不是自然发生的过程。在前期尤其困难，因为人的认知和行为惯性的改变远比技术迭代缓慢。我们没有选择 KPI 强推的方式，而是通过营造编码氛围来驱动自驱力。
第一个抓手是技术分享。我们定期邀请团队内部的最佳实践者来分享自己的经验和心得，形成“用出成效的人来教想学的人”的良性带动效应。第二个抓手是月度评审机制，邀请团队 HR、leader 以及大部门的负责人一起参与，为 AI 编码造势，每月评选出团队维度和个人维度的编码先锋。在推广策略上，我们并不急于一次性全面铺开，而是先小范围试点，打磨到相对成熟后，在每个团队选取一到两个需求、一到两个人进行一对一辅导，帮助他们完整走完一个需求的全流程。这些人实践成功后回到各自团队就成了布道师，最终形成分享、实践、沉淀、再分享的飞轮效应。
光有氛围营造是不够的，我们也建立了硬性的关注指标。第一个维度是 AI 编码率，第二个维度是编码质量——核心观测指标是千行代码 Bug 率和发布回滚率。从 2025 年 4 月推广启动到 9 月，团队整体的 AI 编码率从 9.0% 提升到 89.2%，实现了九倍以上的增长，而代码质量指标始终保持在预期范围之内。后续的成果也水到渠成。我们累计产出了二十四篇 高质量 ATA（阿里和蚂蚁集团内部技术社区）文章，获得阿里和蚂蚁集团联合举办的最佳 AI 实践奖以及年度最佳专题奖。
AI 编码未来的演进方向
回顾过去三年，从智能补全到 Vibe Coding，再到 SDD 规范编程和 Harness 编程，技术演进的主线非常清晰：在持续降低人的参与度，不断提升 AI 的自主决策层级。我们目前正在探索的是将视角从编码阶段拓展到整个研发流程，构建一个端到端的持续交付闭环。
这个闭环中包含两个关键小循环。在研发阶段内部，是编码、优化、CR 和单元测试之间的循环，确保编码阶段就基本锁定质量。另一个小循环在测试阶段与研发阶段之间：编码完成后进入自动化测试，测试报告生成后再反馈到编码阶段，驱动下一轮迭代优化。更大的循环则从需求阶段一直延伸到线上运营阶段，形成完整的反馈链路。
在这个演进趋势下，程序员的价值定位正在发生深刻变化。我认为未来的程序员将从编码执行者走向架构决策者和质量守门员的复合角色。我们从过去涉及具体的模块细节设计和逐行编码，转变为承担整体架构设计以及 AI 运行环境设计的工作。从“代码即规范”的时代，进入“规范即代码”的时代。未来我们可能不会再把大量时间花在逐行阅读代码上，而是在设计和迭代规范本身。
从认知层面，我们需要放下“我比 AI 强”的包袱，学会如何高效地与 AI 协作。无论是国内还是国外的实践数据都已经证明，AI 的执行效率远远高于人类开发者。
从我们的实践可以得出一个清晰的结论：AI 并不是银弹，但它是一个超级杠杆。用好这个超级杠杆，不仅仅意味着把提示词写好，更意味着我们需要具备更清晰的架构思维、更严谨的规范意识，以及更深刻的软件工程哲学。AI 编码说到底，就是对软件工程的深度实践。
作者介绍
邓立山，淘宝闪购高级技术专家，作为 AI Coding 实践的先行者，曾获得首届阿里 &蚂蚁联合发起的最佳 AI 实践案例奖，并在集团内外多次受邀进行实践分享，带领 60+ 成员团队持续推进 AI 编码落地；在 2025 年 2 月末即开始体系化践行 SDD 编码，较业界同类方案更早探索并沉淀可复用方法。同时，作为团队架构师，主导架构整治与演进，使人均应用数从 1.3 降至 0.62，每年带来研发资源降本上百万元；作为团队稳定性负责人，多次主导双 11 大促保障，多次获得稳定性保障最佳团队奖及个人奖。
年中技术充能，盛夏 8 折赴约！AICon 深圳站集结华为、腾讯、阿里等全明星讲师阵容，前沿方向 + 实战干货双在线，承包你一夏的 AI 技术成长。大会限时早鸟票享 8 折专属优惠，现在报名立减 1160，更多详情可扫码或联系票务经理 13269078023 进行咨询。
