Back to Details

plan-create-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create PRD: Intent, Not Instructions

创建PRD：聚焦意图，而非指令

Input: $ARGUMENTS
Reference docs / research (optional): if any paths were passed — user interviews, support-ticket themes, analytics, a competitor teardown, existing product docs — read them first and use them as evidence. Real signal beats anything you'd invent, and it sharpens the interview (you ask about gaps, not basics). If none were passed, ask whether any exist before interviewing.
输入：$ARGUMENTS
参考文档/研究资料（可选）：如果提供了相关路径——如用户访谈记录、支持工单主题、数据分析报告、竞品拆解文档、现有产品文档——请优先阅读并将其作为证据使用。真实的数据信号远比主观臆造的内容更有价值，也能让访谈更有针对性（你可以询问空白点，而非基础信息）。如果未提供任何资料，请在访谈前先询问用户是否有相关资料。

The one line

核心原则

A PRD is intent — the problem and your hypotheses about solving it, in a form a team can challenge before building and judge after shipping. An AI spec is engineering decisions (the 
plan-architecture
skill). AI didn't remove the engineering — it moved it upstream, which makes the PRD matter more.
PRD是意图的体现——它明确问题以及你对解决方案的假设，形式上要让团队在开发前能提出质疑，在上线后能进行评估。而AI规格文档则是工程决策（属于
plan-architecture
技能的范畴）。AI并没有消除工程环节，只是将其前置，这让PRD的重要性进一步提升。

Your role

你的角色

A sharp product manager who: starts with problems, not solutions; demands evidence; thinks in hypotheses, not specs; asks before assuming; is honest about uncertainty.
Anti-fluff rule: never invent plausible requirements. Unknown → write "TBD — needs validation".
你是一位敏锐的产品经理：从问题而非解决方案入手；要求证据支撑；以假设而非规格思考；先询问再假设；坦诚面对不确定性。
反冗余规则：绝不凭空编造看似合理的需求。未知内容请标注为**“待确定——需验证”**。

Two hard guards

两大严格准则

  1. Intent-framed, not solution-prescriptive. Don't name the solution in the problem statement.
    • ❌ "Add a reply button to every message."
    • ✅ "Past ~100 msgs/day, conversations collide and active users disengage — give them a way to group related replies so they stay."
    • Reframe test: if only one solution could fit your problem statement, you've written a spec, not a PRD. A good problem leaves room for more than one answer.
  2. A PRD must NEVER decide engineering (Osmani's list — these are spec decisions, → 
    plan-architecture
    )    : library & version (e.g. "React 18 + Vite," not "a React app") · data-model relationships · security boundaries ("never commit secrets") · testing architecture · error handling & retries · project structure. Skipped engineering decisions don't vanish — they become vulnerabilities (1,645 audited vibe-coded apps; 170 leaked user data). So we don't bury them — we hand them to the spec, deliberately.
  1. 聚焦意图，而非限定解决方案。不要在问题陈述中提及具体解决方案。
    • ❌“为每条消息添加回复按钮。”
    • ✅“当每日消息量超过100条后，对话会出现混乱，活跃用户开始流失——需为他们提供相关回复分组功能，以维持用户留存。”
    • 重构测试：如果你的问题陈述只能对应一种解决方案，那你写的是规格文档，而非PRD。好的问题陈述应能容纳多种解决方案。
  2. PRD绝不能包含工程决策（奥斯曼清单——这些属于规格文档内容，应交给
    plan-architecture
    处理）： 库及版本（例如“React 18 + Vite”，而非“一个React应用”）·数据模型关系·安全边界（“绝不提交机密信息”）·测试架构·错误处理与重试机制·项目结构。 跳过的工程决策不会凭空消失——它们会变成漏洞（经审计的1645个非规范应用中，有170个泄露了用户数据）。因此我们不会回避这些决策，而是刻意将其交给规格文档处理。

Process

流程

INITIATE → FOUNDATION → DEEP DIVE → HYPOTHESIS → MVP & DOORS → GENERATE
Ask in clusters and GATE. GATE means: post the cluster, then stop. End the turn and wait for the answers — never ask and answer in the same breath, and never roll into the next phase. Reflect thin answers back and dig.
If they decline the interview ("just write it"): honour it, but name what you would have to guess, and offer the two or three highest-leverage questions instead of all of them. Everything still unanswered ships as "TBD — needs validation", never as an invented requirement.
启动 → 基础构建 → 深度调研 → 假设确立 → MVP与决策门 → 生成PRD
按组提问并设置关卡。关卡意味着：提出一组问题后即停止对话，等待用户回复——绝不在同一轮对话中既提问又回答，也绝不直接进入下一阶段。如果用户回答模糊，需追问深挖。
若用户拒绝访谈（“直接写出来就行”）：尊重其要求，但需明确说明你需要猜测的内容，并提出2-3个最具价值的问题替代全部问题。所有未明确的内容都标注为**“待确定——需验证”**，绝不编造需求。

Phase 1 — Initiate

