当Agent也能写代码，FDE会怎样变化

如果一个 Agent 能够阅读需求、修改代码、运行测试，甚至协助部署，为什么企业还需要把工程师放到客户身边？

这是一个合理的问题。过去需要人工完成的工作，一旦变得更便宜，原有岗位就需要重新证明自己的价值。FDE 没有理由成为例外。可是，若把工作简单分成“机器写代码”和“人负责沟通”，也会错过真正发生的变化：代码、判断、验证和组织行动之间的边界都可能移动。

截至 2026 年 9 月 25 日，能够确认的是工具与交付安排正在变化。尚不能确认的，是它们会在所有行业形成同一种最终组织。本章因此不预测一个统一的岗位结局，而是沿着一项客户工作，看看什么会消失，什么会转移，什么还需要新的证据。

先别把“感觉更快”写成经营结果

METR 在 2025 年发表的一项研究，让 16 名有经验的开源开发者处理他们熟悉项目中的 246 项任务，随机决定是否允许使用 AI。研究覆盖 2025 年 2 至 6 月所用工具；在这一条件下，允许使用 AI 的任务完成时间估计增加了 19%。¹

这个结果不能代表所有编程，也不能代表今天最新的工具。它说明的是，一项直觉上会加速的能力，进入真实工作以后，可能被阅读、等待、检查和修改等环节抵消。若负责人只看代码出现得更快，就可能漏算把它变成可接受成果的工作。

到了 2026 年 2 月，METR 对后续研究又作出了重要说明：越来越多开发者不愿参与需要禁用 AI 的条件，任务选择与参与者构成因此产生偏差；部分开发者同时使用多个 Agent，或在等待时处理其他任务，也使时间难以归到单项任务上。研究者认为自己的新数据不足以可靠估计当时加速的幅度。²

两份材料应该一起读。不能拿早期“慢 19%”证明 AI 永远无效，也不能拿后续使用意愿增强证明生产率已经提高了某个确定倍数。最值得带走的是测量方式：被自动化的步骤变了，原来衡量工作的办法可能也需要改变。

对 FDE 团队而言，至少要把三种时间分开。机器生成一个候选需要多久，是生成时间；工程师理解、检查、修改候选需要多久，是主动工作时间；客户从提出问题到可以稳定使用需要多久，是交付时间。三者都可能有价值，却不能相互替代。上述 METR 样本不是客户现场的 FDE 项目，后面的学习研究也不是 FDE 人才长期追踪。它们能帮助本章挑出生成、核验和学习中的变量，不能用来预测岗位将增加或减少多少。

例如，一个工程师同时让几个 Agent 工作，机器总运行时间可能很长，他本人投入却不多。反过来，原型十分钟生成，客户仍等待数周才能获得数据权限。把前一种情况说成低效，把后一种说成交付提速，都会让经营判断走偏。

代码便宜之后，验证会发生什么

沿用序章的教学维修企业，进一步假定它准备给备件仓做补货提醒。后文三种未来安排都保持这一个目标，不把它们当成真实项目结果。过去，团队花不少时间写数据连接、界面和简单规则；现在，Agent 能较快生成多个可运行方案。经理因此提出一个诱人的目标：既然开发更快，下个月把更多备件仓接进来。

但接入第二个备件仓时，团队发现“可用库存”的含义不同。一处把已预留的货物扣除，另一处仍计入账面数量。生成程序的成本下降了，确认库存含义的成本却还在。如果定义没弄清，自动化只会更快地把相同误解扩散到更多地点。

这不是说模型永远无法理解业务语义。模型可能帮助发现不一致、提出追问、比对记录。关键在于，组织仍需让正确资料进入系统，确认哪一种解释适用于当前决定，并观察实际结果。能力是否存在，与能力能否接触必要条件，是两个问题。

生成更便宜还会带来另一个变化：候选数量变多。一个方案需要一次审查，十个方案未必只需要相同时间。若没有筛选标准，团队可能把节省下来的开发时间，全花在比较看似完整、实则边界不同的候选上。

因此，FDE 的一部分工作可能从亲手实现，转向使候选能够被有效检验。这包括明确成功条件，准备代表真实困难的任务，保留关键输入与版本，区分可自动检查和必须由业务人员判断的部分。好的验证机制可以反复使用，它的价值不只在于发现错误，还在于使更多候选有机会安全进入比较。

