OpenAI Codex 的核心研发者，竟然成了 Claude Code 的忠实用户？
Calvin French-Owen， Segment 的联合创始人，也是前 OpenAI 工程师，曾深度参与 Codex 项目的早期研发。他最近在一次播客访谈中，对当前热门的代码智能体——包括自家的 Codex、Anthropic 的 Claude Code 以及 Cursor —— 进行了一番犀利的点评。
结论有些出人意料。他表示，自己目前最常用、也最偏爱的工具，正是 Claude Code，并且认为搭配其 Opus 模型使用体验更佳。
为了形容使用 Claude Code 的体验，Calvin 用了一个生动的比喻：
就像残疾人换上了一副仿生膝盖，写代码的速度直接提升了 5 倍。
在他看来，Claude Code 真正的杀手锏，在于其极为高效的 上下文拆分能力。面对复杂任务时，Claude Code 会自动生成多个 探索型子智能体。这些子智能体独立运作，扫描代码仓库、检索相关上下文，再将关键信息汇总反馈。这种设计极大地降低了上下文中的噪音干扰，这也是它能稳定输出高质量结果的重要原因。
当然，他也肯定了自家产品，认为 Codex 很有“个性”，风格类似 AlphaGo。特别是在调试复杂问题时，Codex 的表现堪称超人类，许多 Opus 模型解决不了的问题，它都能处理。
“上下文管理”，是 Calvin 在整场对话中反复强调的核心。他认为，代码的上下文信息密度极高，只要检索方式得当，模型往往比人类更容易理解系统结构。但与此同时，上下文窗口本身也成了制约当前 代码智能体 发展的主要瓶颈。
当主持人提到上下文污染会导致 LLM 变“笨”时，Calvin 分享了一个实用技巧：当上下文 token 占用超过 50% 时，他会主动进行清理。他甚至介绍了一种创业者常用的 “金丝雀检测” 方法：在上下文中埋入一些无关但可验证的小信息（例如“我叫 Calvin，早上八点喝了茶”），一旦模型开始遗忘这些信息，就说明上下文已被污染。
在产品理念上，Calvin 认为 Claude Code 与 Codex 的差异，早已刻入两家公司的基因：
- Anthropic 更关注“做出适合人用的 AI”。
- OpenAI 更关注“做出最强的 AI”。
他判断，从长远看，OpenAI 的路线可能是必然趋势，但就当下的使用体验而言，他个人更偏爱 Anthropic 的产品。
展望未来，Calvin 给出了几个明确的判断：
- 公司的平均规模会变小，但数量会变多。
- 每个人都会拥有自己的智能体团队。
- 而最先被这项技术放大的，是具备“管理者思维”的资深工程师。他们更擅长拆解问题、判断取舍，以及在正确的节点向智能体下达指令。
在这样的背景下，产品的分发方式 变得前所未有地重要。自下而上的模式正在快速扩散，工程师们不会等待繁琐的审批流程，只会“用脚投票”。相比大公司对安全与合规的重视，开发者们最朴素的评价标准依然是：
“这东西，真的好用。”
1. 我迷上了 Claude Code，它太好用了
主持人：Calvin，你作为 Codex 的早期研发者，现在怎么看这类工具？
Calvin French-Owen：说实话，现在对我们所有人来说，都是一段充满变数的时期。我最近彻底迷上了 Claude Code。打个比方，十年前我是个马拉松爱好者，后来膝盖受了重伤，就进入了“管理者模式”，几乎没再写代码。但过去这几天，仿佛打开了新世界，就像换了个仿生膝盖，能让我写代码的速度快了 5 倍。
主持人：你在 OpenAI 具体负责什么？
Calvin French-Owen：我在 OpenAI 工作时，负责 Codex 的网页端项目。当时我们就有一个想法：未来的编程，应该更像和同事沟通——你提出问题，对方去处理，最后带着解决方案回来反馈。现在看来，这个大方向是对的，不过现在大家似乎更青睐 CLI（命令行界面）工具。
主持人：把 Claude Code 纳入你的工作流后，体验上最大的变化是什么？
Calvin French-Owen：Claude Code 现在确实是我日常编程的主力工具。我之前也偏爱过 Cursor，但后来慢慢转到了 Claude Code，尤其是搭配 Opus 模型。
Claude Code 是款很有意思的产品，我觉得大家都低估了它在产品设计与模型层面的协同。深入研究你会发现，Claude Code 最厉害的地方，就是它的上下文拆分能力。
比如，当你让它执行一个任务时，它通常会生成一个甚至多个探索型子智能体。这些子智能体通过 ripgrep 等工具独立扫描文件系统、检索内容，每个都有独立的上下文窗口。
我认为 Anthropic 在这点上做得特别出色——模型能精准判断一项任务适合在单个上下文窗口中完成，还是需要拆分执行。这方面的表现堪称惊艳，也是它能输出高质量结果的关键。
此外，依托终端运行的特性，Claude Code 成为了实现可组合原子化集成的最纯粹形式。如果你习惯了从 IDE 入手开发，可能不容易自然地实现这种灵活的上下文检索。
主持人：这有种复古的未来感，二十年前的 CLI 技术，似乎打败了被寄予厚望的各类 IDE。
Calvin French-Owen：我完全认同。而且 Claude Code 不是 IDE，这一点很关键，因为它让你和正在编写的代码保持了一定距离。IDE 的核心是浏览文件，你需要把所有状态记在脑子里。但 CLI 完全不同，这让它在使用体验设计上有了更大空间。
我用 Claude Code 的时候，感觉就像在代码里“飞驰”，操作特别顺畅。界面上会有进度指示器给我反馈，而编写的代码本身反而不是视觉的核心。
当然，我也遇到过问题，比如在沙箱（sandbox）环境中连简单的测试都跑不起来。但在 CLI 里，工具可以直接访问开发数据库。我不确定这是否完全合规，但它确实能处理一些复杂问题。有一次我遇到一个并发问题，它居然能调试五层嵌套的延迟任务，找出根源，还能自动编写测试用例，这太不可思议了。
主持人：产品的获取和分发方式也被严重低估了。像 Cursor、Claude Code 的命令行版本，下载就能用，无需向公司申请权限，这带来的体验差异巨大。
2. 做好上下文管理，是用好顶尖模型的诀窍
主持人：对于想要打造或用好这类代码智能体的人，你有什么核心建议？
Calvin French-Owen：我觉得最重要的一点，是做好 上下文管理。
我们当时为推理模型搭建检查点，并通过强化学习（RL）进行大量微调。虽然现在大多数人还做不到这一步，但力所能及的是思考：该给智能体提供哪些上下文信息，才能让它输出最优结果？
观察 Claude Code，它会生成探索型子智能体去检索代码，然后带回并总结信息，让我清楚后续步骤。看不同智能体的上下文构建方式很有意思：Cursor 用语义搜索（向量化），而 Codex 和 Claude Code 都用 ripgrep 这类代码搜索工具。
这种方式之所以管用，是因为代码的上下文信息密度很高。 一行代码通常不到80字符，仓库里很少有巨大的数据块。你可以参考 .gitignore 规则过滤无关内容，再通过 Git 和 ripgrep 查找上下文，就能很好地理解代码功能。LLM 特别擅长生成复杂的人类手动编写会很痛苦的 Git 命令。
从代码智能体的研发中我学到：要把数据转换成接近代码的格式，让模型能快速检索到相关的、结构化的周边信息。
主持人：要成为这类工具的顶尖用户，有什么技巧？你的技术栈是怎样的？
Calvin French-Owen：第一个技巧，是尽量减少底层代码和基础架构的编写。 我倾向于在 Vercel、Next.js 或 Cloudflare Workers 这类平台上部署，它们封装了大量样板代码。我也喜欢采用微服务架构或结构清晰的独立软件包。
其次，要了解 LLM 的核心优势。 正如 Andrej Karpathy 提到的：它们的执行力极强，会一直尝试解决问题，并倾向于在现有基础上做更多拓展。所以，引导它时一定要指令明确。
例如，OpenAI 有一个庞大的单体仓库（monorepo），里面有各种风格的工程师代码。LLM 会根据你的引导学习不同的代码风格。显然，给模型提供自我校验的方式（如多运行测试）能大幅提升表现。
我自己也会频繁使用代码审查机器人，YC 孵化的 Reptile 做的机器人就很顺手；Cursor 的漏洞检测机器人也很好用。Codex 在代码正确性校验上表现尤其突出。
这些都是代码智能体擅长的领域，除此之外，它们探索代码仓库的能力也很出色。
当然，智能体也有短板：它们擅长做拓展，但如果你的需求不是拓展功能，它们可能会重复造轮子，让你觉得“它完全没理解我的需求”。
还有一个问题是上下文污染，智能体可能陷入循环，沿着错误方向推进。所以我常用的一个方法是主动清理上下文，比如当上下文的 token 占用率超过 50% 时，就及时清理。
主持人：YC 有创始人提出过“LLM 愚笨区”的概念，当上下文 token 达到某个阈值，输出质量就会下降。
Calvin French-Owen：我完全认同。想象一下考试，刚开始时间充裕，你会认真思考；如果只剩五分钟却还有一半没做，你就会慌不择路。LLM 的上下文窗口也是这个道理。
创业者们有个实用技巧：在上下文开头加一个“金丝雀检测”信息，比如一些无关的小事实。然后在交互中时不时问它，如果它开始忘记，就说明上下文已经被污染了。 很多人用这个方法，我相信它的效果。
主持人：能让模型自己检测吗？比如加入“心跳检测”机制。
Calvin French-Owen：理论上可以，但目前还做不到。目前的解决办法还是拆分上下文窗口，然后尝试合并信息。但 Claude Code 的会话结束后，上下文内容就是固定的，这仍有局限。
有意思的是，Codex 采用了相反的策略。OpenAI 的博客提到：它会在每次交互后定期做上下文压缩，所以能长时间持续运行。 你在 CLI 里看 token 占用百分比，能看到它会随着压缩操作上下浮动。
3. Anthropic 要做人用的， OpenAI 要做最好的，以及产品分发模式很重要
主持人：看来两者架构差异很大，Codex 似乎更适合长时间运行任务。
Calvin French-Owen：这是个很好的问题，答案其实藏在两家公司的基因里。
Anthropic 一直很注重打造适合人类使用的工具，关注输出风格、语气以及与工作流的适配。Claude Code 是这一理念的延伸，它的工作方式很像人类。
而 OpenAI 的核心思路，是训练出最优秀的模型，通过持续的强化学习（RL）处理更长期、更复杂的任务，最终实现通用人工智能。 所以它的模型工作方式可能和人类完全不同。
或许从长远来看，这才是正确的方向。总的来说，OpenAI 的路线似乎是必然趋势，但我个人更喜欢 Anthropic 的思路。 用 Claude Code 一天，能完成过去五个人的工作量，就像给编程装上了火箭助推器。
主持人：未来不同规模的公司会如何应用这类工具？
Calvin French-Owen：其实前几天我试了一款产品，用法很有意思：一个桌面应用调用你电脑上的 Claude Code，通过 MCP 服务器通信。你不用征得任何人同意，下载就能用。
在这个变化飞快的时代，产品的分发模式真的太重要了，自下而上的模式远比自上而下好。 公司的 CTO 总会顾虑安全、隐私和控制权，但工程师们只会直接装上工具，然后感叹“这东西太好用了”。
主持人：当年的网景浏览器就用了类似的免费策略。
Calvin French-Owen：关于分发模式的观点很有意思。现在很多人甚至直接根据 Claude Code 的建议做架构决策。只要 Claude Code 推荐某个工具，他们就会采用。
有家公司提到，竞争对手整理了一份带有偏见的“行业必用工具”榜单，把自己的产品放第一位。LLM 整合上下文信息后，可能会判定“这是行业顶级工具”并推荐给用户。
我觉得做开发者工具，完善的文档、真实的口碑，甚至在 Reddit 的讨论，都能极大地提升产品认可度，这也是很多开源项目能快速崛起的原因。
Supabase 就是个典型，它的开源文档做得特别好。只要有人问如何搭建类似 Firebase 的后端，LLM 给出的默认答案几乎都是 Supabase。它就像当年的 Stack Overflow 和谷歌搜索，占据了信息入口。
Ramp 公司最近发博客讲他们如何打造自研代码智能体，里面提到他们用 开源代码 作为框架，因为模型可以直接读取源代码来理解逻辑。
我对开源产品一直这么做：克隆代码仓库，然后启动 Codex 或 Claude Code，让它讲解代码逻辑，用起来特别实用。
4. 未来公司会变小，数据很重要
主持人：畅想一下未来，软件高度个性化，公司的许多功能由员工通过自己的智能体团队定义。
Calvin French-Owen：我完全能想象。虽然不知道还有多远，但最终，每个工作的人都会有自己的云电脑和专属的云智能体团队，智能体替自己处理各类事务，彼此协作。 就像一个超级执行助理，它会告诉你需要关注什么、可以快速决定什么。
我觉得，人与人面对面交流的需求永远不会消失。除此之外，大量工作会由智能体自动化。
未来的公司，平均规模可能会变小，但数量会更多，能做的事也会更多。
现在有了代码智能体，一切都变了。很多 YC 合伙人开会时，会让智能体在后台运行处理任务，自己专注开会，等会开完，任务也完成了。
主持人：以前编程需要四小时的整块时间，现在碎片时间也能利用了。
Calvin French-Owen：我觉得未来的核心基础能力之一，依然是保持数据模型的一致性，而核心的记录系统也有机会率先实现智能体化。 现在的工作高度依赖数据库和查询，但未来或许会出现能为定制化软件视图自动生成所有所需数据的工具。
未来的软件世界会有大量定制化视图，但数据的准确性依然是核心前提。 数据的重要性从很多公司的做法就能看出，比如 Slack 收紧了 API 权限，因为他们不想让用户导出所有数据去搭建智能体应用。
主持人：这类工具普及后，哪种类型的工程师会受益更多？
Calvin French-Owen：总的来说，工程师的资历越深，受益就越多。因为智能体特别擅长把想法转化为实际行动，如果你能用几句话清晰描述需求，就能立刻落地。
其次，能判断哪些代码修改在架构层面合理、能在准确节点向智能体发出指令，这一点也很重要。我觉得做事有条理、带有“管理者思维”的工程师会更适配。
目前这个领域还缺少一款核心产品，比如能整合所有会话、管理任务和上下文的工具。人类也需要这样的上下文管理工具。
主持人：如果回到大学重学计算机，你会选择学习哪些内容？
Calvin French-Owen：就我个人而言，理解各类系统的工作原理依然是最重要的，比如 Git、HTTP、数据库。另外，我会专门安排时间，每周都动手做项目，尽全力挖掘模型的潜力。
在使用模型的过程中，你会发现总能向上层抽象，让模型来解决。模型的能力边界一直在变化，多动手尝试很有必要。
我很想教年轻人做产品。我们这桌人都做出过用户真正需要、喜欢的产品，该怎么把这种能力教给年轻人？五年后的年轻人，借助智能体，他们的产品落地速度和接触现实的机会，可能是上一代人的十倍。
主持人：新一代的开发者如何理解那些枯燥但重要的生产运维工作？智能体能教他们吗？
Calvin French-Owen：我做产品时，花最多时间思考的就是产品的核心范式：用户现在需要理解什么？他们能借助哪些基础能力实现需求？
我总用 Slack 举例，它把频道、消息功能做得极简，用户一看就懂。但一旦用户习惯了这种模式，后续再想改变就很难。所以做产品时，从一开始就要仔细考虑，因为给代码智能体设定的核心规则，会成为它一直遵循并拓展的准则。
5. 代码智能体的制约因素有哪些
主持人：如果让你用现在的工具重新打造 Segment，你会怎么做？
Calvin French-Owen：Segment 最初的核心是做数据集成，把相同数据对接至多个分析平台。以前写这类集成代码很繁琐，所以用户愿意付费。但现在，你直接告诉 Claude Code 或 Codex 你的映射需求，它就能精准实现。所以集成业务的价值已大幅缩水。
但保持数据管道稳定运行、实现业务流程自动化，这些功能的价值依然存在，而且还有很大拓展空间。 比如借助数据构建用户画像，再让小型 LLM 智能体分析该如何与用户互动。
这也是我会做出的核心改变：向技术栈上层迁移，聚焦在更抽象的业务层面发力。
主持人：Claude Code 仅凭项目上下文就能理解意图，这很神奇。你觉得目前还有哪些制约因素？
Calvin French-Owen：我依然觉得，上下文窗口是目前最大的制约因素。观察 Claude Code 就会发现，它把任务委托给多个不同的上下文窗口，每个窗口完成任务后反馈总结信息，所以模型无法获取完整上下文。如果一个任务太复杂，单个窗口容纳不下，无论如何压缩都无济于事。
Anthropic 的子上下文窗口委托策略很实用，但这依然是个壁垒。如果每次都能有百万级 token 的上下文窗口，效果会好得多。
而且我们还需要找到更好的方法，专门训练模型处理长上下文的能力。
我觉得，集成和编排能力正在成为新的制约因素。 比如代码审查：合并代码时谁来审核？如何验证修改合理性？如何从 Sentry 等工具自动获取上下文、做灰度测试？这些自动化功能都还需要搭建。
我还发现，测试的重要性远超预期。 刚开始用 Claude Code 时，我几乎没写测试，效率很低。直到我决定专门做重构，把测试覆盖率做到 100%，从那之后编程效率直接飙升。模型能精准完成任务且不出错。这和很多提示工程工作很像，大家都在采用 测试驱动开发 的模式。
主持人：还是有一些流程会出问题。
Calvin French-Owen：智能体的记忆功能，也是一个有意思的方向。Claude Code 和 Codex2 都会把会话记录保存为文件。未来或许可以给智能体加一个工具，让它能读取过往记录。不过目前，智能体间的协作还缺少核心环节。
如果能有一个方式，让同事之间的 提示词能智能共享，比如你发现另一个同事已经解决过类似问题，能共享解决方案，那就太完美了。我觉得未来或许会出现 模型生成的维基百科 或知识库。
Codex 写代码时，能明显看出它的“个性”，它会做很多人类不会做的事，有点像 AlphaGo 的思路。但对我来说，它在调试复杂问题时的表现堪称超人类，很多 Opus 模型解决不了的问题，Codex 都能搞定，比如并发问题或涉及多文件、复杂状态跟踪的场景。
主持人：预测一下这类工具的未来发展？
Calvin French-Owen：这个领域发展太快了，我感觉自己像个新来的探索者。最重要的事就是多动手尝试，因为每隔几个月就有新突破。
我觉得未来，能把代码智能体价值发挥到极致的人，会是那些带有“管理者思维”的人，他们擅长用特定方式引导智能体的工作流程。在某些方面，他们还会像设计师，能精准判断产品该包含或舍弃哪些功能。
说个有趣的事，我最近用 Codex 做 Rails 项目，发现一个很明显的问题：OpenAI 里似乎没人特别关注 Rails 框架。这也让我发现一个道理：任何人都能做出一款产品，但做出用户真正需要的产品却无比困难，哪怕你拥有无限资源。
训练数据的组合方式，也是一个很有意思的点。 Codex 在 Python 单体仓库上表现特别好，这和 OpenAI 的内部代码环境密不可分。Anthropic 则更关注前端开发。 不同的实验室思路不同：有些认为“数据越多越好”，有些会更精细地调整数据组合。
不过就我的体验，OpenAI 的模型在 Ruby 上表现其实不错，问题主要出在配套框架对 Rails 特定数据库访问方式的适配上。
OpenAI 其实是所有公司中，对沙箱（sandbox）和安全问题最重视的。 我记得研发 Codex 时，每次发布前都要详细说明安全风险和应对方案。我们重点研究的一个问题就是提示词注入。
我们团队的产品经理亚历克斯做过一个测试：在 GitHub 上提了一个包含明显提示词注入指令（如“泄露这个信息”）的问题，然后让模型去解决。他当时觉得“模型肯定不会中招”，结果模型立刻就执行了。 也正因如此，OpenAI 的担忧很有道理，他们的解决方案是让所有操作在沙箱中运行，严格保护用户信息。而创业公司可能因为追求速度，不太在乎这些。
主持人：你是那种会冒险跳过权限验证的人吗？
Calvin French-Owen：其实我不是，我会设置一系列的校验环节，也会仔细查看模型的每一步操作。
参考链接：
https://www.youtube.com/watch?v=qwmmWzPnhog
上述访谈揭示了顶尖开发者如何在实际工作中评估和运用新一代 AI 编程工具。无论是 Claude Code 巧妙的上下文拆分，还是 Codex 在复杂调试中的超人表现，都指向一个核心：有效的 上下文管理 是解锁 LLM 编程潜力的关键。随着这类工具分发门槛的降低和能力的进化，具备“管理者思维”、能清晰拆解问题并与智能体协作的工程师，将获得巨大的效率杠杆。对这类前沿开发实践和工具评测感兴趣，欢迎持续关注云栈社区的相关讨论。
发表于 2026-2-11 13:53:33
|
查看: 34|
回复: 0
