AI辅助开发的代价：认知疲劳

经过三个月的AI辅助开发，我的生产力达到了前所未有的高度，但我也经历了意想不到的精神疲惫。效率提升是真实的，从草图到工作原型只需数小时而非数天。然而，有一个隐藏的成本常被忽视：这些工具从根本上改变了编程的认知负荷。我不再因纠结于实现细节而感到疲劳，而是因持续在架构和设计层面操作而精疲力竭。事实证明，拥有一个不知疲倦的编码伙伴会带来一种新的倦怠。

传统的编程疲劳源于对细节的持续关注：与语法斗争、调试晦涩的错误、或重复的实现工作。AI工具消除了大部分此类摩擦，但取而代之的是更微妙、更耗神的设计层面的决策疲劳。当你能在以往实现一个解决方案的时间内原型化三种不同方案时，你便不断地做出架构决策：这应该是服务吗？库？简单脚本？错误处理呢？数据持久化？每个决策都会衍生更多决策，而AI随时准备实现你选择的任何方案。

瓶颈从“我能构建这个吗？”转变为“我应该构建这个吗？以及如何构建？”这是更加沉重的认知负荷，且积累速度远超预期。我发现自己需要休息，不是因为被问题卡住，而是因为大脑在高抽象层次思考太久而感到疲倦。这就像对大脑最高级功能进行间歇训练。

最令人震惊的变化是你迅速撞上基本设计决策的速度。传统开发中，你在实现、测试和扩展时才会发现更多架构问题。你有时间思考其影响，因为编写代码本身需要时间。而AI辅助下，你立即遇到这些障碍。实现速度如此之快，以至于你在没有充分考虑之前就面临数据模型、API设计和系统边界等问题。但还有更深层的现象：当人类编写代码时，我们在工作中思考架构，做出小的调整，边编码边重构，将架构决策体现在实现过程中。AI并非如此，或者说它至少在输出中不传达这类思考。结果是代码虽然能工作，但感觉架构扁平，仅实现了你的要求，却缺乏人类实现过程中自然发生的细致设计改进。你不得不做更多显式的架构思考来弥补缺失。

需要审查的代码量激增，但这还不是最难的。真正挑战在于事后无法追问AI的推理逻辑。人类程序员做出奇怪选择时，你可以询问原因；而AI这样做时，其推理隐藏在更大的变更集中。尝试在决策后就具体问题询问AI，只会得到阿谀奉承的道歉：“很抱歉，那是个糟糕的选择，让我修复它。”但我不想要道歉，我想了解导致该实现的权衡。这在代码审查中创造了前所未有的盲点：你审查的是“什么”，却没有“为什么”的上下文，这使得评估方法是否稳健或只是碰巧能工作变得更加困难。因此测试纪律变得至关重要。如果AI不测试自己的代码（通常除非你明确要求，否则不会），那么你就在正确性上盲目飞行。如果调试紧正确的测试本可捕捉的微妙问题，效率优势会迅速消失。

适应不是仅仅更好地使用工具，而是培养持续进行高层次思考的新心智。大脑需要时间在这方面变得更强。我开始更刻意地休息，尤其是在重大设计转变之间。我会离开电脑以清除自己的心智上下文。这与清除AI对话上下文并非巧合——人和AI的思维都会因携带过多信息而变得混乱。另一种适应是将AI用作设计探索的思考伙伴，而不仅仅是实现工具。我不会直接要求“构建这个”，而是花更多时间提问：缺少什么？之前有什么做法？有哪些权衡？AI实际上很擅长这类分析，这有助于前瞻性地完成架构思考。

这种实践类似于工作方式的其他重大转变。版本控制系统普及时，我们需养成提交和分支的新习惯；测试框架成熟时，我们需内化编写可测试代码的特定模式。AI辅助开发是另一根本性转变，需要构建新习惯和心智模型。疲劳是真实的，但也是暂时的。像任何新工作方式一样，它需要练习才能变得自然。奇怪的是，这种疲惫与对可能性的真正兴奋并存。我正在构建更有趣的东西，探索更多方法，发布更精致的原型，但也学会了以以前不需要的方式调整节奏。

我们仍处于理解AI如何改变编程实际体验的早期阶段。生产力提升备受关注，但认知转变同样重要，需要成功驾驭。能够茁壮成长的开发者将是那些认识到这些工具不仅改变你能构建的东西——它们还改变你对构建的思考方式的人。AI放大了你的最高层次思考，这极其强大，但在精神上也非常消耗，我们仍在学习如何管理。适应期是值得的，但不要低估学习曲线，尤其是发生在你大脑内部的部分。给你的大脑时间发展这些新肌肉。工具会等待。