看到GitHub官方博客那篇文章标题的时候愣了几秒。《The cost of saying yes has changed》。说实话 这个角度挺刁钻的。

过去两年所有人都在说AI怎么帮人写代码、怎么提效、能生成多少行。但GitHub这篇讨论的不是AI能写多少，而是——当一个功能请求可以用AI在10分钟内生成代码草案之后，什么变了？

嗯 答案出乎意料的扎心：变的不是写代码的成本，变的是做决策的成本。

以前拦住"好"的是写代码的工作量

这个逻辑其实所有工程师都懂。

一个小功能请求来了。"加个字段？显示一个时间戳？"看着很小对吧。但任何有经验的工程师都知道——"小"只是表面。你需要写代码、写测试、处理边界情况、考虑部署方案、还要在未来为这个功能负责。两个小时的变化，如果碰了不该碰的模块，可能变成两周的坑。

所以工程师学会了说不。不是不愿意做事 而是实现一个功能需要的投入远超过它表面的体量。

翻了下原文 发现了一个有意思的细节。作者描述了一个典型场景：有人要求在设置页面上显示一个已经在后端存在的 `last_active_at` 时间戳。团队开了四十分钟的会。一个人说感觉有风险。另一个人想起两年前相关的迁移。还有人提了截止日期。最后大家得出一个模糊结论——"大概一到两天吧 也可能更多" 而且信心很低。

怎么说呢 这个场景熟悉得有点扎心。真正的问题在于没有人真的去试。因为去试本身太贵了——你得停下来、加载上下文、手写代码、跑测试、然后发现后续影响。在一个两天的讨论和一个两小时的原型之间，团队选择了讨论。

AI把"去试一下"的成本降到了零头

那问题来了 AI在这里改变了什么？

答案其实很简单。一个agent可以在讨论开始的时间内生成第一个patch。它不是免费的 也不是自动正确的。但它足够便宜 以至于明智的做法不再是猜 而是看一个真实的diff。

作者管这个叫"探针"（probe）。AI生成的patch不是最终交付物 它是一种探测手段。它把一个抽象的"这个在不在范围内"的争论 变成了一个可以审视的具体工件。

这个diff长什么样？改了哪些文件？动了测试吗？影响了公共接口吗？

这些问题的质量远高于"这个感觉像不像范围蔓延？"。因为你现在是在证据而不是感觉上争论。如果那个字段需求回来是一个四行的diff加一个通过的测试 发出去就完了——真正的成本本来就是讨论本身。

但事情没有这么简单。如果同一个请求回来的diff动了auth中间件，你马上意识到这个请求从来都不"小"。而且你是在三十分钟内而不是两天内学到的这个教训。

我认为这里最容易被忽略的是——这不是让AI做决定。这是用AI让人的判断更便宜、信息更充分。

真正的成本不在生成 在拥有

这里有一个极其重要的区分点。一个变化并不只是因为代码生成变便宜就真的便宜了。一个变化只有在人能自信地审查并拥有结果时 才是真的便宜。

怎么说呢 一个通过技术审查但没人愿意接手的千行diff不是便宜的变化。它是延迟支付的成本。

所以分界线从来不是"AI能不能写这个？"而是"人能不能验证这个？"

看到这个判断的时候仔细想了一下。确实 有些变更即使代码再简单也要坚决说no。包括改变产品契约的、产生支持负担的、涉及隐私/账单/合规的。AI降低了生成候选方案的成本。但它一点都没降低拥有的成本。

传统的范围纪律发生在实现之前 因为实现是昂贵的事情 需要保护。现在逻辑变了——部分纪律可以移到审查阶段。这不意味着跳过计划。而是精确哪种计划值得做——把精力和判断力花在最需要它们的地方。

那工程师应该怎么调整

这里有个实际的操作框架。在讨论一个小功能请求之前，先做一个受约束的尝试：

生成最小的patch。放在现有feature flag后面。不改变公共契约。增加或更新测试。列出每个改动的文件 标出有风险的地方。

如果agent在这些约束下不能生成干净的patch，说明这个请求比想象中大 你在任何人承诺之前就知道了它真正的拥有成本。如果能生成 那也告诉了你一些事情。

无论哪种方式 你已经把"在不在范围内？"换成了"这就是成本 我们愿意付吗？"

从实际使用来看 这个框架的核心不是AI有多聪明 而是它让一个过去需要昂贵行动才能回答的问题 变成了一个便宜的想法验证。工程师的经验不再是"我知道这个很贵 所以我说不" 而是"我不确定这个有多贵 但我知道怎么快速找出来"。

盯着这个变化看了好一会。AI时代最好的工程师不是对所有请求都说yes的人 也不是条件反射说no的人。他们是能快速给不确定性定价的人。他们知道什么时候一个请求是穿实现外衣的产品决策 什么时候审查比写代码更难 什么时候一个变化小到最负责任的回答就是"试试看"。

最后这个能力是全新的。在过去 "试试看"意味着从其他工作中抽出一个人。现在 对于合适的任务 它意味着给agent一个边界明确的任务 用结果来做更好的决定。

花更少时间猜测 花更多时间监督。花更少时间把实现当作黑箱 花更多时间评估真实的产出。范围蔓延仍然是真实的。但"不 因为任何新代码都太贵了"这个理由 比两年前弱了很多。

代码生成的成本下降了。理解、审查和拥有的成本没有变。所以值得问的问题从"这是不是更多工作"变成了"真正的成本在哪里"。而对一个小而边界明确的变化来说 有时候真正的成本就是"搞清楚到底多贵"的过程。

说"好"的成本变了。说"不"的成本 也应该跟着变。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）