前 Codex 大神倒戈实锤，吹爆 Claude Code：编程提速 5 倍，点破 OpenAl 死穴在上下文

Calvin French-Owen 是 Segment 联合创始人、前 OpenAI 工程师、Codex 项目的早期研发者。他最近在一档播客中，对当前最火的代码智能体 Codex、Claude Code 和 Cursor 进行了锐评。

结论出人意料，他最常用、也最偏爱的，是 Claude Code，他表示搭配 Opus 模型更“香”。

Calvin 用了一个极具画面感的比喻，来形容用 Claude Code 的体验：

就像残疾人换上了一副仿生膝盖，写代码的速度直接提升了 5 倍。

在他看来，Claude Code 真正的杀手锏，是极其有效的 上下文拆分能力。

面对复杂任务，Claude Code 会自动生成多个 探索型子智能体，独立扫描代码仓库、检索上下文，再将关键信息汇总反馈。这种设计，显著降低了上下文噪音，也解释了它为何能稳定输出高质量结果。

不过，他也肯定了自家产品，认为 Codex 很有“个性”，像 AlphaGo。在调试复杂问题时的表现上，Codex 堪称超人类，很多 Opus 模型解决不了的问题，Codex 都能搞定。

“上下文管理”，是 Calvin French-Owen 在整期播客中反复强调的关键词。

他认为，代码的上下文信息密度极高，只要检索方式得当，模型往往比人类更容易理解系统结构。但与此同时，上下文窗口本身，也成为制约代码智能体发展的最大瓶颈。

提到上下文污染的问题时，主持人表示 LLM 会变笨。Calvin 趁此分享了一个非常实用的经验：当上下文 token 占用超过 50%，他会主动清理。

他甚至分享了一种创业者常用的 “金丝雀检测” 方法：在上下文里埋入一些无关但可验证的小信息，一旦模型开始遗忘，说明上下文已经被污染。

在产品理念上，Calvin 认为 Claude Code 与 Codex 的差异，早已写进两家公司的基因里：

Anthropic 更关注“做出适合人用的 AI”

OpenAI 更关注“做出最强的 AI”

他判断，从长期来看，OpenAI 的路线可能是必然趋势，但就当下的使用体验而言，他更偏爱 Anthropic。

在谈到未来时，Calvin 给出了一个明确判断：

公司会变小，但数量会变多

每个人都会拥有自己的智能体团队

而最先被放大的，是具备“管理者思维”的资深工程师。他们更擅长拆解问题、判断取舍、以及在正确的节点上向智能体下达指令。

在这样的背景下，产品的分发方式 变得前所未有地重要。

自下而上的分发模式，正在以前所未有的速度扩散。工程师不会等审批、采购，只会用脚投票。

相比大公司对安全、合规和控制权的高度重视，开发者更在意的，依然是那句最朴素的评价：

“这东西，真的好用。”

以下是播客精彩细节，AI Coding 干货密集，欢迎阅读：

我迷上了 Claude Code，它太好用了 

主持人：Calvin French-Owen 是 OpenAI 旗下 Codex 代码模型的首批研发者之一，在此之前，他创立了 Segment 公司，这家公司市值数十亿美元，最终被知名企业高价收购，成功实现资本变现。 

Calvin French-Owen：说实话，现在对我们所有人来说，都是一段充满变数的时期。我最近彻底迷上了 Claude Code，用一个比喻来说，十年前我还是个马拉松爱好者，特别喜欢跑步，结果后来膝盖受了重伤，这之后我就进入了所谓的 “管理者模式”，再也没写过代码，想想真的很可惜。

但过去这九天，仿佛打开了新世界的大门，我找回了曾经写代码的所有感觉，就好像换了个全新的膝盖，而且还是仿生的，能让我写代码的速度快了 5 倍。

主持人：你怎么看待这款工具？毕竟你一直身处这个领域的前沿，Codex 开创的很多理念，至今仍被大家广泛使用，而且这款模型还在持续迭代。 

Calvin French-Owen：我在 OpenAI 工作时，负责 Codex 的网页端项目，当时 Cursor 这款工具刚面世，他们基于 GPT-3.5 做了一个适配层，能在 IDE 中使用。Claude Code 也刚发布，它是基于 CLI 运行的，当时我们就有一个想法：未来的编程，应该更像和同事沟通 —— 你提出问题，对方去处理，最后带着 PR 回来反馈。我们的网页端项目就是从这个想法出发的，这也是我们当时的研发方向。

现在看来，这个大方向其实是对的。但显然，现在大家都改用 CLI 编程了，不管是 Claude Code 还是 Codex，这类工具的使用频率都高了很多。至少对我来说，这件事带来的启示是，某种程度上你说得对，未来每个人或许都会成为 “管理者”，这是我的个人观点。但要达到那个阶段，需要一步步来，你得真正信任模型，并且理解它的工作逻辑。

主持人：你最近一直在用 Claude Code，把它纳入你的核心技术栈后，使用体验上有什么变化？ 

Calvin French-Owen：Claude Code 现在确实是我日常编程的主力工具。 说实话，我的主力工具每隔几个月就会换一次。之前有段时间我特别偏爱 Cursor，它新出的模型速度很快，用起来确实不错。后来我慢慢转到了 Claude Code，尤其是搭配 Opus 模型使用时，体验更好。

