上一篇文章聊了传统软件和AI应用在技术层面的差异。这篇文章把视角转到你日常最熟悉的工作上——需求文档怎么写、怎么验证质量、怎么迭代产品。

作为传统PM，这些你闭着眼都能做。但AI应用PM在这三件事上的做法，已经发生了根本性的变化。

这篇文章，专门对比这三种核心工作的差异，帮你搞清楚：转AI PM，你到底要补什么。

一、需求文档：从”写流程”到”写标准”

先问自己一个问题：你现在写PRD，核心在写什么？

大部分PRD的内核是流程：用户做什么操作 → 系统怎么响应 → 什么情况报错。逻辑清晰、路径明确，研发照着实现就好。

这个模式在AI应用里，部分失效了。

传统PRD的写法

功能：智能邮件摘要触发：用户点击「摘要」按钮逻辑：  1. 系统读取邮件正文  2. 调用摘要模型，生成100字摘要  3. 显示摘要，用户可复制或编辑异常：  - 正文为空 → 提示"无内容"  - 模型超时 → 提示"生成失败，请重试"

你能写清楚每一步，因为每一步都是确定的。

AI功能的需求文档

同样的”智能邮件摘要”，AI版本的需求文档要怎么写？

功能：AI邮件摘要输入：用户选中的邮件正文输出：100字以内的中文摘要【期望输出特征】- 摘要长度：80-120字- 语言：与原文一致（原文是中文则用中文）- 内容：涵盖邮件的核心信息（人物/事件/时间/动作）- 语气：客观中立，不加入主观判断【拒绝案例（不合格输出）】- 超过150字- 引入了邮件正文未提及的信息- 摘要内容与原文事实矛盾- 使用原文未出现的专有名词【格式要求】直接输出一段文字，不加前缀如"摘要："，不加编号【示例】原文：[某封业务邮件正文...]期望输出：[符合上述特征的摘要...]

看出区别了吗？

传统PRD写的是流程，研发照着实现，输出是确定的。AI功能的PRD写的是标准 + 反例 + 示例，研发照着实现，但输出是概率性的——模型每次生成的内容都略有不同，你要靠这些标准来判断”这次是否达标”。

这本质上更像写测试用例，而不是写流程图。

对你意味着什么

写AI功能的需求文档，你最需要的不是画流程图的能力，而是：

• 定义清晰的能力边界：什么该答、什么不该答
• 识别反例的能力：什么样的输出是绝对不能接受的
• 提供正向示例的能力：几个高质量的输入-输出样例，比任何文字描述都有效

这些能力，和写传统PRD需要的”逻辑拆解”不太一样，但也没有你想象的难——本质上是你已经在做的事情，只是换个侧重点。

二、质量验证：从”QA测试”到”Evals评估”

传统PM怎么判断一个功能”做完了”？

通常是这样：

研发：做完了PM：测试一下QA：有1个bug，已提单研发：修复了QA：回归测试通过PM：验收通过，上线

QA给你的是一个确定性的答案：通过或不通过。功能符合需求就过，不符合就不过。

AI应用没有这个奢侈。

AI输出是概率的，无法穷举测试

你想验证”邮件摘要功能”是否正确——但模型对同一封邮件每次生成的摘要都不同，你不可能把所有可能的邮件都跑一遍。

所以传统QA在AI应用里基本失效，你需要的是Evals（评估体系）。

什么是Evals

简单说，Evals就是一套用机器代替人工QA的评估方法。

步骤如下：

第一步：建立测试集

收集一批有代表性的真实邮件，作为基准样本。比如50封，覆盖不同长度、不同类型（商务/私人/营销）、不同语言的邮件。

第二步：定义评估维度

每个维度对应一个打分规则：

维度1 - 长度合规：80-120字 ✅，超150字 ❌维度2 - 内容一致性：摘要事实与原文一致 ✅，有矛盾 ❌维度3 - 格式正确：无额外前缀 ✅，有"摘要："前缀 ❌维度4 - 信息覆盖率：涵盖核心人物/事件/时间 ✅，缺两项以上 ❌

第三步：跑批量评估

用这50封邮件批量跑模型，把输出交给评估规则打分。人工抽检20%，确保评估规则本身是对的。

第四步：设定通过阈值

