1. 为什么「任务对话上下文」是 WorkBuddy 最容易被低估的能力很多人第一次用 WorkBuddy注意力都放在「它能帮我写什么」上比如生成一段代码、整理一份文档、跑一个自动化任务。但真正用了一段时间之后你会发现决定体验上限的往往不是模型本身有多强而是任务对话上下文管理得好不好。这个词听起来有点抽象我换个说法它决定了 WorkBuddy 在跟你协作时到底「记得住多少事」「记得住哪些事」「什么时候该忘掉哪些事」。我在实际使用中踩过最典型的一个坑就是让 WorkBuddy 连续处理一个多步骤任务前几步都正常到第四步突然开始答非所问甚至把前面已经确认过的参数改掉了。当时我以为是模型不稳定后来才意识到问题出在上下文被压缩compact之后关键信息丢失了。这个经历让我彻底改变了对「上下文」的看法——它不是后台自动帮你搞定的事情而是需要你主动设计和管理的东西。所谓任务对话上下文简单理解就是 WorkBuddy 在一次任务会话中能够「看到」的全部信息集合。它包括你输入的指令、它之前的回复、你上传的文件内容、工具调用的返回结果以及系统自动注入的一些背景信息。这些内容加起来不能无限增长因为底层模型有一个硬性上限也就是大家常说的Context Window上下文窗口。窗口满了怎么办要么截断要么压缩要么丢弃早期内容。而这个过程恰恰是很多「莫名其妙」问题的根源。这篇文章适合三类人看第一类是把 WorkBuddy 当日常生产力工具、但总觉得它「时灵时不灵」的用户第二类是正在做多步骤自动化任务、需要稳定复现结果的进阶用户第三类是想搞清楚 Token、compact、上下文窗口这些概念到底怎么影响实际使用的技术型用户。我会从底层机制讲到实操技巧尽量把每个「为什么」都说明白让你看完之后能自己判断问题出在哪、该怎么调。2. 上下文窗口、Token 与 compact三个概念的真实关系2.1 Token 不是「字数」而是模型的最小计费与处理单位很多人把 Token 直接等同于字数这在中文场景下误差很大。Token 是模型处理文本的最小单位英文里一个单词可能是一个 Token也可能被拆成几个中文里一个字通常对应一到两个 Token具体取决于分词方式。你可以把它理解成「模型眼里的文字颗粒度」。为什么这个区别重要因为上下文窗口的大小是按 Token 算的不是按字数算的。你觉得自己只写了几百字但如果里面夹杂了大量代码、符号、JSON 结构Token 消耗会远超预期。我做过一个粗略统计一段 500 字的中文说明大约消耗 700 到 900 个 Token而同样长度的代码片段可能消耗 1500 个 Token 以上。这意味着当你往对话里粘贴大段代码或日志时上下文消耗速度会明显加快。提示如果你发现 WorkBuddy 在处理某个任务时「记性变差」第一件事不是怀疑模型而是估算一下当前对话的 Token 占用。代码、表格、日志这三类内容是 Token 消耗大户。2.2 Context Window 是「工作台面」不是「仓库」Context Window 常被翻译成上下文窗口我更愿意把它比作一张工作台面。台面就那么大你同时摊开的材料越多每份材料能占的面积就越小。模型在生成每一次回复时都需要把「当前台面上所有材料」重新读一遍然后基于这些材料做判断。这里有个关键认知上下文窗口不是仓库它不会帮你长期保存历史。超出窗口的内容要么被截断要么被压缩成摘要。很多人误以为「我之前说过的它肯定记得」实际上如果那段内容已经被挤出窗口或者被 compact 成了模糊的摘要它就等于「没说过」。2.3 compact 是「压缩收纳」代价是细节丢失compact 是 WorkBuddy 在上下文接近上限时采取的一种策略把较早的对话内容压缩成更短的摘要腾出空间给新内容。这个机制本身是合理的否则长任务根本没法继续。但问题在于压缩是有损的。我遇到过好几次这样的情况前面明确指定了「输出格式必须是 JSON字段名用下划线」经过一次 compact 之后WorkBuddy 开始输出驼峰命名的字段。原因就是压缩时这类细节约束被当作「次要信息」丢掉了。所以我的经验是关键约束不要只靠上下文记忆要用可复现的方式固定下来比如写进自定义指令或者在每个关键步骤重新声明。概念本质超限后的行为对使用的影响Token文本处理最小单位不涉及决定上下文消耗速度Context Window单次可处理的信息总量截断或压缩决定「记得住多少」compact上下文压缩策略有损摘要决定「记得准不准」理解了这三者的关系后面所有的实操技巧就都有了落脚点。接下来我讲具体怎么管。3. 长任务中上下文失控的四种典型表现与排查链路3.1 表现一任务后期开始「遗忘」早期约束这是最常见的症状。任务开始时你说了五条规则跑到第七八步WorkBuddy 只遵守其中两三条了。很多人第一反应是「模型变笨了」其实大概率是早期约束被 compact 掉了。排查链路是这样的先回看对话确认约束是在哪一步之后开始失效的然后检查那一步前后是否有大量内容注入比如粘贴了长日志如果确认是 compact 触发点解决方案不是重开对话而是在当前步骤重新声明关键约束。我通常会在关键节点加一句「重申一下本次任务全程必须遵守1... 2... 3...」成本很低效果立竿见影。3.2 表现二工具调用结果被「稀释」WorkBuddy 在执行任务时会调用各种工具比如读文件、跑命令、查数据。这些工具的返回结果会进入上下文。如果一次返回内容特别大它会把之前的对话挤出去。我见过最夸张的一次是一个命令返回了几千行日志直接把前面所有任务描述都挤没了WorkBuddy 当场「失忆」。应对方法很直接不要让工具返回原始大块内容。能在工具侧做过滤就先过滤只把关键结果喂给上下文。比如查日志时先用 grep 缩小范围读文件时只读相关段落。这个习惯能极大延长上下文的「有效寿命」。3.3 表现三多轮修改后版本混乱做迭代式任务时比如反复修改一份文案或一段代码容易出现「它改着改着改回了旧版本」。这是因为旧版本和新版本同时存在于上下文中compact 之后模型分不清哪个是最新的。我的做法是每次大改之后主动说一句「以上一版为准之前的版本作废」。这句话会作为一个强信号留在近期上下文里降低版本混淆的概率。更好的做法是把当前确认版本单独存成文件后续修改都基于文件内容而不是基于对话历史。3.4 表现四compact 触发后风格突变有些用户会发现长对话进行到某个点WorkBuddy 的回复风格突然变了变得更简短、更笼统。这通常就是 compact 生效了细节被摘要替代。这不是故障而是机制使然。如果你需要风格稳定最有效的办法是把风格要求写进自定义指令而不是依赖对话历史。自定义指令属于系统层面的固定注入不会因为 compact 而丢失。这也是为什么我强烈建议每个长期使用 WorkBuddy 的人都花时间打磨一套自己的自定义指令。注意排查上下文问题时不要急着重开对话。重开意味着所有上下文清零你之前积累的任务状态也没了。先判断是「约束丢失」还是「内容被挤」再针对性补救效率高得多。4. 把上下文当资源来管理我的五条实操原则4.1 原则一任务开始前先「立规矩」我现在养成了一个习惯任何超过三步的任务开头一定先写清楚目标、约束、输出格式、验收标准。这四样东西写全了后面能省掉大量来回。尤其是输出格式一定要在开头定死因为格式类约束最容易被 compact 吃掉。举个例子我让 WorkBuddy 整理数据时开头会写「目标把输入整理成表格约束只保留有效行空值填 N/A输出格式Markdown 表格列顺序固定为 A、B、C验收行数与有效数据条数一致。」这样写下来即使中途 compact我也能快速对照检查它有没有跑偏。4.2 原则二大内容「先切后喂」不要把一整份长文档直接丢进对话。正确做法是先切分按需喂入。比如一份 50 页的文档先让 WorkBuddy 处理第 1 到 5 页产出结果后再处理下一段。这样每一段的上下文都是干净的不会互相干扰。这个原则在处理代码库时尤其重要。我从不一次性把整个项目贴进去而是先说明项目结构再按模块逐个处理。这样既省 Token又能让 WorkBuddy 对每个模块保持高专注度。4.3 原则三关键状态「外置存储」对话上下文是易失的文件是持久的。所以我会把任务的关键中间状态写到文件里比如「当前进度」「已确认参数」「待办事项」。每次继续任务时先让 WorkBuddy 读这个文件而不是依赖它「记得」。这个做法看起来多了一步但稳定性提升非常明显。尤其是跨天继续的任务第二天重开对话只要读一下状态文件就能无缝接上完全不受之前上下文丢失的影响。4.4 原则四定期「主动 compact」既然 compact 迟早会发生不如主动控制它什么时候发生、压缩什么内容。我的做法是在一个阶段性任务完成后主动说「总结一下当前已完成的内容和关键结论后续基于这个总结继续」。这样压缩出来的摘要是我认可的而不是系统随机丢的。主动 compact 的另一个好处是你能顺便检查一下 WorkBuddy 对任务的理解有没有偏差。如果它的总结跟你预期不一致说明前面就有理解问题早发现早纠正。4.5 原则五给上下文「留白」不要把上下文塞得太满。我一般会让有效内容占用控制在窗口的六七成左右留出余量给工具返回和后续对话。塞满的上下文就像塞满的硬盘任何新操作都会触发清理而清理的时机和内容你控制不了。留白的另一个意义是给模型「思考空间」。上下文太满时模型需要在大量信息里找重点容易顾此失彼。适当留白反而能让它抓住核心。原则解决的问题具体动作先立规矩约束丢失开头写清目标、约束、格式、验收先切后喂内容挤占长文档分段处理按需喂入外置存储状态易失关键进度写入文件续接时先读主动 compact压缩失控阶段完成后主动总结再继续留白上下文过载有效内容控制在六七成5. 自定义指令与上下文的分工哪些该固定哪些该临时说5.1 自定义指令适合放「长期不变」的要求自定义指令是 WorkBuddy 里一个非常实用的功能它相当于给你的所有对话预设一套背景规则。适合放进去的内容包括你的身份和偏好、常用的输出格式、固定的术语规范、默认的语言风格。这些东西每次对话都需要放进自定义指令就不用反复说。我自己的自定义指令里有一条是「涉及代码时默认给出可运行的最小示例不要省略关键导入」。这条规则帮我省了无数次补充说明。因为它是系统级注入不会因为 compact 而消失稳定性远超对话里临时说的要求。5.2 对话上下文适合放「本次任务特有」的信息跟自定义指令相反对话上下文适合承载一次性的、任务特有的信息。比如这次要处理的具体数据、这次的特殊约束、这次的目标。这些内容不需要长期保留任务结束就可以丢。分清这两者的边界能显著减少上下文浪费。很多人把长期规则也写在对话里每次都要重复既费 Token 又容易漏。反过来把一次性信息写进自定义指令又会污染所有对话。这个分工想清楚了使用体验会顺畅很多。5.3 冲突时以谁为准偶尔会遇到自定义指令和对话要求冲突的情况。比如自定义指令说「输出用中文」但这次任务你要求「输出英文」。这种情况下对话里的明确要求通常优先级更高因为它是针对当前任务的即时指令。但为了保险我建议在冲突时明确说一句「本次忽略自定义指令中的语言设置改用英文输出」把优先级讲清楚避免模型纠结。5.4 一个容易被忽略的细节自定义指令也会占上下文自定义指令虽然稳定但它同样占用上下文窗口。如果你的自定义指令写得非常长等于每次对话一开始就消耗了一大块空间。所以自定义指令要精炼只放真正高频、真正必要的规则。我见过有人把自定义指令写成几千字结果每次对话可用空间都被压缩得不偿失。提示定期回顾你的自定义指令删掉那些已经内化、或者很少触发的规则。保持精简才能让上下文空间用在刀刃上。6. 从入门到进阶不同阶段的上下文使用策略6.1 新手阶段先学会「说清楚」刚上手 WorkBuddy 的人最大的问题往往不是上下文管理而是指令本身太模糊。这个阶段不用急着研究 compact 和 Token先把「说清楚」这件事做好。目标是什么、要什么格式、有什么限制三句话说清楚体验就会好一大截。我建议新手从短任务练起比如让它整理一段文字、生成一个简单脚本。短任务上下文压力小容易看到完整效果也容易建立对「它怎么理解我」的直觉。等短任务稳定了再逐步加长。6.2 熟练阶段开始关注「任务拆分」当你开始做多步骤任务时就要有意识地把大任务拆成小步骤。每一步都有明确的输入和输出步与步之间通过文件或明确的状态传递衔接。这样做的好处是每一步的上下文都是独立的、干净的不会互相污染。拆分粒度怎么定我的经验是一步只做一件事且这一步的产出可以独立验证。如果一步里既要读数据又要分析又要输出那大概率会出问题。拆得细一点看起来麻烦实际返工少。6.3 进阶阶段主动设计「上下文生命周期」到了进阶阶段你不再是被动应对 compact而是主动设计整个任务的上下文生命周期。什么时候注入信息、什么时候清理、什么时候压缩、什么时候外置全都在你的掌控之中。这个阶段我常用的一个模式是「三段式」准备段负责收集和整理输入执行段负责核心处理收尾段负责汇总和输出。每段之间做一次主动 compact把上一段的结论提炼出来带入下一段。这样整个任务跑下来上下文始终清爽结果也稳定。6.4 不同任务类型的上下文策略对比任务类型上下文特点推荐策略单次问答消耗小无压缩直接问无需特殊管理文档处理输入大易挤占分段喂入及时外置中间结果代码开发结构复杂Token 密集按模块处理关键约束写进自定义指令多步自动化步骤多易遗忘状态外置阶段主动 compact长期迭代跨会话易混乱版本文件化每次基于文件继续这张表是我自己总结的实际用的时候不用死记关键是建立「不同任务用不同策略」的意识。很多人所有任务都用同一种方式结果就是简单任务浪费、复杂任务翻车。7. 几个真实踩坑案例与修复过程7.1 案例一日志淹没上下文导致任务中断有一次我让 WorkBuddy 帮我排查一个构建问题它调用命令跑了一次构建返回了将近两千行日志。结果下一步它就开始答非所问完全忘了我们在排查什么。我当时的排查过程是先确认任务描述还在不在——发现已经被挤出窗口然后重新用一句话概括任务目标并让它只关注日志中的错误行最后把日志过滤后重新喂入。问题当场解决。这个坑教会我一件事工具返回的内容要可控。后来我在让 WorkBuddy 跑命令时都会加上过滤条件比如只看错误级别、只取最后若干行。这样既保留了关键信息又不至于淹没上下文。7.2 案例二compact 后格式约束失效还有一次是生成一批结构化数据开头明确要求了字段命名规范。跑到中途输出格式突然变了。我回看发现正好在那一步之前上下文触发了压缩。修复方法很简单在压缩后的第一步重新声明格式要求。但更根本的解决办法是把格式规范写进自定义指令从此再没出过这个问题。这个案例说明越是机械、越是不能出错的约束越应该放在稳定的位置而不是依赖对话记忆。对话记忆适合承载灵活的、临时的信息不适合承载硬性规范。7.3 案例三跨会话续接时状态丢失跨天继续一个任务时我重开了对话结果 WorkBuddy 完全不记得昨天的进度。这个其实不算 bug因为新对话本来就没有旧上下文。但从那以后我养成了写状态文件的习惯。每次收工前让它把当前进度、已确认结论、待办事项写进一个文件。第二天开新对话第一句就是「读一下这个文件我们继续」。这个习惯带来的稳定性提升是巨大的。现在我做长任务基本不担心中断因为状态都在文件里随时可以接上。7.4 案例四多版本并存导致改回旧版迭代修改文案时我遇到过改到第五版它突然输出回第二版的情况。原因是几个版本都在上下文里压缩后模型分不清哪个最新。解决办法是每次大改后明确声明「以此版为准之前作废」并且把最新版单独存文件。后来我干脆改成「基于文件修改」对话里只讨论改什么不保留完整历史版本问题彻底消失。这几个案例的共同点是问题看起来像「模型不行」实际都是上下文管理的问题。一旦你建立起上下文管理的意识大部分「玄学问题」都会变成可解释、可修复的工程问题。8. 关于 Token 用量与成本的一点个人经验Token 用量直接关系到使用成本和响应速度这点很多人到用量上来了才意识到。我的经验是控制 Token 用量最有效的三个动作是精简自定义指令、过滤工具返回、及时外置状态。这三件事做好用量能降下来一大截而且不影响效果。另外不同任务对 Token 的敏感度不一样。短问答无所谓随便用长任务就要精打细算。我一般会在长任务开始前心里估一下大概要跑多少轮、每轮大概多少 Token心里有数就不容易失控。还有一个细节中文的 Token 效率其实不如英文。同样意思的内容英文往往占用更少 Token。所以在写自定义指令这种长期占用的内容时如果英文表达更简洁用英文反而更划算。当然这要看你的实际习惯不必强求。最后分享一个我自己的小技巧我会定期回看自己的历史对话看看哪些地方 Token 浪费得厉害。看多了就会发现规律比如某些习惯性的冗余描述、某些不必要的重复确认。改掉这些习惯用量自然就下来了。上下文管理这件事说到底是一种使用习惯的养成工具本身提供的机制是固定的怎么用出效果全在细节里。