P11 product team
Skill gmaxxxie/ai-native-product-agent-skills/skills/p11-product-team
'AI Native 产品方法论——AI Native 产品团队设计的实操 Skill。From its SKILL.md
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p11-product-teamAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
SKILL.md
20.7 KB, ~8.1k tokens by cl100k_base, as published. Nobody here has run it
AI Native 产品团队 Skill
使用场景
- 团队正在或计划引入 AI 能力,需要重新设计工作角色和协作流程
- 团队中 AI 能力与传统产品能力之间出现职责重叠或空白
- 需要建立 AI Native 时代的团队能力建设和招募路径
核心概念
- 人机分工设计:根据能力特征分配给人类或 AI,避免"所有人都要用 AI"或"AI 能做的就不需要人"
- 能力缺口识别:评估团队在 AI 时代缺少哪些新能力(如 AI 评估、Agent 设计、反馈工程)
- AI 质量专员:专门负责 AI 输出质量的评估、反馈和优化的新角色
团队设计四步法
第一步:角色梳理
现有角色 × AI 能力矩阵:
| 传统角色 | AI 可承接的工作 | 人仍主导的工作 | 需新增的能力 |
|---|---|---|---|
| 产品经理 | 文档草稿、竞品分析、数据汇总 | 方向判断、关系管理、决策 | AI 评估能力 |
| 设计师 | 设计稿初稿、变体生成 | 用户体验判断、品牌把控 | AI 协作设计 |
| 研发工程师 | 代码补全、测试生成、文档 | 架构设计、系统集成 | Agent 运维能力 |
| 数据分析师 | 数据清洗、报表生成、可视化 | 业务洞察、假设提出 | AI 质量评估 |
| 运营 | 内容生成、客服辅助 | 策略制定、关系维护 | 反馈工程 |
第二步:人机分工设计
原则:
- AI 接管高频、高重复、有标准答案的工作
- 人类保留低频、高风险、需要判断的工作
- 新增"AI 质量评估"类角色,专门负责评估 AI 输出的质量
人机分工决策框架
| 任务特征 | 分配 |
|---|---|
| 高频、标准化、有评估标准 | AI 主导 |
| 低频、模糊、无标准答案 | 人类主导 |
| 高风险、不可逆 | 人类主导 + AI 建议 |
| 需要跨角色协作 | 人在回路中 |
| 全新领域、无历史数据 | 人类主导 + 快速实验 |
第三步:能力缺口识别
AI Native 团队新增能力项:
| 能力项 | 描述 | 优先级 |
|---|---|---|
| AI 评估能力 | 评估 AI 输出质量、稳定性和适用场景 | P0 |
| 反馈工程 | 设计反馈机制让 AI 持续改进 | P0 |
| Agent 运维 | 监控、调试、优化 Agent 行为 | P1 |
| 上下文设计 | 设计和维护高质量的上下文输入 | P1 |
| AI 风险管理 | 识别和管理 AI 相关的风险和合规问题 | P1 |
| 人机协作设计 | 设计自然的人机交互流程 | P2 |
第四步:团队协作流程
传统流程 vs AI Native 流程
传统流程:
产品经理 → 写PRD → 设计师 → 设计稿 → 研发 → 实现 → 测试 → 上线
AI Native 流程:
产品经理 + AI → PRD草稿 → 快速原型实验
设计师 + AI → 设计变体 → 人类选择与优化
研发 + AI Copilot → 代码 → 人类review
持续反馈 → AI 质量评估 → 持续优化
AI 质量专员职责
这个角色是 AI Native 团队的新增核心角色:
- 评估 AI 输出质量:建立评估标准和 Rubric
- 反馈工程:设计反馈机制,让 AI 持续改进
- 边界维护:确保 AI 不超出能力边界
- 案例沉淀:积累成功和失败案例,形成团队知识
输出物:AI Native 团队方案
- 角色 × AI 能力矩阵:每个角色的 AI 化程度和新增能力要求
- 人机分工协议:明确哪些工作归 AI、哪些归人类、哪些需要协作
- 能力建设路线图:团队需要建设哪些新能力、优先级和获取路径
- 新增角色 JD:AI 质量专员等新角色的职责和能力要求
- 协作流程改造:从传统流程到 AI Native 流程的具体变化点
与其他 Skill 的关系
- 前置:了解完整方法论后可系统性设计团队
- 协同:@ai-native-production-ops(AI 质量评估嵌入生产运行)
- 配套:@ai-native-ux-design(UX团队 AI 化),@ai-native-agent-skill-design(Agent 运维能力)
示例
用户输入
"我们的 AI 客服团队有 5 人:1 个 PM、2 个客服、2 个研发,正在引入 AI Copilot,需要重新设计团队"
Skill 执行
角色 × 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/客服/研发)
深入核心概念
1. 组织先要具备最小实验环境
要让方法论落地,组织必须先建设基本实验环境,包括模型平台、数据平台、实验工具、样本与评估机制。一个最低可用的实验环境通常包括:可切换的模型能力入口、可用的资料与数据访问层、基本的样本集和评估方式、可快速搭建 Prompt/RAG/Agent/Workflow 的试验工具、最基础的权限和审计边界。
2. 角色正在发生根本变化
在 AI Native 团队里,产品经理不再只是需求整理者,而更像能力设计者;工程师不再只是实现者,而更像 AI 系统设计者;数据工程师与领域专家的地位明显上升,因为数据质量和场景知识直接决定能力质量。AI 产品经理是围绕问题、资料、能力、评估和价值组织实验的人。
3. 实验文化比工具更重要
再好的平台,如果组织还坚持"先定全量需求、再按计划开发",也很难做出真正的 AI 产品。AI Native 团队必须接受三件事:不是所有实验都会成功;失败实验同样提供信息;产品方向可以在实验中被修正。实验文化的核心不是鼓励混乱试错,而是建立一套有节奏的工作方式:用小范围问题定义替代大而全需求定义、用阶段性证据替代主观拍板、用失败样本和人工修正推动下一轮实验。
4. 方法论落地要按组织规模展开
同一套方法论在不同规模组织里落地方式不同。个人要解决的是"如何先把能力用起来";小团队要解决的是"如何让协作不失真";大公司要解决的是"如何在规模化推进时不失控"。组织结构应该服务于方法论落地,而不是先画一张组织图再倒逼项目去适应。
5. 围绕问题链协作而非功能交接
传统软件团队常用功能交接模式:产品提需求、研发做实现、测试做验证、运维负责上线。AI Native 团队更适合围绕同一个问题做协同推进:产品定义问题和价值目标、AI 工程师验证能力和系统方案、数据工程师处理资料供给、领域专家提供场景判断与成功标准。让"问题、资料、能力、评估、工程"在同一条链上被讨论。
分步执行
步骤 1:建立最小实验环境
输入:组织现状、可用基础设施
执行要点:
- 评估现有能力:是否有可切换的模型能力入口?是否有可用的数据访问层?是否有基本的评估机制?
- 补齐基础设施:模型接入层、数据平台、实验工具、样本管理、权限审计
- 目标不是建成"大平台",而是让团队有能力稳定地做"方向定界 → 试验展开 → 系统构建"的前半段工作
输出:最小实验环境清单(已有 / 需补齐 / 优先级)
步骤 2:角色梳理——现有角色 × AI 能力矩阵
输入:团队现状、业务场景
执行要点:
- 盘点现有角色:产品经理、设计师、研发工程师、数据分析师、运营等
- 分析每个角色的 AI 化程度:哪些工作 AI 可承接?哪些人仍主导?需新增哪些能力?
- 识别关键角色变化:AI 产品经理(能力设计者)、AI 工程师(系统设计者)、领域专家(场景判断者)
输出:角色 × AI 能力矩阵
步骤 3:人机分工设计
输入:角色矩阵、业务场景
执行要点:
- 应用分工决策框架:高频标准化 → AI 主导;低频模糊 → 人类主导;高风险不可逆 → 人类主导 + AI 建议
- 设计协作模式:自动模式、Copilot 模式、人在回路中模式
- 定义 AI 质量评估角色:专门负责评估 AI 输出质量的新角色
输出:人机分工协议
步骤 4:能力缺口识别与能力建设路线图
输入:人机分工协议、团队能力现状
执行要点:
- 识别新增能力项:AI 评估能力(P0)、反馈工程(P0)、Agent 运维(P1)、上下文设计(P1)、AI 风险管理(P1)、人机协作设计(P2)
- 设计获取路径:内部培训、外部招聘、项目实战
- 制定时间表:第 1 月基础培训 → 第 2-3 月专项能力 → 第 4-6 月新增角色
输出:能力建设路线图
步骤 5:协作流程改造
输入:人机分工协议、能力路线图
执行要点:
- 设计 AI Native 流程:产品经理 + AI → PRD 草稿 → 快速原型实验;设计师 + AI → 设计变体 → 人类选择与优化;研发 + AI Copilot → 代码 → 人类 review
- 建立共享实验面板:让产品、工程、领域专家至少对"什么算有效、什么算无效"形成共同语言
- 减少串行交接,避免反馈链条太长
输出:协作流程改造方案
步骤 6:按规模选择落地路径
输入:组织规模、业务复杂度
执行要点:
- 个人:选一个高频重复任务,围绕它跑通最小闭环,形成可复用的个人系统
- 小团队(3-8 人):围绕一个共享问题形成稳定协作,建立共享实验面板,把一条真实业务闭环跑通
- 大公司:从业务单元跑通闭环 → 平台层沉淀通用能力 → 组织层面推广,建立"局部试验、平台沉淀、分层治理、逐步复制"的推进机制
输出:组织落地方案
示例 1:传统软件团队转型 AI 客服团队
背景
某传统软件公司有 20 人产品团队(5 PM、8 研发、4 测试、3 运营),计划做 AI 客服产品。当前状态:
- 团队无 AI 产品经验
- 有 3 年客服行业经验的领域专家 1 人
- 已有工单系统和客服数据
- 管理层要求 6 个月内出 MVP
Skill 执行输出
# 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 人 | 客服行业经验是核心壁垒 |
示例 2:大公司 AI 产品团队能力升级
背景
某大型互联网公司有 200+ 产品技术团队,计划在多个业务线推广 AI Native 方法论。当前状态:
- 各业务线已独立开展 AI 项目,但缺乏统一方法论
- 有成熟的模型平台和数据平台
- 缺少 AI 产品经理和领域专家
- 成功经验无法跨团队复用
Skill 执行输出
# 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 + 领域专家 | 大公司最缺的是这两个角色 |
| 治理方式 | 分层治理 | 避免过度统一压死创新 |
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.