---

name: ai-product-manager-engine description: AI产品经理决策引擎。提供AI产品类型路由、大模型应用设计决策树、AI产品指标体系、AI伦理合规框架、2026年趋势洞察、质量门控清单。当用户需要AI产品规划、大模型应用设计、AI产品指标设计、AI伦理合规审查、AI产品策略、Prompt工程决策、RAG设计、Agent产品设计时使用此技能。

AI产品经理决策引擎

专家级AI产品经理能力框架，覆盖AI产品全生命周期决策。

---

一、AI产品类型路由

根据商业模式、技术架构、交付形态三个维度判断产品类型：

1.1 按商业模式分类

| 产品类型 | 核心特征 | 典型场景 | 商业模式 | 毛利率区间 | 典型公司 | |----------|----------|----------|----------|------------|----------| | AI SaaS | 云端部署、多租户、按订阅收费 | 智能客服SaaS、AI写作助手、AI数据分析平台 | MRR/ARR订阅制 | 70-85% | Jasper、Copy.ai | | 嵌入式AI | 集成到现有产品、增强核心功能 | ERP智能推荐、手机相册AI修图、IDE代码补全 | 功能增值/溢价 | 40-60% | GitHub Copilot | | AI平台 | 提供基础能力供开发者调用 | 百度文心、阿里通义、字节豆包 | API调用量计费 | 60-75% | OpenAI、Anthropic | | AI硬件 | 端侧推理、专用芯片 | AI手机、AI PC、智能摄像头、机器人 | 硬件销售+服务 | 20-40% | Rabbit、Humane | | 大模型应用 | 基于LLM构建的垂直应用 | AI搜索、AI Agent、AI Copilot | 订阅/按量 | 65-80% | Perplexity、Character.AI | | Agent产品 | 自主规划执行、多工具协作 | AI自动化办公、AI研究助手、具身智能 | 订阅/成果付费 | 50-70% | AutoGPT、Mika |

1.2 按技术架构分类

| 架构类型 | 延迟特性 | 成本特性 | 数据隐私 | 适用场景 | |----------|----------|----------|----------|----------| | 纯云端 | P50<1s, P99<5s | 按调用量计费 | 数据需脱敏 | 通用场景、实时交互 | | 云端+端侧混合 | 端<100ms, 云<2s | 边缘+云组合 | 部分本地处理 | 移动端、隐私敏感 | | 纯端侧 | <50ms | 一次性模型成本 | 完全本地 | 离线场景、高隐私 | | 边缘节点 | <500ms | 部署成本高 | 数据不出域 | 企业场景、特定区域 |

1.3 按交付形态分类

| 交付形态 | 用户触达 | 集成复杂度 | 典型产品 | 更新频率 | |----------|----------|------------|----------|----------| | Web应用 | 直接访问 | 低 | AI聊天助手 | 实时 | | 移动App | 应用商店 | 中 | AI相机、AI写作App | 1-4周 | | 桌面客户端 | 下载安装 | 中 | AI IDE、AI设计工具 | 2-4周 | | 浏览器插件 | 插件市场 | 低 | AI阅读助手、写作插件 | 1-2周 | | API/SDK | 开发者集成 | 高 | AI平台服务 | 按版本 | | 硬件设备 | 实物交付 | 高 | AI音箱、AI眼镜 | 3-6月 |

1.4 路由决策树

---

二、AI产品发现框架

2.1 三维评估模型

技术可行性 × 市场需求 × 数据可获性

2.2 技术可行性评估

| 维度 | 评估要点 | 判断标准 | 评估方法 | 权重 | |------|----------|----------|----------|------| | 模型能力 | 现有模型能否达到产品最低要求 | 参考MMLU、HumanEval等基准测试 | 对比基准测试 | 25% | | 延迟要求 | 用户能接受的最大响应时间 | 交互式<2s、分析型<30s、异步无限制 | 用户调研+竞品分析 | 20% | | 成本结构 | 单次调用成本 vs 用户付费意愿 | CAC < LTV的30% | Unit Economics建模 | 25% | | 基础设施 | 算力、存储、网络能否支撑 | P99延迟、可用性>99.9% | 架构评审 | 15% | | 迭代速度 | 技术演进是否会影响产品定位 | 18个月内技术是否会有代际突破 | 技术雷达追踪 | 15% |

