L4.14.4plan abstraction must match judgement设计研究
计划的抽象层级需匹配用户的判断能力，过细的计划无法被审阅
别名: 计划粒度 · reviewable plan · 不要把计划写成调用日志
概念解释
计划要给人审，粒度就得停在人能判断「这一步该不该做」的那一层：对哪个对象做什么、是否对外。把每一次内部函数、每一次检索、每一次格式转换都列成节点，审阅会退化成点头。计划抽象要匹配判断（plan abstraction must match judgement）：过细与过粗都审不成，过细是读不完，过粗是看不到对外。
四十行「调用工具 X」不是计划，是还没跑的日志。
机制
审阅是有时限的判断。工作记忆和阅读速度给节点数设了上限。超过上限，人改用启发式：看起来像那么回事就批。自动化偏见在计划页上同样成立。过程视图的过密发生在跑的时候；计划过密发生在跑之前，废掉的是执行前这一截前移。可改也依赖可审：节点多到不可识别，删哪一步都变成猜。
对外性、对象、动词是判断所需的最小字段。内部实现细节不是。
怎么研究
同一任务，比较三种计划：对象-动作节点（约数步到十几步）、全量工具调用、只给一句目标。因变量：错误对外节点被拿下的比率、审阅时间、是否报告「我其实没看完」。自变量：节点数、对外是否标出、是否允许展开细节。
没看完却批准，是粒度失败。只给一句目标则对外节点根本看不见。
边界
专家调试需要展开到调用级，那是次级视图，默认不要打开。执行中变更通知若按过细粒度发，会刷屏。真路径可以在内部是细的，展示给审批的必须是聚合后的节点；聚合不得编造不存在的节点。一步任务没有粒度问题。
怎么落地
- 默认计划节点 = 一个对外或对内的世界动作 + 对象。内部检索与格式转换默认折叠。
- 节点数超过你们测过的「还能看完」的上限时，强制分组，而不是继续追加行。
- 验证：把一个错误对外动作藏在第二十个内部调用里。若几乎从不被拿下，粒度就还停在日志。收到对象-动作级再测——拿下了，抽象才匹配判断。再问「看完了吗」——没看完却批了，上限还得再降。