说"好"的成本已经变了
过去，一个小功能需求最贵的部分是写代码。现在，通常是“要不要写这段代码”的那场会议。这确实是实实在在的变化，而且它悄悄让很多工程师的本能失灵了。
工程师入行不久就会学到：大多数“小要求”其实不小。它们需要测试、需要上线计划、需要有人把边界情况想清楚，还要在功能发布之后继续负责维护。一个两小时的改动，如果碰错了系统的某个部分，可能演变成两周的干扰。所以我们习惯性地说不：这真的需要吗？适不适合放进这个版本？会不会改动我们已经达成的接口约定？我不打算放弃这种直觉。但它背后有一个假设，而这个假设正在悄悄失效——写第一版代码才是最贵的一步。对某一类改动来说，这个假设已经不再成立。如果你能分辨出这类改动和其他改动的区别，就可以把“这算不算在范围内？”换成另一个三十分钟就能回答的问题，而不是花两天去争论。
争论往往比补丁本身更贵
我反复看到同一个模式：有人提了一个小改动，比如在设置页面上展示一个后端早就存好的 last_active_at 时间戳。团队在聊天群里来回讨论了四十分钟。一个人说听起来有风险；有人想起两年前相关的一次数据库迁移；有人提起截止日期。最后大家的结论是“大概一两天，也可能更久”，而且信心不足，主要是因为根本没人真正动手试过。
在“试一下”本身很贵的时代，这套流程是合理的。你得停下手头的事，把上下文重新加载进脑子，手动改代码、写测试，然后才发现第二层、第三层的连带后果。但如果第一次尝试很便宜，守边界花的功夫可能比跨过边界更贵。群里刚讨论出一点热度，agent 就已经把第一版补丁写出来了。它不免费，也肯定不保证正确。但它便宜到——明智的做法往往是别再猜了，直接看一份真实的 diff。
第一版补丁是询价，不是交付物
误区在于把生成的补丁当成交付物。它不是。它是一个探针。
它把一场抽象的范围争论，变成了一份可以摆在桌面上逐条拷问的具体产物：它动的是你预期中的文件吗，还是横跨了五个包？测试写得清楚明白，还是这个改动压根就不好测？它有没有保留原有的抽象设计？它是不是在悄悄逼你做一个新的产品决策？半年之后，你还愿意为这个行为负责吗？这些问题比“这算不算范围蠕变”要强得多，因为你现在是在拿证据争论，而不是凭感觉。如果 last_active_at 这个字段最终拿回来的是一个四行的 diff 外加一个通过的测试，那就放行吧。真正花力气的是前面那场辩论。但如果同一个请求回来的时候动了认证中间件，你就该明白：这个需求从来就不小。而且，你只用三十分钟就看清了这点，而不是等两天之后才反应过来。这不是让 AI 来做决定，而是用 AI 让人的判断变得更廉价、更有依据。
写得便宜，不等于拥有得便宜
这里有个陷阱，也是 AI 时代最重要的一条分界线：一个改动便宜，不是因为它生成代码的时候便宜，而是因为有人能放心地 review、放心地对它负责。一个一千行的 diff，技术上能通过但没人愿意接手，那不叫便宜，那只是把成本往后拖。所以这个场景下的分界线不是“Agent 能不能写出来”，而是“人能不能验证得了”。
后端已经有这个字段，只是把它显示到界面上，这种改动通常很便宜。改动授权逻辑则绝不便宜，不管 diff 看起来多干净都一样。重构一个有完备测试的工具函数，通常很便宜。改数据保留的语义，则不便宜。哪怕代码本身微不足道，照样有很多改动该果断拒绝：任何动了产品契约的、会带来客服负担的、牵扯到隐私、计费或合规的，都属于这一类。AI 降低了生成一个候选方案的成本，但对“接手这个改动”的成本毫无帮助。
让范围纪律更贴近证据
过去，范围管控发生在动手写代码之前，因为实现本身才是需要保护的那个昂贵环节。现在，部分管控可以挪到 review 阶段来做。但这不是说可以跳过规划。
这意味着要精确定位哪些规划真正值得投入。在重新争论一个小改动之前，先要求一次受限的尝试——限制条件本身就是关键。生成尽可能小的补丁，放在现有功能开关后面，不改变公共契约，添加或更新测试，列出你动过的每一个文件，并指出任何有风险的地方。如果 agent 在这些约束下拿不出干净的补丁，说明这个请求比你预想的要大，而且在任何人承诺之前，你就清楚它带着真实的维护成本；如果它能做到，那同样说明问题。无论哪种情况，你都已经把「这算不算在范围内？」换成了「这是它的成本，我们愿意付吗？」
新技能是为不确定性定价。在 AI 辅助的世界里，最优秀的工程师不会是那些对一切都说「好」的人，也不会是那些条件反射式拒绝的人。他们会是那些能快速为不确定性定价的人。他们知道什么时候一个请求是披着实现外衣的产品决策，什么时候评审比写代码更难，什么时候改动足够小，以至于最负责任的快速答复就是直接试一试。最后这一点是真正的新事物。「试试看」过去意味着把开发人员从其他工作中拉出来；现在，对于合适的任务，它意味着交给 agent 一个限定范围的任务，然后用结果做出更好的判断。少花时间猜测，多花时间监督；少把实现当作黑箱，多去评估具体的产出物。
范围蔓延依然真实存在。但「不行，因为任何新代码都太贵了」这个理由，已经比两年前弱了很多。生成代码的成本下降了，而理解、评审和长期维护它的成本没有。所以值得问的问题从「这是不是更多工作？」变成了「真正的成本在哪里？」而有时候，对于一个小的、有边界的改动，真正的成本就是去搞清楚。说「好」的成本变了，说「不」的成本也应该随之改变。
「The cost of saying yes has changed」一文最初发布在 GitHub Blog 上。