Prompt 组装流水线：槽位设计、注入时序、为什么这个顺序
Prompt 组装不是 5 种"拼接字符串的方式"，是槽位体系：谁在什么位置注入什么内容，顺序决定了缓存命中率、行为覆盖关系和调试难度。核心原则就一条——会变的内容不进 System Prompt。 某实现 用 9 槽位（身份→平台→环境→Skill→记忆→上下文→纪律→模型策略→通用指导），Claude Code 把会变的东西放进 Attachment，某编码助手 按变化速度分 5 层注入——它们都在回答同一个问题：每段内容应在哪一层、什么时机、什么顺序注入，才既不破坏 Cache 又让 LLM 正确理解。
1x2x
0/14 · 待播放
输入源 → PromptBuilder 组装 → 槽位1-3(稳定前缀) → 槽位4-6(会话级) → 槽位7-9(recency) → 发给 LLM
光点 = 当前环节 · 顺序决定缓存命中率/行为覆盖/调试难度
某宿主 9 槽位（Context → String 纯函数）—
1identitySOUL.md 人设几乎不变
2platform平台适配几乎不变
3environmentOS/CWD/Shell几乎不变
4skillsSkill 索引安装/卸载时变
5memoryMEMORY.md对话后可变
6contextFilesAGENTS.md项目变更时
7discipline工具使用纪律框架升级
8modelStrategy模型策略切模型时
9guidance通用指导框架升级
就绪点 ▶ 播放，看 Prompt 组装流水线的槽位设计与注入时序。Prompt 组装
⚡ 运行时动作：正在发生什么💡 知识讲解：为什么这么设计
Prompt 组装日志核心原则：会变的内容不进 System Prompt
知识点一句话总结：Prompt 组装 = 槽位体系，核心原则：会变的内容不进 System Prompt。9 槽位顺序设计三件事：槽位 1-3（身份/平台/环境）放前面——几乎不变 → 作 Cache 前缀 → 高命中率；槽位 4-6（Skill/记忆/上下文）放中间——会话级变化，不能放最前面破坏前缀；槽位 7-9（纪律/模型策略/指导）放最后——recency bias 让 LLM 对最后读到的印象最深。LLM 没有"后面的覆盖前面"的硬语义，只有统计倾向的 recency bias——所以真正的硬约束不在 Prompt 里，在 frontmatter（allowed-tools 在工具网关拦截）。Claude Code 走相反的路：会变的东西移出 System——Skill 列表放 Attachment（user message 的 system-reminder），System 段保持逐字节不变 → 断点被推到整条请求最尾部 → 旧前缀继续命中，只为尾部增量付全价（代价：Attachment 本身每轮都算新增，只适合变化频繁但体量小的信息）。一切判据只有一条：从第 0 个 token 起逐字节相同的那一段能复用，字段边界在服务端不存在，位置决定损失。工具定义虽是独立字段，序列化后排在大段文字之前——MCP Server 连接让 tools 变 → 断点前移到最前面 → System 与历史一起失效，这就是"MCP 是最难缠的 Cache 杀手"的根本原因。