01 触发事件

2025 年，Sendbird CEO John Kim 在 Lenny's Newsletter 访谈里披露了一套很具体的内部 AI adoption 机制：公司追踪全员 token 使用，按每日 token 消耗划分五个层级到 AI God；同时搭建了一个叫 Automators 的内部 quest 市场，任何人都可以提交 automation 或 tooling 需求，由工程师或 AI agents 接单；再加上一套预先通过 InfoSec 审核的 app templates，让非工程团队也能直接上线生产级应用。

更具体一点，原文给了三个不该被忽视的信号。

第一，营销团队在没有工程支持的情况下，做出了一个带 Stripe 集成的 live swag store，而且不是 demo，原文明确说它能产生真实收入。

第二，quest 本身不是工单，而是被产品化：每个 quest 会标明 risk level、weeks saved、受益对象，完成者还能获得经验值并兑换奖励。

第三，token 使用不是后台报表，而是组织可见的 leaderboard。John Kim 甚至设定了 AI God 门槛：超过 100M tokens/day。

这里最值得停一下的，不是 100M 这个数字本身，而是它被放进了管理系统。我没在 Sendbird 内部跑过这套机制，所以对 token 口径、是否含 batch、是否含 agent loop 还不能下结论；但哪怕保守看，这也是一个很强的供给侧信号：成熟团队已经开始把 token 当作和 headcount、SaaS seat、cloud spend 同级的经营变量。

原文里还有一句更关键的判断：John 看的不是 token 总量，而是 usage curve 是否平滑。周末或假期曲线下滑，说明 AI 还没在“替你工作”；曲线越平，说明 AI 系统开始 24/7 运转。

这才是这篇访谈真正值得写的地方。

空白处我认为最重要的一句原文是：

John monitors token usage over time and looks for smoothness in the curve. Dips mean people are on weekends or vacation and AI isn’t working.

02 这事的真正含义

表面上，这是“如何推动员工使用 AI”。

其实不是。

这件事真正说的是：企业内部正在出现一层新的治理栈，位于 model access、权限控制、成本分配、激励设计和 production shipping 之间。token leaderboard 只是前台 UI，后台是组织把 AI 从个人提效工具，改造成可审计、可比较、可预算、可分层授权的生产系统。

问题不在“员工会不会用 Claude 或 ChatGPT”，而在“公司能不能把 AI 使用转译成稳定产出，同时不把安全和成本炸掉”。

Sendbird 的三件套，刚好构成一个闭环。

token leaderboard 负责可见性。

quest marketplace 负责需求撮合与产出度量。

secure templates 负责把 experimentation 压进合规边界内。

这三者合在一起，等于把原本散落在各个团队里的 shadow AI，收编进一个内部平台。这里的核心不是文化，而是 platformization。企业不是在买几个模型 API；企业是在为内部 builder 建一条受控的生产通道。

这对 AI infra 和 API 市场很重要，因为它意味着真正会被定价的，未必只是每百万 token 单价，而是“谁能成为企业内部 AI 治理层的默认入口”。

如果一个平台能同时提供 model routing、usage attribution、budget guardrails、RBAC、审计、缓存、模板化 deployment，它的 switching cost 会比单一模型高得多。模型可以换，治理面板更难换。很多人还在盯 benchmark 排名，这当然重要；但对组织采购来说，benchmark 只决定“能不能进门”，治理能力决定“能不能留在里面”。

我可能在这里高估了中大型公司对统一治理的执行力，因为很多组织会卡在部门预算、IT 权限和自建意愿上；但趋势很清楚：AI adoption 正从“seat-based software rollout”转向“token-based production management”。

而这会直接改变 token 经济学。

当 token 从个人消费变成组织预算对象后，管理层会更关心三件事：

  • token 是否带来可归因产出
  • 哪类 workflow 值得高价模型，哪类应该 routing 到便宜模型
  • 哪些 agent 任务应该在夜间、batch、缓存命中或异步执行

也就是说，企业最终购买的不是 intelligence，而是 governed throughput。

03 历史类比 / 结构对照

我想到的类比不是 2022 年 ChatGPT，而是 2014 年前后的 AWS 普及期。

当年云计算真正的拐点，不是“开发者终于可以租服务器”，而是公司开始围绕 cloud 建预算、权限、计费标签和 deployment 流程。EC2 本身只是算力；真正改变组织行为的是整套 cloud operating model。后来 FinOps 会成为独立职能，并不意外。

今天 token leaderboard 很像早期 cloud cost dashboard。

quest marketplace 很像内部版的 Jira 加上 App Store。

secure templates 很像平台工程团队给业务线提供的 golden path。

也因此，我更愿意把 Sendbird 这套方法理解为“AI Platform Engineering 的雏形”，而不是“员工培训项目”。培训解决的是认知落差，平台解决的是系统摩擦。认知会随着时间自然扩散，系统摩擦不会。

另一个更锋利的类比是 iPhone 之后的 mobile shift。那时很多公司误以为自己需要的是“一个手机网站”，后来才发现真正要重建的是 distribution、交互和应用结构。现在很多公司也误以为自己只需要“给员工开通一个大模型账号”，但真正要重建的是任务流、权限边界和成本结构。

这也是为什么 quest 机制有意思。它把需求从管理层指派改成市场撮合，把“我要一个工具”变成一个可领取、可比较、可奖励的工作单元。某种意义上，这是在企业内部模拟一层 AI-native labor market。

