三、一个能力，一个Skill / 产品规划提示词+Skill
分级方式 P0/P1/P2分析（需求规划 2）
这个能力会把需求分级：必须有（P0）、加分项（P1）、未来考虑（P2），并教你用"砍掉它还能不能解决核心问题"来残酷地审 P0，防止"全都是 P0 等于没有 P0"。
方法简介
P0/P1/P2 三级：必须有（砍了功能就不成立）、加分项（砍了核心还能用）、未来考虑（这版不做但留好设计余地）。
三条分级心法：残酷审 P0、P1 要"确定会做"、P2 是"架构保险"。
在什么场景用
| 场景 | 你的状态 |
|---|---|
| 需求清单里每一条都像"必须做" | 分不清哪些砍了会伤筋动骨、哪些砍了只是少个亮点 |
| 团队什么都想塞进第一版 | 没人敢说"这版不做"，范围越滚越大 |
| 上线想快一点 | 需要砍需求，但不知道从哪砍起 |
| 想给未来留余地 | 有些功能现在不做，但要提前设计好、别堵死以后的路 |
不适合的场景：
- 只有一个需求，没什么好分的
- 分级是"定优先级"，不是"排期"，
适合谁用
| 职能 | 为什么适合 |
|---|---|
| 产品经理 | 定 MVP（最小可行版本）时，残酷地砍出核心 |
| 技术负责人 | 拿到分级清晰的需求，知道先做哪部分 |
| 创始人 | 资源有限，必须分清"必须有"和"以后再说" |
| 项目经理 | 按分级排迭代，P0 先做 |
立刻上手，将思维框架用作提示词
要求用 P0/P1/P2 分级，重点在"残酷审 P0"：
帮我把这个功能的需求分成 P0/P1/P2，对 P0 残酷一点，砍了还能用的就降级。要求砍掉无意义的 P0：
这份需求清单里每样都标了 P0，帮我用"不做它就不上线吗"挨个挑战一下。要求设计 P2，为未来要留的设计空间
有些功能这版不做但以后要做，帮我标成 P2，并说明设计上要留什么余地。实操：把“需求规划”写入 agent skill
下面对三个知识点，我逐个详细解释：1. 应该掌握的核心思维和专业洞察。 2. 你可以用来教 AI 的方法。3. 提示词 Prompt
可复制方法指令，可以作为Skill的一部分
- 提示词可复制，分析方法可作为prompt使用，连同任务一起交给AI，
- 如果需要这些分析方法，可以按需写入 Agent Skill，作为处理相关任务的方法和步骤。你还可以结合具体工作，补充相关资料、输出要求等。
方法 ①：需求优先级 P0/P1/P2 三级
1. 应该掌握的核心思维和专业洞察：
- 分清"伤筋动骨"和"锦上添花"：砍了 P0 功能不成立，砍了 P1 只是少个亮点
- 给未来留路：P2 现在不做，但要提前设计好，别堵死以后
2. 你可以用来教 AI 的方法：
对 P0 判定来说，有很多方式。可以挑选最核心的非此即彼方式："砍了这个 P0，功能还能不能解决核心问题？"。这句话是判断 P0 的试金石：
- 砍了还能解决核心问题 → 它不是 P0，降级。
- 砍了就解决不了核心问题 → 它是 P0，必须留。
3. 提示词 Prompt：
### 需求
**必须有（P0）**：没有这些，功能就不能发布。它们代表这个功能的最小可行版本。问："如果砍掉这个，功能还能解决核心问题吗？"如果答案是不能，那它就是 P0。
**加分项（P1）**：显著改善体验，但没有它们核心用例仍然可用。这些通常在发布后很快跟进。
**未来考虑（P2）**：明确不在 v1 范围内，但我们希望设计时能支持以后再做。把它们记下来，可以防止未来做出让它们变难的技术决策。
对每一条需求：
- 写清晰、无歧义的期望行为描述
- 包含验收标准（见下文）
- 记下任何技术考虑或约束
- 标注对其他团队或系统的依赖
### 分级技巧
- 对 P0 要残酷。必须有清单越紧，你上线越快、学得越快。
- 如果每样都是 P0，那就没有 P0 了。挑战每一个"必须有"："我们真的会因为它没做就不上线吗？"
- P1 应该是你有信心很快会去做的东西，而不是一张愿望清单。
- P2 是"架构保险" - 它们指导设计决策，即使你现在不去做它们。原文：
### Requirements
**Must-Have (P0)**: The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
**Nice-to-Have (P1)**: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.
**Future Considerations (P2)**: Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.
For each requirement:
- Write a clear, unambiguous description of the expected behavior
- Include acceptance criteria (see below)
- Note any technical considerations or constraints
- Flag dependencies on other teams or systems
### Tips for Categorization
- Be ruthless about P0s. The tighter the must-have list, the faster you ship and learn.
- If everything is P0, nothing is P0. Challenge every must-have: "Would we really not ship without this?"
- P1s should be things you are confident you will build soon, not a wish list.
- P2s are architectural insurance — they guide design decisions even though you are not building them now.联系与支持
编号05.1.5
本篇基于 Anthropic knowledge-work-plugins （开源库）与 04_skill_md_series （我的内部资料）的研读系列
想继续看其他能力/职能，或对本系列有反馈，
请联系顾问：程老师
微信号：kciagent
