高可靠场景下警惕AI生成代码的陷阱，代码设计范式skills来解决。

目前AI生成代码越来越破圈，最近AI编码科技圈出了一个又一个的爆款，claude code、openclaw、claude cowork。。。层出不穷，应接不暇。给开发人员众多选择的同时，也越来越多的让程序员担心自己是不是面临被AI颠覆的风险越来越近了。
但是从目前阶段应用效果看，以大模型现有能力，复杂场景下的“严肃代码”还是需要人机协同的。
我对软件设计的理解来看，“reasonable”是第一性原理。
对于关键系统的关键模块，特别是高可靠性场景下，代码还是需要人来审核和把关，这取决于大模型生成代码的可理解性和人对系统的理解程度，人能看懂的代码才能确认其可靠性，才能最终合入系统。
看不懂就不能把控，不能把控就不能识别波及影响和潜在故障。
我们线上最近有个故障，很能代表这一类问题。
系统中需要一个单调时钟，python3中有直接对应的系统调用，time.monotonic()，但是python2中没有类似功能，开发人员一看，这还不简单吗？让AI生成一个，于是prompt一亮像，一分钟不到一个函数闪亮登场：

由于get_monotonic_time函数每30s会被调用一次，属于系统高可靠性场景下的高频应用，出于谨慎考虑，开发人员对该功能进行了详细的功能验证，不出所料，功能全部正常，这段代码自然被纳入账下，合入代码库。大家一起拍手感叹，AI就是强，我们必须给大模型点一个大大的赞。至于函数内蓝框里定义的内部类TimeSpec，大家纷纷觉得它仅为get_monotonic_time服务，定义在该函数中正是满足了软件设计的LoW（最小知识原则），如果一个代码元素仅在一个函数内使用，封装最彻底就是封装到该函数中，外部不可见，防止被非法访问。AI太牛了，不仅考虑了代码功能实现，并且正确实现了，还充分考虑了代码clean code，不仅又对AI大大点了一轮赞。殊不知这段代码埋下了一个大坑。读这篇文章的都是编程高手，给大家一分钟，看出来代码的问题所在了吗？

代码上线后，几个现场都出现了系统服务卡顿、响应延迟，但是cpu没有冲高的现象，初步怀疑是内存泄露导致，现场用服同学查看系统状态，发现该服务占用内存严重超标不止2G（门限1G）。经过定位分析，问题出现就在classTimeSpec(ctypes.Structure)，因为ctypes.Structure有特殊性：

与C语言结构体直接映射，涉及复杂内存布局

ctypes内部会缓存元数据和类型信息

这些信息通过弱引用被追踪，无法被GC正常回收

以上特点会造成随着classTimeSpec频繁调用，ctypes在内存中被反复创建，且不会被及时销毁回收，造成这种特殊形式的内存泄露。定位到原因，就非常容易修改了。classTimeSpec定义在函数外就可以了。这个故障修改难度不大，但是给现场造成的影响却非常大。所以我们认为，大模型生成的代码，普通场景的代码另当别论，但是高可靠场景的下代码，务必要保持可理解性，并且开发人员能够要能够轻量级读懂，只有读得懂的代码才能谈得上控制，只有做到完全控制这些代码，才能最终放心在高可靠性场景下使用这些代码。见上图，在高可靠性要求较高的“严肃软件”中，AI生成的读不懂但是测试对的代码其实最危险。大家知道，软件中的bug总是抓不完的，但是如果能读不懂代码，在现场高可靠性场景中，如果bug出现，短期内快速定位并修复bug非常关键。但是如果读不懂代码，短期修复bug就很难，因为很难通过代码的意图联系到对应的bug上，特别是bug的波及影响就更加难以猜测到。况且，如果不理解的代码被新增代码和bug层层包裹起来，那定位起来就更难了。大家可以想见在高可靠场景中bug不能被及时定位，而被客户反复责难是多被动的一件事啊，那种超高压力体验过的都印象深刻。那有什么方法可以解决这个问题呢？我们推荐在AI编程中使用代码范式的实践，即在高并发领域内，针对某种业务意图，只能使用推荐的代码范式生成代码。代码设计范式通过claude code skill的形态存在，根据业务场景匹配对应的代码范式，达到功能实现的稳定可靠、没有隐藏代码安全隐患等。比如代码元素的声明周期管控，在高频调用的函数中，就不允许有内部类、函数或者隐藏的长生命周期的状态创建等，上述例子中就是函数内的函数定义导致。全局变量是否只读、是否共享、是否可写都有不同的实现范式，权限范围既不能越界又不能不足。对于服务进程，可能会挂掉操作尽量在线程中操作，挂掉后主线程回收资源即可。再比如，变量相互依赖时一个方向必须是weak（前导声明等）的，防止强循环依赖等。我们做了一系列的rust代码设计范式skill，把rust语法特性和惯用法中特有的方式：所有权资源管理可变性零成本抽象类型驱动错误处理并发声明周期管理。。。 还包括已知严重故障的反模式都做成了设计范式skill，确保大模型生成的代码严格满足设计规范（包括编码规范和设计规范、最佳实践等），对AI生成代码设计质量的前端防护提供重要的抓手。另外，哪种设计范式该出现在哪种业务场景出现通过skill hook实现了挂接，从而可以实现精准匹配。更好的实现了高可靠性场景下，AI生成代码中潜在严重治理问题的预防。另外这些skill也可以用在后端代码review中。这样既可以用来对新增代码增加内生治理标注，又可以对存量代码进行补充检查，一举多得。以往放飞使用AI生成高可靠性场景代码时，尽快AI可以完成最高80%多的代码，但是其中AI引入的代码安全隐患带来的损失可能不止80%的工作量投入，必须要对AI生成代码进行及时有效的约束，才能预防这种工作量大幅后移的状况。其他编程语言也可以做类似处理，大家有兴趣可以联系我交流。这些具体细致工作代码范式看起来不够高大上，就像现在市面上大部分人都在说自己练的是“九阳神功”“九阴真经”“葵花宝典”，我觉得自己练的就是“军体拳”一样，但是真上战场，实打实的杀敌自保，不还得是一拳一脚、一招一式吗？综上，在高可靠性软件中，通过代码设计范式为AI圈画了一道道的电子围栏，使得AI在围栏内最大限度发挥大模型的创造力；同时又通过电子围栏有最大限度限制AI产生代码安全隐患，从而为AI在软件开发提效上真正进行保驾护航，实现开发效率的大幅提升。