// AI Native 产品方法论——AI Native 产品团队设计的实操 Skill。 用户提供产品阶段和团队现状，Skill 自动执行团队设计： 角色梳理 → 人机分工设计 → 能力缺口识别 → 团队协作流程 → 能力建设路径 → 输出 AI Native 团队方案。 基于《AI Native 产品方法论》第25章 AI Native 产品团队。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p11-product-team |
| description | AI Native 产品方法论——AI Native 产品团队设计的实操 Skill。 用户提供产品阶段和团队现状，Skill 自动执行团队设计： 角色梳理 → 人机分工设计 → 能力缺口识别 → 团队协作流程 → 能力建设路径 → 输出 AI Native 团队方案。 基于《AI Native 产品方法论》第25章 AI Native 产品团队。 |
| tags | ["ai-product","methodology","team-design","human-ai-roles","capability-building","book-skill"] |
| author | Max |
| source_book | AI Native 产品方法论 |
| source_chapter | 第25章 AI Native 产品团队 |
| version | 1 |
| stage | p11 |
| homepage | https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p11-product-team |
现有角色 × AI 能力矩阵：
| 传统角色 | AI 可承接的工作 | 人仍主导的工作 | 需新增的能力 |
|---|---|---|---|
| 产品经理 | 文档草稿、竞品分析、数据汇总 | 方向判断、关系管理、决策 | AI 评估能力 |
| 设计师 | 设计稿初稿、变体生成 | 用户体验判断、品牌把控 | AI 协作设计 |
| 研发工程师 | 代码补全、测试生成、文档 | 架构设计、系统集成 | Agent 运维能力 |
| 数据分析师 | 数据清洗、报表生成、可视化 | 业务洞察、假设提出 | AI 质量评估 |
| 运营 | 内容生成、客服辅助 | 策略制定、关系维护 | 反馈工程 |
原则：
| 任务特征 | 分配 |
|---|---|
| 高频、标准化、有评估标准 | AI 主导 |
| 低频、模糊、无标准答案 | 人类主导 |
| 高风险、不可逆 | 人类主导 + AI 建议 |
| 需要跨角色协作 | 人在回路中 |
| 全新领域、无历史数据 | 人类主导 + 快速实验 |
AI Native 团队新增能力项：
| 能力项 | 描述 | 优先级 |
|---|---|---|
| AI 评估能力 | 评估 AI 输出质量、稳定性和适用场景 | P0 |
| 反馈工程 | 设计反馈机制让 AI 持续改进 | P0 |
| Agent 运维 | 监控、调试、优化 Agent 行为 | P1 |
| 上下文设计 | 设计和维护高质量的上下文输入 | P1 |
| AI 风险管理 | 识别和管理 AI 相关的风险和合规问题 | P1 |
| 人机协作设计 | 设计自然的人机交互流程 | P2 |
传统流程:
产品经理 → 写PRD → 设计师 → 设计稿 → 研发 → 实现 → 测试 → 上线
AI Native 流程:
产品经理 + AI → PRD草稿 → 快速原型实验
设计师 + AI → 设计变体 → 人类选择与优化
研发 + AI Copilot → 代码 → 人类review
持续反馈 → AI 质量评估 → 持续优化
这个角色是 AI Native 团队的新增核心角色：
"我们的 AI 客服团队有 5 人：1 个 PM、2 个客服、2 个研发，正在引入 AI Copilot，需要重新设计团队"
角色 × AI 能力矩阵:
PM:
AI承接: 文档草稿、竞品分析模板、数据汇总
人类主导: 需求判断、优先级决策、客户沟通
新增能力: AI评估能力（评估Copilot输出质量）
客服:
AI承接: 常见问题回复、工单分类、FAQ检索
人类主导: 复杂投诉、情绪处理、高风险沟通
新增能力: 反馈工程（高质量反馈 → 模型优化）
研发:
AI承接: 代码补全、测试生成、文档
人类主导: 架构设计、Agent运维、系统集成
新增能力: Agent运维能力（监控+调试+优化）
人机分工协议:
AI主导场景:
- 订单状态查询 → AI自动回复
- FAQ检索 → AI回答
- 意图分类 → AI + 人工确认
人类主导场景:
- 退款决策 → 人工
- 投诉处理 → 人工
- 系统架构 → 人类
协作场景:
- 回复建议 → AI生成 + 人工确认
- 知识库更新 → AI建议 + 人工审核
- 新功能设计 → 人类主导 + AI辅助
能力建设路线图:
第1月:
- 全员AI工具培训（ChatGPT/Copilot基础）
- 建立反馈收集机制
- 目标: 人均AI使用频率>3次/天
第2-3月:
- PM: 学习AI评估方法，建立Copilot评估标准
- 客服: 建立反馈工程机制
- 研发: Agent运维基础培训
第4-6月:
- 新增AI质量专员（从现有PM或客服中选拔）
- 建立完整的AI质量评估体系
- 目标: Copilot采纳率>70%
新增角色 JD - AI质量专员:
职责:
- 建立AI输出质量评估标准和Rubric
- 设计反馈工程机制，持续优化AI表现
- 监控AI系统在生产环境的质量指标
能力要求:
- 理解AI能力边界和局限性
- 有数据分析能力（评估质量指标）
- 有产品Sense（判断AI输出是否满足用户需求）
- 擅长跨角色沟通（协调PM/客服/研发）
要让方法论落地，组织必须先建设基本实验环境，包括模型平台、数据平台、实验工具、样本与评估机制。一个最低可用的实验环境通常包括：可切换的模型能力入口、可用的资料与数据访问层、基本的样本集和评估方式、可快速搭建 Prompt/RAG/Agent/Workflow 的试验工具、最基础的权限和审计边界。
在 AI Native 团队里，产品经理不再只是需求整理者，而更像能力设计者；工程师不再只是实现者，而更像 AI 系统设计者；数据工程师与领域专家的地位明显上升，因为数据质量和场景知识直接决定能力质量。AI 产品经理是围绕问题、资料、能力、评估和价值组织实验的人。
再好的平台，如果组织还坚持"先定全量需求、再按计划开发"，也很难做出真正的 AI 产品。AI Native 团队必须接受三件事：不是所有实验都会成功；失败实验同样提供信息；产品方向可以在实验中被修正。实验文化的核心不是鼓励混乱试错，而是建立一套有节奏的工作方式：用小范围问题定义替代大而全需求定义、用阶段性证据替代主观拍板、用失败样本和人工修正推动下一轮实验。
同一套方法论在不同规模组织里落地方式不同。个人要解决的是"如何先把能力用起来"；小团队要解决的是"如何让协作不失真"；大公司要解决的是"如何在规模化推进时不失控"。组织结构应该服务于方法论落地，而不是先画一张组织图再倒逼项目去适应。
传统软件团队常用功能交接模式：产品提需求、研发做实现、测试做验证、运维负责上线。AI Native 团队更适合围绕同一个问题做协同推进：产品定义问题和价值目标、AI 工程师验证能力和系统方案、数据工程师处理资料供给、领域专家提供场景判断与成功标准。让"问题、资料、能力、评估、工程"在同一条链上被讨论。
输入：组织现状、可用基础设施
执行要点：
输出：最小实验环境清单（已有 / 需补齐 / 优先级）
输入：团队现状、业务场景
执行要点：
输出：角色 × AI 能力矩阵
输入：角色矩阵、业务场景
执行要点：
输出：人机分工协议
输入：人机分工协议、团队能力现状
执行要点：
输出：能力建设路线图
输入：人机分工协议、能力路线图
执行要点：
输出：协作流程改造方案
输入：组织规模、业务复杂度
执行要点：
输出：组织落地方案
某传统软件公司有 20 人产品团队（5 PM、8 研发、4 测试、3 运营），计划做 AI 客服产品。当前状态：
# AI Native 团队方案：传统团队转型 AI 客服
最小实验环境:
已有:
- 工单系统和历史数据（10 万+ 条）
- 基本的开发和测试环境
- 领域专家（1 人，客服行业 3 年经验）
需补齐:
- 模型接入层（接入 LLM API）
- 评估工具（自动评估 + 人工评估）
- 样本管理（标注工具 + 样本库）
- 权限审计（数据脱敏 + 操作日志）
优先级:
P0: 模型接入层 + 评估工具
P1: 样本管理
P2: 权限审计
角色 × AI 能力矩阵:
PM（5人）:
AI承接: 文档草稿、竞品分析模板、数据汇总、用户画像
人类主导: 需求判断、优先级决策、客户沟通、方向决策
新增能力: AI 评估能力（评估 Copilot 输出质量）
转型路径: 2 人转 AI 产品经理，3 人保持传统 PM
研发（8人）:
AI承接: 代码补全、测试生成、文档、简单 Bug 修复
人类主导: 架构设计、Agent 运维、系统集成、安全审计
新增能力: Agent 运维能力（监控 + 调试 + 优化）
转型路径: 4 人转 AI 工程师，4 人保持后端/前端
测试（4人）:
AI承接: 测试用例生成、回归测试、性能测试
人类主导: 测试策略、边界场景、用户体验测试
新增能力: AI 质量评估（评估 AI 输出的准确性和稳定性）
转型路径: 2 人转 AI 质量专员，2 人保持测试
运营（3人）:
AI承接: 内容生成、数据报告、客服辅助
人类主导: 策略制定、关系维护、危机处理
新增能力: 反馈工程（设计反馈机制让 AI 持续改进）
领域专家（1人）:
AI承接: 无（领域专家是 AI 的输入源）
人类主导: 业务规则、例外情况、成功标准、案例审核
新增能力: 无（保持领域深度，学习如何与 AI 协作）
人机分工协议:
AI 主导场景:
- FAQ 自动回答 → AI 直接回复
- 工单分类 → AI 自动分类 + 人工抽检
- 意图识别 → AI 识别 + 人工确认
人类主导场景:
- 退款决策 → 人工确认
- 投诉处理 → 人工处理
- 系统架构 → 人类设计
协作场景:
- 回复建议 → AI 生成 + 人工确认
- 知识库更新 → AI 建议 + 人工审核
- 产品设计 → 人类主导 + AI 辅助
能力建设路线图:
第 1 月:
- 全员 AI 工具培训（ChatGPT/Copilot 基础）
- 建立反馈收集机制
- 目标: 人均 AI 使用频率 >3 次/天
第 2-3 月:
- PM: 学习 AI 评估方法，建立 Copilot 评估标准
- 研发: Agent 运维基础培训（LangChain/LlamaIndex）
- 测试: AI 质量评估培训
- 领域专家: 学习如何提供高质量的领域知识
第 4-6 月:
- 新增 AI 质量专员（从测试中选拔）
- 建立完整的 AI 质量评估体系
- 目标: Copilot 采纳率 >70%
新增角色 JD - AI 质量专员:
职责:
- 建立 AI 输出质量评估标准和 Rubric
- 设计反馈工程机制，持续优化 AI 表现
- 监控 AI 系统在生产环境的质量指标
- 沉淀成功和失败案例，形成团队知识
能力要求:
- 理解 AI 能力边界和局限性
- 有数据分析能力（评估质量指标）
- 有产品 Sense（判断 AI 输出是否满足用户需求）
- 擅长跨角色沟通（协调 PM/客服/研发）
协作流程:
传统流程:
产品经理 → 写 PRD → 设计师 → 设计稿 → 研发 → 实现 → 测试 → 上线
AI Native 流程:
PM + AI → PRD 草稿 → 快速原型实验 → 验证
设计师 + AI → 设计变体 → 人类选择与优化
研发 + AI Copilot → 代码 → 人类 review
测试 + AI → 测试用例 → 人工补充边界场景
持续反馈 → AI 质量评估 → 持续优化
落地方案（小团队路径）:
第一步: 选一个高频、可验证、资料可得的问题（客服 Copilot）
第二步: 搭出最小实验闭环（问题 → 资料 → 能力 → 评估 → 人工修正）
第三步: 围绕这条闭环暴露的真实需求，反推需要什么角色和工具
目标: 3 个月内跑通第一条业务闭环，6 个月内出 MVP
| 决策点 | 选择 | 理由 |
|---|---|---|
| 转型路径 | 渐进式转型 | 团队无 AI 经验，不能一次性全转 |
| 新增角色 | AI 质量专员 | 确保 AI 输出质量可控 |
| 落地路径 | 小团队路径 | 20 人规模，适合围绕一个问题跑通闭环 |
| 领域专家 | 专职 1 人 | 客服行业经验是核心壁垒 |
某大型互联网公司有 200+ 产品技术团队，计划在多个业务线推广 AI Native 方法论。当前状态：
# AI Native 团队方案：大公司能力升级
最小实验环境:
已有:
- 模型平台（统一的 LLM 接入和管理）
- 数据平台（数据仓库 + 数据治理）
- 基本的开发和部署工具
需补齐:
- 统一的实验工具（Prompt 管理 + 评估 + 样本库）
- 跨团队知识共享机制
- 统一的治理框架（权限 + 审计 + 合规）
优先级:
P0: 统一实验工具
P1: 跨团队知识共享
P2: 统一治理框架
角色变化:
AI 产品经理（新增）:
职责: 围绕问题、资料、能力、评估和价值组织实验
来源: 从现有 PM 中选拔 + 外部招聘
数量: 每个业务线 1-2 人
领域专家（强化）:
职责: 提供业务规则、真实案例、例外情况和判断标准
来源: 从业务团队中选拔
数量: 每个业务线 1-2 人
AI 工程师（转型）:
职责: AI 系统设计、Agent 开发、模型调优
来源: 从后端/算法工程师中转型
数量: 每个业务线 3-5 人
数据工程师（强化）:
职责: 资料供给、结构化、权限管理
来源: 现有数据团队
数量: 每个业务线 2-3 人
落地方案（大公司路径）:
第一层 - 业务单元跑通闭环:
- 选择 3 个高密度、高价值、强约束的业务场景
- 每个场景组建最小团队（AI PM + AI 工程师 + 数据工程师 + 领域专家）
- 目标: 3 个月内验证问题 → 资料 → 能力 → 评估 → 价值的完整链路
第二层 - 平台层沉淀通用能力:
- 模型接入统一管理
- 权限控制和日志审计
- 样本评估和知识接入
- 工作流编排工具
- 目标: 6 个月内建成可复用的平台能力
第三层 - 组织层面推广:
- 建立"局部试验、平台沉淀、分层治理、逐步复制"的推进机制
- 每季度跨团队分享会，沉淀最佳实践
- 建立统一但不过度僵化的治理框架
- 目标: 12 个月内覆盖 80% 业务线
能力建设路线图:
第 1-3 月:
- 选拔 AI 产品经理（每业务线 1-2 人）
- 领域专家赋能（学习如何与 AI 团队协作）
- AI 工程师培训（Agent 开发 + 评估方法）
- 目标: 3 个示范性闭环跑通
第 4-6 月:
- 平台能力建设（实验工具 + 知识共享 + 治理框架）
- 跨团队分享会（每月一次）
- 目标: 平台能力可复用
第 7-12 月:
- 推广到更多业务线
- 建立统一治理框架
- 沉淀组织级 AI 产品能力
- 目标: 80% 业务线覆盖
治理框架:
分层治理:
- 业务层: 各业务线自主决策实验方向和节奏
- 平台层: 统一模型接入、权限控制、日志审计
- 组织层: 统一方法论、最佳实践、治理边界
推进机制:
- 局部试验: 允许各业务线自主探索
- 平台沉淀: 成功经验沉淀为平台能力
- 分层治理: 不同层级有不同决策权
- 逐步复制: 成功模式逐步推广到更多业务线
| 决策点 | 选择 | 理由 |
|---|---|---|
| 落地路径 | 三层推进 | 大公司需要平台支撑和治理框架 |
| 示范场景 | 3 个业务线 | 有代表性，可复制 |
| 新增角色 | AI PM + 领域专家 | 大公司最缺的是这两个角色 |
| 治理方式 | 分层治理 | 避免过度统一压死创新 |