AI 概念图：知识总量没有消失，进入本轮任务的只是一条经过筛选的上下文流。

●① 大上下文不等于有效上下文

模型拥有更长的输入窗口，只表示它能接收更多内容，不表示每一条内容都对当前任务有帮助。一个“分析平台后写技术文章并发布”的请求，如果同时加载数据库建模、Unity、打印、OCR、工作流、商城安装和移动端组件规范，真正相关的约束会被大量合法但无关的信息包围。

问题通常表现为三类：入口规则被后面的细节稀释；两个领域的“强制”语句被错误地放在同一优先级；旧快照与实时状态混在一起。它们都不是模型不够聪明，而是上下文工程没有把任务边界说清楚。

AI 概念图：大量规范同时进入推理核心时，有用信号仍然存在，但查找成本与冲突面一起扩大。

●② 我怎样构造这次基准

样本不是手写的虚拟文档，而是当前工作区microi.skills下真实存在的 62 个SKILL.md入口。对照组读取全部入口；路由组只读取本任务实际要求的 7 份文件：工作区总约定、内容发布入口，以及跨客户端质量、技术文章、通用排版、公众号排版和恢复门禁五份参考。

脚本逐文件统计 UTF-8 字节、行数、标题、代码块和任务词命中，并把原始结果保存为 JSON。为了避免“关键词多就是准确”的偷换，结果里明确写了三条边界：只衡量体积和任务词密度，不衡量模型正确率；路由集合只对当前任务有效；换任务必须重新计算。

node evidence/benchmark-context-routing.mjs \ evidence/context-routing-results.json

这条命令没有调用模型，也没有访问生产数据。它做的是最基础、也最容易复核的一件事：确认我们究竟给助手放进了多少字节、多少行，以及其中多少内容与任务词直接相关。

●③ 结果：不是少一点，而是少一个数量级

本地验证截图：结果由工作区文件直接计算，显示全量入口与按需路由的体积差异。

本地结果显示：62 个入口文件合计 740,648 字节、10,453 行、727 个标题和 221 个代码块；7 份路由文档合计 80,165 字节、868 行、59 个标题和 28 个代码块。字节减少 89.18%，行数减少 91.70%，文件数减少 88.71%。

同一组任务词在全量入口中的密度为每 10KiB 40.19 次，在路由集合中为 86.61 次，倍率为 2.16。这里的“密度”只表示相关词更集中，不代表模型一定答得更对；它是上下文纯度的工程指标，不是智能评分。

{ "all": { "files": 62, "bytes": 740648, "lines": 10453 }, "routed": { "files": 7, "bytes": 80165, "lines": 868 }, "byteReductionPercent": 89.18, "signalDensityMultiplier": 2.16 }

●④ 为什么全量加载容易制造假冲突

完整 Skill 库里的每条规则都有适用条件。例如后端安全规则、移动端视觉规则和文章发布规则都可能写着“必须”，但它们约束的是不同对象。如果把 62 个入口平铺成一段没有层级的提示，模型需要先自行猜测哪些“必须”属于当前对象。

另一个风险是时效性。源码中的稳定协议适合直接读取，在线帐号、模型额度、发布 Schema 和公开页面状态则必须实时回读。全量上下文若夹带上次任务的帐号清单，模型很容易把历史事实当成当前事实。路由不只是在减字节，也是在把“稳定知识”和“实时状态”分开。

• 稳定层：工作区约定、API 签名、文件归档结构、安全边界。
• 任务层：本轮文章类型、排版标准、素材数量、发布变体。
• 实时层：当前帐号、当前 Schema、额度、任务终态与公开链接。

把三层拆开以后，每次执行都要回答两个简单问题：

• 哪些规则是本任务改变决策所必需的，必须在创作前加载？
• 哪些信息只有实时查询才可信，不能从旧文章或上次发布记录里复制？

●⑤ 入口Skill应该像目录，而不是百科全书

一个好入口先回答三件事：这项能力何时触发；有哪些不可越过的硬门；遇到不同分支应读取哪份参考。只有被选中的参考才进入当前上下文，其余文件仍然留在知识库里，随时可以被下一种任务使用。

function buildContext(task) { const entry = loadSkill(classify(task)) const refs = entry.routes.filter(route => route.matches(task)) return [workspaceRules(task), entry, ...refs.map(load)] }

这段伪代码的重点不是关键词匹配，而是“入口先行、分支后读”。入口可以要求完整读取；参考文件也要完整读取；真正被避免的是把所有不相关入口提前展开。

AI 概念图：同一知识库保留全部模块，当前任务只点亮经过入口判定的七个节点。

●⑥ 路由之后仍然需要硬门

减少上下文不能牺牲安全。以 Microi吾码AI 的内容发布为例，路由组仍然保留了恢复门禁、跨客户端质量契约和两套视觉排版规范。它们负责阻止重复正式提交、Markdown 泄漏、移动端文字墙、错误图床以及“任务已创建就等于发布成功”等常见问题。

所以正确的优化顺序不是删规则，而是把规则分成“入口必读、分支必读、实时获取、结果验证”四类。只要一条规则影响不可逆写入、付费调用或公开发布，它就应该留在硬门里，而不是依赖模型记忆。

●⑦ 怎样判断路由有没有过度裁剪

可以用四个问题做发布前检查：任务中的每个名词是否有明确事实源；每个外部写入是否有幂等与回读；每个公开断言是否有证据等级；每个视觉变体是否有独立门禁。如果任何一项找不到归属，就说明路由集合还缺文件。

反过来，如果一份文档既不改变决策、也不提供接口、证据或门禁，它就不应在本轮提前加载。它可以保留在索引里，等任务真正触发时再读。

保留：会改变决策、调用方式、风险边界或验收结果的规则 延迟：只在特定分支出现时才需要的详细参考 实时：帐号、额度、Schema、任务状态、公开页面 排除：与当前对象和交付边界无关的能力说明

●⑧ 结论：把上下文当成运行时依赖

软件不会把仓库里所有依赖都塞进一次函数调用，AI 助手也不该把所有知识都塞进一次推理。Skill 库像依赖仓库，入口像模块清单，参考路由像动态导入，实时回读像运行时配置，验证脚本则像测试。

这次 62 对 7 的基准给出的不是“少读文档”的口号，而是一条可复现的工程边界：保留完整知识库，按任务加载最小充分集，再用硬门补上安全与验收。上下文越大不一定越差；没有路由的大上下文，才最容易把有效知识变成噪声。