从 Prompt 到 Spec
约 705 字大约 2 分钟
2026-06-01
Prompt 适合启动一次对话，但不适合作为工程事实源。只要任务影响真实系统行为，就需要把关键上下文从临时聊天迁移到仓库里的可审查材料中。
这就是从 Prompt 到 Spec 的意义。
Prompt 的问题
Prompt 的优势是快，但它有几个工程缺陷：
| 缺陷 | 影响 |
|---|---|
| 临时性 | 对话结束后，后来的人很难知道当时为什么这样做。 |
| 不完整 | 用户经常在多轮对话里逐步补充约束。 |
| 不可审查 | PR reviewer 很难只靠最终 diff 还原需求边界。 |
| 不稳定 | Agent 当前上下文、memory 和工具输出会影响理解。 |
| 难归档 | 完成后无法自然变成系统当前行为事实。 |
Spec 解决什么
Spec 不是把 prompt 写长，而是把工程判断放到正确位置：
| 位置 | 回答的问题 |
|---|---|
| proposal | 为什么做、做什么、不做什么 |
| delta spec | 哪些行为会新增、修改或移除 |
| design | 实现取舍、风险和架构判断 |
| tasks | 如何拆成可执行和可验证的步骤 |
| archive | 完成后哪些事实进入长期记录 |
这些材料让人和 AI 共享同一份事实源，而不是依赖谁还记得某轮对话。
什么时候必须从 prompt 升级到 spec
| 信号 | 原因 |
|---|---|
| 涉及用户可见行为 | 需要明确验收标准。 |
| 跨多个模块 | 需要边界和设计判断。 |
| 会影响权限、数据、安全或部署 | 需要记录风险和验证。 |
| 多人协作 | 需要 reviewer 能脱离聊天记录审查。 |
| 未来要复用或归档 | 需要把结果变成长期事实。 |
和 OpenSpec 的关系
OpenSpec 提供了处理 “Prompt 到 Spec” 的规范层。它把一次待实施变化放进 openspec/changes/，完成后再通过 archive 更新长期事实源。
这不是为了增加流程，而是为了回答一个简单问题：
如果三个月后只看到代码 diff，团队还能理解这次变更的目标、边界和行为影响吗？
如果答案是否定的，就应该让 prompt 升级为 spec。
最小实践
不需要所有任务都写完整 change。可以按风险分层：
| 任务类型 | 建议做法 |
|---|---|
| 小文案、小样式 | prompt + diff 审查即可 |
| 普通功能 | proposal + tasks |
| 行为变化 | proposal + delta spec + tasks |
| 架构或跨模块变化 | proposal + delta spec + design + tasks |
| 高风险变更 | 加入 review、测试证据和归档检查 |
核心结论
Prompt 是启动器，Spec 是事实源。AI 时代的软件工程不应该把所有上下文都留在对话里；真正重要的判断，应该进入仓库，能被审查、验证和归档。
