给编程智能体每轮改动加上增量检查

编程智能体连续改了多轮，最后才运行类型检查，报错就可能混在一大段 diff 里，很难定位是哪轮引入的。dev.to 的这篇文章提出，把利用缓存的检查放到每轮改动之后，尽早反馈问题。现有节选给出了 tsc、ESLint 等工具的用法，也提醒：新建 git worktree 后，首次检查仍可能较慢。

目前能确认什么

增量检查会复用此前的分析结果，减少重复工作。但不同工具的缓存覆盖范围不同，不能统一理解成「只检查改过的文件」。

TypeScript 的示例是：

npx tsc --noEmit --incremental --tsBuildInfoFile .tsbuildinfo

它保存项目依赖图等信息，后续运行复用缓存，也能发现修改类型后遗漏的跨文件调用。.tsbuildinfo 应加入 .gitignore。

不要把改动文件列表直接传给 tsc。

节选明确指出，命令行指定输入文件会使 tsconfig.json 被忽略，丢失其中的严格检查和路径配置。应让 tsc 检查项目，再由增量机制减少工作量。

ESLint 可以使用 --cache --cache-strategy content，但缓存不跟踪文件间依赖，涉及类型或导入关系的规则可能返回过时结果。作者因此要求合并前再运行一次不带缓存的检查。

ESLint、Ruff、tsc 和 Cargo 的缓存保存在项目目录内，新 worktree 的首次运行是冷启动，不能用它代表后续检查耗时。

我的判断

我认为，最有价值的变化是让报错尽量对应到单轮改动，缩小排查范围。接入智能体流程时，检查失败应先交回当前轮修复，再继续下一轮任务。

每轮检查通过，仍不能作为任务完成的唯一依据。

例如，cargo check 不包含完整代码生成；ESLint 缓存也有跨文件盲区。任务结束时仍需要完整构建、测试及相应检查。

目前节选未完整展示八种工具，更没有给出适用于所有项目的耗时结论。是否适合每轮运行，还要看项目规模、缓存命中情况，以及智能体是否频繁创建新 worktree；这些需要在自己的仓库里测量。