过去，小功能请求中最昂贵的部分是编写代码。现在通常是关于“要不要写这段代码”的会议。

这是一个真实的变化，它悄然打破了许多工程直觉。工程师们很早就明白，大多数“小的需求”其实并不小：它们需要测试、发布计划、有人思考边界情况，并在上线后承担行为责任。一个两小时的改动，如果触及系统中的错误位置，就可能变成两周的干扰。所以我们会推拒。这真的有必要吗？它属于这个版本吗？它会改变我们已经同意的契约吗？我不会放弃这种直觉。

但这种直觉建立在一个正在悄然失效的假设之上，即编写代码的第一个版本是昂贵的步骤。对于特定类别的变更而言，情况已不再如此。如果你能把这类变更与其他变更区分开来，就可以把“这个在范围内吗？”替换成一个可以在三十分钟内回答的问题，而不是两天的争论。

争论往往比补丁更贵

我经常看到这样的模式。有人请求一个小改动，例如把后端已有的 last_active_at 时间戳显示在设置页面上。团队在讨论线程里花了四十分钟。有人说这听起来有风险。有人想起两年前的一次相关迁移。有人提到截止日期。最终我们得出结论：“可能要花一到两天，也可能更久”，置信度很低，主要因为没人真正尝试过。

这个过程在“尝试”是最昂贵的环节时是合理的。你必须停下手头的工作，把上下文装进脑子里，手动完成改动，编写测试，然后发现二阶和三阶后果。当第一次尝试变得廉价时，捍卫边界所花费的成本可能超过跨越边界。

一个代理可以在讨论线程热身的时间内生成第一个补丁。它不是免费的，也肯定不会自动正确。但它已经足够廉价，以至于明智的做法往往是停止猜测，转而查看一个真实的 diff。

第一个补丁是价格检查，而不是最终产品

错误在于把生成的补丁当作可交付成果。它不是。它是一个探针。它把抽象的范围争论转变为可以审视的具体工件：

  • 它是否触及你预期的文件，还是扩散到五个包？
  • 测试是否显而易见，还是这个变更难以测试？
  • 它是否保留了现有的抽象？
  • 它是否悄无声息地需要一个新的产品决策？
  • 你是否愿意在六个月后继续拥有这个行为？

这些问题比“是否感觉像范围蔓延”更好，因为现在你是从证据而不是直觉出发争论。如果 last_active_at 字段返回的是一个四行 diff 且测试通过，那就发布它。争论才是昂贵的部分。然而，如果同一个请求返回的结果触及了 auth 中间件，你就知道这个请求从来都不小。而且，你只用三十分钟就知道了，而不是两天。

这不是让 AI 做决定。这是用 AI 让人类的判断变得更廉价、信息更充分。

写起来廉价不等于拥有起来廉价

这里有一个陷阱，也是 AI 时代最重要的区别。一个变更并不仅仅因为代码生成成本低就廉价。只有当一个人能自信地审查并拥有结果时，它才是廉价的。

一个技术上通过但没人愿意拥有的千行 diff 并不是廉价的变更。它是一笔递延成本。因此，在这种情况下，分界线不是“代理能否写出这个？”而是“一个人能否验证它？”

  • 添加一个后端已存在的展示字段通常是廉价的。
  • 更改授权行为不廉价，无论 diff 看起来多么干净。
  • 重构一个经过良好测试的辅助函数通常是廉价的。
  • 更改数据保留语义不廉价。

即使代码微不足道，许多变更仍然值得坚决说不。这包括任何改变产品契约、产生支持负担，或触及隐私、账单或合规性的内容。AI 降低了生成候选方案的成本，但它并没有降低拥有一个候选方案的成本。

把范围纪律移到证据更近的地方

传统上，范围纪律发生在实现之前，因为实现是需要保护的昂贵环节。现在，其中一部分纪律可以移到审查阶段。这并不意味着跳过规划。它意味着要精确判断哪些规划真正有回报。

在重新争论一个小变更之前，先请求一次受限的尝试。约束条件才是关键。

生成尽可能小的补丁。把它放在现有的功能开关后面。不要更改公共契约。添加或更新测试。列出你触及的每一个文件，并指出任何风险点。

如果代理无法在这些约束下生成干净的补丁，说明这个请求比你想象的更大，而且你会在任何人承诺之前就知道它带来了真正的拥有成本。如果它能生成，那么这也告诉你一些信息。无论哪种情况，你都把“是这个在范围内吗？”替换成了“这是它的成本。我们想支付吗？”

新技能是给不确定性定价

在 AI 辅助的世界里，最优秀的工程师既不是对一切都说“是”的人，也不是条件反射地说“不”的人。他们是能够快速给不确定性定价的人。他们知道什么时候一个请求其实是披着实现外衣的产品决策，什么时候审查比编写更难，以及什么时候一个变更足够小，以至于最负责任的快速回答就是直接试一试。

最后这一点是真正新的。“试一试，看看”曾经意味着把开发者从其他工作中拉出来。现在，对于合适的任务，它意味着给代理一个有界限的指派，并利用结果做出更好的判断。更少的时间用于猜测，更多的时间用于监督。更少的时间把实现当作黑箱，更多的时间评估具体工件。

范围蔓延依然真实存在。但“不行，因为任何新代码都太贵了”这个论点，比两年前弱得多。生成代码的成本下降了。理解、审查和拥有代码的成本却没有。因此，值得问的问题从“这是不是更多工作？”转变为“真正的成本在哪里？”有时，对于一个小的、有边界的变更，真正的成本只是去找出答案。

说“是”的成本已经改变。说“不”的成本也应该随之改变。