用上AI之后，我们的开发速度比以往任何时候都快。一个大语言模型（LLM）能在几秒内编写出一个函数。一个Code Agent能在你的牛马饮料热气消散之前搭建好一个服务。一个曾经需要两周才能完成的原型，现在两小时就能呈现出来。
然而，许多由人工智能驱动的系统却显得异常脆弱。问题并不在于模型本身不够强大。问题在于，我们是在凭感觉进行开发。
你对项目的代码是不是越来越感觉到陌生？
如果AI已经渗透到你的日常开发工作，那么你一定很熟悉这种模式：
如此来回折腾数次之后，满心欢喜的交付给测试。
这就是Vibe Coding，你和大模型进行对话，它推测你的意图，然后你们不断的调整以达到最终的目标。这种体验非常让人上头，尤其适合验证想法或者测试API等需要快速探索的场景。
正如Andrej Karpathy所言：
The hottest new programming language is English.
把英语换成普通话也是一样的。本质都是通过使用自然语言与大模型进行交流，然后让大模型思考之后指挥Agent完成任务。
问题也出现在这里，自然语言并非技术规范，天然具有模糊性。
当你告诉大模型你需要创建一个登录接口的时候，基本上存在数十种有效的实现方式，而且背后通常隐藏着无数的技术细节，例如，是否需要限流？用哪种加密方式？是否需要图像验证码？支不支持Refresh Token？
然而大模型才不管你这些，它会替你选择一个最简单的方式完成任务，你没说的就是没有。PS：像不像贵司那个偷奸耍滑的程序员给一个不关心技术的产品经理干活？
任务完成了，但似乎并不符合你的架构设计。当然了，这种问题在古法编程里同样存在。
Program testing can be used to show the presence of bugs, but never to show their absence./程序测试可以用来证明存在的缺陷，但永远无法证明不存在的部分。
这就是典型的凭感觉编码，跳过了规划阶段，直接进入到实施阶段，先写代码，有问题再改。（程序员：又不是不能用？！）
小系统或者是demo问题不大，但是如果在稍微有一点规模的生产系统这个干，将会是灾难性的。
Spec Driven Development（规格驱动开发）的提出正是为了解决这一问题。与其反反复复的跟大模型“谈判”，不如把规格说明写清楚。
你不能再含糊地说一句：“用 Python 构建一个登录 API。”。
而是要告诉它（最好是用markdown保存成文件）：
### 任务
开发一个用户认证功能
#### API地址
`POST /api/user/login`
输入格式：json
输出格式：json
#### 实现要求
1. 输入：用户名（支持手机号、邮箱和普通用户名）+密码，如果连续登录失败超过2次，还需要输入4位的图形验证码
2. 登录成功返回200状态码，响应body为JWT，包含access_token、refresh_token、用户id、角色、scope，认证失败返回401状态码
3. 建立一个refresh_token表，主键使用UUID，包含用户id、颁发时间和有效期（14天），主键作为JWT的refresh_token返回给用户
4. 连续10次登录失败后锁定账户，首次锁定15分钟，往后每次增加15分钟，最多不超过12小时
5. 同一IP地址每分钟限制请求10次
6. 用户表需要包含xxx、xxx、xxx等字段
7. 需要记录用户登录日志，包括请求时间、IP地址、浏览器信息、请求来源（APP或者浏览器）。
#### 技术要求
语言：Python/Java
框架：Django/FastAPI/SpringBoot+JPA
数据库：MySQL/PostgreSql
缓存：Redis
部署环境：Docker/Linux/Windows
如果你使用Claude Code这类工具进行开发，那就意味着你想得到的不是一份能运行的代码，而是一个完整的解决方案。你也不是一个机械的AI操作员，而是产品经理和架构师的复合体。这也就是为什么我经常说：
AI编程对程序员的要求不是降低了，而是提高了，你要去做AI想不到或者做不到的事情。
在SDD模式下进行开发，你不是指挥大模型干活，而是在定义行为和约束条件。大模型生成需求文档（按它的理解），你进行审核、优化，等到大模型的理解和你的预期一致了，才开始实施。
大模型虽然能轻松生成代码，但并不能消除因需求模糊而产生的成本曲线。规格驱动开发（Spec Driven Development）在保持开发速度的同时，重塑了开发纪律。
经常返工的朋友都知道，在古法编程模式中，错误的需求（包含两层意思，一是需求本身的问题，二是理解偏差）会导致功能失效，而使用AI编程会放大这种风险。
试想一下，一个由AI驱动的产品分类流程，如果你给大模型一个模糊的提示：“将产品分类”。
80%的情况你可能得到一个正常的结果，但是在精度和召回率控制都及其严苛的企业系统中，这是无法接受的。
一个平台的上下游节点很多，链路很长，模糊性会不断积累。上游对大模型行为的宽松定义，会导致下游产生干扰数据（noisy data），这些数据会随着消息中间件（例如Kafka）、HTTP请求、数据分析管道以及客户仪表盘不断向外传播。
规范驱动开发迫使你思考：
这更接近行为驱动开发，只不过将大语言模型作为协作伙伴。
我们来做一个简单的对比。
提示词：使用嵌入向量构建一个推荐 API。
大模型生成
随后你进行了一些简单的测试，虽然正常运行，但是你发现：
行为：
大模型 可以：
你并非将 AI 排除在流程之外，而是通过明确意图对其进行约束。
关于人工智能将取代工程学科的炒作甚嚣尘上。实际上，大模型虽是出色的模式匹配器，但仍需结构化的引导。
Vibe coding助长了反应式思维。而规格驱动开发（Spec Driven Development）则促进结构化思维。大模型并不能消除对架构的需求。它们只会放大架构薄弱所带来的后果。
当我们将生成式人工智能（GenAI）集成到企业平台中时，特别是在受监管或高风险领域，我们需要可追溯性。我们需要知道系统为何会表现出特定行为。
在SDD模式中，Spec可以：
试想一个Code Agent正在重构微服务。如果没有规格说明，它只会进行局部优化；反之，它便会朝着预定义的行为进行优化。
这一点在事件驱动架构中尤为强大。当服务通过事件进行通信时，契约至关重要。定义不当的事件模式可能会悄无声息地破坏下游消费者。
是的。至少在初始阶段的确是这样的。编写清晰的规范感觉比编写提示词更慢。但在软件开发中，速度不在于打字有多快，而在于返工有多少。
在 AI 系统中，返工往往隐藏在：
规范驱动开发将思考工作前置。这并非官僚主义，而是杠杆作用。大模型非常擅长将结构化的意图转化为具体成果，但在从模糊的指令中推断意图方面则不太可靠。
如果你正在构建AI驱动的系统，尤其是在生产环境中，这里有一个务实的方法：
这种方法融合了规格驱动开发、测试驱动开发与现代 AI 工程。这并非反 AI，而是与 AI 协同的工程实践。
我们常说，人工智能正在改变我们的编码方式。更深层次的变革在于，人工智能正在改变工程领域中最关键的部分。
在这个代码廉价、清晰度却弥足珍贵的时代。规范驱动开发并非是在阻碍创新，而是为了让人工智能生成的系统变得可预测、可审计且可扩展。
我们仍处于这一旅程的早期阶段。大模型在不断进步，开发工具将日趋成熟，智能代理将变得更加自主。
但即便模型不断进步，有一条原则始终成立：模糊性难以扩展。
若想构建具备韧性、可观测且值得信赖的“AI优先”平台，我们必须从凭感觉转向遵循规范。
并非因为人工智能能力薄弱。而是因为严肃的系统理应拥有严肃的意图。而这种意图始于一份规范。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。