一键在 Manus 中运行任何 Skill

开始使用

product-lens

星标4

分支0

更新时间2026年4月25日 23:59

写代码前先做 4 模式产品诊断（诊断/创始人审查/用户旅程/优先级），输出 PRODUCT-BRIEF.md。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

18811184907

18811184907/mcc

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Product Lens — 动手写代码前先想清楚"为什么"

这个 skill 专注于产品诊断，不负责写实现级别的 spec。

如果产出需要进入正式 PRD → 实现流程，直接衔接 /prd 和 planner agent。

何时使用

启动任何新功能前——先验证"为什么要做"
每周产品回顾——我们在做对的事情吗？
在多个功能之间选不出来时
发布前——对用户旅程做一次清醒检查
把模糊想法变成 PRODUCT-BRIEF 交给 engineering 之前

工作方式

Mode 1: Product Diagnostic（产品诊断）

像 YC office hours 自动化版本，问最硬的 7 个问题：

1. Who is this for? (specific person, not "developers")
2. What's the pain? (quantify: how often, how bad, what do they do today?)
3. Why now? (what changed that makes this possible/necessary?)
4. What's the 10-star version? (if money/time were unlimited)
5. What's the MVP? (smallest thing that proves the thesis)
6. What's the anti-goal? (what are you explicitly NOT building?)
7. How do you know it's working? (metric, not vibes)

输出：PRODUCT-BRIEF.md，包含回答 / 风险 / go/no-go 建议。

如果结论是"是，继续建"，下一步进入 /prd 把 brief 变成正式 PRD。

Mode 2: Founder Review（创始人视角复盘）

从创始人视角审视当前项目：