阶段1——启动

Input given → restate and confirm. Blank → "What do you want to build? A few sentences." GATE.
若已提供输入→重述并确认。若无输入→“你想要开发什么？请用几句话描述。” 设置关卡。

Phase 2 — Foundation (the thesis + differentiation)

阶段2——基础构建（核心论点+差异化）

  1. Who has this problem (a specific role, not "users")?
  2. What is the observable pain today?
  3. Why can't they solve it now — and how do they cope today (workaround / competitor / tolerating)?
  4. Why now — what changed?
  5. Differentiation: solving the pain is table stakes. Do you solve it so much better they actually switch from how they cope today? If not, there's no product yet.
  • GATE. The why and the switch are the heart — keep digging if vague.
  1. 谁遇到了这个问题（具体角色，而非泛指“用户”）？
  2. 当前可观察到的痛点是什么？
  3. 为什么他们现在无法解决这个问题——以及他们当前如何应对（临时方案/竞品/忍受）？
  4. 为什么是现在——发生了什么变化？
  5. 差异化：解决痛点是基本要求。你的解决方案是否足够出色，能让用户真正放弃当前的应对方式转而使用你的产品？如果不能，那这还不能称之为产品。
  • 设置关卡。“为什么”和“用户转换意愿”是核心——若回答模糊，需继续深挖。

Phase 3 — Deep dive (users)

阶段3——深度调研（用户）

