# 提示词：需求澄清与写规格

> 让智能体先采访你、再把模糊想法整理成带验收标准的 SPEC.md，适用于动手前还没想清楚的中大型功能，避免做到一半发现方向错了。

## 适用场景

你脑子里只有一句「想做个导出功能」或「给后台加权限管理」，直接让智能体去写，它会替你做一堆未经确认的决定，最后得到一份方向跑偏的代码。

更稳的做法是把「想清楚」和「写代码」拆成两个阶段：先让智能体像资深同事一样追问你，把答案整理成一份规格文件；然后开一个新会话，只拿着这份文件去实现。新会话上下文干净，不会被访谈过程占满。

## 模板

把【】换成你的内容，然后整段发送：

```text
我想做【一句话描述功能】。
背景：【为什么要做，谁会用，现在是怎么解决的】。
已知约束：【技术栈、截止时间、不能改动的部分】。

先不要写任何代码，也不要修改任何文件。请按下面的方式采访我：

1. 先自己阅读与该功能相关的代码和文档，能从代码里查到的问题不要问我。
2. 每一轮只问 1 到 3 个问题，且优先问「答案会改变实现方案」的问题。
3. 每个问题尽量给出 2 到 4 个选项，并标出你的推荐和理由，我只需回复编号。
4. 重点追问我可能没想到的部分：边界与异常情况、权限与数据安全、
   与现有功能的冲突、性能与规模、失败后怎么回滚、上线后怎么确认没问题。
5. 当你觉得信息足够时，先复述你的理解，等我确认后再往下走。

确认后，把结果写入 SPEC.md，结构如下：
- 目标：一句话。
- 非目标：这次明确不做的事。
- 用户场景：2 到 4 条，每条写清「谁在什么情况下做什么」。
- 功能清单：按优先级排序，每项注明涉及的文件或模块。
- 边界与异常：逐条列出，并写明期望行为。
- 验收标准：每条都必须能被命令或操作验证，写出具体命令或步骤。
- 待定问题：目前仍未决定的事项及负责人。
```

## 怎么用 / 怎么改

1. 在支持提问工具的环境里（例如 Claude Code 的 AskUserQuestion 提问工具），智能体会用选择题的形式向你提问。不支持的工具直接用文字问答也行，把第 3 条改成「用编号列出选项」即可。
2. 访谈结束、`SPEC.md` 写好之后，自己读一遍并动手改。规格写得再好，也要由你拍板。
3. 开一个新会话，提示词只写一句：「阅读 SPEC.md 并实现，每完成一项功能就运行验收标准里对应的命令，把结果贴给我。」
4. 功能很小（一句话能说清 diff）就别用这套流程，直接让智能体做，节省时间。
5. 想加快节奏，可以删掉第 5 条的确认环节，但保留「先问再写」。

## 常见问题或注意事项

- **智能体问了一堆废话。** 在提示词里补一句「如果你问的问题可以通过阅读代码得到答案，那是不合格的提问」。
- **验收标准写得很虚。** 「体验良好」不能验证。要求它改写成「导出 1 万行数据，耗时小于 5 秒，用某条命令可以复现」这类可检查的语句。
- **规格文件变成负担。** 规格的目的是对齐，不是文档工程。超过两页就让它压缩，只保留会影响实现的信息。
- **实现中发现规格有误。** 回到规格文件修改，再让智能体按新版本继续，不要只在聊天里口头改。