跨模型调度工作的运营团队

原文：The Ops Team That Routes Work Across Models 作者：Laura Entis 日期：2026-07-15

AI 模型从未像现在这样聪明，也从未像现在这样强大。但要把它们的潜力发挥到极致，仍然需要 AI 技能、流畅度，以及最重要的——愿意把复杂工作交给一个智能体（Agent），或是一群智能体。今天，我们将展示 Every 的业务运营团队如何跨 Fable、Codex 和客服平台 Fin 协同工作，随后看看 Granola 计划如何把会议转化为任何智能体都能使用的上下文。我们还会解释为什么 Sonnet 5 在写作方面依然表现平平（但在更明确限定的任务上做得更好），审视 AI 时代正在涌现的三种角色，并分享一些我们在 X 上最喜欢关注的人。

Every 内部观察

前沿的业务运营

执行运营经理 Jalaiyah Bolden 只有几天时间来为 Every All Access 的发布制定客户支持计划。All Access 是一项面向构建者的新型年度会员，包含对 Every 产品的无限使用权限及其他权益。她需要的信息散落在六个不同的来源中。“那完全是信息过载，”她回忆道——这种量级的混乱足以压垮规模大得多的运营团队。

但 Jalaiyah 没有手忙脚乱，而是深吸一口气，开始在不同模型之间灵活穿梭。

Jalaiyah 首先召唤了 Fable。她把所有相关上下文都开放给模型，指示它在任何信息缺失时提出澄清性问题，然后开始干活。

Fable 审查了 Slack 频道，读取了 Notion 文档和会议记录。它访问了发布会用的阶段性网站，逐一点击按钮以确认它们能正常工作，并标记出页面内容与会议记录或源文档矛盾的地方。接着，它把发现整理成一份按优先级排序的行动计划，并起草了支持材料：三篇面向用户的帮助文章、六段为 Fin（即之前的 Intercom 客服平台）编写的回复片段，以及 17 个供人工客服用来回复用户的模板。整个过程大约耗时 90 分钟——而且大部分在后台运行——这让 Jalaiyah 得以专注于其他事务。

在审核并“人性化”处理了文字之后，Jalaiyah 把所有内容交给运营负责人 Arielle Shipper，她随即启动 Codex 来校对文档，并创建了一个 Notion 任务追踪表，以便所有人清楚谁负责什么，保持进度一致。客户支持计划顺利且提前完成。知道何时以及如何使用不同模型，让这个团队能够屡屡达成看似不可能完成的截止日期。

换句话说，真正关键的不仅是拥有多个 AI 工具，而是建立一套清晰的流程，让每个模型在最合适的环节发挥作用——Fable 负责研究与初稿，Codex 负责校对与结构化管理，人工则专注于审核和情感判断。

拿走这个工作流

把糟糕的客服对话变成更好的智能体指令

当 Fin 的客服智能体错误地处理了一次客户对话时，客服经理 Waqqas Mir 并不会重写整个支持设置。相反，他使用 Codex 把这次处理不当的对话转化为一条有针对性的新指令。通过这种方法，他添加了一条规则，明确规定智能体应在何时将愤怒的客户转接给人工；还添加了一条明确指令，用以修补一个漏洞——即 Fin 会在用户要求时为他们生成代码。Waqqas 是在一次测试中让 Fin 为自己写了一个文件转换脚本后，才加上了这道护栏。

Waqqas 的工作流：

  • 通过平台的模型上下文协议（MCP，Model Context Protocol）服务器，把 Codex 连接到 Fin。 授权后，MCP 允许 Codex 从你的 Fin 工作区检索对话记录。在 Codex 的提示词中，输入两三个 Fin 处理出错的对话 ID，要求 Codex 拉取完整对话并诊断哪里出了问题。

  • 询问 Codex，指令在哪一步出了问题。 接着追问：“它为什么没有遵循我的指令？你能找出是什么造成了混淆吗？”Codex 会识别出缺失、不清晰或自相矛盾的指导，并提出简明的补充建议来修复问题。

  • 添加建议的规则并重新测试该场景。 MCP 连接允许 Codex 分析 Fin 的数据，但 Codex 无法直接修改 Fin 的设置。Waqqas 会自己添加新的指导规则，然后再次运行同一类对话。如果 Fin 重复犯错，他就把那轮对话的 ID 交给 Codex，要求它精准定位是哪条指令仍在引发问题。

本质上，这种调试方法把模糊的“表现不好”转化成了可定位、可修复的指令缺陷，就像给一段程序修 bug 一样来优化客服智能体。

“AI 与我”：Granola 的视野超越会议纪要