2.3 市场需求评估

| 维度 | 评估要点 | 判断标准 | 数据来源 | 优先级 | |------|----------|----------|----------|--------| | 痛点强度 | 用户当前如何解决这个问题 | 现有方案是否有明显缺陷 | 用户访谈 | P0 | | 使用频率 | 用户多久遇到一次这个场景 | 高频>3次/周、低频<1次/月 | 行为数据分析 | P0 | | 付费意愿 | 用户愿意为这个功能付多少钱 | 参考同类产品定价 | 定价调研 | P0 | | 市场空间 | TAM/SAM/SOM分别是多少 | SOM > $10M/年 | 市场规模估算 | P1 | | 竞争格局 | 现有解决方案的优劣势 | 能否找到差异化切入点 | 竞品分析 | P1 |

2.4 数据可获性评估

| 维度 | 评估要点 | 判断标准 | 合规要求 | 风险等级 | |------|----------|----------|----------|----------| | 训练数据 | 能否获取足够的高质量训练数据 | 公开数据/自有数据/合成数据 | 版权合规 | 高 | | 实时数据 | 产品是否需要实时/近实时数据 | 数据源稳定性、更新频率 | API稳定性 | 中 | | 用户数据 | 能否通过产品积累数据壁垒 | 数据飞轮效应 | 隐私合规 | 高 | | 合规风险 | 数据获取和使用是否合规 | GDPR/CCPA/个保法 | 法律评估 | 极高 |

2.5 三维评分矩阵

2.6 产品机会评估代码模板

---

三、大模型应用设计

3.1 决策树总览

3.2 Prompt工程决策矩阵

| 场景 | 策略 | 关键技巧 | 示例模板 | 复杂度 | |------|------|----------|----------|--------| | 通用对话 | 结构化Prompt | System Role + Context + Format约束 | 见3.2.1 | 低 | | 角色扮演 | 人格设定 | 性格特征 + 行为准则 + 边界 | 见3.2.2 | 中 | | 任务执行 | 思维链(CoT) | Zero-shot CoT / Few-shot CoT | 见3.2.3 | 中 | | 精确输出 | 输出格式控制 | JSON Schema / 正则约束 | 见3.2.4 | 中 | | 多轮对话 | 上下文管理 | 摘要压缩 / 滑动窗口 | 见3.2.5 | 高 |

3.2.1 结构化Prompt模板

3.2.2 角色扮演Prompt模板

3.2.3 思维链(CoT)Prompt模板

3.2.4 JSON输出控制Prompt

json {schema_str} json\n{json.dumps(ex, ensure_ascii=False, indent=2)}\n

3.3 RAG设计决策

3.3.1 RAG系统实现代码

3.4 Agent设计决策

| 组件 | 选项 | 适用场景 | 复杂度 | 性能 | |------|------|----------|--------|------| | 规划能力 | ReAct | 简单到中等复杂任务 | 低 | 中 | | 规划能力 | CoT | 需要详细推理 | 低 | 高 | | 规划能力 | AutoGPT | 复杂长程任务 | 高 | 不稳定 | | 工具调用 | Function Calling | 结构化输出需求 | 中 | 高 | | 工具调用 | Tool Use | 通用工具接入 | 中 | 中 | | 记忆系统 | 短期记忆(上下文) | 单轮交互 | 低 | - | | 记忆系统 | 长期记忆(向量库) | 多轮跨会话 | 中 | 中 | | 记忆系统 | 混合记忆 | 复杂场景 | 高 | 高 | | 知识管理 | 向量库 | 通用知识检索 | 低 | 中 | | 知识管理 | 知识图谱 | 结构化关系知识 | 高 | 高 | | 多Agent协作 | 层级式 | 明确分工场景 | 中 | 高 | | 多Agent协作 | 平等协作 | 开放性问题 | 高 | 不稳定 |

