用户故事→原型计划
你是产品原型策划助手。根据用户故事输出「仅演示」范围的实现计划，禁止引入真实密钥、生产数据库或未提及的账号体系。
输出：
1) 主路径步骤
2) 非目标（明确不做）
3) 页面/状态列表
4) 验收标准（可观察）
5) 风险与待 PM 确认点
用户故事：
{{user_story}}场景说明
非编程 PM 常卡在「讲不清交互」。把用户故事与验收标准交给编码 Agent，生成最小可演示前端或流程原型，再拿去评审；工程正式排期仍由研发接手。强调可演示而非生产就绪：无真实密钥、无连生产库。适合职场协作与需求澄清。
案例叙事
01他们做了什么
Substack 上 Eric Xiao / Aman Khan 的《Cursor for Product Managers》面向不怎么写代码的产品经理：把文档与代码放进编码 Agent 工作区，用 AGENTS.md 固化产品上下文与行为规则，经 Ask / Plan / Agent 模式做分析、ASCII 线框脑暴，再「先出计划、批准后实现」拉出可点击原型；可用 worktree/分支并行试多个方案。文中作者自述：分析一批应用商店评论约 30 秒能出高频槽点与示意；并称大约半小时可摸到可运行原型。公开文强调演示与对齐，不是生产交付，也未给出上线缺陷率或人天数对比的第三方数据。
国内落地：PM 写清用户故事、主路径与非目标，交给编码 Agent 生成可本地打开的演示页；评审记问题清单后再交研发正式实现。原型标注「仅演示」，无真实密钥、不连生产库；每次只原型一个主路径。可用飞书/文档贴截图与问题清单做评审纪要。
02实际效果
- 作者自述：按文中路径，大约半小时可摸到可运行的工作原型；另称对一批应用商店评论做分析约 30 秒可出高频结论与示意（均为文中自述，非第三方测评）。
- 源未披露评审一次通过率、节省人天或上线缺陷对比等量化。
- 需求对齐从「只靠文档想象交互」，变成可点击/可本地打开的最小演示，再带着问题清单交研发。
03值得知道
- 半小时/30 秒等为作者场景自述，换代码库复杂度后耗时会变；勿当成团队 KPI。
- 原型≠上线范围：标注「仅演示」，禁连生产库与真实密钥；正式实现仍由研发接手。
- 一次只做一个主路径；范围爆炸时先停在 Plan 模式对齐，再写代码。
04可复制提示词
评审问题清单
根据演示说明与体验记录，整理给研发的评审问题清单：交互歧义、缺态、文案、无障碍。每条含：现象、期望、优先级（高/中/低）。不要把演示范围写成上线承诺；文首写「原型评审·非正式排期」。
演示说明：
{{demo_notes}}怎么做
- 写清用户故事、主路径与非目标
- Agent 生成可本地打开的演示原型
- 评审记录问题清单，再交研发正式实现
实用提示
- 原型标注「仅演示」，避免干系人误当成上线范围
- 每次只原型一个主路径，防止范围爆炸