docs: CLAUDE.md 罕见情况改为规定默认动作

用户 2026-10-02："同意你的修改"。原"什么情况值得为它写代码"的五问与"值得防的三类"要模型自查、且"无法察觉"一类成了写分支的理由；换成默认动作：先改表示让它不可能出现，做不到就在入口报错停下。依据 Anthropic 提示词最佳实践（Overeagerness 一节）、Claude Code best practices（CLAUDE.md 过长会被忽略、审阅者追每条发现导致过度设计）、Minsky "make illegal states unrepresentable"、Ousterhout "define errors out of existence"。文件锁一句移到"中断后怎么恢复"。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -52,24 +52,15 @@
 
 只有原因在我们控制之外时（网络断开、服务超时、进程被系统杀掉），才按"错误怎么处理"做有限次重试，并把失败记下来。原因查不清，或者要修就得动这次范围之外的东西时，停下来把查到的情况告诉用户，不要先上一个临时的绕法。
 
-### 什么情况值得为它写代码
+### 罕见情况怎么办
 
-罕见情况的处理代码平时很少被执行到，坏了也没人知道。分布式系统的故障研究发现，92% 的严重故障出在这类代码里（Yuan 等，OSDI 2014）。所以每加一条专门路径之前，先问自己：
+没见过的情况不写专门处理。按顺序选：
+1. 改数据的表示或格式要求，让它不可能出现。例：要求研究者的三个数严格递增，就不存在"三个数相等"。
+2. 做不到，就在数据进来的那一处检查，不满足就报错停下；真出现了，再按"遇到问题先找原因"去改。
 
-1. 能不能改一下数据的表示，让这种情况变成正常情况的一种？
+"可能会出现"不是写分支的理由：不写的代价只是它出现时停一次，写了的代价是一段平时跑不到、坏了也没人知道的代码。审别人的提议时也只问一句：不写会怎样？答案是"会报错停下"，就不写。
-2. 它防的情况在参考项目的真实运行里出现过吗？没出现过的先不写。
-3. 调用方拿到这个错误能做什么？说不出来，就直接停下，不定义这个错误。
-4. 有没有测试或真实运行会执行到它？执行不到就不写。
-5. 它会不会散到好几个文件里？会的话，先想办法把它收在一处。
 
-值得防的只有三类：没人操作也会发生的、模型正常工作时就会做的、出错后无法察觉的（比如测不到的数值被记成 0）。
+以下不防：用户本人中途改配置、改提示词、同时开两个进程、随时终止；有人在同一账号下故意用 shell 绕开规则；出错后马上就能看出来的问题。
-
-以下这些不防：
-- 用户本人中途改配置、改提示词、同时开两个进程、随时终止；
-- 有人在同一个账号下故意用 shell 绕开规则；
-- 出错后马上就能看出来的问题。
-
-同一个研究目录同时只允许一个控制进程，用一把文件锁实现。
 
 ### 错误怎么处理
 
@@ -82,6 +73,7 @@
 
 ### 中断后怎么恢复
 
+- 同一个研究目录同时只允许一个控制进程，用一把文件锁实现。
 - 每次启动都走同一条恢复路径：从账本读出当前状态，找出已登记要做、但还没有结果的动作，逐个核对。不为不同的中断原因分别写分支。
 - 启动正式运行、调用模型这类花钱的动作，都按"先登记，再执行，再登记结果"的顺序走同一个入口。恢复时只核对，不重做。
 - 核对不出结果，就记为"状态未知"并停下，由用户决定。