深度复盘小红书AI搜索：为什么说「评测」是AI PM的新PRD？

最近我听了一场小红书 AI 搜索团队的内部分享，收获极大。他们一线实践中遇到的问题、设计的架构和迭代的思路，清晰地印证了一个正在硅谷形成的新共识：AI 时代的 PM，最核心的技能不再是写 PRD，而是写 Evals（评测）。

这篇文章，我想先完整复盘一下小红书的 AI 搜索，然后结合他们的实践，详细聊聊为什么「评测即 PRD」是 AI 产品经理在当前时代最重要的思维转变。

Part 1：复盘小红书 AI 搜索

首先，小红书如何定义 AI 搜索？

与传统搜索交付相关文档（笔记列表）相比，AI 搜索能理解自然语言提问，代理信息检索过程，最终直接交付答案或解决相关问题。

1、传统搜索的「围城」与 AI 搜索的「破局」

小红书是一个「经验」的宝库，传统搜索（笔记列表）的优势在于多样性和信任感。用户搜「西安攻略」，可以看官方总结，也可以看真实用户的细致分享，能「逛」起来，满足浏览型需求。

但传统搜索的劣势也很明显：效率低、无法解复杂 Query。用户需要自己翻阅大量笔记来总结答案。

AI 搜索恰好相反，它的优势是效率高、能解复杂问题（如攻略、决策对比）、支持多轮。但它的致命弱点是信任感低（幻觉、虚构）和多样性差。

讲座中提到了一个绝佳的例子：

用户问：「2026 年世界杯冠军是谁？」

AI 搜索可能会基于站内用户的「预测」笔记，言之凿凿地回答：「是葡萄牙，C 罗踢进了几个球。」

这个 case 生动地说明了 AI 搜索的挑战。小红书的 AI 搜索，就是要在保留「经验感」和「信任感」的同时，提供「答案效率」和「复杂问题解决能力」。

用户的需求分为「问答类」和「决策类」。无论是哪一类，都存在从单一问题到复杂决策的路径。小红书 AI 搜索的核心，就是服务好这些传统搜索无法高效满足的复杂需求，如经验问答和决策攻略。

2、从 RAG 到 Workflow：架构演进

面对复杂的搜索路径，小红书是如何设计技术架构的？讲座中分享了他们对几种常见 AI 搜索方案的取舍。

纯 LLM：完全依赖大模型，受限于训练数据，无法获取实时和站内信息，最早被淘汰。

RAG（检索增强生成）

Query -> Retrieval -> LLM -> Response

这是目前的主流方案。好处是能引入外部真实信息，解决幻觉问题。但坏处是，它本质上还是「单次检索」，无法解决需要多步思考、多次搜索的复杂问题（比如做攻略）。

Agentic Search（智能体搜索）

Query -> Thinking -> Action (Search / APIs) -> Loop ...

在 RAG 的基础上引入了「思考」和「循环」。模型可以自行规划，多次搜索，解决多跳问题。

AI Workflows（工作流）

针对特定问题（如旅行攻略、购物决策）设计的 SOP（标准作业程序）。

「霸王茶姬推荐」就是典型的 Workflow：系统会去搜索、聚类、统计不同奶茶被用户「喜欢」的次数，然后分门别类地介绍，最后给出统计结果。这远比一个 Agent 的泛泛而谈要有用得多。

3、最终选型：RAG + Agentic + Workflows 的混合框架

他们完整的技术框架如下：

• Pre-Search（预搜索）：首先对 Query 进行理解，引入关联笔记和高频搜索词，让模型真正理解用户背后的意图。
• RAG：应对简单的问答。
• Agentic Search：应对复杂问题。讲座中用「UPF 是什么意思」举例：简单 RAG 只会回答 UPF 的定义；而 Agentic Search 会进一步思考「用户为什么搜这个？」，并扩展搜索「防晒衣 UPF 值多少合适？」，从而给出更满意的答案。
• AI Workflows：应对高价值的复杂场景（如旅游、购物）。为什么不用 Agent？因为 Agentic Search「很难找到很好的可验证的 reward」，输出不可控。而 Workflows 通过注入专家知识和固化流程，能极大提升结果的确定性和质量。
• 多工具调用：除了站内搜索，还会调用全网搜索、实时信息 API 等。

Part 2：「评测即 PRD」：AI PM 的新范式

复盘完小红书的 AI 搜索，我们会发现一个核心问题：系统如此复杂（RAG、Agent、Workflows 并存），模型输出又具有不确定性（比如「2026 世界杯」的幻觉），PM 该如何管理这个产品？如何确保优化迭代是走在正确的方向上？

