软件工厂陷阱,生成代码不再是难事,生成正确的代码是最困难的部分

编者摘要：本文核心指出AI 能轻松生成代码，但生成符合需求、架构与业务约束的正确代码才是难点，这便是软件工厂陷阱：代码只是工程的“表面”，缺失需求、决策、上下文等隐性知识，仅靠AI 代理会导致审核成本飙升、协调困难；跳出陷阱需本体论（定义对象关系）+ 认识论（建立证明规则）双支撑，同时区分同步协作与异步自主任务，避免自建工厂沦为维护负担，最终强调上下文质量（形状）远胜于数量，软件工厂应承载专家判断而非仅生成代码。

一个好的模型可以编写差异，搭建服务，编写测试，解释API，迁移组件，并在一个人会感到疲倦的情况下继续工作。这个部分在很大程度上已经解决。

1. 定位：软件工厂陷阱的本质

AI 已能高效完成代码编写、服务搭建、测试生成等表层工作，但生成正确代码（符合需求、尊重架构、通过有效测试、易维护）仍是核心难题。
代码是软件工程的可见表面，背后隐藏需求、业务约束、设计决策、领域知识等不可见上下文，这是陷阱的根源。

2. 陷阱的主要表现

可执行文件≠完整产品：运行无需上下文，但迭代、修改必须依赖上下文，部落知识无法规模化供AI 使用。
代理≠软件工厂：AI 仅能完成执行，缺少权限、源权威、证明规则、失效检测等流程结构，导致审核成本远超效率收益。
团队结构失衡：工程师成为领域所有者指挥多AI，无共享教义会引发全局分裂，协调成本暴增。
证明陷阱：系统看似严谨，实则验证错误对象（如后端测试通过≠用户流程可用）。

3. 跳出陷阱的两大核心支柱

支柱	核心定义	作用
本体论	定义系统中对象（需求、源、任务、工件等）及相互关系	提供统一工作地图，让人与AI 基于同一模型运作
认识论	定义声明与有效证据的匹配规则	建立证明标准，确保验证对象与目标一致

二者协同：将“AI 做了某事” 转化为“约束下声明成立+ 证据支撑+ 失效条件明确”，大幅降低人工审核负担。

4. 关键认知：上下文的质量＞数量

盲目接入全量上下文（Slack、文档、代码库）会导致依赖关系模糊、失效检测失效、源权威混乱。
有效方案：用上下文图管理局部权威上下文，记录依赖关系与失效条件，而非堆砌信息。

5. 工作模式优化：同步与异步分离

异步自主任务：
后台迁移、API 修改等需求明确、证明清晰的工作，AI 可独立完成。
同步协作任务：
UI 设计、用户体验等需人类判断的工作，AI 辅助+ 人工迭代。
误区：将所有任务强行归为单一模式，浪费杠杆或增加重建成本。

6. 真实数据与行业结论

受控实验：GitHub Copilot 使JS 任务效率**+55.8%，单元测试全过概率+53.2%**。
真实场景：METR 2025 显示AI 使任务耗时**+19%；47% 高频AI 用户反馈QA、审核等下游工作更棘手**。
结论：AI 是现有流程的放大器，流程强则更强，流程弱则更快暴露缺陷。

7. 最终方向：避免自建工厂陷阱

自建软件工厂会沦为第二代码库，需持续维护提示、权限、脚本等，成本极高。
团队目标：获取高效可信结果，而非成为工厂维护方，应依托标准化工具层。
工厂升级方向：承载推导、正确性论证、产品意图、专家判断，达到资深工程师的思考高度。

8.惯例的三个问题Q&A

问题1：什么是软件工厂陷阱？主要成因是什么？

答：软件工厂陷阱是指AI 可轻松生成代码，但因缺失需求、设计决策、业务约束等隐性上下文，导致代码仅语法正确、语义残缺，人工审核与协调成本远超效率收益，最终自建工厂沦为维护负担的现象；主要成因是代码只是工程表面，AI 代理缺少本体论、认识论与流程结构，无法理解决策背后的完整上下文。