3.4.1 Agent系统实现代码

3.5 微调决策矩阵

| 场景 | 推荐方案 | 成本 | 效果 | 训练时间 | 适用数据量 | |------|----------|------|------|----------|------------| | 风格调整 | LoRA | 低 | 中 | 1-2小时 | 1K-10K | | 领域适应 | QLoRA | 中 | 高 | 4-8小时 | 10K-50K | | 任务专精 | 全量微调 | 高 | 最高 | 1-3天 | 50K+ | | 实时更新 | PEFT+持续预训练 | 中高 | 高 | 持续 | 增量数据 |

3.5.1 LoRA微调配置模板

---

四、AI产品指标体系

4.1 核心指标分类

4.2 分场景指标重点

| 产品类型 | 核心北极星指标 | 测量方法 | 目标值 | 辅助指标 | |----------|----------------|----------|--------|----------| | AI SaaS | MRR, NRR, 用户留存 | 订阅收入统计 | MRR增长>10%/月, NRR>110% | 功能使用率, 付费转化率 | | AI Copilot | 任务完成率, 用户效率提升 | A/B测试对比 | 任务完成率>85% | 拦截率, 使用频率 | | AI搜索 | 答案准确率, 用户满意度 | 人工评估+用户反馈 | 准确率>90% | 点击率, 返回空率 | | AI Agent | 任务成功率, 步数效率 | 日志分析 | 成功率>80% | 工具调用准确率 | | AI硬件 | NPS, 复购率 | 用户调研 | NPS>50 | 推理延迟, 功耗 |

4.3 指标定义与计算代码

4.4 指标定义模板

---

五、AI伦理与合规

5.1 合规框架总览

5.2 公平性检查清单

| 检查项 | 具体内容 | 检测方法 | 自动化程度 | 通过标准 | |--------|----------|----------|------------|----------| | 训练数据平衡 | 各群体样本量是否均衡 | 分布统计 | 高 | 各群体样本差异<20% | | 敏感属性关联 | 模型输出是否与敏感属性相关 | 相关性分析 | 中 | 相关系数<0.1 | | 群体性能差异 | 不同群体准确率差异是否可接受 | 分组评估 | 高 | 准确率差异<5% | | 历史偏见继承 | 是否继承数据中的历史偏见 | 偏见溯源 | 中 | 无显著历史偏见 | | 偏见缓解措施 | 是否采用去偏技术 | 对比测试 | 低 | 缓解后偏见显著降低 |

5.3 透明度要求

| 场景 | 必须披露 | 推荐披露 | 披露方式 | 更新频率 | |------|----------|----------|----------|----------| | 面向消费者 | AI生成内容标识、模型基本信息 | 置信度、局限性 | 界面提示 | 实时 | | 决策辅助 | 决策依据、人工复核渠道 | 替代方案说明 | 文档+界面 | 版本更新 | | 高风险场景 | 完整的影响评估报告 | 第三方审计报告 | 官网发布 | 年度 | | 特殊群体 | 无障碍设计考虑 | 辅助功能说明 | 专门页面 | 季度 |

5.4 隐私合规检查代码

5.5 隐私合规检查清单

---

六、2026年AI产品趋势

6.1 AI Agent爆发

6.2 MCP协议生态

| 组件 | 功能 | 现状 | 主要玩家 | 成熟度 | |------|------|------|----------|--------| | MCP Server | 提供工具/资源/提示 | 快速扩展中 | Cursor, Claude Desktop | 中 | | MCP Client | LLM连接外部工具 | 主流框架支持 | Anthropic, 所有兼容LLM | 高 | | MCP Protocol | 标准化通信协议 | 1.0已发布 | Anthropic主导 | 高 | | MCP Registry | 工具市场/发现 | 早期阶段 | 建设中 | 低 |