不过，验证本身也不能成为新的口号。若测试只检查程序有没有成功运行，真实业务结果仍可能错误。沿用这个教学情境，假设客户规定：扣除预留后的可售库存少于 30 件就提醒补货。仓库实有 100 件，其中 80 件已预留，当前可售应为 20 件；系统却把 100 件都当作可售，因而没有发出提醒。接口调用和数字格式可以全部通过检查，遗漏补货的业务错误仍然存在。交付者需要保证检查所问的问题，与客户实际承担的后果相连。

同一个项目，三种不同的下一步安排

假定团队已经确认：可售库存须扣除预留，客户资料负责人能够裁定例外，并准备最多投入十个供应商工程师日做下一阶段。这个十日额度只是教学预算，不是研究测出的交付周期；客户自己的投入另算。

接下来，我们只改变两个条件：标准产品是否覆盖这项任务，客户是否已有能力维护它。目标仍是可靠的补货提醒，不能在便宜的方案里偷偷减少正确性要求。

三种情景改变了人员、花钱方式与产品反馈。第一种把成熟工作交给标准配置，不再购买持续探索；第二种保留密集共同工程，但设置一个可以停止的阶段；第三种购买的是帮助客户建立能力的投入，而非一直替客户操作。它们都不要求取消供应商，只是缩小或扩大他必须亲自承担的部分。

也可以得到另一个合理答案：暂停三种投入，先整理库存定义。表格成立的前提是负责人已经确认语义与例外；如果这个前提不成立，十天代码工作未必能换来一次可靠提醒。工具进步会降低某些成本，却不会凭空提供尚未被记录的事实。

这些不是三项已经证实的行业趋势。未来观察应追踪同一种任务：标准产品是否使第二次接入的人工作业真正减少；低成本原型是否带来持续使用，而不只是更多演示；内部接手是否减少外部操作，又没有把隐藏的维护劳动转给客户。没有这些后续记录，就不能把人天减少直接写成总成本下降。

第5章 模型与交付变化提到的 Redbox 停止后续开发，已给标准产品取代一部分自建提供了实际对照；不同工作条件中的韩国案例具名 FDE 建设统一验证和接口的访谈，则显示现场团队也可能主动减少下次重复工作。两者都不足以决定行业总岗位数量，却比单看代码生成速度更接近组织怎样变化的问题。

团队变小以后，谁处理相互影响

Agent 使一个人能够推进更多任务，有时也会让团队更容易低估协作。任务分别完成，不等于它们能够同时成立。

继续这家维修企业的备件补货情境。一个 Agent 修改库存定义，一个 Agent 改采购建议，一个 Agent 更新管理看板。三个修改各自通过检查，却可能基于不同时间点和不同解释。合在一起后，看板使用新定义，采购建议仍按旧定义，用户看到的数字与系统采取的动作开始分离。

工程上可以用版本管理、集成检查和发布机制处理一部分相互影响。经营上还要有人决定变更何时生效，哪个仓库先使用，旧任务如何结束。这些工作不会因为团队人数减少而自然变少；有时，参与生成的工具越多，明确共同状态反而越重要。

因此，一个未来 FDE 团队可能不需要很多人，却需要清楚的责任安排。谁能定义任务、谁检查跨任务影响、谁取得客户确认、谁在结果偏离时接手，不能只靠“总有一个人会看到”。当执行能力更丰富时，未分配的责任可能成为更显眼的限制。

这种限制也可以被工具继续改进。例如 Agent 帮助比较规则变化、整理待确认问题，或者在发布前指出彼此矛盾的假设。但它们的判断仍应放进可检查的过程。一个协调 Agent 宣布所有工作完成，并不等于客户已经接受结果，正如一个项目经理口头说完成也不够。

人怎样在使用工具时继续长本领

更强的工具还会改变人才培养。如果新人很少亲自追踪故障，却越来越早被要求审查生成结果，他靠什么形成判断？

Anthropic 在 2026 年 1 月公布的一项研究，让 52 名主要为初级的 Python 工程师学习不熟悉的 Trio 工具并完成任务。Trio 是一套帮助 Python 程序协调多个同时进行的任务的工具；参加者需要学会怎样使用它。AI 组之后测验的平均得分为 50%，手工组为 67%，相差 17 个百分点；AI 组完成任务快约两分钟，但这一时间差异没有统计显著性。³

这是一次特定学习任务的短期研究，不能证明长期使用 AI 必然损害技能，更不能据此要求所有工程师回到不用工具的方式。它提出的是一个值得认真对待的区别：完成了工作，不一定获得了完成这类工作的理解。

对 FDE 尤其如此。客户通常看见的是工程师能否解释系统为什么这样运行，以及出现意外时能否判断下一步。如果生成工具代替了大量中间推理，团队需要主动保留让新人形成这些理解的机会。

