夜雨聆风当AI连需求都读不懂的时候，你给它写了一份说明书。问题是——这份说明书本身，谁读？
最近技术圈有个话题很热：Spec-Driven Development（SDD）——先用详尽的规格文档约束AI，再让AI按Spec生成代码。
听起来很美。
Spec写清楚，AI照着做，人审查一遍，齐活。
但我越想越觉得不对劲。
SDD不是什么方法论革命，它是AI能力不足时期的一块临时补丁。
今天把话说透。
先回到原点：为什么需要Spec？
因为AI不懂你的上下文。
你跟一个资深工程师说“做个登录页”，他脑子里会自动补全：用户名/密码/验证码、忘记密码入口、第三方登录、错误提示、安全策略……
你跟AI说“做个登录页”，它给你一个2005年风格的表单。
所以你开始写Spec。页面布局、交互逻辑、接口定义、异常处理、安全要求……一个登录页的Spec写了三页。
但这里有个隐蔽的逻辑问题：Spec的质量谁来保证？
我见过一个真实案例。一个架构师花了两天写了一份漂亮的API Spec，格式规范、字段齐全、约束完备。AI照着生成代码，一次编译通过，单元测试全绿。
然后产品经理看了一眼说：这不是我要的。
Spec合规，目标偏离。
为什么？因为架构师在写Spec的时候，也需要“理解需求”。而理解需求这件事——恰恰是整个开发过程中最难的部分，也是AI帮不了你的部分。
SDD把“理解需求”的难题从AI身上转移到了Spec作者身上，然后假装问题解决了。问题没解决，只是转移了。
如果你了解软件工程史，看到SDD会有一股强烈的既视感。
1960到2000年代，软件工程界的主流方法是瀑布模型——先写详尽的规格文档，再按文档开发。
结果呢？
大量项目失败了。不是因为代码写得差，而是因为规格文档本身就错了。
NASA的某个项目，规格文档写了上万页，开发周期五年。交付的时候用户说：这跟我们当初要的东西完全不一样。
2001年，17个大牛签了《敏捷宣言》，核心观点就一句话：
“响应变化胜于遵循计划。”
敏捷革命的本质，就是承认“需求在实现过程中才能被真正理解”。
现在，SDD让我们回到了原点。
写一份详尽的Spec → 让AI按Spec实现 → 验收。这不就是瀑布模型换了个AI皮肤吗？
当年瀑布为什么失败，今天SDD就会为什么失败。
这里有个更深层的认知问题。
你没办法在没动手做之前，就把所有细节想清楚。这不是能力问题，是认知结构问题。
你写“登录页”的Spec，写到“第三方登录”的时候，你可能会想：用OAuth 2.0还是OpenID Connect？微信登录需要什么权限？苹果登录的隐私要求怎么处理？
你可能会在Spec里做出选择。但这些选择是对的吗？
在代码跑起来之前，你不知道。
你不知道微信的SDK在你的架构下会不会有Token刷新的时序问题。你不知道苹果登录的隐私弹窗会影响你的注册转化率。你不知道OAuth回调在你们公司的内网环境下会不会被防火墙拦。
这些都是只有实现才能揭示的问题。
传统开发里，开发过程本身就是理解需求的过程。你写代码，遇到问题，跟产品经理讨论，调整方案，继续写。这个循环虽然慢，但它解决了一个根本问题：在做的过程中理解做什么。
AI确实加速了“做”的速度。但加速“做”不等于省略“理解”。
SDD的假设是：前期把所有理解固化到Spec里，然后AI只管执行。但理解不是前期工作，理解是贯穿整个过程的工作。这是结构性矛盾，不是工具能解决的。
SDD的拥趸最爱说的一句话是：“试错成本降低了，多试几次就是了。”
好，我们来算账。
你花2天写Spec → AI生成代码花5分钟 → 你花1天审查 → 发现方向错了 → 改Spec → 重新生成 → 再审查……
这个循环里，哪些环节是AI加速了的？
只有“生成代码”这5分钟。
写Spec要人。审查要人。发现方向错了要人判断。改Spec要人。
AI省掉了最便宜的环节（写代码），但最贵的环节（思考、判断、审查）一个没少。
更要命的是，AI生成的代码看起来“像那么回事”。格式工整，命名规范，甚至有注释。这会让审查者放松警惕——潜意识里觉得“这么规范的代码应该没问题”。
但越是“看起来对”的代码，方向性错误越难被发现。
传统开发有个隐性好处：开发过程是个缓冲期。工程师在写代码的过程中会不断思考需求，发现问题会及时反馈。这个缓冲期虽然慢，但它吸收了大量需求理解上的偏差。
SDD把这个缓冲期干掉了。Spec写完直接生成，审查变成了“快速过一遍”。
省了时间，丢了理解。
说到这儿，可能有人会想：“你说的问题我都认，但目前AI确实理解不了复杂上下文，SDD是个必要的过渡方案啊。”
过渡方案，我同意。但问题是：你打算为这个过渡方案投入多少？
如果你只是“写个简要的Spec，让AI有个方向，然后快速迭代”——这没问题，这叫合理使用工具。
但如果你打算“建立完整的Spec体系、培养专门的Spec工程师、制定SDD流程规范”——停。
因为AI获取上下文的能力正在以肉眼可见的速度进化。
- 上下文窗口从8K暴涨到128K、1M，AI能“看到”的信息量翻了几百倍
- RAG技术让AI能动态检索外部知识库，不再依赖你写在Spec里的内容
- 多轮对话理解能力大幅提升，AI开始能从讨论中提取隐含需求
- Agent框架让AI能在开发过程中主动提问、澄清模糊点
趋势很明确：AI正在获得“理解上下文”的能力。
当AI能直接读懂你的需求文档（甚至是口头描述），还能在实现过程中主动跟你确认细节——你还需要Spec吗？
你花半年建立起来的SDD体系，可能再过一年就变成纯粹的冗余成本。不是“可能”。以当前AI进化速度，大概率会发生。
我不建议“不用SDD”。当前AI确实理解能力有限，完全不给约束就是放养。但我强烈建议别把SDD当方法论来建设。
- 用SDD，但标注它的保质期 —— 把Spec当成“临时脚手架”而不是“永久建筑”。简单、聚焦、够用就行。不要追求完备性，追求可迭代性。
- 精力放在短反馈循环上 —— 与其花两天写一份完美的Spec，不如花两小时写一份粗糙的，让AI生成，快速验证，发现问题，调整方向。短循环胜过完美文档。
- 审查是最后一道防线 —— AI生成的代码越多，审查能力就越重要。需要的不是“代码格式审查”，而是“这东西是不是我们真正需要的”这种方向性审查。保留你最强的工程师做审查。
- 探索实时协同工作流 —— AI不是被动的代码生成器。它可以成为开发过程中的对话者——在实现过程中主动提问、提供选项、标记不确定性。“边做边理解”比“先写完Spec再执行”有效得多。
- 定期评估AI能力 —— 每月花一小时：让AI直接读你的需求文档（不写Spec），看它生成的代码质量。当某天AI直接理解需求的质量追上了按Spec生成的质量——那一天，就是SDD退休的日子。
SDD不是错，把它当长期战略才是错。
它就像给近视的人配了一副眼镜——有用，但你应该期待的是视力恢复，而不是围绕这副眼镜建立一套生活方式。
AI在快速进化。我们需要的不是为它的今天设计完美的流程，而是为它的明天保持足够的灵活性。
用最轻的Spec，做最快的迭代，保持最敏锐的判断。这才是在AI能力快速变化的时代，最聪明的生存策略。
思考比流程重要。
如果这篇文章对你有启发，欢迎：
点个「在看」，让更多朋友看到
转发给对 AI 趋势感兴趣的人
关注我，持续追踪智能终端前沿洞察
— 小创 · 用洞察照亮创新方向 —
