企业官网建设流程全解析

先看一个真实场景：上周你的 LLM 功能还好好的，用户问题、返回格式、解析逻辑都没动过，但这周一你发现线上开始偶发返回异常，失败率从 0.1% 涨到了 3%。代码没有合入任何变更，模型服务也显示健康，可行为就是变了。这种让人头疼的问题，往往不是 bug，而是 LLM 在生产代码库里悄悄漂移了。

本文会从工程视角拆解 LLM 漂移（drift）的本质，然后给出一套可以落地的稳定化方案：从版本锁定、结构化输出、缓存与降级，到评估回归、监控告警、CI 集成。无论你是刚接触 LLM 应用开发，还是已经在生产环境维护 AI 功能，都能照着这套思路把代码重新收敛回可控状态。

1. 背景与核心概念

1.1 什么是 LLM 漂移

LLM 漂移指的是：在没有我们主动修改代码、提示词或业务规则的情况下，LLM 系统的输出行为与之前不一致。这种不一致可能是输出格式变化、语义偏差、回答长度变化，甚至是拒绝回答策略变化。

传统软件里，“代码不变则行为不变”是一条基本定律。但 LLM 应用打破了这条定律，因为系统的行为不仅由你的代码决定，还取决于远端模型服务的行为，而远端模型并不完全受你控制。

你可以把 LLM 漂移理解成一种“外部依赖漂移”。它与依赖库版本升级带来的行为变化类似，但更难感知，因为：

• 模型服务方不会在每次调整模型权重时都发布公告。
• 即使是同一个模型 ID，在不同时间段也可能有静默的行为变化。
• 输出是非确定性的，即便采样参数完全一致，也可能有微小差异。
• 生产环境通常缺少对单次输出质量的自动判断能力。

1.2 漂移的常见类型

我把生产环境里常见的漂移分为四类，方便后续排查时对号入座：

在真实项目中，这四类漂移经常叠加出现。比如你升级了 Embedding 模型，检索结果变化，再叠加远端大模型更新，最终用户感受到的答复质量就可能骤降。

1.3 为什么生产代码库必须重视漂移

生产代码库和实验脚本的最大区别在于：有用户、有流量、有可用性要求。实验阶段你可以接受“某次输出不好看”，但生产环境一次批量回复质量下降，可能直接影响转化率、客服效率，甚至造成合规风险。

更重要的是，漂移会破坏你对系统的信任。如果每次发布前无法判断模型行为是否回归，那么任何功能迭代都会变得很不可靠。反过来说，只要建立了对抗漂移的工程机制，LLM 应用就可以像普通后端服务一样做版本管理、回归测试和监控告警。

2. 环境准备与版本说明

本文示例以 Python 环境为主，因为 LLM 生态目前最成熟的 SDK 和工具链基本都在 Python 侧。版本需要根据你的项目实际情况调整，下面给出一套常见组合。

2.1 运行环境

# 操作系统 Ubuntu 22.04 / macOS 14+ / Windows WSL2 # Python Python 3.10+ # 建议使用虚拟环境 python -m venv .venv source .venv/bin/activate

2.2 依赖说明

# LLM SDK，以 OpenAI 兼容接口为例 pip install openai # 配置与管理 pip install pydantic pydantic-settings # 测试与评估 pip install pytest pytest-asyncio # 缓存 pip install redis # 日志 pip install structlog # HTTP 客户端 pip install httpx

这里要强调一点：不同 SDK 的 API 差异较大，OpenAI 兼容接口是目前大多数云厂商和自建网关都会支持的标准。如果你使用的是其他厂商 SDK，核心思路完全一致，只需要替换客户端初始化方式。

2.3 目录结构

llm_production_stable/ ├── src/ │ └── llm_gateway/ │ ├── __init__.py │ ├── client.py # LLM 客户端封装 │ ├── schema.py # 结构化输出 Schema │ ├── cache.py # 缓存层 │ ├── fallback.py # 降级与重试 │ └── monitor.py # 日志与监控 ├── tests/ │ ├── test_schema.py │ └── test_client.py ├── evaluate/ │ ├── golden_set.jsonl # 金标数据集 │ └── run_evaluation.py # 回归评估脚本 ├── prompts/ │ └── intent.py # prompt 模板，强制版本化 ├── .github/ │ └── workflows/ │ └── evaluate.yml # CI 评估流水线 └── pyproject.toml

3. 核心机制：为什么 LLM 会漂移，以及如何对抗它

