mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-15 11:14:46 +08:00
94 lines
3.0 KiB
Markdown
94 lines
3.0 KiB
Markdown
---
|
||
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. 建议：入门流程的三大修复方案
|
||
```
|
||
|
||
### 模式 4：功能优先级排序
|
||
|
||
当你有 10 个想法却需选出 2 个时：
|
||
|
||
```
|
||
1. 列出所有候选功能
|
||
2. 对每个功能进行评分：影响（1-5）× 信心（1-5）÷ 工作量（1-5）
|
||
3. 按 ICE 分数排序
|
||
4. 应用约束条件：时间窗口、团队规模、依赖关系
|
||
5. 输出：带有理由的优先级路线图
|
||
```
|
||
|
||
## 输出
|
||
|
||
所有模式均输出可操作文档，而非长篇大论。每条建议均附带具体下一步行动。
|
||
|
||
## 集成
|
||
|
||
配合使用：
|
||
|
||
* `/browser-qa` 验证用户旅程审计结果
|
||
* `/design-system audit` 进行视觉优化评估
|
||
* `/canary-watch` 用于发布后监控
|
||
* `product-capability` 当产品简报需转化为可实施的能力计划时
|