夜雨聆风最近两年，几乎每个用过大模型的人都在聊天窗口里派过活：帮我写个方案、帮我改段代码、帮我整理数据。聊到第四十轮，方向改了三次，新增了五个要求，模型开始前言不搭后语，你只好新开一个对话，把之前的结论人工复述一遍。那么，究竟是模型不够聪明，还是我们跟它说话的方式从根上就错了？
我的答案是，错误的交互方式影响了模型的能力。而正确的交互方式带来的不是百分之几的改善，是能力数量级的放大。这背后根本的机制只有一句话：你给模型的，终于是结构化的上下文了。
一、聊天的问题不是模型笨，是上下文在腐烂
聊天流的本质，是一条按时序累积的流水账。第三轮的补充推翻了第一轮的要求，第十五轮的口径覆盖了第八轮的口径，但你作废掉的方案、说错的事实、中途放弃的方向，全都还躺在上下文里。模型没有「作废」机制，它分不清哪些指令还有效、哪些早已翻篇，于是每一次生成，都要从全部历史噪声里打捞当前意图。腐烂的上下文，逼着模型在废墟上工作。产出越来越脏、越来越保守，不是它能力不够，是它脚下全是瓦砾。
这些乱象背后共同的病根，是把「一个聊天」当成了「一个工作单元」。聊天是很好的媒介，但它是为「交流」设计的，不是为「工作」设计的。交流可以反复、可以含糊、可以即兴推翻，工作不行——工作需要目标稳定、边界清楚、变更留痕。拿交流的容器去装工作，装得越多，漏得越快。
二、文档交互：聊天负责想清楚，文档负责说清楚，执行器负责做完
那正确的方式是什么？我的答案是把一次工作切成三段，让三种媒介各司其职：讨论用聊天，确认用文档，执行按文档。
具体到我们的实践：派活之前，先把这件事跟模型聊透——比什么维度、给谁看、依据哪些材料、什么时候要；聊清楚之后，让模型把结论整理成一份可以修改的任务说明，写明目标是什么、完成条件是什么、用哪些数据、依赖哪些别的任务、权限到哪一步。人把这份说明逐项审一遍、确认之后，才开始执行。模型永远不能替你按确认键。哪怕你明说「直接开始」，它也必须先把说明摆出来、等你点头。需求边界只能由人划定，因为边界即责任——出了问题，承担责任的必须是确认过边界的那个人，而不是起草说明的模型。
对比一下两种下任务的方式。聊天式下达：模型边执行边猜你的意图，你中途随手一句话就是一次口径变更，它猜测、它返工、你再纠正。文档式下达：等执行开始时，意图已经完整、稳定、可验证，模型的第一步就走在正确的路上。前者把澄清成本摊到整个执行过程里反复支付，后者把澄清成本一次性付在开工之前。先讨论成文档再执行，不是多了一道手续，是把无穷次返工换成了一次确认。
三、模型产出=模型能力*上下文质量*交互结构
为什么敢说「跃迁」？因为这里的数学关系是乘法不是加法。一个模型的有效产出，等于模型能力乘以上下文质量，再乘以交互结构。模型是常量的时候，后两项就是全部的变量——而它们的天花板，比多数人想象的高得多。
我们在执行前会为每个任务重新编译一份结构化的上下文清单：你是谁、有什么权限；这件事的大目标是什么、进行到哪一步；这个任务自己的范围和完成条件；你在讨论里确认过什么（注意，是结构化摘要，不是聊天原文）；你可以引用哪些已完成的结果；以及上一次执行到了哪里。每次开工、每次追加要求、每次暂停恢复，都重新编译一遍，旧的清单立即作废。这份清单里有一条原则，我认为值得所有人抄走：「完整」的意思不是把所有聊天记录塞进去，而是结构化、当前有效、权限之内完整。长对话按摘要加按需检索来组装，绝不每轮重放全量原文。
这条原则同时产生三个好处。省 token ：因为每一个 token 都花在有效信息上，不花在流水账上——同样一件事，聊天流要背着四十轮历史走，结构化清单只带当下的边界。长程任务能一次到位：因为执行器从第一步拿到的就是完整边界，不需要在第 N 轮才发现你第一轮漏说的前提。产出干净：因为它的上下文里没有废案、没有无关闲聊、没有过期口径——没有瓦砾，自然不需要在瓦砾上盖房子。写出来的代码和文档干净，从来不是模型的自律，是上下文的卫生。
四、任务一旦成文，你从监工变回验收者
任务从一段对话变成一份结构化的说明，性质就变了：它有了独立的生命周期——独立的执行会话、独立的上下文、独立的进度存档。一组相关的工作可以拆成几份并行的任务同时跑：收集数据的、分析风险的、起草报告的，互不干扰。隔离是制度性的：其他任务的原始聊天，不会自动进入当前任务的上下文，要共享只能显式声明依赖、共享确认过的摘要。并行不是并发数的问题，是每条工作线都干净地持有自己的边界。
对人的解放更直接。任务跑起来之后，你可以关掉页面去干别的，状态由服务端事件推送，回来时从上次的进度接续。你的注意力不需要一直挂在屏幕上等它问下一句。中途想改需求怎么办？不是往对话框里插一句话，而是追加一条结构化指令——新的要求在安全点生效，原目标不被覆盖，每一次变更都有版本记录。改需求从一个污染事件，变成了一条干净的变更记录。这是聊天形态永远做不到的：聊天里没有「安全点」和「版本」，只有一条越积越长的历史。
五、模型越强，文档交互越值钱
肯定有人会说：模型在变强啊，上下文窗口越来越长，还有了记忆，会自己追问，是不是终有一天不需要人来结构化上下文？我恰好持相反的判断，理由有三。第一，需求边界的确认权天然在人这边——窗口再长，模型也替你决定不了「要什么、不要什么、做到哪算完」，这件事没有技术解，只有确认制。第二， token 和注意力是物理约束，不是能力问题——长窗口不等于免费窗口，塞进去的噪声一样稀释模型的注意力，腐烂上下文的病不会因为窗口变长而痊愈，只会更贵。第三，模型越强，「讨论成文档」的成本越低——澄清、起草、拆解这些活它干得越来越好，人只需要审和确认。所以方向不是文档交互被淘汰，而是它越来越顺手。当然边界也要说清：这套方法适用于长程、可验证、有明确产出的任务——代码、文档、报告、分析。探索、头脑风暴、闲聊，就用聊天，别把生活也文档化。
我们如今做项目的整个流程，就是用文档交互的方式运转的：每个里程碑先冻结一份几百行的执行计划，写清目标、边界和验收门禁，然后交给模型按文档长程实现。几百行的文档换来的是一次到位的实现和干净得多的代码——这件事我们重复了一次又一次，每次都成立。它反过来改变了我的工作习惯：现在我对模型说的最长的一句话，往往是一份文档的名字。跟模型聊天，是交朋友；给模型文档，是派工作。朋友不嫌多，工作要的是漂亮。
本文由 AI 辅助创作，作者进行了实测验证和编辑修改。