为什么我们从 Claude Code 切换到 Codex
访谈概述
在本期访谈中，Every 创始人 Dan Shipper 与其增长主管 Austin Tedesco 探讨了人工智能代理（Agent）正在如何重塑知识工作者的日常工作流。两人分享了他们从最初使用 Claude Code（命令行界面）到全面转向 OpenAI 的 Codex 桌面应用的经历。
访谈的核心观点是：“AI 智能代理管理界面（Agent management interface）”正在成为知识工作的新一代操作系统。如果一个 AI 能在你的电脑上写代码，它也能完成任何其他的知识工作。Austin 详细演示了他如何将 Codex 变成自己 80% 工作时间所在的主力工具，涵盖了从自动化处理 Gmail、Slack 和 Notion 的日常琐事，到撰写市场推向（GTM）计划，甚至重建公司实时 KPI 仪表板和协助招聘等多样化的非工程类任务。此外，他们还讨论了在使用 AI 生成内容时，人类审查环节的重要性，以及如何在繁忙的工作中平衡“探索新 AI 工具”与“完成日常任务”的冲突。
专用词语翻译列表
| 英文原词 | 中文翻译/解释 |
|---|---|
| Agent | 智能代理/智能体（指能够自主执行任务、与其他软件交互的 AI 程序） |
| Codex / Claude Code / Claude Co-work | 指代两家主要 AI 公司推出的桌面级或命令行 AI 辅助编程/工作平台 |
| Vibe coding | 意念编程/感觉编程（科技圈黑话，指非技术人员通过自然语言提示，依靠 AI 模型直觉性地生成应用或代码） |
| CLI (Command Line Interface) | 命令行界面 |
| GTM (Go-to-market) plan | 市场推向计划（产品上市营销策略） |
| KPI (Key Performance Indicator) tracker | 关键绩效指标追踪表 |
| MRR (Monthly Recurring Revenue) | 月度经常性收入（SaaS 等订阅制业务的重要指标） |
| PR (Pull Request) | 代码合并请求 |
| Compound Engineering | Compound Engineering（文中提到的一款由开源社区或其团队开发的 AI 插件/工作流规范，包含自动审查、安全检查等步骤） |
访谈正文
引言与开场
Dan Shipper：如果在三到六个月前，Codex 简直是垃圾。如果 OpenAI 的人在听这个播客，我百分之百坚持这个说法。但如果你在电脑上拥有了一个强大的通用编程代理（Agent），它实际上非常适合任何类型的知识工作。如果它能独立编写软件，它就能独立完成任何形式的知识工作。现在，我每天一上线，第一个打开的就是 Codex。它能从 Gmail、Slack、Notion、Stripe 以及我们所有的数据源中提取我需要的一切信息。
我现在大约 80% 的工作时间都是在它里面度过的。压倒性的原因就是，这个应用本身做得实在太好了。一种全新的操作系统正在诞生，它决定了你将如何、在哪里完成工作，而这种“代理管理界面（Agent management interface）”就是未来。
大家好，欢迎来到 Codex 营地——探索 Codex 在知识工作中的应用。很高兴大家能来，特别高兴能在 GPT-5.5 发布的这个具有纪念意义的日子里举办这次活动。希望大家都一切顺利。我是 Dan，今天和我在一起的是我们的增长主管 Austin。Austin，给大家打个招呼吧。
Austin Tedesco：大家好。
从“高级工程师专属”到“知识工作者的日常主力”
Dan Shipper：我们非常激动能举办这次活动。就像我说的，三六个月前的 Codex 简直一塌糊涂（如果 OpenAI 的人听到，我绝对坚持这个看法）。那时候它纯粹是为高级工程师做“结对编程（Pair programming）”设计的，它会跟你抬杠，让你觉得自己很蠢，它有点像个没感情的机器，毫无情绪智商（EQ）。
我认为 OpenAI 从 GPT-5 开始有个有趣的策略或理论：他们以为大家在 ChatGPT 里进行“意念编程（vibe coding）”，把所有杂活都放在那儿；然后高级工程师会用 Codex 来做所有专业的编程工作。为了防止它作恶，他们把它关在沙盒里，对模型进行了很多限制。
但结果是，Anthropic（Claude 的母公司）想明白了：在你的本地电脑上拥有一个好用、快速、聪明且具备高情绪智商的模型，并且它能直接访问你的电脑文件，这对程序员来说是绝佳的体验。这意味着你可以抛弃很多旧的编程环境，不再需要亲自敲代码，你只需在终端输入指令，它就会开始工作。
进而 Anthropic 发现：如果你的电脑上有一个出色的通用编程代理，它实际上也非常适合任何种类的知识工作。 如果它能独立写软件，它就能独立做任何知识工作。于是，我们开始看到一种转变——过去只有程序员在 Claude Code 里委托任务，现在任何类型的知识工作都被委托在 Claude Code、Claude Co-work 等环境里进行。
起初 OpenAI 还坚持他们的分类：“哦，你们在 ChatGPT 里搞意念编程。”但我认为他们看到了 Claude Code 的发展趋势。在过去的大约三个月里，他们对 Codex 进行了极其硬核的战略转向：它从一个纯粹为高级工程师做结对编程的工具，变成了现在这种——我愿称之为进行此类知识工作的“日常主力驱动器（daily driver）”。
我现在用 Codex 做所有事情，从深度的工程任务到写作，再到招聘。我其实做大量的招聘工作，它在这方面非常拿手。我待会儿会给大家举几个例子。
他们弄明白了这一点：在你的电脑上拥有一个具备写代码、访问文件系统、浏览网页能力的通用代理，并把它封装在一个桌面应用里，是知识工作的理想下一步。我认为他们目前做出了这个方向上最好的版本。
现在局势逐渐清晰了：一种新的操作系统正在形成，它决定了你如何以及在哪里完成工作，这就是这种代理管理界面。
不管是 Anthropic 的 Claude Code / Co-work 桌面应用，还是 OpenAI 的 Codex，或者是 xAI 最近收购的 Cursor（还有 Google，虽然他们有 Anti-gravity，但还没人真的拿来做这个，不过我想他们迟早也会跟进的）。这就是各家大模型公司目前正在角逐的赛道——打造基于编程代理的知识工作桌面端入口。
对于我们这些享受这些工具红利的人来说，在这些工具之间灵活切换是非常重要的。比如使用 Codex，让你提前感受一下在“代理优先（agent-first）”的世界里工作是什么体验。因为一旦代理成为你访问和使用软件及互联网的主要方式，它将解锁很多以前不可能实现的功能。你可以派你的代理去和其他软件交互，然后带着结果回来。
这就是我们正在步入的世界。你的代理就是你工作的接口。这其实非常有趣且酷炫。所以我想请 Austin 过来一起聊聊。因为 Austin 是我们的增长主管，大概三四个月前，他经历了真正的“代理觉醒时刻（agent pill moment）”。
我记得你当时在周一早上跟我说：“哦，我整个周末都泡在电脑前，一天 12 个小时，哪儿也没去。”因为你在用 Claude Code。你开始用它来处理一个增长营销人员会遇到的各种知识工作。但在过去几周，当我们开始使用 GPT-5.5，而且我一直催你去试试 Codex 后，看起来你已经把所有的工作都转移到了带有 5.5 模型的 Codex 上。所以我认为你是最适合谈论这些代理管理界面如何改变工作流，以及你为什么喜欢 Codex 的人选。
接下来我很想看看你实际 Codex 工作流的演示，从你的视角来看看这一切。
Austin Tedesco：好的，听起来很棒。是的，我的“代理觉醒时刻”大概是在去年 12 月到今年 1 月的时候，我花了一整个星期深度体验 CLI（命令行界面）版本的 Claude Code。
Austin 转向 Codex 的经历
Austin Tedesco：我把它与我的工作和个人生活中的一切都连接起来。我使用 Warp 作为我的 CLI 终端。我发现它能自动处理的东西、能代劳的事情，以及它作为“思维伙伴”让我的工作变得更好的方式，让我觉得：“这就是我处理知识工作唯一想要的方式了。”无论是战略思考、数据分析还是发布营销文案，这些通常会让你在一天中分散在各个不同的 App 里的工作，现在都可以集中处理了。
大概在 2 月份的时候，你不断地向我推销 Codex，说它有哪些好。在 Every，只要团队里有人这么推荐，我通常都会去试试。而且我喜欢挑战自己，去尝试一些更偏工程的任务，看看这些模型到底能做什么。所以我试图在 Codex 里纯靠“意念编程（vibe coding）”给自己做一个个人 App，这也是你当时说它很擅长的地方。
我最初的反应是：“我确实觉得它在建 App 方面更强了，但我实在受不了它，因为从来没有任何东西像两个月前的 Codex 那样让我觉得自己如此愚蠢。”
我习惯使用 Compound Engineering 插件（这是 Kieran Lawson 为我们开发的一个插件，适用于几乎所有事情，包括知识工作，特别是在尝试构建 App 或向网站提交 PR 时）。
当时我让它做一个计划，它在计划里提出了三个关于方向选择的问题。但我完全不知道它在说些什么。我问它：“这三个选项具体什么意思，你能详细解释一下吗？”它的回答基本上是：“问那么多干嘛？为什么不直接照我推荐的做？”
所以我找到了一种平衡：对于所有的工程任务，我坚持用 Codex，因为我确实喜欢它的结果，哪怕我不喜欢在里面工作；但对于知识工作，我 80% 还是倾向于在终端里使用 Claude Code。
但是一个月前，当我们拿到新的 GPT-5.5 模型时，我最先感受到的是：至少对于我所做的这类知识工作来说，最新的 Opus（Claude）模型和最新的 GPT 模型已经达到了平分秋色的地步。有一些事情 Opus 做得更好，有一些事情 Codex 做得更好。
对我来说感觉甚至更具体一些。比如除了设计方面（我仍然非常信任 Opus），这更像是一种主观偏好。但对我而言，真正的差异在于：作为一款纯粹的桌面 App，Codex 桌面端的速度和强大程度是无可比拟的。 相比之下，Claude 桌面端就不够看了。我从来没法让 Co-work 为我顺畅运行。我想这是因为我已经被 Codex 极其流畅的体验“宠坏”了。
Codex 速度太快了，它的子代理（sub-agents）太好用了。它为我建议和部署自动化的方式，让我无法想象不再使用它。如果有哪周 Claude 桌面端突然变得跟它一样好，我也不会惊讶；但就目前而言，当我在工作日登录时，Codex 是我第一个打开的东西。
它整合了我需要的一切：Gmail、Slack、Notion、Stripe 以及我们所有的数据源。今天早上我突然想起来：“哦对，我们需要为今天的营地活动准备一个流程表（run of show）。”我就直接给 Codex 发消息：“做一个活动流程表。”
它确切地知道该去哪里找信息，因为我们已经在聊天记录里讨论过今天的主题了。它自动把流程表推送到 Notion，并发送到 Slack，简直完美。我大概 80% 的时间都在这里工作，绝大部分是因为这个 App 本身做得太好了，而现在模型的智能程度也足以让它成为我的日常主力。
Dan Shipper：我完全同意。如果有人问我们讨论的是 App 还是 CLI？我们讨论的是桌面 App。你说得对，两家公司都看到了这个终局，都在朝正确的方向推进。在未来一段时间内，这将是一场赛马比赛。每隔几周或几个月，就会有一家领先，推出一些令人惊艳的功能，然后竞争对手（比如 Anthropic）会在几个星期后发布更新，至少达到平级甚至超越，它们会不断交替领先。
最终这种疯狂的迭代会慢下来，你会看到不同的生态系统形成。但目前，在它们之间切换其实还挺容易的。不是毫无成本，但非常简单。比如你可以直接让 Codex：“嘿，去把我 Claude 里的东西都抓取过来。”它就能办到。
Austin Tedesco：确实如此。我现在人在纽约（我通常住洛杉矶）。我那些从事知识工作的朋友经常问我该用什么工具。他们全都是 Claude Code 或 Claude 桌面端的死忠粉。当我告诉他们我已经完全转投 Codex 时，他们脸上都露出了惊恐的表情，仿佛在问：“我真的必须得换吗？”我当然告诉他们不用强求，但我真的建议他们试试。
因为知识工作者有了 Claude 桌面端后，已经觉得是颠覆性的体验了。告诉他们 Codex App 可能还要好上 30% 到 40%，他们会觉得：“哇，那得花好多学习成本。”我们稍后可以聊聊我是怎么迁移的，其实非常简单。我很乐意分享屏幕给大家看看。
Dan Shipper：好啊，分享你的屏幕吧。我同意你的看法，这更多是一种“我又要学新东西”的情感抵触，但实际操作起来非常相似。我很想看看你的工作流。
Austin Tedesco：酷。这就是 Codex App。快速带大家逛一下（我想很多人已经看过了）。我非常喜欢它的一点是：它的组织结构比 Claude 桌面端好太多了。我可以建文件夹，里面放着持久连贯的聊天记录，随时可以进去查看。
Austin 是如何设置 Codex 的（文件夹、密钥与审查代理）
Austin Tedesco：对我来说最大的区别是，由于它更适合工程任务，我偶尔需要为我们的产品提交 PR。这时我不需要在 Claude Code CLI、Claude 桌面端和 Codex 之间来回切换。我就在这个界面里，刚才还在完善我们的 KPI 追踪表，下一秒我就可以切换到下方的标签页，为我们的“Plus One”项目提交一个代码 PR。
上周 Claude 桌面端发布更新时我试用了一下，我给它的压力测试是：在不同的聊天窗口，为我们的新产品制定一个市场推向（GTM）计划，并同时提交一个代码 PR 给 Sparkle。结果它极其笨重和缓慢。但当你在 Codex 里做这些时，它就是非常流畅和迅速。一旦你体验过这种流畅感，就很难再回头了。
所以我建了这些不同的文件夹：有些用来放我随便建的意念编程小 App，有些是我个人的开源代理（Open Claw），我可以在这里操控它们。最核心的包含所有日常聊天的文件夹叫“Every Growth OS”。
这其实就是一个装满各种 Secrets 和 API Keys 的文件夹，所以它连接着我们公司用的所有工具。里面还有一些项目说明文件，向模型解释我们公司的业务是什么、我们在乎什么、我们喜欢怎么合作。
里面还有一些受 Compound Engineering 启发的“审查代理（reviewer agents）”。原版的 Compound 审查步骤（比如检查代码安全性和前端设计）对我做战略计划帮助不大。所以我分叉（fork）出了适合知识工作的版本，比如审查方案是否与公司战略对齐、数据准确性如何。将这些内置在文件夹里意味着，当我在制定计划时，我能得到模型极具针对性的审查反馈。
我先展示一下我是如何起步的。昨天我给我们的主编 Katie 演示了推荐的 Codex 入门提示词。
(此时穿插了一段口播广告，赞助商为 Bilt，一家可以通过支付房租/房贷赚取积分的平台)
Austin Tedesco：我放大一下屏幕。通过 Codex 的插件工具，我手动点击连接了我每天使用的工具，比如 Gmail、Slack 和 Notion。
然后，我进入由 Claude Code 构建的一个名叫“Everyplace OS”的新聊天窗口。那里有一个 Claude 的 markdown 配置文件，保存在本地并同步推送到 GitHub。当我在 Codex 里开始工作时，我直接打开那个项目。我启动了一个 Compound Engineering 的“头脑风暴”工作流，因为我习惯在尝试新事物时，先让一个强大的前沿模型作为思考伙伴来帮我理清思路。
利用 Codex 对 Gmail、Slack 和 Notion 的自动化进行头脑风暴
Austin Tedesco：我基本上对它说：“去看看我最常用的这几个工具（Notion、Slack 和 Gmail），想出一些能帮我提高工作效率的自动化方案。”
我发现，与其自己绞尽脑汁去想，不如让一个极其聪明的模型告诉我：“你可以这么用它，它能帮你做这些事。”这是我最喜欢的起手式。
Codex 看了一下我和公司目前的状况，然后给出了建议。我觉得这些建议非常好。比如它提到了“跟进雷达（follow-up radar）”。很多做知识工作、做合作拓展或社交媒体营销的人都会遇到这个问题：有海量的信息从不同渠道涌向你。如果有一个工具能帮你做优先级分类呢？
当我们要举办像今天这样的活动时，有很多活动部件，它能充当一个类似“命令传感器”的角色。
就像它提到的招聘：我们没有用 Ashby 之类的专业招聘工具，所有的流程都在 Notion 里流转。像 Codex 这样的代理完全可以帮我们处理大部分的候选人流转和追踪工作，你只需告诉它把这些自动化就行了。
在这个演示中，我没有给它太多具体的反馈，我就说“看起来不错”。接下来是我一直对 Codex（以及这类模型）印象最深的地方：它说“太好了，我为你生成了这个自动化流程。”
我发现它们就是运作得出奇的好。基本上不需要什么微调，它就是那种“我每天都愿意用并且真的在用”的工具。这里有一套基于它对我的了解而生成的指令集。我可以修改它运行的时间、添加额外的信息、把它连接到其他工具，但通常它就是开箱即用。
我现在有一个在用的自动化：每天工作结束时，它会整理所有我还没有回复的信息，草拟好回复，然后我们可以一起过一遍看看说什么。或者实际上，我只需要在 Slack 上点个大拇指的表情，它就会自动帮我发出去。它有点像一个“笨但很听话的代理”，每次都会做正确的事。
当然还有聪明的代理，比如我们在做的一个项目，你可以和它来回探讨，它更像是一个具有创造力的战略伙伴。Codex 在构建这两类代理上都很擅长。如果有人问“我想看看这玩意儿能怎么帮我做知识工作”，我会强烈建议从“头脑风暴自动化”开始。你会对它的速度感到惊讶，然后你会惊呼：“哦，我开始懂它能干嘛了。”
Dan Shipper：这太酷了。你的 Codex 玩得比我高级多了。（笑）我获得了不少灵感。
我想在这里稍微停一下。通常我们把提问环节放在最后，但我觉得现在听听大家的疑问会很有趣。请举手。
Margaret（观众）：你们好，我是 Margaret，来自 Plymouth。我的问题是，你的“审查步骤（review step）”具体是怎样的？在提示词里说“未经明确批准不要发送或修改”，实际操作中，你是如何批准的？是让它推送到你手机上，还是怎样？
Austin 是如何在 AI 草拟沟通内容时进行人工审核的
Austin Tedesco：对于这个，我个人的偏好是（昨晚我和一个朋友吃饭，他也自己琢磨出了同样的方法）：我绝大部分的工作都在 Codex 里完成（比如起草和设置），但我喜欢把最终的审查步骤放在“外部应用”里。
比如，它会草拟好所有的 Slack 消息，然后我去 Slack 里的“草稿（draft）”标签页，逐个检查并发送。这能让我的大脑清醒一下：“好的，我确认这就是我想发给一个真人看的内容。”邮件也是同理。它在 Gmail 里创建好草稿，我再打开 Gmail 去检查和发送。我知道有些人直接在终端里就确认发送了，但我更喜欢战略计划推送到外部，比如推送到 Proof（Dan 做的那个对代理友好的 markdown 编辑器）或者 Notion 里。
我喜欢在人类接触这些内容之前，暂时离开这种“代理自动化空间”，在另一个软件里做最后一遍检查。这几乎是我唯一需要离开 Codex 应用的时候。
Alex（观众）：嗨，我叫 Alex，是一名音乐人。我经常接演出，总会收到客户的邮件。我得把演出线索和那些新闻简报等垃圾邮件分开。你怎么确保提示词能让 Codex 安全地保留那些需要我个性化回复的邮件？我只想确保不会因为 AI 乱发邮件导致我丢了赚钱的机会（笑）。
Austin Tedesco：就我个人而言，我非常依赖 Cora——也就是 Kieran 在 Every 开发的一款 AI 邮件助手。现在 Cora 有了 CLI 和 API 接口，这非常有帮助。我可以在 Codex 里告诉 Cora（它在管理我的邮件过滤规则）我想要什么、我在乎什么。
不管你用不用 Cora，我的建议是一样的：让代理来“采访”你，去理解你想要的规则是什么。 我通常会用语音转文字应用（比如 Monolog）做一次“大脑倾倒（brain dump）”：“我现在的邮件一团糟，我想梳理一下。”
如果你想在 Codex 里直接建立一个自动化规则，它同样能运作得很好。你可以说：“这些是我不想错过的邮件，绝对不要替我发送任何东西，只能存为草稿。我想在每个工作日下午 3 点集中处理邮件，请你去搜索并生成子代理（sub-agents）来帮我分类。”（我经常让 Codex 生成子代理去跨工作流处理任务。）
然后让它带着计划回来。你可以查看它的计划，看看它是否准备自动归档某些可能帮你赚钱的邮件。在这里你可以微调它。
我的另一个做法是，我用 Todoist 来管理所有的任务提醒。它也连着 Codex。我只需给 Codex 发个消息：“给我的日程表加个提醒，72 小时后检查一下这个新的邮件自动化规则运行得怎么样，做个审计。”
看看它到底归档了些什么。我发现这非常有帮助。我很高兴我们的产品团队做了大量的工作，让我只需向 Codex 发出指令，就能随心所欲地操控这些应用程序。
Dan Shipper：谢谢 Alex。我想补充一点，我们内部做了一个托管的开源代理产品叫“Plus Ones”。Austin 开始用 Codex 和 Claude Code 来设置他的 Plus Ones 代理，发现体验极佳。
与其提供一个复杂的后台设置面板，让用户手动点击一堆按钮、输入大量上下文信息，不如我们直接通过 CLI 将 Plus Ones 暴露给 Codex。你只需要跟 Codex 聊天，它就会把你电脑里的所有知识和过去的对话记录提取出来，扔给 Plus Ones 去完成设置。这证明了当你假设每个用户都能访问这样的智能代理时，整个产品形态都会改变。我们不再需要复杂的设置仪表板，不需要繁琐的新手引导，甚至不需要手动收集上下文，Codex 会免费把这些都做好。
从产品高管 Claire Vo 处获得灵感，利用 Codex 构建专业代理矩阵
Austin Tedesco：我最喜欢的一个用例，是受到了产品高管 Claire Vo 在 Lenny 的播客中一段采访的启发。她说当她停止试图打造一个无所不能的“全能超级代理”，转而构建一套由 6 个分工明确的专业代理组成的矩阵时，她迎来了巨大的突破。
我当时就去 Codex，打开我那个包含各种配置和 API Key 的主文件夹。我直接把 Claire 的采访文字稿发给它，说：“我也想这么做。考虑到你对我工作和职责的了解，制定一个计划，向我们的 Slack 里部署 6 个专业代理。考虑一下有些可能只需要用简单的 Notion 自定义代理，有些可能需要更聪明的逻辑。拿个方案出来。”
它给出的计划非常棒，我稍微微调了一下。现在我的 Slack 里就有了一套包含 6 个代理的矩阵，它们配合得天衣无缝。
当然，目前的私人代理还是会崩溃的。你需要接受这点。但真正强大的地方在于，你不用再去跟后台配置死磕，生闷气。我只需去 Codex，截图或者直接提及其中的错误信息，告诉它：“去找出这次对话中发生的这个愚蠢错误，然后修好它。”它能非常出色地重构代理的逻辑并修复问题。这完全改变了你的工作方式。
Dan Shipper：我非常同意。我想展示一个我认为对知识工作者最有帮助的功能。可以说这是我职业生涯中一直梦寐以求的东西，它解决了我最头疼的知识工作痛点之一。
将会议记录和 Slack 讨论提炼成市场推向（GTM）计划
Dan Shipper：我们正在为一个新产品（Plus Ones）筹备一个非常正式、公开的市场推向（GTM）发布。我们在 Slack 里和内部会议中进行了大量的讨论：“我们的上市策略是什么？我们要怎么做？”
我们已经完成了那些“只有人类才能做”的工作，比如提炼营销卖点、商业案例、叙事定位等。并不是所有内容都已经完善，但它们已经分散地存在于各处。
我原本打算这周专门抽时间来写这份 GTM 计划文档。但这周突发事件太多了，又要面试候选人，又刚好碰上新 GPT 模型发布。有一天（应该是周二），在两个会议之间的几分钟空隙里，我这样向 Codex 发出提示：
“嘿，大部分工作我们已经讨论过了。在我们公司的 Notion 里，所有的会议转录文本都在那儿。我们在 Slack 里也聊了很多。我有一个我非常喜欢的 GTM 计划模板。你能直接把这份计划做出来吗？”
在我的预期里，它也许能做到 6 分或 7 分，然后我可以继续微调它。我要求它：“先通过头脑风暴流程，生成一个 Proof 格式的草稿文档，我看看你做得有多接近。”
这里有一个小插曲，除非我特别强调，否则它经常会忘记去查看我们日历上即将发布的帖子和活动。所以我赶紧补充了一句：“去查一下所有已排期的活动，因为我需要把相关文案也写进 GTM 计划里。”
随后它生成了一个 Proof 格式的草稿。我扫了一眼——这还是在两个会议之间挤出的 5 分钟——我惊呆了：“这做得太好了。你已经把主体架构搭得差不多了。再融入一项小修改，然后直接把这份计划推送到 Notion 里去吧。”
它推送到 Notion 里的计划，我阅读后觉得已经完成了 80% 到 90%。这并不是因为我依赖模型来“发明”我们的 GTM 策略；而是我依赖模型去翻阅我们之前关于 GTM 策略的所有口头讨论和碎片化思考，把它们拼凑在一起，然后进行审查。
这里面包含了大量的上下文加载：它知道我们的目标理想客户画像（ICP）是什么，知道我们的目标是什么，知道我们对叙事定位的看法。在这一切成为可能之前，我唯一的选择要么是封锁一整天的时间坐下来写；要么就是等到晚上六七点钟下班后，熬个通宵来写。
这对我来说是一个彻底的颠覆。而且这不仅是给人看的。当我把这份计划发给团队时，对人类来说它是易读的；但更关键的是，因为一切都在一个结构清晰的文档里，我们的 COO Brandon（他深度参与这个产品），可以直接问他的代理：“告诉我 Austin 的计划是什么？帮我总结一下商业逻辑。”
Brandon 需要根据这份计划来建立定价模型，他可以基于这份计划和代理协作。在以前，我得花大量时间去抠字眼，去想这份提案在汇报给 CEO 时排版是否合适，现在我全放弃了。我只在乎：“这份计划本身足够好吗？如果 CEO 批准的话，他的代理能读懂这份计划吗？”
它让我工作得更快，让工作成果更好，让我不必再去操心那些无关紧要的蠢事。对我来说，这是一种强大得多、也更有趣的工作方式。
Dan Shipper：我完全同意。你说的点太有意思了。第一点就是：让“相互发送代理编写的文档”成为常态。
有很多所谓的“AI 写作工具”宣称要“用你的语气写作”。但我认为另一种情况是：只要承认这是 AI 写的就行了。 在很多情况下，我其实更愿意读你的代理写的文档，而不是你自己写的。因为我知道，让你的代理把所有的思考提炼成一种清晰可读的格式，对你来说更容易。
我关心的只是：你是否为这份文档背书？你是否深入思考过里面的内容？如果我挑出其中某个具体要点来问你，你是否能证明你已经考虑周全了？
只要我们之间建立起了这种信任，我绝对更喜欢阅读“代理版本”的报告。
Austin Tedesco：完全赞同。我的朋友 Rachel Karten（她经营着一份关于社交媒体的知名 Newsletter）本周写了一篇很好的文章，谈论社交媒体从业者的挫败感。大家觉得好像所有内容都必须通过 AI 处理，导致质量下降。其中一个原因就是你说的这个矛盾点：你到底为哪些内容负责？如果文档经过 AI 润色，可能你的经理甚至都不知道里面到底写了什么。
我喜欢在 Every 工作的原因之一是，当你拿着一份 AI 提前写好的文档来开会时，大家的期望是：你会为里面的每一句话负责。如果有人问你文档里的某个细节，你回答“哦，我都不知道那写在里面”，那你就彻底暴露了自己敷衍了事。
同时，我们也在不断投资于我们的技能、工作流和工具，以确保这种尴尬不会发生。比如我在项目中设定了严格的规则：“不要在文档里添加任何我在其他语境中未曾表达过的观点。你可以把你的建议发在聊天框里，但不要直接写进最终文档。”当然，当上下文变得非常庞大时，模型有时会违背这些规则，这也是为什么我总是把最终的审批步骤留在 Codex 外部、让真实的人类同事看到之前来进行。
Dan Shipper：你说得对。在日常工作中，很多时间都花在了“将你已经完成的思考，转化成别人可以阅读和消费的格式”上。真正重要的是“思考”本身。
当然，写作本身也是一种很好的思考方式，对于某些特定的事情你确实需要亲自去写。但对于像“公司战略”这类东西，大量的思考是在会议里通过口头讨论完成的。
有时我需要写一些像“过去三年半 AI 发展的回顾与对未来的预测”这样的长篇大论。坐在那里干写太难了，但“口述”就容易得多。我就开着录音一通说，然后利用 AI 帮我理清我到底想表达什么。
在这些场景下，把你所有的话录下来，开放所有权限给 Codex，让它直接吐出一份战略文档，你再过一遍去确认是否同意——这极其节省时间。特别是对于像我们这样，每天要开很多会，根本没有大块连续时间去写战略长文的人来说。它帮你填补了时间缝隙，完成了大量繁重的梳理工作。我爱死这个功能了。
在 Notion 中构建代理可读取的实时 KPI 追踪表
Austin Tedesco：我也非常喜欢。在进入提问环节之前，我想再展示一个用例。这是一个融合了知识工作和轻度工程开发的场景，如果没有这类工具是不可能实现的。
我一直在重建我们的每周 KPI 追踪表。我们在 Every 有很多不同的业务板块，要把所有这些数据点汇总到一个传统的工具（比如 PostHog）里作为单一真相源（SSOT），是非常困难的。我们需要一个既面向人类，又面向智能代理的仪表板，并且它要实时更新我们关心的所有指标。
我一直没找到一个好方案能只靠 PostHog 就搞定。所以我一直在试图在 Notion 里重建我们的 KPI 表。目标是：任何人都可以让他们的代理去看这个表，立刻知道我们新的付费订阅转化情况如何、页面浏览量如何、iOS App 的月度经常性收入（MRR）如何，与计划目标的对比等等。
这不仅对人类工作有帮助，更是实现“代理自动化工作”的关键基石。因为如果你的代理看到我们在某个本该拿下的 SEO 关键词上落后了，而且数据源是绝对可靠的，代理就可以直接去发布一堆登陆页（Landing pages）来帮我们抢占这个关键词的流量。
所以我在 Codex 里死磕这个对我来说很复杂的工程流：让我们一起在 Notion 数据库里建这个表，确保所有代理都能访问。我试了很多版本。第一版是：“Codex 你能一步到位（one-shot）吗？你有所有的 API Key，我也可以给你解释我们是怎么计算 MRR 的。”
结果每次都会出现偏差，格式、数字或者统计口径上可能有 5% 到 10% 的误差。但我们的 MRR 数据连 5% 的误差都不能有！一个连基准真相源都有 3% 误差的企业是没法正常运转的。它必须百分之百准确。
这逼迫我做了一件事（虽然现在回想起来觉得自己很蠢，但也是必须的）：我让 Codex 逐列（column by column）、从头到尾地确保每一列都完美无缺。因为这是我们可靠地运营和发展业务的唯一方式，也是我们敢于放手让代理根据 KPI 表采取行动的前提。
有趣的是，我居然因为“模型不能直接完美替我搞定一切”而感到沮丧——这恰恰是因为这些模型变得如此强大，以至于我理所当然地对它们抱有如此高的期望。
这个过程涉及使用 Notion 的 Worker 工具、构建常驻后台的工具调用（拉取 Stripe 和社交媒体数据）、编写各种脚本。老实说，我根本看不懂那些代码，但我懂输出结果。我知道结果是一个每 6 小时自动更新所有业务指标的 Notion 数据库。
这太爽了，我不需要花钱请顾问，也不用占用我们数据工程师的时间。我只需要向模型发出指令，并确保我理解那些业务指标的计算逻辑，我自己就能搞定。
Dan Shipper：这太惊人了！我等不及了，下周一它能上线吗？
Austin Tedesco：绝对没问题，周一就能用。我感觉棒极了。事实证明，弄清楚你到底赚了多少钱、增长了多少，本质上是一个哲学问题（笑）。你必须去设定具体的统计口径。
Dan Shipper：确实。要客观地说明你到底赚了多少钱，几乎是不可能的，你只能选定一种统一的口径坚持下去。
在进入提问环节前，我还想分享一个知识工作场景，它彻底颠覆了我的认知：招聘。
利用 Codex 辅助招聘
Dan Shipper：我们最近在大量招人。我们在找一位学习与发展（L&D）的主管，也就是帮我们做课程培训的人。纽约有一家叫 General Assembly (GA) 的公司，他们过去在教人们技术（比如编程、设计）方面做得非常出色。
我的理论是：如果我们要招人来打造我们的课程，那些曾在 GA 早期工作过的人可能会非常合适。
于是我直接对 Codex 说：“嘿，你能帮我找一份 GA 前员工的名单吗？我正在招 L&D 总监。然后，请你帮我筛选出那些后来进入了 AI 领域的人。”
它直接就给我列了一份名单！我点开第一个人的主页，心里想：“这家伙简直太完美了。”然后我发现他还在 Twitter 上关注了我，于是我直接私信了他。
我不知道我们最终会不会录用他，但这绝对是一个让我直呼“卧槽”的灵感时刻。通常我们做招聘时，需要在海量的简历中进行人工筛选，试图找到合适的人。虽然这种方式依然不可或缺，但在需要“主动出击拓展”的时候，AI 绝对能以不可思议的效率帮你找到草垛里的那根针。我极力推荐大家试试这个功能。
(后半部分为提问环节，涉及关于如何通过 API Token 获取、订阅 Every 的广告，以及具体到回答用户如何用 Compound Knowledge 定制知识工作审查流程，在此略作删减，保留核心问答意义即可。)
Rich（观众）：我看到你在工作流中使用了 Compound Engineering。你是直接用了现成的插件，还是做了修改？当你处理非代码生成任务时，它在哪些地方表现好或不好？
Austin Tedesco：其实大多数情况下没必要自己去分叉（fork）一版。我很长一段时间都是直接用原版处理所有的知识工作。直到大概两个月前，我发现它内置的审查步骤太侧重工程了——比如审查代码安全性、前端设计。我就想，这可是个市场推向计划啊，代理居然跑去审安全性了。
所以我在我们的公开 GitHub 上分叉出了一个专门的版本叫“Compound Knowledge”，移除了纯工程的安全审查，加上了“战略对齐”和“数据准确性”的审查步骤。我从这个过程中学到了很多。如果你不想折腾，原版的 Compound Engineering 直接拿来处理知识工作也是绝对好用的。
Rory（观众）：你们怎么在日常繁忙的工作和会议之间，抽出时间去折腾和尝试这些新工作流的？有什么组织层面的建议吗？
Austin Tedesco：这是一个非常现实的挑战。因为这些自动化工具太诱人了，你很容易陷入“只要我再把这个自动化调试一下，我的工作就会变得完美”的陷阱里。很多时候我发现自己沉迷于搭建极佳的工具，反而没有花足够的时间去完成那些真正推动业务的急迫任务。
我给自己的唯一底线是：确保 Codex 里的这些日常自动化工具能帮我把底线任务（比如按时发社交媒体帖子）完成。
Dan Shipper：我想补充一点，这是一种公司文化的体现。在 Every，探索新工具就是我们工作的一部分。现在的工具和工作流迭代得太快了。如果你只盯着眼前的死工作疯狂地跑，迟早会被那些掌握了新工具和新范式的人轻松击败。
给自己留点时间去玩（折腾）这些工具，虽然当时感觉像是在浪费时间，但它其实是在帮你提升维度，让你去玩另一场高维度的游戏。我们公司每年有两次“思考周（Think Week）”，大家完全放下日常工作，聚在一起探索和把玩最新的技术。你不一定要休一整周，但哪怕每个季度抽出一天来，给团队一点空间去探索，也是非常值得的。
Dan Shipper：好的，今天就到这里。感谢大家的参与。我们喜欢这种一起探索的感觉。请记得，Every 是你保持在 AI 最前沿所需的唯一订阅服务。感谢你们的支持！下次见。