智能体写代码，不等于软件工程

当智能体能独立运行数小时、管理自己的迭代循环并提交 PR 时，它就不再是你调用的工具，而更像是你分配任务的员工。问题不在于你如何监督他们，而在于你一开始分配给他们什么工作。

我们都在实时摸索，我看到许多团队犯了一个可以理解但关键的错误：他们调整自主性旋钮，增加或减少审查节点，而真正重要的变量是哪些类别的工作应由智能体负责，哪些应由开发者负责。这种区分无关风险承受能力，而是能力边界问题。

写代码和软件工程不是一回事

写代码是模式识别：借鉴已有做法，应用到新场景，搭建框架。大语言模型在这方面非常出色，因为它们正是这样工作的：从海量历史作品中识别并重现模式。

软件工程则不同。它涉及权衡、约束，以及需要模型无法获取的上下文才能做出的决策：你的业务领域、产品策略、客户、技术债务，还有团队上周关于为何选择某种方案的讨论。

大多数团队按重要性或风险承受能力划分工作。真正的分界线在于：哪些工作可以从既有模式中推导，哪些工作需要代码库之外的上下文、策略和判断。

开发者真正负责什么

真正需要开发者的工作比“任何重要的事”更具体，但无法简化为一份整洁的任务清单。它贯穿工程流程的每个环节。

“智能体能读代码，但读不懂氛围。”

开发者负责那些正确答案取决于代码库之外上下文的工作。产品策略、业务约束、团队动态、Slack 线程中的对话、架构评审，都是系统为何如此构建的历史的一部分。智能体能读代码，但读不懂氛围。

开发者负责那些风险状况模糊或故障模式难以预测的工作。某些变更的影响会因组织边界、部署时机或多年迭代中嵌入系统的数据契约而扩散。评估这些情况下的正确性需要判断力，这是任何模型无法仅从代码中推导的。不确定性越高，越需要理解代码为何如此编写的人。

开发者负责那些产出是决策而非工件的工作：构建什么、砍掉什么、六个月后下哪些技术赌注。智能体能生成选项，但无法告诉你哪个选项适合你的情况，因为“正确”取决于存在于人脑和组织背景中的因素，而非训练数据。

这一切仍在演变。随着团队通过更好的文档、更清晰的契约和更结构化的决策记录来让上下文更明确，边界也在移动。曾经需要开发者机构知识的工作变得智能体可及。但非结构化、高判断力工作的前沿也在不断移动，而这正是开发者时间最有价值的地方。

在分布式系统中，这个问题更严重。服务分布在多个团队和代码库中越多，关键上下文就越存在于任何单一代码库之外。修改一个服务的事件模式可能以该服务自身测试套件无法捕捉的方式破坏下游消费者。

此外，智能体不知道它不知道什么。该团队的开发者知道——不是因为他们写了代码，而是因为他们参加了约定模式的会议。对于云原生团队，这扩展性很差：服务越多，隐性契约越多，只有人携带的上下文也越多。

智能体价值最大的地方

每个代码库中都有大量浪费人脑的工作：样板代码、脚手架、重复重构、单元测试生成、配置模板、数据格式化。这些工作机械、重复，完全可以基于既有模式推导。智能体应该负责这些。

一旦开发者指定接口、契约和预期行为，智能体就能比开发者更快、更一致地实现。实现是可重复的部分，而之前的推理不是。

“在这种模式下成功的开发者不会是写最多代码的人，而是做出最佳决策的人。”

迭代速度也很重要。生成多个实现、运行测试套件、检查契约一致性：智能体以开发者无法匹敌的速度完成这些。Circle CI 的软件交付状态报告发现，吞吐量瓶颈最常出现在反馈和验证循环中，而非代码编写阶段。当验收标准明确且智能体能访问运行时环境和验证工作所需的工具时，它们能显著压缩这个循环。

在这种模式下成功的开发者不会是写最多代码的人，而是做出最佳决策的人——决定构建什么、如何架构，然后将执行交给比任何人移动更快的智能体。

划分工作的三层模型

在我们团队中，我们发现一个粗略的框架很有用，用于将工程工作分类，以便决定如何在智能体和开发者之间分配。

第一层：智能体主导，开发者审查

智能体执行高置信度且输出可自我验证的任务。包括样板生成、配置模板、在既定模式内添加端点、运行和报告测试套件、根据现有约定搭建新服务或模块。开发者审查输出，但智能体负责工作。

将这些工作交给开发者是在浪费你最昂贵的资源。随着团队更擅长让模式变得明确和可测试，这一类别应扩大。

第二层：智能体辅助，开发者指导

需要代码库之外上下文来验证的任务。智能体实现，但开发者定义范围、约束和成功标准。包括在理解良好的领域内的功能工作、在既定边界内的重构、以及为开发者定义的策略实施测试。

开发者提供工程判断，智能体提供实现吞吐量。大多数功能工作，无论何种架构，都属于这一层。

第三层：开发者主导，智能体支持

核心工作是判断而非实现的任务。包括架构决策、跨边界契约变更、调试突发故障、定义下一步构建什么。智能体可以协助子任务：起草提案、分析日志、生成候选实现供评估。但必须由开发者驱动，因为工作本身是推理，而非模式执行。

与第二层的区别在于，开发者不仅仅是验证输出，而是在做任何训练数据都无法替代的智力工作。

划分错误的代价

与我交流的大多数团队要么向智能体分配不足，要么分配过度。两者都是昂贵的错误。

分配过度是更明显的失败。将智能体推入第三层工作，它们会产生需要大量返工的输出，因为必要的上下文对它们不可用。返工成本是真实的，但机会成本更糟：本应做第三层工作的开发者却在审查和纠正本不该委托的智能体输出。

分配不足更隐蔽但同样有害。那些因为智能体输出似乎不确定而默认将工作交给开发者的团队，正在为第一层任务支付开发者级别的成本。开发者时间是团队中成本最高的资源。将其浪费在智能体可以处理的模式执行工作上，是对速度的缓慢拖累，会随时间累积。

这就是为什么许多采用智能体工作流的团队看到合并代码吞吐量增长有限甚至略有下降。他们没有解决分配问题，只是添加了新工具而没有改变工作分配方式。

审计工作，而不仅仅是智能体

问题不在于智能体是否取代开发者，而在于当智能体处理机械工作、人类专注于战略工作时，正确的工程模型是什么样子。

在这方面做得好的团队不仅仅审计他们的智能体，他们还审计他们的工作。他们问哪些任务在边界明确后可以由智能体主导，然后投入资源让这些边界变得明确。这种投资将开发者时间返还给高判断力、依赖上下文的工作，这些工作智能体短期内不会很好地负责。

答案不会来自 AI 实验室，而将来自每天以这种方式构建软件的工程团队——通过实践找出分界线，并了解他们特定的代码库、团队和领域在分界线的每一边需要什么。