问题2：本体论和认识论在软件工厂中分别起到什么作用？为何必须协同？

答：本体论为工厂提供工作地图，明确需求、源、任务、工件等对象的关系，确保人与AI 基于统一模型运作；认识论提供证明规则，定义声明与有效证据的匹配方式，避免验证错误对象。二者协同才能将AI 的执行结果转化为可验证、可追溯、可失效检测的可信工作，大幅降低人工重建成本。

问题3：为什么更多上下文不能解决软件工厂问题？正确做法是什么？

答：因为问题不是上下文数量，而是上下文形状；全量接入上下文会导致依赖关系混乱、失效检测失效、源权威模糊，反而增加不确定性。正确做法是构建可控的上下文图，仅保留工作周边的权威局部上下文，记录依赖关系与失效条件，由工作流程驱动AI 读取正确片段，而非堆砌所有信息。

附录：生成正确的代码是最困难的部分

正确的代码不是编译通过的代码。它是符合需求的代码，尊重架构，处理业务约束，通过真正重要的测试，并在下个月上下文变化时仍然易于理解的代码。

这个差距就是软件工厂陷阱所在。但要理解这个陷阱，首先你需要明白代码实际上是什么，以及它遗漏了什么。

代码是表面

Conal Elliott在一次Haskell基金会的采访中，将该程序描述为一个更大对象的表面。

可执行文件不是整个产品

整个内容包括规范、推导、目的、正确性论证、权衡和产生最终代码的概念空间路径。

代码之所以高效，是因为它剔除了所有这些内容。运行时不需要做出权衡的会议。不需要顾客澄清边缘案例的Slack讨论。不需要使一种行为可接受而另一种不可接受的产品判断。这些都不需要运行。

所以我们移除它。

该程序需要这些内容被理解、扩展并安全地修改。但并不是为了运行。因此，赋予代码意义的上下文悄然消失，只留下可执行的表面。

在大多数软件历史中，这一切都是可以应对的。经验丰富的工程师将缺失的背景知识记在心中，或记在没有人更新的文档里。他们知道哪些对象重要，哪个源有权威，哪个证明有效，流程可能在哪里中断，哪个捷径是虚假的。他们在私下进行本体论和认识论，而不称之为那样。这只是成为一名资深工程师的意义所在。

问题在于，私人专业知识无法在群体中扩展。部落知识并不会因为它在组织中的某个地方存在而变得可供软件工厂使用。它必须在工作之时被捕捉——在决策、审查评论、设计文档、与客户的对话以及记录中——以便智能体在需要时可以读取它。手动回顾文化也无法扩展到工厂中。捕捉必须成为工作流程的固有部分，这样当智能体需要使用时，上下文已经是可读的。

如果工厂无法理解影响决策的背景，它就无法可靠地扩展由此产生的工作。

这是基础问题。并不是说智能体无法编写代码。它们可以。问题在于，智能体被要求根据创建当前系统的一部分上下文生成系统的下一个版本。它们产生的工作在语法上是正确的，但在语义上是不完整的。这看起来像是在进步。在任何事情可以被信任之前，都需要高级工程师进行审核。

那就是瓶颈。它一直存在。人工智能使其显而易见。

工厂不是智能体

当智能体完成任务时，您通常会得到：

l明文说明

l智能体更改了7个文件

你实际上需要的是更接近于：

l这一变化源于需求A

l使用的来源文档B 和C

l假设D

l实施了规范块E

l由检查证明F

l如果B或C发生变化，就会变得过时。

第二个记录不是装饰。它使得任何人（无论是人还是系统）都能在不从头回放每个轨迹的情况下验证工作。如果没有它，审查就变成了重建。有人必须仅仅从输出中重建整个意图、上下文、实施和证明的链条。这样所花的时间比智能体节省的时间要长。

错误在于认为工厂是智能体。它不是。

