Qwen Code 实际发布了什么
两项拉取请求（Pull Request）于 9 月 20 日合并，并在当天下午的 v0.24.2 版本中发布。
第一项变更修改了 /context detail 的输出。现在，属于活动扩展的上下文文件将渲染为扩展名称后跟文件名，格式为 Extension: Report Tools · QWEN.md。没有扩展所有者的文件则保留其原有的路径。官方给出的理由非常直接：以前扩展的上下文文件“显示为安装目录下的一个路径，这无法告诉读者是哪个扩展在为此买单”。
第二项变更修改了扩展提供指令的方式。扩展现在可以贡献路径条件规则（path-conditional rules），这被描述为作者“将特定于文件的指导移出始终加载的上下文文件”的一种方式，以便在“访问匹配的文件时注入，而不是在启动时发送”。与此同时，扩展指南现在完整地载入了关于成本的那句话：
“扩展的上下文文件会被拼接进该扩展处于活动状态的每个会话的每次请求的系统提示词中，无论当前的工作是否与您的扩展有关 —— 这里没有相关性过滤，也没有大小限制。”
这句话背后的测量数据可以在拉取请求引用的跟踪议题（tracking issue）中找到。在一个抽样会话中，“九个扩展的上下文文件总计达到了 9,989 个 token”。相比之下，同一会话的技能（skill）列表包含 84 个技能，总计仅 4,620 个 token，因为技能是按名称和描述列出的，只有在被调用时才会加载其主体内容。
此外还新增了一项警告。当总体的常驻上下文超过根据模型窗口计算出的阈值（上限为估算的 10,000 个 token）时，Qwen Code 现在会发出警告。拉取请求对该警告的性质进行了谨慎的说明：“这是一个警告，而不是截断或针对单个扩展的配额限制。”
这改变了什么，又没有改变什么
它本身不会减少任何内容。拉取请求直接指出：“只有当扩展作者实际将适当的指导移入其中时，提供条件替代方案才能减少常驻内容。”机制是新的，但迁移并不是自动的。用作者自己的话来说，“现有的上下文文件不会自动迁移。”
因此，在您更新的当天，您安装的每个扩展所贡献的内容与前一天完全相同。改变的是，您现在可以看到逐项列出的清单，而且扩展作者现在有了一个更好的地方来放置这些内容。
还有两个细节值得仔细阅读，因为它们描述的是行为而非意图。
扩展规则必须包含 paths: 前置元数据（front-matter）条目。没有该条目的规则“将被跳过并发出警告” —— 它既不会默默变成常驻规则，也不会无故消失。规则会“按扩展所有者进行标记”，这与应用在全新界面上的归属思路一致。
此外，在信任处理上存在一种不对称性，拉取请求对此进行了坦率的说明：“已安装的扩展规则不受工作区信任限制，这与现有的扩展上下文边界一致；而项目规则仍保留其信任限制。”您安装的扩展被视为您已经担保过的内容；而您刚刚打开的仓库中的规则文件则不然。这是一个刻意设计的边界，而不是疏忽，这也是为什么扩展指南要专门花一个段落来讨论到底什么才属于扩展的原因。
人们会从中得出什么结论，以及为什么不应该这样想
流传最广的第一种解读将是“Qwen Code 添加了一个显示扩展成本的命令”。这虽然是事实，但并没有太大用处，因为该命令早已存在。/context detail 已经列出记忆文件有一段时间了，每行一个文件。它以前无法做到的是指出某一行属于哪个扩展。
第二种解读更具误导性：认为这个版本让扩展变得更便宜了。事实并非如此。条件规则途径虽然对扩展作者开放，但在作者将指导移入其中之前，您已有的文件仍会继续被拼接。除了停用扩展之外，您在自己的项目中做任何事情都无法改变这一点。
第三种误读值得专门用一个段落来讨论。人们很容易得出结论，认为常驻指令才是问题所在，所有内容都应该变成条件式的。但指南并没有这么说。它建议“将上下文文件保留为少数始终正确的客观事实 —— 扩展的身份、其词汇表、硬性约束 —— 并将场景指导放入技能中”。有些事实确实是始终正确的。失败模式并不是因为存在常驻上下文，而是因为场景指导被当作始终正确的事实来归档，而系统中却没有任何机制来提醒任何人。
这种区别与为什么长上下文窗口不等于记忆背后的道理是一样的：更大的窗口改变的是能容纳什么，而不是什么应该留在那里。
解决方法：阅读逐项清单，然后决定哪些事实是始终正确的
您无法代表扩展作者去迁移扩展的上下文文件。但您可以找出您正在承载的内容，决定您自己的哪些内容属于常驻层，并移动其余内容。
步骤 1：在进行任何更改之前，先获取逐项读取结果
在您实际工作的项目中开启一个会话，进行一轮对话，然后运行详细的上下文细分。特别阅读记忆文件（memory-files）部分。在 v0.24.2 之后，每个属于扩展的文件都会标明其扩展名称，因此您得到的是所有者列表，而不是路径列表。
将该列表记录在工具之外的某个地方，并在每个名称旁写上文件大小。您稍后将以此进行对比，而细分本身是一个会随着会话变化的实时读取结果。
此时通常会有两件事让人感到意外。分布是不均匀的 —— 在抽样会话中，两个扩展大约占了扩展总量的三分之一。而且贡献最多的扩展往往很少是使用最频繁的扩展。
步骤 2：将您自己始终正确的事实与场景指导分离开来
现在看看属于您的那些行：您项目自己的指令文件以及您从中引用的任何内容。将每一行分类到以下两个存储桶之一。
始终正确：项目的名称和目的、构建和测试命令、无论您接触什么都适用的约束、工具可能会搞错的词汇。这些属于常驻文件，而且它们通常比人们预期的要短。
仅有时正确：如何开发支付模块、迁移目录的规范、发布清单。这些属于场景指导。Qwen Code 自己的建议是使用技能（skill），技能按名称和描述列出，并在调用时加载其主体，而受文件路径限制的技能“在触及匹配的文件之前甚至不会被列出”。
这种整理是没人能替您完成的，因为它取决于您实际开发的内容。这也是一个能持续带来回报的步骤，因为正是这种整理促使智能体去阅读您的指令文件 —— 相比于冗长的文件，一个包含真正始终正确事实的简短文件能更可靠地被遵循。
步骤 3：对照您记录的列表重新阅读细分明细
在同一个项目中再次运行详细细分，并与您在步骤 1 中记录的内容逐行进行对比。您需要检查两件事：您移动的行已从常驻层中消失，以及扩展行保持不变（因为您没有动过它们，它们不应该发生变化）。
如果显示了总体警告，请注意是哪些所有者导致了该警告。这就是值得提交给扩展作者的列表，而且现在这是一个您可以精确陈述而不是模糊描述的列表。
保留这份书面记录。任何已安装扩展的下一次发布都可能在不通知您的情况下更改其上下文文件，而发现这一点的唯一方法就是拥有昨天的数字。
在 MemoryLake 中进行设置
步骤 2 中的整理会产生一些持久的东西：一组跨会话正确的简短事实，以及一组仅在特定情况下正确的较长事实。MemoryLake 是一个保存第一组事实的地方，这样即使您下个月更换了工具，它们依然存在。
您可以用自己的语言亲自编写这些条目。不会从 Qwen Code 自己的记忆文件夹、扩展的安装目录或任何厂商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并在控制面板中生成一个密钥。该密钥允许智能体读取您编写的条目，并且它的作用域是您的工作区，而不是任何单一的编辑器或 CLI。
步骤 2：上传您的第一批记忆
从上面步骤 2 中始终正确的列表开始：项目的目的、命令、无论您接触什么都适用的约束。保持每个条目只有一个事实，用您对新同事说话的方式来表述。
步骤 3：连接您的 AI 和智能体
将您的智能体指向该工作区。这样，无论您在哪里工作，都可以使用这组简短的事实，这意味着项目指令文件可以保持简短，而不会在您更换工具时丢失这些事实。
这在实践中改变了什么
实际的转变是从一个比例变成了一个列表。在此版本发布之前，对于“我的提示词中有多少是扩展”的诚实回答是一个没有附带名称的数字。现在，它是一组您可以阅读的所有者，以及一组您可以独立于自己的文件进行操作的对象。
这比听起来更重要，因为这两组内容有不同的解决办法。您自己的常驻内容今天就可以由您来缩减。而扩展的内容则需要作者来移动，您能做的最有效的事情就是准确地告诉他们是哪个文件以及有多大。
它还改变了不断增长的上下文账单的表现形式。一个看起来几乎没有占用其窗口的会话，在每一次请求中可能仍然承载着一个巨大的固定前缀，因为前缀是绝对的，而窗口读取是相对的。那些只关注 token 使用量而不关注其构成的团队，一旦能够看到逐项列出的明细，往往会首先发现这个固定部分，而且节省的成本来自于您每次停止发送的内容，而不是来自于更大的窗口。
还有一个值得说明的后果：如果您在工具之间迁移，始终正确的那组事实是可以干净利落地迁移的部分。场景指导通常是用特定工具的限制机制的词汇来表达的，这就是为什么它很少能在迁移中完好无损地保存下来 —— 这与模型更改要求您刻意迁移上下文，而不是假设它会自动跟随是同一个道理。
保持常驻层精简的最佳实践
在安装任何扩展前后进行读取对比。 逐项细分的运行成本很低，而且它是安装增加了什么内容的唯一记录。没有“之前”的数据，“之后”的数据就无法说明任何问题。
将始终正确的列表写在工具无法重写的地方。 扩展文件会在更新时发生变化。您自己的文件会在您编辑时发生变化。在这两者之外保留一份记录，才能让您分辨出是哪一个发生了变化。
优先选择仍能触发的最窄载体。 受文件路径限制的技能在触及匹配文件之前不会被列出。没有限制的技能按名称和描述列出。而上下文文件则总是完整发送。该列表中的每一步往下都会增加成本，因此请从最底部开始，只有当某些内容确实每次都适用时才往上移动。
根据扩展在提示词中留下的常驻内容来评估它，而不是根据它的功能列表。 一个每周只做一次有用事情却贡献了冗长上下文文件的扩展，在两次使用之间的每一次请求中都在支付“租金”。有时这是一笔公平的交易，但它应该是一个经过权衡的决定。
向作者索要特定的文件。 现在行已经被标记了，请求可以指明扩展名称和大小，而不是描述一个笼统的问题。作者们有文档记录的途径将指导移入条件规则中，而一份精确的报告正是让使用该途径变得有价值的原因。
在目录更改后重新检查。 当扩展目录刷新时，已安装和处于活动状态的内容可能会在没有可见事件的情况下发生变化，这与技能在原本应该存在的目录中悄然缺失属于同类问题。
结论
全新的归属行是输出上的一个微小变化，却是可认知信息上的一个巨大飞跃。有史以来第一次，“哪个扩展把这个放进了我的提示词”的答案是一个名称而不是一个路径，而曾经推荐这种高成本架构的指南现在也说明了其代价。
这些本身并不能缩减任何内容。条件规则途径取决于扩展作者是否使用它，而您自己的常驻文件取决于您是否对其进行整理。该版本带给您的是读取结果，而您记录下来的读取结果，决定了您的账单是只能用来争论，还是可以逐项核对。
从细分明细开始，将您自己的内容整理为“始终正确”和“有时正确”，并将始终正确的那组内容保存在一个比当前工具更持久的地方。您可以调用的技能并不是记忆，在将所有内容归为一类之前，这一点值得明确，您忘记了正在发送的上下文文件同样也不是记忆。