# Openprd Requirement Intake > OpenPrd 需求入口与 PRD 分流 skill：判断用户可见需求类型和内部 L0/L1/L2 路由码，决定直接澄清、mini-plan 或正式 PRD，并选择通用 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景的 PRD 视角。对用户复述时不要直接把 consumer / b2b / agent 当展示词；这些枚举值只用于内部记录和命令。 - Skill: `davidlam-oss/openprd-requirement-intake-2` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add davidlam-oss/openprd-requirement-intake-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/davidlam-oss/openprd-requirement-intake-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: davidlam-oss (https://skillmd.com/u/davidlam-oss) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/davidlam-oss/openprd-requirement-intake-2 --- # 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 | 目标明确，但影响多个文件、状态或用户可见行为 | 先给对话内 mini-plan，再执行 | | 新功能/新流程方案 | L2 | 新产品、模块、入口、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清 | 先走 PRD/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 . `；无法判断时保持 `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`。