用可审查差异约束 AI 文件修改

AI 说「文件已经改好了」，离你真正接受修改还差一次审查。这篇文章给出的办法很具体：把可检查的 diff 放在 AI 建议和项目文件之间，先核对改动范围，再检查内容含义，最后通过项目的正常入口验证。

它没有比较哪款模型更强，也没有提供效率提升数据，而是围绕一次文档字段改名，梳理了一套可复用的验收流程。对经常让 AI 批量修改示例、配置和文档的程序员来说，这几分钟能帮助你明确：到底该检查什么，才能放心接下补丁。

搜到了，不代表可以改

原文设定了一个小型文档仓库：只给两个示例里的字段改名，归档中的旧示例必须保留。AI 搜出了多处同名内容，但搜索结果比允许修改的范围更大。

搜索范围和写入范围必须分开。

归档可以帮助 AI 理解历史用法，却不因此获得修改资格。与其笼统要求「尽量别动其他文件」，不如明确列出两个允许修改的路径，并要求 AI 只报告其他位置的匹配项。

这套做法还需要一个起点：干净的工作区，或者只包含本次任务所需文件的临时副本。如果已有未提交改动，就先保留它们并记录位置，否则后面很难分清哪些是原有工作，哪些是 AI 新增的修改。原文并没有要求为了得到干净状态而丢弃本地工作。

为什么要先看文件清单，再读 diff

作者建议先运行 git status --short，查看已修改和未跟踪的路径，再用 git diff --stat 观察已跟踪文件的改动分布。

这一步先回答范围问题：该动的两个文件有没有动，不该动的归档有没有被碰到，有没有突然冒出新文件。确认范围以后，再逐个阅读获准路径的具体 diff。

几个命令不能互相替代。普通的 git diff 不会展示未跟踪文件，也不会展示已经暂存的改动；暂存区需要用 git diff --cached 检查。只盯着一份看起来合理的补丁，可能漏掉补丁之外的文件。

接下来才是语义审查。同一个字段名可能出现在注释、对象的键或字符串值中，拼写相同，用途却不同。机械替换完成，不代表请求完成。

作者还提醒逐块阅读 diff。这里的差异块（hunk），就是一次修改及其附近的上下文。检查字段有没有改对，也要看周围示例是否仍然成立。缩进在普通文字里可能无关紧要，在结构化示例中却可能影响解析。如果只是改名，却连带重排了整段内容，就应要求缩小补丁，让审查重新聚焦。

验证通过，还要再检查一次工作区

验证应该走示例真正的使用入口：需要解析的示例，就实际解析；出现在渲染文档中的内容，就渲染对应页面并阅读修改后的部分。

格式检查通过只能提供一部分证据。它可能证明排版符合规则，却不能证明示例仍然表达了正确用法。

检查结束后，还要再次对照允许修改的路径清单。验证工具可能生成本地输出，这些文件是否应该进入补丁，需要单独判断；项目没有要求时，不应顺手提交生成文件。

最后留下简短验收记录：原始请求是什么、允许修改哪些路径、实际运行了什么检查。如果归档示例被刻意保留，也写清理由。下一位审查者就不必翻遍聊天记录，才能理解为什么旧字段还存在。

原文也把这套流程用于比较 AI 工具：让候选工具处理同一个小仓库、接收同一条指令，记录改动路径、符合要求的修改，以及接受结果前需要纠正的地方。提出修改、应用修改和批准结果，是三个不同环节；回复速度只覆盖了其中一部分工作。没有实际测试过的写入控制或权限设置，应保留结论。

我的判断

我认同它把审查对象具体化的做法。与反复追问 AI「你确定没改错吗」相比，路径清单、差异块和实际检查结果更容易核对，也更方便指出下一轮需要修正的位置。

但这是一套流程建议，原文没有给出产品实测、错误率或耗时对照，不能据此宣称它一定提高了多少效率。

它的例子也有明确前提：任务小、路径已知、修改目标单一。换成跨文件重构，允许路径可能需要在分析后扩展；此时应该先更新范围约定，再检查实现，不能把最初的文件清单当成永远不能调整的限制。

此外，diff 能展示文本变化，却不能独立证明行为正确。自动测试、权限控制和人工审查各自解决不同问题。这篇文章最有价值的地方，是把它们串进验收过程，而不是把一份好看的补丁当成最终答案。

能拿来做什么

• 让 AI 修改文档或示例前，写明允许修改的文件路径、具体替换目标，以及哪些目录只供参考；其他匹配项要求单独报告。
• 接收补丁时，先用 git status --short 核对范围，再结合 git diff --stat 和具体 diff 阅读；存在暂存改动时，补看 git diff --cached。
• 修改前端文档或 Node 示例后，运行能实际覆盖该示例的解析、执行或页面渲染检查，并再次查看工作区，确认验证生成的文件是否需要保留。
• 试用不同 AI 编程工具时，固定仓库和指令，同时记录返工内容与验收检查，避免仅凭回复速度判断哪个更适合团队。