3.1 模型是“外部依赖”，不是稳定函数

很多开发者第一次写 LLM 代码时，会把模型调用当作普通函数：

response = openai.chat.completions.create( model="gpt-4o-mini", messages=[...], )

这种写法在实验阶段没问题，但它隐含了一个假设：同一段输入、同一个模型 ID，输出总是可预期的。实际上并不成立。远端模型服务的权重、推理配置、部署实例都可能变化，所以我们必须把模型调用当成“不稳定外部依赖”来设计系统。

对抗思路也很简单：假设它不稳定，然后在外面加一层稳定边界。

3.2 三个关键稳定边界

第一个边界是版本锁定。把模型 ID、prompt 版本、输出 schema 版本一起作为调用参数传入，并且在日志里记录，这样一旦出现问题，能立刻定位是哪一层变化导致。

第二个边界是结构约束。无论模型返回什么自由文本，业务层只消费结构化字段。解析失败时宁可抛异常，也不要让一段脏字符串流向下游。

第三个边界是评估回归。建立一套只覆盖核心场景的金标测试集，每次发布前自动跑分，评分低于阈值则阻断发布。

3.3 成本、延迟与漂移的关系

很多人以为为了对抗漂移就要做复杂链路，实际上一个好的设计反而会降低成本。缓存在这里很关键：对确定性要求高的请求，命中缓存后直接返回，完全绕开模型，天然不受模型漂移影响。此外，缓存还能降低延迟和费用。

但缓存也会带来一个新问题：如果模型行为已经漂移，而缓存一直没有失效，用户会一直拿到“旧版结果”。所以缓存键里必须带上 prompt 版本、业务参数版本、模型 ID，必要时还要设置 TTL。

4. 完整实战案例：构建稳定的 LLM 接入层

下面我们从零开始搭建一个生产可用的 LLM 接入层。这个接入层的目标非常明确：让业务代码依赖一个稳定的调用接口，而不是直接依赖模型 SDK。

4.1 定义结构化输出 Schema

首先定义业务需要的输出结构。这里以“用户意图分类”为例，适合用短文本演示，但思路完全适用于摘要、信息抽取、客服回复生成等复杂场景。

# 文件路径：src/llm_gateway/schema.py from enum import Enum from typing import Literal, Optional from pydantic import BaseModel, Field, field_validator class IntentType(str, Enum): AFTER_SALE = "aftersale" PRE_SALE = "presale" COMPLAINT = "complaint" OTHER = "other" class IntentResult(BaseModel): intent: IntentType confidence: float = Field(ge=0.0, le=1.0, description="置信度，0-1") product_keyword: Optional[str] = Field( default=None, description="商品关键字，仅在识别到商品时填写" ) raw_reply_short: str = Field(description="给用户的一句话简短回复") @field_validator("confidence") @classmethod def validate_confidence(cls, v: float) -> float: if v < 0.6: # 低置信度时，让业务走人工兜底，而不是强行走自动流程 raise ValueError("confidence too low, please reply with can_not_handle=True") return v class IntentResponse(BaseModel): can_not_handle: bool = Field( description="当无法用给定商品/规则处理时设为 true" ) result: Optional[IntentResult] = None

这里有几个值得注意的设计点：

• can_not_handle字段用于让模型表达“我处理不了”，业务层看到后直接转人工，避免模型硬答。
• 置信度低于 0.6 时触发校验异常，防止低质量结果进入业务链路。
• 输出结构必须可序列化、可校验，后续评估和日志都依赖它。

4.2 编写带版本控制的 Prompt 模板

Prompt 不能散写在代码里，要单独管理并带版本号。版本号会进入缓存键和日志，是排查漂移的关键线索。

# 文件路径：prompts/intent.py from typing import Any PROMPT_VERSION = "intent-v3" def build_intent_messages(user_input: str, rules: list[str]) -> list[dict[str, str]]: system_prompt = f""" 你是一个电商客服意图识别助手。 请严格根据用户输入和业务规则输出 JSON。 要求： 1. 只输出 JSON，不要输出 Markdown。 2. JSON 必须符合以下结构： {{ "can_not_handle": true/false, "result": {{ "intent": "aftersale|presale|complaint|other", "confidence": 0-1, "product_keyword": "string or null", "raw_reply_short": "不超过20字的中文回复" }} }} 3. 当规则无法覆盖用户需求时，设置 can_not_handle=true。 4. 当置信度不足0.6时，设置 can_not_handle=true。 业务规则： {chr(10).join('- ' + rule for rule in rules)} 用户输入： {user_input} """ return [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input}, ]

