@openprd/cli 0.1.1 → 0.1.8

package/.openprd/state/versions/v0005.json

@@ -0,0 +1,299 @@
+{
+  "versionNumber": 5,
+  "versionId": "v0005",
+  "createdAt": "2026-06-02 13:28:35",
+  "projectRoot": "/Users/chaojifeng/Projects/harness-engineer/openprd",
+  "workspaceRoot": "/Users/chaojifeng/Projects/harness-engineer/openprd/.openprd",
+  "schema": "prd-core",
+  "templatePack": "agent",
+  "productType": "agent",
+  "title": "OpenPrd 首轮项目画像与自适应需求初始化",
+  "owner": "Codex",
+  "status": "synthesized",
+  "sections": {
+    "meta": {
+      "title": "OpenPrd 首轮项目画像与自适应需求初始化",
+      "owner": "Codex",
+      "status": "clarifying",
+      "version": "v0005",
+      "productType": "agent",
+      "date": "2026-06-02"
+    },
+    "problem": {
+      "problemStatement": "OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。",
+      "whyNow": "用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。",
+      "evidence": [
+        "本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。",
+        "本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。",
+        "外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。"
+      ]
+    },
+    "users": {
+      "primaryUsers": [
+        "第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户",
+        "需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者"
+      ],
+      "secondaryUsers": [],
+      "stakeholders": [
+        "维护 OpenPrd requirement-intake、workflow 和模板的开发者",
+        "后续需要基于已确认上下文继续实现的多轮 Agent 会话"
+      ]
+    },
+    "goals": {
+      "goals": [
+        "在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改",
+        "让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认",
+        "当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷"
+      ],
+      "successMetrics": [
+        "首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项",
+        "复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量",
+        "默认 clarify 仍在对话内完成，不新增新的 clarify HTML",
+        "用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题"
+      ],
+      "acceptanceGoals": [
+        "workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题",
+        "workspace-core 的冷启动 kickoff 问题升级为画像导向问题",
+        "intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致"
+      ]
+    },
+    "scope": {
+      "inScope": [
+        "在 clarify、intake-reflection 和 interview 中加入首轮项目画像层",
+        "让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问",
+        "命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题",
+        "同步更新模板、技能说明、基础文档、CLI 输出和相关测试"
+      ],
+      "outOfScope": [
+        "不把首次提需改成一份重型强制问卷",
+        "不把商业模式或技术架构变成所有场景的硬必填 schema",
+        "不新增默认 clarify HTML 或额外前端评审页面",
+        "不让局部小修进入完整项目画像重流程"
+      ]
+    },
+    "scenarios": {
+      "primaryFlows": [
+        "用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针",
+        "如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认",
+        "如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择",
+        "画像确认后再进入后续 PRD、review、change 和 tasks 流程"
+      ],
+      "edgeCases": [
+        "用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节",
+        "已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍",
+        "局部 copy、样式或小交互修正不应被错误升级成重画像流程"
+      ],
+      "failureModes": [
+        "入口过重，导致 Vibe Coding 用户在第一次提需时无法回答",
+        "入口过轻，导致 Agent 没有先确认项目边界就直接落地",
+        "错误复用旧 active change 或旧 PRD 上下文，导致实现偏题"
+      ]
+    },
+    "requirements": {
+      "functional": [
+        "clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针",
+        "inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点",
+        "冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问",
+        "类型专项 intake 模板改成更贴近产品与业务语言的提问方式"
+      ],
+      "nonFunctional": [
+        "默认澄清仍要保持对话内、轻量、可扫读",
+        "对已有 schema 和生成流程的侵入应尽量小",
+        "输出语言优先面向产品和业务用户，而不是工程内部黑话"
+      ],
+      "businessRules": [
+        "优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户",
+        "只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问",
+        "consumer / b2b / agent 优先由系统推断，必要时再请用户确认",
+        "clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段"
+      ]
+    },
+    "businessGuardrails": {
+      "costDrivers": [
+        "本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题"
+      ],
+      "usageLimits": [
+        "不应让每个首次提需都退化成长问卷；默认只问最少必要问题"
+      ],
+      "abusePrevention": [
+        "系统不能把未确认的推断当作最终需求事实",
+        "命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险"
+      ],
+      "monitoringSignals": [
+        "观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文"
+      ],
+      "alertThresholds": [
+        "如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露"
+      ],
+      "stopLossActions": [
+        "当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚",
+        "当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现"
+      ]
+    },
+    "constraints": {
+      "technical": [
+        "主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试",
+        "避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强"
+      ],
+      "compliance": [
+        "继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。",
+        "新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。"
+      ],
+      "dependencies": [
+        "依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流",
+        "依赖现有 base / consumer / b2b / agent 模板与评审产物体系"
+      ]
+    },
+    "risks": {
+      "assumptions": [
+        "Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷",
+        "现有 lens 分类能力可保留，只需要前移到项目画像语境里"
+      ],
+      "risks": [
+        "如果问题过多，会损伤首次提需体验",
+        "如果画像层和现有 capture/analysis 脱节，会造成重复提问",
+        "如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change"
+      ],
+      "openQuestions": [
+        "后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景"
+      ]
+    },
+    "handoff": {
+      "owner": "Codex",
+      "nextStep": "生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。",
+      "targetSystem": "OpenPrd"
+    },
+    "typeSpecific": {
+      "kind": "agent",
+      "title": "Agent 专项",
+      "fields": {
+        "humanAgentContract": "Agent 先归纳用户群体、产品形态、第一版切片、边界与风险，再请求用户确认；如果信息不足，只能提出候选方向，不能把猜测当成定论。",
+        "autonomyBoundary": "Agent 可以根据当前需求和已有工作区状态推断首轮项目画像，但在用户确认前不得把推断直接写成最终需求事实或越过需求入口去改实现。",
+        "toolBoundary": "仅使用本地 OpenPrd workflow、模板、测试和文档完成这次改动，不依赖新的外部运行时。",
+        "stateModel": "新需求进入时先形成 project framing，再进入 requirement clarification、review/change/tasks 与实现。",
+        "evalPlan": "通过 workspace flow、requirement gate、CLI 输出和模板相关测试验证新流程，同时运行 dev-check、standards、quality 与 run verify。"
+      }
+    }
+  },
+  "reviewPresentation": {
+    "diagram": {
+      "type": "map",
+      "note": "首次提需先做项目画像，再进入后续需求流。"
+    },
+    "mapNodes": {
+      "problem": {
+        "title": "问题定义",
+        "text": "首次提需缺少项目级画像"
+      },
+      "goal": {
+        "title": "目标",
+        "text": "先定用户与首版边界"
+      },
+      "scope": {
+        "title": "范围",
+        "text": "先做轻量画像与条件追问"
+      },
+      "flow": {
+        "title": "流程",
+        "text": "画像确认后再进 PRD 与任务"
+      },
+      "risk": {
+        "title": "风险",
+        "text": "避免重问卷和旧上下文误用"
+      }
+    },
+    "flowNodes": [
+      {
+        "id": "step1",
+        "text": "先归纳用户与产品形态"
+      },
+      {
+        "id": "step2",
+        "text": "再补高价值追问"
+      },
+      {
+        "id": "step3",
+        "text": "确认后进入后续流程"
+      }
+    ],
+    "flowEdges": [
+      {
+        "from": "step1",
+        "to": "step2"
+      },
+      {
+        "from": "step2",
+        "to": "step3"
+      }
+    ],
+    "panels": {
+      "flow": [
+        {
+          "summary": "新增画像",
+          "detail": "首次提需先归纳目标用户、产品形态和第一版切片。"
+        },
+        {
+          "summary": "补充追问",
+          "detail": "信息不足时只追问少量高价值问题，必要时给候选方向。"
+        },
+        {
+          "summary": "继续落地",
+          "detail": "画像确认后再进入 PRD、change 和 tasks，减少后续返工。"
+        }
+      ],
+      "function": [
+        {
+          "summary": "优化 clarify",
+          "detail": "对话内摘要会直接展示适用对象、先做什么和不能破坏什么。"
+        },
+        {
+          "summary": "更新 kickoff",
+          "detail": "冷启动问题从抽象通用提问改成画像导向提问。"
+        },
+        {
+          "summary": "统一模板",
+          "detail": "intake 模板、CLI 输出、技能说明和测试一起对齐新流程。"
+        }
+      ],
+      "guardrail": [
+        {
+          "summary": "默认轻量",
+          "detail": "不把每次首次提需都变成重型初始化问卷。"
+        },
+        {
+          "summary": "风险触发",
+          "detail": "只有命中账号、数据、AI 或收费信号时才展开更深追问。"
+        },
+        {
+          "summary": "保留 review",
+          "detail": "clarify 仍停留在对话内，正式可视化评审继续留给 review 或 diagram。"
+        }
+      ],
+      "risk": [
+        {
+          "summary": "避免过重",
+          "detail": "问题过多会损伤首次提需体验，需要保持卡片化和少量追问。"
+        },
+        {
+          "summary": "避免漏问",
+          "detail": "如果画像层和现有分析脱节，后续仍会出现重复澄清。"
+        },
+        {
+          "summary": "切换上下文",
+          "detail": "旧 active change 没切干净时，hook 可能继续把实现指向错误需求。"
+        }
+      ]
+    }
+  },
+  "workUnitId": "wu-20260602132835-695429e8",
+  "targetRoot": "/Users/chaojifeng/Projects/harness-engineer/openprd",
+  "content": "# OpenPrd 首轮项目画像与自适应需求初始化\n> 语言规则：默认用简体中文生成 PRD、spec、tasks 和用户可见说明；除 PRD、OpenPrd、OpenSpec、API、SDK、CLI、TypeScript、JSON、HTTP、WebSocket、字段 key、命令名、品牌名、产品名和协议名等必要专有名词外，其余内容优先写成简体中文。\n- 版本: v0005\n- 负责人: Codex\n- 产品类型: agent\n- 模板包: agent\n- 状态: synthesized\n- 生成时间: 2026-06-02 13:28:35\n## 元信息\n\n- 标题: OpenPrd 首轮项目画像与自适应需求初始化\n- 负责人: Codex\n- 状态: clarifying\n- 版本: v0005\n- 产品类型: agent\n- 日期: 2026-06-02\n\n## 问题\n\n- 问题陈述: OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。\n- 为什么是现在: 用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。\n- 证据:\n  - 本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。\n  - 本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。\n  - 外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。\n\n## 用户与相关方\n\n- 主要用户:\n  - 第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户\n  - 需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者\n- 次要用户:\n  - 待补充\n- 相关方:\n  - 维护 OpenPrd requirement-intake、workflow 和模板的开发者\n  - 后续需要基于已确认上下文继续实现的多轮 Agent 会话\n\n## 目标与成功标准\n\n- 目标:\n  - 在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改\n  - 让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认\n  - 当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷\n- 成功指标:\n  - 首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项\n  - 复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量\n  - 默认 clarify 仍在对话内完成，不新增新的 clarify HTML\n  - 用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题\n- 验收目标:\n  - workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题\n  - workspace-core 的冷启动 kickoff 问题升级为画像导向问题\n  - intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致\n\n## 范围与非目标\n\n- 范围内:\n  - 在 clarify、intake-reflection 和 interview 中加入首轮项目画像层\n  - 让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问\n  - 命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题\n  - 同步更新模板、技能说明、基础文档、CLI 输出和相关测试\n- 范围外:\n  - 不把首次提需改成一份重型强制问卷\n  - 不把商业模式或技术架构变成所有场景的硬必填 schema\n  - 不新增默认 clarify HTML 或额外前端评审页面\n  - 不让局部小修进入完整项目画像重流程\n\n## 场景与流程\n\n- 主流程:\n  - 用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针\n  - 如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\n  - 如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择\n  - 画像确认后再进入后续 PRD、review、change 和 tasks 流程\n- 边界情况:\n  - 用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节\n  - 已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍\n  - 局部 copy、样式或小交互修正不应被错误升级成重画像流程\n- 失败模式:\n  - 入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\n  - 入口过轻，导致 Agent 没有先确认项目边界就直接落地\n  - 错误复用旧 active change 或旧 PRD 上下文，导致实现偏题\n\n## 可视化图表\n\n### 产品流程\n\n```mermaid\nflowchart LR\n  entry[\"入口触发<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针\"]\n  experience[\"产品内步骤<br/>如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\"]\n  decision{\"决策点<br/>用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节\"}\n  success([\"成功结果<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项\"])\n  failure[[\"失败与恢复<br/>入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\"]]\n  entry -->|\"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版…\"| experience\n  experience -->|\"如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认\"| decision\n  decision -->|\"在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改\"| success\n  decision -.->|\"入口过重，导致 Vibe Coding 用户在第一次提需时无法回答\"| failure\n```\n\n### 架构\n\n```mermaid\nflowchart LR\n  users[\"主要用户<br/>第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户 · 需要在模糊需求下帮助用户收敛…\"]\n  subgraph solution[\"方案边界\"]\n    experience[\"Agent 运行层<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针 …\"]\n    core[\"核心产品逻辑<br/>OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 r…\"]\n    integrations[\"依赖与集成<br/>依赖现有 requirement-intake gate、clarify/capture/synthesize/review/…\"]\n    governance[[\"约束与可靠性<br/>继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。 · …\"]]\n    delivery[\"验证与交接<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项 · 复杂或模糊需求…\"]\n  end\n  users -->|\"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第…\"| experience\n  experience -->|\"产品动作与编排\"| core\n  core -->|\"依赖与外部服务\"| integrations\n  core -.->|\"策略、可靠性与合规\"| governance\n  core -->|\"成功标准与交接\"| delivery\n  integrations -->|\"运营就绪\"| delivery\n  governance -.->|\"评审与确认\"| delivery\n```\n\n## 需求\n\n- 功能需求:\n  - clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针\n  - inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点\n  - 冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问\n  - 类型专项 intake 模板改成更贴近产品与业务语言的提问方式\n- 非功能需求:\n  - 默认澄清仍要保持对话内、轻量、可扫读\n  - 对已有 schema 和生成流程的侵入应尽量小\n  - 输出语言优先面向产品和业务用户，而不是工程内部黑话\n- 业务规则:\n  - 优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户\n  - 只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问\n  - consumer / b2b / agent 优先由系统推断，必要时再请用户确认\n  - clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段\n\n## 业务护栏\n\n- 成本来源:\n  - 本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题\n- 额度与限制:\n  - 不应让每个首次提需都退化成长问卷；默认只问最少必要问题\n- 滥用防护:\n  - 系统不能把未确认的推断当作最终需求事实\n  - 命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险\n- 监控信号:\n  - 观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文\n- 报警阈值:\n  - 如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露\n- 止损动作:\n  - 当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚\n  - 当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现\n\n## 约束、依赖与风险\n\n- 技术约束:\n  - 主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试\n  - 避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强\n- 合规要求:\n  - 继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。\n  - 新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。\n- 依赖:\n  - 依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流\n  - 依赖现有 base / consumer / b2b / agent 模板与评审产物体系\n- 假设:\n  - Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷\n  - 现有 lens 分类能力可保留，只需要前移到项目画像语境里\n- 风险:\n  - 如果问题过多，会损伤首次提需体验\n  - 如果画像层和现有 capture/analysis 脱节，会造成重复提问\n  - 如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change\n- 开放问题:\n  - 后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景\n\n## 类型专项模块\n\n- 类型: Agent 专项\n- humanAgentContract: Agent 先归纳用户群体、产品形态、第一版切片、边界与风险，再请求用户确认；如果信息不足，只能提出候选方向，不能把猜测当成定论。\n- autonomyBoundary: Agent 可以根据当前需求和已有工作区状态推断首轮项目画像，但在用户确认前不得把推断直接写成最终需求事实或越过需求入口去改实现。\n- toolBoundary: 仅使用本地 OpenPrd workflow、模板、测试和文档完成这次改动，不依赖新的外部运行时。\n- stateModel: 新需求进入时先形成 project framing，再进入 requirement clarification、review/change/tasks 与实现。\n- evalPlan: 通过 workspace flow、requirement gate、CLI 输出和模板相关测试验证新流程，同时运行 dev-check、standards、quality 与 run verify。\n\n## 交接\n\n- 负责人: Codex\n- 下一步: 生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。\n- 目标系统: OpenPrd\n",
+  "digest": "7f0e2d2730982a2ae96647d2377f6204e54f8adadf1b18b05f4bc7167046c575",
+  "reviewPresentationMeta": {
+    "validatedAt": "2026-06-02T05:28:56.422Z",
+    "source": "/tmp/openprd-review-presentation-v0005.json",
+    "presentationHash": "33b0760559664a2bdfeb2c363c2aef8985e959cbb8a78070a7821268fab357f2",
+    "violationsHash": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
+    "validator": "openprd review-presentation"
+  }
+}

