docs: 没有真实证据的可能情况不写进 WORK_LOG；记下任务书 06 核对结果

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 23:54:48 -04:00
parent 6850c0a1d4
commit 2925d709a3
2 changed files with 2 additions and 3 deletions
@@ -58,7 +58,7 @@
 1. 改数据的表示或格式要求，让它不可能出现。例：要求研究者的三个数严格递增，就不存在"三个数相等"。
 2. 做不到，就在系统的边界检查，不满足就报错停下。边界指模型的提交、用户的配置、外部服务的返回。下面这些不算边界，不加检查：模块之间的调用，不为另一个模块可能传错参数而查；本项目自己写的程序的输出，包括放进容器里跑的校验器、检查脚本，读的时候按约定的格式直接用，不交叉核对它自己前后是否一致。真出现了，再按"遇到问题先找原因"去改。

-"可能会出现"不是写分支的理由：不写的代价只是它出现时停一次，写了的代价是一段平时跑不到、坏了也没人知道的代码。审别人的提议时也只问一句：不写会怎样？答案是"会报错停下"，就不写。
+"可能会出现"不是写分支的理由：不写的代价只是它出现时停一次，写了的代价是一段平时跑不到、坏了也没人知道的代码。审别人的提议时也只问一句：不写会怎样？答案是"会报错停下"，就不写。没有真实证据的可能情况，在报告里提一句就够，不写进 `WORK_LOG.md`：写进去会变成以后的待办，被下一个 Agent 补成专门处理。

 以下不防：用户本人中途改配置、改提示词、同时开两个进程、随时终止；有人在同一账号下故意用 shell 绕开规则；出错后马上就能看出来的问题。