从Prompt到Spec——为什么AI编程需要一种新方法论

用AI写代码的人，大概率都经历过这种崩溃：

你对Claude Code说"帮我写个订单查询"，它秒出一版代码。你一看，嗯，能用。合并。上线。

然后发现：排序逻辑没考虑分页、缓存失效策略不对、没有异常处理。

你回去改Prompt，加了一堆约束："必须用QueryWrapper"、"排序下沉到SQL"、"缓存命中率要超80%"。AI又出了一版。这次好多了。但还有问题：缓存key设计不合理、没有SQL注入防护。

再改Prompt，再生成，再返工。

三次之后你发现一个事实：你在用Prompt教AI写代码，而教的时间比你自己写还长。

问题不在AI，在你跟AI的协作方式。

先搞清楚三个概念

在讲方法论之前，先把容易混淆的东西理清楚：

Harness Engineering。

Mitchell Hashimoto（Terraform创始人）在2026年初命名。定义：Agent = Model + Harness。 Harness是除了模型之外的一切——约束、工具、文档、反馈回路。

Martin Fowler网站上专门发了文章，OpenAI和Anthropic正式使用这个词。核心原则："每次Agent犯错，你就设计一个方案确保它不再犯同样的错。"

SDD（Spec-Driven Development，规范驱动开发）。

不是新东西。思想根源可以追溯到1980年代Bertrand Meyer提出的Design by Contract（基于契约的设计）。

核心理念：先写规格说明，再写代码。 和TDD（Test-Driven Development，测试驱动开发）、BDD（Behavior-Driven Development，行为驱动开发）是一条线上的——TDD先写测试，BDD先写行为，SDD先写规格。2000年代就有人在敏捷开发中实践。

它们的关系不是替代，是互补。

Harness Engineering解决"怎么约束AI的执行行为"，SDD解决"怎么定义需求"。Spec本质上就是需求层的Harness——你用spec约束AI的需求理解，用流程和工具约束AI的执行行为。

两种方式：Prompt驱动 vs Spec驱动

我之前写过一篇文章讲Harness Engineering——用结构化的Prompt约束AI的行为AI工具链效率提升——以ClaudeCode为例，从Demo代码到工程化落地。

三层框架：上下文层、任务层、约束层。

管用。但有一个根本局限：你是"教练"，AI是"执行者"。你需要告诉它每一步该怎么做。

SDD提供了一个不同的思路：

从教练变成产品经理。从"用QueryWrapper写"变成"查询p99<200ms，你自己选技术方案"。

Claude Code生态里已经有两个验证了这条路线的成熟项目：

• Superpowers

强制AI走Brainstorm → SDD（Plan）→ TDD → Review的完整流程，不跳步，将 SDD 作为流程核心。

• gstack

/plan-eng-review 阶段即执行 SDD，先定架构与规约，再编码。把浏览器验证、QA测试、发版流程封装成一键命令

这两个项目的核心逻辑一致：

不是让AI更快地写代码，是让AI更对地写代码。

Spec驱动到底在做什么？

Superpowers的工作流程能说明白这件事：

第一步，AI不写代码，先提问。

你说"帮我加个登录功能"，Superpowers会拦截AI，不让它直接动手。

它会先问："登录方式是什么？手机号还是邮箱？失败重试几次？要不要图形验证码？需要记住登录状态吗？"

这些问题可能是你没想过的。

第二步，AI写计划，你确认。

把需求拆成2-5分钟可执行的小任务，每个任务有明确的输入输出。你确认了计划，AI才开始写代码。

第三步，TDD循环。

先写测试（RED），再写实现（GREEN），再重构。每段代码都有测试覆盖。

第四步，自动审查。

AI审查自己的代码——先过规范合规（"你按spec来了吗？"），再过代码质量。

gstack补上最后一块：验证。

/browse截图看页面渲染，/qa跑端到端测试，/ship发版。没有验证报告，不算完成。

整条链路的本质：人只负责定义"要什么"，AI负责"怎么做"和"做得对不对"。

为什么Spec比Prompt强？

▪ 1. Spec是结构化的，Prompt是零散的

Prompt每次从头写，上次写的约束下次忘了。

Spec是一次写好、持续维护的。你不用每次都提醒AI"用QueryWrapper"、"加异常处理"——这些都在spec里。

▪ 2. Spec是唯一真相来源

传统开发最头疼的问题：代码和文档永远对不上。改了代码忘了改文档，改了文档忘了改代码。

Spec驱动的核心原则：代码跟着spec走，不是spec跟着代码走。 这不是新概念——Design by Contract（1980年代）、TDD（2000年）、BDD（2003年）都在说同一件事。只是现在被AI工具链实现了，效果放大了。

▪ 3. Spec让AI从"执行者"变成"合作者"

Prompt模式下，AI只是你的打字员。你说的它写，你没说的它不管。

Spec模式下，AI在brainstorming阶段会主动提问："这个排序字段要不要做白名单校验？""缓存失效策略你考虑过订单状态变更场景吗？"

这些问题可能是你没想过的。

需要诚实说几点

Spec驱动在AI场景下的实践还不够成熟。 SDD本身是老概念，但用SDD配合AI编码工具的实践才刚开始。目前有一些框架（比如OpenSpec）试图把规范管理工具化，但用户量还很少，没有被大规模验证。

不是所有任务都需要Spec。 改个CSS、修个小bug、写个一次性脚本——直接干就行。有开发者在实战中总结了三级分流：轻量任务直接做，中任务简化流程，大任务走完整闭环。硬给轻量任务套完整流程是浪费。

Superpowers和gstack都强依赖Claude Code。 换别的编码Agent（比如Codex、Cursor），流程需要适配。

真正的前瞻：不是工具变了，是角色变了

工具会变——今天Superpowers+gstack，明天可能换成别的。但有一个趋势不会变：

用AI写代码的人，正在从"写代码的"变成"写需求的"。

这不是说代码不重要。而是说，当AI能按spec稳定地产出代码时，你的核心竞争力不是编码速度，是需求定义能力和架构判断力。

Harness Engineering教会我们约束AI的行为。SDD提醒我们先把需求想清楚。两个加在一起，才是完整的AI编程方法论。

说实话，从Prompt切换到Spec，最大的变化不是AI，是你自己。你得学会不教AI怎么做，而是想清楚你要什么。

这个转变不容易。但一旦习惯了，你会发现：你写的不是Prompt，是设计文档。你做的不是编程，是架构。

而AI，只是你的实现工具。

💡 一句话带走： 别教AI写代码了，把需求写清楚，让AI自己决定怎么实现。