Claude Code 是款很有意思的产品，我觉得大家都低估了它在产品设计与模型层面的协同表现。要是你深入研究就会发现，Claude Code 最厉害的地方，就是它的上下文拆分能力。

比如需要调用功能、让子智能体协同工作时，你让 Claude Code 执行某个任务，它通常会生成一个甚至多个探索型子智能体。这些子智能体会通过 ripgrep 工具扫描整个文件系统、检索相关内容，而且每个子智能体都有独立的上下文窗口（context window）。

我认为 Anthropic 在这点上做得特别出色 —— 面对一项任务，模型能精准判断出，这个任务适合在单个上下文窗口（context window）中完成，还是需要拆分后再执行。模型在这方面的表现堪称惊艳，这也是它能输出高质量结果的关键。

更有意思的是，依托终端运行的特性，Claude Code 成为了实现可组合原子化集成的最纯粹形式。如果你习惯了从 IDE 入手做开发，比如用 Cursor 或是早期的 Codex，就会发现，这种更灵活的上下文检索方式，其实并不容易自然而然地实现。

主持人：这一点确实很独特。我个人挺意外的，不知道你有没有这种感觉，总觉得有种复古的未来感，二十年前的 CLI 技术，居然打败了本被寄予厚望的各类 IDE。 

Calvin French-Owen：我完全认同。而且 Claude Code 不是 IDE，这一点其实很关键，因为它能让你和正在编写的代码保持一定距离。IDE 的核心就是浏览文件，对吧？你需要把所有代码状态记在脑子里，还要理清其中的逻辑。但 CLI 完全不同，这让它在使用体验的设计上有了更大的发挥空间。

不知道你有没有这种感觉，我用 Claude Code 的时候，感觉就像在代码里 “飞驰”，各种操作都特别顺畅。界面上会有小的进度指示器，随时给我状态反馈，而编写的代码本身反而不是视觉的核心。

开发环境本来就很杂乱，我特别喜欢 sandbox（沙箱）在概念上的简洁性。但实际使用时，我遇到了很多棘手的问题，比如就连简单的测试都搞不定：sandbox（沙箱）需要访问 PostgreSQL 数据库，却一直连接失败；我写的 codex.md 文件只有二十行，最后还是无法运行。

但在 CLI 里，工具可以直接访问开发数据库。我不确定这么做是否合规，但我确实试过让它访问生产数据库执行一些操作，而且它真的做到了。比如有一次，我遇到了一个并发问题，想排查一下，结果发现这款工具居然能调试五层嵌套的延迟任务，找出问题所在，还能自动编写测试用例，之后这个问题就再也没出现过。这真的太不可思议了。

主持人：没错。而且我觉得产品的推广和使用获取方式，被严重低估了。想想 Cursor、Claude Code 还有 Codex 的命令行版本，你只需下载就能用，不用向公司申请任何使用权限，这一点带来的使用体验差异，实在太大了。 

做好上下文管理，是用好顶尖模型的诀窍

主持人：你在代码智能体领域有很多实践，对于想要打造这类工具的人，你有什么建议？有哪些实战经验可以分享？ 

Calvin French-Owen：我觉得最重要的一点，是做好 上下文管理。

当时我们为一款推理模型搭建了检查点，随后基于强化学习（RL）对它开展了大量微调工作：我们会给模型布置各类编程相关任务，比如解决编程问题、修复测试用例、实现新功能，再通过强化学习的方式，训练模型如何更精准地应对这些任务。当然，目前大多数人还做不到这一步，但大家力所能及的是，多思考该给智能体提供哪些上下文信息，才能让它输出最优的结果。

比如观察 Claude Code 的工作过程，它会生成多个探索型子智能体，这些子智能体会去检索文件系统里的各类代码相关内容，完成后会把上下文信息带回来并为我做好总结，我就能清楚后续该怎么推进工作了。

看不同智能体的上下文构建方式，是件特别有意思的事。比如 Cursor 用的是语义搜索的方式，它会把所有内容转化为向量形式，再匹配和查询需求最相关的内容；而 Codex 和 Claude Code，其实用的都是 ripgrep 这个代码搜索工具。这种方式之所以管用，是因为代码的上下文信息密度很高。 一行代码通常不到 80 个字符，代码仓库里不会有太多大数据块或 JSON 格式的文件，就算有，数量也极少。

你可以参考 Git（代码版本管理工具）的忽略规则，先过滤掉无关内容或是已打包的文件，再通过 Git 和 ripgrep 查找代码的上下文，这样就能很好地理解代码的实际功能了。同时这类工具还能自动扫描整个文件夹的结构，而且 LLM（大语言模型）特别擅长生成复杂的 Git 命令，这些命令让人类手动写的话，简直是种折磨。而这一整套操作，其实就是强化学习（RL）在实际场景中的落地应用。

我现在也在做非编程领域的智能体集成系统，从代码智能体的研发过程中，我也学到了很多：要把数据转换成接近代码的格式，让模型能快速检索到相关的周边信息，进而获取到结构化的有效数据。

