#模型时代# OpenAI 总裁 Greg Brockman：我眼睁睁看到，软件开发正在迎来一次“复兴”。

如果你最近没怎么用这些新工具，那你很可能低估了自己错过了什么。因为从去年 12 月开始，像 Codex 这样的工具能力出现了一个“台阶式”的跃升——不是慢慢变好，而是突然上了一个档次。昨天我们团队里有几位很强的工程师跟我说：从 12 月之后，他们的工作方式已经发生了根本变化。以前他们最多用 Codex 写写单元测试；现在它基本能把大部分代码都写出来，还能替他们做很多运维、排错和调试的活。

当然，不是所有人都已经用到这个程度。有些人还没跨过这一步，但原因往往不在于模型能力不够，而在于别的因素——比如习惯、流程、权限、组织方式等等。

我觉得现在每家公司都面对同一个机会：怎么把这件事用对、用好。它有点像当年拥抱互联网、或者上云一样——机会很大，但走对路径需要认真思考。这篇分享讲的是：我们在 OpenAI 里，正在怎么把团队重新“装备”起来，转向以“智能体式软件开发”为核心的工作方式。我们也还在学习、迭代中，但目前我们的想法大概是这样：

作为第一步，我们希望在 3 月 31 日之前做到两件事：

1）只要是技术任务，人类的第一选择应该是先和一个“智能体”交互，让它来推进工作，而不是一上来就打开编辑器或终端自己敲。
2）人类默认使用智能体的方式，既要被明确评估为安全，也要足够高效——高效到大多数工作流不需要再去申请额外权限、走额外审批。

为了达到这个目标，我们几周前给团队的建议是：

第一，真的花时间去用一用这些工具。
工具本身会“自我推销”——很多人几个月前从 codex web 用着用着就流失了，但最近在 Codex 里的 5.2 版本上重新试过之后，体验非常惊艳。不过也有很多人因为太忙还没来得及试，或者一直停留在“它能不能做 X”的设想阶段，而不是直接上手试一下。
我们建议每个团队指定一个“智能体负责人”，专门琢磨怎么把智能体真正嵌入团队工作流；在少数几个固定的内部频道里分享经验和问题；甚至可以搞一次公司级的 Codex hackathon，用一天集中把用法打穿。

第二，把经验写下来：做 skills，也写 AGENTS.md。
你参与的每个项目，都应该有一份 AGENTS.md：它是给智能体看的“项目使用说明书”。只要智能体在哪件事上做错了、卡住了，就把教训补进这份文档里，让它下次别再犯。
另外，只要你让 Codex 成功完成了某类任务，就把这套“怎么让它做”的方法写成 skills，提交到共享仓库的 skills 目录里，方便团队复用。

第三，把团队依赖的内部工具盘点清楚，并让智能体能用起来。
把你们常用的内部工具列成清单，并确保有人负责把它们改造成“智能体可调用”的形态，比如做成 CLI，或通过 MCP server 暴露出来。

第四，让代码库更适合“智能体优先”的开发方式。
模型变化太快，这块还在探索期。但方向很明确：测试要跑得快；组件之间的接口要更清晰、更高质量——这些会直接决定智能体能不能稳定、高效地推进任务。

第五，坚决拒绝“糊弄式代码”。
大规模管理 AI 生成代码，是一个正在出现的新问题。我们需要新的流程与约定来守住质量底线：任何合并的代码都必须有明确的人类负责人；做 code review 时标准不能因为“是 AI 写的”就降低；并且要确保提交者真的理解自己提交了什么。

第六，把基础设施补起来。
工具本身变得更强、更好用了，但围绕它的基础设施还有大量空白值得建设：比如可观测性、追踪机制（不仅追踪最终提交的代码，也追踪智能体一路是怎么做决策、怎么走到结果的）、以及对智能体可使用工具的统一管理等等。这些都可以由内部用户反馈来驱动改进。

总之，像 Codex 这样的工具带来的不只是技术变化，更是一种深层的文化变化，后面会牵动很多连锁反应。我们鼓励每一位管理者带着团队一起推进这件事，同时也要认真想清楚还需要哪些配套动作——比如上面第 5 点提到的：除了“有人负责 + 评审不放水”之外，还能用什么机制，避免那种“功能看似正确、但维护性很差”的代码悄悄侵蚀代码库。