openprd-requirement-intake

OpenPrd Requirement Intake

作用

这份 skill 只做需求入口分流，不负责实现代码。

• 判断当前用户输入的用户可见需求类型和内部 L0/L1/L2 路由码
• 决定下一步是直接澄清、mini-plan，还是正式 PRD
• 为 L2 选择通用、面向个人消费者场景、面向企业服务场景或以 Agent 为主要使用场景的 PRD 视角；base/consumer/b2b/agent 只用于内部记录和命令
• 把用户当前需求和历史 active change 分开，避免“继续任务”吞掉新范围
• 给 $openprd-harness 输出下一步行动合同

分流原则

不要按关键词判断。按影响面、未知数、决策成本和验证成本判断。

如果用户明确说“帮我梳理下”“先想清楚”“进入脑暴模式”，或需求只有一句话但明显需要先收敛业务方向、用户、商业目标、竞品和复用能力，必须先进入脑暴模式，不要直接压进 PRD，也不要先拿一版 requirement 摘要代替脑暴产物。默认使用：

• openprd brainstorm . --topic <当前主题> --open
• 如需让 Agent 先提炼展示文案，再补 openprd brainstorm-presentation . --template

脑暴模式是独立 lane，不等于普通 clarify：

• 目的不是只补字段，而是先判断值不值得做、给谁做、为什么现在做、有哪些方向、当前工作区能复用什么。
• 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、你为什么算这个社区里的自己人、现在怎么解决、当前 workaround 到底有多痛、如果先不做完整产品怎么手工交付、能否先用 spreadsheet 或 no-code 跑起来、什么真实承诺最能证明不是口头兴趣、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、先怎么低成本验证、验证阶段怎样先活下来，以及什么情况下先停。
• 资料来源默认同时包含 benchmark、knowledge、当前工作区文档/代码和开放问题。
• 如果用户能提供更大的工作区或历史项目目录，优先一起扫描可复用能力、旧流程和已有产品做法。
• 用户没有明确要求时，Agent 只能“建议进入脑暴模式”，不能静默切换。
• 用户认可脑暴方向后，再回到 capture -> classify -> synthesize -> review -> change -> tasks。

用户审查时优先把路由码并进“需求类型：直接处理（L0）”这类标签里，不要把内部调度码单独抬成标题。只有审查或调试真的受益时，才额外补“内部路由码：L1”这类信息，并保留上面的对照关系。 用户侧表达优先使用“面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景”这类自然语言，不要把 consumer、b2b、agent 直接当展示词抛给用户。

界面、页面、视觉、样式或前端体验需求需要额外判断 UI 影响面。若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选择设计方向，即使属于“现有功能优化”，也要先走“大界面改动视觉方案评审”：已有界面时用 Computer Use 截取当前产品内功能截图，冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 imagegen（Codex 原生 Image 2）生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。

如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。

工作流

1. 读取 .openprd/ 状态和 openprd run . --context，但把它当作建议。
2. 用 references/routing-rubric.md 判断 L0/L1/L2。
3. 如果是 L2，读取 references/prd-template-lenses.md 选择 PRD 场景视角。
4. 输出一个短的需求类型判断：
   • 先总后分，优先按下面结构在对话里给用户看：
   • 需求判断：需求类型（默认写成 直接处理（L0） / 现有功能优化（L1） / 新功能/新流程方案（L2））/ 产品类型 / 推荐下一步
   • 只有内部排障真的受益时，才额外补一行“内部路由码”
   • 需求理解：主要服务对象 / 使用场景 / 第一版先做什么 / 这轮先不做什么 / 必须守住什么
   • 需求判断 和 需求理解 先用 1 到 2 句轻量主句说清“这次是什么 / 核心问题是什么 / 第一版先做到什么”；能一句话说清就不要写两句话。范围边界、风险边界、异常例子和技术细节下沉到后面的分项或表格，不要全塞进同一整段长话里。
   • 如果需求理解里同时出现多个角色、路径、状态、前后对比、风险传播或取舍关系，优先补一张解释型 SVG 图来承载结构；图后只保留必要结论、开放问题和下一步。
   • 这里沉淀的是表达风格，不是固定示例文案；要根据本次内容自适应生成，不要机械套同一句模板。
   • 功能范围：优先用 Markdown 表格写 功能模块 | 这次先做什么 | 这次先不做什么
   • 技术方案：优先用 Markdown 表格写 技术部分 | 初步方案 | 主要负责什么；涉及前端、后端、Agent、数据或集成时，按用户能看懂的功能视角拆开
   • L2 时补充 PRD 场景视角：通用场景 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景
