生产级LLM系统远不止提示词：八大工程支柱如何决定落地成败
去年帮一家电商团队把内部知识库问答从“能演示”推到“能抗住大促”，最开始所有人盯着提示词调了两周。结果一上线，用户问私有订单数据就幻觉，并发一上来延迟直接崩到十几秒，安全审计还差点因为提示注入被卡住。提示词确实是最便宜的杠杆，但生产环境里它只是整条链路里最表层的那一层。真正决定系统能不能活过三个月的，是下面这八根支柱如何被同时拧紧。
我起初以为把模型调用封装成API、再加个向量库就够了。后来把线上日志和成本账单摊开一看，发现每一次“看起来简单”的失败背后，都对应着某根支柱的缺失：要么检索粒度不对，要么上下文被无聊挤爆，要么量化后精度掉得太狠，要么根本没有可回归的评估集。这八根支柱不是并列清单，而是从“怎么说话”到“怎么活着”的完整工程栈。
提示工程：把指令当代码写，而不是当聊天记录抄
提示仍然是起点。它能解决的问题比大多数人以为的多——格式锚定、少样本示范、思维链约束，往往能把准确率直接拉高一截。关键是把它当成可版本、可测试、可复现的代码，而不是一次性粘贴的“魔法咒语”。
生产里我见过最有效的做法是把系统提示、用户模板、输出Schema拆成独立配置，用单元测试跑黄金集。下面是一段重构后的伪代码示例（逻辑精简自常见生产实践，重点在可测试性）：
# 提示模板：强制结构化输出 + 少样本锚定
SYSTEM_PROMPT = """
你是电商订单助手。只回答与用户历史订单相关的问题。
输出必须是合法JSON：{"answer": str, "confidence": float, "sources": list}
"""
FEW_SHOT = [
{"user": "上周买的那双鞋到哪了？",
"assistant": '{"answer": "已发货，预计明天到", "confidence": 0.92, "sources": ["order_8821"]}'},
]
def build_prompt(user_query: str, history: list) –> str:
# 历史压缩：只保留最近3轮，避免token稀释
compressed = compress_history(history, max_turns=3)
return f"{SYSTEM_PROMPT}\\n{FEW_SHOT}\\n历史：{compressed}\\n用户：{user_query}"
这段代码看起来普通，但它把“可复现”这件事落到了实处。提示工程的上限其实很高，直到你碰到模型训练截止日之后的数据，或者需要长期记忆的时候。
检索增强与上下文工程：不是“塞进去就行”，而是“抢token的艺术”
RAG解决了“模型不知道公司文档”的硬伤：文档切块、嵌入、检索、重排序，再塞进提示。但真正的战场其实在上下文工程——对话历史、工具返回、系统指令、记忆、少样本，全都在同一扇窗口里抢注意力。
检索只是输入之一。上下文工程要决定：什么留下、什么压缩、什么直接丢掉。每多一个token都在花真钱，也在稀释模型的注意力。把RAG当成上下文工程的子工具，而不是全部，才能避免“检索到了却答不对”的尴尬。
类比一下：上下文窗口就像一张有限面积的办公桌。你不能把所有资料、历史邮件、工具手册同时摊开，否则真正要看的合同就被压在最底下。生产级做法通常是：查询改写 → 检索 → 交叉编码器重排 → 动态摘要压缩历史。
微调、智能体与部署：权重、循环与流量的三重关卡
当提示和上下文都到了天花板，才轮到权重。LoRA/QLoRA用低秩矩阵在单卡上就能适配领域数据，数据质量（去重、指令格式、过滤）比训练循环本身更重要。微调不是银弹，它解决的是“分布偏移”，而不是“临时知识”。
智能体把单次生成变成多轮决策：选工具、调用、读结果、再决定下一步。工程难点不在模型会不会选工具，而在状态管理、重试、步数限制、错误降级。无限循环和错误工具调用，是生产里最常见的“看起来很聪明却死循环”的坑。
部署则是另一套完全不同的问题。很多人直接把DevOps经验套过来，结果发现LLM的KV缓存浪费、批处理策略、流式输出延迟，跟传统微服务完全不是一个量级。vLLM的PagedAttention把缓存浪费从60-80%压到4%以下，吞吐能翻2-4倍，这已经是2026年的事实标准。再往上叠服务层（LitServe之类）、网关路由和成本追踪，才能扛住真实流量。
优化、安全与可观测：账单和事故真正教你的事
第一张推理账单下来，优化立刻变成刚需。量化（FP16→4-bit）通常只损失不到1%困惑度，却能让70B模型塞进单张24GB卡；蒸馏和剪枝则是进一步的取舍。所有优化都必须在真实业务负载上测，而不是通用榜单。
最后一根支柱是安全、评估与可观测。评估回答“输出好不好”（黄金集回归），可观测回答“现在发生了什么”（链路追踪、token、延迟、失败）。没有这两层，前面所有优化都是黑盒赌博。提示注入防御、输出过滤、实时告警，是生产系统的底线。
下面这张表把八大支柱放在一起看，方便做决策取舍：
| 提示工程 | 指令歧义与格式不稳定 | 低 / 低 | 任何项目起步 | 提示漂移、不可复现 |
| RAG系统 | 私有/时效知识缺失 | 中 / 中 | 需要公司数据 | 检索噪声、切块不当 |
| 上下文工程 | token竞争与注意力稀释 | 中 / 高 | 多轮/工具密集 | 上下文爆炸、成本失控 |
| 微调 | 领域分布偏移 | 高 / 中 | 提示+上下文见顶 | 数据污染、灾难性遗忘 |
| 智能体 | 多步决策与工具编排 | 高 / 高 | 需要闭环行动 | 无限循环、错误工具 |
| 部署 | 并发、延迟、吞吐 | 高 / 高 | 上线后流量上来 | 缓存浪费、冷启动 |
| 优化 | 推理成本与硬件上限 | 中 / 中 | 账单变贵时 | 精度掉太多 |
| 安全/评估/可观测 | 质量未知与线上故障 | 中 / 高 | 从第一天开始 | 黑盒事故、合规风险 |
这张表不是优先级排序，而是“什么时候该拧哪根螺丝”的地图。我见过太多团队把前三根拧到极致，后面五根几乎空白，结果系统一上线就集体翻车。
把LLM当玩具玩的时候，提示词几乎是全部；把它当成生产系统的时候，提示词只是入口。真正拉开差距的，是后面七根支柱有没有被当成一等公民来工程化。2026年的现实是：模型本身越来越强，工程栈的完整度才决定你能不能把能力变成稳定交付。
你现在负责的LLM项目里，哪一根支柱是明显短板？或者你觉得还应该再加一根什么？欢迎直接说，咱们下期可以专门拆。
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
