Spec Kit 和一个巨型 Prompt：什么时候值得把意图拆成工程阶段

先给判断

一个巨型 Prompt 并不总是坏方法。小修复、一次性脚本或已知边界的内容改动，明确输入、验收和退出条件后，一次请求可能更快。问题出现在任务需要多人协作、跨模块约束、可追踪决策或多轮恢复时：所有意图挤在一个上下文里，下一步很难知道哪些是需求、哪些是方案、哪些已经完成。

GitHub Spec Kit 的官方仓库把 spec-driven development 描述为先定义要构建的东西，再形成技术计划、任务清单，最后实现。它提供 specify、plan、tasks 和 implement 等阶段命令，也支持扩展、preset 和 bundle。本文不把这种流程当成唯一正确的开发法，而是把它当作“什么时候拆阶段”的判断工具。

拆阶段解决的不是写作长度

specify 负责需求、用户故事和边界；plan 负责技术和架构选择；tasks 负责可执行的工作项；implement 才进入代码。四者分开后，评审人可以在代码出现前发现目标冲突，也能在实现过程中回到原始需求检查漂移。

这对 Agent 特别重要。模型可以在一个 Prompt 中同时扮演产品经理、架构师和程序员，但输出往往把未经批准的技术选择伪装成“下一步”。阶段化流程让每次产物有名字、输入和审查点，不等于它会自动变正确。

什么时候一个 Prompt 足够

可以用一个短 Prompt 的条件通常是：目标文件已知，修改面小，输入资料齐全，失败容易回滚，验收可以用一个命令表达。例如“在一个组件中修正 aria-label，运行现有测试并报告 diff”不需要先建立完整产品规格。

相反，若任务涉及新数据模型、多个角色、权限、迁移、部署和长期维护，先写 spec 往往能避免模型直接进入实现。多次使用同一领域模板时，preset 或 extension 也比每次复制巨型 Prompt 更可维护。

一个可复制的选择表

单文件、小 diff、可立即回滚
  -> 明确 Prompt + 测试
多模块、多人评审、约束互相影响
  -> specify -> plan -> tasks
已有项目行为改变
  -> 先更新 spec，再实现
重复的团队规则
  -> preset/extension
  -> 不要更长 Prompt

无论选择哪条路，都要把验收标准和禁止事项写出来。Spec 不是测试的替代品，Plan 不是批准，Tasks 不是执行回执。

常见误区

第一，把 Spec Kit 的命令当成自动交付保证。官方 README 说明它是工具包和流程，不证明生成代码的质量。第二，把社区 extension 当成官方安全审查通过的插件；官方文档提醒社区贡献需要自行审查。第三，为了“看起来规范”给一个两小时的小改动增加不必要的文档负担。

适用边界

绿地项目、复杂 brownfield 改造和需要跨角色审查的 Agent 工作适合阶段化。一次性实验、明确的内容修订和已覆盖的重复修复可以用更短路径。关键不是命令数量，而是下一位接手的人能否知道“为什么做、准备怎么做、做完如何证明”。

来源与边界

GitHub 官方仓库和文档支持 Spec Kit 的阶段、命令和扩展模型。本文没有声称它优于所有开发流程，也没有把示例命令当作在本仓库实际执行的结果。