【从凭感觉编程到需求驱动开发，AI 时代新范式】

快速阅读：随着 AI 生成代码的速度超过人类阅读的速度，软件开发的瓶颈已从“如何写”转向“写什么”。本文探讨了如何通过结构化的需求规范（Spec）来对抗 AI 生成中的随机性与低质量，实现从“凭感觉编程”向“需求驱动开发”的范式转移。

当你在用 Claude 写功能时，是不是总会遇到这种时刻：它表现得极其惊艳，但当你指出一个边缘情况，它只会机械地回复“非常抱歉，我马上修复”，然后陷入无限的错误循环？

这种现象本质上是上下文窗口（Context Window）的局限性。当对话变长，需求就会像被挤压的内存一样丢失细节。我们正在进入一个“后 Slop 时代”——如果输入的是垃圾，输出的必然是垃圾。

有意思的是，解决办法并不在更复杂的 Prompt 里，而是在回归那些被遗忘的传统：写文档。

但这里的文档不是那种写完就烂掉的 README，而是结构化的、机器可读的 Spec。作者提出的核心逻辑是：既然代码正在变得廉价且易于生成，那么真正具有资产价值的、不可替代的，将是那些定义了“系统应该如何运行”的逻辑意图。

有网友提到，这听起来像是回到了 70 年代的瀑布流，但其实不然。现代的 Spec-Driven Development 更像是在为 AI 提供一种“指令流水线”。通过使用类似 YAML 的结构化格式（如 `feature.yaml`），我们可以给每个需求分配一个稳定的 ID（例如 `AUTH-1`）。

这种做法妙在它建立了一种“强耦合”：代码和测试不再是孤立的片段，而是通过这些 ID 与需求直接挂钩。当 AI 在代码中引用 `AUTH-1` 时，它实际上是在进行一种逻辑对齐。

这让审查（Review）的维度发生了变化。你不再需要逐行检查代码的语法，而是通过仪表盘去查看“验收覆盖率”：哪些需求已经实现？哪些测试通过了？哪些逻辑还处于模糊地带？

当然，这种做法也有争议。有观点认为，用 YAML 编写 Spec 是一种“为了机器而折磨人类”的行为，甚至有人调侃这会让开发者变成“YAML 猴子”。

但换个角度想，如果代码生成是廉价的，那么人类的精力应该花在哪里？是花在纠结 AI 写的循环怎么写，还是花在定义系统的边界、约束和核心业务逻辑上？

当生成软件变得像在搜索框输入指令一样简单时，你对软件的“验收标准”将成为你唯一拥有的资产。

acai.sh/blog/specsmaxxing