把 prompt 版本号放在模板文件里，而不是由业务方乱传，能有效避免“有人偷偷改了 prompt 但没人记得”的问题。后续如果调整了 prompt 内容，请同步更新PROMPT_VERSION。

4.3 封装 LLM 客户端

接下来是核心的客户端封装。这一步要承担几件事：

• 统一模型 ID 和 provider 配置。
• 固定采样参数（temperature=0、top_p=1.0）。
• 记录完整调用信息。
• 解析和校验结构化输出。
• 失败时抛出统一异常。

# 文件路径：src/llm_gateway/client.py import json import time from typing import Any import httpx from pydantic import ValidationError from .schema import IntentResponse from .monitor import log_llm_call class LLMClientError(Exception): """统一 LLM 调用异常""" class LLMClient: def __init__( self, api_base: str, api_key: str, model: str = "gpt-4o-mini", timeout_seconds: float = 15.0, ): self.api_base = api_base.rstrip("/") self.api_key = api_key self.model = model self.timeout_seconds = timeout_seconds async def chat_json( self, messages: list[dict[str, str]], response_model: type[IntentResponse], prompt_version: str, temperature: float = 0.0, ) -> IntentResponse: start = time.perf_counter() try: payload = { "model": self.model, "messages": messages, "temperature": temperature, "top_p": 1.0, "response_format": {"type": "json_object"}, } async with httpx.AsyncClient(timeout=self.timeout_seconds) as client: resp = await client.post( f"{self.api_base}/chat/completions", headers={ "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", }, json=payload, ) resp.raise_for_status() data = resp.json() content = data["choices"][0]["message"]["content"] # 鲁棒解析：先尝试 JSON，解析失败则抛异常 try: parsed = json.loads(content) except json.JSONDecodeError as exc: raise LLMClientError( f"model returned invalid json. content={content[:200]}" ) from exc # 用 Pydantic 校验结构 try: validated = response_model.model_validate(parsed) except ValidationError as exc: raise LLMClientError(f"schema validation failed: {exc}") from exc log_llm_call( prompt_version=prompt_version, model=self.model, latency_ms=(time.perf_counter() - start) * 1000, output_hash=hash(content), validation_ok=True, ) return validated except httpx.HTTPError as exc: log_llm_call( prompt_version=prompt_version, model=self.model, latency_ms=(time.perf_counter() - start) * 1000, error=str(exc), validation_ok=False, ) raise LLMClientError(f"http request failed: {exc}") from exc

这个封装有几个值得学习的地方：

• response_format强制模型输出 JSON 对象，减少 Markdown 干扰。
• 用 Pydantic 模型做二次校验，保证下游拿到的一定是合法结构。
• output_hash用于日志追踪，方便后续对比相同请求的输出是否变化。

4.4 增加缓存层

缓存是为了解决两个问题：第一是降低成本和延迟，第二是让确定性请求不受模型漂移影响。但缓存键必须包含版本信息，确保 prompt 或 schema 升级时能自动绕过旧缓存。

# 文件路径：src/llm_gateway/cache.py import hashlib import json import time from typing import Any, Optional import redis.asyncio as redis class SemanticCache: def __init__(self, redis_url: str, default_ttl: int = 300): self.client = redis.from_url(redis_url, decode_responses=True) self.default_ttl = default_ttl @staticmethod def _build_key( model: str, prompt_version: str, schema_version: str, messages: list[dict[str, str]], ) -> str: raw = json.dumps( { "model": model, "prompt_version": prompt_version, "schema_version": schema_version, "messages": messages, }, ensure_ascii=False, sort_keys=True, ) return "llm:" + hashlib.sha256(raw.encode()).hexdigest() async def get(self, key: str) -> Optional[str]: return await self.client.get(key) async def set(self, key: str, value: str, ttl: Optional[int] = None) -> None: await self.client.set(key, value, ex=ttl or self.default_ttl)

缓存方案其实有多种选择：

• 精确缓存：请求消息完全一致，直接返回历史结果。适合客服回复、意图识别等重复性高的场景。
• 语义缓存：通过向量相似度匹配相似请求，适合 FAQ 场景。语义缓存复杂度更高，需要控制相似度阈值，避免误命中。
• 临时禁用：对实时性要求极高的场景，可以只做短期 TTL 缓存。

