阿里工程师揭秘：掌握渐进式Spec，AI编程从此不再靠运气！

本文核心观点：AI编码不是"给需求等代码"的魔法，而是人机协作的渐进式过程。通过Spec驱动、任务拆分、Hard-Gate审查、知识飞轮四个机制，让AI从"问答工具"变成"可信赖的协作者"。

核心要点：

1.模型是地基：T0模型（Gemini/Claude）vs T2模型，差距不在"能不能写"而在"一次做对的概率"

2.Agent的本质：while循环 + Tool Use + 工具执行器，工具的边界就是Agent的能力边界

3.渐进式Spec：背景调研→Spec撰写→任务拆分→编码实现→审查确认，五步闭环

4.Hard-Gate机制：关键节点强制人工审查，防止AI"自信地犯错"

5.知识飞轮：把踩过的坑、做过的决策沉淀为可复用的知识资产

最近，一位阿里工程师分享了他团队落地AI编码的实战经验。

不是那种"AI几秒生成一个App"的营销视频，而是真正在生产环境里，让AI和人类工程师协作写代码的方法论。

这篇文章很长，技术细节很多，但我读完后的最大感受是：AI编码不是魔法，而是一门需要方法论的工程实践。

今天，我把核心观点提炼出来，希望能给正在尝试或想要尝试AI编码的同学一些参考。

一、先对齐三个基础认知

在聊具体方法之前，作者先花了很大篇幅对齐三个基础认知。这三点没搞清楚，后面的方法论都是空中楼阁。

# 1. 模型是地基，方法论是上层建筑

很多人以为AI编码的效果主要取决于"提示词技巧"，但作者的观点很直接：模型是地基，地基不行，上面盖得再好也白搭。

当前顶级模型（T0梯队）可以独立完成中等复杂度的编码任务——理解需求、读代码、写实现、修编译错误。但不同模型之间的性能差异是断崖式的。

> Chatbot Arena的真人盲评数据显示：同样是"给Spring Boot服务加个带缓存的分页查询"——T0模型一次生成全链路且主动处理边界情况；T2模型能写骨架但需要较多人工调整。

差距不在"能不能写"，而在一次做对的概率。

T0模型三轮搞定的事，T2模型可能15轮还不一定对。这不是提示词能弥补的。

# 2. Agent的本质：从"一问一答"到"自主行动"

知道了模型能力之后，下一个问题是：怎么让它自主行动？

裸LLM只是一个无状态的问答函数——你问一句它答一句，没有工具、没有记忆、不会自己行动。

Agent = while循环 + Tool Use + 工具执行器

用一个例子说明：

1. 你说："把UserService里的getById方法加个缓存"

2. Agent调用【读文件】工具，读取UserService.java（侦察）

3. Agent分析代码，决定修改方案（思考）

4. Agent调用【写文件】工具，插入缓存逻辑（行动）

5. Agent调用【终端】工具，运行编译检查（验证）

6. 编译报错，Agent读取错误信息，自动修复（自愈）

7. 编译通过，Agent回复你"已完成"（结束）

这个循环就是Agent的全部——"智能"来自模型，"能力"来自工具，"自主性"来自循环。

关键理解：工具的边界就是Agent的能力边界。给它读写文件的工具，它能改代码；不给它网络工具，它就上不了网。

# 3. 软件复杂度：不是所有任务都适合AI

作者提出了一个复杂度分层模型：

•简单：单一文件修改，逻辑清晰，边界明确

•中等：跨文件协作，涉及接口变更，需要测试覆盖

•复杂：架构级改动，影响面大，需要多人协作

核心原则：AI目前最适合处理简单和中等复杂度的任务。复杂任务仍需要人类架构师的把控。

二、渐进式Spec：五步闭环工作流

这是整篇文章的核心方法论。作者团队把AI编码过程拆解为五个阶段，形成闭环：

# 阶段一：背景调研（Research）

目标：让AI理解"现状"，而不是凭空想象。

具体做法：

• 让AI读取相关代码文件，理解现有实现

• 识别依赖关系、接口契约、数据流向

• 标记风险点和边界情况

关键输出：一份Research Findings文档，记录"代码现状"

# 阶段二：Spec撰写（Specification）

目标：把需求转化为AI能理解的"技术规格说明书"。

作者强调：Spec不是简单的需求描述，而是要包含：