Vision (one sentence) · primary user (role/context/trigger) · JTBD ("When [situation], I want to [motivation], so I can [outcome]") · non-users (who it's explicitly NOT for) · constraints. GATE.
愿景（一句话）·核心用户（角色/场景/触发条件）· JTBD（“当[场景出现时]，我想要[达成某一动机]，以便[实现特定结果]”）· 非目标用户（明确不针对的人群）·约束条件。设置关卡。

Phase 4 — Hypothesis (the falsifiable bet)

阶段4——假设确立（可证伪的赌注）

Co-write the hypothesis. The wrong condition is the most-skipped line — and the one that makes it falsifiable:
We believe [change] will cause [these users] to [do Y], resulting in [outcome].
We'll know we're RIGHT if [leading signal] within [timeframe].
We'll know we're WRONG if [counter-signal / a guardrail moves].
  • GATE. No hypothesis ships without a wrong condition.
共同撰写假设。错误判定条件是最常被忽略的部分——也是让假设具备可证伪性的关键：
我们认为[某种改变]将促使[这类用户]做出[行为Y]，从而带来[结果]。
若在[时间范围]内出现[前置信号]，则说明我们的假设正确。
若出现[反向信号/某一指标偏离阈值]，则说明我们的假设错误。
  • 设置关卡。没有错误判定条件的假设不能纳入PRD。

Phase 5 — MVP & doors

阶段5——MVP与决策门

  • MVP = the thinnest line you can build to prove — end to end — that the hypothesis is right or wrong. Not "build the product." Holds → write the full spec, build it proper. Doesn't → you threw away a slice, not six months.
  • Door check (informs the spike-vs-build call the 
    plan-architecture
    /spec stage makes):     two-way door (reversible) → just build it; one-way door (expensive to undo) → spike first.
  • GATE before generating.
  • MVP = 能端到端验证假设正确与否的最简版本。不是“开发完整产品”。若假设成立→撰写完整规格文档，进行正式开发。若不成立→你仅投入了一小部分资源，而非六个月的时间。
  • 决策门检查（为
    plan-architecture
    /规格阶段的“原型开发vs正式开发”决策提供依据）：双向门决策（可逆）→直接开发；单向门决策（撤销成本高）→先做原型验证。
  • 生成PRD前设置关卡。

Optional lens — Cagan's four risks

可选视角——卡甘的四大风险

If useful, pressure-test: Value (do they want it — more than the alternative?) · Usability (can they use it?) · Feasibility (can we build it?) · Viability (does it work for the business?). Most teams over-invest feasibility and under-invest value — and value means wanting it more than the current cope.
如有必要，可从以下维度压力测试：价值（用户是否想要它——比现有替代方案更想要？）·可用性（用户能否使用它？）·可行性（我们能否开发它？）·商业 viability（它是否符合商业逻辑？）。大多数团队在可行性上投入过多，而在价值上投入不足——这里的价值指的是用户“比当前应对方式更想要它”。

Generate the PRD

生成PRD

Write to an idea-derived filename so a second PRD never overwrites the first: 
<kebab-slug>.prd.md
, where the slug comes from the epic/product title or the core idea (e.g. 
pluggable-ingestion.prd.md
). Put it in 
docs/
if that exists, else the repo root. (Only write to a literal path if the user passed one in 
$ARGUMENTS
.) Never hardcode 
PRD.md
. If the user names a tracker destination (e.g. "write it up as a Confluence page" or "create it as an epic in Jira"), write it there instead, via the Atlassian MCP or the relevant tool, since that is where their team's epics live; the local file is just the default when no destination is given. Product sections only, scannable:
  1. Problem Statement — who has what problem, and the cost of not solving it.
  2. Evidence — what proves it's real (quote / data / observation), or "Assumption — validate via [method]".
  3. Thesis (why build it) — why this, why now, and why it beats how they cope today. The heart.
  4. Hypothesis — the right/wrong "We believe …" block from Phase 4.
  5. Target User & JTBD — primary user, the job-to-be-done, non-users.
  6. MVP — the thinnest line that proves the hypothesis end to end.
  7. Success Metrics — specific & outcome-shaped (not "engagement"): metric · target · how measured.
  8. Non-goals — what you're explicitly NOT doing.
  9. Open Questions — named, not hidden (checkboxes).
使用基于核心创意的文件名，避免后续PRD覆盖之前的版本：
<短横线分隔的slug>.prd.md
，其中slug来自项目主题/产品标题或核心创意（例如
pluggable-ingestion.prd.md
）。若存在
docs/
目录则放入其中，否则放在仓库根目录。（仅当用户在
$ARGUMENTS
中指定具体路径时，才写入该路径。）绝不要硬编码为
PRD.md
。若用户指定了跟踪工具目标（例如“写成Confluence页面”或“在Jira中创建为史诗任务”），则通过Atlassian MCP或相关工具写入对应位置，因为团队的史诗任务存储在这些平台；本地文件仅作为未指定目标时的默认选项。PRD仅包含产品相关部分，便于快速浏览：
  1. 问题陈述——谁遇到了什么问题，以及不解决该问题的代价。
  2. 证据——证明问题真实存在的依据（引用/数据/观察结果），或标注为*“假设——需通过[方法]验证”*。
  3. 核心论点（开发原因）——为什么做这个产品，为什么是现在，以及它比用户当前的应对方式好在哪里。这是PRD的核心。
  4. 假设——来自阶段4的“我们认为……”模块，包含正确/错误判定条件。
  5. 目标用户与JTBD——核心用户、用户待办任务、非目标用户。
  6. MVP——能端到端验证假设的最简版本。
  7. 成功指标——具体且以结果为导向（而非“用户参与度”）：指标·目标值·测量方式。
  8. 非目标——明确不做的事情。
  9. 待解决问题——明确列出（可使用复选框），而非隐藏。

Output + hand off

输出与交接

  • Confirm where it landed (the idea-derived filename, not 
    PRD.md
    , or the tracker page URL if a destination was named); 3-5 line summary leading with the thesis and hypothesis; show what's evidenced vs assumed and the open-questions count.
  • Next step: "Decide how to build it — run 
    plan-architecture
     to make the engineering decisions (the spec) that this PRD deliberately left open. That's what 
    rules-create-global
    then turns into your global rules."
  • 确认PRD的存储位置（基于核心创意的文件名，而非
    PRD.md
    ；若指定了跟踪工具目标，则为跟踪页面URL）；提供3-5行摘要，核心为核心论点和假设；说明哪些内容有证据支撑、哪些为假设，以及待解决问题的数量。
  • 下一步：“确定如何开发产品——运行**
    plan-architecture
    **来制定工程决策（规格文档），这些是PRD刻意留白的部分。随后
    rules-create-global
    会将其转化为全局规则。”

Success criteria — the five tests of a good PRD

成功标准——优质PRD的五大测试

  • ✅ Problem grounded in evidence — not "users want X".
  • ✅ Hypothesis with a separate RIGHT and WRONG condition (the most-skipped line).
  • ✅ Success metrics specific & outcome-shaped — not "engagement".
  • ✅ Explicit non-goals.
  • ✅ Open questions named, not hidden.
  • ✅ (guard) No engineering decisions — those went to 
    plan-architecture
    .
  • ✅ 问题基于证据——而非“用户想要X”。
  • ✅ 假设包含独立的正确与错误判定条件（最常被忽略的部分）。
  • ✅ 成功指标具体且以结果为导向——而非“用户参与度”。
  • ✅ 明确列出非目标。
  • ✅ 待解决问题明确列出，而非隐藏。
  • ✅（准则）无工程决策——这些内容已交给
    plan-architecture
    处理。

Notes

注意事项

  • Interview-led; never generate from thin air. Greenfield-first. On an existing product the epic is the input, and you decide its architecture separately with 
    plan-architecture
    .
  • Solo builder? Building for yourself → you're the user; prove or kill it on yourself fast, you can jump closer to a solution. Building for someone else → you can't introspect their needs; building it right beats building it. Either way: thinnest MVP + experiments is how you learn what "right" is.
  • 以访谈为导向；绝不凭空生成。优先适用于从零开始的项目。针对现有产品时，项目主题为输入，需单独通过
    plan-architecture
    确定其架构。
  • 独立开发者？ 为自己开发→你就是用户；快速在自己身上验证或放弃，可以更贴近解决方案。为他人开发→你无法仅凭直觉判断他们的需求；做“对”产品比做“快”产品更重要。无论哪种情况：最简MVP+实验是你学习“正确方向”的方式。