当 AI 把代码写快之后，瓶颈移到了哪里

一场关于 AI 与工程实践的对谈，从一段演示开始：代码由 AI 生成，测试全部变绿。看上去，过去最耗时间的编码环节已经被大幅压缩。但对谈中的两位嘉宾很快把问题拉回现实——测试变绿，只说明代码符合测试；它并不说明测试写对了，更不说明做出来的东西是客户真正需要的。

当“写代码”不再是主要瓶颈，工程的重心到底去了哪里？这是这场对谈真正想回答的问题。

代码提速后，瓶颈没有消失，而是向前后两端移动

矢上给出的经验很直接：他们准备了 AI 驱动的开发环境，也已经把 AI 用到一部分生产代码的开发中，编码所需的时间确实在下降。但省下来的时间并没有让整个交付变轻松，反而让压力更清楚地暴露在编码之前和之后。

往前，是要决定“到底做什么”。客户真正的问题是什么，哪些需求必须被满足，哪些只是表面要求，例外情况又该怎么处理——这些判断如果没做清楚，AI 只会更快地生成一个错误答案。往后，是验证和运营：生成出来的行为是否符合业务规则，出了问题谁来判断，系统进入生产后如何维护。编码越快，这两端的欠账越显眼。

在对谈中，矢上把最困难的部分指向了“语言化”。金融等行业有大量运行了十几年、几十年的遗留系统，很多规则只存在于具体操作和人的经验里，并没有被完整写下来。即便是一家成立约八年的公司，也仍然有大量流程没有被清楚表达。所谓语言化，不是把旧文档整理得更漂亮，而是把那些“大家一直这么做、但没人说清楚为什么”的判断、例外和责任，变成可以被讨论、被验证、最终可以被系统承接的定义。

这件事很难由 AI 代劳。AI 可以读文档、生成代码，却无法自动知道一个从未被记录的业务例外。需要有人去问、去看、去把模糊的说法拆成具体条件。需求定义重新成为工程的核心工作，不是因为工具变笨了，而是因为工具把“没想清楚”的代价放大了。

工程师的新位置，在客户、业务和代码之间

对谈里有一个很现实的观察：过去工程师的成长，很大程度上来自“看着前辈怎么做”。新人跟在资深工程师身边，从日常工作和项目推进中逐渐学会判断。但今天做 AI agent 的工程师，往往找不到一个完全对应的前辈角色。工具、工作方式和交付对象都在变，可传承的经验还没有形成稳定的形态。

这不意味着技术基础不重要。相反，对谈中提到，技术底子扎实的人更容易进入新领域；真正稀缺的，是既懂系统设计、又做大规模实现和上线，还能直接面对客户的人。只会在既定需求下写代码不够，只会讲概念也无法把系统真正落地。

新的工作方式更接近这样一条链路：先和客户或业务团队持续对话，理解他们真正想改变什么；再把模糊的诉求结构化，找出信息缺口；然后用 AI 快速做出可验证的东西，在过程中补齐缺失的部分。对谈把这类角色与 FDE（Forward Deployed Engineer，前置部署工程师）联系起来。它既不是纯粹的程序员，也不是只做访谈的顾问，而是能在业务现场和工程实现之间来回切换的人。

这也解释了为什么“培养”变得棘手。这样的能力很难靠一门课程教出来，更多是在真实项目里，跟业务方一起把问题拆开、把方案做出来、再为结果负责的过程中长出来的。对谈中提到，让工程师尽量靠近最了解客户的人，持续对话，是比单独训练提示词更重要的条件。

测试全绿，不代表产品做对了

演示里最容易被忽略的一幕，是“绿色”带来的安全感。测试通过当然重要，但它只证明一件事：代码符合当前测试所定义的预期。如果测试本身漏掉了关键场景，或者需求从一开始就理解错了，那么全绿反而会制造一种虚假的完成感。