在本周的 AI & I 节目中，Granola 联合创始人兼 CEO Chris Pedregal 说，经营一家创业公司是一场永无休止的“刀战”。Granola 凭借一款出色的 AI 会议记录工具打响名号，并达到了15 亿美元的估值，但它不能就此止步：如今，Notion、OpenAI 和 Zoom 都提供了能转录和总结会议的工具。

Chris 对 Every CEO Dan Shipper 表示，更大的战役在于“我们将用什么界面来工作，以及在 AI 原生世界里，工作本身会变成什么样子”。正因如此，Granola 计划全面掌控围绕会议开展的工作：帮助人们在会前做好准备，在会后采取行动，并让会议上下文能够被他们使用的任何智能体获取。

在未来几个月里，Granola 计划改进其 API 和 MCP，力争成为这一领域的领导者。“前方有一个巨大的机遇，我们有机会抓住它，其他几家公司也一样，”Pedregal 说。

他对公司的方向和策略充满信心，但也清楚现在仍处于早期阶段——这场刀战永远不会结束。

“当人们说‘Granola 做得太好了’时，我心里想的是，来得容易去得也快，”他说道。“会议记录很有用，但还有很多东西会发生变化。仅仅因为人们现在用我们，并不意味着将来他们还会继续用我们做这件事——前提是我们在下一件事上不是最好的。”

可在 X 或 YouTube 上观看，或在 Spotify 或 Apple Podcasts 上收听。你也可以阅读文字记录。

脉搏检查

Spiral 总经理对 Sonnet 5 的试用体验

在 Every 内部，对 Sonnet 5 的初步评测充其量只能用平淡来形容。Marcus Moretti 将 Sonnet 5 纳入工作流测试两周后，发现这个评价大体上仍然成立——不过他找到了一个 Sonnet 5 能够证明自身存在价值的领域。

Sonnet 为 Every 的写作应用 Spiral 生成了大部分文本。Spiral 的计费基于 token 数量，而据称 Sonnet 5 在产出相似内容时，token 用量比 Sonnet 4.6 大约多出 30%。这是不把它直接部署到 Spiral 里的一个重要原因。在另一款内部产品上，替换为 Sonnet 5 后出现了更多的格式错误和更低质量的回答。我们不想花更多钱却得到更差的结果，因此在几天的测试后换回了 Sonnet 4.6，并决定在下一个版本发布之前，让 Spiral 继续运行在 4.6 上。

话虽如此，Sonnet 5 在分析报告这项特定任务上确实表现出色。我们在几款产品上每天运行复合工程中的 /ce-product-pulse 命令——本质上是一份产品健康报告。Sonnet 5 在这方面做得非常好。

对于这类重复性的、范围明确的任务，Sonnet 5 在性价比和性能之间取得了平衡。——Marcus Moretti

登录上线

亲手体验 Every 如何使用 AI。以下是团队成员现场教授我们工作中所用工作流的直播营、工作坊和聚会活动。

即将举行的活动

  • Every IRL（7 月 15 日）：在 Every 布鲁克林总部举办的线下聚会，仅限付费订阅用户，美东时间下午 6 点至 8 点。立即预约。

  • 答疑时间：All Access 构建者（7 月 24 日）：作为即将定期举办的系列活动首场，Every 团队将分享我们如何使用 Builder Pack 中的工具，然后共同处理会员们提出的问题和项目。请带上一件你想构建或改进的事项。此线上活动仅对 All Access 会员开放。

全新的工作职位

首席 AI 官的角色正在增长

越来越多的非科技公司正在将这一职位纳入领导团队，以求理解如何最佳地运用 AI 并衡量其影响。汇丰银行、德勤英国，以及国际律师事务所 Pillsbury 和 Ropes & Gray 近期都宣布了首次首席 AI 官的任命。据彭博法律报道，这承认了该技术“现在已是最高管理层（C-suite）的职责所在”。

企业想要 AI 影响者

为了在极其拥挤的 AI 领域脱颖而出，创业公司正求助于 AI 影响者，或者用 Morning Brew 联合创始人 Alex Lieberman 的话说，是“全栈 AI 创作者”。

目标在于，聘请一个能成为下一个 Andrej Karpathy、Boris Cherny 或 Aaron Levie 的人，通过建立一种类似狂热崇拜的个人追随者来破局。那么，这个角色在实践中是什么样子？用 Lieberman 的话说，“你用 AI 去构建。你谈论你构建的东西。你通过内容教会人们如何使用 AI。”

提示工程师出局，内容工程师登台

失业的编辑专业人员如果想利用自身技能变现，曾经会在 LinkedIn 上搜寻“提示工程师”的职位。而现在，这一类别已经演变成了针对“内容工程师”的招聘——他们是能构建系统来产出高质量 AI 生成文本的写作者或编辑。类似的变化轨迹也正在设计领域发生：公司正在寻找能够构建系统来创建设计组件的人。

策展信息流

