AI 写完代码后怎么检查？从改动范围到失败用例

先把“做好了”换成可检查的行为

假设你让 AI 给一个名单加搜索：忽略英文大小写，忽略查询词首尾空格，清空搜索时显示全部，没有匹配时显示空结果。这几个条件最好在改代码之前写下。否则看到页面能输入、能筛选，很容易就结束检查。

这里的要求是一个刻意缩小的练习：名单是字符串数组，查询词也是字符串，不处理拼音、多语言排序或模糊匹配。真实需求若包含这些行为，应另外说明，而不是把一段简单示例直接当成完整搜索方案。

GitHub 对 Copilot Chat 的官方说明也提醒，生成的代码可能看起来有效，却没有正确表达开发者意图，因此仍需审阅和测试。本文不比较哪款工具更可靠，而是给你一套能亲自核对小改动的办法。

官方依据：来源 1

打开差异，看看它有没有顺手改别的

先看新增、修改和删除的文件清单，再看每个改动与需求有没有关系。给名单加搜索，通常需要解释过滤逻辑、输入控件和对应测试的变化；若同时出现登录校验删除、新增第三方请求或整套依赖升级，就暂停接收这些改动，要求逐项说明。不是说其他文件一定不能改，而是每一处都需要有理由。

使用 Git 时，git diff 查看尚未暂存的修改；已经暂存的内容要看 git diff --cached。已经提交的修改则应对照改动前后两个明确的提交查看，不能因为工作区没有差异就判断什么也没变。新建但未跟踪的文件还要从编辑器或文件清单单独检查；不要只盯着一个空的差异窗口。

让 AI 解释“为什么改”有帮助，但解释不能替代文件内容。尤其检查它有没有通过删除断言、吞掉异常或返回固定成功值，让问题看起来消失。

官方依据：来源 2

用五个输入拆穿“正常路径通过”

下面的候选实现可以运行，输入小写 a 时也能找到两条记录。但它没有按需求处理大写词和空格。候选实现和修正实现都是本站编写的教学代码，不是某个 AI 产品的真实回答。

保存为 review-demo.mjs，运行 node review-demo.mjs。预期先打印候选实现失败 3 个用例，再打印修正实现失败 0 个用例；不需要安装依赖。这里只验证这五个字符串输入，不检验界面、网络或其他语言的大小写规则。

// 原创教学样例；不联网、不读取文件、不调用模型。
const rows = ['Alpha', 'Beta'];
const candidate = q => rows.filter(name => name.includes(q));
const corrected = q => {
  const term = q.trim().toLowerCase();
  return rows.filter(name => name.toLowerCase().includes(term));
};
// 预期来自需求，而不是照抄函数当前的输出。
const cases = [
  ['a', ['Alpha', 'Beta']],
  ['ALPHA', ['Alpha']],
  [' alpha ', ['Alpha']],
  ['   ', ['Alpha', 'Beta']],
  ['zz', []]
];
function failures(fn) {
  return cases.filter(([input, expected]) =>
    JSON.stringify(fn(input)) !== JSON.stringify(expected)).length;
}
const before = failures(candidate);
const after = failures(corrected);
if (before !== 3 || after !== 0) throw new Error('教学结果不符合预期');
console.log('候选实现失败用例：', before);
console.log('修正实现失败用例：', after);

测试通过后，再看测试有没有问对问题

如果测试只检查“函数返回了数组”，上面的候选实现也能通过。测试的预期要来自需求：空查询应该展示全部，就检查全部结果；无匹配应该为空，就检查确实为空。不要让 AI 把函数当前输出抄成预期，再用它证明自己的改动正确。

也可以要求它这样复查：“按最初四条需求，指出当前测试没有覆盖的输入。先给出输入和预期理由，不要修改实现或删除已有测试；如果认为需求矛盾，先说明矛盾。”你仍需要核对这些预期，而不是把第二次 AI 回答当成独立审计。

这段练习故意放了一个不合要求的候选函数，让你看到测试确实能报出差异。实际项目若要验证测试是否有效，应在独立副本里做小范围实验，不能为试验破坏正在使用的代码。

函数没问题，页面也可能没接好

如果改的是网页，还要在实际页面输入大写词、带空格的词，再清空输入。确认结果数、无结果提示和恢复后的列表一致；用键盘能否操作、手机有没有被长内容撑宽，也需要另外检查。函数测试不会证明输入事件已经绑定，更不会替你检查视觉布局。

涉及网络或存储时，先用合成数据验证失败分支：请求失败会不会继续显示旧成功状态，重复点击会不会产生重复写入。没有获准使用真实账户或付费接口，就把未验证部分写明，不为凑一次“全流程成功”而扩大权限。

若新增依赖或安装脚本，先检查来源与用途；看不懂的删除、迁移或上传命令不要直接执行。发现代码把服务商密钥放进前端时，应回到服务端设计，而不是继续调试一个已经暴露凭据的页面。

• 检查 API Key 是否被放进浏览器或仓库 →

只接收能说明白、能退回的这一批

留下改动前可工作的版本、这次实际修改的文件，以及执行了哪些检查。修复搜索时，不必同时接受一整套重构。发现无关改动，可以要求 AI 缩小补丁，再重新检查保留下来的差异。

需要恢复时，先保存自己的未提交工作，分清哪些是这次改动、哪些是其他人的内容，再用项目既有的版本恢复流程处理。不要为了退回一个函数而覆盖整个目录；已经上线并写入的数据，也不会因为代码回退就自动恢复。

最终记录可以很短：“修改搜索的空格和大小写处理；五个本地用例通过；页面操作已检查／尚未检查；没有验证其他语言或大数据量。”这比一句“AI 说测试全过了”更方便接手的人判断还能在哪些范围内使用。

• 如果代码接收模型返回值，再检查结构与业务内容 →