我没看到 Sendbird 公开更多完成率、复用率、单 quest 成本等硬数据，所以还不能断言这套机制已经形成 durable moat；但结构上，它确实对应了一个越来越清晰的历史模式：每一次底层技术扩散，赢家不是最先喊口号的人，而是最先把新资源纳入管理系统的人。

04 对 AI builder 意味着什么

如果你是 AI builder、API 消费者、或者在带一个开发者团队，这件事对这周和这个月的决策有非常直接的含义。

第一，不要再把 token usage 只当成本看板，要把它变成行为与产出的联合指标。

最低配也该做到按 team、project、workflow、model 维度切 usage attribution。再往前一步，应该能回答：哪个 agent flow 花了多少 token，带来了多少节省工时、多少 ticket closure、多少 revenue assist。没有 attribution，就谈不上 routing 优化；没有 routing 优化，模型单价再降也只是被浪费吞掉。

第二，建立面向非工程人员的 golden templates。

Sendbird 这点非常务实。非技术团队最大障碍不是不会写 prompt，而是不敢把东西发到生产环境。我没在你的组织里看过现有权限结构，但经验上只要 authentication、database、logging、secret management、审计路径先包好，业务团队的 shipping 速度会突然上一个台阶。这里真正稀缺的不是模型能力，而是可复用的安全脚手架。

第三，内部 AI adoption 的单位应该从“人均账号数”切到“任务自动化吞吐量”。

token leaderboard 看起来像 gamification，但底层是在给组织找出高频 builder、潜在 platform owner 和 AI-native operator。对 leader 来说，比“谁会写 prompt”更重要的是“谁能把不连续的人类工作流变成连续的 agent workflow”。那种人不一定 title 高，但会很快成为关键节点。

第四，API 采购逻辑要变。

如果你的客户正在学 Sendbird 这种治理方式，那么他们未来会越来越需要：

  • 统一 model access
  • 多模型 routing
  • token 级别计费可视化
  • prompt caching / batch / 异步任务
  • policy guardrails
  • 团队与项目维度的预算上限

这意味着单一模型 vendor 的 moat 可能弱于控制入口的网关和 orchestration 层。至少在中期，我认为 model quality 仍会决定高价值任务归属，但预算和治理会决定绝大多数 token 流经哪里。

第五，开始看 usage curve，而不是月度总消费。

平滑曲线的含义非常现实：你的 agent 是否脱离了“有人盯着才运行”的状态。周末还在跑的不是员工，而是 workflow。能不能把白天同步交互任务转成夜间异步处理，能不能把高延迟高成本步骤放进 batch，能不能利用 KV cache 和 prompt caching 降低重复调用，这些都会决定你的 token 毛利结构。

这部分我可能偏向 infra 视角，低估了很多团队现在最缺的仍然是具体 use case；但一旦 use case 成立，治理与吞吐很快就会压过 demo 感。

05 反方观点 / 风险

我刚才的判断有一个明显风险：我可能把一个优秀 CEO 的内部管理实验，误读成了普遍可复制的方法论。

首先，token leaderboard 可能制造错误激励。

高 token 消耗不等于高价值产出，甚至可能只是低效 prompt、失控 agent loop、过度上下文塞入、或者把本该 deterministic 的流程硬丢给模型。把 100M tokens/day 设成 aspirational tier，某种程度上是在奖励消耗，而不是奖励结果。除非背后有非常强的 outcome metrics，不然这套机制可能把组织带向“用得越多越先进”的幻觉。

第二，quest marketplace 可能演变成内部需求黑市。

如果没有统一的 code ownership、维护责任和生命周期管理，非工程团队快速做出的工具会大量堆积，最后变成一堆没人敢删、也没人持续维护的内部小应用。你今天省掉了两周工程排期，六个月后可能换来安全债和维护债。我没看到原文披露 quest 的后续维护制度，所以这里我会保留很强的怀疑。

第三，secure templates 解决的是起步，不是复杂系统整合。

模板适合 CRUD、表单流、内部工具、轻量 agent，但一旦碰到核心交易链路、复杂数据一致性、多系统集成、严格审计要求，非工程 builder 的边界很快就会出现。换句话说，这套方法更像把长尾需求吸出工程队列，而不是替代核心研发。

第四，这个案例对外部市场的启示也可能被高估。

Sendbird 作为一家本身就偏技术和全球化的软件公司，组织密度、管理带宽、员工素质未必具有代表性。很多传统企业连 SaaS 权限治理都没做明白，更别说 token attribution 和内部 builder 市场。把这套 playbook 生搬硬套过去，结果可能只是多了一个漂亮 dashboard。

最后，还有一个更大的反方：如果基础模型继续快速 commoditize，那么企业内部真正稀缺的未必是治理平台，而是拥有业务上下文、能接系统、能闭环执行的 agent product。本质上，治理层可能只是过渡价值，最终大头利润仍会被拥有 distribution 和工作流入口的应用层拿走。

这一点我不能排除。

但即便如此，我还是会坚持一个核心判断：Sendbird 这次透露出来的，不是“AI 用得很猛”，而是企业开始把 token、权限、模板和任务市场绑成同一套 operating system。谁先控制这层，谁就更可能控制未来企业 AI 的默认入口。