ARTICLE · 1122515
AI都能写代码了,为什么还要培养一万名工程师?
AI都能写代码了,为什么还要培养一万名工程师?
Anthropic给新学院的学员安排了一项具体任务：带着一个回到本机构后要负责落地的Claude项目来参加培训。
这个细节，比“一万名工程师”的数字更值得看。学员要把培训带回工作现场，让一个真实项目进入业务流程。最终接受检验的，是系统能否被公司持续使用。 10月2日，Anthropic宣布推出Claude Frontier Academy，承诺投入1亿美元，目标是在2027年底前培养一万名前沿部署工程师。首批参与机构包括埃森哲、贝恩、德勤、麦肯锡，以及银行、制药企业等。 一亿美元是投入承诺，一万人是培养目标。计划主要面向由客户和合作伙伴提名的现有工程师，不能据此推导出一万个新增岗位。 
一家以AI模型为核心产品的公司，为什么要花钱培养把模型送进业务的人？当AI已经能够生成代码、修改程序、协助调试，工程师的工作究竟剩下什么？ 顺着这项计划往下看，会发现企业购买AI时的一道缝隙：模型提供能力，公司需要的却是一套能在自己的条件下运转的系统。填上这道缝隙，需要的工作远远超过代码生成。 以一个假设的电商售后项目为例。让AI读取一条投诉、判断客户诉求，再生成一段回复，已经能做出颇有说服力的演示。要让它接管一部分日常售后，事情就会变得具体。 订单系统里记录的退款状态，可能与客服表格不同步；历史规则未必适用于当前活动；同一个问题，在不同平台、不同商品上可能有不同处理方式。有人得先决定该相信哪份数据、采用哪条规则。 接下来还要划清动作范围。AI可以查订单，是否也能修改订单？可以提出退款建议，是否可以直接执行？哪些情况交给人工，发生错误时如何追溯？这些选择会决定系统怎样设计，也会决定公司承担多少风险。 即使系统顺利上线，业务仍要继续追问：客户的问题解决了吗？员工花在检查和返工上的时间有多少？节省下来的工时，能否转化为更好的服务或更多订单？代码运行，只回答了其中一部分。 DORA研究团队在2026年3月发布的分析中，讨论了类似的落差。他们分析了谷歌软件工程师在2025年第三季度提交的开放式反馈：AI能加快初始代码生成，但部分节省的时间会转移到审核与验证。 这是特定工程师群体的反馈，不能当成所有企业的统一结论。不过，它提示了一项需要认真计算的成本：写得更快之后，确认“写得对、接得上、改得动”，仍然占用时间。 
企业软件的工作会经过需求、开发、测试、部署和实际使用。一个环节突然提速，后面的环节未必同步变化。开发人员一天能提交更多修改，如果审核、测试和发布仍然拥堵，客户未必能更早得到可用功能。 Anthropic的训练安排，恰好把学员放在这些接口之间。官方项目页显示，学员先完成线下模拟企业项目与考核，通过后进入12周实践，在自己的机构领导一个真实Claude部署项目，最后再次接受评估。 把学习放回真实项目，会遇到教程里很难完整呈现的条件：已有系统怎样连接，哪些数据能够使用，需求由谁决定，成果由谁验收。技术判断必须与公司的实际运行方式一起接受检验。 这类工程师的价值，可以从这里理解。他既要懂软件，也要问清业务；能够把模糊的要求拆成可以实现、可以验证的步骤，再把技术结果交还给使用它的人。 这也解释了企业AI项目为什么会有模型账单之外的支出。接入旧系统、整理数据、设计评估、调整流程、培训员工、持续维护，都可能消耗资源。选错场景，即使调用费用很低，整个项目也未必划算。 从公司的角度看，评价一个部署工程师，应看他能否减少这些摩擦：让值得做的项目更早落地，让不值得做的项目更早停下。后者同样需要专业判断。 但Anthropic的动机，还要从客户交付这一侧继续看。 模型公司可以把产品卖给很多企业，却很难仅靠自己的团队，逐一理解每家公司的采购方式、系统历史和行业惯例。培养客户与合作伙伴中的工程师，意味着让更多组织具备交付Claude项目的能力。 这条路已经铺了一段时间。2025年12月，埃森哲与Anthropic宣布成立专门业务集团，计划培训约三万名专业人员。双方公布的企业软件开发方案，也包含价值测量、工作流程重设计，以及变更管理和培训。 这些安排把模型能力与服务公司的交付经验放到一起。对企业客户而言，技术选型之外，还有实施团队可供选择；对模型公司而言，合作伙伴能够帮助它接触客户，并把试用向持续使用推进。 同样的方向也出现在竞争对手那里。2026年9月8日，埃森哲与Google Cloud宣布成立新的Gemini Enterprise业务集团，计划建立一支千人的前线部署工程师队伍。 
同一家咨询公司，同时参与多家模型与云平台的部署生态。由此可以作出一个商业判断：交付能力正在成为模型公司争取企业客户的重要渠道。它也提醒我们，合作关系并不天然具有排他性。 谁更容易被客户采用，除了取决于模型能力，还可能取决于谁能提供熟悉客户情况的团队、清楚的实施路径，以及可以参考的交付记录。尤其当采购方需要解释投入和结果时，这些条件会影响选择。 Anthropic在2026年6月公布的合作伙伴服务体系，已经把部分条件写进分级规则：认证人员、实际进入生产运行的客户，以及公开客户案例，都会影响伙伴等级。它还区分了交付能力评价与业务引荐激励。 培训、认证、实施和客户案例因此连成一条路径。它有助于客户寻找服务商，也可能鼓励服务商继续积累Claude项目经验。能力建设与市场拓展，在这里发生了联系。 客户黏性，也可能从项目本身逐渐形成。
假如一家企业围绕某个模型建立了评估方法、数据连接和员工工作习惯，下一次增加应用时，沿用现有路径往往更省协调成本。更换模型时，则要重新比较质量、成本和改造工作量。 这里的转换成本来自已经投入的工作。它并不证明企业被锁定：设计得较为开放的系统、多模型方案，以及合作伙伴掌握的跨平台经验，都可能降低迁移难度。 因此，培养一万名工程师能否成为Anthropic的商业优势，要看一个条件：这些人是否带来持续运行、持续产生价值的Claude项目。如果培训留下的主要是证书，客户上线后仍然频繁返工，这条路径的作用就会减弱。 对服务公司来说，也存在同样的考验。更多代码和更快演示，能够帮助它们启动项目；要持续获得客户付费，还需要证明实施工作节省了什么、改善了什么，以及这些改善能维持多久。 当然，这项培养计划不能成为“工程师永远不会被替代”的证据。随着模型与工具进步，系统连接、测试和部分部署工作，也可能进一步自动化。 METR在2026年2月更新开发者生产率研究时，就指出，相比早期研究，新的AI工具很可能已经带来更多提速；但参与者和任务的选择偏差，让提速幅度难以可靠估计。工具变化很快，不能拿一项旧实验替整个行业下结论。 如果常见的集成与验证工作逐渐标准化，企业可能用更少的人完成相同项目，实施服务的价格也可能受到压力。部署岗位的需求、人数和收费，都需要跟随实际工作量变化，而不能只看今天的培训目标。 工程师因而需要关注自己承担的任务。只熟悉某个工具的操作，与能够理解系统、检查结果、判断取舍，是不同深度的能力。AI可以加快学习和产出，扎实的基础仍有助于识别它遗漏的问题。 企业选择实施团队时，也可以把问题问得更具体：这个项目原来花费多少时间与资源？上线后，包含检查、返工和维护的总成本发生了什么变化？如果结果不如预期，团队能否说明原因并调整？ 这些问题会把一场容易停留在演示中的技术讨论，带回实际经营。培训人数可以说明投入规模，证书可以说明完成了某项考核，项目的持续表现才能说明企业获得了什么。 回到标题里的疑问：AI已经会写代码，Anthropic仍要培养一万名工程师，是因为它需要更多人把模型能力接到客户的数据、系统和工作流程中，并让结果通过业务检验。 到了2027年底，值得关注的除了有多少人毕业，还有他们负责的项目是否持续被使用，是否减少了企业的总成本，或者创造了新的业务价值。一万人的计划，最终要由这些结果来回答。
Anthropic给新学院的学员安排了一项具体任务：带着一个回到本机构后要负责落地的Claude项目来参加培训。