Every 的业务运营团队，开始让模型处理复杂工作
Every 最新文章展示了业务运营团队如何用 Fable、Codex 和 MCP 处理客服计划、文档审计与规则迭代，真正保留给人的工作是范围判断、质量把关和生产写入。
核心判断
Every 最新一篇公开文章给出的信号很具体：它的业务运营团队已经把模型放进客服计划、文档审计和支持规则维护这些工作里。模型承担的是搜集、核对、起草和归纳，人仍然决定范围、检查语气、确认规则是否真的解决问题。所谓「surf the models」，不是在几个聊天窗口之间随便切换，而是把复杂工作拆给更适合的模型，再把结果接回同一条工作链。1
这比「每个员工都有一个 AI agent」更值得追踪。Every 展示的不是一个炫技 demo，而是一套业务运营方法：让模型先处理信息过载，人再把判断留在真正需要负责的地方。
90 分钟做出客服支持计划
Every 的执行运营经理 Jalaiyah Bolden 需要在几天内为 Every All Access 上线准备客户支持方案。信息散落在大约六个来源里，她把 Slack、Notion 文档、会议记录和上线中的网站交给 Fable，让模型先提出缺失信息，再开始工作。1
Fable 做的事情已经超出问答：它审阅 Slack 频道、Notion 文档和会议记录，访问上线前的网站并点击按钮确认功能可用，还把会议或源文档与页面之间的矛盾标出来。大约 90 分钟后，它交付了一份按优先级排序的行动计划、3 篇面向用户的帮助文章、约 6 条 Fin 客服平台的回复片段，以及 17 个供人工客服使用的模板。1
| 工作环节 | 模型承担的任务 | 人保留的判断 |
|---|---|---|
| 信息整理 | 读取多处资料，找出缺口和相互矛盾的说法 | 决定哪些上下文应该交给模型 |
| 上线核验 | 浏览预发布网站，检查按钮和页面信息 | 判断问题是否真的影响用户支持 |
| 文档初稿 | 生成帮助文章、客服片段和回复模板 | 审阅并「人化」语言 |
| 交付管理 | 用 Codex 校对文档，建立 Notion 追踪表 | 确认负责人和后续进度 |
随后，Every 运营负责人 Arielle Shipper 用 Codex 校对文档，并建立 Notion 追踪表，让团队知道每项工作由谁负责。这里的人机分工很清楚：第一个模型把散乱材料变成可审阅的草稿，第二个模型处理质量检查和协作管理，人负责把结果变成对外承诺。
真正可复制的是反馈闭环
文章里更有用的案例来自 Every 的客户支持经理 Waqqas Mir。他没有在 Fin 出错后重写整套客服配置，而是把错误对话变成一条新的模型指令。一次测试中，Fin 甚至在用户提出需求后生成了文件转换脚本，Waqqas 随后补上一条规则，要求这类请求进入人工处理边界。1
他的流程可以压缩成四步：
- 通过 Model Context Protocol（MCP）把 Codex 接到 Fin，挑出两三条处理错误的对话。
- 让 Codex 拉取完整对话，诊断客服 agent 到底误解了哪条指令。
- 把新的规则手动加入 Fin 的配置，而不是让 Codex 直接修改生产设置。
- 用同类场景重新测试；如果错误再次出现，再把新的对话交给 Codex 定位冲突指令。
这条链路的价值在于，错误不会只停留在一次人工纠正。它被转化成可以再次测试的规则，客服 agent 的配置也因此逐步变得更具体。MCP 在这里不是「让模型自动操作一切」的开关，而是让模型拿到真实上下文，同时把写入权限留在人手里。1
Every 也没有把新模型一视同仁
同一篇文章还披露了 Every 对 Sonnet 5 的实际使用结果。Spiral 继续运行在 Sonnet 4.6 上，原因是 Every 认为 Sonnet 5 对相近输出大约需要多消耗 30% 的 token；在另一个内部产品里，换用 Sonnet 5 后还出现了更多格式错误和更低质量的回答，团队测试几天后就换了回去。1
但 Sonnet 5 并非完全没有位置。Every 的产品团队发现，它适合每天运行的
/ce-product-pulse 产品健康报告，这类任务范围窄、重复性高，性能和成本比较容易平衡。这个判断很朴素，却比「新模型一定全面替代旧模型」更接近真实的产品决策：模型价值取决于任务边界、输出格式和运行成本。对使用 AI 的团队来说，模型评估至少要同时看四件事：任务完成质量、格式错误、token 或调用成本，以及它能不能稳定地重复完成同一类工作。只看一次对话的惊艳程度，结论通常会偏得很快。
从客服规则到工作上下文
Every 在同一期内容里介绍了 Granola 联合创始人兼 CEO Chris Pedregal 的观点。Granola 早期以会议记录起家，但它现在想处理的是会议前后的工作，并让会议上下文能被用户选择的其他 agent 使用。公司计划在未来几个月继续改进 API 和 MCP。1
这和 Every 自己的业务运营案例指向同一个问题：agent 的能力越来越强之后，瓶颈会落在上下文是否完整、规则是否可维护，以及结果能不能回到原来的业务系统里。Fable 需要 Slack、Notion、会议记录和预发布网站，Codex 需要 Fin 的真实对话，Granola 则试图把会议上下文交给更多 agent。模型本身只是其中一环，工作上下文才决定它能不能把任务做完。
给团队的三个落地点
- 把一次性任务改造成可重复的流程。先记录输入、输出和失败案例，再决定哪个环节值得交给模型。
- 给模型足够的上下文，但把生产写入权限分开。读取、诊断和起草可以自动化，改规则、发公告、改变用户体验仍然要有人确认。
- 用失败案例更新指令。每次错误都应该留下可复现的测试场景，否则团队只是在一次次手工救火。
Every 这篇文章最值得带走的不是「Fable 很强」或「Codex 更适合校对」，而是它把模型选择放回了业务流程里。模型负责把信息过一遍，人负责决定哪些信息可以变成承诺；错误则回到规则中，成为下一轮测试的输入。
资料边界：Every 原文后半段关于 chief AI officer、full-stack AI creator 和 X 账号推荐的内容位于付费墙后，以上未作延伸概括。
相似内容
- 登录后可发表评论。