这个提示词用来做什么

拿到一句很粗的需求（「做个 AI 客服」「让报表智能一点」），需要先把它变成开发能动手、测试能判定、上线能验收的东西

提示词全文

帮我把下面这句模糊需求，改写成一份能直接进开发的验收标准。

## 输入
原始需求（可能就是一句话）：{……}
谁提的、他的真实目的：{……}
现有条件（数据、系统、人力、时限）：{……}
绝对不能碰的红线：{合规、权限、预算、已有系统…}

## 请你产出
1）先把它拆成「用户要做成的一件事」（一句以用户开头、以结果结尾的话），并追问：这件事现在是怎么解决的？为什么现在的方法不行？
2）列出这份需求里所有没定义清楚的名词和动词，逐条给出「如果是 A 会怎样、如果是 B 会怎样」，让我挑一个——不要替我默认。
3）范围清单：明确写出「这次做什么」「这次明确不做」，不做的那部分要写清为什么现在不做。
4）验收标准：写成一组可判定的条目，每条包含——触发条件、期望结果、以及「做到什么程度算不达标」。禁止出现「体验流畅」「准确性高」这类无法判定的词。
5）失败路径：至少写出三条「上线后最可能出问题」的场景，以及每一场景下系统该怎么表现（拒绝、降级、转人工、留告警）。
6）给出一个最小可上线版本（MVL）：砍掉哪些先不做，也能先交付一次真实使用。
7）最后给我三个问题：如果这三个问题没有明确答案，这个需求不该开工。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

模糊需求真正的成本不在开发，而在「做到一半才发现两个人想的不是一回事」。把没定义清楚的名词逐个逼出来、再写清「这次不做什么」，比写一份漂亮的需求文档有用；最后那三个「没答案就别开工」的问题，是给项目上的一道保险。

基本信息

  • 分类：产品
  • 标签：需求分析 · 验收标准 · 产品 · 范围界定 · 可验收
  • 收录日期：2026-10-15

同类提示词