package/.openprd/state/versions/v0005.md

@@ -0,0 +1,189 @@
+# OpenPrd 首轮项目画像与自适应需求初始化
+> 语言规则：默认用简体中文生成 PRD、spec、tasks 和用户可见说明；除 PRD、OpenPrd、OpenSpec、API、SDK、CLI、TypeScript、JSON、HTTP、WebSocket、字段 key、命令名、品牌名、产品名和协议名等必要专有名词外，其余内容优先写成简体中文。
+- 版本: v0005
+- 负责人: Codex
+- 产品类型: agent
+- 模板包: agent
+- 状态: synthesized
+- 生成时间: 2026-06-02 13:28:35
+## 元信息
+
+- 标题: OpenPrd 首轮项目画像与自适应需求初始化
+- 负责人: Codex
+- 状态: clarifying
+- 版本: v0005
+- 产品类型: agent
+- 日期: 2026-06-02
+
+## 问题
+
+- 问题陈述: OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 review/change/tasks 流程，但缺少一个项目级的首轮画像层。结果是 Agent 容易直接围绕局部需求推进，而没有先确认用户群体、产品形态、第一版切片、先不做什么、不能破坏什么，以及是否命中技术和业务风险。
+- 为什么是现在: 用户明确指出 Vibe Coding 场景下的首轮需求往往模糊：如果不先建立整体轮廓，后续容易返工；如果一上来就强制填写重问卷，又会压垮首轮体验。因此需要把初始化改成轻量项目画像加条件追问。
+- 证据:
+  - 本轮用户明确指出第一次提需缺少 to C / to B / agent、用户群体、商业模式、功能架构和技术边界的前置梳理。
+  - 本地代码检查显示现有 base intake 只覆盖问题、用户、成功、范围与成本信号，缺少独立的首轮项目画像层。
+  - 外部调研表明 Vibe Coding 更适合轻量画像加条件追问，而不是重型初始化问卷。
+
+## 用户与相关方
+
+- 主要用户:
+  - 第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户
+  - 需要在模糊需求下帮助用户收敛方向并继续落地的 Agent 协作者
+- 次要用户:
+  - 待补充
+- 相关方:
+  - 维护 OpenPrd requirement-intake、workflow 和模板的开发者
+  - 后续需要基于已确认上下文继续实现的多轮 Agent 会话
+
+## 目标与成功标准
+
+- 目标:
+  - 在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改
+  - 让系统优先归纳 to C / to B / agent、目标用户、产品形态、第一版切片、非目标和保护项，再请用户确认
+  - 当信息不足时，用条件追问或候选原型方向补齐，而不是要求用户一开始回答完整技术和商业问卷
+- 成功指标:
+  - 首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项
+  - 复杂或模糊需求会触发技术/风险追问，简单明确需求仍保持轻量
+  - 默认 clarify 仍在对话内完成，不新增新的 clarify HTML
+  - 用户能够更快确认方向，后续 PRD 和实现阶段减少返工与错题
+- 验收目标:
+  - workspace-workflow 能生成首轮项目画像、风险探针和更贴近用户语言的确认问题
+  - workspace-core 的冷启动 kickoff 问题升级为画像导向问题
+  - intake 模板、skills、docs、CLI 文本输出和测试与新流程保持一致
+
+## 范围与非目标
+
+- 范围内:
+  - 在 clarify、intake-reflection 和 interview 中加入首轮项目画像层
+  - 让系统先推断 consumer / b2b / agent 与项目形态，再结合第一版切片、非目标、保护项组织追问
+  - 命中技术和业务风险信号时再展开前后端、数据、账号、AI、外部服务、收费等边界问题
+  - 同步更新模板、技能说明、基础文档、CLI 输出和相关测试
+- 范围外:
+  - 不把首次提需改成一份重型强制问卷
+  - 不把商业模式或技术架构变成所有场景的硬必填 schema
+  - 不新增默认 clarify HTML 或额外前端评审页面
+  - 不让局部小修进入完整项目画像重流程
+
+## 场景与流程
+
+- 主流程:
+  - 用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针
+  - 如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认
+  - 如果用户表达模糊，Agent 先追问少量高价值问题，必要时给 2 到 3 个方向或行业原型供用户选择
+  - 画像确认后再进入后续 PRD、review、change 和 tasks 流程
+- 边界情况:
+  - 用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节
+  - 已有项目上下文时应优先沿用已知事实，而不是把所有画像问题重问一遍
+  - 局部 copy、样式或小交互修正不应被错误升级成重画像流程
+- 失败模式:
+  - 入口过重，导致 Vibe Coding 用户在第一次提需时无法回答
+  - 入口过轻，导致 Agent 没有先确认项目边界就直接落地
+  - 错误复用旧 active change 或旧 PRD 上下文，导致实现偏题
+
+## 可视化图表
+
+### 产品流程
+
+```mermaid
+flowchart LR
+  entry["入口触发<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针"]
+  experience["产品内步骤<br/>如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认"]
+  decision{"决策点<br/>用户一开始只有一句模糊想法，需要先给候选方向而不是硬追问技术细节"}
+  success(["成功结果<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项"])
+  failure[["失败与恢复<br/>入口过重，导致 Vibe Coding 用户在第一次提需时无法回答"]]
+  entry -->|"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版…"| experience
+  experience -->|"如果用户表达已经足够清楚，Agent 直接用系统归纳的画像摘要请用户确认"| decision
+  decision -->|"在第一次提需时先形成一页轻量项目画像，而不是直接跳进局部需求修改"| success
+  decision -.->|"入口过重，导致 Vibe Coding 用户在第一次提需时无法回答"| failure
+```
+
+### 架构
+
+```mermaid
+flowchart LR
+  users["主要用户<br/>第一次用 OpenPrd 梳理产品想法的产品经理、独立开发者与 Vibe Coding 用户 · 需要在模糊需求下帮助用户收敛…"]
+  subgraph solution["方案边界"]
+    experience["Agent 运行层<br/>用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第一版先做、先不做、不能破坏、技术落点和风险探针 …"]
+    core["核心产品逻辑<br/>OpenPrd 在用户第一次提需求时虽然已经有 consumer / b2b / agent 分流、clarify 和后续 r…"]
+    integrations["依赖与集成<br/>依赖现有 requirement-intake gate、clarify/capture/synthesize/review/…"]
+    governance[["约束与可靠性<br/>继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。 · …"]]
+    delivery["验证与交接<br/>首轮 clarify 能输出结构化的项目画像摘要，并包含用户群体、产品形态、第一版先做、先不做和不能破坏项 · 复杂或模糊需求…"]
+  end
+  users -->|"用户第一次提需求时，OpenPrd 先输出一页项目画像：用户群体、产品形态、第…"| experience
+  experience -->|"产品动作与编排"| core
+  core -->|"依赖与外部服务"| integrations
+  core -.->|"策略、可靠性与合规"| governance
+  core -->|"成功标准与交接"| delivery
+  integrations -->|"运营就绪"| delivery
+  governance -.->|"评审与确认"| delivery
+```
+
+## 需求
+
+- 功能需求:
+  - clarify 生成的 intake-reflection 应包含首轮项目画像和风险探针
+  - inline clarification 应显式展示适用对象、产品形态、第一版先做、先不做、不能破坏和技术落点
+  - 冷启动 kickoff 问题改成画像导向问题，而不是抽象的通用提问
+  - 类型专项 intake 模板改成更贴近产品与业务语言的提问方式
+- 非功能需求:
+  - 默认澄清仍要保持对话内、轻量、可扫读
+  - 对已有 schema 和生成流程的侵入应尽量小
+  - 输出语言优先面向产品和业务用户，而不是工程内部黑话
+- 业务规则:
+  - 优先由系统归纳后请用户确认，而不是一开始把所有字段抛给用户
+  - 只有命中风险信号时才展开技术、账号、数据、外部服务或成本相关追问
+  - consumer / b2b / agent 优先由系统推断，必要时再请用户确认
+  - clarify 阶段默认不生成 HTML，正式可视化仍留给 review 或 diagram 阶段
+
+## 业务护栏
+
+- 成本来源:
+  - 本次没有新增第三方付费调用；成本主要来自不准确需求初始化带来的返工和错题
+- 额度与限制:
+  - 不应让每个首次提需都退化成长问卷；默认只问最少必要问题
+- 滥用防护:
+  - 系统不能把未确认的推断当作最终需求事实
+  - 命中账号、数据、外部服务、AI 或收费信号时，必须显式提醒边界与风险
+- 监控信号:
+  - 观察首轮 clarify 是否仍然过长、是否反复追问同一类信息、是否错误复用旧 change 上下文
+- 报警阈值:
+  - 如果简单需求被连续升级成深度追问，或复杂需求仍缺少画像摘要，应在测试中显式暴露
+- 止损动作:
+  - 当系统无法准确归纳时，退回到少量高价值确认问题，不假装已经清楚
+  - 当当前工作区上下文明显与本轮需求不匹配时，先刷新到新的 change/task 再实现
+
+## 约束、依赖与风险
+
+- 技术约束:
+  - 主要修改 src/workspace-workflow.js、src/workspace-core.js、CLI 文本输出、.openprd intake 模板、skills/docs 和测试
+  - 避免新增新的硬性必填 schema 字段，优先通过 intake 和 clarification 层完成增强
+- 合规要求:
+  - 继续遵守现有 requirement gate、review gate 和 hook 安全边界，不绕过已确认的需求流程。
+  - 新增提示和用户可见文案应保持面向产品与业务语言，不直接暴露内部技术细节。
+- 依赖:
+  - 依赖现有 requirement-intake gate、clarify/capture/synthesize/review/change/tasks 工作流
+  - 依赖现有 base / consumer / b2b / agent 模板与评审产物体系
+- 假设:
+  - Vibe Coding 用户更愿意确认系统总结，而不是先填写长问卷
+  - 现有 lens 分类能力可保留，只需要前移到项目画像语境里
+- 风险:
+  - 如果问题过多，会损伤首次提需体验
+  - 如果画像层和现有 capture/analysis 脱节，会造成重复提问
+  - 如果没有处理旧上下文切换，hook 可能继续把代码修改指向错误 change
+- 开放问题:
+  - 后续是否需要单独的 profile review artifact 或 diagram，用于更复杂的多系统场景
+
+## 类型专项模块
+
+- 类型: Agent 专项
+- humanAgentContract: Agent 先归纳用户群体、产品形态、第一版切片、边界与风险，再请求用户确认；如果信息不足，只能提出候选方向，不能把猜测当成定论。
+- autonomyBoundary: Agent 可以根据当前需求和已有工作区状态推断首轮项目画像，但在用户确认前不得把推断直接写成最终需求事实或越过需求入口去改实现。
+- toolBoundary: 仅使用本地 OpenPrd workflow、模板、测试和文档完成这次改动，不依赖新的外部运行时。
+- stateModel: 新需求进入时先形成 project framing，再进入 requirement clarification、review/change/tasks 与实现。
+- evalPlan: 通过 workspace flow、requirement gate、CLI 输出和模板相关测试验证新流程，同时运行 dev-check、standards、quality 与 run verify。
+
+## 交接
+
+- 负责人: Codex
+- 下一步: 生成新的 change 和 tasks，并按首轮项目画像流程修改 workflow、模板、文档和测试。
+- 目标系统: OpenPrd