我们分享 X 上最喜欢关注的人

特约撰稿人 Katie Parrott 推荐：

  • Ethan Mollick（@emollick），沃顿商学院教授、AI 思想领袖：“他一直活跃在可能性的最前沿，同时也很擅长挖掘可信的学术研究，让技术进展带来的后果显得易于理解。”

  • Zara Zhang（@zarazhangrui），AI 构建者和开源创作者：“她拓展了我对于用技能能做到什么的想象。”

Marcus 推荐：

  • Simon Willison（@simonw），独立开源开发者：“我倾向于关注 X 上那些严肃的工程师，以及那些会揭穿虚假 AI 生产力做秀的人，”Marcus 说。而 Simon Willison——流行 Python 框架 Django 的联合创始人——是你所能找到的最严肃的工程师之一。“他是一位传奇性的工程师，”Marcus 如此评价。

  • Ryan Dahl（@rough__sea），软件工程师：“Ryan 属于同一类人。他创建了 Node.js，现在正在开发 Deno（一个 JavaScript 和 TypeScript 的运行时环境）。”

技术咨询主管 Mike Taylor 推荐：

  • Riley Goodside（@goodside），前 Scale AI 和 Google DeepMind 的提示工程师：“有些人习惯于在 AI 相关事物上保持领先，”Mike 说，而 Riley Goodside 就是其中之一。“他是第一个自称提示工程师的人”，后来去 Google DeepMind 工作了。

平台主管 Willie Williams 推荐：

  • Jeffrey Emanuel（@doodlestein），开源开发者：“他有点疯狂，但也有相当的可能性，他已经活在了未来。他想出了如何驾驭比大多数人使用的多出 10 倍的智能体，并以一种让它们高效产出的方式协同工作。一个恰当的类比是：当别人只有一个手工作坊时，他已经拥有了一家工厂。”

最后一件事

值得点击的链接

核心启示：AI 工具的强大已不是新闻，真正的分水岭在于构建一套精密的运营系统——知道何时调用哪个模型、如何用正式指令修复非正式错误、以及怎样把人机协作沉淀为可复制的工作流。

The Ops Team That Routes Work Across Models 的发芽报告

材料核心

AI 应用正进入新的组织化阶段：团队不再只是“使用”某个模型，而是开始像调度供应链一样，把复杂工作分解、路由到不同的模型（Fable、Codex、Fin），并通过系统化的操作流程和新的职业角色，使跨模型协作成为一项可管理的组织能力。

发芽 01：从“使用模型”到“编排模型”——AI 时代的泰勒主义 2.0

种子

Jalaiyah 的“冲浪模型”表面上是一位运营经理高效使用多个 AI 工具，本质上却是一次精巧的工作分解与路由：审计交给 Fable，校对和追踪交给 Codex，直接对话交给 Fin。这与 1911 年弗雷德里克·泰勒在伯利恒钢铁公司的“铁锹实验”有着相同的基因——把一项复杂工作拆解为最适合工具（或人）执行的最小单元，然后建立标准流程来协调它们。如果说泰勒把体力劳动工业化，那么 Every 的运营团队正在把知识工作工业化。

1911 年，泰勒发现铲煤工人用同一把铁锹铲不同密度的物料效率极低。他按照物料比重设计了 15 种不同尺寸的铁锹，并规定了每铲最佳重量（21.5 磅）。结果，工厂的铲煤成本下降了 60%，工人数量从 500 人减少到 140 人，而个人工资上涨了 60%。泰勒做的最重要的事不是改善了铲煤动作，而是把“铲煤”这条工作流解构成一系列可指派、可优化的任务。

今天，Jalaiyah 面对的同样不是“生成文本”这种笼统需求，而是信息审计、一致性检查、帮助中心撰稿、客服回复模板等一系列可拆解的小任务。她没有要求一个模型包办一切，而是根据每个模型的能力“铁锹”——Fable 能理解长上下文并生成结构化计划，Codex 擅长与现有系统（Notion）交互并完成定向校对，Fin 能扮演可控的客服角色——把最适合的任务分配给最适合的模型。更关键的是，她还在中间层建立了人工“人性化”和审核节点，这正是科学管理中不可缺少的质量检验工序。

这种模式正在被系统化。Waqqas 用 Codex 诊断 Fin 的误判，再将修正后的指令手动注入回 Fin，本质上是建立了一条 AI 客服系统的持续改进流水线。泰勒时代的“最佳实践卡片”变成了可写入的模型指令，Codex 则充当了流程工程师的角色。而 Granola 想做的更进一步：把会议上下文变成任何代理都能调用的“标准件”，让后续的工作路由不再从零开始，而是可以重复使用已验证的上下文模块。这几乎就是丰田生产系统中“标准作业”与“即时代”（just-in-time）信息供给在知识工作领域的翻版。