一名新工程师不仅仅因为聪明而有用。他们需要入职培训、目标、仓库访问、责任边界、权限、工单、评审循环、升级路径，以及完成定义。智力是必要的，但不是充分的。它必须组织成劳动。

智能体也是如此。当前类别的编码智能体可以读取文件、编辑代码、运行命令、检查故障，并且有时可以修复自己的错误。这些工具是真实的。它们缺少的不是另一个工具，而是周围的结构：哪些上下文来源是权威的，适用哪些权限，如何证明工作，以及当输入变化时什么变得过时。

没有这种结构，失败模式是可以预测的。智能体人编写代码。抽象是错误的。实现通过了狭窄的测试，同时违反了产品意图。人类工程师花费在审查、解开和重新解释上的时间比他们直接做工作的时间还要多。

一家工厂应该生产比废物更多的价值。许多本土工厂则相反，因为它们在自动化代码生产的同时，将需求、证明、背景和审查留给人类重建工作。

这就是为什么大多数内部“软件工厂”项目变成陷阱的原因。它们以一个合理的前提开始：给智能体访问代码库，给他们设定目标，让他们编写代码，让人类审查结果。起初这感觉像是杠杆。但随后，二次系统出现了。

在智能体开始之前，谁拥有这些需求？哪些来源是权威的？每个工作人员应该获取多少上下文？它拥有什么权限？哪些测试实际上证明了这个需求？当源上下文发生改变时，什么变得过时？

在那个时候，团队并不是在构建带有智能体的软件，而是在维护使智能体可用的工厂。

团队结构正在改变

这个问题还有第二个维度，它在第一个维度的下面。

以智能体为主的工程并不总是看起来像是一支正常的工程师团队，在经理的带领下，共同在同一个代码库上工作。在与一位已经建立了以智能体为核心工作流程的创始人的一次对话中，他描述了一种更接近拿破仑式规划的方式。目标设定在顶层。每位工程师负责一个领域。然后，每位工程师带着他们自己的智能体工作者，去弄清楚如何完成那部分工作。

这种模式是合理的。如果一名工程师能够有效指挥多个智能体，那么这名工程师看起来就不再是一个单独的贡献者，而更像是拥有一支小型军队的领域拥有者。执行变得便宜且本地化。每个领域拥有者都可以快速行动。每个本地表面区域都可以迅速发展。

但没有共同的教义，这就会导致分裂

共享层变得更加重要，而不是更少：合同、API协议、证据标准、源权威、架构边界和审查规则。如果工程师们正在成为拥有智能体军队的领域所有者，那么公司需要一种方式来协调这些军队，而不是让管理者变成全职的交通指挥员。

这种更难的版本是跨工厂协调。两个工程师可能各自在代码库的不同部分运行着自己的智能体，结果发现他们涉及同一抽象或做出不兼容的假设。大多数智能体系统将冲突通过人工途径传递：智能体到人，人到人，人再返回智能体。这在短周期内是有效的。但当智能体已经运行几个小时，而且相关上下文位于计划下方几个抽象层时，这种方式就会失效。

为此环境构建的软件工厂需要一个通信层，智能体可以在其中呈现冲突、比较源权限、提议共享合同，并仅将真正需要人类判断的决策升级。目标不是将人类从架构中移除。目标是停止浪费人类关注力在重建系统本可以最初显式的上下文上。

这是软件工厂陷阱的第二个版本。杠杆效应是真实存在的，但协调负担也是如此。而且协调负担的增长速度超过团队的预期，因为它在两支智能体军队碰撞的那一刻之前是看不见的。

证明也需要证明

要摆脱这个陷阱，你需要两个协同工作的因素。大多数软件工厂设计都不具备这两者。

第一个是本体论。

本体告诉系统什么东西存在以及它们之间的关系。在这个背景下，这意味着工厂有一个关于重要对象的工作模型：需求、来源、利益相关者、任务、工件、权限、测试、证明声明、产品表面、依赖关系和决策。它知道这些事物之间的关系。一个需求可以支持一个任务。一个来源可以授权一个需求。一个测试可以支持一个证明声明。一个来源的变化可以使一个工件失效。

