From 310b901446c1cd3fb8d04b1f8b6201f2c364c9f7 Mon Sep 17 00:00:00 2001 From: iomgaa Date: Fri, 2 Oct 2026 02:11:16 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20CLAUDE.md=20=E7=BD=95=E8=A7=81=E6=83=85?= =?UTF-8?q?=E5=86=B5=E6=94=B9=E4=B8=BA=E8=A7=84=E5=AE=9A=E9=BB=98=E8=AE=A4?= =?UTF-8?q?=E5=8A=A8=E4=BD=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 用户 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 --- CLAUDE.md | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index a778246..4b237e8 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -52,24 +52,15 @@ 只有原因在我们控制之外时（网络断开、服务超时、进程被系统杀掉），才按"错误怎么处理"做有限次重试，并把失败记下来。原因查不清，或者要修就得动这次范围之外的东西时，停下来把查到的情况告诉用户，不要先上一个临时的绕法。 -### 什么情况值得为它写代码 +### 罕见情况怎么办 -罕见情况的处理代码平时很少被执行到，坏了也没人知道。分布式系统的故障研究发现，92% 的严重故障出在这类代码里（Yuan 等，OSDI 2014）。所以每加一条专门路径之前，先问自己： +没见过的情况不写专门处理。按顺序选： +1. 改数据的表示或格式要求，让它不可能出现。例：要求研究者的三个数严格递增，就不存在"三个数相等"。 +2. 做不到，就在数据进来的那一处检查，不满足就报错停下；真出现了，再按"遇到问题先找原因"去改。 -1. 能不能改一下数据的表示，让这种情况变成正常情况的一种？ -2. 它防的情况在参考项目的真实运行里出现过吗？没出现过的先不写。 -3. 调用方拿到这个错误能做什么？说不出来，就直接停下，不定义这个错误。 -4. 有没有测试或真实运行会执行到它？执行不到就不写。 -5. 它会不会散到好几个文件里？会的话，先想办法把它收在一处。 +"可能会出现"不是写分支的理由：不写的代价只是它出现时停一次，写了的代价是一段平时跑不到、坏了也没人知道的代码。审别人的提议时也只问一句：不写会怎样？答案是"会报错停下"，就不写。 -值得防的只有三类：没人操作也会发生的、模型正常工作时就会做的、出错后无法察觉的（比如测不到的数值被记成 0）。 - -以下这些不防： -- 用户本人中途改配置、改提示词、同时开两个进程、随时终止； -- 有人在同一个账号下故意用 shell 绕开规则； -- 出错后马上就能看出来的问题。 - -同一个研究目录同时只允许一个控制进程，用一把文件锁实现。 +以下不防：用户本人中途改配置、改提示词、同时开两个进程、随时终止；有人在同一账号下故意用 shell 绕开规则；出错后马上就能看出来的问题。 ### 错误怎么处理 @@ -82,6 +73,7 @@ ### 中断后怎么恢复 +- 同一个研究目录同时只允许一个控制进程，用一把文件锁实现。 - 每次启动都走同一条恢复路径：从账本读出当前状态，找出已登记要做、但还没有结果的动作，逐个核对。不为不同的中断原因分别写分支。 - 启动正式运行、调用模型这类花钱的动作，都按"先登记，再执行，再登记结果"的顺序走同一个入口。恢复时只核对，不重做。 - 核对不出结果，就记为"状态未知"并停下，由用户决定。