京东健康OPC团队的产品全流程Skill探索

一、背景和适用场景

京东健康正在探索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。在对话框输入以下提示词即可安装：

从 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 最常见的使用顺序如下：

这条链的内在逻辑是：

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

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

三、第一阶段：问题判断

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

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

3.1 使用哪些 Skill

3.2 怎么接入需求上下文

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

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

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

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

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

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

3.3 启动提示词

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

请按 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 的需求规格建议至少包含：

 
## 需求规格
 
### 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 中尤其要坚持一个原则：新增需求不是「多做一点」，而是一次资源再分配。

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

 
## 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，把结果拉回到需求最初定义的成功指标上：

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

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

6.2 分对象同步：stakeholder-update

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

建议固定使用状态色：

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

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

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

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

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

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

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

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

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

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

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

第四步：补齐其余环节

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

第五步：沉淀团队约定

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

八、常见误区

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

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

九、总结

对 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_）

京东健康OPC团队的产品全流程Skill探索

评论 (0)