最近听了一期 Latent Space 的播客，嘉宾是 Notion 的 Sarah Sachs 和 Simon Last。

Sarah 负责整个 AI 工程团队，Simon 则是那个整天在折腾新原型的技术大佬。

这期播客聊了将近两个小时，我一口气听完。

他们最近刚发布了 Custom Agents 功能，表面上看就是让用户自己搭建 AI 助手，但背后的故事可太曲折了。

从 2022 年拿到 GPT-4 的早期访问权限开始算，这个功能他们前前后后推倒重建了 4、5 次。

不是小修小补那种，是真的整个推翻重来，为什么会这样？

今天我就把播客里最精彩的几个观点整理出来，和大家聊聊 Notion 在 AI 这条路上到底踩了哪些坑，又是怎么爬出来的。

1️⃣ 早期失败不是偶然，是模型真的不行

Simon 很坦诚地说，2022 年底他们刚拿到 GPT-4 的时候，第一反应就是做一个能调用 Notion 所有功能的 Agent。

听起来很美好，结果现实狠狠打了脸。

当时的问题有三个层面。

第一是模型本身太弱，连工具调用的概念都还没出现，他们得自己设计一套框架，然后和 OpenAI、Anthropic 合作微调模型去学会用这些工具。

第二是上下文窗口太短，稍微复杂点的任务就装不下了。

第三是可靠性极差，经常出现莫名其妙的错误，根本没法拿去给用户用。

Sarah 提到一个细节特别有意思，她说当时团队里总有人觉得是不是我们设计得不够好，是不是提示词没写对。

但后来他们逐渐意识到，这不是工程问题，是模型能力的硬伤。用她的话说，你得学会判断自己是在逆流而上还是顺流而下。

如果模型根本做不到，你再怎么优化架构也没用。

这个教训对我来说挺深刻的。很多做 AI 产品的团队现在可能也在经历类似的事情，拼命调优、加监控、写更复杂的 prompt，但如果方向错了，这些努力可能都是在浪费时间。

2️⃣ Agent Lab 理念：不只是套个壳那么简单

Sarah 说她面试的时候会给候选人看 Swyx 写的那篇 Agent Lab 的文章，然后问他们怎么理解。

这篇文章的核心观点是，做 AI 应用不是简单地把模型包一层 UI 就完事了，你得真正理解用户是怎么协作的，他们的工作流是什么样的。

Notion 的优势在于他们早就在做协作工具了，知道人们怎么用文档、数据库、看板这些东西。

现在 AI 来了，他们要做的不是造一个新的聊天界面，而是把 AI 能力无缝地嵌入到已有的工作流里。

比如说你在整理客户反馈，Agent 可以自动从 Gmail 读邮件，在 Notion 数据库里创建记录，用网页搜索补充公司信息，然后在 Slack 里通知相关团队。这整套流程，数据都在 Notion 里，用户根本不用切来切去。

Sarah 打了个比方，说他们就像 Datadog 和 AWS 的关系。AWS 提供基础设施，但 Datadog 更懂开发者需要什么样的可观测性工具。

Notion 和大模型的关系也是这样，模型是基础能力，但 Notion 更懂人们怎么协作。

这个角度我觉得很关键。

很多公司现在都在做 AI wrapper，但能不能做出真正有价值的产品，关键不在于你用了多先进的模型，而在于你对业务场景的理解有多深。

3️⃣ 团队文化：低自我和快速推倒重来

Sarah 管着 50 人左右的核心 AI 团队，但她说自己的角色不是出主意或者做技术决策，而是确保大家理解目标，知道什么最重要。

听起来有点鸡汤，但她后面说的一点我觉得特别务实：团队得习惯删自己写的代码。

Notion 的 AI 团队有个文化叫演示胜于备忘录。

工程师有想法了，不是写个文档等审批，而是直接做个能跑的原型出来。

公司内部有个专门的设计 playground，设计师也不画静态稿了，直接搭一个可交互的界面。

这种文化的好处是快，坏处是可能会产生很多废弃代码。

但 Notion 不在乎这个，他们觉得在 AI 这个快速变化的领域，方向比执行更重要。

如果新的模型出来了，新的架构思路更好，那就推倒重来。团队里没人会因为自己的代码被废弃而不爽，因为这本来就是常态。

4️⃣ Eval 体系：故意让 30% 测试失败

Sarah 花了不少时间讲他们的测试体系，这块我觉得是整个播客里最硬核的部分。

Notion 把 Eval 分成三类：回归测试、发布质量测试和前沿测试。

回归测试就是普通的单元测试，确保改了代码不会把已有功能搞坏。

发布质量测试是针对具体用户场景的，比如邮件分类、Bug 归档这些任务，通过率要达到 80%-90% 才能上线。

但最有意思的是第三类，叫前沿测试或者空间测试。这类测试故意设计得特别难，通过率只有 30% 左右。

为什么要这么做？

因为他们想知道模型能力的天花板在哪里。如果所有测试都能通过，那就说明测试太简单了，没法帮助他们理解技术的边界。

Sarah 说这个思路是跟 Anthropic 和 OpenAI 合作时慢慢摸索出来的。

一开始他们的测试都是围绕当前能做的事情设计的，但后来发现这样没意义，因为新模型出来了你也不知道它到底强在哪儿。

现在他们会专门设计一些今天做不好、但理论上应该能做的任务，然后看新模型能不能把通过率从 30% 提到 50%。

为了支撑这套体系，Notion 还创造了一个新职位叫 Model Behavior Engineer。

这些人不是传统意义上的软件工程师，很多人是语言学背景或者新毕业生。

他们的工作是写测试用例、分析失败原因、判断模型能不能做某件事。现在这个团队已经开始用 Coding Agent 来辅助写测试了，效率提升很明显。

这个思路我觉得值得所有做 AI 产品的团队借鉴。很多公司只关注今天能不能用，但不去思考明天模型进化了怎么利用。Notion 这种既看当下又看未来的做法，让他们能更好地把握技术演进的节奏。

5️⃣ 技术选择：为什么既支持 MCP 又更看好 CLI

播客里有一段关于 MCP 和 CLI 的讨论挺有意思。MCP 是 Anthropic 推的一套协议，用来让 Agent 调用外部工具。Notion 支持 MCP，但 Simon 说他个人其实更看好 CLI。

原因是什么？CLI 本质上就是给 Agent 一个终端环境，让它可以运行命令、读写文件、调试代码。这种方式的好处是灵活性特别高，Agent 可以自己排查问题，自己修 Bug。而 MCP 虽然权限控制更严格，但能力也更受限，适合那种比较简单、不需要太多自由度的场景。

Sarah 补充了一个商业角度的考量。她说 Notion 的定价策略是基于价值的，而不是简单地按 token 数计费。如果用户用 CLI 写了个脚本，一次性把任务搞定了，那就不会反复调用语言模型，成本自然低。但如果用 MCP，每个操作都得通过模型调用工具，token 消耗就会很高。从用户体验和成本角度，CLI 都更有优势。

不过他们也承认 MCP 还是有价值的，特别是在需要严格权限控制的场景。所以 Notion 两种都支持，具体用哪个看用户需求。

听完这期播客，我最大的感受是 Notion 在 AI 这件事上特别务实。

他们不追求 AGI 那种宏大叙事，也不急着去做基础模型，而是扎扎实实地解决具体场景的问题。

推倒重建 5 次听起来很痛苦，但也说明他们愿意承认错误，愿意等待技术成熟。