--- title: "京东健康OPC团队的产品全流程Skill探索" source_url: "https://mp.weixin.qq.com/s/k9adgO1QynvscitSSVA6pg" source: wechat ingested: 2026-07-05T04:04:26Z sha256: a17c3c290ad37ebcbc9964e96316b08b432a686fb5c740ae42015e285359f51f vxc: 56 stars: 4 _provider: deepseek --- # 京东健康OPC团队的产品全流程Skill探索 --- source: wechat source_url: https://mp.weixin.qq.com/s/k9adgO1QynvscitSSVA6pg ingested: 2026-07-05 source_published: 2026年6月26日 17:26 --- # 京东健康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 最常见的使用顺序如下： 这条链的内在逻辑是： 1. **先判断问题是否值得做** （问题判断）； 2. **再把方向打磨成可执行需求** （需求定义）； 3. **再把需求放进优先级、容量和依赖约束** （排期执行）； 4. **最后用指标验证结果，并完成同步** （上线复盘）。 可以把它当成一套轻量工作协议：**任何需求只要进入开发，就至少要经过「证据、假设、边界、排期、验收、复盘」六个环节。** **** ** 三、第一阶段：问题判断 ** > **本阶段目标** ：判断「这个问题是否足够重要」，而不是证明「我们想做的方案是对的」。 需求刚出现时，不要急着写 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 变更说明、复盘清单）固化为团队文档，后续需求直接复用。 ** 八、常见误区 ** 结合实践，提醒几个容易踩的坑： 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） 推荐阅读 [京东 Oxygen xLLM 大模型推理引擎正式捐赠开放原子开源基金会，共建国产 AI Infra 生态]() [全球首个！京东全栈开源JoyAI-VL-Interaction，让大模型从“一问一答”走向“边看边说”]() [进入全球第一梯队！京东开源JoyAI-Echo框架 长视频生成“所想即所得”时代到来]() [高可用架构的工程智慧]() **关注我们**