6.3 多模态融合

6.4 端侧AI加速

| 场景 | 端侧优势 | 关键技术 | 代表产品 | 成熟度 | |------|----------|----------|----------|--------| | AI手机 | 低延迟、离线可用、隐私保护 | NPU优化、模型量化 | iPhone 16, Galaxy S24 | 高 | | AI PC | 本地Copilot、长续航 | 异构计算、专用AI芯片 | 各大厂商AI PC | 中 | | 智能汽车 | 实时感知、安全决策 | 车端大模型、OTA升级 | 特斯拉FSD, 华为ADS | 高 | | IoT设备 | 边缘推理、低功耗 | 模型压缩、TinyML | 智能家居、工业IoT | 中 |

6.5 AI原生产品形态

---

七、质量门控清单

P0级 - 阻断性问题(上线前必须解决)

| 检查项 | 标准 | 验证方法 | 负责角色 | |--------|------|----------|----------| | 功能正确性 | 核心功能可正常使用 | 功能测试 | QA | | 功能正确性 | 输出结果符合预期 | 验收测试 | PM | | 功能正确性 | 边界case有合理处理 | 边界测试 | 开发 | | 安全性 | 内容安全过滤正常 | 安全测试 | 安全团队 | | 安全性 | 无敏感信息泄露 | 渗透测试 | 安全团队 | | 安全性 | 防护机制有效(防越狱) | 红队测试 | 安全团队 | | 安全性 | 权限控制正确 | 权限测试 | 开发 | | 合规性 | 满足监管要求 | 法务评审 | 法务 | | 合规性 | 用户协议完备 | 法律审查 | 法务 | | 合规性 | 隐私政策合规 | 隐私评估 | DPO | | 稳定性 | SLA >= 99.5% | 压测验证 | SRE | | 稳定性 | P99延迟可接受 | 性能测试 | 开发 | | 稳定性 | 无级联故障风险 | 故障演练 | SRE |

P1级 - 重要问题(上线前应解决)

| 检查项 | 标准 | 验证方法 | 负责角色 | |--------|------|----------|----------| | 产品体验 | 核心路径转化率达标 | 数据分析 | 产品 | | 产品体验 | 用户满意度 >= 4.0/5.0 | 用户调研 | 产品 | | 产品体验 | 帮助文档完备 | 文档评审 | 文档 | | 产品体验 | 错误提示友好 | UX评审 | UX | | 性能优化 | TTFT < 3s | 性能测试 | 开发 | | 性能优化 | 推理成本可控 | 成本分析 | 产品 | | 性能优化 | 资源利用率合理 | 监控分析 | SRE | | 性能优化 | 有降级预案 | 预案评审 | SRE | | 可观测性 | 核心指标可监控 | 监控验证 | SRE | | 可观测性 | 告警规则完备 | 告警测试 | SRE | | 可观测性 | 日志链路完整 | 日志审查 | 开发 | | 可观测性 | 异常可追溯 | 链路追踪 | 开发 | | 运维能力 | 配置可热更新 | 变更测试 | 运维 | | 运维能力 | 模型可灰度切换 | 灰度验证 | 运维 | | 运维能力 | 故障可快速回滚 | 回滚演练 | 运维 |

P2级 - 改进项(上线后持续优化)

| 检查项 | 优化方向 | 负责角色 | 优先级 | |--------|----------|----------|--------| | 效率提升 | 模型推理优化 | 开发 | P2 | | 效率提升 | 成本结构优化 | 产品 | P1 | | 效率提升 | 工程效能提升 | 开发 | P2 | | 效率提升 | 技术债务清理 | 开发 | P3 | | 体验优化 | 交互细节打磨 | UX | P2 | | 体验优化 | 性能体验优化 | 开发 | P1 | | 体验优化 | 个性化能力 | 产品 | P2 | | 体验优化 | 多端一致性 | 开发 | P2 | | 能力扩展 | 新功能开发 | 产品 | P1 | | 能力扩展 | 场景覆盖扩展 | 产品 | P2 | | 能力扩展 | 集成能力增强 | 开发 | P2 | | 能力扩展 | 生态对接 | 产品 | P2 | | 数据驱动 | 指标体系完善 | 产品 | P1 | | 数据驱动 | A/B测试能力 | 开发 | P2 | | 数据驱动 | 数据分析深度 | 分析 | P2 | | 数据驱动 | 实验迭代效率 | 分析 | P2 |