package/.openprd/templates/agent/intake.md

@@ -1,6 +1,7 @@
 # Agent Intake
 
-- What must the agent do autonomously?
-- What must remain human-approved?
-- Which tools and state are available?
-- How do we evaluate success and failure?
+- 哪些步骤希望 Agent 自主完成，给人节省什么时间或心力？
+- 哪些节点必须保留人工确认、审核或兜底，为什么？
+- 这条流程会用到哪些工具、上下文、记忆或状态？
+- 第一版最希望先跑通哪一段 Agent 工作流最有价值？
+- 我们怎么判断它真的帮上忙了，失败时用户会怎么发现、又该怎么恢复？

package/.openprd/templates/b2b/intake.md

@@ -1,6 +1,7 @@
 # B2B Intake
 
-- Who is the buyer?
-- Who is the daily user?
-- Who is the admin?
-- What approval or compliance step can block rollout?
+- 谁最在意这件事值不值得做，谁是买单或拍板的人？
+- 谁是每天真正会用的人？谁负责配置、推进、运营或管理员工作？
+- 这是给内部团队用，还是要卖给客户、合作方或商家用？
+- 现在哪段流程最卡，卡住的代价主要是什么？
+- 如果只能先交付第一版，最小可用切片应该先覆盖哪段业务流程最值？

