1. 引言

这两年，AI 写代码的能力突飞猛进，我也从最初的新鲜好奇，变成了重度依赖。GitHub Copilot、ChatGPT、Claude…… 各种工具轮番上阵，提效确实明显。但最近我发现自己陷入了一种奇怪的状态：代码写得越来越快，却越来越"看不进去"了。

这里的"看不进去"，不是指看不懂，而是指一种心理上的抗拒——不想逐行读代码、不想深究实现细节、甚至看到大段代码就本能地想跳过。这篇文章想聊聊我自己的这段心路历程，以及我踩过的坑和正在尝试的解法。

2. 从"写代码"到"审代码"的角色转变

以前写代码，是一个从无到有的过程。需求拆解、接口设计、逻辑实现、边界处理，每一步都需要自己动手，代码的每一行都带着自己的思考痕迹。

现在有了 AI 助手，我的工作流变成了：

• 描述需求，让 AI 生成初版代码；
• 简单跑一下测试，能过就提交；
• 出问题了，把报错丢给 AI，让它修。

不知不觉间，我从"写代码的人"变成了"审代码的人"。而审代码这件事，恰恰是最需要耐心和专注力的。当 AI 生成的代码越来越长、越来越复杂，我却越来越不愿意逐行去读它。

3. 为什么我会"看不进去"

回顾这段时间，我总结出几个原因，可能也是很多人的共性：

3.1 代码量暴增，阅读负担加重

AI 生成代码的速度快，但往往也会带来"过度设计"或"冗余实现"。以前我自己写一个功能可能只要 50 行，AI 可能给你生成 150 行，还带上了各种防御性判断和注释。代码量上去了，阅读负担自然就重了。

3.2 缺乏"亲手写"的掌控感

自己写的代码，每一行都知道为什么存在。AI 生成的代码，尤其是经过多次迭代修改之后，我常常会有一种"这代码是怎么变成这样的"的恍惚感。缺乏掌控感，就会下意识地回避去读它。

3.3 即时反馈的诱惑

AI 工具给到的反馈太快了。写完需求，几秒钟代码就出来了；报错了，粘贴进去，答案马上就有。这种即时满足感，会让人越来越没有耐心去慢慢读代码、慢慢思考。

4. 看不进去，会带来什么问题

一开始我觉得这只是个小毛病，但时间久了，问题开始显现：

• 代码质量失控：不读代码，就发现不了 AI 生成的潜在 bug 和坏味道；
• 技术成长停滞：不读代码，就学不到新的写法、新的思路，长期依赖 AI 会让自己的技术判断力退化；
• 线上事故风险：不读代码就上线，等于把风险直接交给运气。

有一次，AI 生成了一段看似正确的代码，我直接合入了主干。结果在特定边界条件下触发了空指针异常，线上告警响了一整夜。那次之后我才意识到，"看不进去"不是一个小问题，而是一个必须正视的隐患。

5. 我尝试的解法

既然意识到了问题，就得想办法解决。以下是我正在尝试的一些方法，分享出来供参考。

5.1 强制"代码走读"环节

现在我会给自己定一条规矩：AI 生成的代码，必须逐行读一遍才能提交。哪怕只是走马观花，也要把每个函数、每个分支都过一遍。读的过程中发现问题，就顺手改掉；读不懂的地方，就追问 AI 让它解释。

5.2 让 AI 当"讲解员"而不是"代写员"

与其让 AI 直接生成一大段代码，不如让它先给出思路和关键代码片段，再由我自己补全。或者让 AI 用自然语言解释它生成的代码逻辑，我再对照着读。这样既能保持思考，又能借助 AI 提效。

5.3 缩小 AI 的"代写范围"

对于核心业务逻辑、复杂算法、关键接口，我尽量自己动手写，让 AI 只负责那些重复性、模板化的部分。这样既能保证核心代码的质量，也能维持自己的手感。

5.4 定期"手写"练习

我给自己定了一个小目标：每周至少手写一个完整的小功能，不借助 AI 补全。这就像练字一样，保持手感，防止手生。

6. 写在最后

AI 写代码是大势所趋，我不打算逆着潮流走。但我也越来越清楚：工具可以替代"写"的动作，却替代不了"读"和"想"的能力。

"看不进去"不是矫情，而是一个信号——提醒我该重新找回对代码的掌控感了。如果你也有类似的感受，不妨也停下来想一想：是代码真的不需要看了，还是我们正在慢慢丢掉阅读代码的能力？

希望这篇文章能给你一点共鸣和启发。欢迎在评论区聊聊你的看法。