京东健康OPC团队的产品全流程Skill探索-京东云开发者社区

>【本文来自专栏：[AI研发新范式](http://sd.jd.com/column/541?shareId=111034&isHideShareButton=1)，欢迎阅读收藏 】

## 一、背景和适用场景

京东健康正在探索OPC（One Person Company）下模式的高效交付，在 OPC 团队中，没有专职产品角色，这意味着团队不仅要关注「把需求做完」，还必须回答几个更前置的问题：

- 这个问题是否真的值得做？
- 证据来自用户、数据、业务，还是只是个人判断？
- 当前方案是不是唯一方案？
- 需求边界是否清楚？
- 当前迭代是否真的有产研资源承接？
- 上线后如何判断成功或失败？
- 风险、进展和结果如何对不同对象同步？

Anthropic 开源的 [Product Management Skills](https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills) 正好可以承接这些问题。它本质上是一套**产研共同决策框架**：把从发现问题到上线复盘的过程，拆成一组可重复使用的动作，帮助 OPC 在缺少专职产品角色的情况下，仍然保持清晰、可追溯、可评审的产品流程。

本文把这套实践适配到 OPC 的工作场景，快速补齐OPC团队的产品能力，跑通从需求发现、定义、排期、开发到上线复盘的全过程。

## 二、流程总览

### 2.1 安装 Skill

这套实践在 Anthropic 原生环境中对应 product-management plugin；在 JoyCode 或 Codex 中，需要接入 `product-management/skills` 下的 8 个 Skill。在对话框输入以下提示词即可安装：

```text
从 https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills
安装以下 skills：
synthesize-research、metrics-review、competitive-brief、product-brainstorming、
write-spec、roadmap-update、sprint-planning、stakeholder-update。
```

### 2.2 一条判断链

8 个 Skill 最常见的使用顺序如下：
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-06-11-10-457wi10DM0DPbK9ngi.png)

这条链的内在逻辑是：

1. **先判断问题是否值得做**（问题判断）；
2. **再把方向打磨成可执行需求**（需求定义）；
3. **再把需求放进优先级、容量和依赖约束**（排期执行）；
4. **最后用指标验证结果，并完成同步**（上线复盘）。

可以把它当成一套轻量工作协议：**任何需求只要进入开发，就至少要经过「证据、假设、边界、排期、验收、复盘」六个环节。**

## 三、第一阶段：问题判断

> **本阶段目标**：判断「这个问题是否足够重要」，而不是证明「我们想做的方案是对的」。

需求刚出现时，不要急着写 PRD，也不要直接进入技术方案。第一步是判断问题本身是否成立。

### 3.1 使用哪些 Skill

| Skill | 用在什么时候 | 产出什么 |
| --- | --- | --- |
| synthesize-research | 有用户访谈、工单、销售反馈、问卷、会议纪要时 | 用户主题、痛点、机会点、置信度 |
| metrics-review | 有使用数据、转化数据、留存数据、业务指标时 | 指标现状、异常变化、目标差距、行动建议 |
| competitive-brief | 需要理解竞品、替代方案、市场动作时 | 竞品差异、机会、威胁、战略含义 |

### 3.2 怎么接入需求上下文

Anthropic 的做法不是让团队手工整理一份完整报告后再交给 AI，而是把现有材料按来源接入到 Skill 工作流里。以 synthesize-research 为例，它支持三类输入：

- **直接粘贴**：访谈记录、会议纪要、问卷开放题、工单摘要。
- **上传文件**：研究文档、表格、录音转写摘要、调研结果。
- **连接工具**：从知识库、用户反馈系统、产品分析工具、会议转写工具中拉取上下文。

在 Anthropic 的插件设计里，这些工具用通用占位符表示：