由此看来，过去两年大家迷恋的“提示工程”像极了早期工匠作坊里的熟练工，靠个人手艺与单个模型对接；而今天出现的内容工程师、模型路由操作者，则是流水线时代的管理工程师。他们关心的不再是一个 prompt 的魔法，而是整个“AI 生产系统”的节拍、换模时间和良品率。

Aha 瞬间

“当知识工作变成可排序的作业，管理者新的核心技能不是使用 AI，而是设计一条能让多个模型稳定运载上下文、持续产出质量的工作流水线——知识工作的泰勒主义才刚刚开始。”

发芽 02：从“提示词”到“内容工程师”——写作作为制造，文字作为零件

种子

原文指出“Prompt engineers are out. Content engineers are in.”，并解释内容工程师是“构建一个系统来生产高质量 AI 生成文本”的人。这背后不仅仅是职业名称的更迭，而是写作活动本体的转变：文字产出正从手工艺式的“创作”，转变为一种类似制造工程的“系统化生产”，其本质是把语言拆解为可组装、可质检、可迭代的零件。

1850 年代，美国军火工业推行的“可互换零件”系统彻底改变了生产方式：来复枪的每一个零件都有严格公差，可以在任何一支枪上替换，不再依赖匠人手工打磨。这直接催生了现代装配线和规模化制造。今天的“内容工程”思想，恰似在文字领域推行同样的原则。

在材料中，Jalaiyah 让 Fable 生成三篇帮助文章、六段 Fin 回复代码片段和 17 个客服回复模板。这些输出并非一篇篇文章，而更像是一套规格明确的零件：帮助文章有自己的模板（零件形状），代码片段有固定的交互边界（公差），客服模板则留有手工代理插入共情的空间（人工组装）。每个“零件”都是为了与其它零件（Notion 文档、客服平台、人工代理）无缝对接，而不只是孤立的美文。Waqqas 从一次失败的客服对话中提取出一条新的 Fin 指令，其实是发现了一个“不合格零件”，并修正了零件规格和检测标准。

这种对文字的零件化处理，需要一套完整的生产系统。过去，媒体和出版业的编辑流程（约稿、审校、排版）虽也是系统，但每个环节高度依赖个体心智；而内容工程则试图将部分心智工作固化为提示模板、评估尺度、MCP 连接和自动重试机制。它很像 1980 年代桌面出版（DTP）革命：Aldus PageMaker 和 Adobe PostScript 将排版和图形变成了可编程对象，设计师从描图纸上手工贴片，变成操作样式表和分色指令。今天的内容工程把“写作风格”“语调”“事实校验”同样变成了可以调参的控制元素。

另一个更近的参照是 Google 的 SRE 实践在内容领域的移用。SRE 不是手动修复每一个服务器故障，而是编写自动化脚本、设定 SLO、建立错误预算，把运维变成软件工程问题。内容工程师则把“持续产出质量合格文本”变成工程问题：定义 what is good（相当于 SLO），建立自动化监控（用 Codex 或测试集检测偏离），并把返修循环标准化（如 Waqqas 的 rewrite-instruction-retest 闭环）。

这揭示出一个深度转变：AI 时代最坚固的竞争壁垒可能不是你的模型多强，而是你围绕文字、设计、代码构建的“零件化系统”有多精密、多可复用。Granola 争夺的“会议上下文可被任何代理使用”，其实是在争夺一种新的标准零件——上下文零件。谁掌握了上下文的标准化接口和持续供应能力，谁就可能成为知识工作流水线上的“台积电”。

Aha 瞬间

“文章已经死去了吗？没有，但它正在被重新发明为一组可互换的语言零件；而内容工程师的工作，是为这套零件系统定义公差、组装线、质量门和持续交付管道。”

你的思考空间

  • 如果组织内部真的开始建立“模型路由”流水线，是否会像微服务架构一样，带来碎片化、调试困难和接口冲突？我们能否借鉴混沌工程，主动为 AI 流水线注入故障来检验韧性？
  • Granola 想把会议上下文变成任何代理可用的资产——这是否意味着未来的企业竞争力之一，是“上下文资产”的厚度和可组合性，就像今天的数据资产一样？
  • 当写作被零件化，人类作者的角色是否从“创作者”变成了“零件规格制定者”和“人工组装者”？这对创造性行业的伦理和美学意味着什么？
  • Jalaiyah 的工作流中，Fable 负责审计和起草，人类负责“人性化”语言，这是否揭示了当前 AI 应用的一条关键铁律：机器人负责逻辑与信息，人类负责信任与共情？
  • 随着模型路由操作成熟，是否会催生出类似“模型路由师”或“AI 流程工程师”的正式岗位？他们的职业发展路径可能是什么样子的？