产品透镜 — 先思考再构建 是做什么的？
此职责掌管产品诊断，而非实现就绪的规范编写。
如果用户需要持久的 PRD 到 SRS 或能力契约工件，请将任务转交至 product-capability。
何时使用
- 开始任何功能之前 — 验证“为什么”
- 周度产品回顾 — 我们是否在构建正确的东西？
- 在两个功能之间犹豫不决时
- 上线之前 — 对用户旅程进行严格检查
- 将模糊的想法转化为产品简报后，再开始工程规划
工作原理
模式 1：产品诊断
类似于 YC 办公时间的自动化版本。提出棘手的难题：
1. 这是为谁做的？（具体的人，不泛指“开发者”）
2. 痛点是什么？（量化：频率、严重程度、他们现在怎么做？）
3. 为什么是现在？（什么变化使这成为可能/必要？）
4. 10 星版本是什么？（如果无限资金/时间）
5. MVP 是什么？（能证明假设的最小化产品）
6. 反目标是什么？（你明确不构建什么？）
7. 如何知道它有效？（依据指标，而非感觉）
输出：一份 PRODUCT-BRIEF.md，包含答案、风险以及“继续/停止”建议。
如果结果是“是的，构建这个”，下一个职责是 product-capability，而不是更多的创始人表演。
模式 2：创始人审查
以创始人视角审查当前项目：
1. 阅读 README、CLAUDE.md、package.json、最近的提交
2. 推断：这个项目试图成为什么？
3. 评分：产品市场契合度信号（0-10）
- 使用增长轨迹
- 留存指标（重复贡献者、回访用户）
- 收入信号（定价页面、计费代码、Stripe 集成）
- 竞争护城河（什么难以复制？）
4. 识别：一件事能带来 10 倍增长
5. 标记：你正在构建但无关紧要的东西
模式 3：用户旅程审计
映射实际用户体验：
1. 以新用户身份克隆/安装产品
2. 记录每个摩擦点（令人困惑的步骤、错误、缺失的文档）
3. 计时每个步骤
4. 对比竞争对手的用户引导流程
5. 评分：价值转化时间（用户多久才能获得第一次成功体验？）
6. 推荐：用户引导流程的前三大修复点
模式 4：功能优先级排序
当你有 10 个想法但只能选 2 个时：
1. 列出所有候选功能
2. 对每个功能评分：影响力（1-5）× 信心（1-5）÷ 工作量（1-5）
3. 按 ICE 分数排序
4. 应用约束条件：资金余额、团队规模、依赖关系
5. 输出：带有理由的优先级路线图
输出
所有模式都输出可操作的文档，而非长篇大论。每条建议都附带具体的下一步行动。
集成
与以下技能配合使用：
/browser-qa验证用户旅程审计发现/design-system audit进行视觉打磨评估/canary-watch进行发布后监控product-capability当产品简报需要转变为实现就绪的能力计划时