Product Partner 是一个可移植、可持续更新、可被个人、团队和其他 Agent 调用的产品专家能力包。
它要解决的问题不是「让 AI 写更多产品文档」，而是把一个真实产品人的判断标准、方法论、历史产出、复盘经验、知识资产和可执行工作流，沉淀成一个 24 小时在线的产品专家。
02
WHY
为什么做
产品工作里最稀缺的不是模板，而是稳定的判断
在真实协作中，很多问题并不是缺少文档，而是缺少以下能力：
🔄
把历史项目经验迁移到新问题里，而不是机械套案例
🛡️
在团队、平台、公司变化时，保留个人和团队沉淀下来的产品能力
核心目标：把「人脑里的产品判断」产品化，而不是把资料简单堆进提示词。
03
POSITIONING
产品定位
可调用的产品专家 Agent 能力包
👤
个人使用
作为个人产品能力助手，辅助判断、评审、写作和复盘
用户本人
👥
团队使用
作为团队产品专家，帮助 PM、新人和协作团队提高产出质量
产品团队 / 运营 / 设计 / 研发 / 数据
🤖
Agent 调用
作为可安装能力包或 Runtime 能力，被其他平台和 Agent 调用
WorkBuddy / 飞书 Aily / Codex / MCP
当前阶段已具备：角色、人设、产品底层思想、方法卡、案例卡、调用包、权限模型、回归测试集，以及 Runtime P0 的专家调用基础。它还不是完整的团队 Agent 服务，也不是全面生产化的 MCP Server——项目重心是让专家判断稳定、可验证、可迁移，再逐步进入平台化和服务化。
04
DESIGN THINKING
设计思路
从个人经验到团队能力的转化系统
从经验到能力的转化闭环
这套设计背后的核心思路有六点：
01
从经验出发，而不是从模板出发
问题：模板只能统一格式，不能保证判断质量
体现：先沉淀用户认可的 PRD、评审、复盘和产品观点，再提炼成可复用规则
02
把判断和资料分开
问题：资料会变，判断标准需要稳定迁移
体现：核心能力包保存产品观和方法论，企业资料通过权限在运行时接入
03
统一专家入口，内部按任务分工
问题：用户不应该面对一堆零散工具
体现：对外只有 Product Partner，对内按需求、数据、架构、复盘等场景加载不同能力
04
少读、准读、按任务读
问题：全量塞上下文会让回答变散、变慢、变不可控
体现：Runtime Manifest 定义 L0–L3 加载级别，按任务读取 playbook、方法卡和案例卡
05
案例只做启发，不做套用
问题：历史案例如果不判断前提，很容易误导新业务
体现：案例卡必须说明相似点、差异点、可借鉴机制和不可照搬部分
06
用真实任务持续校准
问题：Agent 能力不能只靠设计文档证明
体现：通过回归测试、失败样本、真实材料闭环持续修订
一句话概括：Product Partner 不是把资料喂给 AI，而是把产品判断拆成可迁移的核心能力、可更新的知识资产、可执行的工作流和可验证的评估闭环。
05
CAPABILITY MAP
产品能力地图
先判断问题，再调用知识，最后完成产物
🎯 澄清目标 — 这个问题到底要解决什么
👥 拆用户场景 — 谁在什么情况下为什么需要
⚖️ 做产品取舍 — 值不值得做、先做什么
⚠️ 识别风险 — 事实缺口、验证风险、协作风险
↓
🧠 产品底层思想 — 需求观、用户观、数据观、技术观
📋 方法卡 — 竞品、场景、沟通、复盘
📦 案例卡 — 脱敏案例、历史经验、机制启发
📚 知识源 — Blog、方法论、企业知识库
↓
📝 BRD 前置判断
📋 PRD 审查
🗺️ 需求场景梳理
🔄 项目复盘
📊 路线图 / 能力地图
📈 埋点 / 指标方案
V0 聚焦三类高频、高价值任务：
1. 梳理需求和用户场景
2. 数据分析及项目复盘
3. 架构设计及路线规划
这三类任务最能检验一个产品专家是否真的具备判断力，而不是只会整理格式。
06
ARCHITECTURE
产品架构总览
多入口进入 Runtime，统一调用 Core、Knowledge 和 Skill
Product Partner 完整架构 — 从上到下：调用入口 → Runtime → Core + Knowledge → 治理与评估
| 图中区域 | 中文解释 | 关键价值 |
|---|
| 调用入口 | 用户可从 Codex、WorkBuddy、飞书 Aily 或其他 MCP Client 进入 | 不绑定单一平台，未来可迁移 |
| Runtime | 统一接收问题，判断任务类型，装配上下文，决定是否调用 Skill | 避免每个平台维护一套不同逻辑 |
| Runtime Core | 专家大脑：角色、人设、产品观、治理规则和模板 | 保证输出口吻、判断标准和质量红线稳定 |
| Knowledge Assets | 方法卡、案例卡、知识目录、外部知识源和动态更新机制 | 让专家持续学习，但不污染核心能力 |
| Skill Runner | 执行 BRD、PRD 审查、复盘、路线图等具体工作流 | 让专家从「会分析」走向「能交付」 |
| Governance & Evaluation | 权限、元数据、回归测试、知识盘点和失败样本 | 保证可审计、可回滚、可持续改进 |
从用户视角看，它始终是一个统一的产品专家；从系统视角看，它是一套分层能力系统：入口负责接入，Runtime 负责调度，Core 负责判断，Knowledge 负责供给，Skill 负责执行，Ops 负责治理。
07
CORE ARCHITECTURE
核心架构：可迁移 + 平台
可迁移层跨平台通用，平台层按权限运行时接入
核心架构 — 可迁移层（个人知识库 + 产品思维 + 落地技能）↔ 平台层（业务知识库 + Axhub 需求作品）
| 层级 | 内容 | 通用性 |
|---|
| 可迁移 · 底座 |
个人知识库：知识沉淀、方法论、案例（知识 + 经验） |
✅ 跨平台通用 |
| 可迁移 · 能力 |
产品思维（Playbook）+ 产品落地技能（可调用 Skill） |
✅ 跨平台通用 |
| 平台 / 业务层 |
业务知识库（企业文档 · 内部数据）+ 各类需求作品（Axhub） |
🔒 平台专属 · 按权限运行时接入 |
实现对应：可迁移层的「个人知识库」对应 Knowledge Assets L1–L3；「产品思维」对应 Runtime Core 的 Playbook；「产品落地技能」对应 Skill Layer。平台/业务层的「业务知识库 + Axhub 需求作品」对应 L4，运行时按权限接入，不混入可迁移核心包。
🚀
可迁移层
个人知识库 + 产品思维 + 产品落地技能
跨平台通用
🏢
平台 / 业务层
业务知识库 + 需求作品(Axhub)
按权限运行时接入
08
RUNTIME CORE
专家大脑
Product Partner 最稳定、最核心的部分
核心专家角色
定义 Product Partner 的身份、语言、行为规则和输出标准
用户产品画像
沉淀用户的产品哲学、偏好、质量红线和判断习惯
产品底层思想
把产品视角、需求视角、用户视角、数据证据、技术认知、路线图取舍等拆成可加载 playbook
标准模板
用于 PRD、BRD、评审、复盘等产物的结构化输出
关键设计 — 按任务加载：轻量问题只加载最小专家指令；复杂任务再按场景加载相关 playbook、方法卡和案例卡，避免上下文堆料。
Runtime Core 按任务加载机制 — L0 到 L3 逐级加载最小必要上下文
设计意义：Product Partner 不会每次把全部文件都读进来，而是根据任务难度和场景，选择最小必要上下文。这保证了回答的精准度和速度。
09
KNOWLEDGE ASSETS
持续进化的知识层
让专家越来越接近真实的产品判断，但不把所有资料直接塞进核心提示词
| 层级 | 内容 | 是否可复用 |
|---|
| L1 核心原则 |
产品哲学、判断标准、写作风格、评审标准 |
✅ 是 |
| L2 方法论 |
需求分析、用户研究、竞品分析、路线图、复盘方法 |
✅ 是 |
| L3 案例资产 |
脱敏后的 PRD、评审、架构图、复盘案例 |
⚠️ 视情况 |
| L4 业务私有知识 |
业务知识库（企业文档 · 内部数据）、各类需求作品（Axhub 原型 / 流程图 / 交互稿） |
❌ 否 · 按平台权限接入 |
知识分层金字塔 — 从稳定核心到运行时按需接入
保证一：产品能力可沉淀、可复用，从个人经验转化为团队资产
保证二：企业私有知识不会被混入可迁移核心包
Online Blog、产品方法论、案例卡等公共或可迁移内容，会通过同步 → 蒸馏 → 打标签 → 审阅 → 发布进入知识索引版本；企业资料则只在运行时按身份和权限检索。知识层的核心不是「存得多」，而是可追溯、可授权、可迁移、可更新。
10
SKILL / TOOL LAYER
从会判断到会执行
把产品工作流沉淀成可执行能力
Product Partner 不只回答「怎么看」，还要逐步具备「怎么做」的工作流能力。Skill 层负责把 BRD、PRD 审查、需求梳理、项目复盘、埋点方案、流程图等产品工作流沉淀成可执行能力。
Skill 执行链路 — 从发布到收口的完整流程
P0 已具备：Release 同步、Bundle 校验、原子 Lock 切换、统一 Skill API、Token 身份和审计，以及 brd-writing 的本地执行试点。
设计好处：平台不需要临时下载任意 Skill，线上版本可控，权限可审计，出现问题时可以回滚到上一成功版本。Skill 像「经过审批的产品工作流」一样被调用，而不是临时把任意脚本交给平台执行。
12
VERSION & ROLLBACK
版本、发布与回滚
生产请求由三个版本共同决定，可分层独立回滚
三版本独立管理 — 判断、知识、工具可分层回滚
设计意义：线上质量问题可以定位到「判断、知识、工具」中的某一层，而不是只能整体回退。这比把 Prompt、知识和工具混在一起更适合长期运营。
13
CURRENT STATUS
当前阶段进展
从「概念」到「可调用能力包 + Runtime P0」的关键跨越
产品定位与蓝图
已具备
已明确 Product Partner 是可迁移产品专家能力包
核心专家能力
已具备
已有专家角色、产品画像、输出规则和产品底层思想
知识资产
已具备基础
已有知识目录、方法卡、案例卡和 Blog 学习机制
评估体系
已具备基础
已有 V0 场景、回归测试和失败样本机制
Skill 执行
P0 可用
已支持 Skill 同步、Lock、统一接口和 brd-writing 试点
平台适配
方向明确
已规划 Codex、WorkBuddy、飞书 Aily 和 MCP 接入方式
生产服务化
建设中
还需要完整模型编排、租户权限、企业知识连接器和异步队列
当前阶段关键词：可调用、可验证、可发布基线，但仍在从能力包走向生产服务。
14
ROADMAP
演进路线
围绕真实任务形成闭环，而非继续堆框架
近期重点不是继续堆框架，而是围绕真实任务形成闭环：
1.
用真实或脱敏材料验证 V0 三类场景
2.
把认可的输出沉淀为知识卡、Skill 卡和评估样本
3.
把「不像用户」的输出记录为失败样本
4.
优先建设高频、低风险、易评估的 P0 Skill
5.
在 WorkBuddy 个人入口试点后，再进入飞书 Aily 团队试点
| 阶段 | 汇报表达 | 关键动作 |
|---|
| 现在 |
先把专家能力做稳 |
用真实材料验证判断质量，沉淀失败样本 |
| 近期 |
再把高频工作流做深 |
BRD、PRD 审查、需求梳理、复盘等 P0 Skill |
| 后续 |
最后接入真实组织场景 |
WorkBuddy 个人试点，飞书 Aily 团队试点，MCP 扩展 |
15
KEY TAKEAWAYS
核心判断
Product Partner 的关键创新不在于「用了 Agent」
Product Partner 的关键创新在于把产品能力拆成了可迁移、可治理、可执行、可评估的系统。
3
不是平台绑定机器人 → 而是通过 Runtime 被多个入口调用
4
不是一次性产物 → 而是通过真实任务、失败样本、版本发布和回归测试持续进化