有意改动不是故障
入档：2026-07-23 来源：LastStand《从0到发布》教程的跨会话配图协作（主会话 Claude Code + Claude 桌面版拍图，靠
docs/screenshot_handoff.md交接） 验证状态：⚠️ 首次；一次错误归因让同一处改动被还原两次、还写了一节错误经验 再验：2026-07-28 强再验并扩容为四类——kb-content 的整目录脏改动被连续两次误判为工具事故（真凶是自家构建脚本的设计行为），且第 5 条操作规则「归因被推翻要连经验一起改」在那次被反向验证：没改的错误归因，会主动加速下一次误判。见 构建产物的脏改动不是事故_复发是归因错了的信号_v1
一句话律
看到文件被改，先分清是谁的有意操作，别默认是故障就动手还原。 用户的手动改动几乎总是有意的——先问”他为什么这么改”，而不是”这是不是坏了”。
来源实例
教程「成品展示」区原有一张战斗截图，是早期版本的 3D 机甲画面。跳蛛先生手动删掉了这张图的引用（因为它过时了，和当前 2D 精灵敌人不符）。
我（主会话）看到 zero_to_release.md 被改、战斗图引用没了，直接归因为”桌面版编辑器的 format-on-save 越界删了内容”——于是 git checkout 还原了一次，后来又 Edit 把图加回去，还基于这个错误归因写了一整节”防 formatter”经验。跳蛛先生一句话点破：“战斗图是过时的，我手动删除了，你应该安排补拍。”
代价：同一处改动被错误还原两次、一节归因错误的经验、几轮来回澄清。改对之后——正文改成”待补拍”占位 → 桌面版进游戏补拍当前 2D 精灵战斗画面 → 回填。结果反而更好：战斗图从过时的 3D 机甲更新成当前画面，正好契合教程”3D 模型 → 2D 精灵”的主线。
四类归因（动手前先分）
文件出现变化时，来源无非四类，处理方式完全不同：
| 来源 | 特征 | 处理 |
|---|---|---|
| 用户有意改 | 删过时内容、调措辞、改结构——像在贯彻某个意图 | 尊重，别还原；不解其意就问 |
| 协作方/工具越界 | 副会话或 formatter 误伤了不该动的内容 | 还原，并在交接单加约束 |
| 无害格式化 | 表格重排、缩进规整，渲染结果无差 | 通常保留，别为格式化单独返工 |
| 流水线的设计产物（2026-07-28 补） | 整目录、成百上千个文件同时变，形态高度一致；目录在 .gitignore 里、由脚本克隆、同步时会 reset --hard | 既不还原也不提交；确认是派生物后，让它别出现在需要判断的位置 |
误判几乎都是把第①类（人的意图）当成第②类（工具的副作用）——于是”帮忙”撤销了用户的决定。 第④类的误判方向不同：它会被当成第②类事故，于是白白归档、stash、反复清理一个每次构建都会重新产生的东西（见 构建产物的脏改动不是事故_复发是归因错了的信号_v1，同一现象误判了两次）。分辨它只要看一个信号：这个目录是不是可以整个删掉再重建——能，就是派生物。
为什么会错
- 默认归因是”坏了”：看到变化第一反应是”出故障了要修”，而不是”这是谁做的、为什么”。
- 前一个坑刚踩过：这次之前正好在同一份交接里遇到过 formatter 重排表格（真的是工具行为），于是把”删图”也顺手归到 formatter 名下——用一个真实的模式去套了一个不属于它的现象。
- 成本倒置：花两次还原 + 一节经验去对抗一个”故障”，而真相只需一句”这图是你删的吗”就能问清。
操作规则
- 看到正文/文件被改，先
git diff看清改了什么，再判断谁改的、为什么。 - 按三类归因分流；归因不清就问一句，别擅自还原——还原是破坏性动作，撤销的可能是用户的决定。
- 对用户的手动删除/修改，默认有意：先假设”他在解决什么问题”，据此往下走（如”过时了要补新的”），而不是”这错了要还原”。
- 确需还原时，还原前说清理由让对方能否决；别把还原和别的改动混在一个 commit 里，方便回退。
- 基于归因写下的”经验/规范”，一旦归因被推翻，连经验一起改——错误的经验会污染后续判断（本次那节”防 formatter”经验就得推翻重写）。
边界
协作方（副会话 / formatter）确实越界误伤内容时，还原是对的——本律不是”永远别还原”，而是动手前先分清是”人的意图”还是”工具的副作用”，别把前者错当后者。人不可达、异步等待成本高时，可先按最合理的一类处理，但把判断标为假设，第一次能确认时立刻证实或推翻。
关联文档
- ⭐ 构建产物的脏改动不是事故_复发是归因错了的信号_v1 —— 本律的强再验与扩容（2026-07-28）：补出第④类「流水线的设计产物」，并把本律第 5 条操作规则推进一步——那条说「归因被推翻要连经验一起改」，那次证明了不改的后果：写进记忆的错误归因让第二次误判来得更快也更自信（“上次就是这个原因”）。附三条可迁移判据：复发+已修=上次归因错（比时间戳最快证伪）、查”谁干的”要点名册而非从 diff 形态反推、派生物损坏≠源损坏
- 变通方案不等于故障点_v1 —— 最同族：那条管”别从产物形态反推故障位置”，本条管”别把文件变化默认成故障”；都是接手他人产物时的错误归因
- 复盘事实先行原则 —— 事后同理：先冻结事实再归因，别让”默认叙事”接管判断
- Cowork协作的接口文件模式 —— 场景枢纽：本次踩坑发生在跨会话协作的交接链路里
- Claude完成报告核查心法 —— 邻近：核查协作方产出的真实性；本律更靠前，管”别误判用户/协作方的改动性质”
- ⭐ 交付前实测证伪律_v1 —— 同族纪律：证伪在交付前、核查在交付后、本律在”动手还原前”
- 04_方法论与洞察索引