关掉AI编程助手后，我的代码写得更快了

AI 正在让你更快，还是更“懒”？

一个反直觉的现象正在开发者圈子中悄然发生：一些程序员在关闭了 GitHub Copilot 或 Cursor 这类 AI 编程助手的实时建议功能后，发现自己交付代码的速度反而变快了。

这听起来有些不可思议。毕竟，AI 编程工具的市场估值高达数百亿美元，行业报告也显示其在开发者中的渗透率已超过95%。各类研究，例如 Faros 的数据显示，使用 AI 工具的开发者工作时长和代码产出量都更高。那么，怎么会有人反其道而行之，并且声称效率得到了提升？

答案可能藏在一个被我们忽略的细节里：AI 正在重塑我们的思考习惯，而我们为此付出了隐性代价。

“微观拖延”：自动补全的甜蜜陷阱

“永远在线”的 AI 自动补全功能，就像一个时刻在你耳边低语的助手。它随时准备预测你的下一步，并给出建议。这在单行代码的层面上，无疑是高效的。但将时间拉长，这种模式会潜移默化地训练我们养成一种新的习惯：等待。

写下一行代码，光标闪烁，下意识地停顿半秒，等待 AI 给出灰色建议。这个过程每天重复成千上万次，就构成了一种“微观拖延症”。我们的大脑不再主动思考整个代码块的逻辑，而是被动地对 AI 的建议做出反应——接受、拒绝或修改。

这种思维模式的转变，可以称之为从“架构师模式”退化为“校对员模式”。我们不再是构思整个蓝图的建筑师，而更像一个逐行检查建议是否合理的校对员。短期看，这减少了记忆API和编写样板代码的负担；但长期看，它正在削弱我们进行系统性、结构性思考的能力。

从“行级思维”到“函数级思维”的回归

一位开发者在尝试关闭 AI 自动补全两周后，记录下了思维方式的显著变化：

• 第一天：阵痛。 打字变慢，频繁忘记函数参数顺序，写出了笨拙的 for 循环，而不是更优雅的 map 映射。大脑习惯性地寻求补全，而非寻找最优解。
• 第三天：转变。 他发现自己开始在动工前，思考整个函数的逻辑结构，而不是下一行代码。变量命名更有预见性，代码提交的颗粒度也变得更小、更独立。
• 第七天：突破。 完成了一个拖延已久的代码重构。他意识到，之前之所以拖延，是因为在 AI 的辅助下，重构变成了一场接受无数琐碎建议的“苦差事”。而当他独立思考时，这个过程变成了一系列清晰、可控且富有成就感的小决策。

最终，他在关闭 AI 补全的两周内，合并的 PR（代码合并请求）数量从 7 个增加到了 11 个。代码增加行数几乎不变，但删除行数（通常意味着重构和优化）却增加了 40%。

这揭示了一个核心差异：AI 自动补全优化的是“下一行代码”的编写速度，而关闭它，则倒逼我们优化“整个功能”的设计质量。后者带来的长期收益，远非前者可比。

中国语境下的“效率”迷思

这个现象在中国当下的技术环境中，尤其值得深思。

在追求快速迭代和极致效率的“卷”文化下，任何能提升“产出”的工具都会被迅速采纳。AI 编程助手完美契合了这种对短期效率的迷恋。管理者看到的，是工程师提交代码的频率变高了；工程师感受到的，是编写重复代码的痛苦减轻了。

然而，这种“速度”可能是一种幻觉。它催生了大量“看起来能用”但结构混乱、难以维护的代码。当业务逻辑需要调整或重构时，早期靠 AI “堆”出来的技术债会集中爆发，最终反而拖慢整个项目的进度。

海外的开发模式或许有更多空间允许个人进行这种“效率实验”，但在国内，对“人效”的极致追求，可能会让团队对这种“反效率”的行为更加警惕。然而，真正优秀的工程文化，恰恰需要为这种深度思考和高质量设计留出空间，而不是仅仅考核代码行数或 PR 数量。

如何与 AI 共舞，而不是被其驯化？

这并非要全盘否定 AI 编程工具。问题不在于工具本身，而在于我们与工具的交互方式。

一个更明智的策略，或许是从“被动接受”转向“主动调用”。

具体做法很简单：关闭编辑器的实时内联建议（inline-suggestion）功能，但保留 AI 聊天或代码块生成等功能。这意味着：

• 当你思路清晰时，专注写代码，不受打扰。 让你的思维自由流动，完成整个逻辑闭环。
• 当你遇到明确障碍时，主动向 AI 求助。 比如，“帮我写一个解析这个 JSON 结构的函数”、“解释一下这段正则表达式的原理”或“为这个模块生成单元测试”。

通过这种方式，AI 从一个喋喋不休的“副驾驶”，变回一个听候指令的“专家顾问”。你依然是思考和决策的主体，AI 只是你用来扫清障碍、加速特定任务的强大工具。

最终，衡量一个开发者价值的，不是他接受了多少 AI 的建议，而是他做出了多少高质量的架构决策。在 AI 时代，学会如何保护自己的专注力和深度思考能力，可能比学会使用任何一个新工具都更加重要。