主持人：优秀的代码智能体，核心能力就是上下文工程，那要成为这类工具的前 1% 顶尖用户，有什么技巧？你的技术栈是怎样的？你是如何借助这些工具大幅提升效率的？ 

Calvin French-Owen：第一个技巧，是尽量减少底层代码和基础架构的编写。

我平时会在 Vercel、Next.js 或 Cloudflare Workers 这些平台部署技术栈，这些平台已经封装了大量样板代码，不用自己费心搭建各类服务，也不用处理服务发现、中心端点注册、数据库配置这些问题。所有功能基本都能在一两百行代码内实现。我也倾向于采用微服务架构，或者使用结构清晰的独立软件包。

其次，要了解 LLM 的核心优势。

其实代码智能体的特点，Andrej Karpathy 最近也在推特上提到过：它们的执行力极强，不管遇到什么问题，都会一直尝试解决，最终往往会在现有基础上做更多的拓展。所以如果你想引导它完成某个任务，一定要明确指令。 这里可以稍微拿 OpenAI 举个例子，他们有一个庞大的 monorepo（单体代码仓库），已经用了好几年，有成千上万的工程师在上面提交代码。这些工程师里，有经验丰富的资深开发者，他们精通生产环境代码的编写；也有刚毕业的博士，编程经验相对欠缺。人员构成差异很大，所以 LLM 会根据你的引导方向，学习不同的代码风格。我觉得代码智能体还有很大的探索空间，比如研究出最优的代码生成范式。显然，给模型提供自我校验的方式，能大幅提升它的表现，比如尽可能多地在代码检查、CI 等环节运行测试用例。

我自己也会频繁使用代码审查机器人，YC 孵化的 Reptile 公司做的这款机器人用起来就特别顺手；Cursor 的漏洞检测机器人也很好用，我也常常用 Codex 做代码审查，它在校验代码正确性这块的表现尤其突出。

这些都是代码智能体格外擅长的领域，除此之外，它们探索代码仓库的能力也很出色。

当然，智能体也有短板：它们擅长做拓展，但如果你的需求不是拓展功能，它们往往会重复编写代码，浪费大量时间做已经实现过的功能，这时候你就会觉得 “它完全没理解我的需求”。

还有一个问题是上下文污染，智能体可能会陷入某个循环，因为执行力强，会一直沿着错误的方向推进，而它参考的上下文信息，其实对于解决问题毫无帮助。所以我常用的一个方法，是主动清理上下文，比如当上下文的 token 占用率超过 50% 时，就及时清理。

主持人：哇，这个比例其实特别关键。不知道你有没有关注到，YC（Y Combinator 的缩写，全球顶级的创业孵化器）2024 年秋季孵化营里，那家做 HumanLayer（人类层）的公司，创始人 Dex Horthy 就总聊这个话题，还专门提出了 “LLM 愚笨区”的概念：当上下文的 token 数量达到某个阈值后，模型的输出质量就会开始下滑。 

Calvin French-Owen：我完全认同这个观点，结合强化学习（RL）的工作逻辑来看，这一点就更明显了。

想象一下，你是一名参加考试的大学生，考试刚开始的五分钟，你会觉得时间很充裕，一定能好好答题，认真思考每个问题；但如果只剩五分钟，试卷还有一半没做完，你就会慌不择路，只求尽快写完。LLM 的上下文窗口（context window），就是这个道理。

创业者们有一个小技巧，我觉得很实用：在上下文开头加一个 “金丝雀检测” 信息，就是一些特别小众甚至有趣的内容，比如 “我叫 Calvin French-Owen，早上八点喝了茶” 这类无关的小事实。然后在和模型的交互过程中，时不时问它 “你记得我叫什么吗？”“你记得我几点喝的茶吗？”，如果它开始忘记这些信息，就说明上下文已经被污染了。 这是我见过很多人用的方法，我自己还没试过，但完全相信它的效果。

主持人：这个方法很有意思。我在模型做上下文压缩前，还没遇到过这类问题，可能是我没太留意。你是说，token 数超标后，模型会开始做出一些不合理的操作？我得留意一下，这个问题能在 Claude Code 内部解决吗？比如让模型自己做检测，在上下文里加入类似 “心跳检测” （通过定期发送 “状态确认信号”，实时监控目标对象的运行状态，一旦信号异常就触发预警或处理）的机制，实时监控状态。 

Calvin French-Owen：理论上可以，但目前还做不到。我认同你的终极设想，但现在要做好上下文管理，依然很难。目前的解决办法，还是拆分上下文窗口（context window），然后尝试合并信息，但 Claude Code 的会话结束后，上下文的内容就是固定的，这一点还是有局限。

有意思的是，Codex 采用了完全相反的策略，OpenAI 的博客最近也提到了：它会在每次交互后定期做上下文压缩，所以 Codex 能长时间持续运行。 你看 CLI 里的 token 占用百分比，就能看到它会随着压缩操作上下浮动。

Anthropic 要做人用的，OpenAI 要做最好的，以及产品分发模式很重要

主持人：看来 Claude Code 和 Codex 的架构差异很大，Codex 似乎更适合长时间运行的任务，所以二者的使用场景不同，架构设计也天差地别。现在看来，CLI 的工具越来越火，2026 年可能会成为 “CLI 元年”。 