一种做法是在低风险练习中，让新人先预测结果，再运行；先解释某次失败可能来自哪一层，再让工具排查；完成修改后，自己说明影响了什么、还有什么未被证明。这些是本书的培养建议，不是研究已经验证的统一课程。

也可以把工作模式分开。赶一个明确任务时，优先利用工具完成；学习一个新领域时，要求工具解释、提出检查问题，并留出独立重做的环节。目标不在于坚持手工比例，而在于确保需要承担责任的人仍能辨认错误。

如果团队只奖励交付数量，新人可能会隐藏自己不理解的部分。若允许他明确说“这里由工具生成，我还没有确认这项假设”，审查反而更容易把注意力放到需要帮助的地方。工具越强，诚实表达理解边界可能越有经营价值。

当“AI FDE”已经成为产品名称

这个变化已经不只存在于预测中。Palantir在2026年3月12日宣布，名为AI FDE的产品对启用AIP的环境正式可用。公告描述了用自然语言完成数据变换、代码与Ontology编辑，并列出既有用户权限、可控制的上下文，以及在分支中验证修改后再合入等设计。⁴ 这是平台产品的可用性公告，没有证明一位真人工程师已被完整替代。

但它确实改变了我们应当研究的问题。若对象、权限和工具已经被整理进一个平台，过去需要工程师亲手完成的一部分平台操作，就可以交给软件执行。现场工作最有可能先被压缩的，未必是业务最重要的部分，而是已经有稳定对象和检查办法的部分。

回到前面的补货例子，库存口径已经由客户确认后，才有条件检验：平台能否按这项规则生成正确的处理和界面，并让接手者复核？本书未实际运行AI FDE，这仍是一项待验证的任务。

有价值的比较因此要拆到动作：原来几天的配置，现在用了多久；检查与返工增加了多少；客户能否自己完成下一次同类变更。若平台操作变便宜，就调整采购量和岗位分工；若新瓶颈移到业务定义，就把协作安排到那里。不能为了维护FDE这个名称，要求人继续做已经可靠自动化的步骤，也不能因为软件用了这个名称，就把整段共同工程宣布完成。

模型进步会不会吞掉今天的现场优势

会有这种可能。今天需要经验才能完成的判断，明天可能变成产品能力。某类复杂接口一旦标准化，原本稀缺的知识也可能变得普遍。FDE 不能把“客户环境很复杂”当成永久不变的护城河。

但反过来，也不能假设所有复杂性都会随着模型能力一起下降。一部分困难来自资料缺失，一部分来自目标冲突，还有一部分来自现实资源与责任。模型可以帮助组织看见和处理它们，是否能解决，仍取决于系统如何进入具体环境。

企业需要做的，是持续识别自己当前的价值来源。若主要价值只是替客户写一段容易生成的程序，定价和组织可能需要较快调整。若价值在于能够以更少成本、可靠地改变某项重要业务，就应继续测量这种结果是否存在，而不必为了维护一个职称保留不必要的人工步骤。

同样，不应把客户依赖当成能力强的唯一证据。如果客户已经能自行完成日常修改，这可能说明产品和交接发挥了作用。供应商可以继续提供更复杂的帮助，也可以接受某些工作不再需要自己。只有这样，产品进步才不会与现场团队的短期利益直接冲突。

留下一项会改变决定的观察

下次工具升级，维修企业不必立即重画组织图。它可以取一组原来需要人工处理的请求，用新版本完成相同工作，并沿第12章 项目经济性的口径记录工程、客户复核与持续支持投入。候选生成快了而核对增加，就不能只报前一半；供应商省了时间而客户接手困难，也不能把成本记成消失。

若结果支持表中的第一种情景，应当敢于减少专门工程购买；若原型便宜而新任务确有价值，可以有条件地扩大探索；若客户已能自行改变规则，就把供应商的投入移向内部做不到的地方。变化的依据是工作条件，不能只是发布会的能力图。

FDE 的未来可能包含更多 Agent、更小团队和更多标准产品。职业名称会不会留下，并不是客户必须先回答的问题。客户可以先知道：这一轮机器多做了什么，人少做了什么，哪一项判断仍需有人承担，以及什么证据会让当前安排再次改变。

从这个意义上说，未来研究应当给出可以推翻的安排，而不是一个永远需要 FDE 的理由。第二篇将回到甲乙双方的具体选择：哪些工作值得共同建设，如何安排团队，并为投入设置可以重做判断的条件。