跳到正文
码上手 coding.chengyu.dev

提示词:需求澄清与写规格

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

通用需求规格澄清 更新于 2026-10-25

适用场景

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

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

模板

把【】换成你的内容,然后整段发送:

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

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

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 秒,用某条命令可以复现」这类可检查的语句。
  • 规格文件变成负担。 规格的目的是对齐,不是文档工程。超过两页就让它压缩,只保留会影响实现的信息。
  • 实现中发现规格有误。 回到规格文件修改,再让智能体按新版本继续,不要只在聊天里口头改。

参考来源

Esc

输入关键词开始搜索,例如「CLAUDE.md」「MCP」「部署」