夜雨聆风上周三凌晨两点。我盯着屏幕上看一段代码。
这段代码是 AI 帮我写的。一个数据清洗脚本。看起来没问题。逻辑通顺。注释完整。连变量命名都很规范。
但我跑了一遍测试。发现了一个致命缺陷。
数据清洗的时候。AI 用了一个库。这个库在处理空值的时候不会报错。它会悄悄把空值替换成零。零和空值是两回事。但 AI 不知道。或者说。它知道。但它不在乎。
因为 AI 的目标是生成"看起来正确的代码"。不是"能跑的代码"。
我查了一下这个库的文档。空值替换成零。在某些场景下会导致严重的数据偏差。比如医疗数据。比如金融数据。零是有效值。空值是缺失值。你把缺失值当零处理。统计结果就废了。
问题不在 AI。在用 AI 的人。
我去查了 OpenClaw 工程师的原始报告。比我想的严重得多。
AI 不只是偶尔出错。它在批量制造低质量代码。而且这些代码已经进入了生产环境。GitHub 上至少有 12000 个仓库引入了由 AI 生成的安全隐患的代码。
最可怕的不是 AI 写错了。是写错了之后没人看出来。
因为代码看起来是对的。
拿我检查到的一个真实案例来说。
一个库存管理系统。AI 帮我写了一个库存预警函数。逻辑很简单。当库存低于阈值时触发告警。
代码写得很漂亮。变量命名清晰。注释完整。连异常处理都写了。
但我跑了一个测试。把库存量设为负数。
正常情况下。库存量不应该是负数。但实际业务中。因为退货、损耗、数据录入延迟等原因。负数库存是真实存在的。
AI 写的函数在负数库存时不会触发告警。因为它的逻辑是"如果库存小于阈值且大于等于零"。它把负数过滤掉了。
这意味着。如果某个商品的库存变成负数。系统不会告警。仓库管理员不知道缺货了。采购部门不知道要补货。客户下单后发现没货。
一个小缺陷。引发的连锁反应。
我花了二十分钟修复。加了负数处理逻辑。重新写了告警规则。
我开始检查自己的项目。把 AI 帮我写过的代码全部翻出来。逐行看。
一周。我检查了四十多个脚本。
发现问题。
十七个有缺陷。
十七个。百分之四十二。
这些缺陷不是语法错误。不是拼写错误。是逻辑错误。类型判断缺失。边界条件没处理。异常捕获没写。变量作用域混乱。
如果你不仔细看。根本发现不了。
我总结了三条检查方法。以后 AI 写的任何东西。不管代码、文案、数据分析报告。都过一遍。
第一条：边界值测试。
AI 最喜欢忽略边界值。空值。零。负数。超大数字。特殊字符。
你让 AI 写一个计算年龄的函数。它会用当前年份减去出生年份。看起来很对。但如果出生年份是未来呢。如果当前日期还没到生日呢。
AI 不管这些。它生成的是"平均情况"的代码。不是"所有情况"的代码。
检查方法很简单。跑五个边界值测试。空输入。零输入。超大输入。特殊字符。负数。五个全通过。才算过。
第二条：溯源每一个依赖。
AI 引用的库。它不会去查这个库有没有已知漏洞。不会去查这个库是否已经停止维护。不会去查这个库的许可证是否兼容你的项目。
它只是用。
OpenClaw 报告里提到的那个空值处理库。就是这个问题。库本身没问题。但在特定场景下行为不可预期。AI 不知道这个场景。它只看了库的基本文档。
检查方法：AI 每引入一个新依赖。你去查三件事。这个库上次更新是什么时候。有没有未修复的 CVE 漏洞。许可证是否允许商用。
三分钟的事。能避开百分之八十的坑。
第三条：自己跑一遍核心逻辑。
不要只看 AI 的输出。把核心逻辑提取出来。自己手动跑一遍。
不是全部。是核心部分。
AI 写了一个数据清洗脚本。你看它的核心逻辑。提取。输入几个测试数据。手动算一遍。再对比 AI 的输出。
如果不一致。说明核心逻辑有问题。
这个方法慢。但最有效。
具体来说。你可以这样做。
拿一张纸。一支笔。把 AI 写的核心逻辑拆成步骤。每一步写下来。然后手动输入数据。一步步推演。
比如 AI 写了一个用户注册验证函数。核心逻辑是检查邮箱格式、密码长度、用户名是否重复。
你手动推演。输入一个带特殊字符的邮箱。推演 AI 的逻辑能不能处理。输入一个六个字符的密码。看能不能拦截。输入一个已经存在的用户名。看返回信息是否正确。
推演完。和 AI 的实际输出对比。
不一致。说明有问题。
我检查的十七个缺陷里。十四个是用这个方法找到的。剩下三个是用边界值测试和依赖溯源找到的。
很多人问我。既然 AI 这么不靠谱。为什么还用。
我的回答是。AI 不是不靠谱。是你要知道它哪里不靠谱。
AI 擅长什么。格式。结构。重复性工作。它能在三秒内生成一个完整的函数框架。能在一分钟内写出你花半小时才能写的注释。能把你的想法快速转化为可执行代码。
AI 不擅长什么。逻辑判断。边界处理。安全审查。它不知道你的业务场景。不知道你的数据特点。不知道你的用户会怎么折腾你的产品。
这些需要人来做。
我的工作流程是这样。
第一步。让 AI 生成框架。函数签名。基本逻辑。注释。三十秒搞定。
第二步。我自己写核心逻辑。边界处理。异常捕获。安全校验。这是最费时间的部分。占整个开发的百分之七十。
第三步。让 AI 做代码审查。让它找潜在问题。它确实能发现一些我没注意到的细节。但我不完全相信它。我自己再跑一遍测试。
这个流程效率比纯手写高三倍。但质量不会下降。因为核心逻辑是人写的。不是 AI 写的。
有人可能会说。这太麻烦了。AI 就是为了省事的。你这样用。不如自己写。
我理解这种想法。但省事和质量不能同时选。
你要么省时间但承担风险。要么花时间但保证质量。
没有第三条路。
OpenClaw 工程师的报告发布后。社区里有一种声音。说应该限制 AI 写代码。甚至禁止在生产环境使用 AI 生成的代码。
我不这么认为。
问题不在 AI。在用 AI 的人。
你让一个不懂代码的人用 AI 写代码。然后直接部署。这是你的问题。不是 AI 的问题。
你让 AI 帮你写代码。但自己检查每一行。自己跑每一个测试。自己审查每一个依赖。这就不是问题。
工具没有好坏。只有会不会用。
我把那四十多个脚本全部重写了一遍。花了三天。
重写完之后。十七个缺陷全部修复。测试全部通过。
我把检查清单整理成了一个简单的表格。存在 Notion 里。每次用 AI 写代码之前看一眼。
清单不长。五条。
一、边界值测试通过没有。
二、依赖库有没有未修复漏洞。
三、核心逻辑手动跑过没有。
四、异常处理有没有遗漏。
五、安全审查有没有做。
五条全过。才提交。
这五条看起来很简单。但很少有人真的去做。
因为太慢了。AI 一秒就能生成。你要花十分钟检查。
但十分钟换一个缺陷。值了。
上周修那十七个缺陷的时候。我算了一笔账。如果这些缺陷到了生产环境。修复成本至少是现在的十倍。如果是金融项目。可能是百倍。
十分钟。换十倍的修复成本。这笔账不用算。
AI 在变强。这个趋势不会变。
OpenClaw 的报告只是一个开始。以后会有更多类似的报告。AI 生成的内容质量参差不齐会成为常态。
能做的只有一件事。
学会检查。
不是学会写代码。是学会检查 AI 写的代码。
不是学会写文章。是学会检查 AI 写的文章。
不是学会做分析。是学会检查 AI 做的分析。
检查能力会越来越值钱。因为生成能力会越来越便宜。
我写这篇文章不是为了说 AI 不好。
AI 很好。我用它。每天都在用。
但我不信任它。
信任是盲目的。检查是清醒的。
清醒比盲目好。