AI 生成的不是抽象的代码，而是一段会实际运行的行为。行为对不对，最终要看它是否解决了业务问题，是否在异常情况下仍然可控，是否有人能为结果负责。Codex 这类工具让生成变得便宜，也让“判断”变得更贵。对谈中提到，同一套工具在不同人手里，产出的质量会逐渐分化：有人能不断把问题收敛，有人则不断生成看似合理、实际偏离目标的东西。

所以，技术判断力并没有被自动化取代。相反，它被推到了更前面：决定让 AI 做什么、给它什么上下文、如何验证结果、什么时候必须停下来让人介入。编码速度是下限，判断力才决定上限。

AI 放在哪里：先找“必须由人判断”的点

第二个主题更具体：一个组织应该把 AI 放进哪些环节，又在哪些环节明确不让它进来？

矢上以金融业务为例，给出的思路不是按岗位划分，而是按决策性质划分。凡是规则明确、可以机械确认、不需要推论的流程，就尽量系统化；真正需要人做价值判断、处理例外、承担责任的节点，则要彻底梳理出来，明确保留给人。过去做业务设计时，常见的做法是把人的流程整体系统化；现在则要把其中适合推理和生成的部分交给 AI，把人的判断留在关键位置。

这条边界不能只在架构图上画一条线。它需要落到具体业务：哪些指令可以自动执行，哪些必须二次确认，哪些异常必须升级，出了问题由谁负责。对谈中提到的银行场景——资金划转、冻结或扣划之类的指令——之所以敏感，正是因为它们不只是“信息处理”，还涉及授权、责任和不可逆的后果。越是这样的环节，越不能因为 AI 能生成一段看起来合理的操作，就把它放进生产流程。

渡辺补充了另一个常被低估的前提：安全与治理。SoftBank 在自己的公司内部推进 AI 应用时，会涉及重要数据和个人信息，通信行业又有非常严格的信息管理要求。在这些条件下，能不能用某个工具，不只是效果问题，还包括数据如何被处理、权限如何控制、出了问题如何追溯。很多企业并不是不知道 AI 有用，而是还没能力把“可用”与“可管”同时做到。

第一步不是选模型，而是把责任和条件准备好

对谈最后，主持人问：如果明天就要开始，第一件事是什么？

两位嘉宾的答案都指向组织，而不是工具。每家公司的情况不同，但有几件事绕不过去。第一是经营层的明确态度。AI 转型如果只是某个团队的自发实验，很难跨过部门边界；需要有人从公司层面推动，也需要一个能对结果负责的责任人。第二是数据和技术条件的准备。数据没有整理好，权限和安全边界没有想清楚，工具再强也只能停在演示阶段。第三是让一线人员从身边的小问题开始做自动化，而不是一上来就改造核心系统。

这也回应了主持人提到的年轻人焦虑：不必等到“准备好”才进入这个领域。把公司里一个重复、琐碎、边界清楚的流程自动化，就是很好的开始。这样的项目能让人同时理解业务、数据和系统，也能让人看到 AI 在哪里有用、在哪里会出错。对谈中还提到，年轻人的目光不必只停留在媒体、广告这类互联网应用上；真正支撑社会、保护生命的关键系统，同样需要有人愿意进入。能力不是先学完再上场，而是在一个个小结果里长出来的。

对谈没有给出一个可以照抄的答案。它给出的是三个需要持续回答的问题：工程现场到底移到了哪里，谁来决定要做什么，以及 AI 与人的边界画在哪里。代码写得快，并不会自动让组织变得更快；真正决定结果的，是组织有没有把“做什么”和“谁来负责”想清楚。

速度不是终点

如果只带走一句话，那就是：AI 让编码变快，但把“定义问题”和“判断结果”推到了更前面。测试全绿、演示流畅，都不等于价值已经被创造出来。对工程师来说，新的竞争力不只是把代码写出来，而是能走进业务现场，把没说清楚的事情说清楚，把不该交给 AI 的部分守住。

这也是为什么，越是在 AI 能快速生成的时代，越需要有人对“做什么、为什么做、做到什么程度”负责。工具会继续变快，边界却不会自动出现。它需要被讨论、被设计，也需要由具体的人承担。