此方法适用于普通协作，不保证所有请求都合理或一定被满足；请求内容仍需与实际关系和规则相符。
事实要让别人能够核对
“全乱了”是总体感受，别人不容易验证；“第二页标题与目录不一致”是可检查的描述。写事实时，限定具体对象和这一次情况，不引入未经确认的动机。若事实还没有核实，可以写“我目前看到的是”并邀请对方检查。这样既保留问题，又给发现遗漏留下空间。
影响不要无限放大
说明影响是为了让对方理解优先级，例如“我无法继续排版”，而不是断言“这毁了所有安排”。只写自己能确认的后果。尚未发生的风险可用“可能”并说明条件；如果只是个人偏好，也直接说“我更希望”。分清事实、推测和偏好，能避免用语言把一个可调整的小问题升级为全面指责。
原创示例：活动信息变动
原创场景：“握草，地址又变了？”改为“通知里的集合地点与昨天不同，我已经在路上。请确认以哪个为准，并发一下附近标志。”这句话包含可核对差异、当前影响和两个相关请求。若对方说明是自己看错日期，应及时修正理解，而不是为了保住语气继续争论。
可执行检查单
- 01圈出一句可以核对的事实。
- 02补上与这次沟通有关的影响。
- 03写清希望确认或完成的动作。
一个常见问题
每次都要写三句话吗？
不需要。简短任务可以合成一句，如“第二页缺图，请补上原图后告诉我”。框架用于检查缺了什么，不要求把自然交流写成表格。
请求要给对方回应空间
“现在立刻解决”可能没有可执行的信息。可以问“能否在出发前确认”，并说明真正需要的时间。若对方做不到，邀请提出替代安排。请求和命令的差别不能只靠一个“请”字决定，也要看是否允许说明限制。涉及必须遵守的流程时，应明确引用实际约定，而不是伪装成可自由选择。
区分请求与结果通知
有些消息需要协商，有些只是告知已经确定的事实。原创例句：“我已按约定发出文件，链接在上一条，请确认能否打开。”其中前半是结果通知，后半是请求核对。不要把尚未同意的安排写成已经完成的决定，也不要把必需的任务信息藏在随意感叹后面。如果你需要对方选择，可以列出真实可行的两个方案，并说明什么时候需要答复，让接收者知道如何参与。