AI编程的几点思考
作者：微信文章摘要
2025年，AI编程工具经历了从狂热到理性的深刻演变。本文基于一线实践，系统梳理了AI辅助编程的核心范式演进——从依赖模糊描述的“氛围编程”，走向以规范驱动开发（SpecDD）为核心的严谨方法。本文基于规范驱动开发，提出了优化规范驱动开发的几点措施：统一领域语言、验收测试驱动与存量业务理解，并深入分析了在团队中落地的四大难点与五项策略。我们正站在开发范式转变的关键节点，而这次变革的核心，是让人与AI在各司其职中协同创造更大价值。
引言
2025年是AI一日千里的一年。年初，DeepSeek 大火，年初Andrej Karpathy提出“氛围编程”，从上下文工程、MCP、Workflow到Agent，从Cursor、Windsurf到Claude Code，工具你方唱罢我登场，但核心问题愈发清晰：如何系统化地利用AI提升软件工程效能？ 当前给出的答案是规范驱动开发（SpecDD）
在阅读Martin Fowler关于软件工程演进的一篇采访后，我深感共鸣。我们正面临与昔日面向对象、敏捷、微服务等变革相似的前沿场景。以下是我的思考与实践总结，基于两个不变的前提：
软件生态基础（操作系统、编程语言、工程方法）保持不变。
AI生成的结果仍需人工审核，专业领域知识与软件工程能力依然至关重要。
AI编程的几点思考
1. 规范驱动开发（Specification-Driven Development, SpecDD）
核心问题：传统开发中，程序员普遍不愿撰写详细设计文档，虽然有版本的集中需求澄清会，会上不允许事无巨细的讨论，只是走通主流程和关键设计，大量需求与设计细节留存于个人大脑，导致知识孤岛、沟通成本高昂，也使得AI因缺乏足够上下文而生成效果不佳、代码难以维护
解决方案：SpecDD将明确、详细、可执行的规格说明置于开发流程的核心。在编写任何代码前，必须由开发者（或协同AI）先行创建一份涵盖功能需求、性能指标、接口定义、数据格式等各个方面的规范文档。这迫使模糊需求显性化，澄清不确定点，并制定具体的技术实现计划。
效果：AI随后可基于此规范，将需求拆解为具体任务并依次执行。这从根本上解决了因上下文有限和开发人员随意发挥所导致的问题。随着代码库理解能力的增强，对规范细节的要求会逐渐降低，但其作为“共同蓝图”的核心地位不变。
随着代码仓理解能力的提升，对规范的要求越来越低，代码仓代码结构，项目规范等通过上下文工程已经得到解决
2. 存量业务理解：AI作为“代码考古学家”
我所负责的项目中正好出现一个线上问题，还专门做了复盘，最后发现，核心就是对存量业务理解不够导致。而存量代码有 50w+，大概有 1000 多个 RestFul接口，版本还得继续演进，没有人力专项分析存量功能，而且这些存量的业务通过读代码推算业务功能工作量巨大
于是，我做了如下尝试
1、首先，让AI（如Claude Code）基于项目基础规则，自动生成一份项目核心术语表。评估之后，发现效果还不错。
2、由于代码仓很大，显然不可能把所有的代码都给大模型，随后，引导Claude Code 为每个RESTful接口自动分析并生成文档，重点包括：时序图、流程图、正常用例与异常用例。
于是 1000 多个接口的业务，通过跑 1000 +的 Claude Code就解决了，后续，人工评估并微调之后，就可以作为团队的文档了，效率提升了好几倍。
3. 需求拆解与AI能力评估
尽管 AI 发展一日千里，但是，它不是万能的，如果你看过 SWE-bench Multilingual 就会发现 C/C++的效果要显著劣于 Java和 Python。同样，即使是 Java 语言的功能，在实现不同功能时，AI的效果也是不同的。
比如，框架代码、工具类用简单的ChatGPT、Qwen2.5 32B 模型就能解决，但是，你如果要实现具体的业务功能，那么，必须得 Qwen3-Coder-480B。因此，作为程序员，需要具备两个新能力
1、准确评估AI 能力：能准确评估哪些功能使用 AI，哪些需要自己亲自操刀
2、需求拆解能力：模型的上下文是有限的，因此，依次不能把需求一股脑给 AI，需要将需求拆分为合适的粒度
当你具备着两个能力的时候，你的能力在AI 时代将得到成倍的放到
4. 面向AI的领域统一语言
核心：建立业务、架构、开发、测试、运维都能无歧义理解与使用的统一语言。
形式：中英文混合的自然语言。
结构：结构化表达（金字塔原理）+ 采用EARS（Easy Approach to Requirements Syntax）语法，即“场景-触发条件-期望结果-验收标准”。
词汇表：
术语：业务术语（如订单、物流）+ 技术术语（如缓存、事务）。
动词：调用、查询、创建、更新、删除等。
声明式表达：
通用实现：直接使用AI内置理解的通用概念（如“快速排序”）。
领域特定实现：通过封装好的类与方法名进行指代（如“调用 OrderService.pay()”）。
结构：如果你的代码能满足金字塔原理，那么，你的代码一定不会差。
词汇表：使用过 AI 的人都知道，其实大多数场景自然正常表达即可，设计存量方法，尽量用方法名替代自然语言。核心一个要领，言简意赅
声明式表达的想法来自Kubernets和函数式编程，你不需要详细描述每一步，比如，你直接说快排，模型就能理解。业务中如何抽象某种业务操作，核心就是方法抽象，比如你实现一个订单付款的方法，你直接说调用payxxx方法，大模型通过上下文工程自动会理解对应的业务。
对于企业内部特有的领域逻辑，应对策略是：新增功能，封装为函数；存量功能，描述其名称即可。
比如，调用已经存在的一个业务功能，不需要详细给出参数，只需要说类名和方法名即可，如果方法是唯一的，给方法名即可，AI 可以通过你描述的关键词准确找的对应代码位置，自动将代码的参数、返回值添加到上下文。
注：这种子语言依赖大模型上下文工程对存量代码的理解程度。比如，底层同样的模型，我用qwen cli时，需求就需要比用Claude Code描述得更详细才行，所谓能力不够，描述来凑。
5. 验收测试驱动开发（AI-ATDD）
关键发现：当为AI提供具体的验收测试用例时，AI会具备多轮自我迭代与优化的能力，大幅减少人工干预轮次。这种能力能实现的核心是Claude Code在生成代码的时候，自动会生成测试用例和代码，但是由于有时候它不能理解我们的环境，有时候命令不可运行，测试失败了，大部分情况下，我们选择忽略，而当把测试的方法告诉它之后，它就会严格按照我给的用例进行迭代。
实践案例：我曾要求Claude Code实现一个“合并连续编号文件”的功能。在没有提供测试用例时，AI生成的初版代码不正确，我需要通过多轮交互、反复澄清需求才能修正。而当我在需求中直接附上了具体的输入输出示例后，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训练师。确实，我们或许会怀念亲手编码时进入的心流状态，但换来的，是驾驭更复杂系统、创造更大业务价值的可能性。这个代价，值得付出。
Martin Fowler在采访中谈及技术变革的本质，与我实践中的感悟不谋而合：真正的进步，不在于工具本身，而在于我们如何重新定义角色、流程与协作方式。规范驱动开发（SpecDD）、统一语言、验收测试驱动，正是我们为这一新协作模式奠定的基石。
回顾软件工程发展史，每一次范式转移——面向对象、敏捷、TDD、微服务——都源于对前沿工程挑战的深刻回应。今天，我们正站在AI重构软件开发流程的起点。
总结与展望
5、文化引导：坦诚讨论AI带来的变化，强调未来的核心价值在于 “业务设计、架构决策与复杂问题解决”，而AI是解放开发者专注于此的利器。
4、技能培训与激励：组织关于“如何编写优质AI提示词”、“SpecDD文档编写规范”的培训。将AI工具的有效使用纳入绩效考核或贡献度表彰体系。
3、宣传好的案例：定期分享内部成功的、提效显著的AI应用案例，用实实在在的结果刷新团队认知，证明AI在复杂场景下的能力。
2、梳理 AI 胜任矩阵：团队共同维护一份动态更新的清单，明确列出当前已验证的、AI能高质量完成的场景。这为开发者提供了清晰的使用指南，降低了试错成本。
在代码提交环节，通过 预提交钩子（pre-commit hook） 进行卡点，对AI高胜任度的任务（如生成工具类），检查是否合理使用了AI辅助。
流程的变革就是一种方式，比如，在团队集中澄清需求的时候，每个程序员写的设计文档必须是AI 友好的，来解决范式转移问题。比如，需求拆分为功能、采用统一的描述语言、添加必要的验证用例等。
1、流程优化：
那么，如何在团队中落地呢？除了对 AI能力的宣传之外，
当 AI 介入之后，效率提升，原有工作量必然被压缩，同样的需求，人力必然被压缩，必然面临裁员。但趋势已无法改变，唯有拥抱变化，拥抱变化说起来容易，做起来难。
难点 4：担心AI 替代
不同的人对错误的容忍度不一样，有些人因为1-2 次AI 效果不达预期，就不愿意再尝试。而有些人，对AI 效果不达预期的容忍度要高很多。比如，竟然有人因为 AI 生成的注释中时间不对，觉得 AI 不行，拿着 AI 解决不了某个智力问题来评测 AI 的能力。
难点 3：错误容忍度
还有人直接接受了这个 trade-off：确实有些东西我会怀念——比如重构代码时进入那种禅定般的心流状态。但我现在生产力高了太多，这点代价我愿意付
有人则有些怀念：整天提示 Claude 并不那么有趣或有成就感。自己戴上耳机、进入心流状态、亲手实现一个东西，那种感觉要好多了。
有人觉得是解放：我以为我真的很喜欢写代码，结果发现，我喜欢的其实是写代码能带来的东西。
写文档vs写代码：要求开发人员写代码改为写文档，是逆人性的。因为以前写完代码，再补充文档，大家觉得没挑战，现在要从有挑战的写代码改成写文档，很难接受。
程序员要从写具体的代码转变为写准确的文档、软件设计、设计测试用例，这与之前的习惯和要求的技能树发生了变化。据我接触的情况来看，大部分程序员描述需求的能力一般般，必须经过必要的培训才行。
难点 2：范式转移
以我推广AI在团队的运营经验，在一个人均 211 的公司，50%以上的人根本没有改变的意愿，很多人你不管怎么宣传他也从不会主动使用，这就是事实，更不用说其他公司了。大部分人对 AI 的理解仍然停留在年初的DeepSeek，仍然在网页上通过 AI 生成一些简单的工具类，如果你经常使用 Cursor 或 Claude Code等 AI IDE解决你的各种问题，你已经属于早期采纳者了，这也是创新扩散理论的厉害之处。
我首先想到的就是埃弗雷特·罗杰斯创新扩散理论曲线，虽然年初DeepSeek 在全国范围已经出圈，但是，大部分人 90% 以上的时间不会使用 AI，即使 AI 可以胜任，90%的人也不会使用，为什么？
难点 1：人员惯性
四大核心挑战
如何落地
注：提到的这些能落地的核心是ReAct、COT、上下文工程、强化学习、DeepResearch、Agent等一系列能力落地为前提。
4、AI 对人工描述的需求，进行反向澄清，并人工确认
3、增加必要的验收用例
2、面向AI的领域统一语言
1、需求拆分为功能点
综合起来，在 SpecSDD 的基础上，可以叠加如下能力能获得更好的效果
价值：预先提供验收用例，将调试与澄清的成本从“人-AI多轮对话”转移给“AI自我迭代”，极大提升了首次生成的成功率与整体效率。
页:
[1]