| Anthropic 连接器类别 | 典型输入 | 用来回答的问题 |
| --- | --- | --- |
| knowledge base（知识库） | PRD、历史方案、研究文档、会议沉淀 | 以前是否讨论过？当时为什么这么决策？ |
| user feedback（用户反馈） | 工单、客服反馈、用户会话、功能请求 | 用户真正抱怨什么？频率和严重程度如何？ |
| product analytics（产品分析） | 漏斗、留存、转化、功能使用数据 | 数据是否支持这个问题？影响面有多大？ |
| meeting transcription（会议转写） | 访谈转写、评审纪要、客户会议摘要 | 关键观点、分歧和未决问题是什么？ |
| project tracker（项目跟踪） | 需求池、缺陷、迭代任务、历史 issue | 是否已有相关工作？是否有重复或依赖？ |
| chat（即时沟通） | 群聊讨论、异步决策、风险同步 | 团队最近在争论什么？是否已有隐性结论？ |

我们无法直接使用这些海外工具的连接器，但思路完全可以复用：**把内部系统的材料映射到同样的证据类别**。

| OPC 材料 | 建议处理方式 | 进入哪个 Skill |
| --- | --- | --- |
| 历史 PRD、方案文档、复盘文档 | 摘出目标、结论、遗留问题、历史取舍 | synthesize-research / write-spec |
| 工单、缺陷、客服反馈、用户反馈 | 按问题类型、用户角色、影响范围、频次归类 | synthesize-research |
| 问卷结果 | 区分结构化数据和开放题；结构化数据看分布，开放题做主题聚类 | synthesize-research / metrics-review |
| 会议纪要、访谈纪要 | 标注参会角色、结论、分歧、待确认事项 | synthesize-research |
| 数据看板、埋点、经营指标 | 提供当前值、上期值、目标值、时间窗口、口径说明 | metrics-review |
| 需求池、迭代任务、项目计划 | 标注状态、owner、依赖、是否重复、是否阻塞 | roadmap-update / sprint-planning |
| 竞品资料、外部案例 | 标注来源日期、能力差异、用户价值、是否只是功能跟随 | competitive-brief |

关键是**不要把材料无差别丢进去**。每份材料进入 Skill 前，至少要带上 5 个字段：

```markdown
## 材料输入格式

- 来源：来自哪个系统、文档或会议？
- 时间：材料产生于什么时候？是否仍然有效？
- 对象：涉及哪个用户、业务方、系统或场景？
- 内容：核心事实、原话、数据或结论是什么？
- 关联：它支持或反驳哪个问题假设？
```

### 3.3 启动提示词

可以直接使用下面这段提示词启动问题判断：

```text
请按 synthesize-research / metrics-review 方法，
帮我判断这个问题是否值得进入需求定义。

我会提供以下材料：
1. 历史文档和已有结论
2. 工单 / 用户反馈 / 缺陷记录
3. 问卷和访谈纪要
4. 会议纪要和待决策事项
5. 指标看板或数据摘要

请输出：
- 主要问题主题
- 每个主题的证据来源
- 频率、影响和置信度
- 用户说法与实际数据是否一致
- 当前最关键的假设
- 还缺哪些证据
- 是否建议进入 product-brainstorming 或 write-spec
```

> **本阶段产出**：问题主题清单 + 证据与置信度评估 + 是否进入需求定义的结论。

## 四、第二阶段：需求定义

> **本阶段目标**：把「值得做的问题」打磨成可评审、可拆解、可验收的需求规格。

### 4.1 先发散：product-brainstorming

当问题值得继续推进后，先进入 product-brainstorming。这个 Skill 的价值是帮助团队拆开**问题空间、方案空间和关键假设**。它会推动团队追问：

- 谁真正有这个问题？
- 用户现在如何绕过这个问题？
- 这是症状还是根因？
- 除了当前方案，还有哪些替代方案？
- 哪个假设一旦错误，整个方向就不成立？
- 最便宜的验证方式是什么？

### 4.2 再收敛：write-spec

