仓库规则不再只靠人盯：Tessl Verifiers 让每次代理改动都过一遍通过或失败
核心概要
Tessl 发布 Verifiers，把仓库里的编码规则写成纯文本检查项，在每次代码改动时由 LLM 裁判逐条判定通过或失败，并像 lint 或测试一样在本地、pre-commit 或 CI 中运行。此前这类规则只能靠代码评审或 AI 代码评审发现，前者滞后，后者面向整个 PR 寻找一般问题，无法保证每次运行都检查同一条规则。Verifiers 目前处于 GA，默认裁判为 openai/gpt-6-luna，也可切换到只返回判定与置信度的 Jev 模型。
深度剖析
仓库里那些写下来给代理看的编码规则，现在可以在每次改动时被自动检查，并给出通过或失败的结果。 此前这类规则主要靠代码评审发现，或者由 AI 代码评审处理，但评审面向整个 PR 寻找一般问题，不会在每次运行时可靠地检查同一条规则。 Verifiers 在每次运行时返回通过或失败，因此可以像 lint 或测试一样用在本地、pre-commit 或 CI 门禁中。
检查项以 JSON 文件形式放在仓库里，包含一条指令、适用条件以及一份是或否的规则清单。 运行 tessl change verify 时，由 LLM 裁判读取相关文件并给每条规则打分。 默认裁判是 openai/gpt-6-luna，也支持 Jev 模型，后者对每条规则返回判定和置信度而不写推理过程，可用 --model jev 在命令行切换。
检查范围与严格程度放在 verifier 之外配置，因此同一个 verifier 可以在不同团队以不同设置复用。 tessl.json 的 verify 块为每个分组设定 info、warn 或 error 级别；在 CI 中警告会被报告但不使构建失败，错误则以非零退出并可以阻止 PR。 默认只检查当前改动触及的文件，改动 verifier 或其配置时会重新检查该 verifier 覆盖的全部内容，用 --all 审计整个项目，在 monorepo 中加 --recursive。
启示与展望
Verifiers 面向的是有明确是或否答案、证据能在改动文件中看到、且没有 linter 或测试能可靠检查的规则，例如每条 API 路由使用类型化响应助手、面向用户的错误信息告诉用户下一步、处理器不记录请求头或令牌。它适合放在 CI 作为 PR 门禁，也可以放在 pre-commit 钩子中，或让代理在开 PR 前运行。建议从 warn 级别开始观察真实 PR 上的表现，信任后再移到 error。
Verifiers 不适合“这段代码可读吗”这类主观问题，规则需要收窄到可以用清单检查的程度。如果 linter 能完成这项工作，就应当使用 linter。默认只检查当前改动触及的文件，全项目审计需要显式加 --all。