基于过程的质量控制

我现在越来越认为， Agent take 开发需要依赖于一套足够的质量控制过程来保证。这就像制造业中的 QA 一样，对关键部位进行抽样，或者是对整个流程控制进行管控，来观察自己的产出管线是否有保证一个比较良好的质量。一旦这样的生产管线建立成功，质量就是可以成为能够复刻的产品。

因为随着 AI 代码的愈发膨胀，人类生核代码会变得越来越不可能。你像我写个东西，整体下来设计加上代码产出，一共也就用了 28 个小时，写了快 1 万行。其质量出来还几乎都是生产级的设计。那三个工作日耶，这个放平常，恐怕没个半个月、一个月下不来。但是现在就可以压缩到接近一周之内解决。这些代码，就算你给我一周的时间，让我每天去 review，恐怕都不一定能 review 的完。如果按照 500 行 90 分钟那样的情况来看的话，哪怕是核心代码，恐怕都得拉出个两三天去 review。因此， Agent take 开发时代， Review 会变得越来越不重要。我不是说它可以没有，而是会变得越来越不重要，因为大部分代码你都没有精力去 Review。QA 质量控制过程会变得越来越重要。

所以说我现在虽然也微操，但这个微操的层级颗粒度不再放在代码层面，而是放在了架构和边界的层面。尤其是边界，我认为边界是非常重要的。边界本身就像组块一样，也符合学习科学中对于人类工作记忆的研究。我们将大的东西，啊，应该说我们将小的细碎的东西，凝抽象成大的东西，将那些零散的东西抽象成组块。只有这样，我们的工作记忆才是可以承受的。因此，对于大量复杂的细碎的东西，最好的方法就是将其视作组块。那么，良好的代码开发，它的组块应该是什么呢？在我看来就是边界。不同的代码边界构成了一个小的模块，不同的小的模块构成了一个大的模块，不同的大个模块构成了整个架构。这就是一个又一个边界所组成的组块。

而在最小边界之下的细碎代码，那些完全可以交给 QA 流程来管控，只要边界测试整体上是通的。然后再加上仍然是过程哦，注意，上生产的过程也是一种过程，不是全量上，而是逐步的、分模块的、一点点的往上上，同样可以保证，哪怕出了问题，也可以将损失控制在可行范围内。 还有一个方面则是清晰的设计。以前我会认为微服务可能有点太高成本，但现在来看，微服务的优势反倒体现出来了，那就是各个模块之间的彼此分离。我自己在开发的时候也注意到了。分离，尤其是对契约负责的架构设计，可以让 Agent take 并行去进行开发。每个部分只要约定好接口跟契约，就可以直接开发自己的了，不会被阻塞。这是一个很大的优势。

另一方面则是将 AI 的问题严格控制在契约的边界范围内，就保证哪怕单个 AI 出了问题，它的问题也不会扩散到外部。而只会在一个模块中发生，微服务也是一样啊，哪怕这个仓库真的挂了，也只是一个地方挂，而不会扩散到全局。因此 AI 时代对于那些高度去耦合的代码要求量一定会增长。

这些在过去看来可能有些过度设计的存在，在今天变成了质量保证的一个硬性环节。就比如说微服务，我们以前会说，哎呀，这开发成本啊、维护成本啊，都很高。但现在关键点在什么？代码都能交给 AI 去写了，架构才是最重要的。你说多几个仓库确实写起来有点麻烦，但接口这种东西你交给 AI 去写不就行了吗？以前得手写，那确实超级麻烦，但现在不会这样了。因此当前时代体现出来结果就是，能够保证质量的架构才是好的架构，尤其是能够保证 AI 开发之下质量的架构才是好的架构。当然我这里是从质量角度上来讲的，具体到各个情况下肯定有自身的考量。但是在当前的时代，没有哪个组织能够眼睁睁的看着 AI 的高效率不用。比如说把一一个月的工作压缩到一周，这对他来讲是巨大的诱惑，或者说甚至形成了一种反向淘汰的选择压，没有积极使用这套生产形式的企业就会被淘汰，因为它的开发周期时间太长，甚至质量也不见得比 AI 好到哪里去。

总之就是过程会越来越重要，而一个良好的过程设计尽管需要根据情况来设计，但一旦设计好，后续将长期有效，会让整个产出环境都受益。