方向收敛后，使用 write-spec 生成需求规格。重点是让需求具备**可评审、可拆解、可验收**的结构。OPC 的需求规格建议至少包含：

```markdown
## 需求规格

### 1. Problem
用户是谁？问题是什么？不解决会造成什么影响？

### 2. Evidence
证据来自哪里？用户反馈、数据、竞品、业务承诺分别是什么？

### 3. Goals
本需求要达成哪些可衡量结果？

### 4. Non-goals
本期明确不做什么？为什么不做？

### 5. Requirements
- P0：没有这些就不能解决核心问题。
- P1：明显改善体验，但不阻塞上线。
- P2：未来可能需要，但本期不做。

### 6. Acceptance Criteria
如何判断每个需求点已经完成？

### 7. Metrics
上线后看哪些领先指标和滞后指标？

### 8. Open Questions
还有哪些问题未决？谁负责回答？是否阻塞开发？
```

一个好的需求规格，不是把所有想法都写进去，而是清楚说明：**为什么做、做什么、不做什么、做到什么程度算完成。**

> **本阶段产出**：经过假设检验的方向 + 一份结构完整的需求规格文档。

## 五、第三阶段：排期执行

> **本阶段目标**：把需求放进优先级、容量和依赖约束，落成可执行的迭代计划。

需求清楚后，仍然不能直接进入迭代。还需要判断它在整体计划里的位置。

### 5.1 先定位置：roadmap-update

roadmap-update 适合回答：

- 这个需求应该放在 Now、Next 还是 Later？
- 它和当前目标、OKR 或项目主题是否一致？
- 它依赖哪些人、系统、数据或外部条件？
- 如果要插入这个需求，什么需求要延期、降级或移除？
- 当前 roadmap 是否已经超出实际产研资源的容量？

OPC 中尤其要坚持一个原则：**新增需求不是「多做一点」，而是一次资源再分配。**

因此，每次新增或提优需求，都应明确说明：

```markdown
## Roadmap 变更说明

- 变更内容：新增 / 提前 / 延后 / 移除什么？
- 变更原因：出现了什么新信息？
- 影响范围：影响哪些需求、人员、时间点？
- 取舍结果：为了做它，什么被降级、延期或移除？
- 风险与依赖：有哪些阻塞项？谁负责处理？
```

### 5.2 再落计划：sprint-planning

进入当前迭代前，使用 sprint-planning 把路线图里的方向落到具体执行计划：

- 本迭代唯一的 sprint goal 是什么？
- 团队真实可用容量是多少？
- 上个迭代 carryover（顺延任务）的原因是什么？
- P0、P1、P2 分别是什么？
- 每个事项 owner 是谁？
- 哪些依赖和风险会影响交付？
- Definition of Done（完成标准）是什么？

**建议只规划 70%-80% 的产研资源容量**，剩余空间留给线上问题、临时协作、评审返工和不可预期中断。

> **本阶段产出**：一份带取舍说明的 roadmap 变更记录 + 一份带容量约束的迭代计划。

## 六、第四阶段：上线复盘

> **本阶段目标**：用指标验证结果、形成下一步决策，并向不同对象完成同步。

上线不是结束，而是下一轮判断的开始。

### 6.1 用指标说话：metrics-review

上线后应再次使用 metrics-review，把结果拉回到需求最初定义的成功指标上：

```markdown
## 上线复盘

- 目标指标是否变化？
- 哪些领先指标最先出现信号？
- 哪些用户群体受益最大？
- 是否出现负向影响？
- 结果符合预期，还是推翻了原假设？
- 下一步是继续迭代、扩大范围、回滚，还是停止投入？
```

复盘时要避免只说「已上线」「已完成」。应该回答的是：**上线后我们学到了什么，下一步决策是什么。**

### 6.2 分对象同步：stakeholder-update

当需要向不同对象同步时，使用 stakeholder-update。同一件事，对不同对象应该有不同表达方式：

