我们为什么从 ClaudeCode 转向 Codex-丨Every
公众号名称：晚点再听LaterCast
作者名称：Capihom
发布时间：2026-05-15 21:32
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
“如果它能自己写软件，它就能自己做任何知识工作。”
“Codex 是我每天打开的第一个东西。”
“新的工作操作系统，正在变成一种 Agent 管理界面。”
这期节目对谈嘉宾是 Every 的增长负责人 Austin Tedesco，聊他们为什么从 Claude Code 转向 Codex。Austin 说，自己现在大约 80% 的工作时间都在 Codex 桌面应用里，里面连着 Gmail、Slack、Notion、Stripe 和公司数据源。他没有以工程师身份坐在 IDE 里写代码，作为增长负责人，他把策略、数据分析、招聘、GTM 计划和自动化都搬进了一个 Agent 管理界面。
Codex 从工程师工具变成工作入口
Dan 开场很直接：几个月前，Codex 在他的体验里还很糟，像一个只给资深工程师用的结对编程工具，会和人争辩，也缺少情绪智能。他认为 OpenAI 原本把场景切开：普通人的 vibe coding 留在 ChatGPT，资深工程师在 Codex 里写程序。Claude Code 证明了另一条路：一个能访问本机、速度够快、体验够好的 coding agent，天然会溢出到所有知识工作。
“如果你的电脑上有一个好用的通用 coding agent，它其实非常适合任何知识工作。”
这个判断对工程师之外的人更重要。过去，产品、增长、运营、招聘的人在十几个工具之间切来切去：一个地方看邮件，一个地方查 Slack，一个地方写文档，一个地方跑数据。Codex 的变化在于，它把“让 Agent 去别的软件里干活”变成一个稳定入口。Dan 还把它放进更大的竞争里：Anthropic 有 Claude Code 和 Claude Cowork，OpenAI 有 Codex，xAI 通过 Cursor 进入这一层，Google 也有 Antigravity。模型公司抢的已经是桌面上的工作入口。当 coding agent 能读文件、开浏览器、调接口、改文档，工作台就不再只是写代码的地方。
增长负责人的 Agent 时刻
Austin 的转变从 Claude Code 开始。他在十二月到一月花了一周时间，把 CLI 接到自己的工作和个人生活里，发现它能自动化琐事，也能做思考伙伴。Dan 形容他的“agent pill moment”很夸张：某个周一早上，Austin 说自己整个周末每天在电脑前 12 小时，哪里也没去，因为一直在用 Claude Code。几个月后，他把同一套知识工作流迁到了 Codex 和 GPT-5.5 上。
“我想做的那种知识工作，需要战略思考、数据分析、写营销文案，还会散落在一堆应用和工具里。”
增长负责人的工作很适合观察这次迁移。它不像纯工程任务那样边界清晰，也不像纯写作那样只在一个文档里完成。Austin 要读 Slack、查 Notion、看数据、写策略、出推广计划，还要和人确认。Codex 对他的吸引力，来自它能把分散的上下文拉到同一个任务空间里。 他还会刻意尝试更“工程化”的任务，因为这能帮他判断模型到底到了哪一步，而不是只在营销文案里感受模型能力。
80% 的工作时间搬进一个界面
Austin 说，自己白天登录后，第一个打开的就是 Codex。它会从 Gmail、Slack、Notion、Stripe 和其他数据源拉需要的东西。他把 Codex 当成一个可持续工作的桌面：一个文件夹放 Every Growth OS，里面有密钥、项目说明、公司背景、工作偏好和一组 reviewer agents。每个长期任务都有持续存在的上下文，不用每天重新解释公司在做什么。他喜欢 Codex 的文件夹和持久会话，因为能一边改 KPI 表，一边切到产品代码里发 PR，不用在 Claude Code、Claude 桌面和代码工具之间来回换。一次工作可以跨策略和代码两层。
“我每天打开它，它会从 Gmail、Slack、Notion、Stripe 和所有数据源里拉我需要的东西。”
这里的关键不只是“接了很多工具”。很多自动化工具也能接 API，但 Austin 需要的是一个能理解业务语境的工作台。比如 Every 是什么、增长团队看重什么、过去怎样写计划、公司如何做战略评审，这些都存在项目说明和长期会话里。工作入口从“打开应用”变成“打开一个带业务记忆的 Agent 工作区”。
他还把工程团队的复查方法搬到知识工作里。Compound Engineering 原本会检查安全、前端设计等工程问题，Austin 做了一个面向知识工作的分叉，让 reviewer agents 去看战略是否贴合公司目标、数据是否准确、计划是否漏掉重要约束。增长计划、定价讨论、市场发布，不再只靠一个人关掉文档前再扫一遍。评审也变成可调用的工作流，而不是靠临场记忆。
先让 Agent 教你怎样用 Agent
Austin 推荐新手的第一步很具体：不要先自己想“我能自动化什么”，先让模型去看自己最常用的 Notion、Slack、Gmail，再让它提出能帮助工作的自动化。他会开一个 compound engineering brainstorm workflow，直接要求 Codex 分析哪些重复动作值得改造。模型给出的不一定马上完美，但会让人快速看到边界在哪里。
“当我尝试一个新模型或新应用时，我希望一个很聪明的前沿模型告诉我该怎样用它。”
这个方法适合非工程团队。很多 PM、运营和市场人卡住，往往因为需求太散，自己也不知道该从哪里自动化。Austin 的做法是把问题先交给 Agent 做盘点：常用工具、重复行为、风险边界、需要人工确认的环节。最小起步可以很轻：先让 Agent 给你的工作流做一次体检。 他把这叫成一种 brainstorming automation 状态，人先描述现状，模型再把模糊的痛点拆成可以尝试的自动化清单。速度很重要，因为第一轮反馈能迅速打开想象力。
人工确认仍然留在外部工具里
对话里有人问，Austin 的 review step 到底长什么样。回答很实用：他会让 Codex 起草 Slack 消息、邮件、规则和计划，但最终发送、归档或修改，一定放在外部应用里完成。比如邮件 triage，他会先用语音把问题说清楚，再让 Agent 采访自己，理解什么重要、什么可以归档、什么绝不能自动处理。然后设定规则：不要替我发送，只能起草；定期帮我审计过去 72 小时有没有错删或误归档。
“我所有起草和准备都在 Codex 里做，最后的确认步骤留在外部应用里。”
这是一条很重要的边界。Agent 自动化越深入，越需要明确哪些动作必须由人确认，尤其是涉及客户、钱、招聘和团队沟通的时候。Austin 的经验是，把“想、找、写、整理”交给 Codex，把“发出、删除、承诺、变更规则”留给人。他在项目规则里写清楚：建议可以发到聊天里，但不要擅自放进正式文档；起草可以很快，外发前一定回到人类眼前。AI 工作流真正可用，靠的是把人工确认放在最容易看见的位置。
GTM 计划先写给人，也写给 Agent
Austin 最喜欢的用法，是把会议、Slack 讨论、内部想法整理成 Go-to-market 计划。Every 准备发布 Plus One 时，团队已经开了很多会，也在 Slack 里讨论过定位和上线动作。过去，Austin 可能要抽出一整天，或者晚上工作结束后再熬夜，把所有讨论整理成一份人能看的计划。现在，他让 Codex 找出这些材料，拼成结构，再送到 Notion。
“我依赖模型整理我们已经说过、想过的东西，再把它们拼起来并做审阅。”
他对这份计划的要求也变了。文档既要给人读，也要给 Agent 用。Brandon 负责定价模型时，可以让自己的 Agent 读取 Austin 的计划，提炼商业理由，再继续做价格测算。Austin 甚至说，这类计划“主要是给人类通过 Agent 理解的”。知识工作文档开始承担双重角色：人读它来对齐，Agent 读它来继续执行。 这会改变公司内部文档的写法，越完整、越结构化，后续自动化越容易接上。
Dan 补了一句很重要：很多工作其实是在把已经完成的思考，整理成别人能读、能消费的形式。战略、发布计划、复盘文档，常常来自会议里讲过的话、Slack 里的争论、领导层已经形成的判断，最后被压成一份可以传播的材料。Codex 擅长的正是这段“整理成形”的劳动，但 Every 对人的要求也更高：你分享 AI 写的文档，就要能站在会议里回答里面的每个问题。答不上来，团队会立刻知道你没有真正拥有那份材料。
数据源不准，Agent 越勤快越危险
Austin 也讲了 Codex 做不到一步到位的地方：公司的 KPI 表。他想把 KPI 放进 Notion 数据库，让任何人都能让 Agent 查看新付费订阅试用、页面访问量、Monologue iOS MRR 等指标和计划的差距。Codex 能接 API，也能建表，但前几版总有 5% 到 10% 的格式、数字或框架偏差。Austin 很清楚，MRR 这种数不能差 3%，更不能差 5%。
“我们的 MRR 数字不能差 5%。公司不能靠一个哪怕差 3% 的事实源运转。”
所以他逼自己一列一列核对，确保每个字段都准确、可解释、可防守。这段尤其适合所有想上 Agent 的团队：自动化之前，先清理事实源。因为一旦 Agent 能根据 KPI 自动建议 SEO 页面、增长实验或客户动作，错误数据会放大成错误执行。Austin 说自己甚至会对“还要逐列核对”感到烦，因为模型已经强到让人期待它一把做完；可经营公司时，事实源没法靠期待。Agent-first 的前提，先是把基础数据做得足够可靠。
招聘也变成找针的工作
Austin 还展示了一个招聘用法。Every 要找学习与发展负责人，他想到 2010 年代纽约的 General Assembly：很多擅长技术课程、编程和设计教育的人，可能在那里工作过。他让 Codex 找一批 GA 校友，再筛出后来进入 AI 领域的人。结果第一位候选人看起来就很合适，而且还在 Twitter 上关注他，于是他直接发了私信。
“它能很好地帮你在草堆里找到那根针，尤其适合 outbound。”
招聘场景说明了 Codex 的另一种价值：它能帮人更快写 JD，也能把人的判断路径变成搜索路径。Austin 的判断是“GA 早期的人可能懂课程质量”，Codex 负责把这条假设变成名单、筛选和线索。传统招聘更像等候申请池，outbound 更像带着一套判断去找人。经验丰富的人给出判断框架，Agent 负责把框架跑到足够大的候选空间里。
Dan 在最后也点出 Every 的组织氛围：他们很重视玩新工具。公司每年两次 Think Week，团队暂停日常任务，用一整周一起试新东西、搭原型、学习工作流。Austin 承认，自己有时会过度沉进学习和搭建里，所以反过来让 Codex 自动提醒他完成 Brandon 需要的商业计划、业务开发材料等急事。玩和交付不冲突，前提是有系统把人拉回正事。
写在最后
这期最有价值的提醒，是 Codex 竞争的已经不只限于代码编辑器。它在争夺知识工作者每天打开的第一个入口。真正要学的也不只是某个按钮，更像一次工作流重建：哪些交给 Agent，哪些必须人来确认，哪些事实源先要整理干净。先从一个真实任务开始，让 Agent 看见你的工具和上下文，比收藏十个教程更接近答案。越早把工作流放进去，越早能看清自己每天到底被哪些碎片拖住，然后一点点拆掉。先做一件真事，这一步最关键，马上做一轮就好。
内容来源：“Why We Switched From Claude Code to Codex”丨Every
原视频：https://www.youtube.com/watch?v=x9BNBcP\_C7Q&t=29s
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
Original Capihom 晚点再听LaterCast
内容效果不满意？点此反馈