•背景与目标：为什么做 + 做完后的效果

•代码现状：基于Research的结论，每个结论必须有代码出处

•功能点清单：输入→处理→输出的完整描述

•业务规则：约束条件、边界情况、异常处理

•数据/接口变更：具体改哪些表、哪些接口

•影响范围：可能影响的其他模块

•风险与关注点：涉及资金/状态流转/权限变更必须标注

关键原则：Spec必须达到"另一个工程师看了能直接写代码"的精度。

# 阶段三：任务拆分（Task Breakdown）

目标：把Spec拆解为可独立提交的原子任务。

作者的拆分顺序：数据模型 → 接口协议 → 底层实现 → 上层编排 → 入口层

每个任务的要求：

• 可独立提交（3-5个文件）

• 精确到文件路径和函数签名

• 有明确的验收标准

# 阶段四：编码实现（Implementation）

目标：让AI按Spec和Task列表执行编码。

这个阶段的核心是人机协作：

• AI负责具体的代码生成、编译错误修复、简单重构

• 人类负责审查关键决策、处理复杂边界、验证业务逻辑

# 阶段五：审查确认（Review & Confirm）

目标：通过Hard-Gate强制审查，确保质量。

Hard-Gate是作者团队设计的关键机制：在关键节点设置"强制人工审查点"，不通过不能进入下一阶段。

典型的Hard-Gate检查清单：

• [ ] 代码是否符合Spec描述？

• [ ] 是否处理了所有边界情况？

• [ ] 测试是否覆盖核心逻辑？

• [ ] 是否引入新的技术债务？

• [ ] 是否更新了相关文档？

三、核心机制一：Hard-Gate防止"自信地犯错"

作者特别强调了Hard-Gate的重要性。

AI有一个特点：它会"自信地犯错"。生成的代码看起来很有道理，编译也能通过，但业务逻辑可能是错的。

如果没有强制审查机制，这种错误会一直累积，直到最后才发现，返工成本极高。

Hard-Gate的设计原则：

1.关键节点必须人工介入：Spec评审、架构决策、测试验收

2.检查清单必须可执行：不能是"代码质量良好"这种模糊标准，而要是"所有P0测试用例通过"

3.不通过不能进入下一阶段：强制阻断，防止"差不多就行"的心态

四、核心机制二：知识飞轮让经验沉淀

作者团队的另一个重要设计是知识飞轮。

AI编码过程中会产生大量"隐性知识"：

• 这个模型的特点是什么？

• 这类任务怎么拆分最有效？

• 踩过什么坑？怎么解决的？

• 哪些提示词模板效果好？

如果不把这些知识沉淀下来，每次都要重新摸索，效率极低。

知识飞轮的做法：

1.实时记录：每个Task完成后，记录决策、踩坑、发现

2.定期归档：/archive时逐条确认，有价值的沉淀到knowledge目录

3.形成模板：把可复用的经验固化为Spec模板、Task模板、测试模板

4.持续迭代：下次遇到类似任务，直接套用模板，在此基础上优化

最终目标：让团队的知识资产像滚雪球一样越滚越大，而不是每次从零开始。

五、给初学者的三条建议

基于作者的实战经验，我提炼了三条给初学者的建议：

第一，选对模型比写对提示词更重要

如果你用的是T2级别的模型，再怎么优化提示词，效果也赶不上T0模型的默认表现。模型是地基，先把地基打牢。

第二，不要期待"给需求等代码"的魔法

AI编码不是魔法，而是协作。你需要投入时间写Spec、做审查、沉淀知识。省下的不是"思考时间"，而是"重复劳动时间"。

第三，从小任务开始，建立信任

不要一上来就让AI处理复杂架构。从简单的、边界清晰的任务开始，逐步建立对AI能力的信任，再扩大协作范围。

六、总结：AI编码的本质是什么？

读完这篇文章，我对AI编码有了更深的理解：

AI编码的本质，不是用AI替代工程师，而是用AI放大工程师的能力。

好的工程师 + AI = 超级工程师

但前提是：你必须有方法、有流程、有审查机制。

渐进式Spec、任务拆分、Hard-Gate、知识飞轮——这些机制的存在，不是为了限制AI，而是为了让AI成为可信赖的协作者。

当AI从"问答工具"变成"协作伙伴"，你才能真正享受到AI编码带来的效率提升。