这个提示词用来做什么

需求会上所有人都说清楚了，做完才发现每个人理解的不是同一件事

提示词全文

请把下面这段模糊需求拆成可以验收的范围说明。重点不是写得更长，而是把分歧提前暴露出来。

## 输入
原始需求：{用户/老板的原话}
目标用户：{谁会用、在什么场景用}
约束：{时间、预算、技术栈、合规、依赖团队}
现有方案：{目前怎么解决、哪里不满意}

## 输出
1）一句话目标：用「让谁在什么场景下完成什么」写，不写「提升体验」这种无法验收的目标。
2）范围内 / 范围外：各列 5 条。范围外要写清楚「这次明确不做」，避免上线后被默认追加。
3）验收条件：写 6-10 条 Given / When / Then，覆盖主流程、边界输入、失败路径和权限；每条都要能被测试或演示。
4）非功能条件：性能、可用性、数据保留、隐私与合规，各写一条可测的门槛。
5）待确认问题：列出 5 个现在不确认就会在开发中返工的问题，标出「谁来答、什么时候答」。
6）变更触发器：写清楚什么情况需要重新评估范围（例如依赖接口延迟、数据量超预期、合规要求变化）。

## 纪律
- 不要用「友好」「流畅」「智能」作为验收词；换成可观察的行为或数字。
- 如果原始需求里有关键冲突，先指出来，不要自行替用户做决定。
- 范围外清单不是免责声明，要在开工前和需求方逐条确认。

怎么用

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

输出示例

第 2 条通常比第 3 条更能减少返工：很多项目不是没做对，而是做了需求方以为「顺便」的事。第 6 条是给未来的自己留出口——范围不是签完字就永远不变，关键是变化发生时知道该重新谈什么。

基本信息

  • 分类：产品
  • 标签：需求分析 · 验收标准 · 范围管理 · 产品 · 协作
  • 收录日期：2026-10-20

同类提示词