提示工程到上下文工程：把模型用稳的方法论
把指令设计、结构化输出、少样本、思维链、上下文管理这几块彻底摸透，攒成能重复用的工程能力
- 写系统提示，要做到清晰、可复用、可评测。
- 掌握结构化输出与可靠性约束
- 理解少样本、思维链的适用场景与代价
- 建立提示版本管理与回归意识
提示词不是“咒语”，而是可工程化的接口契约
生产系统里，提示词是你和模型之间的“接口规范”。它不该是一堆零散技巧，得像函数签名一样：明确角色、输入、任务、输出格式、约束与异常处理，并且要被版本化、被评测、被回归。
1.1 一条合格系统提示的骨架
推荐结构：角色与目标（你是谁、要完成什么）；输入说明（会收到什么字段）；任务步骤或判断规则；输出格式（最好给出 JSON Schema 或固定模板）；边界与拒答规则（不知道怎么办、不许做什么）；少量高质量示例。
别写“回答要专业简洁”这种虚的。直接写死：不超过 120 字、分三点、不要使用夸张形容词、无法判断时输出 UNKNOWN。规则能落地检查，才能做评测，才能稳定复现。
1.2 结构化输出：让下游程序能用
结果要给程序消费时，直接要求模型输出固定 JSON，代码侧做解析校验：查字段全不全、枚举值合不合法、类型对不对。解析失败就触发重试或降级，别让脏数据流到下游。
常见稳健做法：提示里直接写死「只输出 JSON、不要多余解释和 markdown 代码块」的强约束，再配一个示例；服务端用 Schema 做校验；关键字段提前设好兜底默认值。不少模型服务自带专门的「结构化输出/JSON 模式」开关，开了能明显减少格式漂移的情况。
模型输出要被程序解析时，最稳健的组合是？
1.3 少样本（Few-shot）与思维链（CoT）
零样本（Zero-shot）：直接下指令，适合简单任务。少样本（Few-shot）：给几个“输入→输出”范例，能快速统一风格与判断口径，范例要覆盖典型与边界情况，且避免把偶然规律当规则。思维链（Chain-of-Thought）：引导模型“先推理再结论”，能提升多步任务表现，代价是更多 Token 与延迟；面向用户时可只展示结论、把推理留在内部。
示例会长期占用上下文、推高成本，示例之间要是互相矛盾，反而会降低稳定性。一般 2~5 个高质量、覆盖边界的示例就够；规则能用文字讲清的时候，优先写规则，别堆示例。
1.4 上下文管理：决定稳定性的隐形战场
线上效果出波动，别先盯着提示词改，大概率是上下文的问题——要么被污染了，要么直接被撑爆了。常见的就三种情况：历史对话里混了错误信息、工具返回一大段没用的噪声、还有互相打架的指令。
1.5 提示的版本管理与回归
把提示当代码管：每次改完记版本、改的原因、评测分数。留一套固定评测集，不管是改提示还是换模型，先跑回归，分数没降才能上线。线上碰到的 Badcase 要收进测试样本里，走「发现—复现—修复—回归」的流程。
提示工程落地清单
是否有明确角色、任务、输出格式与拒答规则；是否对输出做了程序化校验与兜底；示例是否覆盖边界、是否相互一致；上下文是否做了裁剪与排序；是否有版本记录与评测集回归；失败时是否能降级到规则或人工。六条全满足，才算“工程化”，不是“试出来能用”。
关于提示工程，下列哪项是生产级做法？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
全量微调要更新模型全部权重，显存和存储成本极高。LoRA 假设「权重的更新量是低秩的」，冻结原模型，只在每层旁挂两个很小的矩阵 A、B 来近似权重变化，训练参数量可降到不到原来的 1%，一个基础模型能挂多套 LoRA 按需切换。代价是容量有限，适合风格、格式、垂直领域对齐；要注入大量新知识仍更适合 RAG 或继续预训练。