0框架
AI 产品经理系统性知识图谱 v2（修订版）
设计原则： 从”按知识领域分类”转向”按PM决策场景分类”。每个模块的存在理由是回答一个具体的产品决策问题，而非覆盖一个学术知识域。
与v1的核心差异：
- 技术底层模块大幅瘦身，只保留直接影响产品决策的技术认知
- 工程化与产品设计按场景重组，不再人为割裂
- 新增”度量与实验”独立模块（v1最大盲区）
- 新增”竞品拆解方法论”模块（从观察者到牌桌玩家的跳板）
- 新增跨模块”决策耦合层”，处理真实产品决策的多维度博弈
- 新增”AI PM工作操作系统”（工作方式，非知识储备）
模块架构总览
┌─────────────────────────────────────────────────────────┐
│ 跨模块决策耦合层 (Cross-Module Layer) │
│ 真实产品决策 = 技术约束 × 体验影响 × 成本结构 × 合规风险 │
└───────┬──────┬──────┬──────┬──────┬──────┬───────────────┘
│ │ │ │ │ │
┌────┴┐ ┌──┴──┐ ┌─┴──┐ ┌┴───┐ ┌┴───┐ ┌┴────┐
│ M0 │ │ M1 │ │ M2 │ │ M3 │ │ M4 │ │ M5 │
│技术 │ │产品 │ │度量 │ │商业 │ │竞品 │ │风险 │
│素养 │ │架构 │ │实验 │ │战略 │ │拆解 │ │合规 │
└─────┘ └─────┘ └────┘ └────┘ └────┘ └─────┘
┌─────────────────────────────────────────────┐
│ 底座：AI PM 工作操作系统 (Operating System) │
│ PRD写法 / 协作语言 / AB实验 / 日常节奏 │
└─────────────────────────────────────────────┘模块 0：AI 技术素养（Technology Literacy）
定位
回答的核心问题： 这个需求在物理上能不能做？成本量级是什么？
这不是一个”学到精通”的模块，而是一个”建立判断直觉”的模块。目标是让你在听到技术团队说”这个做不了”或”这个很简单”时，能判断对方是在说事实还是在推诿/低估。
与v1的差异
v1的模块一深度过剩（KV Cache的字节级推演、Softmax概率插值的数学本质、PRM的树搜索机制）。这些内容对AI PM的日常决策帮助有限，但消耗大量学习时间。v2只保留直接影响产品决策的技术认知，其余降级为”知道存在、能听懂术语”即可。
子章节
0.1 概率思维基础（保留，但压缩）
- 核心认知跃迁：从确定性系统到概率分布系统
- “过拟合”和”欠拟合”的产品体验映射（保留，这是直接影响需求定义的）
- 幻觉的不可消除性（保留结论和产品含义，砍掉Softmax数学推导）
- 砍掉的内容： 监督/无监督学习的学术分类、分类vs回归的抽象定义——这些对产品决策没有直接帮助
0.2 算力约束与成本直觉（保留核心，砍掉推演细节）
- Prefill vs Decode的本质差异 → 直接映射为：输入Token贵还是输出Token贵？长Prompt的成本后果是什么？
- KV Cache → 直接映射为：上下文窗口越长，并发越低，成本越高。产品要不要支持100K上下文，这是一个成本决策
- TTFT vs TPOT → 直接映射为：用户等首字的时间和看到内容流出的速度，分别受什么约束
- 砍掉的内容： 显存带宽的具体数值计算、PagedAttention的实现原理、Speculative Decoding的验证机制——知道存在即可
0.3 架构选型的产品含义（保留对比表，砍掉原理细节）
- Dense Transformer / MoE / SSM 的产品适用场景对比（保留）
- 每种架构的成本-延迟-能力 trade-off（保留）
- 砍掉的内容： 注意力机制的数学公式、MoE路由机制的工程细节、SSM隐状态向量的物理意义
0.4 多模态与端侧（保留趋势判断，砍掉生成机制差异）
- 原生多模态 vs 管线串联对延迟的影响（保留，直接影响语音产品设计）
- 端侧部署的可行性边界（保留，影响产品架构选型）
- 砍掉的内容： 自回归vs扩散模型的数学差异、VLM导航的技术细节
0.5 后训练与数据墙（保留战略含义，压缩技术细节）
- 核心判断：基础模型趋同，后训练（SFT/RLHF）是产品差异化的主战场
- PM能插手的环节：SFT的场景定义、偏好数据的采集设计、评估标准的制定
- 合成数据的战略意义（保留概念，砍掉具体Pipeline设计——那是工程师的活）
- 砍掉的内容： PPO/GRPO算法细节、Constitutional AI的技术实现、DPO的数学公式
扩展Prompt设计（v2修订）
你是一位有丰富产品合作经验的AI技术负责人。我是一个正在转型AI领域的产品经理，
有3年互联网PM经验但没有AI实战经验。
请帮我建立"AI技术素养"——不是让我成为半个工程师，而是让我具备以下能力：
1. 听到技术方案时，能判断其成本量级和可行性边界
2. 写PRD时，能预判技术约束对产品体验的影响
3. 和算法工程师讨论时，能用对方听得懂的语言描述产品需求
对于每个知识点，请用这个格式：
- 【一句话本质】用一句话说清楚这个概念的核心
- 【产品决策影响】这个技术事实会在什么产品决策场景中出现
- 【判断直觉】当工程师提到这个概念时，我应该追问什么问题
- 【不需要深入的部分】哪些细节可以留给工程师，PM知道存在即可
拒绝任何与产品决策无关的纯技术深挖。如果某个概念对PM决策没有直接影响，
请直接标注"了解术语即可"并跳过。模块 1：AI 产品架构决策（Product Architecture Decisions）
定位
回答的核心问题： 面对这个业务需求，技术上应该怎么做（Prompt Engineering / RAG / 微调 / Agent），产品上应该怎么设计交互？
这是v1的模块二（工程化）和模块三（产品设计）按决策场景重组后的结果。核心改动：不再把”RAG的技术链路”和”RAG产品的交互设计”分开讲，而是作为一个完整的决策单元。
子章节
1.1 技术选型决策矩阵
PM面对一个需求时的第一个决策：用什么技术路径实现？
| 决策维度 | Prompt Engineering | RAG | 微调 (SFT/LoRA) | Agent |
|---|---|---|---|---|
| 知识更新频率 | 静态或低频 | 高频/实时 | 低频（重新训练成本高） | 依赖外部工具实时获取 |
| 领域专业深度 | 通用知识足够 | 需要垂直知识库 | 需要改变模型行为模式 | 需要多步骤复杂任务 |
| 数据安全要求 | 低（数据过API） | 中（知识库可私有化） | 高（数据不出域） | 视工具链而定 |
| 成本结构 | 最低 | 中（向量DB+检索） | 高（训练+部署） | 最高（多次调用） |
| 延迟容忍度 | 最低延迟 | 中（检索+生成） | 低延迟 | 高延迟（多步骤） |
| 上线速度 | 小时级 | 周级 | 月级 | 周-月级 |
| 典型场景 | 客服话术、格式化输出 | 企业知识问答、法律检索 | 垂直领域专家、风格定制 | 自动化工作流、数据分析 |
决策不是非此即彼的： 成熟的AI产品几乎都是组合方案。例如：RAG + Prompt Engineering（检索后用精细Prompt控制输出格式），或 微调 + RAG（用微调建立领域语感，用RAG注入实时知识）。
1.2 RAG 产品的完整决策链（技术+产品一体化）
不再把RAG拆成”技术链路”和”产品体验”两个模块，而是按决策顺序一路打通：
- 分块策略选择 → 直接决定用户看到的答案粒度和准确度
- 选择依据：文档类型、用户查询模式、答案长度预期
- PM需要判断的：粒度太细答案碎片化，太粗检索命中率低——这是产品决策不是纯技术决策
- 检索架构选择（稀疏/稠密/混合） → 直接决定什么类型的问题能被回答
- 专有名词多的场景（法律条文、产品型号）必须保留关键词检索
- 用户表达模糊的场景必须依赖语义检索
- PM需要判断的：目标用户的提问模式是精确的还是模糊的？
- 重排序（Reranker） → 决定用户看到的第一个答案是不是最相关的
- 这是RAG产品体验的生死线，但常被工程团队低估
- 引用溯源与可信度展示（产品层） → 用户凭什么信任AI给出的答案？
- 引用标注设计、来源链接、置信度信号
- 检索失败时的降级策略：承认”我没找到相关信息” vs 硬答（体验与信任的trade-off）
- 反馈闭环设计（产品层） → 如何用用户行为数据持续优化检索质量？
- 用户点击了哪个引用来源、是否触发了”重新搜索”、答案被复制还是被忽略
1.3 Agent 架构的产品化决策
Agent不是一个技术方案，而是一种产品形态选择。PM需要决策的核心问题：
- 自主性边界： 这个Agent在什么范围内可以自主行动，什么时候必须请求用户确认？
- 低风险操作（信息查询）→ 自动执行
- 中风险操作（发送邮件）→ 生成草稿，用户确认后执行
- 高风险操作（资金操作）→ 只能提供建议，不能执行
- 失败模式设计（最容易被忽视的部分）：
- 工具调用失败 → 重试策略 + 降级方案 + 用户通知
- 规划错误（走错路径）→ 如何让用户纠正而不需要从头开始
- 长时间执行 → 进度展示、中途取消、部分结果保存
- 多Agent协同的产品逻辑：
- 角色分工设计（Planner / Executor / Reviewer）
- 对用户的呈现方式：透明展示协作过程 vs 只展示最终结果
- 类比：这是组织架构设计，不是纯技术问题
1.4 交互范式的场景化选择
不再笼统地讲”对话式 vs 非对话式”，而是按场景给出交互形态选择：
| 场景特征 | 最佳交互形态 | 案例 |
|---|---|---|
| 用户意图明确，需要精确执行 | 行内补全 / 命令式 | GitHub Copilot Tab键采纳、Notion AI的”/“命令 |
| 用户意图模糊，需要探索 | 对话式 + 引导 | ChatGPT、Perplexity |
| 高频重复任务 | 自动化工作流 + 审批节点 | Zapier AI、企业RPA |
| 创意生成，需要迭代 | 画布式 + 变体选择 | Midjourney V变体、Figma AI |
| 长文档处理 | 侧边栏 + 行内标注 | Cursor、Google Docs AI |
| 实时辅助（无屏幕） | 语音 + 触觉反馈 | 穿戴设备、车载AI |
1.5 防御性UX设计清单
针对AI产品的两个固有缺陷（非确定性 + 高延迟），提供可直接落地的设计清单：
- 延迟管理： 流式输出、骨架屏、“AI正在查阅资料…”状态外显、进度预估
- 幻觉管理： 置信度标识、引用来源、“此回答可能不准确”提示的触发条件设计
- 纠错交互： 局部重新生成、分段确认、用户编辑后的模型学习
- 降级策略： 模型超时→缓存回答、模型拒答→转人工、检索失败→承认+建议替代查询
扩展Prompt设计（v2修订）
你是一位同时精通AI工程和产品设计的首席产品架构师，主导过多个千万DAU的AI产品。
请帮我建立"AI产品架构决策"能力。
核心要求：
1. 对于每个技术选型（RAG/微调/Agent），不要把技术实现和产品设计分开讲。
请按"决策链"的顺序：业务需求→技术选型→实现约束→交互设计→度量方式，一路打通。
2. 用一个具体的商业场景（如"出海企业的多语言客服系统"）作为贯穿线索，
推演从0到1的完整产品架构决策过程。在每个决策节点，指出：
- PM需要做什么判断
- 需要向工程师问什么问题
- 这个决策会如何影响后续的成本、体验和可扩展性
3. 特别展开Agent的失败模式设计。大部分AI产品教程只讲Agent怎么work，
请重点讲Agent怎么fail，以及PM该如何设计兜底机制。
4. 提供一份"AI产品防御性UX设计清单"，可直接作为PRD附件使用。模块 2：AI 产品度量与实验（Metrics & Experimentation）
定位
回答的核心问题： 这个AI功能上线后，怎么知道它是好是坏？怎么持续改进？
这是v1完全缺失的模块，也是AI PM日常工作中占比最高的活动之一。
为什么需要独立模块
AI产品的度量和传统互联网产品有三个根本性差异：
- 非确定性输出： 同一个输入，模型可能给出不同输出。你无法像传统产品那样用”功能是否正常工作”来衡量
- 双轨指标体系： 必须同时追踪模型性能指标和业务指标，且两者的关系是非线性的（幻觉率从5%→3%可能业务指标没变化，从3%→1%可能带来跃升）
- 数据飞轮效应： 产品的度量数据本身就是模型改进的训练数据，度量设计和模型迭代是一个闭环
子章节
2.1 AI 产品核心指标体系
模型性能指标（技术侧）：
- 任务完成率 (Task Completion Rate)：用户的请求是否被正确执行
- 幻觉率 → 映射为”人工接管率 (Human Takeover Rate)”
- 首字延迟 (TTFT) 和生成速度 (TPOT)
- 检索命中率 (Hit Rate) 和排序质量 (MRR)（RAG产品专用）
业务体验指标（产品侧）：
- 采纳率 (Acceptance Rate)：用户是否使用了AI生成的结果
- 编辑距离 (Edit Distance)：用户在AI输出基础上做了多少修改
- 重试率 (Retry Rate)：用户触发”重新生成”的频率
- 会话深度 (Session Depth)：用户和AI交互了几轮才完成任务
- 逃逸率 (Escape Rate)：用户在AI功能中放弃，转向手动完成的比例
商业结果指标（业务侧）：
- 效率提升量化：使用AI前后完成同一任务的时间对比
- 成本相关：单次交互的算力成本 (COGS per interaction)、LTV/CAC
- 留存与付费转化
2.2 指标间的因果链与阈值效应
- 不是所有模型性能提升都会转化为业务指标改善
- 阈值效应：某些场景下，准确率必须跨过一个门槛（如95%）才会引发用户行为变化
- 感知质量 vs 实际质量的分离（和你滴滴案例的”感知安全 ≠ 实际安全”是同构问题）
- 如何建立”模型指标→产品指标→业务指标”的归因链条
2.3 AI 产品的AB实验设计
- 传统AB实验的假设（确定性输出、独立样本）在AI产品中不完全成立
- 模型版本切换的实验设计：如何控制变量（Prompt变化 vs 模型变化 vs 检索策略变化）
- 长尾case的处理：AI产品的问题往往集中在少数极端场景，均值指标可能掩盖严重问题
- “好的AI”的定义是场景依赖的：同一个模型输出，在创意场景是优点（发散），在合规场景是灾难（不精确）
2.4 数据飞轮的工程设计
- 隐式反馈采集：采纳/拒绝、编辑修改、停留时长、复制行为
- 显式反馈采集：点赞/点踩的交互设计、重新生成的触发机制
- 反馈数据→训练数据的转化管道：如何把前端交互数据清洗为可用于SFT/RLHF的标注数据
- 冷启动期的数据策略：没有用户反馈数据时怎么办（合成数据 + 人工标注 + 内部dogfooding）
2.5 评估体系搭建实操
- 离线评估 vs 在线评估的分工
- LLM-as-a-Judge的搭建逻辑与已知偏见（位置偏见、冗长偏见）
- 人工评估的标注指南设计（标注一致性 > 标注量）
- 回归测试：模型升级后如何确保旧场景不退化
扩展Prompt设计
你是一位在头部AI公司（如字节跳动/Anthropic）主导过AI产品度量体系搭建的
数据驱动型产品负责人。请帮我建立"AI产品度量与实验"能力。
核心要求：
1. 给出一套完整的AI产品指标体系框架，分为模型性能层、产品体验层和商业结果层。
对每个指标，说明：定义、采集方式、适用场景、常见陷阱。
2. 用一个具体案例（如"企业级RAG知识库问答产品"），推演从上线到迭代优化的完整度量流程。
重点说明：模型准确率提升X%时，业务指标可能的非线性响应模式。
3. 设计一个AI产品的AB实验方案模板，包括：假设、变量控制、样本量估算、
评估指标选择、长尾case专项评估。
4. 深度拆解数据飞轮：如何在产品交互的微观层面设计反馈采集机制，
使其既不打扰用户，又能产出高质量训练数据。
对比ChatGPT的点赞、Copilot的Tab采纳、Midjourney的V变体这三种机制的数据哲学。
5. 提供一份"AI产品评估体系搭建清单"，可直接指导工程团队实施。模块 3：AI 商业战略与生态（Business Strategy & Ecosystem）
定位
回答的核心问题： 这个AI产品的钱从哪来？护城河在哪？能活多久？
与v1的差异
v1的商业模块覆盖面够了，但缺少两个关键能力：一是把商业分析和技术约束联动起来的能力（比如：定价策略必须考虑算力成本结构），二是对中国AI市场特殊竞争格局的分析框架。
子章节
3.1 AI 产业链价值分布与生态位选择
- 算力层 → 模型层 → 中间件层 → 应用层的价值分配
- 应用层的利润池在哪？为什么大部分应用层公司赚不到钱？
- 中国AI市场特殊性：平台依赖（蚂蚁/腾讯/百度生态）、被收购作为现实退出路径
3.2 “套壳”诊断与护城河构建
-
五维度自检框架：
- 模型替换成本： 如果底层模型换了，产品价值保留多少？
- 数据壁垒： 产品是否在积累用户使用中独有的数据资产？
- 工作流嵌入深度： 用户切换到竞品的迁移成本有多高？
- 网络效应： 更多用户是否让产品对每个用户都更好用？
- 领域know-how： 产品团队是否积累了难以复制的行业理解？
-
护城河构建策略：
- 垂直行业系统记录(SoR)锁定
- 数据飞轮：用户使用→专有数据→模型变强→用户更多
- 工作流深度集成（从”AI工具”到”AI基础设施”）
3.3 商业模式与单位经济模型
- Token计费 vs 订阅制 vs 按结果计费 vs 按座席计费
- AI时代按座席定价的崩溃逻辑（AI减少人头→座席收入下降）
- UE拆解模板：CAC / COGS per interaction / LTV / Gross Margin
- 算力成本对定价策略的硬约束（不是”想定多少就多少”）
3.4 企业级 vs 消费级的战略分化
- ToB：私有化部署溢价、合规信任壁垒、销售周期长但LTV高
- ToC：获客成本博弈、留存是生死线、免费层的算力成本控制
- 当前阶段的PMF判断：为什么低容错创意工具比高精度垂直工具更容易找到PMF
3.5 开源 vs 闭源的战略推演
扩展Prompt设计
你是一位投资过多个AI独角兽、深度参与中国AI创业生态的风险投资人和战略顾问。
请帮我建立"AI商业战略"分析能力。
核心要求：
1. 用"套壳诊断五维度框架"分析3个真实AI产品（1个已死/1个挣扎/1个成功），
推演其护城河强弱的具体原因。
2. 设计一个AI产品的单位经济模型(UE)计算模板。
用"AI自动化客服"和"AI写作助手"两个场景，分别推演其成本结构和盈利路径。
特别要把算力成本（Token消耗）纳入COGS计算。
3. 针对中国AI应用层市场，分析以下竞争格局：
- 平台依赖型公司（蚂蚁/腾讯/百度生态内）的生存策略
- 独立创业公司的差异化路径
- 被收购 vs 独立上市的退出路径选择
4. 推演"按结果定价"(Outcome-based Pricing)在3个具体场景中的可行性，
包括定价逻辑、价值归因难点和用户接受度。模块 4：竞品拆解与行业分析方法论（Competitive Intelligence）
定位
回答的核心问题： 拿到一个AI产品，如何在30分钟内形成有价值的判断？
这是v1完全缺失的模块，也是你从”观察者”转变为”牌桌玩家”的关键工具。你已经在做公司mapping，但需要一个系统化的拆解方法论来支撑这个活动。
子章节
4.1 AI 产品快速拆解框架（30分钟版）
第一层：产品定位（5分钟）
- 解决什么问题？目标用户是谁？
- 在AI产业链的哪个位置？
- 核心价值主张是什么？
第二层：技术架构反推（10分钟）
- 从交互行为反推技术方案：
- 有引用来源 → 大概率RAG
- 响应速度极快 → 可能用了缓存或小模型
- 输出格式高度一致 → 大概率有SFT或严格的Prompt Engineering
- 支持复杂多步骤任务 → Agent架构
- 从定价模型反推成本结构：
- 按Token计费 → 直接API转售，薄利
- 固定订阅制 → 需要控制单用户算力消耗
- 免费 → 靠融资续命或有其他变现方式
第三层：竞争力评估（10分钟）
- 套壳五维度快速打分（各1-5分）
- 数据飞轮是否已经转起来？
- 用户迁移成本有多高？
第四层：产品改进假设（5分钟）
- 如果我是这个产品的PM，最优先改什么？
- 这个产品最可能被什么颠覆？
4.2 行业地图构建方法论
- 如何系统性地mapping一个AI细分领域（你已经在做的事情的方法论支撑）
- 信息源：36Kr、量子位、AI产品榜单、ProductHunt、融资新闻、招聘信息
- 分类框架：按技术路线分 / 按目标用户分 / 按商业模式分
- 动态追踪：融资事件、产品更新、团队变动、竞品跟进
4.3 面试场景的竞品分析模板
-
“你怎么看XX产品？“的标准回答结构：
- 定位判断（一句话）
- 做得好的地方（具体功能+为什么好）
- 结构性问题或机会（不是吐槽细节，是指出战略层面的张力）
- 如果我来做，会怎么改（具体方案+预期效果）
-
“你为什么想来我们公司？“的深度版回答准备方法：
- 拆解目标公司产品的技术架构和竞争位置
- 找到一个你认为有改进空间的具体点
- 准备一个有深度的改进假设（不是泛泛而谈，而是能展示你的产品直觉）
扩展Prompt设计
你是一位资深AI行业分析师，曾为多家头部VC和AI公司提供竞品情报服务。
请帮我建立"AI产品竞品拆解"的系统化能力。
核心要求：
1. 给出一个可复用的"AI产品30分钟快速拆解框架"，包括：
看什么、怎么看、判断标准是什么。
用3个真实AI产品（如Perplexity、Cursor、Kimi）做示范拆解。
2. 教我"从产品交互反推技术架构"的具体方法。
例如：怎么通过使用一个AI产品10分钟，判断它用的是RAG还是微调？
怎么通过定价模型推断它的成本结构？
3. 针对中国AI应用层市场，帮我建立一个行业mapping的信息源清单和追踪节奏。
4. 提供3个"面试场景竞品分析"的完整示范回答（中文），
展示从定位判断到改进假设的完整论证链。模块 5：AI 风险、伦理与合规（Risk, Ethics & Compliance）
定位
回答的核心问题： 这个AI功能会不会让公司被罚、被骂、被起诉？
与v1的差异
v1的合规模块已经够全了，v2只做两个调整：一是增加中国特色的监管要求（深度补充《生成式人工智能服务管理暂行办法》的实操含义），二是把”安全防御”从学术化表述转为PM可直接落地到PRD的清单。
子章节
5.1 AI产品安全攻击面全景（Input → Processing → Output）
- 输入端：Prompt Injection、Jailbreak、社工攻击
- 处理端：数据投毒、模型窃取
- 输出端：幻觉导致的错误信息、有害内容生成、版权侵权
5.2 可落地到PRD的安全防御清单
- 输入过滤层：意图分类 + 敏感词拦截 + 上下文窗口隔离
- 输出审核层：内容安全分类器 + 事实核查（RAG溯源）+ 人工抽检机制
- 系统级：速率限制、异常行为检测、熔断机制
5.3 中国AI监管实操要点
- 《生成式人工智能服务管理暂行办法》的核心要求：算法备案、内容审核、数据合规
- 对产品开发周期的具体影响：备案流程、审核机制、用户协议要求
- 出海场景的双重合规：中国规定 + 目标市场规定（GDPR/CCPA）
5.4 AI Agent的责任界定（新增）
- 当自主执行的Agent造成损失，责任归谁？
- 产品设计中的责任防火墙：确认机制、审计日志、人工兜底
- 用户协议中的免责条款设计
5.5 危机应急响应（保留v1框架，增加实操性）
- 幻觉导致舆情事件的黄金24小时响应流程
- 技术熔断 → 公关回应 → 根因分析 → 修复验证 → 复盘改进
跨模块决策耦合层（Cross-Module Decision Layer）
定位
真实的产品决策从来不是单模块的。“要不要支持100K上下文”这一个问题，同时涉及技术约束（M0）、产品架构（M1）、成本结构（M3）和用户体验度量（M2）。
设计方式
提供3-5个高频决策场景，每个场景拉通所有相关模块：
决策场景1：是否支持长上下文（100K+ tokens）
- M0 视角：KV Cache显存占用、并发限制、成本倍增
- M1 视角：用户真的需要一次丢100K进去，还是RAG分段检索就够了？
- M2 视角：如何度量长上下文功能的实际使用率和价值？
- M3 视角：长上下文的算力成本如何反映到定价中？
- M5 视角：长文档中是否包含敏感信息？如何处理？
决策场景2：模型升级（如从GPT-3.5切换到GPT-4）
- M0 视角：延迟和成本的变化量级
- M1 视角：需要重新调整Prompt和RAG策略吗？
- M2 视角：如何设计AB实验验证升级效果？如何防止回归？
- M3 视角：成本上升后定价是否需要调整？
- M4 视角：竞品是否已经在用更强的模型？
决策场景3：是否构建Agent功能
- M0 视角：多次模型调用的延迟和成本累积
- M1 视角：用户任务的复杂度是否真的需要Agent，还是一个好的Prompt就够了？
- M2 视角：Agent任务的成功率如何度量？失败时用户的挫败感如何管理？
- M3 视角：Agent功能是否能支撑更高的定价？
- M5 视角：Agent自主执行操作的安全和合规边界
决策场景4：出海市场选择与本地化
- M0 视角：多语言Token效率差异（同样的内容，日语消耗的Token可能是英语的2-3倍）
- M1 视角：本地化不只是翻译，还有检索库的本地化、合规Prompt的调整
- M3 视角：目标市场的付费意愿和竞争格局
- M4 视角：目标市场的竞品生态分析
- M5 视角：目标市场的数据合规要求（数据本地化、跨境传输）
底座：AI PM 工作操作系统（Operating System）
定位
回答的核心问题： AI PM日常怎么工作？和谁协作？产出什么文档？
这不是一个知识模块，而是一个工作方式模块。知识图谱的其他模块教你”知道什么”，这个模块教你”怎么做”。
子章节
OS.1 AI PM的PRD长什么样
- 和传统PRD的区别：
- 需要包含模型选型建议和约束条件
- 需要定义”什么算好”（评估标准和验收指标）
- 需要包含失败模式和降级方案
- 需要包含数据采集方案（反馈飞轮设计）
- PRD模板（可直接使用）
OS.2 AI PM和算法工程师的协作语言
- 用什么颗粒度描述需求（不要说”让AI更聪明”，要说”把这类case的准确率从70%提到85%”）
- 什么时候该challenge工程师（“做不了”可能是”不想做”）
- 什么时候该相信工程师（物理限制是真的不能绕过的）
- 需求评审时的核心问题清单
OS.3 AI产品的迭代节奏
- 模型迭代 vs 产品迭代的节奏差异
- 数据标注 → 模型训练 → 评估 → 上线的周期管理
- 如何平衡”快速上线验证”和”模型质量保证”
OS.4 面试情景题的思维框架
- “如何从0到1设计一个XX AI产品？“的回答结构
- “这个AI功能的效果不好，你怎么排查？“的回答结构
- “用户反馈AI回答不准确，你怎么处理？“的回答结构
学习优先级建议（针对Rick的具体情况）
考虑到你的时间约束（旅行中并行准备，约2.5个月后回国求职）和知识结构（技术理解力强但缺乏AI实战经验），建议的学习顺序：
Phase 1（立即开始，旅行期间，每天1-2小时）
- 模块4：竞品拆解 — 这是最快能产生面试价值的模块。对着你已有的公司list，每天拆解一个AI产品。
- 模块2：度量与实验 — 这是你当前知识结构中最大的盲区，也是面试高频考点。
- 底座OS：工作操作系统 — 面试情景题的思维框架，可以在拆解竞品的过程中同步建立。
Phase 2（回国前2-4周，加大投入）
- 模块1：产品架构决策 — 在竞品拆解的基础上，系统化理解技术选型逻辑。
- 模块3：商业战略 — 结合目标公司的具体分析，理解其商业模式和竞争位置。
Phase 3（回国后，面试冲刺）
- 模块0：技术素养 — 查漏补缺，确保能听懂技术面试中的关键术语。
- 模块5：风险合规 — 按需补充，尤其是目标公司涉及出海或ToB业务时。
文档版本：v2.0 修订时间：2026年3月17日 修订依据：基于v1框架的六项结构性缺陷评估