当写代码变快，工程判断为何更重要

原文提出的问题

Rachel Laycock 在十月二十九日发表的评论中提出，优秀开发者对代理式开发的谨慎，并不能简单解释为抗拒新工具。他们关心的是系统投入生产之后能否保持可信、可维护、可演进。文章描述了一次让代理承担编码工作的团队实验：人类仍需决定领域边界并设计反馈，而能运行的应用没有自动带来可靠的构建。这是从业者的观察与解释，不是证明某种开发方式必然更优的对照实验。

以下是由这一问题出发的独立分析。讨论不预测某个职业会否消失，也不将实验中的时间分配外推为行业规律。真正需要解释的是，当代码生产成本下降时，软件交付中的约束究竟移到了哪里，以及团队如何在利用速度的同时保留判断的依据。

交付的对象不是代码存量

软件项目经常把可见产物当成工作完成的代理指标。新增了多少文件、实现了多少页面、关闭了多少任务，都容易计数，也容易展示。然而使用者购买或依赖的不是代码本身，而是某种在条件变化时仍可获得的行为。一个预约系统的价值，是在多人同时操作、请求中断、规则调整之后仍能给出可信结果。代码只有通过这些约束，才成为持续可用的能力。

因此，编码提速并不直接等于交付提速。可以把交付理解为一组必须同时成立的命题：需求被正确理解，行为符合约定，失败受到限制，变更可以追踪，事故可以恢复。任何一项缺失，都可能使大量已经生成的代码变成返工。这里的关系更接近串联约束，而不是把各环节的完成百分比简单相加。最容易生产的环节加速之后，原来不显眼的瓶颈往往会暴露出来。

例如，某团队过去一天只能做出一个待审改动，因此资深工程师有时间在当日完成阅读和讨论。假设现在代理能产出许多改动，而审核能力没有相应变化，结果未必是更多上线，可能只是更长的等待队列。这是说明机制的假设，不是任何真实团队的测量。它揭示了一个常被忽略的问题：局部效率可以提高，全局周期却同时拉长，因为系统需要处理的在制工作超过了承载能力。

稀缺资源从表达转向判别

传统编程中，程序员需要把意图翻译成大量精确表达，语法和工具操作会消耗显著时间。生成工具降低了部分表达成本，却没有消除判别成本。面对一段表面合理的实现，人仍需判断它是否依赖错误前提，是否越过了职责边界，以及是否遗漏了少见但关键的状态。判别通常比生成更难观察，因为正确的判断有时只表现为某项错误没有进入系统。

这种变化会改变经验的用途。经验不应只被理解为记住更多接口或更快写出某种惯用法，而应理解为知道哪些问题不能被当前证据回答。工程师发现需求里没有说明撤销操作如何影响历史记录，可能只需提出一句问题，就能避免后续一串不兼容实现。工具可以快速补齐代码，却不能使未做出的业务选择自动变成正确选择。把这个问题归结为提示词写得不够长，会掩盖决策本身尚未完成。

同时也不能把人的经验神化。资深人员可能固守旧方案，也可能把偶然经历当成普遍法则。保护判断的正确方式，是要求判断能够提出可检验的理由，而不是赋予某个职位无限否决权。如果有人认为某个代理生成方案不能上线，应说明风险路径、相关约束和需要补充的证据。这样，谨慎才能转化为可执行的工程工作，而不是成为无法反驳的品味之争。

需求边界比实现细节更早决定风险

代理擅长沿着给定目标继续推进，但许多工程难题恰好在目标的边缘。例如，允许用户修改信息，是否也允许修改已经用于对账的历史字段；允许重试失败操作，是否意味着可以重复产生外部副作用；允许修复服务，是否包括更换配置与迁移数据。这些问题不能只根据技术上能否完成来回答，而要根据授权、责任和业务不变量来回答。

一个实用做法是在委派之前描述结果必须保持的性质，而不是只列要新增的功能。假设要实现批量导入，可以先明确失败行不会影响成功行、重复提交不会增加重复记录、操作者能够知道哪些记录被接受。这里并没有预先选定数据库或框架，却已经给实现划出了可验证边界。边界清楚后，代理可以在内部自由选择更好的实现；边界不清时，再精细的代码规范也难以防止方向错误。

不变量也需要有层级。界面上的文案可以快速修正，账务记录的含义则不能随意变化。把所有要求都写成同等严格的硬规则，会使团队陷入维护规则本身的负担。更好的区分是：哪些决定影响不可逆后果，哪些决定只影响可恢复的局部体验。前者需要更强的事前验证和较小的变更范围，后者可以依靠快速试验获得反馈。自主程度应随影响范围变化，而不是随工具名称变化。

测试为何不能只证明自己相信的故事

如果同一套推理同时生成代码与测试，测试全部通过只说明实现与测试彼此一致，未必说明二者都符合外部需求。一个代理可能把金额单位理解错误，然后编写恰好验证这个错误单位的测试。这并非代理专属问题，人类开发者也会犯同类错误；只是当生成速度变快时，错误叙事可以更快地长成完整而自洽的文件集合。