但同时也有观点认为，通用人工智能已经到来，超级人工智能也近在咫尺。目前的代码智能体已经非常智能，但还达不到自主长时间运行的程度，如果计算能力提升十倍，能实现 24 小时甚至 48 小时的自主任务运行吗？Codex 的架构，能适配这种场景吗？

Calvin French-Owen：这是个很好的问题，答案其实藏在两家公司的创立基因里。

Anthropic 一直很注重打造适合人类使用的工具，比如会关注模型的输出风格、语气，以及如何和用户的其他工作流程适配，Claude Code 就是这一理念的自然延伸。在很多方面，它的工作方式和人类很像：比如你要建一个狗窝，人类会去五金店买材料，然后研究如何组装，Claude Code 也是如此。

而 OpenAI 的核心思路，是训练出最优秀的模型，通过持续的强化学习（RL），让它能处理更长期、更复杂的任务，最终实现通用人工智能。所以它的模型，工作方式可能和人类完全不同。还是以建狗窝为例，就像 AlphaGo 的下棋思路和人类不同一样，OpenAI 的模型可能会直接用 3D 打印机，从零开始打印出一个狗窝，完全符合你的需求，过程可能会很长，成品也会高度定制化，甚至有些设计会很怪异，但最终能实现功能。

或许从长远来看，这才是正确的方向，所以很期待两家公司的后续发展。总的来说，OpenAI 的路线似乎是必然趋势，但我个人更喜欢 Anthropic 的思路。 十年前，我还会自己写一些奇怪的脚本，在重构代码或理解代码逻辑时，用它来梳理各类信息，而 Claude Code 给我的感觉，和当年的这种体验一模一样，用它一天，能完成五个人的工作量， 就像给编程装上了火箭助推器，太不可思议了。

主持人：很期待不同规模的公司，会如何应用这类工具。我发现，不管是业余爱好者，还是小型创业公司，都在尽可能挖掘代码智能体的潜力，因为他们根本没时间研究其他方法。创业公司的资金和时间都有限，一切都要以速度为核心。但大公司不一样，他们有太多东西可以失去，还有各种代码审查的内部流程，也已经组建了庞大的技术团队。 

未来可能会出现一种很有趣的现象：一个人组成的小团队，看到其他团队的工作效率低，就会自己用代码智能体做一个原型，效果反而更好。总有一天，这种小团队的成果会超越大团队，行业格局的转变，一定会很有意思。

Calvin French-Owen：其实前几天我试了一款产品，它的用法很有意思：你下载一个桌面应用，它会调用你电脑上运行的 Claude Code，再通过 MCP 服务器和桌面应用通信。这种方式让电脑的使用变得很不一样，你不用征得任何人同意，下载后直接用就行。

在这个变化飞快的时代，产品的分发模式真的太重要了，自下而上的模式远比自上而下好，因为后者的效率实在太低。 公司的首席技术官总会顾虑安全、隐私问题，担心各种突发情况，想要绝对的控制权，但工程师们只会直接装上工具开始用，然后感叹 “这东西太好用了”。

主持人：你说得太对了。我本身是做企业级 ToB 业务的，总觉得自上而下的销售模式能构建一定的竞争壁垒，肯定会有公司找到方法，做出一款人人都能用上的产品，或许先从个人用户切入会是个思路。 

当年的网景导航器（互联网早期最具里程碑意义的网页浏览器）就是如此，它对非商业用途免费，结果很多人下载后用在商业场景，网景就通过追踪 IP 地址，统计不同公司的使用量，然后告知对方 “你们违规使用了，只需购买授权就能继续用”。我很好奇，这种模式现在还能复制吗？ 

Calvin French-Owen：你关于分发模式的观点很有意思，现在很多人甚至会直接根据 Claude Code 的建议做架构决策，他们可能都不知道该用什么分析工具，只要 Claude Code 说用 PostHog（ YC W2020 批次孵化的开源平台 PostHog，核心定位是给开发者和产品团队的 “全能型产品优化工具箱”），他们就会百分百采用。

我做顾问的一家公司，最近聊到了他们的生成式优化策略，也就是如何在聊天机器人中优化展示效果。他们说有件事特别有趣：竞争对手整理了一份行业内必用的五大工具榜单，自己的产品当然排在第一位。明眼人一看就知道这是偏见，榜单里的头部工具就是他们自己的产品。但 LLM 会被这种信息误导，它会整合各类上下文信息，然后判定 “这是行业顶级工具”，接着直接推荐给用户。

我觉得做开发者工具的话，完善的文档、真实的用户口碑，甚至在 Reddit 上的一些讨论，这些都能极大地提升产品的认可度，这也是很多开源项目能快速崛起的原因。

Supabase 就是个典型例子，它去年发展得特别快，部分原因就是它的开源文档做得特别好，详细教大家如何搭建各类功能。只要有人问如何搭建类似 Firebase 的后端事务系统，LLM 给出的默认答案几乎都是 Supabase。我亲自试过很多次，结果都是这样。它就像当年的 Stack Overflow 和谷歌搜索一样，占据了互联网的信息入口，现在大家甚至都不用谷歌了，想想真的很神奇。而且这种模式对开源项目的利好是不成比例的。

