规范驱动研发的几点思考

摘要

2025年，AI编程工具经历了从狂热到理性的深刻演变。本文基于一线实践，系统梳理了AI辅助编程的核心范式演进——从依赖模糊描述的“氛围编程”，走向以规范驱动创建（SpecDD）为核心的严谨方法。本文基于规范驱动创建，提出了优化规范驱动开发的几点措施：统一领域语言、验收测试驱动与存量业务理解，并深入分析了在团队中落地的四大难点与五项策略。我们正站在开发范式转变的关键节点，而这次变革的核心，是让人与AI在各司其职中协同创造更大价值。

引言

2025年是AI一日千里的一年。年初，DeepSeek 大火，紧接着 Andrej Karpathy 带火 Vibe Coding，然后上下文工程、MCP、Workflow和Agent之争，从Cursor、Windsurf到Claude Code、kiro、trae等AI IDE你方唱罢我登场，但核心问题愈发清晰：如何系统化地利用AI提升软件工程效能？当前给出的答案是规范驱动开发（SDD）

在阅读Martin Fowler关于软件工程演进的一篇采访后，我深感共鸣。我们正面临与昔日面向对象、敏捷、微服务等变革相似的前沿场景。以下是我的几点思考。

规范驱动研发的几点思考

如今，规范驱动开发（Specification-Driven Development, SDD）大火，对于如何落地规范驱动开发，个人觉得如何加上如下三点之后，效果会更佳。

1. 需求拆解与AI能力评估

不同的。就是尽管 AI 发展一日千里，不过，它不是万能的，上图是 SWE-bench Multilingual 在不同语言的解决率，很容易发现  Rust、Java、Python的效果要显著好于C/C++。同样，即使是 Java 语言的功能，在实现不同功能时，AI的效果也

比如，框架代码、工具类用方便的ChatGPT、Qwen2.5 32B 模型就能解决，但是，你如果要实现具体的业务效果，那么，必须得 Qwen3-Coder-480B。因此，作为程序员，要求具备两个新能力

1、准确评估AI 能力：能准确评估哪些功能使用 AI，哪些需要自己亲自操刀

2、需求拆解能力：模型的上下文是有限的，因此，不能把需求一股脑给 AI，需要将需求拆分为合适的粒度

当你具备着两个能力的时候，你的能力在AI 时代将得到成倍的放大

讲这个点是，大家产品线的 AI IDE能力在 10 月份有一个非常大的能力提升，之前基于 workflow+qwen2.5 32B的模型，简单说就是只能达成基本的 CRUD，稍微加点业务就不行，一个不到 200 行代码，我花了一个下午验证，末了，通过对需求增加了更多详细的约束之后，基本一次能相对生成 80%的代码直接可用，于是，我们针对业务梳理了各种典型的开发场景，评估哪些场景可以使用 AI。而到了10月份底，重新基于Agent+Qwen3-Coder-480B实现之后，能力出现了一个很大的飞跃，同事利用周末一天开发了 3k 的代码，而全程几乎没有人工写代码，仅仅改了配置。

2 面向AI的领域统一语言

结构：若是你的代码能满足金字塔原理，那么，你的代码一定不会差。

词汇表：运用过 AI 的人都知道，其实大多数场景自然正常表达即可，涉及存量手段调用，尽量用技巧名英文单词替代中文。核心一个要领，言简意赅

技巧抽象，比如你实现一个订单付款的方法，你直接说调用payxxx办法，大模型通过上下文工程自动会封装对应的业务。就是声明式表达：想法来自Kubernets和函数式编程，你不需要详细描述每一步，比如，你直接说快排，模型就能理解。业务中如何抽象某种业务操作，核心就

对于企业内部特有的领域逻辑，应对策略是：新增业务功能，封装为函数；存量功能，描述其名称即可。

比如，调用已经存在的一个业务功能，不需要详细给出参数，只需要说类名和方法名即可，如果方法是唯一的，给方法名即可，AI 可以通过你描述的关键词准确找的对应代码位置，自动将代码的参数、返回值添加到上下文。

