AI 概念图知识总量没有消失进入本轮任务的只是一条经过筛选的上下文流。摘要给 AI 助手一次性塞入所有规范看上去最稳妥实际却把无关 API、部署规则、前端约束和发布门禁放进同一竞争区。本文用当前工作区 62 个 Skill 入口做一次可复现的体积基准全量为 740,648 字节按文章发布任务路由后为 80,165 字节减少 89.18%任务词密度提高到 2.16 倍。这个结果不等于“准确率提升”但足以说明上下文应该被路由而不是被堆满。●① 大上下文不等于有效上下文模型拥有更长的输入窗口只表示它能接收更多内容不表示每一条内容都对当前任务有帮助。一个“分析平台后写技术文章并发布”的请求如果同时加载数据库建模、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 的基准给出的不是“少读文档”的口号而是一条可复现的工程边界保留完整知识库按任务加载最小充分集再用硬门补上安全与验收。上下文越大不一定越差没有路由的大上下文才最容易把有效知识变成噪声。结论上下文工程的目标不是追求最少字节而是让每一段进入推理窗口的内容都有明确职责提供事实、改变决策、约束风险或验证结果。