1000 人、100 万个 Agent：Notion 如何把组织推向可编程工作台

2026 年 5 月，Notion 把自己的工作台接上了 AI agent、外部数据源和可运行的自定义代码。公司称，自 2026 年 2 月推出 Custom Agents 以来，客户已经创建了超过 100 万个 agent。Notion 也开始支持 Workers、外部 Agent API，以及 Claude Code、Cursor、Codex、Decagon 等外部 agent 接入。1

这组动作说明，Notion 不再满足于做一个「记笔记和写文档的工具」。它想成为人、数据、代码和 agent 协作的工作台。

反差在公司内部。2025 年 8 月，WIRED 把 Notion 描述为一家约 1,000 人、估值 100 亿美元的旧金山创业公司；报道同时写到，工程师已经普遍使用 AI coding 工具，三位联合创始人之一 Simon Last 放弃管理岗位，转做「super IC」——超级个人贡献者。2

这不是一家靠缩减人数来证明 AI 效率的公司。公开资料里更清楚的信号是：工作单元正在变化。人负责表达意图、补充上下文、设定质量标准和验收结果；AI 负责搜索、起草、改代码、做摘要和串联工具。

Notion 的完整组织图、部门数量、管理层级和 manager-to-IC 比例没有公开可靠的统一口径。能确认的，是几个会改变组织运行方式的节点。

第一，创始人不被固定在管理岗位上。Simon Last 是三位联合创始人之一，后来把管理责任交出去，专注于个人贡献者工作。2

这不等于 Notion 没有管理者，也不等于所有公司都应该让创始人回到一线写代码。它至少说明了一种选择：管理是职责，不是晋升后的唯一终点。在 AI 加快执行速度之后，熟悉系统、判断质量、能把复杂问题讲清楚的人，未必需要通过带人来获得影响力。

第二，产品方向已经把组织压力从单一应用推向平台。Notion 的 Developer Platform 要同时处理 agent 编排、外部数据同步、云端代码运行、第三方 agent 接入和安全隔离；TechCrunch 报道称，用户可以让 Workers 在沙箱中运行自定义代码，也可以通过 API 把自己的内部 agent 接入 Notion。1

从产品路线可以推断出组织需要的能力：工程团队不能只维护页面编辑器，产品团队也不能只做文档体验；平台、数据连接、agent 行为、权限和开发者体验会被拉到同一张路线图上。这是基于产品公开信息的推断，不是 Notion 已公开的部门划分。

WIRED 报道中的一句话很有信息量：Notion 仍在积极招聘工程师，但希望招聘那些对 coding tools 真正乐观的人。2

这和「AI 会让工程师消失」不是一回事。Notion 的工程师会用 Cursor、Claude 或 Claude Code、Codegen，让 AI 起草代码、解释陌生代码、修功能；人仍然要调试、测试并把结果送进生产环境。2

更有意思的是 pair programming 的用法。WIRED 记者作为英文专业背景的非资深编码者进入团队时，没有被单独扔给一个 agent，而是和有经验的工程师一起工作。Ivan Zhao 解释，资深工程师有「taste」，因此更适合和经验较少、但能借助 AI 做出东西的人配对。2

所以，Notion 可观察到的招聘信号不是「只要会提示词的人」，而是三件事的组合：

前两点来自报道中的工作过程，最后一点是对这些事实的组织化总结。Notion 没有公开一套完整面试题或评分表，因此不能把这段总结冒充成官方招聘规则。

Notion 工程师把 AI coding 工具比作「管理一群实习生」。Simon Last 曾同时使用三个 AI coding 工具，后来发现这种方式很有压力，改成通常一次只依赖一个工具。2

这个比喻比「AI 助手」更准确。实习生可以快速执行，却不一定理解系统约束；管理者要给上下文、拆任务、检查中间结果，并承担最终责任。AI coding 只是把这种管理关系放进了每个工程师的工作台。

WIRED 记录了一段很小、但很具体的协作流程：工程师先让 AI 研究 Notion 代码库，随后把 Slack 里的工程笔记和明确的 ticket 一起交给模型；模型生成代码，人和 pair programmer 再调试、测试。记者和两位工程师把 mermaid 图表的放大功能从准备到完成，合计用了约 45 分钟。2

