---
url: 'https://aisee.wiki/ai-engineering/prompt-to-spec/index.md'
---
# 从 Prompt 到 Spec

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](/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 时代的软件工程不应该把所有上下文都留在对话里；真正重要的判断，应该进入仓库，能被审查、验证和归档。