免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

【访谈对话】造过 Codex 的人,为什么每天用 Claude Code

发布日期:2026-02-08 09:55:52 浏览次数: 1523
作者:宝玉AI

微信搜一搜,关注“宝玉AI”

推荐语

编程AI工具如何重塑开发者工作流?听听Codex创造者为何偏爱竞品Claude Code的深度解析。

核心内容:
1. Claude Code的产品架构优势:子Agent拆分机制与高效代码检索
2. Anthropic与OpenAI截然不同的产品哲学对比
3. LLM如何改变开发者工具生态与创业机会

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

Calvin French-Owen 联合创办了 Segment,2020 年被 Twilio 以 32 亿美元收购。之后加入 OpenAI,带队用 7 周时间从零构建了编程 Agent Codex。2025 年中他离开 OpenAI 回归创业,日常主力编程工具却是竞品 Claude Code。

他最近在 YC 播客 Lightcone 上,和 YC CEO Garry Tan 做了一场对话。Garry 刚用上 Claude Code 九天,Calvin 则是造过 Codex 的人。两人聊了编程 Agent 的产品哲学差异、怎么成为 top 1% 用户、上下文中毒的应对、LLM 如何改变开发者工具的分发逻辑,以及如果今天重新创办 Segment 会做什么不同。

要点速览

  • • Claude Code 被低估的优势不在模型本身,而在产品架构:通过子 Agent 拆分上下文窗口,用 grep 而非语义搜索检索代码,这套机制让它在实际编程中表现远超预期
  • • Anthropic 和 OpenAI 的产品哲学有根本差异:一个造“去五金店买材料造狗窝”的人类工具,一个造“3D 打印整个狗窝”的通用智能。Calvin 认为后者长期可能不可避免,但前者让他“一天能做五个人的工作量”
  • • LLM 正在替代 Google 成为开发者工具的推荐引擎。竞品公司可以通过伪装排名文章操纵 LLM 推荐,Supabase 则因优秀的开源文档成了所有 LLM 的默认后端推荐
  • • Segment 最初的核心价值,数据集成连接,现在已经被 AI 编程工具抹平了。创始人自己亲口说的
  • • 上下文使用超过 50% 就该清理。LLM 的“迟钝区”就像考试最后五分钟还剩半张卷子没做

CLI 的复古未来:为什么命令行击败了 IDE

Garry Tan 用一个膝盖手术的类比开场:十年前他是个“马拉松跑者”(写代码的人),后来遭遇“灾难性膝伤”(变成了管理者),停止编程。最近九天用上 Claude Code,感觉像换了仿生膝盖,跑得比原来快五倍。

Calvin 说 Claude Code 现在是他的日常主力工具,虽然这个工具每隔几个月就换一次。他之前深度用过 Cursor,后来转到 Claude Code,尤其是 Opus 模型出来之后。

他认为人们太关注模型能力本身,忽视了产品和模型的协同。Claude Code 做得特别好的一件事是拆分上下文。

当你给 Claude Code 一个任务,它会生成多个“探索子 Agent”,每个用 Haiku 模型遍历文件系统、搜索相关代码。这些子 Agent 各自运行在独立的上下文窗口里,互不干扰。Anthropic 在这件事上想明白了一个关键问题:给定一个任务,它是能塞进一个上下文窗口,还是应该拆分成多个?

Claude Code 子 Agent 上下文拆分机制

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 所在,然后写一个测试确保永远不再发生。”

CLI vs IDE 开发范式对比:

自下而上的分发: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 会被骗。

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

代码检索方式对比:语义搜索 vs 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 自己判断:什么才是应该生产的最优代码风格。”

成为编程 Agent Top 1% 用户的四个策略

第四,给模型提供检查工作的手段。 测试、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:

两家公司的创始 DNA 对比:Anthropic vs OpenAI

"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 帮你维护上下文,碎片时间也能有产出。

Maker Schedule vs Manager Schedule 被改写

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 流程。

软件价值链重构:AI 抹平底层,价值向上迁移

Garry Tan 总结:低层级的东西被 Agent 取代了,价值向上迁移到了更抽象的“营销活动”层面。

Calvin 还分享了一个让他持续感到惊讶的事情:Claude Code 仅仅从他正在工作的代码上下文中,就能推断出他的意图和动机。

“你给 Agent 一份代码仓库的副本,然后从门缝塞进去一张纸条说'帮我实现这个'。它完全不知道你的公司是做什么的,你的客户是谁。但它竟然能工作。”

未来软件:每家公司 Fork 自己的版本

未来软件:每家公司 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 立即生效了。

Prompt Injection 安全威胁与防护措施

所以 OpenAI 对沙箱和安全非常谨慎:所有代码在沙箱中运行,不碰机器上的敏感文件,严格管理密钥。

但如果你是一个跑得飞快的初创公司呢?Calvin 说可能你就是不在乎,“只想让它能用就行”。

Garry Tan 问了一个有意思的问题:你是“跳过所有权限”派还是“逐条审查”派?Calvin 说他不跳。但 YC 的工程团队大概 50/50。Jared Friedman 开玩笑说安全工程师看到这段会要求剪掉。

Calvin 总结得很实在:这取决于你在什么阶段。企业不该跳过权限检查。什么都没有可失去的初创公司可能就直接上了。

训练数据的隐形优势:为什么 Codex 对 Python 特别好

Garry Tan 试着在他的 Rails 项目上用 Codex,但发现 OpenAI 明显没人在乎 Rails 的支持。Calvin 认为这和训练数据的组合有关。

训练数据的隐形优势:Codex 对 Python 特别好

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。


  • • 访谈来源:YC Lightcone 播客,https://www.youtube.com/watch?v=qwmmWzPnhog
  • • 配图工具:baoyu-article-illustrator skill https://github.com/jimliu/baoyu-skills

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询