一份周报让AI先起稿，几分钟后屏幕上出现完整段落，语气平稳，结构齐全。人读了一遍，却改不动：删掉一段会牵动上下文，保留又像在替一段并不认同的话背书。问题不是它没写，而是它不知道这份周报要给谁看、哪些话不能写、哪些空白需要留给人。
把任务交出去之前，先定义什么叫完成
人机协作里的摩擦，很多发生在验收环节：人以为机器懂了自己的意图，机器只完成了字面任务。与其反复追问“为什么写成这样”，不如在交付前写清完成条件，比如“用于内部同步，不出现承诺性表述，保留两处待确认”。这类说明看起来琐碎，却能减少后面来回修改的成本。
反馈的密度，需要被设计
人看到偏差就不断补充要求，结果上下文变长，任务也跟着漂移。有效的反馈更像校对标记：指出一处、说明原因、给出可执行修改，再观察下一轮。把“不”说清楚，能减少十句形容词。人机协作不是把所有判断都推给模型，也不是让人逐字重写，而是让反馈落在可检查的颗粒度上。
保留人的否决权，也要保留人的解释义务
如果只把AI当草稿工具，人仍要解释为何采用或拒绝。拒绝不是一句“感觉不对”，而是能指出哪条事实需要核对、哪种语气不适合、哪个结论缺少依据。在人机协作中，拒绝不是失败，而是边界被看见。机器可以快速铺开可能性，人需要承担选择之后的说明责任。
回到那份周报，真正需要先写的不是提示词，而是一张简短的任务说明：读者是谁，哪些事实必须核对，哪些语气需要避开，出现分歧时由谁拍板。机器可以生成文字，人得决定这段文字是否值得被发送。把“不”说清楚，协作才有可谈的余地。