由于公司不再提供给员工足量的token使用，在被模型限流和不那么聪明的AI折磨了将近一个月以后，我在这个月月初开通了CodeX Pro套餐，打算正式开始尝试使用AI代替我完成coding工作。

刚刚开通CodeX Pro套餐的时候，那种感觉如有神助。我相信很多人都会有这样的感觉：相比不那么聪明的模型，即便你描述清楚了要做的事情是什么，模型依旧无法完整地实现；用上了满血版的GPT-5.5以后，我似乎可以只通过模糊地概括一下我想要得到的结果（就像我的Leader那样），AI就能帮我做出让我满意甚至惊喜的产物出来。在刚刚上手CodeX的时候，这种新鲜感促使我在工作项目和个人项目上高强度使用它，还用它为一些项目创建了知识地图。当时的我十分相信有了CodeX的帮助，我必定能节约下来非常多的工作时间，早下班不再是梦想。

然而随着AI Coding强度的增长，问题也渐渐暴露了出来。让我在当前这个时间节点不得不重新思考一下古法编程与AI Coding之间的平衡，应该如何抉择。

时间真的节约下来了吗？

不开玩笑，自从有了AI Coding，我工作时间拿起手机的次数至少比起之前提高了一倍。这其中95%的时间都是在等待AI编码，其余5%的时间才是真的需要手机来回复消息/处理问题。不仅仅是拿起手机，在等待AI期间，我还会不自觉地在打开的多个tab之间切换，亦或者进入企微漫无目的地查看消息。

我时长调侃自己是一个单核的CPU，在一个线程阻塞的时候，只能不断地去调度其他线程的任务，即便可能完全没有任务。

对项目的理解更深了吗

为了不浪费这段时间，也为了真正能在单位时间内让AI做更多的事情，我不得不同时开多个AI上下文窗口让AI并行做很多事。这就不得不让我快速地在多个项目上下文之间切换我的注意力。大脑上下文切换的开销比我想象的要大很多，我经常在下午四五点钟的时候感到精疲力尽，按说应该吸收了很多知识才对。但是实际上，每一轮AI给出的反馈，都在等待下一轮AI给出反馈的间隙中被无所事事地消耗掉了，或者被其他项目的知识冲淡了， 相比古法编程那种在心流里不断吸纳知识的感觉，AI Coding无法在工作的同时积累经验。

不信？现在回想一下你刚才用AI做了什么，AI是如何实现的。我敢打赌你对AI写出的代码的理解程度绝对比不上自己写的代码。

真能用在工作项目上吗？

事实上我们之所以能够在Coding的过程中对项目建立一个系统的理解，依赖的不是结果（也就是我们在AI Coding的过程中向着AI发号施令的结果），依赖的恰恰是过程。在对自下而上的每一个逻辑掌握的了如指掌以后，对结果的理解是顺理成章的；理解了一个模块的结果以后，才能进一步系统性地理解更上层的逻辑。整个过程像是建造金字塔，只有地基稳固才能保证上层稳定。

有了AI以后，我们关注的点从底层的逻辑，变成了上层的现象。这恰恰成为了普通程序员和高级程序员之间门槛的体现：有了AI以后，大家都可以做出看起来差不多的东西，都可以在项目的某个模块交付一个看起来能运行的成果。但是经过设计的过程落地的成果，和不分青红皂白让AI做出的成果，在可用性上必然存在差距。我始终认为在复杂系统中，可用性是会随着模块之间的叠加而显著劣化的。体现在日常工作中，这种可用性的劣化往往表现在工期的”分期支付“：原本两天的工作量，现在分了五期支付，每一期0.5天（其中还包含0.5天的利息）。看似0.5天完成，其实只是支付了全部工作量中的一期。

思考

所以，想要更好地使用AI进行编码工作，还是要回到对工作本身的理解上去。为了保护大脑前额叶，为了不陷入分期支付工时带来的沉重债务，必须要把重点从”AI Coding”转移到”Why Coding“和”How Coding“上。前者是为了衡量工作的价值，后者是为了更好地实现价值。每一个项目的运行都有它独一无二的背景，并不存在放之四海而皆准的解决方案，思考如何在独一无二的背景下体现价值是现阶段AI无法代替人类实现的工作。至于如何Coding，需要Coder本人具备丰富的经验，或者学习过足够多的优秀范式。尽管从整个项目的角度来讲，不存在完美的解决方案，但是放到项目中具体的问题来看，选择经过验证的可靠的解决方案是必不可少的。