Tessl 发布 Verifiers，用纯文本规则检查每次 Agent 代码变更
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
本条选题由第三方线索发现；线索方提供的摘要未被采用，本页内容依据下方信源整理。线索来源：AIHOT
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载规则以纯文本形式进仓库
Tessl Verifiers 的定位是补上 linter 与 AI 代码评审之间的空档。团队通常已经为 Agent 写好了编码规范，比如指定该用哪个辅助函数、哪些 API 不该调用，以及不要记录 token 这类安全实践。Agent 多数时候会遵守，但不会每次都覆盖全部情况，规则一旦被漏掉，往往要到代码评审甚至更晚才被发现。linter 只能处理确定性规则，AI 代码评审则面向整个 PR 找通用问题，无法保证每次运行都稳定检查同一条规则。Verifiers 的做法是让检查既能理解代码，又能确定性地重复执行同一套规则。
运行方式与判定结果
一个 verifier 是仓库中的 JSON 文件，里面包含一条指令、规则何时适用的条件，以及一组是/否形式的检查项。执行 tessl change verify 时，由 LLM 裁判读取相关文件，对每条规则给出通过或失败。由于它像 lint 或测试一样返回明确结果，可以放在本地运行、接入 pre-commit，或作为 CI 门禁。默认情况下，该命令只检查当前变更所触及的文件；如果改动了某个 verifier 或其配置，则会重新检查该 verifier 覆盖的全部内容。
范围与严重级别可配置
verifier 适用的文件以及严格程度并不写在 verifier 内部，而是在 tessl.json 的 verify 块中设置，每个组可指定 info、warn 或 error 三种级别。在 CI 中，warn 会被报告但不会让构建失败，error 会以非零状态退出并可能阻止 PR 合并。这种把作用范围与严重级别外置的设计，使同一个 verifier 可以在不同团队间复用，只需各自调整配置。该功能目前已正式可用（GA），官方文档提供了上手说明。
为什么值得看
给 Agent 生成的代码加一道可复用的确定性规则闸门，弥补 linter 与 AI 代码评审之间的空白。
信源1 家
关键事实
相关 · 工具
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。