珍惜你感受到的痛点：我为什么给自己写了一款 AI Code Review 工具

我曾经开发过一款自己用的 code review 工具，只给自己用。最终的成果让我用得很开心。整个开发过程，都是围着自己的痛点转的。

用了两年 AI 编码，我记住了那种「心里没底」

用 AI 辅助编程大约两年，中间有过体验提升的欣喜，也有翻车的痛苦。

最典型的一种别扭是这样的：AI 生成的代码，开发完成、运行起来都没问题，但我脑子里对它的印象是模糊的，细节并不清楚。等到有人来问我这段逻辑，我心里是没底的。

对于非常严肃、非常重要的系统，我不敢双手大撒把地全交给 AI。我需要真正了解它的逻辑细节。

对我自己熟悉的系统来说，这些都不是问题。但最近，由于大家众所周知的原因，我接手了很多并不熟悉的项目。在这些项目里，我一样可以让 AI 开发出我想要的功能，甚至不需要提前知道它的很多细节——但那种心里没底的感觉，让我很不舒服。

更重要的是「责任」这回事。代码是 AI 生成的，可问责依然由代码提交人来承担。功能是它写的，锅是我背的。

基于这些理由，我决定给自己开发一款 AI code review 工具——一个独立的 Web 应用，用 JS + Python 搭建，配上 AI skill 来驱动审查流程。

边用边长出来的功能

这款工具最好的地方，是它在开发过程中就直接用来验证我正在开发的项目本身。哪里不顺手，就当场补上：

• 发现缺少一个整体的流程图，就让它加上；

• 发现缺少对「爆炸半径」的评估，就让它加上——用图形化的方式标出受影响的文件和调用链，从被改动的代码向上追溯，找到引用起点，比如一个 REST 接口或一个定时任务；

• 我需要能根据流程步骤跳转到对应的 code diff，甚至直接跳进 IDE，就一个一个实现；

• code review 的过程做成一个清单，哪一部分 OK 了，我就打个勾。

经过这样多次迭代，才形成了现在的版本。每一个功能，都是我自己真实卡壳的地方，不是别人拍脑袋提的需求。

珍惜你自己感受到的痛点

我最想对那些对 AI coding 感兴趣的朋友说的是：一定要珍惜自己感受到的痛点，根据自己的痛点去开发自己的工具。这是一件非常珍贵的事。

在此之前，很多开发人员的需求来源是产品经理、是客户。很多人被局限在自己流程当中的一环，并不了解价值的来源与去向。久而久之，对软件开发的热情就渐渐冷淡、麻木了。

而基于自己的痛点去开发，会重新点燃这份热情。因为你知道自己的痛点在哪里，知道哪部分可以忽略、哪部分必须重视。

这样干确实累——需要做很多判断和决策类的工作，比单纯写一份需求明确的代码要累得多。但它很快乐。