1. Read README, CLAUDE.md, package.json, recent commits
2. Infer: what is this trying to be?
3. Score: product-market fit signals (0-10)
   - Usage growth trajectory
   - Retention indicators (repeat contributors, return users)
   - Revenue signals (pricing page, billing code, Stripe integration)
   - Competitive moat (what's hard to copy?)
4. Identify: the one thing that would 10x this
5. Flag: things you're building that don't matter

Mode 3: User Journey Audit（用户旅程审计）

映射真实用户体验：

1. Clone/install the product as a new user
2. Document every friction point (confusing steps, errors, missing docs)
3. Time each step
4. Compare to competitor onboarding
5. Score: time-to-value (how long until the user gets their first win?)
6. Recommend: top 3 fixes for onboarding

Mode 4: Feature Prioritization（优先级决策）

10 个想法选 2 个时：

1. List all candidate features
2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
3. Rank by ICE score
4. Apply constraints: runway, team size, dependencies
5. Output: prioritized roadmap with rationale

优先级决策矩阵（v2.2 补 · 4 个维度交叉判断）

四模式产出建议后，用以下矩阵决定先做哪件事：

ICE × Impact-Effort 4 象限

维度	1 分	3 分	5 分
Impact	影响 <10% 用户或营收	10-30%	>30% / 战略级
Confidence	假设多 / 数据少	部分用户访谈支持	已有数据或竞品验证
Effort（反向）	1 周以上	2-5 天	<2 天

ICE 分 = (Impact × Confidence) ÷ (6 - Effort)

≥10：立即做
5-9：本季度做
<5：暂缓 / 进 backlog

4 象限快速归类

            高 Impact
              ↑
   做! ────┼──── 做（但要小心）
  快赢      │      战略投入
  (高 Impact│      (高 Impact
   低 Effort)│       高 Effort)
─────────┼─────────→ 高 Effort
   填空      │      不做
   (低 Impact│      (低 Impact
   低 Effort)│       高 Effort)
              ↓
            低 Impact

快赢（高 Impact 低 Effort）：先做
战略（高 Impact 高 Effort）：拆成小步、小步回报
填空（低 Impact 低 Effort）：碎片时间做（实习生 / 周五下午）
不做（低 Impact 高 Effort）：果断说不

用户访谈数据 vs 直觉

有 ≥5 个目标用户访谈 + 量化数据? → 信 ICE 分
只是直觉 / 创始人偏好?         → ICE 分仅参考，先去访谈再排

反模式

❌ 用 ICE 给已经决定的事情背书（先有结论再算分 → 数据是装的）
❌ Impact 给所有 feature 都打 5（说明你没在 trade-off）
❌ Effort 不区分"做出来"和"做对"（MVP 用 Effort 估时；生产质量再 ×2-3）

输出

所有模式产出可执行文档，不写长篇大论。每一条建议都带一个具体的下一步动作 + ICE 分（让用户立即知道排序）。

格式：

## 建议清单（已 ICE 排序）

### 立即做（ICE ≥ 10）
1. **{建议}** — Impact 5 / Confidence 4 / Effort 2 → ICE = 10
   下一步：{具体动作}

### 本季度做（ICE 5-9）
...

### 暂缓（ICE < 5）
...

与 MCC 其它组件的协同

产出 PRODUCT-BRIEF.md 后 → /prd 把 brief 变成正式 PRD
planner agent 在拿到 PRD 后负责拆解实现计划
和 brainstorming mode 的分工：brainstorming 是轻量对话式探索；product-lens 是产出落盘 brief 的结构化诊断
和 confidence-check 的关系：confidence-check 检查实现层（"这个 feature 能不能正确做出来"）；product-lens 检查产品层（"这个 feature 该不该做"）

同仓库更多 Skills

同仓库

codex-audit

18811184907/mcc

Claude 用 codex CLI 做差异化对抗审查 + Layer 2 二审 + auto-fix 全链路。**v2.8.0 起流式 streaming**：codex 思考过程实时事件流（onEvent 回调每个 thread.started / item.completed / turn.completed），idle-timeout（90s 没新事件才算卡死）替代固定 totalTimeout。runCodexAudit 是 async，要 await。三层架构：Layer 1 codex (OpenAI) 流式产 finding → Layer 2 finding-validator subagent (Claude fresh) 独立复现 → Layer 3 通过自动 Edit 修不询问用户。触发：/plan 完成 / /implement 大改动 / /review 3 路并行 / /pr 4 路 PR 预检。codex 是不同模型 = 不同盲区，跟 Claude 互补不替代。**全自动 — 用户从不需要手动管 codex**。

2026-04-304

user-vault

18811184907/mcc

Claude 自动接管用户级跨项目敏感配置（personal API key / 个人 PAT / git 全局身份 / 跨项目 SSH host）。触发：用户提到跨项目通用 secret、或 project-vault 检测到条目应提升到用户级、或用户问'跨项目共用 secret 放哪'。写 ~/.claude/USER_VAULT.md，hook 自动 sync 到 .user-env.{sh,ps1} + git --global + ~/.ssh/config。与 project-vault 分工：本 skill 跨项目，project-vault 单项目。

2026-04-294

claudemd-sync

18811184907/mcc

Claude 主动沉淀用户跨项目偏好到 ~/.claude/CLAUDE.md，post-hook 自动 commit+push 到 dotfiles repo 跨设备同步。触发：用户说'记下这个偏好 / 沉淀到 CLAUDE.md / 把这个习惯加进去'、用户连续多次重复同样反馈（'又忘了'）、或做了跨项目通用决策（'以后所有项目都用 zod'）。仅追加不覆盖。与 continuous-learning-v2 分工：本 skill 主动显式沉淀偏好，learning-v2 被动观察行为。

2026-04-294

database-schema-doc

18811184907/mcc

Claude 自动维护 docs/SCHEMA.md。触发：用户提到表结构（'加 users 表，字段 email/password'）、写改 ORM 模型（Prisma/SQLAlchemy/TypeORM）、写改 migration SQL、或问'数据库表结构在哪'。不存在自动建（从 ORM 抽骨架），存在直接 Edit 加表/字段；业务含义缺失填 '_TODO_' 占位。与 architecture-decision-records 分工：本 skill 记结构现状，ADR 记选型决策（如选 Postgres）。

2026-04-294

dev-changelog

18811184907/mcc

Claude 自动维护开发实时流水日志 docs/CHANGELOG-DEV.md，记**正在发生**的需求/进度/坑/下一步。触发：用户讲新需求或改主意（◇）、Claude 完成 ≥30 行或跨文件改动（✓）、遇 blocker（⚠）、决定下一步（→）。与 git log（已落盘代码）/ ADR（终态决策）/ SCHEMA（结构）/ mistakes（bug 根因）分工——本 skill 记进行中状态。每条 ≤5 行倒序。

2026-04-294

project-vault

18811184907/mcc

Claude 自动接管项目级敏感配置（API key / DB 密码 / 部署 IP / SSH / token）。触发：用户在对话里说出任何 secret 或 IP、或代码里硬编 secret、或问 '.env 怎么放 / token 存哪'。写 .claude/PROJECT_VAULT.md，hook 自动 sync 到 .env.local + .env.example + ~/.ssh/config + SECRETS-INDEX.md，强制 .gitignore。与 user-vault 分工：本 skill 单项目，跨项目用 user-vault。

2026-04-294

name	product-lens
description	写代码前先做 4 模式产品诊断（诊断/创始人审查/用户旅程/优先级），输出 PRODUCT-BRIEF.md。

Product Lens — 动手写代码前先想清楚"为什么"

这个 skill 专注于产品诊断，不负责写实现级别的 spec。

如果产出需要进入正式 PRD → 实现流程，直接衔接 /prd 和 planner agent。

何时使用

启动任何新功能前——先验证"为什么要做"
每周产品回顾——我们在做对的事情吗？
在多个功能之间选不出来时
发布前——对用户旅程做一次清醒检查
把模糊想法变成 PRODUCT-BRIEF 交给 engineering 之前

工作方式

Mode 1: Product Diagnostic（产品诊断）

像 YC office hours 自动化版本，问最硬的 7 个问题：

1. Who is this for? (specific person, not "developers")
2. What's the pain? (quantify: how often, how bad, what do they do today?)
3. Why now? (what changed that makes this possible/necessary?)
4. What's the 10-star version? (if money/time were unlimited)
5. What's the MVP? (smallest thing that proves the thesis)
6. What's the anti-goal? (what are you explicitly NOT building?)
7. How do you know it's working? (metric, not vibes)

输出：PRODUCT-BRIEF.md，包含回答 / 风险 / go/no-go 建议。

如果结论是"是，继续建"，下一步进入 /prd 把 brief 变成正式 PRD。

Mode 2: Founder Review（创始人视角复盘）

从创始人视角审视当前项目：

1. Read README, CLAUDE.md, package.json, recent commits
2. Infer: what is this trying to be?
3. Score: product-market fit signals (0-10)
   - Usage growth trajectory
   - Retention indicators (repeat contributors, return users)
   - Revenue signals (pricing page, billing code, Stripe integration)
   - Competitive moat (what's hard to copy?)
4. Identify: the one thing that would 10x this
5. Flag: things you're building that don't matter

Mode 3: User Journey Audit（用户旅程审计）

映射真实用户体验：

1. Clone/install the product as a new user
2. Document every friction point (confusing steps, errors, missing docs)
3. Time each step
4. Compare to competitor onboarding
5. Score: time-to-value (how long until the user gets their first win?)
6. Recommend: top 3 fixes for onboarding

Mode 4: Feature Prioritization（优先级决策）

10 个想法选 2 个时：

1. List all candidate features
2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
3. Rank by ICE score
4. Apply constraints: runway, team size, dependencies
5. Output: prioritized roadmap with rationale

优先级决策矩阵（v2.2 补 · 4 个维度交叉判断）

四模式产出建议后，用以下矩阵决定先做哪件事：

ICE × Impact-Effort 4 象限

维度	1 分	3 分	5 分
Impact	影响 <10% 用户或营收	10-30%	>30% / 战略级
Confidence	假设多 / 数据少	部分用户访谈支持	已有数据或竞品验证
Effort（反向）	1 周以上	2-5 天	<2 天

ICE 分 = (Impact × Confidence) ÷ (6 - Effort)

≥10：立即做
5-9：本季度做
<5：暂缓 / 进 backlog

4 象限快速归类

            高 Impact
              ↑
   做! ────┼──── 做（但要小心）
  快赢      │      战略投入
  (高 Impact│      (高 Impact
   低 Effort)│       高 Effort)
─────────┼─────────→ 高 Effort
   填空      │      不做
   (低 Impact│      (低 Impact
   低 Effort)│       高 Effort)
              ↓
            低 Impact

快赢（高 Impact 低 Effort）：先做
战略（高 Impact 高 Effort）：拆成小步、小步回报
填空（低 Impact 低 Effort）：碎片时间做（实习生 / 周五下午）
不做（低 Impact 高 Effort）：果断说不

用户访谈数据 vs 直觉

有 ≥5 个目标用户访谈 + 量化数据? → 信 ICE 分
只是直觉 / 创始人偏好?         → ICE 分仅参考，先去访谈再排

反模式

❌ 用 ICE 给已经决定的事情背书（先有结论再算分 → 数据是装的）
❌ Impact 给所有 feature 都打 5（说明你没在 trade-off）
❌ Effort 不区分"做出来"和"做对"（MVP 用 Effort 估时；生产质量再 ×2-3）

输出

所有模式产出可执行文档，不写长篇大论。每一条建议都带一个具体的下一步动作 + ICE 分（让用户立即知道排序）。

格式：

## 建议清单（已 ICE 排序）

### 立即做（ICE ≥ 10）
1. **{建议}** — Impact 5 / Confidence 4 / Effort 2 → ICE = 10
   下一步：{具体动作}

### 本季度做（ICE 5-9）
...

### 暂缓（ICE < 5）
...

与 MCC 其它组件的协同

产出 PRODUCT-BRIEF.md 后 → /prd 把 brief 变成正式 PRD
planner agent 在拿到 PRD 后负责拆解实现计划
和 brainstorming mode 的分工：brainstorming 是轻量对话式探索；product-lens 是产出落盘 brief 的结构化诊断
和 confidence-check 的关系：confidence-check 检查实现层（"这个 feature 能不能正确做出来"）；product-lens 检查产品层（"这个 feature 该不该做"）