长度合规率 ≥ 95%内容一致性 ≥ 90%格式正确率 = 100%（这是底线，不能妥协）信息覆盖率 ≥ 85%

四个维度全部达标，功能才能上线。

Evals vs 传统QA的核心区别

对你意味着什么

设计Evals，是AI PM最核心的新技能之一。你不需要会写代码来搭建评估系统（通常是工程师帮你搭），但你必须能回答这些问题：

• 这个功能需要测哪些维度？
• 每个维度的”合格”标准是什么？
• 测试集怎么构建才能代表真实用户场景？
• 哪些维度是绝对底线（不能有任何不合格案例）？

你设计Evals的能力，直接决定了你产品的质量下限。

三、产品迭代：从”改代码等发版”到”改Prompt立竿见影”

最后一个大差异：迭代速度。

传统PM提一个需求变更，流程是这样的：

PM提出变更 → 评审 → 研发排期 → 开发 → 测试 → 发版最快：3-5天正常：1-2周复杂：1个月以上

在AI应用里，如果你只是调整Prompt或评估标准，流程变成了：

PM调整System Prompt → 跑Evals → 指标达标 → 上线最快：5分钟正常：30分钟-2小时

这个变化听起来很爽，但背后有两个你必须理解的影响。

影响一：Prompt的质量直接影响产品体验

传统应用里，改一个按钮的文案，研发花5分钟改代码，你几乎感觉不到差异。

AI应用里，改一句话Prompt，效果可能天差地别。

举一个真实的例子：

差Prompt：你是客服，回答用户问题。好Prompt：你是XX公司的客服助手「小帮」。- 只回答与订单、物流、退换货相关的问题- 其他问题回复：「这个问题超出了我的服务范围，我将帮您转接人工客服」- 回答风格：简洁、专业、不超过50字

两个Prompt的差距，不只是体验的差距，是”能用”和”不能用”的差距。

所以Prompt设计变成了AI PM的核心输出物，而不是像传统应用里那样”功能逻辑主要由工程师实现”。

影响二：快速迭代不等于可以随意试错

Prompt改得快，意味着你可以在短时间内验证很多想法——但也意味着你需要一套更快判断”这次改对了还是改错了”的机制。

答案就是Evals。没有Evals支撑的快速迭代，只是盲目试错；有了Evals，你才能真正做到”快速收敛”。

四、转AI PM，能力差距在哪里

说了这么多，具体要补什么？直接给你一个清单。

传统PM已经有的，继续用

✅ 用户调研能力：理解用户在什么场景下有什么需求✅ 竞品分析能力：知道市面上的AI产品怎么解决同类问题✅ 原型设计能力：把产品想法快速可视化✅ 数据分析能力：看指标、找问题、做归因✅ 跨团队沟通：协调研发、设计、测试资源

新增的，必须补

🔴 Prompt设计能力   怎么写System Prompt让它稳定输出你想要的结果   怎么用Few-shot示例提升模型在边缘case的表现   怎么设计输出格式让解析更可靠   → 入门方法：每天用ChatGPT/Claude刻意练习，观察什么描述有效什么无效🔴 Evals设计能力   怎么定义评估维度   怎么构建有代表性的测试集   怎么设定合理的通过阈值   → 入门方法：选一个你常用的AI功能，自己设计一套评估标准并执行🔴 模型基础认知   知道Token、上下文窗口、幻觉是什么意思   知道不同模型的能力/成本/速度差异   知道RAG、Agent、Function Calling的应用场景   → 入门方法：读两篇靠谱的技术科普文，搞清楚这几个概念就够了🔴 成本意识   每次模型调用都在花钱   上下文越长费用越高   不同任务的模型选型影响成本   → 入门方法：用自己产品的API，跑几个真实对话，看看Token消耗

不需要会的

❌ 训练模型❌ 深度学习原理❌ 写完整的AI系统代码❌ 成为Prompt大师（这是目标，不是起点）

五、一句话定位你的新角色

传统PM的核心能力是：把用户需求，翻译成研发能实现的流程逻辑。

AI PM的核心能力是：把用户需求，翻译成模型能理解的约束描述，并建立评估体系确保它执行到位。

翻译的工具变了——从流程图变成了Prompt和Evals——但翻译的本质没变。

你已经在做的事情，加一点新工具，就是AI PM了。

本系列第三篇：《AI应用开发，为什么说”这和以前完全不一样”？》