《你老怪“模型不稳定” ：但真正不稳定的是你注入给它的东西》

很多 AI 应用系统因为不稳定不敢交付上线，有时候不是模型不够强，
而是你每次“喂给模型的上下文”本身就并不稳定：

那大模型会受哪些上下文注入影响 ???

• 有些是工具自动拼的，
• 有些是应用 prompt 固定带的，
• 有些是用户手动注入的，
• 还有些来自外部检索系统。

如果不把这些注入源分辨清楚，就很容易又再怪责“模型又在飘移 ! ”。

下面用不同视角，把“大模型注入”分成几类层次来说明：

核心误解：你以为大模型只吃 user_input

你以为你与大模型交互是一个纯函数：

• output = f(user_input)

但现实里更接近：

• output = f(user_input, injected_context_pack)

这里的 injected_context_pack ，就是“一堆会影响大模型输出的输入包”：

• 工具/CLI 的上下文装配规则、
• 应用的 system/user prompt、
• 用户手动注入的 harness，
• 以及外部检索/知识库召回的参考材料。

当你真正理解它之后，你会发现所谓“模型不稳定”，很多时候是因为你还没学会控制这些 Pack：

• 让 Pack 可见（列清单）
• 让 Pack 可追溯（留 trace）
• 让 Pack 可回放（能复现）
• 让 Pack 可收敛（少而硬，而不是多而散）

换句话说：当你开始学会管理输入包(注入)时,你的AI 应用就混远离飘移 !

隐式输入的 5 个入口（其实是这些輸入在变）

入口 1：记忆（Memory）——主要“自信幻觉”的来源

记忆不是“用户喜欢什么颜色”这种软信息。记忆真正危险的是：你把上一次会话的“结论”当成了这一次的“事实”。

它注入的隐式输入：

• 用户画像（偏好/背景）被当成规则
• 上轮结论被当成证据
• 上轮失败/成功路径被当成策略

典型事故：

• 用户改需求了，你还按老偏好输出，且毫无自觉
• 记忆里一个错误结论被复用 20 次，越跑越偏
• 越聊越像“自说自话”：因为模型在追随它自己制造的历史（记忆)

那你要如何控制这个入口：

• 把记忆分层：preference（偏好）≠ fact（事实）≠ decision（决策）≠ artifact（产物）
• 每次调用都应能说清：用了哪些记忆（至少能列清单）
• 允许撤销与回放：否则就无法复现

例子：同一句话，为什么答得不一样？（记忆注入导致的“自信”）

用户输入（固定不变）
“帮我写一份退款规则说明，面向 C 端用户。”

情况 A：只注入 preference（偏好）记忆（可接受波动）

注入的记忆：preference- 风格：简洁、要点式- 语气：口语化

你会看到的结果

• 输出结构、措辞不同，但规则本身不变
  这类波动是“风格波动”，通常可以接受。

情况 B：混入 fact（事实）记忆，但事实过期/错误（典型“自信幻觉”）

注入的记忆：fact- “退款期是 30 天”- “虚拟商品不支持退款”

如果现实规则已经改成“7 天/部分虚拟商品可退”，那模型就会非常自信地写出错误条款。你以为是模型瞎编，其实是：模型在复述你系统塞给它的“旧事实”。

情况 C：混入 decision（决策）记忆，导致路线跑偏

注入的记忆：decision- “上次决定：退款规则必须按法务模板写，必须带免责声明与条款编号”

这会导致输出突然变得很长、很硬、很“法务”，而你如果不记录这条 decision，就解释不了为什么同一句输入这次风格完全变了。

下面是你可作的最小验证做法：每次输出附带“本次记忆注入清单”
memory_refs（示意）

• preference: style=concise_bullets
• fact: refund_window_days=7 (source=policy_v3, updated_at=2026-08-01)
• decision: use_legal_template=true (decision_id=DEC-102, decided_at=2026-07-15)
• artifact: refund_policy_draft_v2 (file=drafts/refund_v2.md)

这时一旦用户质疑，你能做到（管理或更正注入内容)：

• 撤销：把错误 fact 标为过期/禁用
• 回放：用同一份 memory_refs 重跑复现，定位差异到底来自哪里

入口 2：RAG（检索增强）——最明显的黑箱注入

很多人对 RAG 有一种危险的误解：只要“检索到了东西”，就算“有依据”。
然后他们：

直接把检索结果塞进 prompt，当作 LLM 的参考资料——但自己不看、也不留痕。

不管你 RAG 品质如何，它都是一种非常明显的黑箱注入：
你把一个外部系统的输出，当作“额外输入”喂给大模型。于是你的真实输入已经不是 user_input，而是：

• user_input + retrieved_context

你“不看”只是把它变成暗箱，不会让它不存在。

它注入的隐式输入（你不一定看得见，但它确实在变）：

