先补充前提，再压缩解释

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

读者不理解为什么导出票据要等模式变更，原解释只有“被依赖阻塞”。教学前提是导出器读取新字段customer_code，而当前模式尚无该字段；这个缺失连接才是理解障碍。

具体做法

定位读者没理解的决定及缺少的前提，使用项目已有名词重述。解释前提→当前状态→后果→继续条件，再删掉重复和不必要术语。若前提未证实，先标为待确认；用一个具体例子检验理解，需要时换角度而非反复缩成标签。

反例

导出票据为什么不能开工？答：依赖阻塞。再简短一点：等。

改进写法

导出器需要新字段customer_code，当前模式还没有它。现在按最终接口开发会缺少输入，所以先等该模式可用；若能提供已确认契约，可先做不依赖真实数据的部分。继续条件是字段契约或可用模式得到确认。

为什么这样改

缩短原话不会补上读者缺少的因果关系。明确字段、状态和继续条件，使等待有理由也有结束条件；这比更短的阻塞标签有用。

如何验证

教学读者应能回答缺的是customer_code、当前无法按最终输入验证、何时可以继续。请他们复述决定或提出剩余疑点；若仍不理解，换成一条输入输出例子，不只是再删词。

适用边界

理解因读者背景而异，不能假定所有人缺同一前提。解释不得凭空创造依赖或禁止本可独立推进的工作。项目名词本身不清楚时需先定义，不以行话代替说明。