| 对象 | 重点 |
| --- | --- |
| 管理层 | 结论、状态、目标进展、风险、需要决策 |
| 研发 | 已完成、进行中、阻塞、技术决策、优先级变化 |
| 跨职能团队 | 对他们的影响、需要他们配合什么、截止时间 |
| 外部用户或客户 | 新能力、用户收益、使用方式、已知限制 |

建议固定使用状态色：

- **Green**：按计划推进，无明显阻塞。
- **Yellow**：已有风险，需要关注或调整。
- **Red**：明显偏离计划，需要决策、资源或范围调整。

状态色不是汇报好坏，而是**帮助团队尽早处理风险**。

> **本阶段产出**：一份指标对照的复盘结论 + 面向不同对象的同步材料。

## 七、快速上手：试点同事的最小启动路径

如果你所在的团队刚开始 OPC 试点，不需要一次性把 8 个 Skill 全部用起来。建议按下面的路径，用一个真实需求把链路跑通：

**第一步：安装 Skill（10 分钟）**

按第二章的提示词，在 JoyCode 或 Codex 中安装 8 个 Skill。

**第二步：挑一个手头的真实需求（不要挑太大的）**

选一个你近期正要评估或正要排期的需求，规模以「一个迭代内能做完」为宜。

**第三步：先只用三个 Skill 跑一遍核心链路**

1. 把手头的工单、反馈、数据按「材料输入格式」整理好，用 synthesize-research 做一次问题判断；
2. 如果结论是值得做，用 write-spec 产出需求规格，拉研发一起评审；
3. 上线后用 metrics-review 对照规格里的 Metrics 做一次复盘。

**第四步：补齐其余环节**

核心链路顺了之后，再把 product-brainstorming（方案发散）、roadmap-update / sprint-planning（排期）、stakeholder-update（同步）补进日常流程。

**第五步：沉淀团队约定**

把跑通过程中形成的模板（材料输入格式、需求规格、Roadmap 变更说明、复盘清单）固化为团队文档，后续需求直接复用。

## 八、常见误区

结合实践，提醒几个容易踩的坑：

1. **拿到需求就写 PRD**。第一步永远是问题判断：证据够不够、问题值不值得做。跳过这一步，后面做得再快也可能是白做。
2. **用 Skill 来证明自己想做的方案是对的**。问题判断阶段的目标是判断「问题是否足够重要」，不是给既定方案找论据。
3. **把材料无差别丢给 AI**。没有来源、时间、对象、关联假设的材料，产出的结论置信度很低。先按 5 字段格式整理，再进入 Skill。
4. **把新增需求当成「多做一点」**。容量是恒定的，新增需求必然挤占其他事项。每次插入需求都要写清楚取舍结果。
5. **迭代排满 100% 容量**。线上问题、临时协作、返工是常态，只规划 70%-80%，剩下的留作缓冲。
6. **复盘只说「已上线」**。上线是验证的开始。复盘要回答指标变化、假设验证结果和下一步决策。
7. **对所有人用同一份汇报**。管理层要结论和决策点，研发要阻塞和优先级，跨职能团队要配合事项。同一件事，按对象裁剪表达。

## 九、总结

对 OPC 来说，这套 Skill 的最大价值不在于多了几个 AI 工具，而在于：**让产品与研发共同承担产品判断，并把每一次判断沉淀成可讨论、可追踪、可复盘的工作资产。**

证据、假设、边界、排期、验收、复盘——任何需求进入开发前后，都走一遍这六个环节，OPC 就能在没有专职产品角色的情况下，依然保持产品流程的质量。

## 参考来源

- [Anthropic Product Management Plugin](https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills)

其他同类方案：

- [phuryn/pm-skills](https://github.com/phuryn/pm-skills)
- [refoundai/lenny-skills](https://github.com/refoundai/lenny-skills)