Tessl Verifiers 正式发布，用仓库内纯文本规则检查每次 Agent 代码变更

作者：@Amy Heineike 和 @Simon Maple

Tessl Verifiers 是用纯文本编写的规则，存放在你的仓库中，并在每次代码变更时进行检查。每次运行时，它们都会返回通过或失败，因此你可以像今天使用 lint 或测试一样使用 verifiers：在本地、在 pre-commit 中，或作为 CI 门禁。它们适用于 linter 无法检查的规则，例如“面向用户的错误必须告诉用户下一步该做什么”。

它们目前已正式发布（GA），你可以阅读文档开始使用。

我们为什么构建它们

大多数团队已经为他们的 agent 编写了编码标准。也许他们规定了应该使用哪个 helper，或者哪些 API 应该和不应该被调用，当然还有安全最佳实践，比如绝不记录 token。Agent 通常能很好地遵循这些规则，但它们不会每次都捕捉到所有问题。当某条规则被遗漏时，你通常要到代码审查时才会发现，甚至更晚。

Linters 无法帮助处理大多数这类规则，因为它们只能检查确定性规则。AI 代码审查可以捕捉到它们，但审查会查找 PR 中的一般性问题，并不能在每次运行时可靠地检查同一条规则。在 Tessl，我们需要介于两者之间的东西：一种既能理解你的代码，又能保证每次确定性地运行相同规则的检查。

注册以获取早鸟折扣

它们如何工作

一个 verifier 是你仓库中的一个 JSON 文件。它包含一条指令、适用条件，以及一份是/否规则清单。当你运行 tessl change verify 时，一个 LLM 评判器会读取相关文件，并将每条规则评分为通过或失败。

一个 verifier 适用于哪些文件，以及它有多严格，是在 tessl.json 的 verify 块中设置的。每个组会获得 info、warn 或 error 级别。在 CI 中，警告会被报告，但不会使构建失败。错误会以非零状态退出，并可以阻止 PR。由于作用域和严重性位于 verifier 本身之外，你可以在不同设置的团队之间复用一个 verifier。

默认情况下，tessl change verify 只检查当前变更触及的文件。如果你编辑了一个 verifier 或其配置，它会重新检查该 verifier 覆盖的所有内容。要审计整个项目，请使用 --all 运行它，并在 monorepo 中添加 --recursive。

默认评判器是 openai/gpt-6-luna。我们也支持新的 Jev 模型，以防你觉得它在速度、成本或准确性方面更合适，它会为每条规则返回一个判定和置信度分数，而不提供书面推理。你可以使用 --model jev 标志在命令行切换模型选择。.

何时使用

当规则有明确的是/否答案、你能在变更文件中看到证据，并且没有 linter 或测试能可靠地检查它时，verifier 就很合适。如果 linter 能做这件事，就用 linter。

一些效果很好的例子：

每个 API 路由都使用你的类型化响应 helper
每条面向用户的错误消息都告诉用户下一步该做什么
没有 handler 记录请求头、token 或密码

Verifiers 不适合“这可读吗？”这类主观问题。把规则缩小到你可以用清单检查的程度。

把 verifiers 与你已经在使用的其他工具一起思考会很有帮助。规则在 agent 编写代码之前告诉它该做什么。Verifier 在之后检查结果。它们作为一对配合得很好：规则教授模式，verifier 捕捉 agent 没有遵循它的情况。

试一试

安装 verify 插件：

1tessl install tessl/tessl-verify

然后向你的 agent 索要一个 verifier：

1Create a verifier that checks every user-facing error message
2includes a next step for the user.

该插件的 skill 会帮助你的 agent 编写 verifier、设置其作用域并添加 CI 门禁。作用域最终会出现在 tessl.json 中：

1"verify": {
2  "groups": {
3    "core": {
4      "path": "verifiers/*.json",
5      "level": "error",
6      "include": ["src/**/*.ts"],
7      "exclude": ["**/*.test.ts"]
8    }
9  }
10}

在本地针对一个 PR 运行它：

1tessl change verify

[截图：在真实 diff 上显示一个通过和一个失败的检查]

在哪里运行它们

大多数团队从 CI 开始。在 CI 中验证 agent 变更指南介绍了如何设置拉取请求门禁。你也可以在 pre-commit 钩子中运行验证器，或者让你的 agent 在打开 PR 之前运行它们。我们不会强推任何一种方案。

我们建议从 warn 级别开始，这样你可以看到验证器在真实 PR 上的表现。一旦你信任它，就把它提升到 error。

验证器与 Tessl Code Review 是分开的，它们配合得很好。如果审查者总是留下同一条评论，那条评论很可能就是验证器的好候选。

开始使用

安装 Tessl CLI 并登录。
运行 tessl install tessl/tessl-verify，让你的 agent 编写你的第一个验证器。
在本地运行 tessl change verify，然后以 warn 级别将其添加到 CI。
一旦你对结果满意，就把它提升到 error。

验证器运行可免费试用。验证器文档涵盖了完整配置。

我们在自己的代码库中大量使用 Tessl 验证器，发现它们作为检查手段以及引导 agent 编写更好代码方面都有相当大的进步。我们很想听听你的使用体验，所以为什么不在 discord 上告诉我们呢！