注：此种子语言依赖大模型上下文工程对存量代码的理解程度。比如，底层同样的模型，我用qwen cli时，需求就应该比用Claude Code描述得更详细才行，所谓能力不够，描述来凑。

否存在一种更抽象语言来编程？看到Martin Fowler的采访之后，第一次感觉和大牛同频了，才有了此文。就是统一语言的事情，是 24 年的时候我就在思考这个事情，记得公司的 ICT 软件技术大会结束后，软件总工邀请了徐昊老师进行线下交流，我当时问了两个障碍，其中一个就是

3. 验收测试驱动开发（AI-ATDD）

当为AI提供具体的验收测试用例时，AI会具备多轮自我迭代与优化的能力，大幅减少人工干预轮次。此种能力能达成的核心是Claude Code在生成代码的时候，自动会生成测试用例和代码（依赖具体的模型，我用的后台模型是 GLM 4.6），不过由于有时候它不能理解大家的环境，有时候命令不可运行，测试失败了，大部分情况下，我们选择忽略，而当把测试的方法告诉它之后，它就会严格按照我给的用例进行迭代。

这个想法来源是，我最近用Claude Code实现一个“合并连续编号文件”的机制。在没有提供测试用例时，Claude Code生成的初版代码不正确，我需要通过多轮交互、反复澄清需求才能修正。而当我在需求中附上了简单的输入输出示例后，AI在生成代码后，自动以其为基准进行验证，首次失败后自我反思，在第三次迭代即成功通过用例。

如下示例

遍历文件夹，找的所有的.md文件，取文件名的第一个数字，进行排序；排序之后，取文件
名中的第二个数字，如果数字连续，就将相邻的文档合并。验证：输入
test/xuexijuexing/，存在
xuexijuexing10_6_selector_1_0.md，xuexijuexing11_2_selector_1_0.md，xuexijuexing
12_3_selector_1_0.md，xuexijuexing13_4_selector_1_0.md，xuexijuexing9_5_selector
_1_0.md，合并xuexijuexing9_5_selector_1_0.md，xuexijuexing10_6_selector_1_0.md为
xuexijuexing9_5_selector_1_0.md，合并xuexijuexing11_2_selector_1_0.md，xuexijuex
ing12_3_selector_1_0.md，xuexijuexing13_4_selector_1_0.md
为xuexijuexing11_2_selector_1_0.md   首先排序

通过预先提供验收用例，将调试与澄清的成本从“人-AI多轮对话”转移给“AI自我迭代”，极大提升了首次生成的成功率与整体效率。

还有就是B 站的一个视频，关于 SWE-Bench发展趋势的图，即使 SWE-Bench不能代表编码的能力，但已经能说明一些问题

综合起来，在 SDD 的基础上，行叠加如下能力能获得更好的效果

1、需求拆分为功能点

2、面向AI的领域统一语言

3、增加必要的验收用例

如何落地

难点 1：人员惯性

哪怕年初DeepSeek 在全国范围已经出圈，如果你关注 AI 相关的自媒体，每天看到的都是颠覆，而现实是，只有 10%的开发人员在持续利用 AI 辅助编码，90% 的开发人员只是偶尔用于，

但是，即使 AI 可能胜任，90%的人也不会使用，为什么？这就是埃弗雷特·罗杰斯的创新扩散理论曲线的厉害之处

以我推广AI在团队的运营经验，在一个人均 211 的公司，50%以上的人根本没有改变的意愿，很多人你不管怎么宣传他也从不会主动使用，这就是事实，更不用说其他公司了。大部分人对 AI 的理解仍然停留在年初的DeepSeek，仍然在网页上通过 AI 生成一些简便的工具类，假如你经常运用 Cursor 或 Claude Code等 AI IDE解决你的各种开发问题，你已经属于早期采纳者了。

难点 2：范式转移