• 资料库当时的状态：内容是否更新、是否有新版本、是否下线/替换
• 检索策略的选择：这次到底取了哪些片段、取了多少、按什么规则排序
• 片段组织方式：同一份资料被切成什么粒度、是否合并/去重、上下文拼接顺序
• 可见范围：不同用户/不同权限/不同空间，能拿到的资料可能不同
• 质量波动：有时命中关键段落，有时命中“看起来相关但其实没用”的段落

典型事故：

• 同一句问题，今天引用 A，明天引用 B：输出不稳定但无法解释
• 召回到错误/过期/不适用片段：你还以为是“模型幻觉”
• chunk 拼接错位：答案看似合理，证据却对不上
• 你无法证明“模型没看到敏感信息”：因为你根本没记录注入过什么

怎么控制这个入口（中性版本）：

• 每次输出至少留一份“检索清单”（retrieval_trace）：能回放这次到底注入了什么
• 把检索结果当成 Context Pack 的一部分：可回放即可验收
• 高风险场景（税务/合规/风控/权限/合同）：做来源白名单与质量门控；可疑就降级（宁可输出缺口，也不要把黑箱当证据）

补一句结论：
不管 RAG 做得多好，只要“检索结果不透明 + 不可回放”，
它就天然会带来输出波动与归因困难；这不是谁的锅，是系统结构决定的。

入口 2.5：Repo/CLI 规则文档——最容易被忽略的“自动注入”

很多人以为“注入”只有 RAG。其实还有一类更隐蔽：项目里的 CLI/Agent 规则文档。

比如：

• AGENTS.md（仓库级 Agent 操作规程）
• Claude.md / repo.md / CONTRIBUTING.md（工具/工作流约束）- 各种脚本/模板 md（告诉模型怎么写代码、怎么跑命令、怎么输出格式）

这些文件经常会被工具自动读取、被 workflow 当作默认规则长期携带，或被人手动拼进 prompt。它们更新、换分支、换 项目repo 的时候，你的“真实输入”也会跟着变成：

• user_input + repo_rules + cli_rules

典型事故：

• 换了分支/换了 repo/规则文件更新后，同一个任务输出风格、约束、路径选择全变
• 你不记日志，就解释不了“为什么它突然开始要求先读 spec / 不允许做某些操作”

那你要如何控制这个入口：

• 把被加载的规则文件也纳入清单：rules_loaded[]
• 记录版本（例如文件时间/摘要），保证可回放- 关键约束下沉到 harness/schema/lint，而不是只靠 md 口头约束

入口 3：摘要（Summary）——最隐蔽的“信息损失压缩器”

注入摘要以为可以省 token，但他本质是不可逆压缩。一旦丢了约束/否定条件/边界，后续大模型推理会沿着错误方向越跑越快。

它注入的隐式输入：

• 被保留的事实集合
• 被删掉的上下文
• 摘要生成时的模板/偏好/强调点

典型事故：

• 摘要漏了“不得新增端点”，后续 spec 开始随便编 API
• 摘要漏了“这是 B2B 不是 C 端”，后续开始补 APP 端闭环
• 摘要写成“结论叙事”，模型把它当铁律，不再回看原文

那你要如何控制这个入口：

• 摘要必须可审计：至少能追到“摘要从哪来”
• 关键约束不能只存在摘要里：必须落到显式 harness / schema / lint
• 多摘要分离：facts_summary / constraints_summary / decisions_summary，不要混成一坨故事

入口 4：路由（Routing）——你以为是策略，其实是状态机

路由决定你走哪个 prompt、用哪个模型、超时/重试怎么配。你每改一次路由，就等于改了一次系统行为。

它注入的隐式输入：

• 触发词规则（关键词、分类器、阈值）
• 多模型选择与 fallback
• 任务分解策略（分几步、每步输入裁剪多少）
• 超时、重试、fast-fail 策略

典型事故：

• 同一需求，今天走“合规作业”，明天走“税会作业”，输出结构完全不一样
• fallback 换了模型，但你没记录，结果不可解释
• 重试裁掉上下文，“修复成功但语义错”，更难排查

怎么控制这个入口：

• 路由必须产出可观测元数据：route = {stage, scope, model, retry, fallback, thresholds}
• 把路由决策写进 Raw Output，支持回放与验收
• fast-fail 可以省钱，但要能识别 fast-fail loop（越修越错）并止损

结尾：把注入从暗箱变成清单（Context Pack）

• 模型看到的输入，通常是“用户输入 + 多层注入上下文”的组合
• 这些入口只要有任何一层变化，输出变化就是正常现象
• 真正的工程目标不是“让模型永远稳定”，而是让“每次注入了什么”可见、可追溯、可回放、可收敛

换句话说：把“注入”从暗箱变成清单（Context Pack），你的大模型应用才开始拥有可交付性。