不知道你最近有没有这种感受大模型的能力天花板好像越来越不是瓶颈真正卡住项目进度的是“结果不稳定”。同一个 Prompt 今天能跑出 90 分的效果明天可能直接给你胡编一段换一个模型之后原本好用的提示词又失灵了。我自己的系列项目“超体”做到第三期的时候对这种痛感特别深。所以这一篇我想认认真真聊一下模型选型和 Prompt 工程——这两件事不是各自独立的“配置步骤”而是一套组合拳核心目的只有一个让大模型稳定输出高质量结果。这篇文章适合谁如果你正在接大模型 API、正在做私有化部署、被输出格式问题和幻觉问题折腾过或者纯粹是刚入坑不知道选哪个模型、怎么写提示词这篇都能给你一套能直接落地的思路。我不会只给结论会把选型时真正的判断依据、Prompt 设计的分层方法、以及我用过之后觉得最管用的稳定性手段全部拆开讲。1. 选型不是跑分游戏先搞清楚你的场景在问什么1.1 从结果反推选型三类核心决策场景很多人在模型选型的时候第一反应是去看榜单谁排在前面就选谁。这个思路不能说完全错但放到实际项目里非常容易翻车。我见过不少团队花了不少钱接入了一个“天花板很高”的大模型结果做业务场景时发现输出格式不稳定、延迟扛不住、私有化又部署不上最后又灰溜溜换掉。我的建议是反过来先想清楚你的场景到底在问什么。我把“超体”系列里反复遇到的场景归成三大类每一类的选型侧重完全不同。场景类别典型任务核心诉求选型侧重通用文本生成文案改写、摘要总结、对话回复语言流畅度、逻辑连贯性关注模型基座的预训练质量和指令跟随能力知识处理与抽取合同关键字段抽取、文档分类、信息标准化格式稳定、漏报率低、可解析性强关注结构化输出能力和上下文长度复杂推理与分析代码审查、数学推理、多步决策推理正确率、细节保留关注推理能力和思维链支持有时需要更大参数规模以合同关键字段抽取为例。你其实不需要一个会写诗、会聊天、什么都能聊的“全才模型”你需要的是一个能稳定输出 JSON、不要漏字段、不要自己加戏的“偏科选手”。这种情况下选一个擅长指令跟随、上下文窗口足够大、且对中文格式化输出友好的模型往往比选一个综合分最高但硬要它输出结构化结果时经常跑偏的模型更容易落地。1.2 四个容易踩坑的选型维度抛开榜单我在实际选型里主要看四个维度参数量与部署资源、上下文长度、领域适配度、生态与工具链。这四个维度如果不仔细核对很容易踩坑。第一参数量不是越大越好。70B 的模型效果好但你要先回答一个问题它的量化部署带宽能不能支撑你的业务峰值如果你只有 4 张消费级显卡跑一个 70B 的量化模型推理速度可能只有几个 token 每秒这种体验在真实业务里基本不可用。反过来7B 到 14B 的模型经过良好微调之后在特定任务上的表现可能完全够用而且部署成本和功耗都低一个量级。从我自己的项目经验看任务越聚焦小模型的性价比优势越明显。第二上下文长度要结合你真实要塞进去的内容算而不是看官网标称值。现在的模型动不动就宣传 128K 甚至 200K 上下文但不要忘了上下文越长注意力计算开销越大推理延迟越高而且模型对长上下文中“中段内容”的注意力密度往往明显下降。我建议你按最坏情况算一遍你的业务单次调用最多要喂多少字的输入材料在这个基础上加 30% 的缓冲再决定要不要选长上下文版本。如果不满足优先做滑动窗口切分而不是硬上一个更贵的“长上下文款”。第三领域适配度要看预训练数据的覆盖面和基座风格。比如做工业质检、服装检测这类任务如果业务里全是行业暗语和特殊名词通用模型很容易理解偏差。这时候两个路径一是用一份几百条到几千条的领域样本去跑 GPT 级模型的上下文注入或少样本 Prompt先测一下效果二是直接找垂直领域基座做专业微调或选已经做了行业适配的模型。不要一上来就微调先测试再决定。第四生态与工具链经常被忽略。同一个模型在不同推理框架下的表现差异可能很大比如用 vLLM 部署和用原生 Python 脚本调用吞吐量能差出好几倍。你要提前确认目标模型是不是你选中的推理框架官方支持的格式而不是模型发布方的 Demo 能跑就万事大吉。此外输出能不能方便地开 JSON Mode、能不能控制随机种子、能不能动态调整采样参数这些都会直接影响你后续 Prompt 工程的效率。1.3 “超体”系列第三期的选型复盘回到我自己的“超体”项目。第三期的核心任务是做一个多文档的知识抽取助手需要从用户上传的一堆 PDF 里提取结构化条目。最开始我图省事直接调一个综合能力很强的商用 API结果格式倒是能出 JSON但字段频繁出现遗漏偶尔还会把两篇不同文档的信息悄悄合并到一起。后来我把选型思路改成“场景倒推”任务本质是抽取不是生成那我优先找指令跟随能力好、支持 JSON Mode、且跑私有化部署社区生态比较好的开源模型。把候选模型缩小到两个再实际搭一个最小验证集用一个统一的 Prompt 模板各跑二十遍对比字段完整率和格式错误率拿数据说话。最后选了一个 13B 级别的模型量化后单张 24G 显卡就能跑延迟和稳定性完全满足业务要求。这个过程让我深刻体会到选型做得越扎实后续 Prompt 工程需要做的“对抗性补丁”就越少。2. Prompt 工程的核心不是“写提示词”而是压低不确定性2.1 输出不确定性的四个来源很多刚接触大模型的朋友以为 Prompt 工程就是“把话说清楚一点”其实这是它最小的那一部分。真正值得花精力的是理解输出的不确定性从哪里来然后一个一个去掐掉。我在实操中总结出四个主要来源。第一个是采样随机性这个词本身就有概率属性temperature 不为 0 时同一个 Prompt 跑两次结果可能不同。第二个是指令歧义同一个词、同一个要求模型在不同上下文里可能给出不同理解。第三个是上下文干扰输入材料里的无关信息、冗余表述、甚至文档排版符号都可能把模型的注意力带偏。第四个是解码参数敏感度top_p、frequency penalty 这些参数对结果的影响往往比很多人以为的要大得多。搞明白这四个来源之后你对 Prompt 设计的看法就会从“怎么写更自然”转换成“怎么设计能降低随机性、减少歧义、隔离干扰、收紧解码空间”——这个思路上的转变是 Prompt 工程真正开始起作用的地方。2.2 分层提示词设计System 层 / Task 层 / Output 层我建议把提示词拆成三层就像写代码要分层一样每一层管好自己的职责。不要所有内容都糅在一段长长的指令里。第一层是 System 层负责定义“你是谁、工作原则是什么”。比如面对抽取任务System 层会写“你是一名严谨的信息抽取助手只根据用户提供的材料输出结果绝不自行补充材料中没有的信息。”这一层的作用是给模型一个稳定的角色锚点让它在整个对话过程中都保持一种工作姿态而不是被后文带偏。第二层是 Task 层负责定义“这次具体要做什么”。把任务目标、输入材料、处理步骤、边界条件写清楚。这里有一个容易忽略的技巧尽量把任务描述成“一个流程”而不是一句“要求”。比如“先定位所有包含合同金额的句子再提取金额数值、币种、付款条件然后汇总成清单”这种流程化的描述比“帮我提取合同里的金额信息”稳定得多。第三层是 Output 层负责定义“输出的格式长什么样”。直接给出 JSON 示例或字段说明表明确每个字段的类型、取值范围、是否必填。这一步尤其重要因为大模型对“格式约束”的理解能力比对“自然语言描述”的理解能力要稳定得多。我一般会在 Output 层里直接给一个完整的输出示例然后写一句“严格按上述 JSON Schema 输出不要输出其他内容。”这三个层次拼起来之后你会发现很多原先靠“多说话、多强调”才能勉强稳住的效果现在用几条清晰约束就能达到而且整体 Prompt 变短了、变规则了、也更容易维护了。2.3 让模型“答其所问”任务边界和否定约束的写法关于否定约束我踩过不少坑。很多 Prompt 模板里会写“不要输出无关内容”“不要编造信息”但你有没有发现写完这种句子模型还是照样犯错原因很简单大模型是“生成器”它对否定词的敏感度比对肯定词的敏感度低很多。你告诉它“不要编造”它记住的重点往往落在“编造”两个字上。更有效的做法是用“行为替换”代替“否定描述”。把“不要编造信息”改成“只输出输入材料中明确出现的内容材料未提及的内容一律标记为unknown”。把“不要输出无关内容”改成“输出内容必须限定在三个字段内任何不在这三个字段里的信息都不输出”。这样模型接到的指令就从“禁止做某事”变成“明确应该做什么、遇到边界时怎么办”行为稳定程度会明显提高。另外任务边界也可以体现在“输入材料的分隔”上。如果同时喂了多份文档我建议在每份文档前后加上清晰的标记符号比如document iddoc_001 这里是第一份文档的内容。 /document document iddoc_002 这里是第二份文档的内容。 /document这样模型在抽取时能更准确地关联来源减少跨文档信息合并的概率。这也是我在“超体”第三期里处理多文档抽取时最管用的一个小改动。3. 结构化输出是稳定性的真正抓手JSON 约束与解析容错3.1 JSON 约束为什么比文字约束可靠如果你只需要模型返回一段“通顺的话”那 Prompt 怎么写都相对随意。但一旦你希望把输出接进业务系统情况就完全不同了。自由文本里哪怕只有一个字段名对不上后端解析就会崩。所以我的原则是凡是需要进入程序流程的输出一律优先要求结构化 JSON。为什么 JSON 约束比文字约束可靠因为这个约束不再依赖模型对语言的“感觉”而是依赖它对一个“格式框架”的遵循。模型在预训练阶段见过海量 JSON 数据对键值对、数组、嵌套结构的生成规律比自然语言更敏感。只要你在 Prompt 里给出足够清晰的 JSON Schema 和示例它生成合法 JSON 的概率要远远大于生成一段“恰好能解析”的自然语言。当然即使是 JSON 约束也做不到 100% 稳定。模型偶尔会多一个逗号、少一个括号、把枚举值写成了一个相似的变体。所以如果后端要求强稳定我建议在前端代码里再做一层 JSON Schema 校验不合法就触发重试或修复逻辑而不要天真地“相信”模型任何一次输出都符合规范。3.2 从 Prompt 到代码双层校验的落地示例这里给一段我在项目里经常用的 Python 示例展示怎么在 Prompt 里声明 JSON 约束再用代码做双层校验。Prompt 里的 Output 层大概是这样的请以 JSON 对象输出格式如下 { items: [ { id: string, title: string, amount: number, currency: string, source_doc_id: string, confidence: number } ] } 要求 1. 只能输出 JSON不要附加任何解释文字。 2. 字段缺失时用 null 填充不要自行猜测。 3. amount 只保留数值不要带货币符号。后端的解析和校验代码可以这样写import json from jsonschema import validate, ValidationError def parse_model_output(raw_text: str) - dict: # 第一层提取 JSON 子串并解析 start raw_text.find({) end raw_text.rfind(}) if start -1 or end -1: raise ValueError(输出中未找到有效 JSON 起始标记) json_str raw_text[start:end 1] data json.loads(json_str) # 可能抛出 JSONDecodeError # 第二层用 Schema 做字段校验 schema { type: object, properties: { items: { type: array, items: { type: object, required: [id, title, source_doc_id], properties: { id: {type: string}, title: {type: string}, amount: {type: number}, currency: {type: string}, source_doc_id: {type: string}, confidence: {type: number} } } } }, required: [items] } validate(instancedata, schemaschema) return data这段代码的逻辑很简单先用字符串首尾查找 JSON 大括号来截取模型输出里的 JSON 部分然后交给 jsonschema 做字段合法性校验。校验不通过时抛出的 ValidationError 会被上层捕获触发重试或告警。实测下来加上这层校验之后很多格式错误的输出都进不到业务逻辑层系统的鲁棒性一下子提升了不少。3.3 字段级容错缺省、枚举、数量校验就算有了 JSON 校验业务字段本身也可能出现“合法但不正确”的情况。比如抽取的结果是amount: 1000但原文档里写的是“约1000元人民币”。模型可能给出了一个不精确的数值而你的业务系统需要用精确值。这时候只靠格式校验是不够的还必须在代码里加字段级规则。我常用的几个校验规则大致是这样的异常类型表现处理方式字段缺省必填字段为 null 或不存在将该条目标记为“待人工确认”或触发重试枚举值越界输出值不在预定义列表中做相似度映射如“人民币”映射为“CNY”映射不上则拒绝数值范围异常数值超出业务允许范围结合业务规则校验超限时拒绝或提示数量不一致抽取条数与文档实际内容不匹配对比文档段落统计特征异常时扩大召回重跑字段级校验做扎实之后你才能真正放心地把大模型输出接入下游流程。在我经手的项目里“模型输出 格式校验 业务规则校验”三件套是稳定输出的最低配置。只做到其中一两层的项目上线之后大概率要花不少额外精力去补坑。4. 把 Prompt 当业务代码管版本化与最小回归集4.1 为什么 Prompt “调一次就忘”是最大的隐性成本很多人调 Prompt 是“手感流”。今天多写了一句“请确保”明天把某句挪到前面效果好了就保存一份过几天又忘了当初为什么这么调。等模型版本一升级之前“好不容易调出来”的效果可能直接崩掉却根本找不到是哪次改动引起的。这个问题真正的成本不只是“重新调试”的时间成本而是“不可复现”的项目风险。团队里任何一个人离职或休假另一个接手的人面对一份没有版本的 Prompt几乎只能从头开始。这也是我为什么强烈建议把 Prompt 工程当成业务代码来管要有版本、有测试集、有回归记录。4.2 最小回归集低成本建立评估基线做回归测试之前先要有一个评估集。不用多几十条到两三百条覆盖主要业务场景的样本就够了。关键是每一条样本都要有“标准答案”或“可判定标准”这样你才知道哪次改动是进步、哪次是退步。比如“超体”里的知识抽取任务我维护了一个 50 条的小评估集覆盖不同文档类型、不同字段组合、不同的干扰文本。每改一次 Prompt就把这 50 条跑一遍统计字段完整率、格式正确率和幻觉率也就是抽取了原文没有的信息的条数占比。这些指标不追求漂亮只求稳定可对比。4.3 必备的版本管理文件夹结构与评测记录具体执行上我建议直接引入代码仓库管理不要只靠文件名后缀区分。一个简单的目录结构大概是这样prompts/ system_v1.md system_v2.md task_contract_v1.md task_contract_v2.md output_schema_v1.json output_schema_v2.json eval/ cases/ case_001.md case_002.md results/ v1_result.md v2_result.md metrics.py每次改动 Prompt就新建一个版本文件并在评测记录里写下这次改了什么、为什么改、回归结果如何。这个习惯看起来多做了一步实际上是在给项目上保险。等到哪天上线的新模型效果突然不如预期你翻一翻版本记录很快就能定位到“模型升级 哪个提示词版本”的组合问题。4.4 业务侧自动测试的轻量实现如果团队有工程条件还可以把回归测试做成每天自动跑一遍。核心逻辑很简单定时任务读取 Prompt 文件和评估集调用模型生成结果然后跑解析与校验脚本最后把各项指标写回一个记录文件。这样模型方任何一次升级、Prompt 任何一次修改都可以快速发现影响。我经常开玩笑说Prompt 工程做到后面不是“怎么写提示词”而是“怎么度量提示词”。有度量才有迭代有回归才有稳定。大模型本身是不确定的但你的研发流程可以做到确定性很强这个确定性就是稳定输出的最终保障。5. 提示词之外的工程护栏让不稳定变得可预期5.1 与模型无关的兜底方案不管选型多合适、Prompt 写得多好模型偶尔还是会给你一个意料之外的输出。这时候真正能救场的是一层与模型无关的兜底方案。我在业务系统里一般会做一个重试机制。比如模型输出 JSON 校验失败时自动把温度降到 0.1 再重试一次如果还是失败就把失败信息和模型原始输出记录下来发送告警或走人工兜底。这种“先降温度再重试、重试失败再人工”的三级阶梯比单纯增加调用次数要高效得多因为很多格式错误在一开始的采样参数下是概率性出现的稍微调一下解码空间的随机性就可能恢复正常。5.2 上下文窗口管理Token 预算分配必须提前规划另一个容易被忽略的护栏是 Token 预算。业务方往往只顾着往 Prompt 里塞内容不到模型报错“上下文长度超限”的根本不会想到要做预算。但等真到报错那一刻基线已经崩了。我习惯在代码里提前做 Token 预算分配把每次调用的总 Token 拆成三块系统提示词固定占用、任务级输入材料动态占用、输出预留空间。比如给定一个 32K 上下文窗口的模型我会留出 4K 给输出、2K 给系统指令和输出 Schema剩下 26K 全部留给输入材料。输入材料超过 26K 时做滑动窗口切分或按重要度排序而不是盲目要求模型“先读完再回答”。这样做的好处是即使材料很长模型也始终有足够的输出空间来生成合规的 JSON不会因为残余空间不足而截断。类似这样的细节往往就是线上效果“稳”和“不稳”的分水岭。5.3 关于微调和本地部署热词的冷静看待最近“大模型微调”“本地部署私有化模型”这两个方向的热度很高但我建议冷静选型。微调确实能提升特定任务的风格和领域能力但它不是解决“输出不稳定”的第一选择也不适合在业务早期、样本不足时贸然引入。一样的道理本地部署私有化模型也不是“一上就稳定”你仍然要面对量化质量、推理框架兼容性、上下文长度受限、GPU 显存不足等一系列工程问题。我自己实际用的方案是先用一套少量样本验证 Prompt 加结构化输出的效果确认方向之后再决定是否需要微调如果业务数据涉密或延迟敏感再认真评估私有化部署的推理框架和显卡配置。不要因为概念热就一拥而上每一步都从“它能不能真正降低成本、提高稳定性”这个角度出发才能避免热门技术变成资源黑洞。6. 一点个人体会与后续可做的事写到这里我想再分享一个实际感受。做“超体”第三期的时候我最大的教训就是不要指望“一次调出一个完美 Prompt”而要建立一个允许模型偶尔出错、但系统依然能稳定工作的环境。模型选型解决的是“能力下限”Prompt 工程解决的是“能力发挥度”而工程护栏解决的是“意外发生时有兜底”。这三件事缺了任何一件稳定输出都只能是运气。如果你正准备做类似的大模型应用项目我的建议是从一个小而全的纵向切片开始选定 10 条业务样本、写一个三层结构的 Prompt、设计一个 JSON 输出 Schema、跑通解析校验、记录一轮评估结果。这几十条代码和几十条测试数据看起来不多但它能让你在动手铺开业务之前先建立一套“可度量、可回归、可迭代”的稳定输出机制。后面所有的新需求、新模型、新场景都在这套机制上生长你就不太容易再次陷入“调一次忘一次、换一个模型崩一遍”的循环里。后面如果继续做这个系列我会把“超体”项目里评估集构建和指标定义的具体方法单独写一篇因为这件事决定了你看到的每一句“稳定”“不稳定”背后到底有没有依据。也希望你在自己的项目里从一开始就留出做评估的时间哪怕只是几十条样本后面回头看你会感谢当时这个决定。