改完十几二十个文件以后，测试绿不绿、类型过不过，最后还是人在终端里补跑。开第二个聊天窗让另一个模型「再审一遍」，复制粘贴 diff 本身又耗一轮。想少值守，又不想把生产变更交给无人值守脚本，更靠谱的是把「完成标准」写成机器能判对错的检查，再决定哪些规则必须由工具强制执行。
可执行的完成标准
多数仓库里已经有单测、类型检查、lint。缺的往往不是命令本身，而是 Agent 结束前有没有稳定跑它们。Best practices for Claude Code 把指令分成两类：写在提示或项目说明文件里的，模型通常会听，但仍可能某次跳过。写进 hook、deny 规则、托管设置里的，由工具层每次执行，不取决于模型记不记得。
落地时可以很土：
- 在短配置里写清「跑单个测试文件 / 全量类型检查 / lint」的准确命令，让 Agent 改完自己跑。
- 需要「不过就不能收工」时，用 Stop 一类 hook：脚本非零退出就挡下结束，并把 stderr 打回给模型继续修。文档里的类型检查例子，是把编译器输出重定向到 stderr，失败则
exit 2。 - 编辑或写入之后自动跑格式化，可以用 PostToolUse 一类 hook，避免只靠「记得要 format」那一行说明。
- CI 继续守合并门槛。本地 hook 减少值守。远端 CI 防止「我机器上绿了」直接进主干。
别把偏好也写成 hook。文档的判断很直：老是加粗强调、模型还是漏，说明这条该进 hook。反过来，只是风格偏好却挂了一堆 hook，维护成本会反噬。钩子本身崩溃或超时还想挡动作时，配置里要选失败即阻断，避免扫描仪挂了提交却放行。
上下文别灌太满
各家工具都会读一份项目级说明（有的叫 CLAUDE.md，有的叫 AGENTS.md）。每次会话都会带上的文字，只写读代码读不出来的东西：怎么跑检查、哪里的旧模式不能抄、部署或评审有哪些口头约定。目录结构、框架常识让模型自己看仓库。说明越短越好。个人偏好进本地、勿提交的文件，别塞进团队共享的那份。
只对某一目录生效的约定，可以放到带路径过滤的规则文件里，避免全局说明越写越长。工具连接也一样：用不到的 MCP 服务器会占上下文，闲置的先关掉。会话里若支持查看上下文占用，改完说明文件后看一眼有没有真的加载到。
交叉审核只审 diff
多模型交叉看，有用的通常不是「把整段对话再讲一遍」，而是固定输入输出：变更 diff、对应的需求或规格、只要正确性缺口不要风格意见。有的产品提供「在没见过你推理过程的子代理里审当前分支改动」的命令。通用做法也一样——另一个会话或另一个模型只拿 diff 和验收标准，回差距列表，主会话再改。
审的时候写明跳过文风类意见。评审者被要求「找问题」时总会找到点东西。照单全收，容易多出用不上的抽象和测不到的用例。
少值守 ≠ 无人改生产
谈无人值守时，实践清单里常出现这几道题：完成长什么样、能不能自检、允许碰哪些路径、什么机制叫停、结果交给谁签字。轮次上限、预算上限、分支保护、合并仍要人批，都是边界，不是可选装饰。把生产部署、强推、写库脚本设成 deny 或必须人工批准，比再开一个「全自动运维」聊天窗安全。
权限弹窗、sandbox 管的是单次动作谁批准。这篇只谈怎样少盯梢还不掉质量。两边可以一起配，但不要互相替代。你们现在卡在「模型说测过了但没贴输出」，还是卡在「本地绿、CI 红」？