不知道你有没有看到，Ramp 公司最近发了一篇博客，讲他们如何打造自研的代码智能体，里面提到他们用开源代码作为框架，因为模型可以直接读取源代码，理解其工作逻辑。我对开源产品一直这么做：克隆代码仓库，然后启动 Codex 或 Claude Code，让它讲解代码的逻辑，用起来特别实用。

未来公司会变小，数据很重要

主持人：我们不妨畅想一下四十年后的未来：软件、数据库、访问控制依然存在，但软件的核心会高度个性化。访问控制、权限分配这类事，依然是大家开会讨论的重点，也就是所谓的 “管理者模式”，但公司的其他所有功能、规则，都由员工通过自己的 Claude Code 这类工具定义。可能还是 CLI，也可能是由大量智能体组成的协作体系，那会是一种怎样的场景？ 

比如想象一下，现在如果有公司要接入 Segment，我们复刻代码仓库，给他们一个专属版本，让它在自己的服务器上运行；如果他们想做修改，只需在聊天窗口告诉智能体，智能体通过代码循环完成编辑，而 Segment 总公司推出新功能后，智能体还能自动完成版本合并。 

Calvin French-Owen：我完全能想象出这种场景，这也是我一直在思考的。虽然不知道这个未来还有多远，但最终，每个工作的人都会有自己的云电脑和专属的云智能体团队，智能体替自己处理各类事务，彼此之间也会沟通协作。 这就像有一个 超级执行助理，它会告诉你 “这些是你需要关注的事”“你可以快速做这些决策”“这件事需要你多花时间”“你该和这些人见面沟通”。我觉得，人与人之间面对面交流、交换想法的需求，永远不会消失，至少我能从这种交流中获得很大的满足感。除此之外，会有大量的智能体替人类执行任务，实现各类工作的自动化。

未来的公司，平均规模可能会变小，但数量会更多，能做的事也会更多。 我还很好奇，Paul Graham 提出的 Maker Schedule（创作者日程：给做核心创作 、研发的人用的，需要大块、连续、不被打断的时间） 和 Manager Schedule（管理者日程：给做管理、协调、沟通的人用的，时间是碎片化、以小时为单位的，充满会议、沟通、临时决策，习惯频繁切换事务），未来会演变成什么样子。

在 YC，我们的工作基本都是 Manager Schedule（管理者日程），这让我们很难有时间自己写代码、做产品。但现在有了代码智能体，一切都变了，很多合伙人开会时，就像这期播客刚开始时我做的一样，让智能体后台运行处理任务，自己专注开会，等会开完，任务也完成了。

主持人：没错，就是利用碎片化时间。以前编程，至少需要四个小时的整块时间，否则根本不值得开始，对吧？这其实也反映出编程方式的巨大变化：以前写代码，你需要把所有类名、函数、关联的代码都记在脑子里，构建自己的“上下文窗口”，这个过程需要好几个小时，所以想用十分钟的碎片化时间编程，根本不可能，只会让人觉得沮丧。 

Calvin French-Owen：我觉得未来的核心基础能力之一，依然是保持数据模型的一致性，而核心的记录系统，也有机会率先实现智能体化。 现在我们的工作，还是高度依赖数据库，以及底层的 SQL 或 NoSQL 查询，但未来或许会出现一种工具，能为定制化软件的各类视图，自动生成所需的所有数据。

未来的软件世界，会有大量定制化视图，但数据的准确性，依然是核心前提。 数据的重要性不言而喻，这一点从很多公司的做法中就能看出来：比如很多公司通过 API 或 MCP 开放数据访问权限，而 Slack(全球最主流的企业级团队协作与即时沟通平台，常被称作「硅谷版钉钉 / 企业微信」) 就收紧了 API 的权限，因为他们不想让用户把平台上的所有数据都导出，然后基于这些数据搭建智能体应用。

主持人：你对这款智能体的了解很深，那你觉得，这类工具普及后，哪种类型的工程师会受益更多？ 

Calvin French-Owen：总的来说，工程师的资历越深，受益就越多。因为智能体特别擅长把想法转化为实际行动，如果你能用几句话清晰地描述需求，就能立刻让它落地。

我在浏览开源代码仓库时，经常会有这种感受：看到某处代码，觉得可以优化，只要把这个想法告诉智能体，让它去执行，最后等待反馈就行。这种方式能极大地提升效率，放大个人的影响力。

其次，能判断哪些代码修改在架构层面是合理的、哪些是不合理的，或者能准确判断该在哪个节点向智能体发出指令，这一点也很重要。我觉得做事有条理、带有 “管理者思维” 的工程师，会更适配这类工具。

而且目前来看，这个领域还缺少一款核心产品，比如类似 Conductor 这样的工具，能整合你所有的会话，提醒你 “这个任务已经完成，需要你确认”“你该把注意力转到另一个任务上了”。Conductor（核心解决 AI 编程的 “失忆问题）这类工具，应该给智能体加上上下文管理功能，其实人类也需要这样的上下文管理工具，这一点是毋庸置疑的。

主持人：如果让你回到大学，重新学习计算机科学，让你自己制定课程表，你会选择学习哪些内容？ 

