Tessl 这次扔出来的 Verifiers，说白了就是把“我们团队一直是这么做的”从人脑里搬进仓库。规则写成 JSON 文件，跟代码一起版本管理，每次变更都由 LLM judge 逐条过一遍，给出 pass 或 fail。它不查语法，不跑单测——那是 ESLint 和 pytest 的活。它管的是写不进 linter 的那类东西：日志字段怎么命名、新接口要不要挂 feature flag、错误码能不能随手造一个。
真正有意思的是它站的位置。Verifier 像 lint 或测试一样运行，本地能跑，pre-commit 能拦，CI 里能当门禁。这就把它和“PR 里冒出来的 AI 审查机器人”区分开了——后者的毛病在于反馈太晚，开发者早切到下一个任务了。pre-commit 拦截的边际成本几乎为零，CI 上的失败则是一次明确、有据可查的拒绝。规则本身是 JSON，评审标准于是变成可 diff 的文件，改规则走 code review，谁加的、为什么加，全躺在提交历史里。
当然，LLM judge 不是确定性程序。同一条规则两次跑出不同结果，这种事一定会有。Tessl 把规则放在仓库、让每条独立判定，其实是在承认这一点：不追求绝对正确，而是让“哪条规则在什么情况下判错”可定位、可申诉、可关掉。对已经往流水线里塞进各种 agent 的团队来说，这大概是眼下最实际的答案——别指望模型替你把关，先把自己的规范写清楚；写清楚了，才谈得上自动执行。
