一个人要不要代码审查，我的做法改过

2026-07-31 代码审查,单人开发,AI协作,工程习惯

我给自己配了 5 个 AI 员工做一人公司，其中小码负责写代码。那之后我最长一段时间的心安来源是：AI 审 AI，看上去像有人把关，直到我开始琢磨代码审查一个人怎么做。

后来我把这套做法整个换掉了。结论是：要审，但不能审成流程，得审成习惯。

一、我最初的做法：把审查做成了一道闸

最开始我给自己定的规矩是：写完的功能不立刻合并，先放一天，第二天再看一遍，看完才合并。

这个做法听着很对，执行起来很快就变形了。因为只有我一个人，第二天我大概率在写新东西，那段旧代码我根本没心情重读，最后变成走过场——看一眼，点合并。

没有第二个人在场的时候，所有流程都会退化成仪式。代码审查一个人怎么做，第一个要解决的就是这个问题。

更具体地说，问题出在反馈周期上：放一天再看的收益，抵不过我当天就想推进新功能的冲动。

二、改法一：把「审」提前到写之前

第一次调整是把审查的时点前移。

写之前我先做一件事：把这次要改的文件列出来，然后问自己一句——这次改动会让哪个文件变复杂？答不上来的，说明我还没想清楚。

这个问题还顺带拦住了另一类情况：同一件事我已经在别处写过一遍了，只是忘了。

这个动作花的时间极短，但它拦下了一批「本来就不该写」的改动。

三、改法二：审的不是代码，是差异

第二次调整是把审查对象从「整个文件」换成「这次改了什么」。

我发现自己重读整个文件时，注意力会跑到已经写过的地方，看完很累但抓不到新问题。看差异就聚焦得多：这次新增的分支，有没有对应的失败路径？这次改的字段，有没有别的地方还在用旧名字？

判断标准从「这段代码好不好」变成了「这次改动完不完整」，这对我一个人来说好操作得多。

还有一层好处：差异是有限的，文件是无限的。看差异这件事，永远有看完的时候。

四、改法三：让 AI 当审的人，我当定的人

第三次调整是分工。

现在我让 AI 员工先看一遍差异，让它挑出「空指针、边界、并发、错误被吞掉」这一类确定性问题。这类问题它比我快，也不会因为熟悉而看不见。

然后由我判断的是另一类：这个设计要不要这么走、这个字段要不要现在加。这部分没法外包，因为它依赖我对业务的判断。

AI 能替我看代码，替不了我做取舍。这个分工比「AI 审 AI」踏实得多。

有一点要提醒：AI 挑出来的问题不能全盘照改，它不知道哪些是当时的取舍。判断仍在我这边。

五、我的审查清单现在只有五条

清单太长就不会被执行，所以我把检查项压到五条：

新增的逻辑有没有对应的失败分支
有没有错误被吞掉
有没有把不该写死的东西写死
命名说的是不是它实际做的事
这次改动有没有让某个文件变得更长、更难懂

五条扫完，通常两分钟。能坚持的审查标准，一定是很短的那种。

六、代码审查一个人怎么做到底有没有用

有用，但它解决的不是「别人会不会发现我的错」，而是「我会不会漏掉自己的漏」。

这两个问题不一样。前者需要第二双眼睛，后者只需要一个固定下来的检查动作。

我用 AI 员工补上了前者的很大一部分，剩下的部分靠这五条清单兜住。一个人做代码审查，目标不是审得全，是别让同一个错误犯第二次。这就是我对代码审查一个人怎么做这个问题的全部答案。

常见问题

Q：一个人做代码审查有必要吗？

A：有必要，但不要做成合并前的流程闸门。更有效的做法是看差异、用短清单、把机械问题交给工具，把设计判断留给自己。

Q：AI 写的代码还需要人审吗？

A：需要。AI 生成的代码通常能跑，但边界情况、错误处理、和项目既有约定的契合度，仍然要由人来判断。

Q：自审容易走过场怎么办？

A：把审查对象缩小到「这次改了什么」，并固定一份五条以内的清单。范围小、标准短，才不容易变成看一眼就点合并。