AI能够快速生成代码，但真正考验开发者的，是判断何时进行删减与优化。首先要明确几个核心判断：当前的AI工具在“生成”方面确实表现出色，但随之而来的问题是代码变得臃肿，以及后续维护压力的增加。

“如果有研究团队在关注，恳请让模型更擅长删除代码吧。”

OpenAI Codex应用负责人Andrew在播客中笑着讲出了这句话。

但拥有项目经验的人都明白，这绝非玩笑。

当下的AI太擅长添加内容了。让它修复一个bug，它可能顺手修改出几层无关的代码；让它实现一个小功能，它能拉出一堆新文件；让它补充一个边界条件，它有时会把原本清晰的逻辑绕得更加复杂。

AI生成代码确实很快。但与此同时，代码库也更容易变得臃肿。

它把一个关键问题摆到了所有开发者面前：

当AI越来越擅长写代码，谁来负责删除代码？

Andrew提到，OpenAI内部90%的人都在使用Codex。不是90%的工程师，而是整个公司90%的人员。

这意味着Codex已经不再仅仅局限于纯工程场景。文档、数据、邮件以及各种工作流，它都开始接手处理。

AI工具越深入工作流，开发者需要处理的任务就越不止是“让它写出来”这么简单。

你还需要判断：任务是否拆分正确？能否上线、能否维护？哪些部分该删除？

代码生成速度提升，问题也随之而来

Andrew表示，编写代码这件事已经不是最重要的环节了。最珍贵的是判断和筛选能力。

别误会，这绝不是指写代码不再重要。代码依然需要能够运行、可维护、可上线。过去团队最担心的是“想法无人实现”，如今这个门槛被AI大幅降低了。

以往开发一个新功能，通常需要先写PRD、排期、协调设计、找工程团队。大家在真正开工前反复讨论，是因为成本高昂，试错一次的代价过于昂贵。

现在，很多想法可以先交给AI尝试一下。甚至同一个方向，可能同时涌现出几十个原型。

Andrew谈到，公司里可能有90个没有充分协调的小团队，都在尝试同一个功能的不同实现方式。

效率确实提升了，但另一个问题也随之出现：产出太多了。

哪个原型该继续推进？哪个需求根本没有想清楚？哪段AI生成的代码只是看起来能运行，但未来会坑了维护的人？

Andrew提到的“品味”和“筛选”，放到工程语境中，不是什么审美鸡汤，而是实实在在的判断力。AI能把第一个版本做出来，但它不知道这个版本是否值得保留。

以往程序员的稀缺性，常常体现在“我能不能把东西写出来”。接下来，会更像“我能不能判断这个东西该不该存在”。

PRD并未消亡，别被一个能运行的Demo误导

访谈中还有个颇具反常识的观点。现在很多人喜欢说，PRD已经消亡，原型才是新的沟通方式。但Andrew没那么极端。他的观点更接近：实现成本降低以后，制作原型确实更容易，但文档仍然有它独特的位置。

要澄清一个模糊的方向，文档可能更合适。

要让团队感受一个交互流程，原型更合适。

要验证一个技术风险，那就先做实验。

Claude Code、Codex、Cursor都能很快拉起一个页面、一个API、一个脚本。很多团队会不自觉地认为“有东西在运行”就等于“问题已经想明白了”。

开发者都知道，最麻烦的bug通常不是少写了一个if条件。

而是一开始需求就出了错。

AI会让文档、原型、代码、实验都变得成本低廉，但它不会替团队决定现在该用哪一种表达方式。这里判断错了，后面生成得越快，返工也越快。

未来最稀缺的，可能是善于收拾残局的人

Boris Cherny也曾发布过一条相关的推文。他从Claude Code团队的视角，将未来产品团队分成了五类角色：原型师、构建者、收尾者、增长者和维护者。

最值得开发者关注的是“收尾者”。

收尾者不是打杂的人，而是将AI做出来的半成品整理到真正可用状态的人。

