三、一个能力，一个Skill / 产品规划提示词+Skill
需求定义和边界（需求规划 1）
在 PRD 里要先把"为什么做、做什么、不做什么"钉死。这就是需求定义。
(Product Requirements Document 产品需求文档)
方法简介
核心是五个板块：
- 问题陈述（Problem Statement）
- 目标（Goals）
- 非目标（Non-Goals）
- 开放问题（Open Questions）
- 时间线（Timeline Considerations）
在什么场景用
| 场景 | 你的状态 |
|---|---|
| 需求越做越偏 | 一开始没写清"问题是什么、不做什么"，后面自然失控 |
| 团队对"做成什么样"没共识 | 目标写得太虚，做完也不知道算不算成功 |
| 需求范围老是蔓延 | 没写"非目标"，什么都能往里塞 |
| 有些问题悬而未决 | 想先把"谁知道答案"标出来，别卡住整个进度 |
不适合的场景：
- 只写给自己看、不需要对齐别人的草稿，产品需求文档是给"协作和评审"用的。
适合谁用
| 职能 | 为什么适合 |
|---|---|
| 产品经理 | 写 PRD 时的定调功夫，决定整份文档的质量 |
| 技术负责人 | 需要"非目标"来界定工程范围 |
| 创始人 | 定义产品方向时，用目标和边界约束自己 |
| 项目负责人 | 用开放问题和时间线来排计划、分阶段 |
立刻上手，将思维框架用作提示词
要求重点在定义三个事情，尤其要划边界：
帮我把问题陈述、目标、非目标写清楚，尤其是非目标要列出"这版不做什么"。要求分析开放问题，标注责任人：
有些问题还没定，帮我列成开放问题，标清楚该谁回答、急不急。要求使用时间线板块，做分阶段建议：
这个功能一次做不完，帮我在时间线里规划一下分阶段。实操：把“需求规划”写入 agent skill
下面对三个知识点，我逐个详细解释：1. 应该掌握的核心思维和专业洞察。 2. 你可以用来教 AI 的方法。3. 提示词 Prompt
可复制方法指令，可以作为Skill的一部分
- 提示词可复制，分析方法可作为prompt使用，连同任务一起交给AI，
- 如果需要这些分析方法，可以按需写入 Agent Skill，作为处理相关任务的方法和步骤。你还可以结合具体工作，补充相关资料、输出要求等。
1. 应该掌握的核心思维和专业洞察：
明确要求问题陈述不能是"我觉得用户需要"，而要落到实证上。
写清"不做会怎样"（用户流失？输给竞品？），才能证明这个需求值得做。
区分产出（output）和结果（outcome）两者的意义在于：产出会让你"做完就以为做对了"，结果才会逼你"做完还要看有没有用"。这也呼应了后面"成功指标"定义，目标就是指标的前置。
非目标最容易被忽略，但是可以促使主动列出"不做什么"。当需求越聊越大时，这份"不做什么"的清单就是你说"不"的依据。
开放问题价值在于"把不确定显性化"。很多需求规划的问题在于：悬而未决的事藏在脑子里，没写出来，结果项目卡住了都不知道卡在哪。
发现一个功能一次做不完，就该在这里主动提出分阶段，而不是硬塞进一个版本里。
2. 你可以用来教 AI 的方法：
- 结构化陈述需求：问题陈述让人知道为什么做，防止做着做着忘了初衷
- 让"成功"可衡量：目标是结果（outcome）而不是产出（output），做完能验收
- 用非目标防蔓延：明确"不做什么"，是后面范围管理的第一道闸
- 把悬而未决的事显性化：开放问题标注"谁负责、急不急"，不让它卡住进度
3. 提示词 Prompt：
模块 ①：问题陈述
用 2–3 句说清"谁遇到什么问题、不解决会怎样"，还要有证据。
### 问题陈述
- 用 2–3 句描述用户问题
- 谁遇到这个问题，以及多久遇到一次
- 不解决它的代价是什么（用户痛苦、业务影响、竞争风险）
- 用证据来支撑：用户研究、支持数据、指标，或客户反馈模块 ②：目标
3–5 个具体、可衡量的结果，区分"用户得到什么"和"公司得到什么"。
### 目标
- 3–5 个这个功能应达成的、具体可衡量的结果
- 每个目标都应回答："我们怎么知道它成功了？"
- 区分用户目标（用户得到什么）和业务目标（公司得到什么）
- 目标应该是结果（outcome），不是产出（output）（"把首次价值时间缩短 50%"，而不是"做一个引导向导"）模块 ③：非目标
明确"这版不做什么"，每个都说明为什么。
### 非目标
- 3–5 件这个功能明确"不会做"的事
- 那些相邻的、但不属于这个版本范围的能力
- 对每个非目标，简要说明为什么不在范围内（影响不够、太复杂、独立项目、时机未到）
- 非目标能在实施过程中防止范围蔓延，并为利益相关者设定期望模块 ④：开放问题
把悬而未决的问题标出来，写清"该谁回答、急不急"。
两件关键的事：
- 标注"谁来回答"——一个问题挂上"法务"还是"工程"，责任就清楚了，不会踢皮球。
- 区分"阻塞/非阻塞"——"开始前必须答"和"边做边答"分开，避免一个非紧急问题卡住整个开工。
### 开放问题
- 在实施前或实施中需要答案的问题
- 给每个问题标注应该由谁来回答（工程、设计、法务、数据、利益相关者）
- 区分阻塞性问题（开始前必须回答）和非阻塞性问题（实施中可以解决）
模块 ⑤：时间线
什么时候做硬截止、依赖关系、要不要分阶段。
### 时间线考虑
- 硬截止（合同承诺、活动、合规日期）
- 对其他团队工作或发布的依赖
- 如果功能太大、一次发布做不完，建议分阶段原文1：
### Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and how often
- What is the cost of not solving it (user pain, business impact, competitive risk)
- Ground this in evidence: user research, support data, metrics, or customer feedback原文2：
### Goals
- 3-5 specific, measurable outcomes this feature should achieve
- Each goal should answer: "How will we know this succeeded?"
- Distinguish between user goals (what users get) and business goals (what the company gets)
- Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")原文3：
### Non-Goals
- 3-5 things this feature explicitly will NOT do
- Adjacent capabilities that are out of scope for this version
- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
- Non-goals prevent scope creep during implementation and set expectations with stakeholders原文4：
### Open Questions
- Questions that need answers before or during implementation
- Tag each with who should answer (engineering, design, legal, data, stakeholder)
- Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)原文5：
### Timeline Considerations
- Hard deadlines (contractual commitments, events, compliance dates)
- Dependencies on other teams' work or releases
- Suggested phasing if the feature is too large for one release联系与支持
编号05.1.3
本篇基于 Anthropic knowledge-work-plugins （开源库）与 04_skill_md_series （我的内部资料）的研读系列
想继续看其他能力/职能，或对本系列有反馈，
请联系顾问：程老师
微信号：kciagent
