
关于
使用此技能验证产品决策和功能设计的合理性。
name: product-lens description: 使用本技能在构建前验证"为什么",运行产品诊断,在请求变成实施合同之前压力测试产品方向。 origin: ECC
产品透镜 — 构建前先思考
此通道负责产品诊断,而非编写可实施的规格文档。
如果用户需要持久的PRD到SRS或能力合同文档,请移交给 product-capability。
何时使用
- 开始任何功能之前——验证"为什么"
- 每周产品审查——我们在构建正确的东西吗?
- 在功能选择之间犹豫不决时
- 发布前——对用户旅程进行健全性检查
- 将模糊想法转化为工程规划前的产品简报时
工作原理
模式1:产品诊断
像YC办公时间但自动化。提出尖锐问题:
1. 这是为谁做的?(具体的人,不是"开发者")
2. 痛点是什么?(量化:多频繁,多严重,他们现在怎么做?)
3. 为什么是现在?(什么变化使这成为可能/必要?)
4. 10星版本是什么?(如果金钱/时间无限)
5. MVP是什么?(证明论点的最小东西)
6. 反目标是什么?(你明确不构建什么?)
7. 你怎么知道它在起作用?(指标,不是感觉)
输出:一个 PRODUCT-BRIEF.md,包含答案、风险和go/no-go建议。
如果结果是"是的,构建这个",下一个通道是 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进行详细规格编写
兼容工具
Claude CodeCursor
标签
AI与机器学习