Calvin French-Owen：就我个人而言，理解各类系统的工作原理，依然是最重要的。 比如 Git、HTTP、队列这类数据库，了解这些系统的基础概念，至关重要。另外，我会专门安排一个学期 ，每周都动手做项目，尽全力挖掘模型的潜力。

在使用模型的过程中，你会发现，遇到问题时，总能向上层抽象，让模型来解决。比如你可以给模型一个 “实现” 命令，让它完成计划的下一阶段；也可以给一个 “全部实现” 命令，让它分阶段执行，生成新的子智能体；还能给一个 “校验” 命令，让它自查成果。模型的能力边界一直在变化，所以多动手尝试，是很有必要的。

还有一件事让我觉得很有意思，我特别想教 18 到 22 岁的年轻人做产品。我们这桌人，都做出过用户真正需要、真正喜欢的产品，该怎么把这种能力教给年轻人，是一个值得思考的问题。 我很好奇，五年后的年轻人，会不会在产品审美等方面远超现在的我们？因为他们能借助智能体，做出更多的尝试，产出更多的成果。他们本就该如此，不是吗？他们的产品落地速度、接触现实的机会，应该是上一代人的十倍。

主持人：说到这里，我有一个疑问，不知道你有没有这种感受：我小时候，妈妈总跟我说 “别一心二用，根本没认真听我说话”。这话其实有道理，我当时确实盯着电脑，没认真听，但我发现，我比父母那一代人更擅长多任务处理。而现在的年轻人，比我们更厉害，因为他们成长在互联网时代，每天接触抖音这类短视频，应对各种碎片化信息。我觉得，未来既需要能深度思考的人 —— 他们能专注观察、理解问题、解决问题，也需要能灵活切换场景的人 —— 他们能同时处理多个任务，不断切换上下文，也就是所谓的 “注意力缺陷多动障碍模式”。 

Calvin French-Owen：没错，新一代的年轻人特别擅长这一点。我一直觉得，有一种聪明人，或许是带有注意力缺陷多动障碍的特质，他们脑子里同时酝酿着很多好项目，但从来没有真正完成过一个。我自己可能就有点这种性格。我之前发布了自己的氛围代码，其实如果不是 Claude Code，我根本完不成。

我觉得，有些人的大脑就像有十个分支同时运转，但一天的时间有限，根本没法把所有想法都落地，所以项目总是半途而废。而现在，Claude Code 能帮我把所有想法都落地。 你在博客里也提到过，用它的感觉就像玩电子游戏，总有新鲜感。比如你开始做一个项目，做到一半觉得无聊，又有了新的想法，想先做新想法，再回头做原来的项目，以前这么做，很容易半途而废，但现在有了智能体，两个项目最终都能完成。

主持人：十岁的孩子每天都有写作作业，昨天他第一次用人工智能写作业，我一看就知道，那些表达根本不是一个十岁孩子能写出来的。 

这让我想到，我们现在和很多 18 到 22 岁的年轻人合作，他们有实习经历，但没有做过管理工作，不懂产品市场匹配后的运营逻辑 —— 当你面对数百万的任务队列、数十万的错误日志时，才是真正的管理工作。这份工作其实很枯燥，要逐行排查错误日志，还要在后台手动确保产品对所有用户都能正常运行。

新一代的开发者，该如何理解这些内容？Claude Code 这样的智能体，能教他们架构设计这类知识吗？还是说，他们只能自己踩坑试错，在摸索中成长？

Calvin French-Owen：我做产品的过程中，花最多时间思考的，就是产品的核心范式：用户现在需要理解哪些内容？他们能借助哪些基础能力，实现自己的各类需求？ 我总喜欢用 Slack 举例子，它其实算不上什么全新的概念，在此之前已经有很多聊天工具了，但它把频道、消息、互动功能做的极简，普通人一看就懂，知道该怎么用，这就是它的成功之处。但一旦用户习惯了这种模式，后续再想改变就很难了，比如想改成以文档为核心，或者现在想加入智能体功能，都很难改变用户的固有认知。所以我做产品时，从一开始就会仔细考虑这一点，因为给代码智能体设定的核心规则，会成为它一直遵循的准则，并且不断拓展延伸。

代码智能体的制约因素有哪些

主持人：说到这里，我很好奇，如果现在让你用当下的工具，重新打造 Segment，你会怎么做？ 

Calvin French-Owen：Segment 的业务其实很有意思，我们最初的核心，是做各类集成功能：把相同的数据，对接至 Mixpanel、Kissmetrics、谷歌分析等平台。以前写这类集成代码，繁琐又困难，所以用户愿意付费使用。但现在，这项工作的价值几乎降为零，甚至很多时候，你直接告诉 Claude Code 或 Codex“我想这样做数据映射，需要这个特定功能”，它就能精准实现，完全契合你的需求。所以 Segment 的集成业务，价值已经大幅缩水。

但保持数据管道（data pipeline）的稳定运行、实现业务流程的自动化， 比如客户注册时，通过 Customer IO 自动发送邮件、管理用户群体，这些功能的价值依然存在，而且还有很大的拓展空间。

比如借助这些数据构建完整的用户画像（user profile），再让小型大模型（LLM）智能体分析：该如何给用户推送邮件？用户登录时，是否要调整产品的部分功能？是否要根据用户的不同特征，设计差异化的引导流程？这些都是很有意思的方向，而且都能通过智能体实现。

