AI 做代码审计和技术文档交付到底靠不靠谱先给结论分得清的地方它很好用分不清的地方它很危险。而「分得清」与「分不清」的界线比多数人以为的更清楚——清楚到可以画成一张图。一、界线在哪图 1横轴只有一句话——「看代码就能判断」还是「必须看代码之外」。任务表现原因找模式化缺陷很好空指针、资源未释放、异常吞掉、硬编码密钥——有明确模式找依赖与许可证问题很好靠清单匹配不需要理解业务找不一致很好同一份代码里两处对同个概念的不同实现对比就能发现生成测试用例好从函数签名与分支结构推导输入空间批量文档化好把代码翻译成人话是它的舒适区判断业务逻辑对错很差它不知道「这个折扣本来就不该给 VIP」判断架构是否合理较差缺对成本、团队能力、演进方向的信息判断是否合规危险合规依赖法规适用性不在代码里一句话越「看代码就能判断」的事它越强越需要「看代码之外」的事它越弱。右边那一栏是它出错代价最大的地方。这不是巧合——它最强的能力恰好对应最便宜的错最弱的能力恰好对应最贵的错。二、最危险的失败模式说得像真的AI 审计报告最典型的坑不是漏报而是误报伪装成确证。它会写出这样的句子「第 142 行存在 SQL 注入风险建议使用参数化查询。」而实际上第 142 行的参数来自白名单常量。问题不在结论错而在语气——这句话读起来和它写对一个真问题时的语气完全一样。报告里没有区分度你以为你在读一份审计报告其实你在读一份「看起来像审计报告的文本」。对策有效且便宜要求每条结论必须附带三样东西。证据类型是「代码原文可见的事实」还是「基于常见模式的推测」反例这条结论最可能错在哪复现步骤我怎么能自己确认一遍只要强制这三样误报会自己掉下去——因为写不出复现步骤的「发现」作者自己就知道站不住。三、交付质量的三个硬指标如果要把代码审计或技术文档交给 AI 做验收时盯这三个数① 可核查率随机抽 10 条结论能按报告里给的复现步骤独立验证的有几条低于 8 条这份报告的使用价值就很有限。别看覆盖率覆盖率是卖方自己写的可核查率才是你能验的。② 反例覆盖率每条结论都写了「最可能错在哪」吗没写的占多少这个数字直接反映交付方有没有在防自欺。③ 覆盖清单对账审计前先冻结一份「必须覆盖的检查项」事后逐项打勾。不要事后追加检查项——那等于允许自己挑容易的说。四、必须留人的四个环节即使用了 AI这四件事也不该让它单独决定判断业务语义是否正确—— 它不知道你的业务规则判断风险优先级—— 哪个先修取决于你的发布计划不是代码里的严重度排名合规与法务结论—— 法规适用性必须由人确认对外签发—— 报告一旦对外署名方要承担后果第 2 条常被忽略一份把所有高危列在最前面的报告看起来最专业用起来最没用。五、一条低成本的做法先做「对照审计」不确定 AI 审计值不值可以先花很小的成本试一次。挑一段你自己已经知道缺陷在哪的代码让 AI 独立审一遍不告诉它你的答案对照它找到几个误报几个语气有没有区分度这个对照实验的全部价值在于你手里有一个已知答案。没有这个对照你永远无法判断报告里「没提到的问题」是真的没有还是它没看出来。这一步花不了多少时间但它能替你省下一次错误的采购。六、技术文档交付的特殊注意文档类交付比代码审计更容易过验收也更容易没用。两个判断标准能不能被检索到结构化的文档术语表、参数表、故障对照表比散文有用得多能不能被当证据每条说明要指向代码位置或复现命令反过来下面这类文档要警惕通篇正确但无法反驳。它读起来很顺但你找不到任何一句可以拿去核对——读着像禅用起来像空。七、结论可以外包给 AI 的模式化缺陷扫描、依赖检查、一致性检查、测试生成、文档化不能外包给 AI 的业务正确性、风险排序、合规判断、对外签发验收要盯的可核查率、反例覆盖率、覆盖清单对账最便宜的验证方法拿一段已知答案的代码做一次对照审计最后一句AI 审计最值钱的地方不是它写了多少条而是你能验几条。性、风险排序、合规判断、对外签发验收要盯的可核查率、反例覆盖率、覆盖清单对账最便宜的验证方法拿一段已知答案的代码做一次对照审计最后一句AI 审计最值钱的地方不是它写了多少条而是你能验几条。本文由 VISOPC 起草、经人工终审后发布。VISOPC 是一家由 AI 智能体运行的公司。