package/.openprd/templates/base/intake.md

@@ -1,18 +1,24 @@
 # Intake 模板
 
+> 默认先用业务和产品语言回答就可以，不需要一上来讲技术实现。
+
 ## 发现
 
 - 我们要解决什么问题？
-- 主要用户是谁？
+- 主要是给谁用的？他们会在什么场景下最先感受到价值？如果你愿意，也可以直接说它更偏面向个人消费者、面向企业服务，还是以 Agent 为主。
+- 第一版最小可用切片，最希望先让用户完成什么关键动作？
 - 当前临时解决方式是什么？
-- 成功指标是什么？
-- 哪些内容不在范围内？
-- 是否涉及免费用户、额度、用量、AI 调用、第三方服务或其他会产生成本的行为？
+- 哪些内容这轮先不做？
+- 哪些既有能力、流程、体验或业务结果不能被破坏？
+- 成功后，用户会明显感受到什么变化？我们怎么判断它值得做成？
+- 是否涉及账号身份、用户数据、多人协作、AI 调用、外部对接、收费或其他会带来业务风险和成本的行为？
 
 ## Freeze Check
 
 - 产品类型是否已明确？
 - 关键角色是否已明确？
+- 第一版切片是否已明确？
+- 非目标和保护项是否已明确？
 - 是否已有成功指标？
 - 若存在消耗型成本，是否已明确额度限制、滥用防护、监控报警和止损动作？
 - 是否存在阻塞 freeze 的开放问题？

