07 · 可以直接抄走的清单¶

按落地成本从低到高排序。前三条今天就能开始，不需要任何工具链。

零成本，立刻可用¶

让 AI 干完活，验收时让它重新读文件、重新跑命令、外部复查结果，不问"你做好了吗"。重要的防御测试亲手引入一次回归、看它变红再撤销。可以直接写进你的个人规则或团队约定。

做技术选择时写一页纸：问题 → 决策 → 考虑过哪些替代方案、为什么不选。被否决的提案也留档。一句话记住理由：不写清楚一个决策打败了谁，它就会被反复重新争论。这同时是对"提议被否、事后别人捡起来做"这类组织问题的自我保护。

审 AI 生成的文档/注释时对照扫：叙述历史（"以前是 X 现在是 Y"）、状态标注（"已实现！"）、推理过程复述、强调通胀、跟不存在的 reviewer 辩论（"这个改动是安全的因为……"）。一条判定标准兜底：只看当前代码的读者，能否解析文中每个引用？ 不能就删或改写。

修法优先级：把事实做成工具或注入上下文（结构化、fail loud、判断与事实分离）> 改 prompt 措辞 > 加训诫。给 agent 的事实供给三原则：宁报错不失真、只陈述不判断、可追溯。

事故/踩坑 → 复盘一次 → 蒸馏：能写成脚本检查的写成脚本（lint 规则、CI 检查、pre-commit hook），写不成脚本的写进操作手册（skill / prompt 片段）→ 每次使用后发现不准，当场修订。规范是实践的沉淀物，不是实践的前提。

格式照抄 SRE：摘要、影响、时间线、根因、护栏。两条纪律：时间线基于日志/记录而不是回忆；根因归到"环境缺什么信息/信号"而不是"模型不行"。

盘点你们的规范，每条问一句：有没有 exit 非零的命令兜底？ 有的接进 CI；没有但重要的，写清楚 review 时怎么检查；两者都做不到的规则，考虑删掉——它大概率已经是摆设。评估任何外来工作流方案（spec 框架、流程模板）也用这把尺子：没有执行器的规范会退化成 token 浪费。

反过来也盘一遍已有的门禁：它的输入是真实事实，还是一份要人工维护的平行清单？它抓到的是代码回归，还是机器抖动？前者该拆，后者该先降级再修。拆或放宽时，写下放弃了哪种检测能力（第 09 章有五种动作的样本）。

给 agent 读的常驻文档（AGENTS.md / CLAUDE.md 之类）只放"每次会话都需要的规则"，每条 1–3 行 + 链接；讲道理的内容放到链接目标里。给核心文档设字数上限，超了先搬走、再压缩、最后才调上限。这直接控制上下文消耗。

任何模型可见的文本（system prompt、工具描述、工具结果模板）改动都应有回放手段——最简单从"改 prompt 前后各跑一遍固定用例集、diff 输出"开始。

判断标准他们自己示范过：每条重规则都要过"收益是否大于维护成本"这一关，过不了就明着豁免，并留下豁免理由和恢复条件。