product-lens

name	product-lens
description	在构建之前使用此技能验证"为什么"，运行产品诊断，并在需求变为实现契约之前对产品方向进行压力测试。
origin	ECC

产品视角 —— 先思考再构建

此通道负责产品诊断，而非实现就绪的规格说明编写。

如果用户需要持久的 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. 推荐：引导流程的前 3 个修复

模式 4：功能优先级排序

当你有 10 个想法需要选择 2 个时：

1. 列出所有候选功能
2. 对每个评分：影响力（1-5）× 信心（1-5）÷ 工作量（1-5）
3. 按 ICE 分数排名
4. 应用约束：资金跑道、团队规模、依赖关系
5. 输出：带理由的优先级路线图

输出

所有模式输出可操作的文档，而非文章。每个推荐都有具体的下一步。

集成

配合使用：

• /browser-qa 验证用户旅程审计发现
• /design-system audit 进行视觉质量评估
• /canary-watch 用于发布后监控
• product-capability 当产品简报需要变成实现就绪的能力计划时