这并不是为了自身而引入的异国哲学。这是高级工程师们已经在默默进行的工作。他们在接触系统之前，会在脑海中构建一张地图。他们知道哪些状态转换是重要的，哪些遥测可以证明这一点，哪些面向用户的声明没有被后端测试覆盖，以及哪些依赖项的变化使得工作变得过时。智能体工程必须将这种隐含的地图显性化。并不是因为这是一个好的流程，而是因为智能体无法继承从未记录下来的专家判断。

本体论使得每个人——无论是人类还是智能体——都在同一个系统模型上运作。这并不是模糊意义上的“共享理解”，而是在操作层面上的一致：相同的需求、源、任务、证明主张和产品表面可以被引用，而无需每一方重建自己私有的现实版本。

但是单靠本体论是不够的

你需要的第二件事是认识论。

知识论告诉系统如何使关于那些事物的主张变得可信。这也是大多数工厂设计失败的地方，因为它们在跟踪工作时没有跟踪证据。

"API返回200" 是一种声明。可以通过运行时跟踪、测试、日志或遥测记录来得知。但它并不能证明用户可以完成入职。这是一个不同的声明，且需要不同的证据。“这个输出是过时的”是另一个声明。它取决于该工件是否确实使用了已更改的源，是否将该源视为权威上下文，以及该变更是否足够重大以使结果失效。

一个声明在证明类型与声明类型匹配之前是无效的。截图并不能证明持久状态。通过的后端测试并不能证明用户旅程。清晰的总结并不能证明生成的工作仍然符合源需求。这些替代在智能体工作流程中不断发生，并不是出于不诚实，而是因为系统从未被迫区分它们。

这就是本体论和认识论协同工作的地方。本体论为工厂提供了工作图。认识论提供了证明规则。它们共同将“智能体人做了某事”转变为“在这些约束条件下，此主张成立，且有此证据，而这就是使其失效的原因。”

当两者都被编码到工作流程中时，工厂可以在人工看到之前验证更多自身的工作。它可以发现一个需求被引用但未实施。它可以发现一个测试验证了错误的层。它可以发现一个源在任务生成后发生了变化。它可以检查需求是否来自正确的来源，任务是否使用了正确的上下文，以及是否应该因改变架构边界而升级一个更低层次的实施决策。

人类不应该需要重建从意图到实施再到证明的整个链条。系统应该将这一链条打包，以便人类能够专注于确实需要人类做出的判断。这就是审查负担可以减少的机制——不是通过消除人类判断，而是通过给予人类判断正确的输入，而不是一堆需要逆向工程的输出。

我们直接在内部工作中看到了这一差距。一次运行产生了数十份合同、依赖关系边、清单和可审查的收据。机器运转良好。它完成了大量的结构化工作。但是，产品结果超出了机器被迫证明的范围。后端合同通过了。端到端用户索赔仍未得到证明。这家工厂为错误的对象生成了令人印象深刻的证据量。

这就是工厂陷阱内部的证明陷阱：一个系统看起来可能是严谨的，同时却在证明错误的东西。

公共数据实际上显示了什么

生产力研究往往被选择性引用，通常是为了支持作者最开始的任何论点。以下是它们共同的说法。

在微软研究的一个受控实验中，使用GitHub Copilot 的开发者在一个有限的JavaScript 任务中完成速度提高了55.8%。在一个GitHub 代码质量研究中，Copilot 用户通过所有十个单元测试的可能性提高了53.2%。这些是真实的结果，而且很重要。这是在范围明确且证据清晰的任务上取得的进展——正是工厂机器问题尚未显现的条件。

在METR的2025年初研究中，16名经验丰富的开源开发者在自己的代码库中处理246个真实问题，结果显示接入AI使任务耗时增加了19%。Stack Overflow在2025年的调查发现，更多的开发者对AI准确性表示不信任而非信任，最常见的挫败感是输出“几乎正确，但不完全正确”。Harness在2026年的DevOps现代化报告中指出，47%的高频AI编码用户表示手动下游工作——质量保证、代码审核、补救——变得更加棘手。