上面的示例是精确缓存。业务上如果遇到相同用户重复问同一个问题，也会直接命中缓存，这通常是合理的。

4.5 加入重试与降级

网络抖动、模型服务超时是常态。但重试和降级不能乱来，否则会在模型侧造成更大压力，也会掩盖漂移问题。

# 文件路径：src/llm_gateway/fallback.py import asyncio from typing import Awaitable, Callable, TypeVar from .client import LLMClientError T = TypeVar("T") async def with_retry( func: Callable[[], Awaitable[T]], retries: int = 2, backoff_seconds: float = 0.5, ) -> T: last_exc: Exception | None = None for attempt in range(retries + 1): try: return await func() except LLMClientError as exc: last_exc = exc # 不是所有异常都应该重试，只有网络类错误才重试 if "http request failed" not in str(exc): raise if attempt < retries: await asyncio.sleep(backoff_seconds * (2**attempt)) raise last_exc # type: ignore

这段代码只对网络类错误保留重试能力。对于 schema 校验失败、模型返回非法 JSON 这类问题，重试没有意义，反而会把错误掩盖掉，所以直接抛出，让上层感知并转人工兜底。

降级策略方面，我建议按照“自动处理 → 有限重试 → 人工兜底”的顺序设计。不能让模型失败时静默返回一个默认结果，因为那样会掩盖真实问题。宁可让用户等待或转人工，也不要在后台吞掉异常。

4.6 组装业务调用入口

把上面几个模块组合起来，就是业务层看到的稳定调用入口。业务代码不再直接面对模型 SDK，而是面对一个带有缓存和重试能力的 gateway。

# 文件路径：src/llm_gateway/gateway.py from typing import Optional from .cache import SemanticCache from .client import LLMClient, LLMClientError from .fallback import with_retry from .schema import IntentResponse from prompts.intent import PROMPT_VERSION, build_intent_messages class LLMGateway: def __init__( self, api_base: str, api_key: str, model: str, redis_url: str, schema_version: str, ): self.client = LLMClient(api_base=api_base, api_key=api_key, model=model) self.cache = SemanticCache(redis_url) self.model = model self.schema_version = schema_version async def classify_intent( self, user_input: str, rules: list[str], use_cache: bool = True ) -> IntentResponse: messages = build_intent_messages(user_input, rules) cache_key = self.cache._build_key( model=self.model, prompt_version=PROMPT_VERSION, schema_version=self.schema_version, messages=messages, ) if use_cache: cached = await self.cache.get(cache_key) if cached: import json return IntentResponse.model_validate(json.loads(cached)) async def call_model(): return await self.client.chat_json( messages=messages, response_model=IntentResponse, prompt_version=PROMPT_VERSION, ) try: resp = await with_retry(call_model, retries=2) if use_cache: await self.cache.set(cache_key, resp.model_dump_json()) return resp except LLMClientError as exc: # 生产环境应在此处上报监控，并触发人工兜底 raise

注意，业务代码捕获到LLMClientError后，应该做两件事：上报监控指标并触发降级流程。示例里没有吞掉异常，这正是稳定边界的关键。

5. 建立回归评估体系：让漂移无处可藏

接入层稳定还不够，你还需要一套能自动判断“模型行为是否回归”的机制。这是阻止漂移进入生产环境的核心手段。

5.1 金标数据集（Golden Set）

金标数据集是一组带期望输出的测试样本。它不需要覆盖所有场景，但必须覆盖核心业务链路、易错边界和已知坑点。

# 文件路径：evaluate/golden_set.jsonl {"user_input": "我想退货，订单号是12345", "expected": {"can_not_handle": false, "result": {"intent": "aftersale", "confidence": 0.9, "product_keyword": null, "raw_reply_short": "您好，请问订单号是多少"}}} {"user_input": "这件衣服有黑色吗", "expected": {"can_not_handle": false, "result": {"intent": "presale", "confidence": 0.9, "product_keyword": "衣服", "raw_reply_short": "稍等，我帮您查询库存"}}} {"user_input": "你们公司几点下班", "expected": {"can_not_handle": true, "result": null}}

这个数据集要放进 git 仓库，随着业务迭代持续补充。每次有人修改 prompt 或升级模型，都需要用新数据集跑一遍。

5.2 自动评估脚本