要打破这种循环，需要引入不依赖实现选择的证据。验收条件应来自业务约束，接口契约应由交互双方共同确认，历史数据样本应保留其真实边界。测试可以分别覆盖性质与例子：例子用于说明具体场景，性质用于约束一整类输入。并不是每个项目都需要复杂形式化工具，但团队至少应该能够指出，哪一部分验证不是由当前实现反向推导出来的。

还需要区分检查失败与检查无效。某个测试总是因为环境偶发问题失败，团队可能逐渐习惯忽略红色状态。此时再新增更多测试，未必增加安全，反而可能扩大噪声。可靠检查应当有明确含义：失败时谁负责调查，哪些变更必须停止，哪些条件允许重试。如果检查不能驱动行动，它就只是展示材料。把检查恢复到可信状态，有时比增加覆盖率数字更有价值。

并行不是无条件的吞吐倍增

多个代理同时工作，最容易造成的误解是把它们视为完全独立的工人。实际上，它们可能共享同一个模型假设、相同依赖以及相邻文件中的隐含契约。一个修改字段名称，另一个依据旧名称补写调用，第三个又扩展测试来适配其中一种状态。每个局部改动都可能有道理，组合后的系统却没有一致的时间线。冲突不只是文本冲突，更是决策冲突。

减少这类风险，不一定需要复杂编排平台。先把任务拆成边界稳定的单元，明确谁可以改变公共契约，通常比增加代理数量更重要。可独立验证的任务适合并行，例如分析不同模块的风险；依赖同一接口决定的实现则适合先形成约定再分工。若公共模型仍在不断变化，同时启动许多实现者只会把尚未解决的分歧复制到更多地方。

批次大小也会影响理解能力。一个巨大改动可能减少任务切换，却让审核者无法辨认哪些行为同时改变。较小改动的价值不是遵守某个固定行数标准，而是使因果关系可以被理解：这次为什么变化，哪项证据说明变化正确，若失败应撤回什么。代理可以一次提出宏大计划，人类仍应将其中需要共同承担风险的部分组织成可审查的交付批次。

从演示成功到生产成功还缺什么

演示通常在较少状态、较清晰输入和较短时间内进行。生产环境则不断接收不完整请求、陈旧数据和彼此竞争的操作。一个看起来顺畅的流程，可能在超时后留下半完成结果；一个正确返回的接口，可能在依赖不可用时无限重试。展示证明了某条路径能够运行，生产可信需要说明其他路径如何受到约束。两者都是有效证据，但回答的问题不同。

因此，部署后的观察不是开发工作的尾声，而是验证链条的延伸。团队需要知道用户是否能完成任务，错误是否集中在某类输入，延迟是否与某个依赖变化有关。观察也不能只堆积日志；日志必须能关联到一次变更和一个行为假设。若发生异常，能够快速判断是否与刚上线内容有关，比单纯拥有大量记录更接近可操作的可靠性。

回滚也不能被当成万能保险。代码可以退回旧版本，已经发送的通知、已经执行的外部付款或已经迁移的数据却未必能自动撤销。真正的可恢复设计要在变更前识别这些副作用，并区分代码回滚、状态修复和业务补偿。假设一个操作会产生不可逆影响，就应在执行前缩小范围并保留明确证据，而不是依赖出错后重新生成一段修复脚本。

假设案例：一个预约服务的代理化改造

下面的案例完全是假设，用于检验前述分析。某个公共预约服务需要支持候补名单，团队让代理实现自动递补。最初的需求只是“有人取消就通知下一位”，代理很快做出了可演示的流程。真正的难点却在演示之外：下一位是否仍符合资格，通知发送后何时过期，同时有两个名额释放会否重复分配，以及管理员能否解释某人的排位变化。

若团队只按界面是否完成验收，错误会在真实竞争出现之后暴露。另一种做法是先固定不可重复占位、排位变化可解释、资格校验不依赖浏览器等性质，再让代理生成实现。测试不只检查正常递补，还要模拟两次取消、通知失败、用户重复确认。这里的重点不是预先猜完所有故障，而是把高后果的竞态和外部副作用纳入设计，使未知问题有被发现和限制的机会。

上线时也可以逐步增加自动化程度。先让系统给管理员建议名单，再允许它自动准备通知，最后才在验证充分的范围内自动发出。每一步都应观察是否出现预期外状态，并保留停止机制。这不是永远让人点按钮，而是通过分阶段证据扩大授权。等系统已经证明能够处理明确边界内的情况，人就可以把注意力转向边界变化，而非重复执行每一个低风险步骤。

如何评价代理带来的真正收益

最直接的指标是完成代码所需时间，但它不能独立代表收益。至少还需要观察从需求开始到行为稳定的总周期，以及后续返工消耗。若一次改动生成很快，却需要多人连续解释、修补、重新测试，节省可能只是从一个人的日历移到了另一个人的日历。评价应尽量覆盖整个交付环，而不是只测量最容易展示的片段。