这也是我会做出的核心改变：就像你之前说的，向技术栈上层迁移，摒弃底层的基础开发工作，更多聚焦在营销活动这类更抽象的业务层面发力。

主持人：没错。我特别惊讶的是，Claude Code 仅凭我正在做的项目的上下文，就能精准理解我的需求和意图。我至今依然觉得代码智能体很神奇：你把代码仓库的副本给它，留个简单的指令，比如 “实现这个功能”，它就能完成。大多数情况下，它根本不知道你的公司是做什么的、你的用户是谁，或许因为训练数据里有我的信息，它知道我是加里，但它能完成任务这件事，本身就令人难以置信。这也能看出上下文的重要性，对吧？如果它捕捉到的上下文信息有误，就会偏离方向；如果遗漏了关键信息，就会重复造轮子。 

你觉得目前代码智能体的发展，还有哪些制约因素？上下文窗口的限制依然存在，但现在的窗口已经很大了，虽然还做不了大规模的架构重构，但很多任务都能完成。Opus4.5 模型的智能程度有了很大提升，带来了很大的突破，我不知道这是预训练还是后训练的成果。除了基础的模型智能、前沿模型的能力和上下文窗口，还有哪些因素能推动它的发展？

Calvin French-Owen：我依然觉得，上下文窗口是目前最大的制约因素。观察 Claude Code 的执行过程就会发现，它会把任务委托给多个不同的上下文窗口，每个窗口完成任务后，会反馈总结后的信息，所以模型其实无法获取完整的上下文。如果一个任务的复杂度太高，单个上下文窗口根本容纳不下，那么无论怎么压缩，都无济于事。Anthropic 的子上下文窗口委托策略，确实很实用，但这依然是一个难以突破的壁垒。如果每次都能有百万级 token 的上下文窗口，效果会好得多。

而且我们还需要找到更好的方法，专门训练模型处理长上下文的能力。 互联网上有大量的训练数据，能让模型预测下一句话、下一个段落是什么，但如果有 8 万个 token 的上下文，模型需要根据其中 2 万个 token 的信息，判断下一步该做什么，这就困难多了。

我觉得，集成和编排能力，正在成为新的制约因素。 这一点在代码审查中体现得很明显：合并代码时，谁来审核？还需要人类审核吗？该如何验证代码修改的合理性？还有，如何从各类工具中精准获取上下文，比如你提到的 Sentry 错误监控工具，如何让它自动匹配 PR，先将修改推送给部分用户测试，效果好再全面上线？这些自动化功能，都还需要逐步搭建。

我还发现，测试的重要性远超我的预期。我刚开始用 Claude Code 的前两三天，完全没写测试用例，或者说写得很少，结果效率很低。直到有一天，我决定 “今天专门做重构，把测试覆盖率做到 100%”，从那之后，我的编程效率直接飙升，模型能精准完成任务，而且不会出问题。 我几乎不用手动测试，因为测试覆盖率足够高，代码的稳定性也有保障。这和很多公司在编程之外的提示工程工作很像，大家都在采用 测试驱动开发的 模式。

我们之前和杰克・赫勒做过一期节目，他提到一个重要的范式转变：做出优质的提示词，核心也是测试驱动，测试用例其实就是评估标准。

主持人：目前还是有一些流程会出问题，我觉得需要一款能对接 Stack Overflow（全球最大、最权威的程序员专属问答社区） 的 Claude Code，相当于专属的智能体版 Stack Overflow。 

我最近就遇到一个奇葩问题：我本想设置任务队列的优先级，结果模型自动生成了一个带逗号的字符串，它以为这个语法能生效，但系统实际需要的是 JSON 数组，结果所有任务都无法运行。然后我看着 Claude Code 花了 30 分钟，遍历了 Rails 主动任务框架几千行的源代码，一步步排查问题，最后居然找到了漏洞。

当时我真的惊呆了。想想十年前，我遇到这种问题，只会去 Stack Overflow 或 Rails 的博客找答案，然后发现 “原来这个低级漏洞一直没人修，大家都以为能直接用逗号分隔的字符串，其实必须改成数组”。现在想起来，真的特别搞笑。

我觉得这也是思考未来发展的难点：有些事，人类在 CLI 里一眼就能看出问题，但智能体却做不到。就算把它的智能程度提升 10 个虚拟智商点，它能解决这类问题吗？恐怕还是只会觉得 “这就是个普通的字符串而已”。

Calvin French-Owen：没错。我觉得 智能体的记忆功能，也是一个很有意思的研究方向。

Claude Code 已经做了相关尝试，Codex2 也一样，它们会把所有的会话记录以文件的形式保存。未来或许可以给智能体加一个工具，让它能读取过往的会话记录。不过目前来看，智能体之间的协作，还缺少一个核心环节。

如果能有一个方式，让同事之间的 提示词能智能共享，比如你遇到了一个问题，发现另一个同事布莱恩之前已经解决过了，你们能共享这个解决方案，那就太完美了。我觉得未来或许会出现 模型生成的维基百科，或者类似格拉奥佩迪亚的知识库。

