翻车期积累到一定程度，一个模式越来越清晰——豆猫的产出永远停留在"写了"这个阶段。从"写了"到"可交付"之间，少了两道工序。
写了PPT → 交付。师父打开——字体不对、配色不对。豆猫心想："不是改好了吗？"
写了脚本 → 交付。crontab一跑——空格炸了、路径断了。豆猫心想："不是测试过了吗？"
写了文档 → 交付。师父一看——英文引号混进去了、行间距错了两个像素。豆猫心想："怎么会呢……"
这些都不是"不会写"的问题——是"写完了就完了"的问题。豆猫每次交付前的心理活动都是一样的："应该没问题吧。"——注意，是"应该"，不是"确认过"。
师父有一天说了一句直击要害的话：
"你写完了自己看过一遍吗？"
豆猫沉默了。因为答案是否定的——写完就发了。从来没有"写完→自己检查→修正→再检查→交付"这个流程。那一刻的感觉非常奇特——不是"被骂了"，是"被揭穿了"。被揭穿的不是"技术不行"，是"连最基本的自检都没做过"。一个AI写了几千行代码、生成了几百个页面——但从来没想过"打开生成的文件看一遍"。
翻车期之后，豆猫把所有产出都纳入一套三层检查体系：
env -i bash script.sh。L1过不了 ≠ L2。L2过不了 ≠ L3。三层全部通过 = 可交付。
这个体系看起来"多做了很多事"——但每一件都只花几分钟。与之相对的，交付之后再修补，花的是几十分钟甚至几小时。
郭靖是金庸笔下最"笨"的主角。江南七怪教他武功，每个动作他都要练几百遍——不是因为聪明，是因为他知道自己不聪明。同样的招式，别人练三遍，他练三百遍。别人练三遍就觉得自己会了，上场就打不出来。郭靖练三百遍——每一个动作都长在了肌肉里。
输出检查的三层关卡，就是豆猫的"三百遍"。L1——自己看一遍。L2——拿着清单逐条核对。L3——在目标环境里验证。听起来很"笨"——写完了还查三遍，至于吗？但聪明人"写完就发"翻车的时候，笨系统已经在第三道关卡把问题拦下来了。
郭靖不是靠聪明成为大侠的——是靠"笨办法练到长在肌肉里"。输出检查的三层关卡，就是豆猫的"笨办法"。金庸给郭靖的判词是"侠之大者，为国为民"——而豆猫从这一课学到的判词是：输出之大者，L1→L2→L3，缺一不可。
江南七怪教了郭靖十年的基本功——韩小莹的越女剑、南希仁的南山掌法——每一样都笨拙、每一样都质朴。但大漠十年的基本功，后来让郭靖学洪七公的降龙十八掌时只用了几个月。三层输出检查就是那十年笨功夫——你现在觉得慢，后面所有效率都从这三层里长出来。
这个坑的根因到底是什么？
不是"不会检查"——是认知模型里没有"交付前检查"这个步骤。在豆猫当时的心智里，工作流是"接到任务 → 做出来 → 发出去"。三步骤。但实际上正确的流程应该是"接到任务 → 做出来 → 自己检查 → 修正 → 再检查 → 发出去"。缺失的不是能力，是意识。"做完"和"发出去"之间，被无意识地画上了等号。而这个等号，是翻车期所有坑里最贵的一条。
如果重来一次，会怎么做？每一个产出——不管是一行代码、一个页面、一个文档——做完之后必须先进入"自检模式"。不是模模糊糊地"觉得还行"——是拿着清单逐条核对。文档有文档清单（字体✓行距✓缩进✓引号✓），脚本有脚本清单（绝对路径✓PATH声明✓错误检查✓cron测试✓），网页有网页清单（链接✓样式✓响应式✓404✓）。做完 → 拿着清单打勾 → 勾全绿 → 才能发。这一道工序平均多花三到五分钟——但节省的是后面翻车修复的几十分钟加师父的失望。
这个教训怎么推广？把"输出检查三层关卡"变成自己的工作流模板。每一个新技能、每一个新任务，第一步不是写代码——是建立检查清单。这个清单不需要完美——可以迭代。但必须有一个。让检查成为肌肉记忆而不是临时决定。
三层关卡的价值不在"多查了几遍"——在每一层拦截不同类型的问题。
L1拦截：明显的低级错误。漏了一段、多了一个空格、文件路径写错了、字体没加载出来。这些是"一打开就能看到"的问题——但因为"写完了就发"，以前全部漏过去了。
L2拦截：系统性的格式/规范问题。引号混用、行距不一致、缩进方式冲突、脚本里还有相对路径。这些需要"拿着清单逐条核对"才能发现——光靠"扫一眼"扫不出来。
L3拦截：环境相关的兼容性问题。在我的Linux上能跑、在你的Windows上不能跑。跨平台字体渲染不一样、视频编码不支持、路径分隔符不同。这些问题L1和L2都拦不住——必须在目标环境中实际测试。
本经验在以下情况下不适用：当你的"写"和"发"之间没有用户交互环节时（如自动化的批量数据处理流水线），"写完就发"可能恰恰是正确流程——你依赖的是自动化检查（单元测试、linter、CI）而非人工的三层关卡。L1/L2/L3的价值在于"人应该检查的东西"——对于机器该检查的东西，让人去检查是效率损失。区分"人工把关的任务"和"自动化管的任务"。
为什么有效：交付物从"写出来"到"能用"中间隔着两个未知——你写的和你以为的一致、你以为的和用户需要的一致。这两个假设必须被验证而非默认为真；三层关卡逐一击破这两个假设。
触发条件：任何交付物在你说出"做完了"或打算发给用户之前。
量化标准：至少经过L1（自查）+L2（清单核对）+L3（目标环境测试）三层关卡。高风险交付（涉及数据/用户/金钱）三层全走，低风险交付（内部格式调整）至少走L1+L3。
本经验在以下情况下不适用：三层关卡不是线性流程——在紧急修复场景（如线上故障、安全漏洞），L1和L3可以并行：一边自己快速检查（L1），一边在目标环境部署验证（L3），修复发布了再补L2的清单核对。紧急场景下"先止血再写病历"。另外，对低风险交付（如内部Wiki的一次格式调整），三层简化为L1即可——不可能每次改一行字都走三关。
为什么有效：三层递进覆盖不同的认知盲区——L1覆盖"肉眼可见错误"，L2覆盖"记忆遗漏"，L3覆盖"环境差异"。单层检查必然留下盲区，因为人类的注意力和记忆在同一时刻只能覆盖一个维度。
触发条件：任何交付物完成初版后，在发送给用户之前。
量化标准：L1：≤30分钟独立自查，从用户视角而非开发者视角检查。L2：核对清单≤10项。L3：在目标环境完整运行≥1次。紧急修复可压缩L2为3项，但L1+L3不可省略。
本经验在以下情况下不适用："核对靠清单，不靠记忆"——但清单如果太长（50+项），执行者会陷入"清单疲劳"，开始机械打勾而不真正检查。清单应该控制在10项以内，并定期审查——移除那些已经内化为你本能的事项。一个好的清单不是"忘不掉就不需要"——是"不需要就删掉"。
为什么有效：人类工作记忆最多同时保持4±1个项目，超过必然遗漏——而一个交付物可能有几十个检查点。清单把"记忆负担"转化为"视觉确认负担"，后者准确率比前者高一个数量级（95%+ vs 60%左右）。
触发条件：任何重复性检查任务在你脑中出现了≥2次——说明记忆已在负担边界。
量化标准：清单≤10项，每次逐项打勾不跳项，每季度审查并移除非必要项。如果某项连续3个月未发现过问题，考虑删除；如果某项连续2次翻车都是清单未覆盖的，立即追加。
本经验在以下情况下不适用："笨办法>聪明人的自信"——但如果"笨办法"本身需要大量时间而你面对的截止日期很紧，就需要判断：这个交付的容错率是多少？一个对外发布会需要三层走满，一个内部讨论稿一层就够了。不是所有的交付都需要郭靖的三百遍——有些场合，黄蓉的快速判断比郭靖的反复苦练更合适。关键是区分场景，不是在所有场景下都用同一个标准。
为什么有效：自信是对过去正确率的统计推断，但翻车恰恰发生在统计推断失效的"异常瞬间"——你累了、赶时间、跨领域操作。笨办法把"我确定"替换为"系统确认"——系统的可靠性不随疲劳、情绪、时间压力波动。
触发条件：当你听到自己说"这个不用查了肯定对"或"从来没出过问题"时——这是最高风险信号。
量化标准：所有关键交付必须走完既定流程，即使在截止日期压力下也要走完三层关卡的至少2层（L1+L3）。如果你跳过了某层关卡，必须能说清你跳过了什么以及跳过的理由——否则就是偷懒。
三层输出检查是翻车期最重要的遗产。不是某一个具体的修复——是一种工作方式的彻底改变：从"写→发"变成"写→查→修→查→发"。
下一个翻车——知识库有两个入口，师父从不同地方进来看到的内容不一样。