模式不是“AI编码工具不起作用。”模式是更快的代码生产可能暴露出较慢的验证系统。当代码到达的速度快于审查过程能够吸收的速度时，瓶颈会向下游移动并变得对所优化的指标不可见。你测量时间到差异，它看起来不错。你测量时间到可信结果，它看起来更糟。

DORA的2025研究明确指出组织维度：人工智能是对现有状况的放大器。强大的团队变得更强。薄弱的流程则更快变得更弱。这种框架与上述所有内容一致。如果工厂已经具备良好的需求工程、来源授权和证明纪律，智能体商会使其变得更快。如果没有，智能体商则会使差距变得更昂贵。

自建软件工厂

与一位创始人交谈过，他已经建立了替代方案。

他的团队并不是在讨论智能体是否能够编写代码。他们已经超越了这个问题。他们的工作流程大致如下：将大型需求文档分解为技术规格，规格转化为工作分解结构，然后将工作交给递归智能体员工，输出通过属性和合同测试进行包装，结果与原始需求进行审查。当源上下文发生变化时，他们会重写受到影响的代码，而不是修补过时的部分编辑。

这是真正的软件工厂。它将本文所描述的内容进行具体化：以需求作为起点，明确源权威，递归地分解工作，在执行之前定义证明义务，以及通过重写来处理陈旧性，而不是积累漂移。

拥有这也是很不容易的

在那次谈话中，重要的信号不是“我们喜欢人工智能。”而是更接近于：我们已经建立了内部机器，我们确切知道它的重要性，我们宁愿为维护版本付费，而不是继续拥有这台定制的机器。

这与关于人工智能的一个普遍叙述相悖，即每家公司将简单地生成所有自己的软件，从而停止支付工具费用。现实要复杂得多。当机器变得令人痛苦、快速变化且非核心时，一些团队会寻求一个维护层，而不是无限期拥有它。价值提升到一个新层级。这并不是一个新模式。团队购买CI系统、可观察性平台、身份验证提供者和部署工具的原因也是一样，而不是自己构建每一层。

团队想要的不是更多的智能体。他们想要更快、更好的结果，而不是成为工厂维护团队。

旧流程，新运行态。有一个值得指出的历史类比，因为它澄清了一个重要的原因，解释了为什么这个问题之前一直难以解决。

许多旧的工程学科失败并不是因为这些想法是错误的，而是因为执行层是人类。

像HATEOAS——超媒体作为应用程序状态的引擎——和CORBA——通用对象请求智能体架构——的想法源于一个真正的问题：使分布式系统更易于理解、导航和一致。自描述接口。标准化的API协议。需求追溯到实现。可以审计的正确性论证。技术价值是真实的，协调成本非常高。

让大型组织就API标准达成一致意味着要跨越数十个团队中的数百名工程师，每个团队有不同的历史、偏好和地方激励。维护gRPC、REST、GraphQL、SOAP/XML以及独立设计的纪律意味着要么构建翻译机制，要么说服团队重新调整其接口，或是不断地监督偏差。实际上，即使是最初具备强大API纪律的团队也可能出现退化，因为强制实施一致性对负责的人来说变得过于繁琐。

需求工程遭遇了相同的命运。需求与实现之间的追踪链接成为了无人更新的文档。正确性论证变成了形式主义。证明义务变成了检查框。这并不是因为工程师们草率，而是因为在一个大型组织中手动维护这一切，与实际发布软件并行，是不可持续的。

智能体改变了这种权衡

编码智能体对API风格没有个人偏好。它不需要在架构会议上被说服。它不会厌倦维护追踪链接，也不会对被要求将用户旅程声明与后端证明声明分开感到不满。它需要以可读的形式提供合同，以可执行的形式提供操作，以及以可检查的形式提供证明义务。过去需要组织强制执行的事情可以在工作时刻以执行上下文的形式呈现。

