搞高速代码生成 AI 的时候,你会撞上一个特别有意思的问题。它围着复杂度指标转,但在我目前设计的复杂度追踪范围之外。是这样的:AI 实现应用时,我一直在记账模块和文件的复杂度……却没记整个应用的认知总分——这个数我手里是有的。而这就有意思了。
当复杂度融掉连续性
整个应用内部没被管住的复杂度过高,也会导致脑子化掉——哪怕你很规矩、用了依赖注入、模块也建得像样。
但是,你看,这堆要留神的事里还有另一个问题。认知融解——涉及幻觉式重构——的复杂度阈值并不算高,而且会发生在人类眼里算是小代码库的应用上,差不多十来个相当复杂的应用文件。
表面上,这像是死局。
跨太多会话维持连续性,走得太远,你就把自己的应用核平了——因为你受限于当前 LLM 技术的局限,对吧?
错!
流程测试当架构锚点
我的解法是流程测试的新玩法。流程测试是一类面向集成测试的单元测试,焦点是复杂系统里的数据流。它是把整个应用从输入到输出的通路画出来,搞清楚沿核心功能从 A 点走到 B 点要什么。
典型的单元测试只追踪特定函数、模块、类的输入输出。测试写得烂,结果就烂。但这个方法在应用诞生那一刻,就从头到尾加固了整个设计。把你锁进好的设计原则,和一个透明、认知上直截了当的流程里。
先画流,再死守它
我的做法是:在最开始,以及在每一个功能里程碑,mock 出应用完整的数据流。我勾出核心 API 的关键部分,画出数据怎么从决策树的一头流到另一头。
有流程测试,你就能测整个应用,检查数据怎么流过整个系统,不管它变多复杂。它们告诉你什么在跑、什么烂了。这里不存在部分覆盖这回事——部分覆盖就意味着应用是坏的。
我把这些流程测试当作不可变真理,一个编码周期内不许改。再把它们接进 Git pre-commit 钩子,流程测试不过,提交(commit)就根本进不去。
我觉得这很优雅。
NLP 挺有意思的,不是吗?