商业第 179 期

为什么没有团队负责人愿意专门去修Bug

AI能帮你写代码，却没人给你修代码的理由

安光涉（Oswarld）· OZ Talking 作者与编辑

为什么没有团队负责人愿意专门去修Bug

开篇

订阅者朋友，上周我读到一位开发者写的经历。银行App在支付确认页面竟要求做三次人脸识别，姗姗来迟弹出的Slack窗口抢走了焦点，导致他正在终端里敲的命令被发进了群聊。冰箱保修申请填完一长串表单后，最后一步失败了。车载信息娱乐系统在更新之后，行驶途中会重启。

他补充的一个场景令人印象深刻。几个月前，重新设计那套车载操作系统的团队的PM在领英上发文自夸完成了一件了不起的工作。而每天都在与这个产品搏斗的用户，会不断想起那条帖子。

制造方的自我庆祝和使用方的真实体感，很少像现在这样割裂。先说结论：AI在很大程度上解决了“代码写得不够快”的问题，但完全没有触碰“没人为修复者提供任何回报”的问题。工具越好用，这道裂缝就越大。

吞吐量确实提高了

首先要澄清一点：这不是那种“都怪AI，一切都变糟了”的论调。速度确实变快了。

谷歌DORA团队针对全球约5,000名技术从业者所做的2025年报告显示，**90%**的受访者在工作中使用AI，每日使用时长的中位数为2小时。与2024年的调查不同，这次观测到：AI采用度越高，软件交付吞吐量与产品绩效同步上升的关系。这说明各团队正在学习该把工具用在何处、如何使用。

同一方向也有单独的数据支持。分析代码变更历史的GitClear在2026年1月发布的报告显示，使用AI最多的开发者群体，产出量是不使用者的4至10倍。不过这里附带一个诚实的说明：这一差距的很大一部分其实是AI出现之前就存在的个人能力差异；若拿同一个人的过去做对比，速度提升幅度约为25%。这更像是原本就擅长的人先拿起了AI，而不是AI把人变得擅长。

问题在于同一份DORA报告中并列呈现的另一个结果：AI采用度越高，部署不稳定性1也随之上升。这意味着因故障而产生的计划外部署增多了。DORA把这种组合总结为：AI是放大器。它既放大原本运转良好的组织的优势，也同样放大那些本就摇摇欲坠的组织的缺陷。

消失的不是代码，而是习惯

那么到底是什么在被放大？GitClear于2026年推出的后续研究，对这一点给出了相当具体的说明。这份资料把2023年到2026年间6亿2,300万次代码变更，拆分成八个信号加以追踪，方向高度一致。

最引人注目的是重构2的消失。在全部变更行数中，“被移动的代码”——也就是对既有代码进行整理再排布的比例，从2022年的21%降到了2026年当前的3.8%。同期，复制粘贴而来的代码比例则从9.4%上升到15.7%。2022年时，开发者选择整理代码的次数还是选择粘贴代码的2倍，如今反过来，粘贴以约5倍的优势占据主导。这不只是偏好的反转，而是整个方向都变了。

其余数字讲的也是同一个故事。连续重复五行以上的重复代码块，比2023年增加了81%，创下有记录以来的最高值。新写代码调用既有代码中其他函数的频率下降了35%，也就是说新代码正孤立地存在于与既有代码库脱节的独立文件中。对一年以上未曾动过的旧代码重新打开、加以整理或废弃的工作占比，从1.7%降到了0.46%，降幅达74%。

要理解这为何成问题，只需想象一个重复代码块。一个五行的代码块散落在十个地方，负责修复其中一处的人，就自动背上了要找出其余九处、并判断“这里是不是也得一起改”的义务——即便涉及他并不了解的文件和领域。今天省下的30秒，代价是三年后由某人分成好几个半天来偿还。

GitClear把这种状态称为“可维护性差距”。报告将核心归纳为：问题不在于AI写出了糟糕的代码，而在于当下默认的工作流程，本来就被设计成只交付一条幸福路径、一次通过的测试、一张关闭的工单。看得见、能立刻关闭的事情会得到回报，看不见、被推迟的事情则悄悄被征税。

那为什么没人去修

于是真正的问题浮现了：工具明明变得如此好用，为什么没人偿还这笔债务？前文引用的那位开发者，用一句虚构的发言把答案写了出来。

“这个季度我们不会发布新功能，也没有重新设计的计划，只专注于修复Bug。”

有多少组织真能把这句话摆上季度计划的幻灯片？我几乎没见过。原因很简单：新功能有演示、有可以讲述的故事、有能写进绩效评估的句子。而稳定化工作若做成功了，呈现的形式就是“什么都没发生”。做得好的证据，只能以“不存在的问题”这种形式存在。

bug所以这看似是技术问题，实则是衡量与回报的问题。吞吐量会实时显示在仪表盘上，而可维护性则以三年后的账单形式到来。如果管理者只能看到其中一项，会管理哪一项，答案早已注定。

在韩国，这种扭曲甚至超出了单个公司的文化范畴，被写进了整个行业的价目表里。这说的是公共软件维护费率3的故事。政府在2017年国政悬案检查调整会议上确定，要把该费率从15%左右提升到2022年的20%，以缩小与外国软件（约22%）之间的差距。然而软件政策研究所2019年的产业实态调查显示，仍有**29.8%**的受访企业适用不到10%的费率。民间平均值为14.2%，也就是说公共部门反而更低。给创造定高价、给修复压低价的惯例，已经以文件形式留存了数十年。

