AI 并没有让我更快。它让我有足够的勇气去学习更多。

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文。

过去几个月

在我们正常的功能工作之外，我已经：

• 将我们的 CI 测试时间缩短了 70 %
• 将 API 请求减少了 30 %
• 推出了那些在 “某天” 区域卡了几个月的功能

这并不是因为我突然变成了更好的开发者，而是因为 AI 让我 探索并摆弄那些我以前不敢触碰的系统部分。

成熟代码库的现实

当我加入时，基础已经搭建完毕。聪明且经验丰富的同事们已经做出了架构决策，选择了技术栈，并建立了我们所有人遵循的模式。

• 状态管理、路由、数据获取、认证流程——全部已配置
• CI/CD 流水线已设置好
• 测试基础设施已经就绪

这并不是一个崭新、完美工程化的代码库。和任何已经运行一段时间的大型系统一样，它有技术债务、古怪的决策以及偶尔让人皱眉的实现。我们最近在巨大的截止日期压力下完成了一次重大系统改造。有些东西是经过深思熟虑的；有些则是匆忙完成的。这就是大规模交付软件的现实。

但这并不是有趣的部分。

真正的问题在于：当你加入一个成熟的项目时，你无法做出重大决策。你继承的是结果，而不是导致这些结果的过程。你遵循约定，但很少有机会去探索替代方案。

• 我可以在我们的状态管理体系内工作，但我从未评估过为什么会选择它，或者它做了哪些权衡。
• CI 流水线已经存在并且大体可用。动它感觉风险很大——而且没有必要。

有一条不成文的规则，大多数在成熟公司工作的开发者都会认同：“如果它没有坏，就不要去修它。” 随着多年里资深开发者陆续离开项目并带走了关键的上下文，其余人对触碰任何基础设施的犹豫越来越大。宁可绕开怪癖，也不愿冒险破坏我们并不完全了解的东西。

更何况，任何不是直接面向客户的工作几乎从不被赋予高优先级。产品团队会合理地优先考虑可见的功能。提升开发者体验的改进？基础设施工作？它们会在某个时点实现——但总有更紧急的事情。

这就是成熟代码库的隐藏成本。 你会变得擅长在系统中运作，却停止学习它到底是如何工作的。基础开始显得不可触碰。

进入 AI：降低好奇的成本

我并不是 AI 编码工具的新手。早在 2023 年初我就尝试过它们，最初真的很兴奋，但现实并不尽如人意。上下文经常混乱，建议在细节上失效，我花在修复 AI 生成代码的时间甚至比自己手写的还多。热度很快就消退了。

随后，在 2025 年春，我尝试了 Claude Code。这一次，真的有了改变。

我意识到，AI 的核心并不是让代码写得更快，而是降低探索的成本。

它为我提供了以下杠杆：

• 在代码库中导航不熟悉的部分
• 无摩擦地提出基础或重复性的问题
• 快速尝试想法并在正式提交前进行验证

以前需要两三次冲刺才能估算的功能，突然可以在几天内完成——且不需要偷工减料。代码仍然要经过审查，仍然符合我们的标准，但弄清楚问题的摩擦显著降低。

更重要的是，这种速度为我们创造了呼吸的空间——有余地去探索、实验和学习，而不会把交付风险置于危险之中。这也彻底改变了我的工作方式。

从交付功能到学习系统

在 AI 为我争取到的喘息空间里，我开始探索那些一直停留在 “有时间再做的好事” 心理类别的领域。事实上，从来没有时间。直到突然，时间出现了。

几个例子都遵循相同的模式：识别出让人感到畏惧或未被充分探索的事物，安全地进行实验，验证结果，并在过程中学习。

前端缓存

我分析了我们的 API 调用模式，并实现了缓存策略，使后端请求量降低约 30 %。这意味着后端负载更轻——在票务发布等高流量日子里更稳健——并且降低了基础设施成本。AI 之前，这看起来很冒险——未知因素太多，出错的可能性太多。借助 AI，我能够推理系统、快速测试假设，并迭代直到成功。

性能优化

我为较重的组件实现了懒加载，既使用了标准模式，也使用了 requestIdleCallback（一种浏览器 API，允许将非紧急工作推迟到主线程空闲时执行）。我并没有一夜之间成为浏览器调度专家，但我可以尝试不同方法、测量结果，并在无需数周前期学习的情况下交付有意义的改进。

测试基础设施

我们的集成测试套件拥有超过 850 条测试，运行时间超过 20 分钟，且极其不稳定。多次重新运行流水线是常态。我实现了 测试分片，将执行时间压缩至 5–7 分钟，几乎彻底消除了不稳定性。之前，CI 配置看起来过于关键且不透明，令人望而却步。借助 AI，我能够逐步且安全地进行探索。

“有一天”功能

和大多数团队一样，我们有一些从未形成工单的想法——在工作中注意到的改进，但知道不会被优先考虑。比如扩展对话框和表格视图，或让客户在旅途中看到中间站点。借助 AI，我可以在一个下午内完成概念验证，向设计师展示，吸收反馈，并在一周内交付。原本可能无限期搁置的功能，突然变成了现实。

没有 AI 降低的好奇成本，这一切都不可能发生。

AI 降低了学习的门槛——让好奇心再次变得安全。

实际成为瓶颈的是什么

这里有一个我没预料到的更广阔的洞见：写代码已经不再是最慢的环节。

多年来，我们一直把开发时间视为主要约束。冲刺计划围绕实现能力制定。功能的范围取决于我们认为编码需要多长时间。技术债务不断累积，因为“我们没有时间”。

AI 改变了这套算式。

我现在可以在一个下午内完成一个功能的可信概念验证。但要让该功能获得批准、与设计保持一致、经过利益相关者审查并排入路线图？这仍然需要数周时间。

新的瓶颈是代码之外的所有环节：

• 决策与优先级划定
• 设计反馈循环
• 跨团队对齐
• 审查与发布流程

这不是抱怨——而是观察。开发工作的本质正在改变。能够脱颖而出的开发者不仅仅是打字最快的或最深的专家。他们将是能够在使用 AI 消除技术摩擦的同时，驾驭软件的人际和组织层面的从业者。

对好奇心（与谨慎）的一封邀请

如果你在一个成熟的代码库中工作，觉得系统中有些部分根本不敢碰，我能理解——我也曾有过同感。我的建议很简单：利用 AI 降低尝试的成本。

AI 不仅能帮助你更快完成工作，还能让你重新获得好奇的许可。可以用它来：

• 为你一直在考虑的缓存层做原型。
• 试着修复不稳定的测试。
• 为一个“可有可无”的想法构建概念验证（proof‑of‑concept）。

你不需要在开始之前就完全理解——通常只要尝试一下，验证它能工作，并在过程中学习就足够了。

然而，好奇心并不是鲁莽的借口。 AI 不是魔法。它可能：

• 产生细微的 bug。
• 加强已有的架构错误。
• 如果使用不慎，会让人产生错误的自信。

虽然 AI 让你能够触及一直在回避的系统部分，但它绝不应该取代你的判断——它应当放大你的判断力。

指导原则

• 不要盲目在安全关键代码上进行实验。
• 高度依赖测试、同行评审和团队成员的反馈。
• 验证一切，而不是让“对未知的恐惧”变成“盲目信任”。

在一个变化如此迅速的领域，安全探索未知的能力或许是最有价值的技能。利用 AI 弥合这段距离，但请始终把握方向盘。

如果你有类似的经历，我很想听听你的故事。