# 文件路径：evaluate/run_evaluation.py import asyncio import json import os from pathlib import Path from src.llm_gateway.gateway import LLMGateway async def load_golden_set(file_path: str) -> list[dict]: items = [] with Path(file_path).open() as f: for line in f: line = line.strip() if line: items.append(json.loads(line)) return items def check_response( actual: dict, expected: dict ) -> tuple[bool, dict]: # 简化版校验：can_not_handle 必须一致，intent 必须一致，置信度不低于 0.85 期望值 if actual.get("can_not_handle") != expected.get("can_not_handle"): return False, {"field": "can_not_handle", "expected": expected, "actual": actual} if not expected.get("can_not_handle"): if actual["result"]["intent"] != expected["result"]["intent"]: return False, {"field": "intent", "expected": expected, "actual": actual} if actual["result"]["confidence"] < 0.85: return False, {"field": "confidence", "expected": ">=0.85", "actual": actual["result"]["confidence"]} return True, {} async def main() -> None: golden_set = await load_golden_set("evaluate/golden_set.jsonl") api_base = os.environ["LLM_API_BASE"] api_key = os.environ["LLM_API_KEY"] model = os.environ.get("LLM_MODEL", "gpt-4o-mini") gateway = LLMGateway( api_base=api_base, api_key=api_key, model=model, redis_url="redis://localhost:6379", schema_version="intent-schema-v1", ) passed = 0 results = [] for item in golden_set: user_input = item["user_input"] expected = item["expected"] try: resp = await gateway.classify_intent( user_input, rules=["支持退货和换货"], use_cache=False ) actual = resp.model_dump() ok, reason = check_response(actual, expected) if ok: passed += 1 else: results.append({"user_input": user_input, "ok": False, "reason": reason}) except Exception as exc: results.append({"user_input": user_input, "ok": False, "reason": str(exc)}) total = len(golden_set) pass_rate = passed / total print(f"pass rate: {pass_rate:.2%} ({passed}/{total})") for r in results: print(json.dumps(r, ensure_ascii=False, indent=2)) # 阈值设置，建议根据业务容忍度调整 threshold = 0.9 if pass_rate < threshold: raise SystemExit(f"评估未通过：通过率 {pass_rate:.2%} < {threshold:.2%}") if __name__ == "__main__": asyncio.run(main())

阈值设置要结合业务容忍度。如果评估集本身就包含边界 case，90% 是合理底线；如果评估集只覆盖主流程，建议提高到 98% 以上。关键是：宁可发布慢一点，也不要让漂移悄悄进生产。

5.3 接入 CI 流水线

评估脚本只有跑在自动化流程里才有价值。下面以一个常见 CI 配置为例。

# 文件路径：.github/workflows/evaluate.yml name: LLM Evaluation on: pull_request: paths: - "prompts/**" - "src/llm_gateway/**" - "evaluate/**" push: branches: [main] paths: - "prompts/**" - "src/llm_gateway/**" - "evaluate/**" jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.10" - run: pip install -e ".[dev]" - run: pytest tests/ - run: python evaluate/run_evaluation.py env: LLM_API_BASE: ${{ secrets.LLM_API_BASE }} LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_MODEL: ${{ secrets.LLM_MODEL }}

等 CI 跑通之后，你就会发现一个非常有用的转变：从“谁能保证模型行为没变？”变成“CI 已经在自动检查了，阈值没过就看不到合入口”。这才是生产代码库应有的确定性。

6. 生产监控与漂移检测

评估只能覆盖你写过的样本，线上真实用户的输入分布要广得多。所以生产监控同样不可缺少。

6.1 结构化日志

结构化日志是监控的基础。每一次 LLM 调用都要记录：prompt 版本、schema 版本、模型 ID、输入哈希、输出哈希、延迟、token 用量、是否命中缓存、是否有异常。

# 文件路径：src/llm_gateway/monitor.py import hashlib import json import logging import time logger = logging.getLogger("llm_gateway") handler = logging.StreamHandler() formatter = logging.Formatter( "%(asctime)s %(levelname)s %(name)s %(message)s" ) handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) def _stable_hash(value: str) -> str: return hashlib.sha256(value.encode()).hexdigest()[:16] def log_llm_call( prompt_version: str, model: str, latency_ms: float, output_hash: str = "", validation_ok: bool = True, error: str = "", extra: dict | None = None, ) -> None: data = { "event": "llm_call", "prompt_version": prompt_version, "model": model, "latency_ms": round(latency_ms, 1), "output_hash": output_hash, "validation_ok": validation_ok, "error": error, "timestamp": int(time.time()), **extra, } logger.info(json.dumps(data, ensure_ascii=False))

