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 從公開儲存庫中收錄這些內容。

檢舉或申請下架