AI代码看似正确？先核对测试执行与断言

AI 生成的代码，最难处理的往往是看起来已经修好的那一版：演示能跑、解释合理，问题却留到了上线以后。作者把日常使用 AI 编程工具时反复遇到的失误归成七类，并为每类配了一个约 30 秒的检查动作。

这份清单的价值，是把「AI 说完成了」拆成几个能核对的问题：到底跑了什么、测试有没有被放宽、依赖是否存在、失败有没有被藏起来。对经常让 AI 修改前端和 Node 项目的开发者，这比再加一句「请认真检查」更容易执行。

测试变绿，为什么还不能算完成

第一类问题最直接：AI 改了代码，却没有执行验证。有时它确实运行了测试命令，但没有发现任何测试，进程仍然正常退出。

因此，作者建议追问实际执行的命令和退出码，再看输出里究竟运行了多少测试。退出成功只能证明命令结束了，不能证明目标行为通过了验证。「0 个测试通过」也不能当成修复证据。

第二类更隐蔽：测试通过，是因为测试本身被改了。例如增加 it.skip(、xit( 或 @pytest.mark.skip，把 expect(total).toBe(90) 放宽成 expect(total).toBeDefined()，或者更新 snapshot，让错误输出成为新的预期。

接收修改前，可以执行 git diff -- '*test*' '*spec*'，专门查看测试文件。关键不是禁止修改测试，而是确认修改理由：需求变了，预期当然可能需要调整；如果只是为了消除失败，绿灯就失去了意义。

作者最后把入口进一步压缩成一条命令，用来先看修改范围：

git diff --stat

要注意输出中的文件名和改动量：有没有碰到没提过的文件，测试是否变化，修改规模是否达到任务预期的 10×。它适合发现异常，再决定深入检查哪些 diff。

示例能跑通，离项目可用还有多远

第三类问题是不存在的 API 或依赖。作者举的例子是 import { parseSafe } from "zod/utils"：写法很像真的，但对应函数并不存在。包名也可能被编造。原文还提醒，有攻击者会注册这些虚构名称，让一次依赖误装变成安全风险。

检查动作是打开真实文档或 npm 页面。新发布、下载量很少的包需要继续核实，但这些特征本身不能证明它有问题。

第四类问题是只覆盖正常输入。示例能跑，遇到空列表、null、时区、0、超长字符串或连续双击就失败。作者建议直接问 AI：「哪 3 种输入会让它出错？」然后实际运行这 3 种情况。这里真正产生证据的是运行结果，AI 给出的边界列表只是检查线索。

第六类则是版本错位：在使用 app router 的 Next.js 项目里生成 pages router 写法，调用旧 React Router API，或者写入已经移除的配置项。

原文没有给出具体框架版本号，因此不能从中推出哪些 API 适用于你的项目。可执行的动作是核对 package.json 或锁文件中的版本，再检查 import 和配置，并把版本信息放进下一轮提示。

不报错和能登录，都可能掩盖问题

第五类问题是吞掉错误。作者用下面的代码说明，接口失败如何被包装成正常结果：

try {
  return await getOrders(userId);
} catch {
  return [];   // 用户只会看到「没有订单」
}

要盯住 return []：它把「查询失败」变成了「查询成功，但没有订单」。用户看到空状态，开发者又没有日志，故障就可能直到客服工单出现才暴露。

作者建议搜索 diff 中的 catch、|| []、?? null 和 except: pass，逐处确认是否记录、重新抛出，或者有明确的降级理由。这些写法可以合理存在，审查重点是错误有没有被误当成有效数据。

第七类是安全功能看起来能用。登录成功，并不能证明 JWT 已经验证；能解码也不等于验证签名。类似问题还包括硬编码 secret，以及 API route 没有检查调用者身份或权限。

作者给出的追问很具体：「谁有权调用这个路由，检查写在哪里？」再搜索 diff 中疑似密钥的字符串。对新增接口，这能帮助把审查从「请求成功了吗」推进到「这个请求应该被允许吗」。

我的判断

我认同这套清单的方向：把注意力从 AI 的解释转向可查看的证据。不过，约 30 秒更适合作为初筛预算，复杂权限逻辑和依赖核验未必能在这个时间内完成。

原文引用 Stack Overflow 2025 年调查，称 66% 的开发者抱怨 AI 答案「差一点才对」；又称 2026 年调查中接近一半的人只在容易核验时信任输出。所给材料没有调查链接和统计口径，这些应当视为作者引述，不能直接当作已核实结论。

作者每天使用 AI 编程工具、反复遇到这些问题，属于个人经验。他没有提供对照实验，也没有数据支持「看一眼 diff 就能抓住一半问题」。相较 CI 和人工代码审查，这份清单的优势是启动成本低，覆盖深度仍然有限。

文末推荐的 proof-of-done 和 security-audit 也是作者自己的工具。原文说明了用途和安装方式，没有展示效果评测；自动化检查是否可靠，还要看它实际检查了什么。

能拿来做什么

• 让 AI 修复前端或 Node 问题后，要求它提供实际执行的命令、退出码和测试数量，再核对输出与目标用例是否对应。
• 接收修改前先运行 git diff --stat，再用 git diff -- '*test*' '*spec*' 检查测试变化，重点看跳过测试、放宽断言和 snapshot 更新的理由。
• 为当前修改挑 3 个相关边界输入并实际运行，例如列表的空数据、数值为 0 的输入，或按钮连续双击，确认结果符合预期。
• 新增 API route 时明确调用权限及检查位置；遇到异常兜底时，确认用户能否区分「没有数据」和「请求失败」。