AI PM 认知升级：技术边界与商业逻辑
AI PM 认知升级：技术边界与商业逻辑
AI PM 最容易犯的错，不是“不懂模型”，而是把 AI 当成一个随便接进去就会自动创造价值的 feature。现实里，绝大多数 AI product 失败，不是 demo 做不出来，而是上线后 accuracy、latency、cost 和 user expectation 一起失控。
所以这页的重点不是教你背模型名，而是帮你建立一套 business-first 的判断框架。AI PM 真正的工作，是在 capability 和 business model 之间做取舍。
先说结论：AI PM 先问 4 个问题，再谈功能
任何 AI feature 在立项前，先过这 4 关：
- 模型到底能不能稳定完成这件事
- 用户是否真的愿意把这个任务交给 AI
- 这件事的 unit economics 能不能成立
- 出错以后，产品有没有 guardrail
如果其中两项答不清，这个需求大概率还不该进 roadmap。
AI PM 不需要会训练模型，但必须懂边界
你不需要会写 Transformer 推导，也不需要会做 fine-tuning pipeline。
但下面这些概念，不懂就很容易做错决策。
| 概念 | PM 要理解到什么程度 | 为什么重要 |
|---|---|---|
| Token | 知道它影响 cost 和 context | 直接关系到毛利和响应速度 |
| Context window | 知道模型一次能吃多少信息 | 影响长文档、长对话场景 |
| Temperature | 知道它影响稳定性和发散性 | 影响 UX 和评估结果 |
| Hallucination | 知道它不是 bug，而是概率特征 | 影响产品边界和 trust |
| Model tier | 知道大模型、小模型、开源模型差异 | 决定 cost / quality tradeoff |
AI PM 的基础认知不是“技术炫耀”，而是避免做 impossible roadmap。
AI 产品最常见的 3 个误判
误判 1：demo 能跑，就代表可以商用
不成立。
demo 只证明模型偶尔能做出来，不代表它能在真实流量、真实输入和真实用户容错下稳定工作。
误判 2：回答越聪明，产品越有价值
也不成立。
很多业务场景里，用户要的不是“聪明”，而是“稳定、快、能复核”。
误判 3：先接最强模型，后面再优化成本
这在很多 startup 会直接把你带进死路。
如果 feature 从一开始就只能靠高成本模型撑住，后面很难把 unit economics 拉回来。
AI PM 的核心工作，其实是 Constraint Management
传统 PM 更多是在功能和优先级里做取舍。
AI PM 还要多管 4 类 constraint：
| Constraint | 典型问题 |
|---|---|
| capability | 模型能不能稳定做对 |
| cost | 每次调用花多少钱 |
| trust | 用户敢不敢相信结果 |
| compliance | 数据、版权、审核能不能过 |
这 4 个约束不是产品后期再补，而是需求设计当天就应该考虑。
Model Selection，不要按名气选
更实际的选法是按场景选。
| 场景 | 更适合什么模型策略 | 关键考量 |
|---|---|---|
| customer support draft | 小模型优先，大模型兜底 | cost 和 latency |
| internal knowledge Q&A | RAG + 稳定模型 | source grounding |
| long-document analysis | 大 context model | 文档长度和推理稳定性 |
| creative ideation | 发散型模型 | 多样性比精确性重要 |
| regulated workflow | 人工 review + 明确 guardrail | trust 和合规优先 |
不要问“哪个模型最好”。
要问“哪个模型在这个 use case 下最值”。
Hallucination 不是异常，是默认风险
AI PM 需要接受一个现实：只要是生成式系统，就会有 hallucination。
所以真正的问题不是“怎么完全消灭它”，而是：
- 哪些场景可以容忍
- 哪些场景绝对不能放行
- 错了以后谁来发现、谁来兜底
一个很实用的分类法：
| 风险等级 | 例子 | 产品策略 |
|---|---|---|
| Low risk | brainstorming、标题建议 | 可直接给用户看 |
| Medium risk | summary、draft、分类建议 | 给来源和 edit step |
| High risk | medical、legal、financial advice | 必须加人工复核 |
如果你没做这层分类，产品设计很容易又慢又不安全。
Unit Economics 才是 AI PM 的真基本功
很多 AI feature 一开始看起来体验很好，3 个月后被砍，原因通常不是用户不喜欢，而是成本打不住。
最少要盯这几个数字：
| 指标 | 你至少要知道什么 |
|---|---|
| input tokens / request | prompt 有没有越堆越长 |
| output tokens / request | 模型是不是说得太多 |
| avg latency | 用户是否愿意等 |
| cost per successful task | 每完成一次真实任务要花多少钱 |
| gross margin after AI cost | 功能是否值得长期投入 |
如果你只能报 DAU，报不出 cost per successful task，那这个 AI feature 其实还没被你真正管理起来。
AI PM 更应该设计 Guardrail，而不是只设计 happy path
一个能上线的 AI workflow，至少要有下面这些 guardrail：
| Guardrail | 作用 |
|---|---|
| source grounding | 让回答尽量基于可验证信息 |
| fallback answer | 模型不确定时不要硬答 |
| human review | 高风险环节有人兜底 |
| prompt / model versioning | 出问题能回滚 |
| feedback capture | 让坏回答能被标记和学习 |
很多团队把 90% 精力放在 prompt wording，只有 10% 放在 guardrail。顺序反了。
一个更像 AI PM 的立项模板
在写 PRD 前，先补这张表：
| 问题 | 你的答案 |
|---|---|
| 用户任务是什么 | 例如“先生成客服回复 draft” |
| 为什么要用 AI | 因为规则写不完，人工速度慢 |
| 模型失败会怎样 | 错答、跑题、泄露不该说的话 |
| 容错方式是什么 | source + review + fallback |
| 成本是否成立 | 每次成功任务成本是否可接受 |
只要这 5 个问题答得很虚，这个需求通常还不成熟。
Practice
拿你现在最想做的一个 AI feature，别先写功能列表。
先只回答下面 4 行：
- AI 在替用户完成哪一个具体 task
- 这个 task 出错时会造成什么后果
- 这个 task 的 success 怎么衡量
- 单次成功任务的成本大概多少
你能把这 4 行讲清楚，才算真正进入 AI PM 视角。