这并不意味着每个团队都要建立繁重统计。可以先选择少数有明确解释的信号：待审改动是否积压，变更后是否需要紧急修正，故障定位是否越来越困难，完成同类任务时人是否更有把握。数字与访谈应互相校正。只听主观感受容易被新鲜感影响，只看吞吐数字又可能忽略质量债务。评价的目标是帮助调整流程，而不是给工具或员工排出永久名次。

还要避免把短期试用结果外推到所有任务。格式转换、局部测试补齐与跨系统权限重构的风险结构明显不同。一个团队在前者取得收益，不能证明后者也应同等放开；后者出现问题，也不代表所有自动化都不值得用。比较时应尽量让任务类型、复杂度和责任边界接近。没有这样的可比性，所谓成功率往往只反映选题差异，而不是工具能力差异。

反论证：严格边界会不会拖慢创新

一种有力反对意见是，过多限制会使代理无法探索，团队最终只是把旧流程套到新工具上。这种担忧成立。若每次读取文件、尝试测试都要等待人工批准，生成工具的许多优势确实会消失。但由此不能推出所有约束都应撤掉，而应区分探索空间与影响空间。让代理在隔离环境中自由比较方案，与让它直接改变生产权限，是性质不同的授权。

另一个反对意见是，人本来就会出错，为何对代理要求更高。合理回应不是追求代理零错误，而是比较同等后果下的可发现性与恢复成本。如果代理的操作更难被团队理解，或能在短时间产生更大范围的副作用，就需要相应控制；如果某类操作透明、可逆且已有可靠验证，则没有理由维持多余审批。控制强度应针对风险结构，而不应针对操作者是人还是机器的身份。

也有人担心强调资深判断会阻碍新人学习。事实上，代理承担大量编码之后，团队更需要有意识地安排学习：让新人解释方案中的约束，预测测试结果，参与故障回顾，而不是只观看最终答案。技能不会因为工具存在就自动丢失，也不会因为工具输出正确就自动获得。学习需要对后果建立自己的模型，组织必须为这种理解留出时间，否则未来判断能力的来源会被悄悄削弱。

对成熟团队的实际要求

成熟使用代理，不是把所有事项都变成流程表，而是确保关键决定有归属。谁定义需求边界，谁确认公共契约，谁承担上线后的观察，谁有权停止扩大的影响，都应当能够被说清。代理可以提出建议、收集证据、执行已授权步骤，但责任链不能因为任务被委派而变成无人负责。责任明确反而有助于提高自主程度，因为系统知道何时可以继续、何时必须缩小范围。

文档也需要随之变化。长篇背景资料未必比简短的不变量说明更有效，过时的规则甚至会误导执行者。最有用的上下文通常包括当前事实、决定的理由、禁止越过的边界以及验证办法。它们应与代码变化共同维护，而不是作为一次性提示被遗忘。上下文质量不是把所有历史都塞入窗口，而是让当前行动所依赖的前提可被核实。

最终，谨慎是否有价值，要看它能否产生更好的行动。单纯说“代理不可信”没有给出可验证路径，单纯说“代理已经足够强”也没有回答责任问题。工程判断位于二者之间：给出明确目标，允许可控探索，要求独立证据，在真实反馈中调整授权。代码生产越便宜，这种把愿望变成可信行为的能力越重要。未来开发工作的变化可能很大，但判断是否仍然与后果相连，依旧是衡量工程质量的核心。

公开原文：https://www.martinfowler.com/rachels-ramblings/good-devs-wary.html

让验证预算跟着风险走

代理能同时提出多个实现时，最初的诱惑是把所有版本都做到可运行，再让人比较。但不同方案的争议未必值得同等投入。假设订单修改的核心分歧是旧客户端是否允许重复提交，那么首先值得验证的是契约，而不是三个界面的完整度。可以先用两条可回放的请求描述前后状态，请熟悉业务的人确认何种结果才算正确，再把这项决定变成独立检查。这样即使更换实现，已获得的认识依然可用；反过来，若先选展示最好看的版本，团队可能被早期投入绑住，逐渐接受一个从未得到确认的接口语义。

另一个容易忽略的成本是日后诊断。如果一个改动需要更新服务端、测试环境和运行时配置，验收就应明确哪个版本在何处生效。假设灰度期间某批请求仍进入旧版本，那么一次成功的端到端操作既可能来自新行为，也可能来自旧实现或缓存。可以在不暴露业务输入的情况下保留版本、路由和结果分类，使每次抽查都能追到真实路径。日志不应为了证明代理做得好而堆积；它的职责是在结果不符预期时帮助团队区分环境差异、需求歧义和实现缺陷。若缺少这个能力，发布之后才积累的未知风险会被误算成开发阶段节省下来的时间。

复核也不必每次要求资深工程师重读所有细节。对于低影响、容易恢复的改动，可以让机器先核对稳定的格式和接口规则，由人抽查失败分布与样本变化。对于跨越授权、持久化或外部通知边界的改动，应优先审查状态流转，验证恢复流程和禁止发生的副作用，再决定是否扩大可执行范围。这种分工承认检查本身有成本，同时保留了一个原则：验证强度应随错误后果变化。真正成熟的代理使用方式，会让团队更清楚何处能快、何处应慢，以及为什么同一个工具在不同任务上应得到不同的授权。