那天我在看一段协作回复，越看越觉得不对。事情本身并不复杂，真正需要我判断的内容也不多，可回复里塞满了过程、检查、背景和已经发生过的来回。它看起来很透明，实际上却让我更难看见事情到底做到哪里了。
我于是直接提出了一个很具体的问题：能不能只把要做的事情和核心现状说清楚，其他日常过程不用每次都展开？这不是要求协作方少做事，而是要求它重新判断，哪些信息值得占用我的注意力。
后来我把汇报压缩成 3 类：结论、待办、问用户的事。这个改动看起来只是少写一些字，真正改变的却是协作的重心——从展示“我做过什么”，变成帮助我判断“现在需要知道什么”。
事情做了很多，汇报却没有变清楚
AI 协作很容易产生一种错觉：过程越完整，用户就越有掌控感。每一步搜索、检查、尝试和等待都被记录下来，似乎没有任何信息被隐藏。但用户通常不是在审阅一份运行日志，他更关心结果是否已经成立，下一步是否需要自己做决定。
当这些层次没有被区分，汇报就会变成一个不断增长的容器。已经完成的动作、没有异常的检查、用户刚刚说过的话、后台任务的细节，都会被原样搬回来。它们并非完全没有价值，只是没有必要在每一次状态更新里都出现。
汇报的价值不在于证明过程足够长，而在于让用户迅速知道自己是否需要判断。
这件事让我重新意识到，协作中的信息不是越多越透明。没有经过筛选的细节，会把重要信息和普通噪声放在同一层。最后用户仍然可以找到结论，但要先付出阅读和筛选的成本。
表面是回复太长，实际是没有替用户分层
我一开始也可以把问题理解成“以后少写一点”。可是单纯减少字数，很容易变成另一个极端：只回复一句“好了”，或者只说“正在处理”。字数变短了，用户却不知道结果是否可靠、还有什么没完成、是否需要参与。
所以真正的问题不是长短，而是信息有没有按照用户的决策需要分层。结论回答已经发生了什么，待办回答接下来还缺什么，问用户的事回答哪里必须由用户选择。只要这 3 个问题被回答，很多过程自然就不必反复出现。
如果不处理这个分层问题，后果不只是阅读疲劳。用户可能错过一个真正需要确认的风险，也可能把“还在进行中”误解成“已经完成”，或者在没有必要的地方重复介入。信息太多和信息太少，最后都可能让协作边界变得模糊。
表面上我是在优化回复，其实我是在重新定义“汇报”这件事。汇报不是把后台发生的一切转发出来，而是把后台状态翻译成用户可以采取行动的少数信息。
先固定 3 个出口
第 1 个出口是结论。它要说明做完了什么，以及结果怎么样。比如任务已经完成，就直接说完成；如果只完成了一部分，就说清已完成和未完成的边界。结论不是一句模糊的“已处理”，而是让用户不用继续追问“处理到哪一步”。
第 2 个出口是待办。它只保留接下来确实还要做的事。如果没有待办，就不必为了显得完整而补一句空泛的“继续观察”。如果有待办，就说明它属于谁、处在什么状态，避免把已经完成的动作重新包装成未来计划。
第 3 个出口是问用户的事。这里不能把一大段背景甩给用户，而要先用一句话说明现状，再提出一个明确的问题。用户需要做选择时，问题应该足够具体；如果当前不需要用户决定，就不要制造一个问题出来。
这 3 个出口之间还有一个重要区别：结论是状态，待办是行动，问用户的事是决策。把它们混在一起，读者就很难分清自己是在接收结果，还是被要求继续工作。
好的精简不是少提供信息，而是把信息放回用户真正需要作出判断的位置。
我选择这个结构，是因为它既能压缩文字，又不会牺牲用户继续判断所需的信息。更短的做法当然存在，比如只保留结论，但那会把未完成项和决策点一起删掉；更完整的做法也存在，比如把所有过程都附上，但那又回到了最初的问题。
哪些内容默认不再重复
确定 3 类信息之后，还需要明确省略边界。否则每次写到一半，协作方仍然会觉得“这一步是不是也应该汇报”。我把例行检查、没有发现问题的过程、用户原话复述，以及后台任务的长篇进度，列为默认不展开的内容。
这里的“默认省略”不是永久隐藏。如果某个过程影响结果、暴露风险，或者用户需要复核，它仍然应该被保留。比如一次检查发现了异常，异常本身就是结论的一部分；一次操作改变了原本的范围，改变范围的理由也需要留下；用户追问细节时，再把对应过程展开即可。
过程只有在影响结果、风险或复核时，才值得从后台进入主汇报。
这条边界比“所有过程都不说”可靠，因为它保留了必要的可追溯性。透明不等于实时转播，透明应该意味着关键判断有依据，出现偏差时能回到相关过程复核。
最容易误判的错误捷径，是把所有执行过程原样转发给用户，以为信息越多越负责。它确实让人看见了更多内容，却没有帮助人更快做决定。另一种错误捷径是只回复“OK”，看起来极其简洁，却把状态、风险和下一步都压没了。
记住规则，不等于规则已经生效
最初的做法是把这套格式写进长期记忆。这样做有用，因为它留下了背景，未来重新开始协作时有机会被想起。但当用户继续追问“这已经是默认流程了吗”，问题就从“记不记得”变成了“优先级够不够高”。
我当时的判断是，记忆只能算参考，不能自动等同于硬性约束。规则如果只存在于背景里，遇到更强的任务指令、不同的上下文或临时的表达习惯时，可能被忽略。用户要的不是这一次回复变短，而是以后所有类似汇报都遵守同一个边界。
因此我选择把精简汇报提升到全局规则层。理由不是全局规则听起来更正式，而是它的作用范围刚好匹配用户的要求：这不是某个项目的偏好，而是一条跨会话、跨任务都应该保持稳定的协作原则。
这件事让我重新意识到，规则的内容和规则的存放位置同样重要。把一句话记下来，只解决了“曾经说过”；把它放进更高优先级的约束，才开始解决“下次还会不会照做”。
把方法变成一次汇报前的检查
这套方法可以复用在写作、开发、资料整理和后台任务中。每次准备汇报前，我会先问自己 3 个问题：结果是什么，接下来还缺什么，是否有事情必须交给用户决定？这 3 个问题如果都没有答案，说明当前可能还不适合汇报，或者任务本身还没有形成可读状态。
接着我会删掉 4 类默认噪声：没有异常的例行检查，不影响结果的过程，用户已经知道的原话，以及只展示忙碌程度的后台流水。删完以后，再补回那些会改变判断的内容，包括失败原因、风险、范围变化、未验证的假设和需要复核的证据。
最后再检查信息的归属。结论不能写成待办，待办不能伪装成结论，需要用户选择的事不能藏在一长段背景里。如果用户读完前几行还不知道“现在发生了什么”，就说明压缩并没有完成，只是把长日志改成了短日志。
一个流程成熟的标志，不是它能把每个细节都保存下来，而是它能在不丢关键判断的前提下，让下一次沟通少依赖临场记忆。固定 3 个出口，就是把这种判断提前交给流程，而不是每次都从头猜用户想看什么。
下次我会怎么做
下次遇到类似协作，我会先把汇报写成 3 段：结论、待办、问用户的事。没有内容的段落直接删掉，不为了格式完整硬凑。过程只有在影响结果、风险或复核时才展开；如果用户想知道细节，再按问题补充对应证据。
我也会先判断这条偏好属于哪一层。如果只是这一次的表达要求，按当前任务执行即可；如果它描述的是长期协作方式，就要进入稳定的规则位置，而不是只留下一个容易被忽略的提醒。这样做，才能让“少说但说清楚”从一次临时改进，变成真正可复用的工作习惯。
真正需要保留的，从来不是每个动作，而是动作背后的判断链。用户要知道事情到了哪里、还差什么、是否需要自己决定；剩下的过程，等它在结果、风险或复核上产生意义时再出现。