这意味着一些过程繁重的旧观念在转变为运行时输入而不是人为强制政策时变得新的实用。自描述的动作。架构。接口合同。源权威记录。需求与实施之间的追踪链接。智能体在做工作时可以消耗的测试，而不是事后审计。

这是在人工智能背景下需求工程的商业案例。这并不是回归繁重的流程。它承认，智能体可以维持人类组织认为过于昂贵的纪律，只要工作流程被设计成使这种纪律可执行而非仅仅是文档化。

问题不是上下文的数量，问题是上下文的形状

代码库本身作为整体上下文时，实际上是一个较差的主要上下文来源。它给智能体提供了先前难题的最终部分。它不能可靠地解释这些部分为什么呈现这种形状，哪些权衡导致了它们的形成，保护了哪些客户承诺，或哪些快捷方式是不可接受的。连接所有可用的公司知识实际上可能会增加模糊性，而不是解决它，因为智能体可能能够搜索所有内容，但仍然不知道哪个来源是权威的，哪个决定取代了另一个，哪个讨论仅仅是讨论，或在要求变化时什么应当变得过时。

这就是上下文图变得有用的地方，但只有在我们准确阐明它们价值的基础上。上下文图的价值不在于它包含了一切，而在于它记录了重要的内容、是谁或什么授权了它、什么依赖于它，以及当它发生变化时什么变得无效。重要的对象不是“所有上下文”。而是在工作周围的局部环境：需求、授权它的来源、它涉及的合同、它依赖的假设、将验证它的证据表面，以及如果这些来源发生变化将使其无效的来源。

一个无法导航的图只是另一个上下文转储。一个有用的图是有范围、已被索引并可程序化访问的。它让工厂将工作的适当切片交给智能体，而不是将整个公司拖入提示中。

图表必须与工作流程配对。仅仅在数据库中存在的图表本身并不能增强智能体的能力。智能体必须知道读取哪个片段，哪些边是权威的，哪些声明已经过时，当两个来源意见不合时，哪个来源优先，以及哪个证明表面对其正在进行的工作有效。上下文形状由工作流程设计决定，而不是可用信息的数量。

同步与异步工作

并不是每个任务都应该通过相同的工厂流程，错误的排序本身就是一个陷阱。

一些工作确实适合长期自主任务。后台迁移、API更改、基础设施重构和许多内部系统更改都有明确的要求、强有力的证明表面以及对人类品味的最小依赖。如果要求形成良好且证明义务明确，智能体可以分解工作、执行它、验证它，并返回一个可审查的包，无需持续的人类参与。工厂的工作是使自主性值得信赖，而不是监督每一个步骤。

其他工作需要同步的人类协作。面向产品的用户界面、交互设计、引导流程、文案和用户体验通常需要反复迭代。您仍然可以在这些流程中使用本体论和认识论——实际上，明确的需求使得协作更加精准，因为团队必须阐明它试图创造的体验是什么，以及什么算作成功。但证明是不同的。面向用户的体验不能简化为“处理程序通过”。它需要关于清晰度、信任感、感觉，以及界面是否创造了预期体验的人类判断。

错误在于将每个任务都强行归为一种模式。将依赖判断和经验的工作视为一项长期的自主任务会产生可信的输出，但需要大量的人力重新构建。将有限且明确规定的后台工作视为需要持续人类协作的任务，浪费了工厂所能提供的杠杆作用。

一个有用的软件工厂知道其中的区别。它对强证明表面的工作使用异步任务，对需要人类判断的工作使用同步协作。在这两种模式下，需求工程都很重要；它不是一种仪式，而是确定哪种模式合适以及工作完成的定义的机制。

陷阱

软件工厂陷阱是构建足够的机器以使智能体有用，然后发现这些机器已经成为它自己的产品。

您维护提示。您维护技能。您维护上下文管道。您维护文档。您维护审查仪式。您维护测试规范。您维护智能体权限。您维护追踪导出。您维护将所有这些连接在一起的脚本。每一次模型变更、工具变更、工作流变更和团队习惯变更都迫使工厂进行变更。

