验证与门禁

同一句「改好了」，落在不同层上成本差两个数量级。按改动落在哪一层选手段，不要一律交给最贵的那一层。

顺序不能换：前一层不过不进后一层。2 分钟的工具能挡住的问题，别交给 60 分钟的人。反过来，工具报绿也不等于能跳过人看——「这个改动该不该做」只有人能判。

四类里只有评测判断不进那一条入口命令：单次 3–15 分钟且按量计费，只在改提示词、换模型、改问题集时单独跑。性能与容量也不落在四类里任何一类——它靠基准压测跟上次的基线比，判的是趋势不是对错。

一次门禁就是一条命令跑完八项，任一项非零即停在本地。下面是一次全绿的输出。

要认的是这个形状：八项一次跑完、只报通过与否、不看人怎么解释。任何一项变成「警告」「先合后修」，这一条命令就不再是判据。

认它的办法：先看项数，再看勾。八项变四项、或某一项从「非零即停」改成「警告」，比某项红了更危险——红了会被看见，少了不会。入口命令里出现 || true、--no-verify，或某一项被整段删掉，都是同一个动作的不同写法。

场景：助手给「按租户导出」写完实现，人直接提了合并请求，说明里只写了「实现导出」。

门禁是唯一不依赖人盯着的约束：人可以不看，但它每次都在。检查名可以点开，进到那一项的说明。

每一项的阈值数字写在对应的检查页，这一页不重复。第八项最容易漏：规约里的场景不能自动跑，它就只是一份文档。覆盖率则相反，是最容易被误用的一项——它挡的是「新增代码一行测试都没写」，不是「测试写得好不好」。

红线是「不可降级的底线」，不是「所有质量问题」——风格、命名、格式交给工具。前四条本地能拦，后四条靠分支保护与评审；每条都要写得出发现方式，写不出的先别进清单。

第 5 条最难发现，因为它常伪装成「顺手优化」。判断方式很简单——同一次合并请求里出现检查配置与功能代码，就拆成两次。

助手最常见的「修复」不是改错，是改判据——它要的是让报错消失，而让报错消失最快的方式往往是削弱检查。下面这些改动一律挡回，不算完成。

真想放宽一项检查，就走单独的合并请求：不夹带功能改动，说明为什么，由人提交。检查配置、阈值、指令文件都是判据本身，改动要比普通代码更严——把它们放进 CODEOWNERS，指定必审的人。指令类文件也列进来，是因为助手会读它们，与判据是同一类东西，专用写法见指令与配置保护。

同一类问题在测试里还有另一种形态：假测试。它们跑起来是绿的，一条行为也没验证，却同时把覆盖率抬上去——所以看覆盖率看不出它们，评审里也最容易被放过，因为改动说明都写得像是修复。

把两条要求写进合并请求：新增的测试至少有一条会在数据错时变红的断言；跳过的用例单独写原因与恢复时间。

入口命令全仓库只有一条，本地与持续集成跑同一条，不存在「本地过、线上不过」；工作流只调这条命令，不在 YAML 里另抄一份规则。工作流本身不能代替分支保护——检查跑绿了，仍然有人可以直接推到 main，所以要同时打开「禁止直接推送」与「合并前必须通过检查」两项。