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

我开始认真用AI工具做 side project 的时候，以为工作会变轻松。AI处理样板代码，我专注有趣的部分。这是承诺。

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

不止我这样。最近一位 Google Staff Engineer 离职的事传得很广——不是为了钱，不是为了福利，而是因为工作变得匆忙且失去意义。AI被硬塞进不适合的地方。他凌晨两点被叫起来处理问题。他写道："我不想只是别人的执行工具。"

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

我认为真正的情况是这样的。

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

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

80%——执行

• 写样板代码

• 修重复性bug

• 搬ticket、更新文档

• 配环境、设配置

• 为已知行为写测试

20%——深度思考

• 理解真正的问题

• 在约束下设计系统

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

• 信息不全时做权衡

• 知道什么不该做

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

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

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

叙事是：这是好消息。工程师从无聊工作中解放，可以专注有趣问题。

某种意义上，这是真的。但有个没人明说的事：

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

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

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

没人在谈"人类上下文窗口"

AI圈 constantly 在讨论上下文窗口。模型能hold多少token？怎么优化检索？怎么确保模型在正确时间有正确信息？

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

人的工作记忆有限。深度思考需要把大量信息load进脑子里，保持足够长时间来建立联系、发现模式、预见后果。这是认知上的heavy lifting。

以前的节奏是：执行一阵（让大脑休息），然后深度思考一阵。现在AI把执行压缩到几乎为零，深度思考被连成了马拉松。

更糟的是，AI生成的代码需要更多审查。不是更少。你得理解它写了什么，为什么这样写，边界情况是什么。这本身就是深度思考工作。

质量在变成个人责任，但时间没有给够

以前团队有代码审查、设计评审、架构讨论。这些过程慢，但分散了认知负担。

现在AI让"产出"速度暴涨，流程被压缩。审查变成扫一眼。设计评审变成"先上线再说"。架构讨论变成"让AI迭代"。

结果：个人工程师现在要对更多决策负责，但做决策的时间更少。

那位Google工程师说的"执行工具"就是这个意思。不是不想工作，是不想在没有空间思考的情况下被推着跑。

这不是反对AI

AI工具确实强大。我用Cursor和Copilot，它们省了大量时间。问题不在工具本身，在使用工具的上下文。

公司把AI当成"让工程师产出更多代码"的方式，而不是"让工程师做更好决策"的方式。指标是velocity，不是quality。是features shipped，不是problems solved。

当80%的执行工作消失，20%的思考工作被暴露出来。但组织没有重新设计工作方式来适应这个现实，只是用更多思考工作填满了空出来的时间。

可能的出路

这不是技术问题，是组织问题。一些方向：

• 承认深度思考需要时间，保护工程师的专注时间（不是填满calendar）

• 把AI省下的时间真的还给工程师，而不是用来塞更多任务

• 重建被压缩的质量流程，即使它让"速度"数字变难看

• 重新设计成功指标：从"写了多少代码"转向"解决了什么问题"

那位Google工程师的离职是个信号。不是AI不好，是我们用错了方式。把人类当成无限上下文窗口的机器，最终会把人烧光。

AI没有让软件工程变容易。它只是让难的部分更明显了。现在的问题是：我们要不要承认这一点，还是继续假装一切都只是"执行"的问题？