大多数工程团队都能准确地告诉你哪个环境变量在控制他们的数据库连接池。但几乎没有人能告诉你现在是哪个版本的 system prompt 在处理 90% 的流量 —— 或者自上一次收到模型行为投诉以来发生了哪些变化。
这就是 AI 配置足迹（AI configuration footprint）问题。构建基于 LLM 功能的团队会积累一个隐形的配置层 —— 模型选择、采样参数（sampling parameters）、system prompts、工具 schemas、重试预算 —— 这些配置决定了他们的产品在生产环境中的行为。这一层的大部分内容都没有记录在案（system of record）。它们通过直接修改代码、交付电子表格或 Slack 消息进行更新。当出现问题时，没有人能说清楚发生了什么变化。
这不是流程问题，而是架构问题。解决方案需要以成熟团队对待环境配置、功能旗标（feature flags）和基础设施即代码（infrastructure-as-code）同样的严谨态度来处理 AI 配置。
你的 AI 配置足迹中到底包含什么
直觉上的答案是“提示词”。而真正的答案要广泛得多。
对 LLM 的每一次请求都由一堆设置组成，这些设置以不明显且有时是非线性的方式相互作用：
采样参数（Sampling parameters） —— temperature、top-p、frequency penalty、presence penalty、max tokens —— 控制着输出 token 的概率分布。配合模糊指令的 temperature 0.7 与配合相同指令的 temperature 0.1 产生的输出截然不同。这些设置不能脱离它们所配对的提示词进行独立审计。
系统提示词（System prompts）和指令前导语定义了行为护栏、角色、响应格式预期和任务框架。一个生产系统可能拥有一个主要的 system prompt，加上注入的上下文块，以及每个功能的指令片段 —— 每一个都有自己的变更历史，或者根本没有。
**工具 schema（Tool schemas）**在智能体（agentic）系统中指定了模型可以调用什么以及如何调用。更改工具的描述 —— 甚至不是它的实现，只是自然语言描述 —— 就会改变模型在模糊情况下选择调用哪个工具。
模型版本和提供商是最明显的维度，但往往是追踪最差的。许多团队并不将模型选择视为一个版本化的产出。他们在新模型发布时进行升级，并假设行为是等效的。
重试预算和回退逻辑（Fallback logic） —— 失败的调用是使用较低的 temperature 重试，还是回退到较小的模型，亦或是返回预设响应 —— 同样决定了用户看到的内容。这些决策是配置，而不是代码。
综上所述，这个堆栈就是你的 AI 配置足迹。大多数团队在管理这些内容时，都没有应用他们在基础设施代码上所使用的那种纪律。
为什么 AI 配置比环境变量更脆弱
标准的环境变量言如其意。当你重新措辞时，DATABASE_MAX_CONNECTIONS=50 不会改变它的效果。但 AI 配置的工作方式并非如此。
**概率放大（Probabilistic amplification）**意味着微小的变化会产生不可预测的连锁反应。在 system prompt 中更换一个同义词 —— 例如将“始终回复（always respond with）”替换为“使用……回复（respond using）” —— 会改变模型输出中每个 token 的概率分布。看似微不足道的编辑可能会在成千上万次调用中产生显著不同的行为。生产团队曾记录过，在进行了看似无害的提示词更改后的几小时内，结构化输出的错误率急剧飙升。
配置与内容相互作用。适用于特定 system prompt 的 temperature 设置，在相同指令的重新措辞版本中可能会失效。参数之间并不是独立的。你不能孤立地调整采样设置，并期望它们在提示词更改时保持正确的调整状态。
提供商端的漂移（Provider-side drift）是真实存在的。当模型提供商更新他们的模型时，即使你没有动过自己的配置，也可能会看到行为上的变化。斯坦福大学的一项著名研究测量了 GPT-4 在特定任务上的准确率在三个月内从 84% 下降到 51%，而期间并没有公开的版本变更。团队是从用户投诉中得知这种漂移的，而不是通过监控。
Token 成本对配置很敏感。增加了 500 个 tokens 的 system prompt，或者带有冗长描述的工具 schema，都会在大规模运行下增加单次请求的成本。有记录显示，优化不佳的 RAG 管道仅格式化开销就消耗了 40-70% 的 token 预算。当没有人负责配置足迹时，就没有人负责成本走向。
未经追踪的变更如何导致静默回退
最危险的配置失败不是那些导致系统崩溃的，而是那些悄无声息地降低系统质量的失败。
一个团队在 system prompt 中增加了几个词，让回复感觉更口语化。这些词单独看是无害的。但它们改变了模型的校准（calibration），以至于内容护栏开始允许不该出现的短语。系统没有抛出异常。宏观层面的质量指标保持稳定。问题在几周后通过用户报告浮出水面，而到那时已经没有人记得更改了什么。
另一个团队将“输出严格有效的 JSON（output strictly valid JSON）”改为“始终使用整洁、可解析的 JSON 进行回复（always respond using clean, parseable JSON）”。新的措辞更符合英语自然表达，但也欠缺精确。模型开始偶尔包含多余的逗号或遗漏必需的字段。下游解析器间歇性失败。这些失败非常罕见，以至于在一周内都被视为瞬时错误而被忽略，直到有人追踪到提示词的更改。
这些都是真实记录的模式。它们有一个共同的结构：配置变更是不可见的，行为变化是渐进的或随机的，而因果关系只有在造成重大损失后才被发现。
更糟糕的是复现难度。LLM 的输出是概率性的。针对特定用户群或输入分布，在 3% 的调用中出现的提示词回退（prompt regression），在仅运行少量手动检查的测试环境中可能无法复现。
AI 配置的“配置即代码”规范
解决 AI 配置足迹（footprint）问题并不需要一个新平台，而是需要将现有的软件工程规范应用于这一类新的制品（artifact）。
版本化一切，而不仅仅是提示词文本。 一个提示词版本应当包含完整的行为制品：系统提示词文本、与之配套调优的采样参数、设计协同工作的工具 Schema，以及测试过的模型版本。在不更新版本记录的情况下更改其中任何一项，都会在文档说明与实际行为之间造成隐形的脱节。
使用不可变版本与运行时路由。 生产环境中任何时刻的配置都应该可以通过一个精确的版本标识符来识别。运行时路由——如“production”、“staging”、“canary”等标签——应当映射到不可变的版本标识符，而不是指向最后一次保存内容的浮动引用。这使得回滚具有确定性。你可以从 prompt-v42 切换回 prompt-v41，而无需重新部署代码。
将晋升（发布）视为受控流程。 配置变更不应直接进入生产环境。规范的做法是：创建一个新版本，在评估框架（evaluation harness）中运行，将输出与当前生产版本进行对比，审查差异，然后进行晋升。评估不一定要面面俱到才有用。即使是针对过去用户报告的问题提取的 30-50 个回归测试，也能在发布前捕捉到大部分重大的行为倒退。
实现跨越行为而非仅限于文本的审计追踪。 Git blame 能告诉你谁改了哪行代码。你的 AI 配置系统应该能告诉你哪个配置版本服务了特定的用户会话、其采样参数是什么，以及它是何时被晋升的。这是让事后调查变得可行的关键。
使变更流程与风险对齐。 在验证范围内调整 temperature（采样温度）所需的流程，应当少于对涉及护栏行为（guardrail behavior）的系统提示词的修改。并非每个配置变更都需要进行完整的评估运行——但高风险变更绝不应绕过评估。
比较行为差异，而不仅仅是代码差异
一旦你拥有了版本化的配置制品，下一步要构建的能力就是行为比对（behavioral diffing）——即比较两个配置版本在代表性输入集上的实际表现。
核心原语是评估框架：一组包含预期输出或质量标准的输入案例，针对两个配置版本运行并对比结果。案例不需要详尽无遗，但需要覆盖关键的失败模式：结构化输出的正确性、对护栏的遵守情况、代表性输入下的任务完成度，以及单次调用成本。
生产环境中的 A/B 测试将此能力扩展到了实时流量。一小部分请求运行在候选配置版本上，其余请求运行在生产版本上。指标——单次调用成本、下游错误率、用户反馈信号——会并行累积。这使得在全量发布前，大规模验证行为改进成为可能。
**LLM 作为评判者的评分机制（LLM-as-judge）**填补了自动化指标无法涵盖的空白。对于正确性属于定性性质的输出——例如：这段回答是否准确描述了某项政策？这段摘要是否保留了关键决策？——性能更强的模型可以进行大规模评分，且具有相当的可信度。大规模自动化评分取代了目前大多数团队采用的、并称之为“质量审查”的随机人工抽样。
基于行为指标的回滚，而不仅仅是基于错误率。一个通过了技术健康检查（无异常、延迟正常、Token 数量符合预期）的配置，在行为上仍可能失效。行为指标——如 LLM 评判得分、下游任务成功率、用户反馈代理指标——需要接入与技术指标相同的回滚触发器。
将 AI 配置视为一等基础设施
区分成熟 AI 系统与脆弱 AI 系统的模式，不在于模型选择或提示词工程的精妙程度，而在于围绕控制模型行为的制品所建立的运维规范。
环境变量拥有版本控制、变更管理和部署门禁已经有几十年了。基础设施即代码（IaC）为网络拓扑和云资源带来了同样的规范。而管理着比两者都更难推理的概率行为的 AI 配置，在很大程度上却逃脱了这种待遇。
准入门槛很低。首先盘点你目前的 AI 配置足迹。然后对其进行版本化。接着通过至少最基本的评估来管控变更。大多数团队发现，当他们第一次将生产环境的配置变更与测试框架进行比对时，都能捕捉到某些本会直接上线的问题。
目标并非官僚化。它的目标与任何基础设施规范相同：让你在生产环境中运行的东西变得可知、可审计，并在表现异常时可恢复。AI 配置已经在生产环境中运行了，它已经在治理行为。它只是还没有被当作重要的资产来管理——而它确实至关重要。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