AI现在特别擅长制作Demo，也特别擅长留下烂摊子：重复逻辑、奇怪的抽象、未处理的边界条件、风格不统一的UI、没有测试的功能，以及一堆“现在能运行，但没人敢修改”的代码。

Andrew谈到，模型现在通常会增加复杂度。他甚至开玩笑说，希望模型能更擅长删除代码。

未来团队里可能不缺会用AI快速制作Demo的人，缺的是能把Demo转化为产品的人。

这个人需要能看懂AI写出来的内容，敢于删除，敢于合并，敢于重构，也能判断哪些功能根本不该上线。

有些代码不是需要优化，而是该直接扔掉。

有些功能不是没做完，而是一开始就不该做。

有些Agent跑出来的结果，看起来很努力，实际上只是在制造维护债务。

AI越擅长生成，越需要有人负责收拾。对开发者来说，这个能力不会写在简历第一行，但会决定一个项目能否活到第二个月。

岗位边界会模糊，但别丢掉专业能力

Andrew还聊到了OpenAI内部的角色变化。Codex团队中，设计师开始了解工程，产品经理会写代码，工程师也参与产品判断。

当然，这并不意味着未来人人都是“全能构建者”。如果公司简单宣布“不要产品经理了，大家都去做构建者”，很可能把产品这门专业中积累下来的方法和教训一起丢掉。

这话对技术团队同样适用。

AI会让岗位边界变得模糊，但不会让专业能力消失。会写代码的产品经理更有价值，懂产品目标的工程师更有价值，会用AI做原型的设计师也更有价值。但这不等于所有人都可以无差别替代所有人。

开发者不用焦虑成“全能选手”，但也不能只守着编辑器那一亩三分地。

你需要知道业务目标是什么，也要看得懂设计约束；你要会给Agent分配任务，也要能判断它交上来的东西是否有价值；你能写代码，也要能从代码中抬头看用户。

Codex这类工具，已经把角色边界往前推了一大步。

Codex未来可能不是IDE，而是工作入口

访谈后半段，Andrew讲了一个OpenAI内部的视频案例。非工程岗位也在使用Codex处理工作流。

OpenAI内部有位视频同事Brent，需要剪辑Codex发布用的视频。他一开始只是尝试Codex能否编辑视频。结果Codex发现他用的是Premiere Pro，先通过编辑背后的文件做了一部分操作；遇到做不到的地方，又给自己写了一个Premiere Pro扩展，用扩展去控制Premiere里的标记。

Andrew说，Codex不一定要替代Premiere、Excel、浏览器、Linear、Slack这些专业工具。它更像一个入口，负责理解任务、调用工具、交接结果。

也就是说，Codex以后可能不是开发者一直盯着的IDE，而是很多工作的起点。

你想剪视频，它去接Premiere Pro；你想处理表格，它去接Excel；你想查资料，它去接浏览器；你想推进一个研发任务，它去接代码库、Issue、PR和CI系统。

这对开发者的影响很大。

过去我们做应用，默认是人来点按钮、填表单、看页面。但接下来，越来越多应用还要被Agent调用。

所以Codex这类工具真正要改进的，不只是写代码这一步。它在把“打开一个工具干活”，变成“先把任务交给一个入口，再让入口去调度工具”。这也是为什么它会从IDE往外走，进入视频、文档、数据、邮件和更多工作流。

程序员不会消失，但工作重心会向后移

值得开发者警惕的是：AI把工作的前半段推得太快了。

以前很多问题可以往后拖。需求不清，等产品再补；体验粗糙，等设计再磨；代码脏了，先上线以后再重构；线上出事，再拉测试和运维兜底。

现在，Demo一天能做十个，Agent一晚能改几千行，工具还能接Premiere Pro和Excel。速度上去了，判断、审查、权限、复杂度、维护成本都会更早冒出来。

Boris所说的“收尾者”，放在这里就不只是一个新岗位名。它更像开发者接下来必须掌握的一项能力：把AI生成的东西收回来，拆开看，删掉不该要的，留下能维护的。

代码越容易生成，就越需要有人负责收尾。