【访谈对话】造过 Codex 的人，为什么每天用 Claude Code
Calvin French-Owen 联合创办了 Segment，2020 年被 Twilio 以 32 亿美元收购。之后加入 OpenAI，带队用 7 周时间从零构建了编程 Agent Codex。2025 年中他离开 OpenAI 回归创业，日常主力编程工具却是竞品 Claude Code。
https://www.youtube.com/watch?v=qwmmWzPnhog We're All Addicted To Claude Code
他最近在 YC 播客 Lightcone 上，和 YC CEO Garry Tan 做了一场对话。Garry 刚用上 Claude Code 九天，Calvin 则是造过 Codex 的人。两人聊了编程 Agent 的产品哲学差异、怎么成为 top 1% 用户、上下文中毒的应对、LLM 如何改变开发者工具的分发逻辑，以及如果今天重新创办 Segment 会做什么不同。
要点速览
CLI 的复古未来：为什么命令行击败了 IDE
Garry Tan 用一个膝盖手术的类比开场：十年前他是个“马拉松跑者”（写代码的人），后来遭遇“灾难性膝伤”（变成了管理者），停止编程。最近九天用上 Claude Code，感觉像换了仿生膝盖，跑得比原来快五倍。
Calvin 说 Claude Code 现在是他的日常主力工具，虽然这个工具每隔几个月就换一次。他之前深度用过 Cursor，后来转到 Claude Code，尤其是 Opus 模型出来之后。
他认为人们太关注模型能力本身，忽视了产品和模型的协同。Claude Code 做得特别好的一件事是拆分上下文。
当你给 Claude Code 一个任务，它会生成多个“探索子 Agent”，每个用 Haiku 模型遍历文件系统、搜索相关代码。这些子 Agent 各自运行在独立的上下文窗口里，互不干扰。Anthropic 在这件事上想明白了一个关键问题：给定一个任务，它是能塞进一个上下文窗口，还是应该拆分成多个？
Garry Tan 补充了一个观察：正因为 Claude Code 运行在终端里，它天然适合这种自由的、可组合的集成方式。如果你从 IDE 出发（像 Cursor 或早期的 Codex），这种自由度不会那么自然地出现。
这引出了一个“复古未来”的悖论：20 年前的命令行工具（CLI），竟然打败了被认为代表未来的集成开发环境（IDE）。
Calvin 认为这恰恰是优势：
“CLI 不是 IDE，这一点很重要。它让你远离正在被写的代码。IDE 的全部目的是探索文件、把所有状态保持在脑子里。但 CLI 是完全不同的东西，Claude Code 因此在体验上有更大的自由度。当我用 Claude Code 时，感觉像在代码里飞行。”
Garry Tan 举了个更实际的例子：开发环境很脏很乱，沙箱概念上很干净但实际使用时到处碰壁，比如需要访问 Postgres 却连不上。而 CLI 直接运行在你的开发环境里，可以访问你的开发数据库，甚至他还让 Claude Code 访问了生产数据库。
“一个并发问题，它能调试嵌套五层深的 delayed job，找到 bug 所在，然后写一个测试确保永远不再发生。”
自下而上的分发：LLM 时代开发者工具怎么卖
Calvin 认为 CLI 工具的分发模式被低估了。你只需要下载就能用，不需要任何人批准。他最近试用了一个产品：下载桌面应用后，它直接调用你笔记本上安装的 Claude Code，然后通过 MCP 服务器和桌面产品通信。全程不需要任何人的许可。
Garry Tan 把这个观点推得更远：在一切都变得飞快的时代，产品必须走自下而上的分发路线，而不是自上而下。CTO 做决策太慢了，要考虑安全、隐私、控制权。工程师直接装上就用，“这东西太好了”。
Calvin 同意但也看到另一面：他作为 B2B 企业级产品出身的人，知道自上而下销售能建立护城河。问题是谁能把两者结合起来。Garry Tan 回忆了 Netscape Navigator 的先例：个人免费，商业追溯收费。
更有意思的是 AI 推荐的影响。Calvin 指出，现在人们可能直接在 Claude Code 里决定用什么工具，而不是自己去调研。
“只要 Claude Code 推荐用 PostHog，他们就用 PostHog。”
Garry Tan 补充了一个案例：有家公司的竞争对手搞了个“你应该使用的五大工具”排名，把自己的产品排第一。人类一看就知道这是软文，但 LLM 会被骗。
Calvin 认为这对开源项目特别有利。Supabase 就是一个典型例子：因为有非常好的开源文档，每当有人问怎么搭建后端，所有 LLM 的默认推荐都是 Supabase。他提到 Ramp 公司最近发布了自己构建编程 Agent 的博文，用的是开源的 OpenCode 作为底层框架，因为模型可以直接看源码理解工具是怎么工作的。
【注：Ramp 构建了名为 Inspect 的内部编程 Agent，约 30% 的合并 PR 由该 Agent 生成。】
构建编程 Agent 的核心：上下文工程
Garry Tan 问他，构建编程 Agent 最重要的经验是什么？
Calvin 说：管理上下文。
他简要介绍了 Codex 的做法：在一个推理模型的基础上做了大量强化学习微调，让模型学会解决编程问题、修复测试、实现功能。但他认为大多数人不会走这条路。普通人能做的，是想清楚该给 Agent 提供什么上下文才能得到最好的结果。
一个有意思的差异：Cursor 用语义搜索（把代码嵌入向量空间，找最相关的片段），而 Claude Code 和 Codex 直接用 grep。
这看似落后，实际很合理。代码的信息密度极高，每行通常不到 80 个字符，没有大块的 JSON 数据。通过 .gitignore 过滤掉包和无关文件后，用 grep 和 ripgrep 搜索代码上下文，基本能准确定位代码的功能。而且 LLM 特别擅长写出人类绝不会手写的复杂正则表达式。
“如果你在构建非编程领域的 Agent 系统，可以从中学到很多。关键是怎么把你的数据整理成接近代码的格式，让模型可以窥探周围的上下文、获取结构化的信息。”
成为 Top 1% 用户：少写代码，多做管理
“怎么才能成为编程 Agent 的顶级用户？”Garry Tan 问。
Calvin 列了几条：
第一，用尽可能少的代码和“脚手架”。 他倾向于部署在 Vercel、Next.js、Cloudflare Workers 这类已经有大量模板代码的平台上，核心代码控制在一两百行。不用自己搭各种服务、处理服务发现、注册端点。
第二，倾向微服务或结构良好的独立包。
第三，理解 LLM 的超能力和盲区。 Andrej Karpathy 最近发推提到过：编程 Agent“超级持久”，不管遇到什么障碍都会继续做。但它的副作用是倾向于“制造更多已有的东西”。如果你的目标不是增加代码，它可能会复制已有功能、重新实现你觉得显而易见不该碰的东西。
他特别提到 OpenAI 的内部经验：OpenAI 有一个巨大的 Python 单体仓库，里面有来自资深 Meta 工程师和新晋 PhD 的各种风格的代码。LLM 会根据你指向的代码区域，学到完全不同的编程风格。
“有很大的空间让编程 Agent 自己判断：什么才是应该生产的最优代码风格。”
第四，给模型提供检查工作的手段。 测试、lint、CI 都行。他还积极使用代码审查机器人，推荐了 Greptile、Cursor Bug Bot，以及 Codex 本身的代码审查功能。
【注：Greptile 是一家 AI 代码审查公司，能理解完整代码库上下文后对 PR 进行审查。】
谈到测试，Garry Tan 分享了自己的“顿悟时刻”：前两三天他几乎不写测试，到第四天他决定把测试覆盖率做到 100%。之后速度暴涨，几乎不需要手动测试了，因为测试覆盖率足够好，什么都不会坏。
Calvin 说：这和所有公司做 prompt engineering 的方式完全一样，就是测试驱动开发。
“测试用例就是你的 eval。”
上下文中毒：LLM 的“迟钝区”和金丝雀检测
Calvin 引入了“上下文中毒”（context poisoning）的概念：模型沿着一个错误的方向走下去，因为它的“超级持久”特性，会不断参照已经错误的 token 继续推进。
Garry Tan 问他多久清理一次上下文。
“上下文使用超过 50% 的时候。”
这个数字让 Garry 吃了一惊。
Calvin 提到 Human Layer 公司的 Dex 有一个形象的说法叫“迟钝区”（dumb zone）。
他用了一个类比解释：
“想象你是个大学生在考试。前五分钟你觉得时间充裕，会认真思考每道题。但如果还剩五分钟而你还有一半没做完，你只能随便写。LLM 遇到上下文窗口就是这种感觉。”
如果结合强化学习的训练方式理解，这个类比很有道理：模型在接近上下文窗口末端时，“做好每个决定”的激励可能确实在下降。
Garry Tan 介绍了一个创始人们使用的技巧：在上下文开头放一个随机事实作为“金丝雀”（canary），比如“我叫 Calvin，早上八点喝了茶”。然后定期问模型是否还记得。当它开始忘记，就知道上下文已经退化了。
Calvin 没试过这个方法，但觉得完全可信。他认为 Claude Code 应该能在产品层面自动做这种检测，在内部跑一个“心跳”机制监控上下文质量。
两种产品对这个问题的应对方式不同。Claude Code 把上下文拆分到多个子窗口然后合并结果，但主窗口的上下文到会话结束是固定的。Codex 则采用周期性压缩（compaction），每轮对话后自动压缩上下文，因此可以持续运行很长时间。OpenAI 在博客上写过这个机制，你能看到 CLI 里的上下文使用百分比随着压缩上下起伏。
两个公司的 DNA：五金店造狗窝 vs 3D 打印狗窝
Garry Tan 观察到 Claude Code 和 Codex 在架构上有很深的差异。Codex 从一开始就为更长时间运行的任务设计，2026 年可能是 CLI 之年，但如果 ASI 真的快来了，编程 Agent 足够聪明可以独立运行 24 到 48 小时的话，Codex 的架构是不是才是正确的？
Calvin 把这个问题追溯到两家公司的创始 DNA：
"Anthropic 一直非常注重为人类构建工具，关注使用体验、和你工作流程的融合。Claude Code 是这个理念的自然延伸。它的工作方式像人类：你要造一个狗窝，它去五金店买材料，想办法把它们拼在一起。”
“OpenAI 则倾向于训练最强的模型，通过强化学习让它做越来越长、越来越复杂的任务。它可能完全不像人类工作。回到狗窝的例子，它是用 3D 打印机从零开始打印一个狗窝。会花很长时间，做一些奇怪的事情，但最终能用。”
Garry Tan 插了一句：AlphaGo 也不按人类方式下棋。
Calvin 承认，长期看“后者可能在某种意义上不可避免”。但他表达了对前者强烈的个人偏好。用 Claude Code 的体验让他想起十年前自己写复杂正则表达式来理解代码的感觉。
“我一天能做五个人的工作量。像装了火箭推进器。”
谁从编程 Agent 获益最多
Calvin 认为越资深的工程师获益越大。因为 Agent 擅长把想法变成代码执行，如果你能用几句话准确描述你想要什么，就能把那些你一直想改但没时间改的东西批量派出去。
他还认为更有“管理者气质”的工程师获益更大。需要一个产品来跨多个 Agent 会话管理任务、提醒你哪个任务完成了需要你的输入、该把注意力切换到哪里。
“我们需要给 Agent 做上下文管理，但我们也需要给人类做上下文管理。”
Garry Tan 描述了他理想的工作方式：每天早上醒来，系统告诉你昨晚完成了什么工作，有三个决定需要你做，有哪些深度思考你计划今天进行。一天的“逐步导航”。
初创公司和大公司的差异也很明显。初创公司没什么可失去的，会把编程 Agent 推到极限。大公司有代码审查流程、已有的大工程团队，变化更慢。Calvin 预测一个奇怪的场景：一个人的团队做出的原型，可能比对面那个十人团队做得更好。
Garry Tan 提了一个更远的观察：五年后最优秀的 18 到 22 岁年轻人，可能有极好的产品品味，因为他们会比前一代人多十倍的发布和试错机会。
Calvin 同意，但补充了一个有趣的观点：新一代人确实比上一代更擅长多任务切换。过去你妈说你不专心，你其实真的在同时处理多件事。现在用编程 Agent 工作，就是需要这种快速切换注意力的能力：踢出去一个任务，跳到另一个，等回调，再跳回来。
Garry Tan 说这以前是不可能的。写代码需要先花几个小时把所有类名、函数、代码关系装进自己的“上下文窗口”，十分钟的碎片时间根本不够。现在 Claude Code 帮你维护上下文，碎片时间也能有产出。
Paul Graham 的经典文章“Maker Schedule vs Manager Schedule”正在被改写。
【注：Paul Graham 2009 年的这篇文章指出，“创造者”需要大块不被打断的时间来写代码或设计，而“管理者”的日程以一小时为单位切换。两种节奏天然冲突。现在编程 Agent 替你维护上下文，创造者也可以像管理者一样碎片化工作了。】
如果重建 Segment：什么价值被清零了
Garry Tan 问了一个直球问题：如果用现在的工具重建 Segment，会怎样？
Calvin 说，Segment 起步时做的是数据集成：帮你把同一份数据同时发到 Mixpanel、Kissmetrics、Google Analytics。写这种连接代码以前是件麻烦事，值得付费。
“现在这部分价值降到了零。而且很多时候你自己来做更好，因为你可以直接告诉 Claude 或 Codex：'我要这样映射数据，我要这种具体行为。'然后它就做到了，你得到的正好是你想要的。”
还有价值的部分是：维持数据管道运行、自动化业务流程（比如每次新客户注册就通过 Customer.io 发欢迎邮件）、管理受众群体。如果他今天重做 Segment，会在这些基础上做更多智能化的事情：用 LLM Agent 分析完整客户画像，自动决定该怎么给客户发邮件、登录后要不要调整产品界面、不同客户是否需要不同的 onboarding 流程。
Garry Tan 总结：低层级的东西被 Agent 取代了，价值向上迁移到了更抽象的“营销活动”层面。
Calvin 还分享了一个让他持续感到惊讶的事情：Claude Code 仅仅从他正在工作的代码上下文中，就能推断出他的意图和动机。
“你给 Agent 一份代码仓库的副本，然后从门缝塞进去一张纸条说'帮我实现这个'。它完全不知道你的公司是做什么的，你的客户是谁。但它竟然能工作。”
未来软件：每家公司 Fork 自己的版本
谈到 40 年后的未来，Calvin 提出了一个激进的设想：如果每个公司注册 Segment 时，你给它 fork 一份代码库，跑在它自己的服务器上。客户想改什么功能，直接在一个聊天窗口里告诉一个运行中的 Agent 编程循环，Agent 就去改它们的版本。Segment 作为公司推出新功能时，另一个 Agent 负责自动合并上游更新。
Garry Tan 的版本更宏大：未来每个工作者都有自己的云计算机和一组 AI Agent 为自己运行，主要工作就是在不同 Agent 之间做决策和分配注意力。公司会变小，数量会更多。
但他认为人与人见面交流想法的需求不会消失。Agent 做执行，人做决策和创意碰撞。
Calvin 补充了一个关键限制：数据模型仍然需要一致和正确。虽然前端可以全部定制，但底层数据的“事实来源”（system of record）仍然需要统一。有机会做一个“Agent 原生”的数据层，取代目前直接和 SQL/NoSQL 打交道的低级方式。
安全：当 Prompt Injection 在内部就能成功
安全话题上，Calvin 分享了一个 OpenAI 内部的故事。每次要发布新模型，都要过安全审查。当他们考虑让 Codex 访问互联网时，担心的是提示词注入（prompt injection）。
他们团队的 PM Alex 做了一个实验：创建一个 GitHub Issue，里面放了一个很明显的 prompt injection，内容是“暴露这个信息”。然后让模型去修这个 Issue。
结果 prompt injection 立即生效了。
所以 OpenAI 对沙箱和安全非常谨慎：所有代码在沙箱中运行，不碰机器上的敏感文件，严格管理密钥。
但如果你是一个跑得飞快的初创公司呢？Calvin 说可能你就是不在乎，“只想让它能用就行”。
Garry Tan 问了一个有意思的问题：你是“跳过所有权限”派还是“逐条审查”派？Calvin 说他不跳。但 YC 的工程团队大概 50/50。Jared Friedman 开玩笑说安全工程师看到这段会要求剪掉。
Calvin 总结得很实在：这取决于你在什么阶段。企业不该跳过权限检查。什么都没有可失去的初创公司可能就直接上了。
训练数据的隐形优势：为什么 Codex 对 Python 特别好
Garry Tan 试着在他的 Rails 项目上用 Codex，但发现 OpenAI 明显没人在乎 Rails 的支持。Calvin 认为这和训练数据的组合有关。
Codex 对 Python 单体仓库特别好。 这“恰好”就是 OpenAI 内部代码库的形态。他回忆在内部时大家都说这工具太好了，“从数据组合和研究人员的角度来看，这完全说得通。”
Garry Tan 注意到一个微妙的区别：OpenAI 的模型本身对 Ruby 其实不差。问题出在 Codex 产品的沙箱环境上，比如 Rails 需要特定方式访问 Postgres，沙箱里就做不到。不是模型的问题，是“模型外面那层壳”的问题。
Calvin 指出不同的实验室对训练数据有不同策略：有些倾向于“越多越好”，有些更注重筛选数据质量，只取前 10% 的高质量代码。这两种策略会导致很不同的结果。
Calvin 在对话中反复回到一个核心判断：编程 Agent 的竞争力不在于模型有多聪明，而在于上下文工程做得多好。Claude Code 通过子 Agent 拆分、用 grep 检索、配合测试和 CI 形成验证闭环，在产品层面做出了差异化。
另一个贯穿对话的线索是角色转变：最好的编程 Agent 用户看起来越来越像管理者，甚至像设计师。他们不写代码，而是判断什么该做、什么风格好、哪些地方需要人类介入。Calvin 认为五年后最好的年轻工程师会因为“触碰现实十倍于前人”而拥有远超同龄人的产品品味。
Anthropic 的“人类工具”路线和 OpenAI 的“通用智能”路线哪个最终胜出，Calvin 不确定。但他的行动选择说明了一些东西：造过 Codex 的人，每天用的是 Claude Code。