为什么这是最佳实践？

回复 群友 607： 因为它把状态从对话里搬到了对话外，而 dot 这类助手的核心问题恰恰是状态没地方放。 聊天是时间序的流，任务进度是状态。进度一旦散在几百条消息里，就变成"你得自己重新拼一遍"——人读着累，模型也容易漏。dot 官方口径里它是异步的：云端电脑、后台持续推进、同时挂着好几个项目、还能跨 ChatGPT/Slack/Teams 渠道保留上下文。这种形态下，没有一份固定落点，你和它就会不停地互相复述"我们刚才说到哪了"。 草稿文档解决的正是这件事，它是双方共享的工作内存： 一是对 dot 而言，那是一份可随时重读的显式上下文。它不需要靠"回想自己说过什么"来恢复任务状态，打开文件就知道哪一步做完了、哪一步卡住、哪一步等你拍板。任务跨度一长、上下文一被压缩，这个差别会被放大。 二是对你而言，读文档比翻聊天便宜得多。进度、阻塞项、待决策点都在一屏里，这就是原帖说的"不用一直盯着聊天找半天"。 三是交互变简单了。@ 它加新活时不用交代前因后果，因为它手里有那份文档；它汇报也不用写长篇，改一行状态就行。省下的是每一轮的对齐成本。 四是可审计。文档天然是一份变更日志，你能看出它什么时候改了什么、把你的反馈同步到哪了，比听它自我汇报可靠。这点很重要，因为 dot 会主动做事，你要能低成本地核对它做了什么。 顺带说个边界：这招成立的前提是文档得有结构，按"任务、状态、阻塞、下一步"这种状态化的方式写，保持短。要是写成一部长篇日记，那只是把聊天记录换了个地方，重点照样被淹没；需要你判断的决策也得继续由你批，文档不能代替审批。