你可能不需要阅读那些代码

眼下关于采用代理式编程的开发者是否需要审查自己写的代码，争论不休。大多数理性清醒的声音都在大声疾呼：是的，你得看看它。但且听我一言——他们真的有必要吗？

如今每一位程序员都曾把大量从未细读、甚至根本不甚了然的代码推上生产环境。操作系统、编程语言、Web框架、数据库、消息队列、缓存、各类库与依赖……这些当中，你真正通读过多少？又有多少能让你对其中各个部件的具体运作机制做出详尽的解释？

我干这行够久了，以至于现在知道的东西里，恐怕有一半早已忘光。连自己亲手写下的代码细节都记不清了，就像当年那个埋头敲键盘的计算机系学生一样。即便是在大型代码库中开发时，我也曾遇到过某段代码，心想：“这也太蠢了吧，谁写的？”结果一用git blame查出来，竟然是自己——那条愚蠢的语句果真是我亲手塞进代码库的。更绝的是，它居然还通过了代码评审。

我觉得，多数项目，尤其是企业级应用，至今仍在沿用一年前的老一套人工代码评审。我们InfluxDB也不例外。而那些企业（包括我们）曾经放出去的每一个Bug，当初也都顺利通过了人工评审。那么，人工代码评审的效果或许并没有我们想象的那么好？

当然，支持它的另一个理由是知识共享。没错，知识传播很重要，但实现这一点并不非得靠逐行审阅代码。一份简明文档，或者一张配有图示的演示文稿，就能让另一位程序员了解系统的工作原理，而无需逐行对照源码。

不过，“烂摊子危机”确实存在。我本人就亲历过。一旦让代理肆意驰骋，又迟迟不去过问，很快就会发现，自己造出了一座“代码烂尾楼”。可这样的问题，往往连看代码都不必——只要代理对系统运行机制和当前状况的解释变得荒诞离谱、完全脱离实际，你就该警觉了。这时再去看代码，真相自然水落石出。

关键在于，你不必对每一行代码、每一个子系统都了如指掌，但必须清楚自己交付的系统与应用是如何设计的，它们由哪些部分拼装而成，有哪些依赖关系与活动组件；并且，根据每项依赖的重要性及其成熟度与熟悉程度，决定你需要掌握其具体实现到何种细粒度。而这一切，并不需要逐行啃代码。

当然，也有人乐于与每一行代码“亲密接触”，并以此为傲，打造出所谓“代码宫殿”。但这些终究是主观感受。假如我给你一套能解决问题的可用软件，而且它消耗的CPU周期更少、占用的内存更小、存储开销更低、网络带宽需求也更少，那么，它背后的代码长什么样，真的那么重要吗？

我认为并非如此。真正要紧的是可验证性。过去那些你交付却看不懂的软件系统，之所以被视作安全可靠，无非是因为它们足够成熟、应用广泛，背后还有一群值得信赖的贡献者在持续维护。对于许多内部机制不明的大型软件包，我们大多依靠社会认同与亲身使用来把关。这无可厚非——毕竟，想把所有东西都摸透，根本不可能规模化地做到。

以上这些本不算什么，除非面对一个残酷的现实：强制要求人工逐行代码评审，将严重制约你在2026年8月的交付能力。如今的AI已经足够强大，只要你让Fable或Sol去完成一项功能开发任务，它们不仅能写完代码，还能自审、修复Bug，甚至按端到端的方式进行测试——不是那种随便编出来的低级单元测试，而是真正的黑盒验证。

如果你还不信，也没体验过，不妨试试这样一组实验：以Fable为主管，搭配Opus 5子代理（还得控制每周用量）或GPT‑5.6 Sol xhigh，启动一个项目——比如整套服务器系统或某个应用，交由它们构建。每天给自己留出一小时，连续十天。在这段时间之外，你不得直接干预代理的行为（尽管它可能也会“自主发挥”）。散步时可以构思方案，但你的唯一界面就是那一小时，用来评审代理的工作进展。

最重要的是，你不能看代码。如果是面向用户的API或CLI，作为产品的一部分，当然可以仔细检查；但底层实现一律禁止窥探。你可以与代理交流、提问，仅此而已。当然，你完全可以告诉代理如何组织代码与项目结构。

你的目标是，在离开键盘后，让代理尽可能多地推进工作。在一小时内，你只需评审他们的成果，并为下一步指明方向。理想状态下，你甚至能让它们在无人干预的情况下连续运转数小时。为此，你得把重点放在如何确保软件质量、让代理能够顺畅迭代上。

你会发现，如果只评审架构设计与用户体验，进度会快得多——快得惊人。你会震惊于自己能在短短时间内打造出真正可用的软件。

有人可能会反驳：那又怎样？大家不都搞过些“摆弄风”的玩意儿吗？最后还不是没法交付、无法运维，顶多算个单用户的小玩具罢了。

可事情真非如此不可吗？只要它能正常运行，而且你也验证过了，接下来该怎么办？担心运维？那就让代理加个新特性，做点棘手的事，或者问问程序里的某个环节是怎么工作的。然后翻翻代码，看看它能不能给你讲明白，说的有没有道理。

关键在于，你已经建立起一套工程流程，用于验证、QA、确认，并与客户共同认定所提供的软件确实能胜任其使命。做到了这一点，至于代码是AI写的还是人写的，抑或每行都经过人工精审，其实都没那么重要。

我并不是主张所有代码都可以无视。我只是说，有很大一部分是可以放心略过的，甚至直接忽略。它们不再需要过去那样的细致把关，因为我们有AI帮忙确保细节不出差错。

2026年8月的前沿AI（Fable 5、GPT‑5.6 Sol xhigh）已非2025年12月的水平，它们强得多。就目前而言，它们的代码评审能力大多已胜过人类，而且还将继续提升。

人类的价值体现在那些关乎全局的地方：架构设计、整体系统规划、用户体验，以及系统应如何运转；当然，还有搭建起一套验证一切按预期运行的软件与流程。

眼下，我们大多数人的整个SDLC都被重重速度枷锁捆住。我们远未准备好利用今天的技术潜力，更别提展望2027年的可能性了。原因就在于，我们试图把代理塞进那套沿用了五十年的人工主导的旧SDLC。

其实还有另一条路，但它要求彻底重想SDLC的运作方式。至少，这是我还在沿用两年前那套流程时的思考。如今我在几个新领域浅尝辄止，却发现能做成的事情之多，令人震撼。

我每天清晨醒来，都迫不及待地扑向电脑，想看看那些AI在我熟睡时送来了哪些新“礼物”。这种感觉，简直妙不可言。