AI没让编程变轻松，只是把累人的部分换了一种累法

我开始认真用AI工具写 side project 的时候，以为工作会变轻松。AI搞定样板代码，我专注有趣的部分。当时大家都是这么说的。

结果并没有变轻松。有趣的部分变得更难、更频繁、更让人精疲力竭。

这么想的不止我一个。一位 Google Staff Engineer 最近离职，帖子火了——不是为了钱，不是为了福利，是因为工作变得仓促且失去意义。AI被硬塞进不适合它的场景。他凌晨两点被叫起来处理事故。他写道："我不想只是别人的执行工具。"

如果这种事发生在 Google——地球上技术能力最强的组织之一——那值得追问一下：AI到底对软件工程做了什么？不是看新闻稿，是看实际发生了什么。

以下是我观察到的真实情况。

以前的工作：80%执行，20%思考

软件工程史上大部分时候，工作大致这样划分：

80%——执行层

• 写样板代码

• 修重复出现的 bug

• 流转工单、更新文档

• 配环境、设配置

• 为已知行为写测试

20%——深度思考

• 理解真正的问题是什么

• 在约束条件下设计系统

• 调试没人预料到的边界情况

• 信息不全时做权衡

• 知道什么不该做

80%是体力活，必要但可学。20%才是经验值钱的地方——资深工程师不是靠打字快，而是靠想得更清楚。

AI吃掉了80%。现在20%成了全部工作。

Claude Code、Cursor、GitHub Copilot 在执行层确实出色。样板代码？没了。标准 CRUD 接口？几秒搞定。重复测试？咖啡没喝完就生成了。

当时的说法是：这是好消息。工程师从无聊工作中解放出来，可以专注有趣的问题了。

某种意义上确实如此。但有个没人明说的事实：

20%之所以难，恰恰因为它需要持续、深度的专注。现在工程师被期望永久待在那个状态——而人脑不是这么设计的。

20%成了新的80%。而且累法完全不同。

写三小时样板代码很无聊，但大脑能恢复。花三小时设计分布式系统的故障模式、做架构权衡、调试只在特定负载下出现的竞态条件——这是另一种累。而且 AI 没有减少你做这些的频率，反而增加了。

没人提"人类上下文窗口"

AI 领域一直在讨论上下文窗口：模型能容纳多少 token？怎么优化检索？怎么确保模型在正确时间拿到正确信息？

这是完全合理的工程问题。但还有另一个上下文窗口问题没人谈：人类的。

深度思考不是开关。进入状态需要时间——建立心理模型、加载相关背景、在脑中维持系统的连贯图景。这个"加载时间"是真实的认知成本。

旧的工作流里，80%的执行层成了认知缓冲。写样板代码时，大脑在后台消化问题。等坐到白板前，你已经准备好了。

新工作流里，这个缓冲没了。AI 生成代码的速度超过了你理解它的速度。你一直在"加载"，从未真正"运行"。

结果是决策疲劳的慢性状态。每个问题都 urgent，每个上下文切换都 costly，而恢复时间被压缩到零。

质量悖论

这里有个反直觉的效应：AI 让写代码更快，但让写对代码更难。

当你手写样板时，你在思考。不是深度思考，是浅层但持续的思考。你在感知模式、发现不一致、建立直觉。

AI 生成代码时，你在验证。这是不同的认知模式——更批判性，更防御性，也更消耗。你在找 AI 可能漏掉的东西，而不是自己构建理解。

问题是：AI 的错误不是人的错误。它们更微妙、更系统级、更难察觉。一个拼写错误 IDE 会标红。一个架构层面的错误假设，AI 会自信地实现，而你需要足够的背景才能发现。

验证比创造更累，因为你没有直觉的锚点。你是在检查别人的工作，而且这个人不会累、不会解释、不会承认不确定。

技能萎缩的隐形代价

还有个长期问题：如果你从不写样板代码，你怎么学会识别坏样板？

软件工程里很多"直觉"来自重复暴露。你写过足够多的 CRUD 接口，才能一眼看出哪个设计会埋下技术债。你调试过足够多的竞态条件，才能在代码审查时嗅出隐患。

AI 把这个学习循环切断了。初级工程师拿到能跑的代码，但不知道为什么能跑。他们跳过了形成直觉所需的数千次小失败。

短期看这是效率。长期看这是债务——只是还款周期拉长到了职业生涯尺度。

那怎么办？

我没有简单的答案。AI 工具不会消失，也不应该消失。它们在合适的地方确实强大。

但我们需要诚实面对 trade-off。效率的提升有隐藏成本：认知负荷、技能发展、工作意义感。这些不会出现在 productivity dashboard 上，但会出现在 burnout 统计和离职访谈里。

那位 Google 工程师的帖子下面，最高赞评论是："我以为只有我有这种感觉。"

也许第一步就是承认：这不是你个人的问题。这是系统设计的问题。而系统是可以重新设计的。

只是别指望 AI 来设计它。