在小规模上，这是有趣的工程。在公司规模上，它变成了一个没有预算的第二个代码库。

然而，陷阱下的工作是真实的。需求形成。源头权威。边界上下文。证明义务。审查包。过期检测。协作协议。这些不是谨慎团队出于焦虑而添加的可选层。它们是决定工厂是否生产可信结果或产生重建劳动的层。

这就是为什么团队最终会购买CI 系统、可观察性平台、身份验证提供者和部署工具的原因。他们可以自己构建这些。有些团队会。大多数最终决定他们不想拥有所有使其真实工作可靠所需的每一层机械。智能体工程正在进入这个阶段。自家工厂的努力最终与保持其最新状态的成本相冲突，团队开始询问是否应该由其他人来拥有这一层。

买家信号不是“我们喜欢智能体商。”而是：

我们需要摆脱拥有本土软件工厂的负担，以便可以专注于更大的问题。

更大的问题不是维护一个软件工厂/工程团队，而是导致它在第一时间被需要的那些问题。毕竟，你不是为了随便组建一个工程团队；你这样做是因为你需要构建市场所需的东西。你的精力应该集中在这里，因为这里存在新颖的问题。

这实际上需要的是什么

回到Conal Elliott 的框架中去。

该程序是一个更大对象的投影。代码是影子。其背后包含规范、推导、正确性论证、目的，以及生成最终形状的概念空间路径。运行时不需要任何这些。但是扩展工作、修正它，或知道它是否应该存在— 这些都需要访问更大对象，而不仅仅是它的影子。

这就是不同工程师与相同代码库互动的方式所区别之处。

一名初级工程师查看文件。他们处理眼前的内容。一名高级工程师能够重建足够的周围上下文，以理解代码在做什么以及为什么。一名工作人员工程师则提出一个完全不同的问题：这是不是正确的构建？这与什么相连？如果我们这样做，会有什么变化，如果我们不这样做，会有什么损坏？他们并不是在操作代码。他们是在操作其背后的更大的对象。

当前的编码智能体主要在初级到高级的层次上运作。他们可以读取文件、遵循规范、修复测试、修复故障，并生成语法正确的工作。他们不能可靠地完成的是员工工程师的转变：后退一步思考当前任务是否正确，工作的实际关联是什么，以及它是否应该存在。

那个高度差是保姆税存在的地方。并不是说智能体无法编写代码，而是每个输出仍然需要有人来执行智能体跳过的员工工程师检查。必须有人问：这个符合架构吗？这个满足真实需求吗？我们是否构建了正确的东西？这个问题仅凭阴影是无法回答的。

移动最快的团队并不是那些生成最多代码的团队。他们是那些工厂能够在接近员工工程师高度运作的团队；不仅是在框架内执行，而是有足够的大对象可供质疑框架。这意味着工厂需要推导，而不仅仅是差异。正确性论证，而不仅仅是通过的测试。产品意图，而不仅仅是规范的片段。与商业现实的联系，而不仅仅是工单。

当该上下文被编码到工作流程中时，智能体可以推断出以前需要人类才能推断的事情。它们可以捕捉到某个需求与现有的架构决策相矛盾。它们可以标记出某个证明表面证明了错误的层次。它们可以注意到两个智能体工人在计划下面三个抽象层次上做出了不兼容的假设。它们可以在代码编写之前询问这项工作是否应该存在。

这不是更多的背景信息。它是在正确高度上的背景信息。

软件行业一直知道，随着工具处理更多的底层工作，人类将会向上移动一个抽象层级。而不那么明显的是，向上移动需要更大的对象与您一起前进。您不能可靠地委托给一个只有影子的系统。

我的猜测并不是更多的智能体能够解决这个问题。我的猜测是围绕智能体构建的工厂（那些保留推导、正确性论证、产品意图和通常被困在专业工程师脑中的专家判断的工厂）才是持久杠杆所在。