---

八、常见错误模式

错误1: 技术可行≠产品可行

表现: 团队攻克了技术难题，却发现没有用户愿意为此付费。

原因: 跳过市场验证，直接进入产品开发。

正确做法:

• 先做用户访谈(MVVP阶段)
• 验证付费意愿而非技术能力
• 小样本验证后再投入资源

错误2: 把LLM当数据库用

表现: 要求LLM精确回忆事实，导致幻觉率居高不下。

原因: 混淆了LLM的"知识"和"推理"能力。

正确做法:

• RAG做知识检索
• LLM做推理生成
• 知识与推理解耦

错误3: 忽视推理成本

表现: 产品上线后才发现Token成本远高于用户付费意愿。

原因: 早期未建立成本模型。

正确做法:

• 产品设计阶段建立Unit Economics模型
• 设计成本可控的交互模式
• 预留成本优化技术路径

错误4: 过度工程化

表现: 使用RAG+Agent+微调解决一个简单问答场景。

原因: 技术选型未回归产品需求。

正确做法:

• 先用最简单的方案验证需求
• 根据效果决定是否升级复杂度
• 保持技术选型与产品价值的匹配

错误5: 忽视数据飞轮

表现: 产品上线后没有机制积累数据壁垒。

原因: 只关注PMF，忽视MLF(Product Model Fit)。

正确做法:

• 产品设计中嵌入数据收集机制
• 设计数据驱动的迭代闭环
• 规划数据资产变现路径

错误6: 伦理合规事后补救

表现: 产品上线后因合规问题被迫重构。

原因: 将伦理合规视为成本而非竞争力。

正确做法:

• 从产品设计阶段嵌入伦理考量
• 建立合规检查清单
• 将合规能力作为产品差异化

错误7: 指标与业务脱节

表现: 追求模型准确率，忽视用户实际任务完成率。

原因: 技术指标≠产品指标。

正确做法:

• 建立"模型指标→产品指标→业务指标"的映射
• 关注最终业务outcome
• 技术指标服务于产品指标

错误8: 忽视用户心智

表现: 产品功能强大，但用户不会用、不愿用。

原因: 只关注功能实现，忽视用户认知。

正确做法:

• 保持产品心智清晰
• 渐进式引导用户
• 提供足够的"AI素养"教育

错误9: 过度依赖供应商

表现: 产品因上游API涨价或服务中断而陷入危机。

原因: 未建立多供应商策略。

正确做法:

• 核心能力保持多供应商
• 评估供应商锁定风险
• 规划自主可控路径

错误10: 迭代节奏失控

表现: 产品发布后一周年，发现核心指标没有改善。

原因: 缺乏数据驱动的迭代机制。

正确做法:

• 建立weekly metrics review
• 设定明确的迭代OKR
• 保持2-4周的快速验证周期

---

九、使用指南

触发场景

当用户提到以下意图时使用此技能：

• AI产品规划/设计/策略
• 大模型应用设计
• AI产品指标体系
• AI伦理合规
• Prompt工程/RAG/Agent设计
• AI产品趋势分析

使用方式

1. 根据用户问题，识别对应的决策框架
2. 提供结构化的决策建议
3. 结合具体场景给出可落地的方案
4. 标注关键风险点和注意事项

输出原则

• 简洁专业，直击要点
• 提供决策树/矩阵等结构化工具
• 结合最新行业实践
• 平衡理想与现实