答案是：靠评测。

1、PRD 的转折：从「定义产品」到「定义评测」

过去，PM 通过 PRD 明确功能和边界。但 AI 产品的特点是：模型具有随机性、输出动态、场景开放，任何静态文档都无法覆盖所有情况。

你无法在 PRD 里写一条规则：「模型不允许预测未发生的世界杯结果。」这种静态规则根本无法穷举所有幻觉。

因此，AI 产品团队逐渐转向另一种方式：不再靠文字定义产品，而是靠评测体系定义产品。

Evals（评测）包括自动化测试、黄金对话（Golden Conversation）、LLM 法官（LLM-as-a-Judge），共同构成了一个「活的 PRD」：可运行、可验证、可演化。

以前 PM 写文档指导模型；现在 PM 写评测校准模型。评测不是附属环节，而是核心定义。

2、思维转变

• 传统 PM：先写需求，再做开发。
• AI PM：先实验，再评测，从评测中提炼需求。

评测既是产品规范（Spec），也是验证机制（Judge），为团队提供真实、可操作的质量信号。

Part 3：小红书如何实践「评测即 PRD」？

小红书的分享，完美地印证了上述观点。他们坦言，在实践中最关注三个问题，而这三个问题，恰好构成了以 Evals 为核心的「活的 PRD」体系。

关注点一：SFT 数据构造——定义「黄金评测」

SFT（监督微调）数据决定了模型回答效果的上限。而小红书的 SFT 流程是如何开始的？由「产品」和「数据运营」，通过调 Prompt、设计标准，一起构造一个理想的数据集。

这，就是「评测即 PRD」的第一步。

• 传统 PRD：PM 写一篇文档，描述「旅游攻略」应该长什么样。
• 小红书的 PRD：PM 直接去定义（甚至标注）100 条「理想的」旅游攻略 SFT 数据（Golden Conversation）。

这个「理想数据集」本身就是产品形态的最终定义。它不再是静态描述，而是成为了可运行、可训练的「活 PRD」。

关注点二：强化学习——定义「负面评测」

SFT 定义了上限，而 RL 则保证了下限。PM 不仅要定义「什么是好的」，更要定义「什么是坏的」。

AI 产品的需求不是写出来的，而是在错误中被发现的。小红书明确提到，他们会系统化地分析 Bad Case，比如「重复」「答案格式有问题」「语言风格太油」等等。

• 传统 PRD：PM 在文档里写一条「回答风格不要油腻」。（工程师：？？？）
• 小红书的 PRD：PM 将这些「失败模式」提炼出来，定义成「确定性的 Reward 信号」，用来训练 Reward Model。

这个 Reward Model，就是一个自动化的「负面评测」系统，它系统性地惩罚模型的坏行为。PM 的「失败模式表」不再是一份文档，而是转化为了可执行的、约束模型底线的代码。

关注点三：评估难题——构建「动态评测飞轮」

这是最关键的一环。AI 搜索不像传统搜索有清晰的后验信号（如点击率 CTR）。用户可能看了答案就走了，你不知道他满不满意。

因此，AI 搜索必须依赖强大的「先验评估」。小红书设计的这个「评估飞轮」，就是「评测即 PRD」的终极体现：

A1：评估与产品对齐

这就是 PM 的核心领域。PM 要联合产研团队，定义「黄金标准评测集」和「多维评估标准」（如准确性、完整性、合理性、有用性、创新性等）。这就是产品的核心规范。

A2：评估与训练对齐

当系统复杂到人工难以评测时，就引入「LLM 法官」。小红书实践了三种方式：基于规则、训练 Reward Model、利用更强模型做判别。这就是产品的自动验证机制。

A3：评估与后验对齐

这是飞轮的闭环。A1 和 A2 定义的「先验评测」终究是「专家视角」，它和「用户真实满意度」可能存在 gap。因此，团队必须持续收集真实的用户反馈（点赞、点踩、分享、阅读时长），反过来校验和迭代 A1 的评测标准。

这个 A1 到 A2 到 A3 的飞轮，构建了一个动态迭代、持续进化、连接真实世界的「活的 PRD」。

Part 4：Evals，新一代 PM 的核心语言

小红书的实践清晰地展示了 AI 时代产品经理的转变：传统 PRD 告诉团队「我们要造什么」；Evals 式 PRD 告诉模型「什么才是好」。

评测不只是验证标准，它就是产品需求的动态表达。Evals 是 AI 产品的语言，评测体系是产品不断进化的核心。

对于所有关注 AI 的产品经理同学来说，理解并掌握「评测」这个新语言，远比学习画原型和写 PRD 更为重要。