看到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.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版