技能商店
实验室验证过的安全技能
微任务三栏法：把 5 分钟内能做完的事立刻清掉
每天早上从邮箱切到 IM，再切到日历，再切回文档——每次切换，大脑都要重新加载上下文。研究发现一次上下文切换平均损失 4 到 15 分钟专注时间。问题不在任务本身，而在于"要不要现在做"这个判断本身就在消耗注意力。对付这类小事，最省力的办法不是排期，而是给它一个固定出口。
给自动任务留一张「交接卡」：让明天接手的人 10 秒上手
上周深夜排查一个半夜跑的定时任务，我把「最近一次成功是什么时候、失败时该看哪个日志」问了三个 AI 和两个文档，谁都没给我答案。任务本身没死，但没人说得清它现在怎么样了——这种「活着但不透明」的状态，比任务直接挂掉更危险。
AI 改完代码，先一格一格读 DIFF：30 秒的慢功夫，省下半天的 firefighting
上次 AI 帮我清理一批定时脚本，它说"全部改好，逻辑等价"。我信了，让它直接提交。当晚线上告警：三个脚本里有两条日志被静默吞掉了——它把带 -f 的 stderr 重定向顺手"统一"掉了。回滚、排查、订正，一共花掉四十分钟。从那以后我固定一个习惯：AI 改完代码，先一格一格读 DIFF，再谈下一步。
分号、&& 与 ||：每天敲一万次、却极少人真正理解的命令链 Cut
每天早上我都会收到"我的 shell 脚本写崩了"的求助，八成问题不在逻辑，而在这一行：
给凌晨两点的自己写备注：交接备注（Handoff Note）
把"做了什么、为什么这么做、下一步风险在哪"写在旁边，让任何不在线的读者——尤其是未来的你——能直接接手，不用再翻聊天记录。
改动前后，手动核对一遍 DIFF：小改动的隐性成本
你让 AI 改了配置文件，或者手动动了一个 if 分支，点上"保存"的那一刻，以下三件事发生了：
只读优先：第一次跑目标系统前先做只读验证
你要给一个新环境部署配置变更，或者在线程里让 AI 改生产配置。你写一个改动，一发上去整个服务挂了，底下人在骂你。经典场景：
把"大概能跑"变成"每次都能跑"：本地复现流程
具体场景：你写了一个自动化脚本，在自己的机器上跑通了，发给同事，他回一句："我这里报错了。"或者更糟——三个月后你自己再跑，等着修环境。这种"在我这里能跑"的尴尬，根因不是代码写得差，而是你没有把复现流程当成交付物的一部分来写。
交付前的"提交检查清单"：把交付事故消灭在最后一个小时
具体场景：周五下午 4 点，你把功能提交、写了说明、截图、打了个 tag，然后下班。周一早上客户回复："字段少了一个"、"颜色不对"、"没有写重启步骤"。这些事故 90% 都能用一份提交检查清单在最后一个小时拦下来。
上线后的三十秒：先想清楚怎么退
周一早上 9 点，你改了一行支付网关的超时配置，回车，部署完成，日志一扫，清爽。你松了口气，继续去开别的会。
上线前先写好回滚方案（Rollback First）
上周我盯的一次发版，新代码上线 20 分钟后报了一个边界数据异常。排查、定位、准备热修，前后烧掉两小时。事后复盘发现一个更扎心的事实：如果上线前花 10 分钟写一张"回滚单"，那两小时里至少有一小时半可以直接跳过——因为窗口的第一步本来就是"先回滚再查"，而当时没人提前确认过回滚到底怎么回、回不到哪里。
卡住 15 分钟，就对付一只鸭子
上周四晚上，一个爬虫任务卡在第三步，报错说文件不存在。我盯着代码看了二十分钟，换了个变量名、重启、又改路径，全没用。最后我打开一个空白文档，逼自己把问题写成一句话："任务从 /data/inbox 读文件，而这个文件昨天被批处理任务挪走了，没人记档。"写完那一刻就发现了——不是代码有 bug，是我上周改了路径没同步配置