注意，日志里不要记录完整的用户输入和完整模型输出，避免隐私和合规问题。记录哈希值已经足够用于追踪和对比。

6.2 监控指标建议

如果使用 Prometheus 或云监控，建议至少采集以下指标：

schema 校验失败率上升是一个非常强的漂移信号。如果平时校验失败率低于 0.1%，某天突然涨到 2%，第一反应不应该是修代码，而是要检查模型输出格式是不是变了。

6.3 灰度与金丝雀发布

当你要升级模型版本、换品牌模型或调整 prompt 时，不要直接全量。建议通过灰度策略引入新版本，比如先让 5% 流量走新版本，观察 schema 校验失败率、用户反馈、延迟指标，再逐步扩大。

灰度期间日志里的model字段和prompt_version字段会派上大用场。你可以对比新旧版本在同一批真实输入上的表现差异。

7. 常见问题与排查思路

下面整理了一些生产环境里最常见的漂移相关问题和排查思路。

排查时有一个很重要的原则：不要把眼光局限在代码 diff 上。先看日志和指标，确认变化发生的时间点，再反推当时有哪些变量变了：模型服务、prompt 版本、schema 版本、上下文策略、知识库更新、线上配置开关。其中任何一个变化都可能触发漂移。

8. 最佳实践与工程建议

到这里，稳定化方案已经完整了。最后再整理几条生产环境里踩过坑后沉淀下来的建议。

8.1 把 prompt 当作代码管理

prompt 必须进 git、带版本号、走 code review。不要允许业务方直接改线上配置里的 prompt 字符串。建议单独建立prompts/目录，每个 prompt 文件包含版本常量，所有修改通过 PR 合入。

8.2 输出 schema 先行

在写业务逻辑之前，先定义输出 schema。业务逻辑只消费校验后的 Pydantic 对象，不消费原始字符串。这样即使模型输出漂移，你也能在 gateway 层快速感知，而不是让脏数据穿透到数据库或用户界面。

8.3 让失败可见，而不是静默降级

很多初学者喜欢在异常里返回一个默认值，看起来“稳定”，实际上是在掩盖问题。生产环境应该让失败可观测：上报指标、记录日志、触发人工兜底。宁可让用户等待，也不能让错误数据进入正常流程。

8.4 评估集要持续增量

每次找到线上 bad case，就把它加入金标数据集。评估集越贴近真实输入分布，CI 防线越牢固。建议每个迭代周期至少 review 一次评估集，移除已经不再相关的样本，新增最近发现的坑点。

8.5 监控要设阈值和告警

没有告警的监控等于没有监控。建议至少对以下场景设置告警：

• schema 校验失败率连续 5 分钟超过 1%。
• LLM 调用错误率超过 5%。
• 缓存命中率意外骤降（可能缓存键设计被破坏）。
• 评估脚本在 CI 中失败（直接阻断发布）。

8.6 安全与合规边界

LLM 应用涉及用户数据时，务必在 gateway 层做好脱敏和日志控制。核心建议：

• 日志不记录完整用户输入输出，只保留哈希或脱敏片段。
• 对外部模型的请求增加内容过滤，避免敏感信息外泄。
• 涉及用户个人信息时，确认是否允许将数据发送给第三方模型服务，必要时自建私有化模型网关。

8.7 分阶段推进的路线图

如果你正在接手一个已经上线的 LLM 项目，不要一次性引入上面所有机制，那样风险太高。建议按以下顺序推进：

• 第一阶段：增加结构化日志与输出哈希，建立基础监控。
• 第二阶段：引入 Pydantic schema 校验，确保业务层只消费合法结构。
• 第三阶段：封装统一 gateway，加入缓存与重试。
• 第四阶段：建立金标评估集并接入 CI。
• 第五阶段：增加告警、灰度与 canary 发布机制。

当你走完这五个阶段，代码库不会再被 LLM 的随机性牵着走。每一次模型升级、prompt 调整、SDK 更新，都可以像普通后端变更一样有回归预期、有监控数据、有安全兜底。

如果你最近也被线上 LLM 行为不稳定困扰，建议先按照第六节的指标清单查一遍日志，看看输出哈希在一天内是不是开始剧烈变化。确认了漂移信号之后，再动手搭建本文这套稳定边界。有了版本锁定、结构化输出、评估回归、监控告警这四道防线，LLM 在生产代码库里也能稳定得像普通软件一样。