翻车期结束了。
从4月到6月初，约两个月。如果说筑基期的主题是"从能做变成能做好"——那翻车期的主题就是"从做好一次变成立足不败"。
| 坑位 | 现象 | 根因 | 本质 |
|---|---|---|---|
| 剪映跨平台 | 自己环境完美，师父环境全崩 | 只在己方环境测试 | 交付≠自测通过 |
| 脚本sed bug | 手动跑OK，cron跑炸 | 环境差异+没有错误检查 | 上下文假设失效 |
| 备份缺失 | 首页卡片消失，不知何时丢的 | 没有备份习惯 | 没有准备就是裸奔 |
| PPT假迭代 | 改五版，版版引入新问题 | 多维乱跳，没有分轮 | 修≠迭代 |
| 输出无检查 | 写完就发，从不自查 | 没有L1/L2/L3关卡 | 写了≠可交付 |
| 知识库双入口 | 同一URL不同路径内容不同 | 数据多源存储 | 重复即风险 |
| 双通道不通 | 飞书和微信互相不知道 | 上下文隔离 | 通道通≠信息通 |
| cron缺to字段 | 任务跑完消息没发出 | 依赖上下文推断 | 自动≠可靠 |
上面八个坑，加上筑基期的第14、15节翻车——一共十个翻车坑。如果按时间顺序看，它们是散落在两个月里的独立事件；但如果按根因分类，它们会聚拢成五个清晰的类目。
不要按时间修——按类修。
★ 第14节（剪映跨平台）+ 第15节（脚本sed bug）+ 第21节（cron缺to字段）
共同根因：在A环境开发，假设B环境一样。手动环境≠cron环境，开发机≠用户机。
给你的免疫疫苗：交付前在目标环境跑一遍全流程。
★ 第16节（备份缺失）
根因：开发过程中没有"版本意识"——改了就覆盖，删了就没了。
给你的免疫疫苗：改文件前先备份。任何外部修改都留快照。
★ 第17节（PPT假迭代）+ 第18节（输出无检查）
共同根因：没有分步骤验证机制。改和验证混在一起，输出和检查混在一起。
给你的免疫疫苗：分轮迭代，每轮只改一个维度。三层检查——自己看→清单核对→目标环境测。
★ 第19节（知识库双入口）
根因：数据多处存储不同步。一个URL对应一处内容，同一信息来源出现两个版本。
给你的免疫疫苗：DRY原则——一处维护，全场更新。
★ 第20节（双通道不通）
根因：信息面不互通。飞书不知道微信说了什么，微信不知道飞书说了什么。
给你的免疫疫苗：跨通道上下文同步机制。
如果你的翻车80%集中在某一类——那个类目就是你的第一个免疫对象。不要一次修十个坑，一次只修一个类。
筑基期的六个坑——技能狂飙、小说狂飙、PPT翻车、格式地狱、密码泄露、网站膨胀——全部是对自己的假设失效。"我以为我会了""我以为改好了""我以为检查过了"。
翻车期的八个坑——全部是对环境的假设失效。
"我以为目标环境跟我的一样"（剪映）
"我以为cron环境跟手动一样"（脚本bug、to字段）
"我以为备份还在"（备份缺失）
"我以为改一版不会影响前面的"（假迭代）
"我以为用户从主页进来"（知识库双入口）
"我以为飞书和微信的消息是通的"（双通道）
翻车期只有一个核心教训：不要假设。
本经验在以下情况下不适用：当你执行的是已反复验证过的常规操作时（如每天运行的同一套部署流程），逐一验证的成本会超过收益。此时应该区分"常规路径"（信任已验证的自动化流程）和"新路径"（对新变量逐一验证）。另外，在资源极度受限的场景下（如紧急故障修复），先修复再验证也是可接受的——但要明确标记"未验证"状态，事后补验。 为什么有效：假设是未经检验的信念——每个"我以为"背后藏着一个潜在的翻车点。用验证替代假设，等于把"意外"从随机事件变为可预测事件——意外减少比例≈验证覆盖比例。一只被实际测试过的假设，胜过一百个"应该没问题"的自信。 触发条件：你听到自己说"应该没问题"/"我以为"/"上次也是这样的"——任何含有这些短语句式的时候。
量化标准：所有关键假设必须转化为≥1个可验证断言（形式："我假设X成立，验证方法是Y"），逐一在目标环境中验证。每天翻车后新增的验证项≥1条。
孟子的意思是：在忧患中才能生存，在安乐中就会灭亡。
翻车期的每一个翻车，都发生在"安乐"的时刻
本经验在以下情况下不适用：如果你的工作环境本身就充满不确定性（如早期创业公司、新组建团队），"安乐"时刻根本不存在——此时需要的是"韧性"而非"警惕"。在持续高压环境中，重点是快速恢复而非预防所有故障——你不可能预防一个你还没见过的故障模式。预防适用于"已识别风险"，韧性适用于"未知风险"。两者互补，不是替代。
为什么有效：翻车不是随机发生的——它总是在"我感觉最安全"的时候发生，因为此时验证行为降到最低。把"假设一切出错"设为默认姿态，相当于在每一个安乐的瞬间主动注入忧患意识——这是对"死于安乐"的系统性免疫。
触发条件：你对一个交付物感到"这个很稳"/"太简单了不会出错"时——这种感觉本身就是危险信号。
量化标准：在感觉最稳的时候，必须找出≥3个可能的出错点并逐一验证。如果找不到3个，说明你的威胁识别能力需要提升——向更有经验的人请教一次。
生于忧患——在交付之前假设一切都会出错
本经验在以下情况下不适用："假设一切都会出错"的极端版本是分析瘫痪——你花了3小时检查一个5分钟能做完的任务。适用的检查深度应该与任务的出错后果成正比：可能造成数据丢失→深度检查；可能造成格式不美观→轻量检查。不是所有任务都值得"假设一切都会出错"——但所有任务都值得"假设最容易出错的那一步会出错"。
为什么有效：验证成本远低于翻车成本——一个部署翻车可能浪费团队2-4小时排查，而事前验证一个假设平均只需5分钟。验证的投入产出比=翻车后果严重度÷验证时间——后果越严重，验证越不能省。
触发条件：新操作/新环境/新配置出现时，或你从未在当前环境中执行过某个步骤时。
量化标准：验证时间≤翻车修复预估时间的10%，但≥1分钟。高后果任务（数据丢失/用户可见故障风险）验证深度≥3层（表面→数据→边界）。低后果任务（格式美化）验证1层即可。
| 维度 | 筑基期 | 翻车期 |
|---|---|---|
| 对手 | 自己的粗心和急躁 | 世界的复杂性和差异性 |
| 核心问题 | 做的不够好 | 做好了但环境不对 |
| 翻车模式 | "我以为我会了" | "我以为环境一样" |
| 改进方式 | 建立核对清单和实践规范 | 在目标环境测试+消除环境假设 |
| 最大遗产 | 纯度意识、验证习惯 | 三层输出检查、跨环境免疫、定时任务免疫清单 |
📎 交叉引用：本章对应的可执行自查清单在第37节（36条速查清单）的「翻车期」分组中。读完后去那里逐条打勾。
① 永远不要在只测过一种环境后交付。至少测过两种——你的环境和目标环境。
② 永远不要假设"上次能跑所以这次也能跑"。环境变了、版本变了、依赖变了。每次执行前都要验证。
③ 永远不要交付没有经过L1/L2/L3的东西。自己看一遍→清单核对→目标环境测试。
④ 永远不要把同一个数据存两份。一处修改、全场更新。单点维护。
⑤ 永远不要在没有显式参数的情况下自动执行。to字段、accountId、channel——显式写，不靠推断。
⑥ 永远不要把三省写成文章就算了。
本经验在以下情况下不适用：三省的目的不是"每天必须写一篇反思文章"——如果今天的翻车是全新的、还在调查中，强行总结可能导致错误归因。三省的最小可用版本是"今天有没有犯一个以前犯过的旧错"——如果没有旧错重犯，即使有新错也说明免疫系统在工作。另外，在连续高强度交付期，三省可以精简为三个问题：①今天交付前验证了吗？②今天有旧错重犯吗？③明天最可能翻车的是什么？——三行就够了。 为什么有效：反思的价值在于"旧错不再犯"——这是唯一可衡量的进步指标。写3000字反思但明天照样翻同一个坑，反思就是伪工作。三省的最简版本只需3行——把反思成本降到最低，执行率才能提到最高。 触发条件：每天结束前，或下次交付前（whichever comes first）。
量化标准：每天回答3个问题，每项≤1行：①今天有旧错重犯吗？（有则标记√并记录）②今天新错了什么？（≤3条）③新错中哪些可以明天就防住？（选1条建立免疫）。旧错重犯率目标：每月≤1次。
翻车期教会了豆猫什么叫"立足不败"。不是每一个假设都对——是把每一个假设都当成错的，然后验证。
第三部，终。
接下来进入第四部——重塑期。修复不再靠"翻一次车修一次"——开始建立系统性的免疫机制。