AI 写的代码没人看得懂，接手前先做 3 件事

2026-09-17 AI编程,代码阅读,项目接手

同事把一段 AI 生成的代码转给我，说「能跑，但你看着办」。我打开文件，函数名是 handleData，里面三百行没有一句注释。AI 写的代码没人看得懂这件事，我遇到过不止一次，现在有一套固定动作。

AI 写的代码没人看得懂怎么办：先跑通，再画图，最后才读代码

顺序反了会很痛苦。

很多人一上来就逐行读，读到一半失去耐心，然后开始瞎改。

我的做法是先让代码在本地跑起来，有了可观测的行为，再回头看它做了什么。

前提：这套流程什么时候不适用

如果代码只有几十行、你一眼能扫完，直接读就行，不用这么麻烦。

如果这段代码已经稳定运行很久、没有 bug、也没有改动需求，那就别动它——看得懂不是目的，不出事才是。

真正需要走这套流程的，是你要改它、或者你要对它负责的情况。

第一步：把可观测的东西建起来

在读懂之前，先让它说话。

具体动作：找到入口函数，打上日志，用真实一点的输入跑一遍，把关键分支的输入输出记下来。

跑一次比读十遍有用。你会立刻知道哪些分支根本没被走到。

我接手过一个后台接口，跑起来才发现有一半的错误分支从来没被触发过——那些代码看着像功能，其实是摆设。

第二步：只画主干，别画细节

用纸或文档画一张调用关系图，只画到「谁调用谁」这一层。

不要画类图，不要标参数类型，那会让你陷进去。

目标很简单：知道数据从哪进来、经过谁、最后去哪。

画不出来，说明你没跑明白，回到第一步。

第三步：找边界，不找实现

读代码时优先看三处：输入校验、错误处理、数据写入。

这三处决定了这段代码在异常情况下会干什么。

具体动作：对每个入口问一句「如果传空值会怎样」「如果数据库返回两条会怎样」，然后在代码里找到答案。

找不到答案的地方，就是你改之前必须补测试的地方。

卡住的三个点

卡点一：函数太长。 三百行的函数不用通读。找到它的输入输出，把它当黑盒用。

卡点二：命名没有意义。 别急着改名，改名的 diff 会淹没你真正的改动。先在笔记里给自己翻译一遍。

卡点三：看不懂就想重写。 重写是最后选项。AI 写的代码里，往往藏着一些你没注意到的分支处理，重写等于把这些坑再踩一遍。

一个提醒

看不懂这件事本身不是问题，看不懂还不承认才是问题。

我现在的规矩是：任何一段我读不懂的代码，不进主干、不上生产。

常见问题

Q：AI 写的代码没人看得懂怎么办？

A：先跑起来建立可观测的行为，再画一张只到「谁调用谁」的主干图，最后重点看输入校验、错误处理和数据写入这三处。

Q：要不要给 AI 写的代码补注释？

A：等你看懂之后再补。看不懂的时候补注释，很容易把猜测写成事实，后面接手的人会被误导。

Q：看不懂的 AI 代码可以重写吗？

A：先别重写。AI 生成的代码常带着你没注意到的分支处理，重写会把这些边界条件再踩一遍，成本通常高于读懂的。