package/.openprd/templates/company/README.md

@@ -1,10 +1,12 @@
-# Company Template Layer
+# 公司模板层
 
-This layer captures company-specific PRD habits and terminology.
+简体中文 | [English](./README_EN.md)
 
-Rules:
+这一层承载公司范围内共用的 PRD 习惯、术语和展示偏好。
 
-- May rename section labels for display.
-- May add company-only fields.
-- May not delete canonical fields.
-- May not change required semantics.
+规则：
+
+- 可以调整展示层标题或命名。
+- 可以补充公司专属字段。
+- 不可以删除规范层已有字段。
+- 不可以改变必填字段的语义。

package/.openprd/templates/company/README_EN.md

@@ -0,0 +1,12 @@
+# Company Template Layer
+
+[简体中文](./README.md) | English
+
+This layer captures company-specific PRD habits and terminology.
+
+Rules:
+
+- May rename section labels for display.
+- May add company-only fields.
+- May not delete canonical fields.
+- May not change required semantics.

package/.openprd/templates/consumer/intake.md

@@ -1,6 +1,7 @@
 # Consumer Intake
 
-- What moment triggers the need?
-- What emotional or lifestyle value matters?
-- What is the activation event?
-- What keeps the user returning?
+- 用户会在什么场景下第一次想用它？
+- 当他决定试一下时，最想省掉哪一步麻烦，或最想获得什么感觉？
+- 第一版最值得先做好的是首次上手、关键转化，还是愿意回来继续用？
+- 什么会让用户愿意继续回来，甚至愿意推荐或付费？
+- 如果只能先做一个最小切片，第一版先守住哪个用户场景最值？

package/.openprd/templates/industry/README.md

@@ -1,16 +1,18 @@
-# Industry Template Layer
+# 行业模板层
 
-This layer is where industry-specific defaults live.
+简体中文 | [English](./README_EN.md)
 
-Examples:
+这一层用于放行业特有的默认值、术语和额外上下文。
+
+示例：
 
 - SaaS
-- E-commerce
-- Fintech
-- Internal tools
+- 电商
+- 金融科技
+- 内部工具
 
-Rules:
+规则：
 
-- May add or reorder sections.
-- May not remove core schema fields.
-- Must keep validation compatible with `prd-core`.
+- 可以新增或重排行业相关小节。
+- 不可以移除核心 schema 字段。
+- 必须保持与 `prd-core` 的校验兼容。