Product Lens

affaan-m/ECC/docs/zh-CN/skills/product-lens

作者 affaan-mef648e01899ba3e8dc6371642deaaf64b4477775无许可证275K 个星标收录于 2026年10月9日更新于 2026年10月9日仓库4天前更新

使用此技能在构建前验证“为什么”,运行产品诊断,并在请求成为实施合同之前对产品方向进行压力测试。

AI 生成的概览

在工程规划前运行产品诊断,压力测试产品或功能是否值得构建。

功能
引导智能体完成四种产品思考模式:产品诊断、创始人评审、用户旅程审计和功能优先级排序。每种模式提出结构化问题并产出可执行文档,例如包含答案、风险和“可行/不可行”建议的 PRODUCT-BRIEF.md,或带理由的优先级路线图。它明确不编写可实施规格,而是将这类工作移交给单独的能力规划技能。
适用场景
适用于启动任何功能前验证“为什么”、每周产品评审、在多个功能间难以抉择时、发布前对用户旅程做合理性检查,以及将模糊想法转化为产品简报时。
运行要求
无需脚本或特殊工具,仅为指令。部分模式会读取项目文件,如 README、CLAUDE.md、package.json 和最近的提交,并提及用于浏览器 QA、设计系统审计和发布后监控的配套技能。

产品透镜 —— 先思考,再构建

此通道负责产品诊断,而非编写可实施的规格文档。

若用户需要持久的 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 当产品简报需转化为可实施的能力计划时

来源与署名

来源:affaan-m/ECC位于docs/zh-CN/skills/product-lens提交ef648e0

许可证: 无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架