这段流程的重点不在 45 分钟或 7 美元。小任务本来就不代表复杂系统，token 费用也不等于总成本。真正值得借鉴的是反馈回路：先让 AI 探索，再让人补充上下文；先快速做出可运行版本，再在每周 demo 中公开展示；问题暴露在团队面前，而不是等到上线后才被发现。报道还写到，Notion 的工程师会在 weekly demo meeting 中展示工作成果。2

Notion 的公开工作指南把这种协作写成更正式的流程。产品发布清单要求明确 EPD、市场、销售和客户支持团队的 owner、时间点和依赖关系；Notion AI 可以扫描清单，找出没有 owner 的任务、总结进度、提示需要输入的地方。3

这里需要区分两件事：这是一篇 Notion 公开发布的工作方法指南，不足以证明公司内部每次发布都严格按这套清单运行。但它至少揭示了 Notion 认为好的协作应该具备什么：工作、上下文、负责人和决策点要放在同一处，AI 负责减少搜集和汇报成本，人负责取舍。

Notion 另一个公开指南把 business case 拆成问题、数据、成本、收益、风险、时间线和下一步；在这个过程中，Notion AI 可以总结用户反馈，从粘贴的表格或 CSV 中提取信息，生成方案比较，基于描述生成风险，并在收集评论后提取 action items。4

把这些公开材料与工程师的实际工作放在一起，可以得到一套更接近 AI 原生组织的运行顺序：

这不是一张 Notion 官方组织图，而是从公开工作流程中提炼的分析框架。它改变了管理者的工作重心：管理者不只是派任务、追进度，还要保证上下文完整，设置质量标准，安排能看懂系统的人做验收。

目前没有足够公开证据证明 Notion 已经用 AI 改写了绩效考核、OKR 周期、薪酬体系或 manager 层级。把「AI coding 很普遍」直接写成「公司已经 managerless」，会超出证据。

Notion 内部的 AI 使用并没有停留在工程师写代码。WIRED 报道称，公司已经给企业销售团队安排 AI engineer，教软件销售人员在自己的工作中使用 AI。2

这个岗位很值得管理者注意。AI 工具真正进入业务团队时，难点常常不是购买软件，而是把销售流程、客户问题和工具能力翻译成可复用的工作方式。工程团队最懂模型和工具，销售团队最懂客户和流程；中间需要一个能把两边接起来的人。

2022 年 10 月，Notion 创始团队还曾在一次全公司 off-site 期间，把自己关在酒店房间里，用早期的 ChatGPT 做原型。Ivan Zhao 回忆，那次实验让他们意识到生成式 AI 会让 Notion 早期设想的「no code/low code」方向重新成立。2

这条时间线说明，Notion 的 AI 原生化不是先写战略再让员工执行，而是创始人先把工具放进自己的工作里，看到它改变产品可能性，再把这种能力扩展到工程、销售和客户工作台。不能据此断言所有团队都采用了同一套流程，但它解释了为什么产品路线会从 AI 写作一路走向 agent、Workers 和外部 agent 编排。

一，把 AI 的管理对象从「人」改成「工作单元」。 不要先要求全员使用 AI。先挑一个高频、边界清楚的任务，写明目标、输入上下文、允许的工具和验收标准。没有这些条件，AI 只会加快错误的产生。

二，把 senior 的判断力放到 AI 流程里，而不是流程外。 Notion 的 pair programming 说明，资深工程师的价值不是和 AI 比谁写得快，而是判断代码是否理解了系统、有没有遗漏边界。对新手来说，AI 降低了开始的门槛，也会制造「我已经会了」的错觉；配对和 demo 是纠正它的低成本办法。

三，为业务团队配置 AI 的翻译者。 Notion 给企业销售配置 AI engineer，说明 AI adoption 不是工程部门的独角戏。销售、客户成功、财务和运营都需要有人把本部门的真实流程翻成 agent 能执行、又能被人验收的任务。

Notion 的组织实验还没有公开完整答案：它的绩效机制、管理层级和人员分布仍然不可见。现阶段更稳妥的结论是，Notion 正在把「表达意图、组织上下文、调用 AI、人工验收」做成同一条工作链。能复制的不是 1,000 人的规模，也不是某个工具清单，而是这条链上每一步的责任边界。