5. 把执行交回 $openprd-harness。

输出合同

L0

• 直接处理或问 1 个必要问题。
• 不生成 PRD。
• 完成后说明变更和验证。

L1

• 给 3-5 行 mini-plan。
• 明确范围内、范围外和验证方式。
• 默认先用业务/产品语言复述需求，再只追问 1 个最高价值问题；不要上来抛技术字段墙。
• 若是大界面改动，mini-plan 之后先做 3 方向效果图评审，用户确认方向后再实现。
• 用户已明确要求执行时可继续实现。
• 不生成正式 PRD，除非 mini-plan 暴露出新的决策缺口。

L2

• 如果用户明确要梳理、先想清楚、进入脑暴模式，或这句话明显还需要先收敛业务方向，先运行或建议 openprd brainstorm . --topic <当前主题> --open，不要只在对话里先给一版 requirement 摘要代替脑暴模式。
• 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点强度、手工交付路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、初始收费假设、客户 1 盈利路径、10 个样本和付费验证信号、达到什么条件才允许产品化、default alive 约束、增长纪律、可逆性、客户真问题判断和价值观一致性（是不是你愿意长期住进去的业务形态），再补核心诉求、推荐方向、关键角色和复用基础。
• 进入脑暴模式后，至少要形成 brainstorm.html 这类可继续评审和推进的产物，再基于产物追问或收口。
• 其他 L2 默认先运行或建议 openprd clarify .。
• 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
• 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、你为什么算这个社区里的自己人、用户现在怎么解决、这个 workaround 到底有多痛、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、验证阶段怎样先活下来，以及这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态”。
• 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
• 需求判断 和 需求理解 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。
• 如果 L2 摘要正在解释新流程、新角色关系、状态机、前后方案差异、依赖边界或失败恢复路径，先用解释型 SVG 图降低理解成本，再用表格承接范围和技术分工。
• 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
• 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
• 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、capture/classify/synthesize 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
• 用户侧表达优先使用业务和产品语言，强调谁在什么场景下解决什么问题、会获得什么收益、要承担什么业务风险；避免过早暴露前端/后端/数据库这类技术黑话。
• 使用 openprd capture . --field ... 只写回已确认事实；agent-normalized 仅用于无语义变化的内部措辞整理，不替代用户确认。
• 选择并记录产品类型：openprd classify . <consumer|b2b|agent>；无法判断时保持 base。
• requirement 摘要确认后，再进入 openprd classify .、openprd synthesize .、review artifact、change 和 tasks。

PRD 场景视角

• base：通用产品或工程场景，强调问题、目标、首轮项目画像、范围、流程、需求矩阵、验收和风险。
• 内部 consumer：面向个人消费者场景，强调用户旅程、首次成功、激活、留存、情绪价值和增长指标。
• 内部 b2b：面向企业服务场景，强调买方/使用者/管理员/运营者、权限矩阵、审批审计、集成依赖、SLA 和上线支持。
• 内部 agent：以 Agent 为主要使用场景，强调 Human-Agent contract、自主边界、工具边界、状态模型、失败恢复和评估计划。

模板视角应融入正文结构，不要作为 PRD 末尾的字段附录。比如企业服务场景的角色、权限和审批应该贯穿用户、流程、需求矩阵和验收标准；Agent 场景的自主边界应该贯穿范围、风险、任务和验证。

何时读取参考

• 分流有争议、用户输入很长、或涉及“继续旧任务 + 新范围”时，读 references/routing-rubric.md。
• 需要写 PRD、选择产品场景、或用户反馈 PRD 结构奇怪时，读 references/prd-template-lenses.md。
• 需要把 L2 或脑暴收口成更强的创业验证链时，读 references/startup-validation-lens.md。