结果也在悄然累积。金融监督院在2026年3月的数字·IT部门业务说明会上指出，近来发生的许多事故并非源于精巧的黑客技术，而是源于基本的安全原则和内部控制未被遵守。也就是说，失败的原因不是尖端技术，而是基本功。而基本功，向来是没人会为你鼓掌的领域。

这些数字也该被质疑

读到这里，如果直接得出“果然是AI的问题”这种结论，就有问题了。我们也要一起看看这些证据的局限。

首先，GitClear不是一个中立的观察者。它是一家出售代码质量与开发生产力测量工具的公司。“质量指标正在恶化”这个结论，与这家公司的商业利益是重叠的。数据规模大，并不等于解读是中立的。

DORA的调查在很大程度上也是自我报告式问卷，观测到的只是相关关系。到底是使用AI较多的团队更不稳定，还是本来就习惯快速推进的团队也更早采用了AI，仅凭这份数据无法区分。

最有意思的是一度被广泛引用的METR研究。在2025年7月发布的结果中，16名熟练开发者被随机分配4了246项真实任务，结果显示使用AI时完成时间反而多花了19%。然而METR在2026年2月自行修改了实验设计，理由是从AI中获益越大的开发者，越倾向于回避被分到“禁用AI”条件的组别，存在选择性偏差。以重新参与者为基准重新估算后，结果反而是快了18%。总结来说，研究团队自己已经退回到接近“我们自己也还不知道AI是否能提升生产力”的立场。

不过这次修正之后，还有一个发现留存了下来，那就是认知与时钟之间的落差。参与者在实验开始前预期速度会提升24%，实验结束后自己也感觉快了20%。无论实测值指向哪一边，“人无法凭感觉准确衡量自己生产力变化”这个结论依然成立。而眼下，大多数组织正是凭那种感觉在引入工具、制定人力规划。

Oswarld视角

在制定GTM战略的过程中，我参加过无数次产品路线图会议。稳定化事项在优先级排序中被挤到后面的场景，几乎无一例外地反复上演。有趣的是，会议室里没有一个人真的轻视质量。可是到了要选出一句放进季度目标的话时，“我们减少了40%的故障”永远比不过“我们发布了三个新功能”。前一句话必须去证明一件没有发生的事，而后一句只需要展示出来即可。

补充一点数据方面的经验：“只有被衡量的东西才会被管理”这句话，在组织里几乎像物理法则一样运作。所以我并不认为这次问题的根源在于AI。这本来就是既有的扭曲，AI只是让它执行得更快罢了。当制作功能的成本降到十分之一，原本就已经倾向功能一侧的天平会倾斜得更厉害。而反过来，整理与废弃的工作依然需要人的判断和时间，相对而言就显得更贵。

所以我认为，把这个问题当作“工具选择”问题来处理的组织，大多会失败。无论用Cursor还是Claude Code，只要季度计划里没有“修复工作”的位置，结果都一样。DORA给出的结论说的正是同一件事：AI落地的成败不是工具问题，而是系统问题。

有一点我想留个开口。原文那位开发者也没有只留下悲观，他还写下了这样的期待：在企业不断堆积债务的同时，个人开发者已经能够独自打造出以前想都不敢想的软件。同一件工具，既能制造债务，也能把力量交给那些受够了债务、想找出路的人。

结语

用三句话总结：AI落地之后，吞吐量提高了，但像重构比例降到3.8%、重复代码块增加81%这样能让代码“活得更久”的习惯，全面倒退了。这不是因为AI写出了糟糕的代码，而是因为关闭的工单能得到回报，而没有发生的故障却得不到任何回报。韩国甚至把这种扭曲以维护费率的形式，刻进了价目表里。

给这个季度提个可以尝试的建议：打开路线图，数一数有多少百分比被分配给了“修复与整理”的工作。如果这个数字接近于零，那不是团队的问题，而是计划书的问题。

您是否见过某个组织把整整一个季度都用于稳定化，而不是新功能？我尤其好奇那个决定是怎么获得通过的，以及在之后的评估中，那个团队受到了怎样的对待。

💬 欢迎在评论区分享把整个季度都用于稳定化的组织案例，我们会在下一期中参考。 📨 如果您身边有同事正为了把质量事项塞进路线图而苦恼，请把这篇文章分享给他们。

参考资料与延伸阅读

核心来源

背景知识

值得一起阅读的往期

📝 术语说明

安光涉个人插画

作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。

注释

  1. 部署不稳定性 (delivery instability)：指发布新代码后，因故障或缺陷而不得不重新进行计划外部署的频率。与速度不同，这是用户能立即感受到的指标。 ↩

  2. 重构 (refactoring)：在保持程序功能不变的前提下，只整理代码结构的工作。与其说是新增房间，不如说更接近于把已有的行李收拾整齐。 ↩

  3. 维护费率：乘以软件开发费用以确定年度维护成本的比率。若费率为10%，则一套价值1亿韩元的系统，其年度维护费用即为1,000万韩元。 ↩

  4. 随机分配 (randomized assignment)：将参与者或任务随机分配到实验条件中的方式。它能减少条件之外的差异混入结果，因而比简单比较更有利于说明因果关系。 ↩

延伸阅读

第 178 期商业

可以下载，只是无法运行

2.8万亿参数Kimi K3与“开放”的重新计算

第 177 期商业

兔子死了，账单还是会寄来

因好玩上传的翻译第112集，法院给出的价码是9,637万韩元

第 176 期商业

新任美联储主席为何说话像创业公司

“数字还没出来，但快了”，这种话术已经开始撬动利率了