程序员要从写具体的代码转变为写准确的文档、软件设计、设计测试用例，这与之前的习惯和要求的技能树发生了变化。据我接触的情况来看，大部分程序员描述需求的能力一般般，必须经过必要的培训才行。

写文档vs写代码：要求开发人员写代码改为写文档，是逆人性的。因为以前写完代码，再补充文档，大家觉得没挑战，现在要从有挑战的写代码改成写文档，很难接受。

有人觉得是解放：我以为我真的很喜欢写代码，结果发现，我喜欢的其实是写代码能带来的东西。

有人则有些怀念：整天提示 Claude 并不那么有趣或有成就感。自己戴上耳机、进入心流状态、亲手建立一个东西，那种感觉要好多了。

有人悲喜交加：我不止听到一位同事说，常常使用 AI IDE，发现自己不想手写代码了，他们既有不用手写代码的兴奋，也有自己技能退化的担忧，这么持续下去，会不会不会写代码了

还有人直接接受了该 trade-off：确实有些东西我会怀念——比如重构代码时进入那种禅定般的心流状态。但我现在生产力高了太多，这点代价我愿意付

难点 3：错误容忍度

不同的人对错误的容忍度不一样，有些人源于1-2 次AI 效果不达预期，就不愿意再尝试。而有些人，对AI 效果不达预期的容忍度要高很多。比如，竟然有人因为 AI 生成的注释中时间不对，觉得 AI 不行，拿着 AI 解决不了某个智力疑问来评测 AI 的能力！思维还停留在质疑AI的能力上，而不是欣然接受不确定性

难点 4：担心AI 替代

当 AI 介入之后，效率提升，原有工作量必然被压缩，同样的需求，人力必然被压缩，必然面临裁员。但趋势已无法改变，唯有拥抱变化，拥抱变化说起来容易，做起来难。从多方面想信息来看，本轮 AI 只能解决编码的问题，不能解决软件工程的问题。所以，大可不必担心，尽快专注到业务、设计等高价值的事情

那么，如何在团队中落地呢？除了对 AI能力的宣传之外，

1、流程优化：

• 流程的变革就是一种方式，比如，在团队集中澄清需求的时候，每个程序员写的设计文档必须是AI 友好的。比如，需求拆分为机制、采用统一的描述语言、添加必要的验证用例等。

• 在代码提交环节，依据预提交钩子（pre-commit hook）进行卡点，对AI高胜任度的任务（如框架类、生成工具类等 100 行以上的代码），检查是否合理使用了AI辅助。

2、梳理 AI 胜任矩阵：团队共同维护一份动态更新的清单，明确列出当前已验证的、AI能高质量完成的场景。这为开发者提供了清晰的使用指南，降低了试错成本。

3、宣传好的案例：定期分享内部成功的、提效显著的AI应用案例，用实实在在的结果刷新团队认知，证明AI在困难场景下的能力。

4、技能培训与激励：组织关于“如何编写优质AI提示词”、“SDD文档编写规范”的培训。将AI应用的有效使用纳入绩效考核或贡献度表彰体系。

5、文化引导：坦诚讨论AI带来的变化，强调未来的核心价值在于“业务设计、架构决策与复杂问题解决”解放开发者专注于此的利器。就是，而AI

总结与展望

回顾软件工程发展史，每一次范式转移——面向对象、敏捷、TDD、微服务——都源于对前沿工程挑战的深刻回应。今天，我们正站在AI重构软件开发流程的起点。

Martin Fowler在采访中谈及技术变革的本质，与我实践中的感悟不谋而合：真正的进步，不在于工具本身，而在于我们如何重新定义角色、流程与协作方式。规范驱动编写（SDD）、统一语言、验收测试驱动，正是我们为这一新协作模式奠定的基石。

这不仅仅是效率的量变。它要求大家从“代码编写者”转变为蓝图设计者、质量定义者与AI训练师。确实，我们或许会怀念亲手编码时进入的心流状态，但换来的，是驾驭更复杂系统、创造更大业务价值的可能性。这个代价，值得付出。

改变已至，唯拥抱者先行。