Alexander Embiricos：然后--真正的代码审查。我听到很多人，尤其是在开源世界里，都在抱怨一个问题：大量的AI slop（AI垃圾代码）。人们会直接往开源仓库里提PR（Pull Request），但这些PR很烂。提交的人可能根本没有测试过，甚至也没有审查过代码。我认为这是一个真实存在的问题。
因此，在Codex的常见实践中，就是让Codex审查它自己生成的PR或修改。而Codex在这方面真的非常强。我们明确地训练过模型，让它擅长做code review。这包括：让它擅长给出高信噪比的反馈，也就是说，它几乎不会给出误报的批评。这意味着，当它真的给出反馈时，你是可以高度信任的。
所以我们不仅鼓励团队内部和外部的人直接让Codex来review，你甚至还可以把它设置成自动审查。在OpenAI，几乎所有代码，只要你push到Git repo，都会被Codex自动审查。事实上，有一个挺有意思的现象：一些还没怎么用过Codex，或者很久没用的人，会用Codex去审查其他模型写的代码。结果他们往往会说："靠，我可能真的应该直接用Codex来写代码。"
Harry Stebbings：你刚才说了一点很有意思：对于那些可能还没试过，或者正在回归使用的人来说，你是如何看待这个品类的留存的？我记得Tom Blomfield（YC合伙人）几个月前发过一条推，一直让我印象很深。他说了一件很奇怪的事：在不同提供方之间切换的成本其实非常低。无论是Cursor、Raw Code，还是Codex--老实说我已经记不清他当时具体说的是哪个了。那用户到底有多"粘"？你们又是如何思考留存的？
Alexander Embiricos：我们在Codex上采取了一种有点反直觉的做法：就是把它构建得非常开放。比如说，Codex的核心执行框架是开源的，而且我们一直在努力让切换成本变得更低。
举个例子：当我们去年首次发布Codex时，我们确立了一个约定，叫agents.md。这本质上是一个文件，你可以在里面给agent写指令。我们没有把它命名成Codex.md，因为我们希望它是所有agents都可以使用的通用标准。现在，几乎所有agent都在使用agents.md，除了Claude（这其实也挺酷的）。
就在上周，我们还推动把skills（技能）--也就是我们用来给agent提供指令和脚本的标准--放进一个中性命名的文件夹，叫agents，而不是codec之类的名字。结果，除了"老熟人"之外，几乎所有人都跟进了。我觉得这对开发者来说非常棒，他们拥有了更多选择，而我们也在努力让他们更容易尝试不同的东西。
当然，话说回来。这些编程任务--也就是你让agent写代码的场景--其实是非常"密封的"。我的意思是，如果用电视剧来类比，它更像是单集剧。你有一个开放的agent文件，任何agent都能读；你有skills，任何agent都能用；你让agent写代码，它生成一个patch，然后这个patch进Git。
所以在这个流程里，前后两端都非常中性、vendor-neutral，这使得在不同工具之间切换非常容易，但当agents开始做的事情不再只是写代码，而是更通用的工作--无论是为软件工程师，还是为任何builder，它们就必须开始和其他系统打交道。
比如，你的agent开始和错误监控系统对话，或者和Google Docs之类的系统交互。那我认为，这些agents就会变得非常"粘"。因为，一旦你决定把agent接入这些系统，这本身就是一个高粘性的决策。
如果你是一家企业，真正去信任一个agent，让它访问这些工具，同时确保它有可靠的安全护栏、sandbox（沙箱环境）和控制机制，我认为这是至关重要的。而且这件事，你不会想反复做很多次。所以我们在构建Codex的时候，就已经预见到这一点。因此我们采用了最保守的sandboxing（沙箱隔离）方案。Sandboxing本质上是一整套操作系统层面的控制，用于限制agent能做什么。