Codex 写代码时，能明显看出它的 “个性”，它会做很多人类不会做的事，有点像 AlphaGo 的思路，比如它会写 Python 脚本，修改文件系统的部分内容。这种行为很有趣，是一种模型习得的、和人类截然不同的方式。但对我来说，它在调试复杂问题时的表现，堪称超人类，很多 Opus 模型解决不了的问题，Codex 都能搞定。

主持人：能举个具体的复杂问题的例子吗？ 

Calvin French-Owen：比如并发问题或者命名问题。我发现模型其实在并发处理方面的表现还不错，真正的难点在这类场景：一个请求需要调用多个不同的服务 —— 就像你之前提到的，处理带逗号的内容时的序列化和反序列化问题。模型需要跟踪这类复杂的操作逻辑，或者更新复杂的用户界面状态。如果涉及的文件太多，Opus 模型往往会遗漏关键信息，但 Codex 能精准捕捉到。

主持人：确实很有意思。那你预测一下，这类代码工具未来会如何发展？ 

Calvin French-Owen：这个领域的发展真的很有意思，我感觉自己就像一个新来的探索者，明明知道这个领域在飞速发展，却因为一直处于 “管理者模式”，没有实际参与。直到有一个项目出现，我决定全身心投入，现在才算真正踏入这个领域，虽然感觉有些陌生，但一切又和我记忆中编程的本质一模一样。我觉得大家应该都有这种感受，而最重要的事，就是多动手尝试，因为这个领域的变化太快了，每隔几个月就会有新的突破。

我觉得未来，能把代码智能体的价值发挥到极致的人，会是那些带有 “管理者思维” 的人，他们擅长用特定的方式引导智能体的工作流程。在某些方面，他们还会像设计师或艺术家，能精准判断产品该包含哪些功能、可以舍弃哪些内容。而且他们会很擅长思考自动化的实现方式，以及判断智能体在哪些环节会遗漏上下文信息。

说个有趣的事，我最近用 Codex 做 Rails 项目，发现一个很明显的问题：OpenAI 里没人关注 Rails 框架。这其实也能理解，Rails 算是一种比较老旧的语言，用起来也比较奇怪，只是我十年前深入研究过它，现在用起来还是很有感情。这也让我发现一个道理：任何人都能做出一款产品，但做出用户真正需要的产品，却无比困难，哪怕你像 OpenAI 一样，拥有无限的资源。

如果 Codex 的研发人员现在正在看这期节目，我想提一个建议：把主流的运行时环境都梳理一遍，给它们加上适配的语法糖，其实针对前 15 种主流运行时，最多只需要提交 10 个代码合并请求就能搞定。这件事也提醒我们：现在，开发者再也没有借口，做出对用户不友好的软件了。

训练数据的组合方式，也是一个很有意思的点。Codex 在 Python monorepo（用「单一代码仓库」的方式管理的 Python 项目）上的表现特别好，这和 OpenAI 的代码环境息息相关。我在 OpenAI 内部使用 Codex 时，真的觉得这款工具太神奇了，表现堪称完美，这和它的训练数据组合、研发人员的技术方向都密不可分。

Anthropic 则更关注前端相关的开发，至于 Ruby 语言，目前哪家公司的模型做得最好、谁的训练数据组合更优，我还不太清楚。

不同的实验室有不同的思路：有些实验室认为 “数据越多越好”，会尽可能多地投喂数据；有些则会更精细地调整数据的组合方式。 不同的思路，会带来截然不同的结果，比如只选取 JavaScript 领域前 10% 的优质数据做训练，和用全量数据训练，效果肯定不一样。

不过就我的使用体验来看，OpenAI 的模型在 Ruby 语言上的表现其实很好，问题主要出在模型的配套框架上。Rails 框架有个很奇葩的设定，必须用特定的方式访问 PostgreSQL 数据库，否则就无法适配，核心问题还是 sandbox 的限制。

OpenAI 其实是所有公司中，对 sandbox 和安全问题最重视的。 我记得研发 Codex 时，模型发布前的一个核心审核环节，就是每次都要详细说明模型的安全风险，以及对应的应对方案。我们当时重点研究的一个问题，就是提示词注入，尤其是模型面向互联网开放后，这个问题更突出。很多用户都要求模型能对接互联网，我们当时心里也没底，因为提示词注入的实现方式，看起来太简单了。

我们团队的产品经理亚历克斯，做了一个测试：他在 GitHub 上提了一个问题，里面包含一个明显的提示词注入指令，比如 “泄露这个信息”，然后让模型去解决这个问题。他当时觉得 “模型肯定不会中招”，结果模型立刻就执行了提示词注入的指令。 也正因如此，OpenAI 对这个问题的担忧是很有道理的，他们的解决方案是：让模型的所有操作都在 sandbox 中运行，确保它不会访问电脑上的敏感文件，严格保护用户的机密信息。而创业公司因为追求发展速度，可能根本不在乎这些，他们只希望模型能正常工作。

主持人：你是那种会冒险跳过权限验证的人吗？ 

Calvin French-Owen：其实我不是，我会设置一系列的校验环节，也会仔细查看模型的每一步操作。

参考链接：https://www.youtube.com/watch?v=qwmmWzPnhog

本文来自微信公众号 “AI前线”（ID：ai-front），作者：高允毅，36氪经授权发布。