技术 · 熟练
检查自己挂了，默认让它过吗
闸门值不值钱，只看它坏掉时系统往哪边倒
大多数人给自动化任务配的检查，默认都是「放行」：格式校验报错就跳过、权限规则读不到就当没规则、敏感词服务超时就先发出去。这类检查只在一切正常时存在，而一切正常时你并不需要它 —— 真正需要它的那一刻，恰好是它自己也最容易坏的那一刻。这一页做的是把默认值翻过来：判定失败 = 不通过；再让「检查失败」在日志里长得跟「检查通过」不一样；最后故意弄坏一次，看流程是不是真的停住。
方法 · 一图看懂
1
先把闸门列出来 — 哪些检查在跑：格式与必填 · 权限规则 · 敏感与隐私 · 预算与条数上限 · 结果自洽
2
逐个问「它失败时会怎样」 — 多数是放行；把每个检查的默认方向写成一句话，写在它旁边
3
把放行改成阻断 — 判定失败 = 不通过，⛔ 不是「跳过这一项继续跑」
4
让失败可区分 — 检查失败与「检查通过」在日志里长得一样，是最贵的一种静默
5
演练一次 — 故意让某个检查失败（改坏配置 / 断掉依赖），看流程是否真的停住并报出是哪一道
原理 · 为什么有效
检查的价值不在「写得全不全」，在「它坏掉时，系统往哪边倒」。fail-open 的检查有一个隐蔽的成本：它让「没有报警」同时意味着「没问题」和「检查根本没跑」—— 这两件事在日志上无法区分，于是所有人都会按「没问题」来读。把默认翻成阻断之后，代价立刻可见：一次配置错误会让任务停下，而不是让它带着坏数据继续跑。这条判据比「多加几个检查项」重要得多：再多检查，只要默认放行，它们的期望价值都接近零。同族的做法在别处也出现过 —— 策略引擎把 deny 放在 allow 之前、审计工具要求「每个动作都能回放」，思路是同一个：先保证「不确定时不动」，再谈「动得对不对」。
适用场景
适用：每天 / 每周自动跑的任务 · 会对外发消息、写文件、改线上数据的 agent · 多人共用的技能与插件 · 有合规或预算红线的流程。⛔ 不适用：纯只读的查询任务（阻断只会让你多按一次重跑）· 探索性的一次性脚本（还没定型，谈不上闸门）。⚠️ 前提：你至少能说清「这个任务有哪几道检查」，否则第一步就做不了。
自测 · 5 问
你能不能一条条说出这个任务有哪几道检查，以及每道检查失败时会发生什么？
上一次某道检查其实没跑成，你是怎么发现的？
你的日志里，「检查通过」和「检查失败」是不是长得差不多？
你有没有故意弄坏过一道闸门，看流程会不会停？
这道闸门拦下过东西吗？半年一次都没拦下，它可能一直没在工作。
怎么上手 · 验证步骤
先挑最贵的那一个任务，不要全改。第一步只做一件事：把它的检查项列成清单，每项后面写「失败时：放行 / 阻断」。第二步，挑其中一项改成阻断（优先选「会造成对外影响」的那一项：发消息、写数据、花钱）。第三步，改完立刻演练：把该项的依赖弄坏，跑一次，确认流程停在它这里、并且报出是哪一道。第四步，把这次演练的日志留一份 —— 下次有人问「这闸门有用吗」，拿它回答。
演练之后看三样：① 流程停了吗 ② 报错里有没有写清「哪一道闸门、因为什么」③ 停下之后有没有留下可续跑的现场（做了一半的东西在哪、从哪继续）。三样缺一，就是「停了但没人能接手」。