1. 从「超体」说起为什么模型选型和 Prompt 工程是一件事「超体」这个系列名字起得挺有意思它暗示的不是某一个具体模型而是一种“超越单一模型能力”的工程化思路。我在过去一年多里帮团队和外部客户落地过十几个大模型应用从客服问答、合同解析到代码辅助踩过的坑几乎都集中在两个环节模型选型和Prompt 工程。很多人把这两件事分开看觉得先选个“最强模型”再随便写写提示词就完事了。实际做下来你会发现选型决定了你的能力上限和成本底线而 Prompt 工程决定了你能把这个上限发挥出几成。两者是乘法关系不是加法关系。这篇文章面向的是已经动手做应用、或者正准备把大模型接进业务系统的开发者、产品经理和技术负责人。我会把「超体」模型选型与 Prompt 工程这套方法论拆开讲透怎么根据任务类型、延迟要求、成本预算、数据合规要求去筛模型怎么写提示词才能让输出稳定、结构化、少幻觉怎么用工程手段把 Prompt 变成可维护、可测试、可迭代的资产。全文没有玄学都是能直接抄作业的步骤和参数。先给一个我常用的判断框架后面所有内容都围绕它展开维度核心问题影响任务类型是生成、抽取、分类还是推理决定模型能力需求输出形态自由文本还是结构化 JSON决定 Prompt 策略延迟要求实时对话还是离线批处理决定模型规模和部署方式成本预算按 token 付费还是自建推理决定选型范围数据合规数据能否出内网决定本地部署还是 API迭代频率Prompt 多久改一次决定工程化程度这六个维度里只要有一个是硬约束选型范围就会大幅收窄。比如数据不能出内网那基本就锁定本地部署路线如果要求首 token 延迟低于 500ms那 70B 级别的模型在消费级显卡上就很难达标。先把约束条件列清楚再去谈“哪个模型好”否则就是空谈。2. 模型选型别追榜单先看你的约束条件2.1 主流模型的能力分层与适用场景我不太喜欢直接给模型排名因为榜单更新太快而且很多榜单和真实业务表现差距很大。更实用的做法是按能力分层然后对号入座。下面这张表是我根据实际项目经验整理的覆盖了目前常见的几类模型层级典型代表参数量级适合任务不适合任务轻量级Qwen2.5-7B、Llama-3.1-8B7B-9B分类、抽取、简单问答复杂推理、长文生成中量级Qwen2.5-14B、Yi-1.5-9B9B-14B结构化输出、中等推理多步数学、代码生成重量级Qwen2.5-72B、Llama-3.1-70B70B复杂推理、长文写作高并发实时场景超大规模闭源旗舰 API未公开综合能力最强数据合规敏感场景这里要强调一个反直觉的点不是所有任务都需要大模型。我做过一个合同关键信息抽取的项目最初用 70B 模型准确率 92%但单次推理成本高、延迟大。后来换成 7B 模型做微调准确率反而到了 95%因为任务足够窄小模型在特定分布上更容易拟合。所以选型的第一步不是“哪个模型最强”而是“我的任务到底需要多强的通用能力”。2.2 本地部署还是 API 调用一笔算得清的账这是每个项目都会遇到的决策。我的建议是先用 API 快速验证验证通过后再评估是否转本地。原因很简单API 的试错成本几乎为零而本地部署从环境配置到推理优化没有一周时间下不来。但有些场景必须本地部署比如数据不能出内网、调用量极大导致 API 成本不可接受、或者需要极低延迟。本地部署的硬件门槛我整理如下模型规模最低显存推荐显存量化后显存典型硬件7B8GB16GB4-6GBRTX 3060/406014B16GB24GB8-10GBRTX 409032B24GB48GB16-20GB双卡 409070B48GB80GB24-32GBA100/H100量化是本地部署的关键手段。4-bit 量化能把显存需求降到原来的四分之一左右代价是精度略有下降。我实测下来7B 模型 4-bit 量化后在抽取类任务上精度损失不到 2 个百分点完全可接受。推理框架方面llama.cpp 适合 CPU 和低显存场景vLLM 适合高并发 GPU 场景Ollama 适合快速验证。选哪个取决于你的并发量和硬件条件。注意本地部署不是一劳永逸的。模型更新、推理框架升级、驱动兼容性问题都会持续消耗维护精力。如果团队没有专门的运维人力API 调用往往是更务实的选择。2.3 一个可复用的选型决策流程我把选型流程固化成四步每次新项目直接套用明确硬约束数据合规、延迟上限、成本上限、并发量。这四项只要有一项不满足直接排除对应方案。任务能力匹配用 20-50 条真实样本在 2-3 个候选模型上跑一遍看基础能力是否达标。这一步不要用公开榜单一定要用你自己的数据。成本与延迟实测对达标模型做压力测试记录首 token 延迟、吞吐量、单次调用成本。很多模型在单条测试时表现很好一上并发就崩。留出替换空间无论选哪个都要在架构上把模型调用抽象成接口方便后续替换。我见过太多项目把模型调用写死在业务代码里换模型时改到崩溃。这四步走完选型基本不会出大错。剩下的就是 Prompt 工程的事了。3. Prompt 工程让模型稳定输出的核心手法3.1 结构化输出从“求它”到“逼它”大模型最让人头疼的问题之一就是输出不稳定。你让它返回 JSON它有时候给你加个“好的以下是结果”有时候字段名大小写不一致有时候干脆少一个字段。解决这个问题靠的不是反复祈祷而是工程手段。最基础的做法是在 Prompt 里明确输出格式并给出示例。但光这样还不够我通常会叠加三层保障第一层格式约束。在系统提示词里写清楚“只输出 JSON不要任何解释文字”并给出完整的字段定义和示例。第二层参数控制。把 temperature 调到 0 或 0.1减少随机性。对于抽取类任务temperature 设为 0 是标配。第三层后处理校验。用代码对输出做 JSON 解析解析失败就重试或走兜底逻辑。这三层下来结构化输出的成功率能从 70% 提到 98% 以上。如果还不行那就考虑用支持结构化输出的 API 参数比如某些平台提供的 JSON mode 或 function calling能从解码层面保证格式正确。3.2 防幻觉让模型“不知道就说不知道”幻觉是大模型落地最大的信任障碍。我处理过的项目里幻觉主要出现在三种情况模型知识盲区、Prompt 诱导性太强、上下文信息不足。对应的解法也不一样。对于知识盲区最有效的手段是RAG检索增强生成。先把相关资料检索出来塞进上下文再让模型基于资料回答。但 RAG 本身也有坑检索不准照样幻觉。我的经验是检索召回率比精度更重要宁可多召回几条让模型自己判断也不要漏掉关键信息。对于 Prompt 诱导要避免问“为什么 X 是对的”这种预设结论的问题。改成“根据以下资料X 是否成立如果不成立请说明原因”。把开放式问题改成验证式问题幻觉率会明显下降。对于上下文不足要在 Prompt 里明确指示“如果资料中没有相关信息请回答‘资料中未提及’不要自行推测。”这句话看起来简单但实测能减少大量编造内容。提示防幻觉不是一次性的需要持续用真实 bad case 去迭代 Prompt。我习惯建一个“幻觉案例库”每次发现新的幻觉模式就补一条约束进去。3.3 上下文工程把对的资料放在对的位置Prompt 工程往上走一层就是上下文工程。模型能看到的全部内容——系统提示、历史对话、检索资料、用户输入——都是上下文的一部分。上下文的质量和排列方式直接决定输出质量。我总结了几条实操原则重要信息放两头。模型对上下文开头和结尾的信息注意力更强中间容易忽略。所以关键指令放开头关键资料放结尾。控制上下文长度。不是越长越好超出模型有效窗口后中间内容会被稀释。我一般控制在模型窗口的 60%-70%。用分隔符明确边界。资料和指令之间用---或 XML 标签隔开避免模型混淆。历史对话做摘要。多轮对话场景下不要把所有历史都塞进去定期做摘要压缩。这些原则听起来简单但每一条都能带来可测量的效果提升。我在一个客服项目里仅仅调整了资料和指令的顺序回答准确率就提升了 8 个百分点。4. 实操落地从 Prompt 草稿到可维护的工程资产4.1 搭建 Prompt 开发与测试环境Prompt 工程不能靠“在聊天框里试”。你需要一个可版本管理、可批量测试、可对比效果的环境。我的做法是用 Python 脚本加配置文件把 Prompt 模板、测试样本、评估指标都管起来。一个最小可用的目录结构是这样的prompt-project/ ├── prompts/ │ ├── extract_v1.txt │ ├── extract_v2.txt │ └── system.txt ├── data/ │ └── test_cases.jsonl ├── eval/ │ └── evaluate.py └── config.yamlprompts/放不同版本的提示词模板data/放测试样本eval/放评估脚本。每次改 Prompt 就新建一个版本文件跑一遍评估对比指标。这样你永远知道哪个版本效果最好也方便回滚。评估脚本的核心逻辑是加载测试样本对每条样本调用模型把输出和预期结果对比计算准确率、格式合规率、幻觉率等指标。下面是一个简化示例import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) def load_prompt(path): with open(path, r, encodingutf-8) as f: return f.read() def run_eval(prompt_path, test_file): prompt_template load_prompt(prompt_path) results [] with open(test_file, r, encodingutf-8) as f: for line in f: case json.loads(line) filled prompt_template.replace({{input}}, case[input]) resp client.chat.completions.create( modelqwen2.5-7b, messages[{role: user, content: filled}], temperature0 ) output resp.choices[0].message.content results.append({ input: case[input], expected: case[expected], output: output, match: case[expected] in output }) acc sum(r[match] for r in results) / len(results) print(f准确率: {acc:.2%}) return results这个脚本很粗糙但足够让你开始量化 Prompt 效果。有了它你改 Prompt 就不是凭感觉而是看数据。4.2 结构化输出的完整实现方案回到结构化输出这个高频需求我把完整方案拆成四步第一步定义 Schema。用 JSON Schema 或 Pydantic 模型把输出结构定义清楚。字段名、类型、是否必填、取值范围都写明白。第二步生成 Prompt。把 Schema 转成自然语言描述塞进 Prompt同时给一个完整示例。示例比描述更重要模型模仿示例的能力很强。第三步调用与解析。调用模型后用 JSON 解析器解析输出。解析失败时先尝试修复常见问题比如去掉 markdown 代码块标记再失败就重试。第四步校验与兜底。用 Schema 校验解析结果字段缺失或类型错误就走兜底逻辑比如返回默认值或转人工。这套方案我在合同解析、简历抽取、工单分类三个场景都用过结构化输出成功率稳定在 97% 以上。关键点是示例要足够典型覆盖边界情况。4.3 多轮对话中的上下文管理多轮对话是另一个高频场景也是 Prompt 工程容易翻车的地方。核心问题是上下文会越来越长成本和延迟都会上升而且模型容易“忘记”早期指令。我的做法是分层管理上下文层级内容处理方式系统层角色定义、输出格式、核心约束每轮都带不压缩摘要层历史对话的滚动摘要定期更新控制长度近期层最近 3-5 轮完整对话原样保留检索层当前问题相关的资料按需检索动态插入这样既保留了关键信息又控制了上下文长度。摘要层用一个小模型来生成成本很低。实测下来这套方案在 20 轮以上的对话中回答一致性明显优于“全量历史”方案。5. 常见问题与排查技巧实录5.1 输出格式不稳定的排查路径这是最高频的问题。排查顺序我一般是这样的检查 temperature。如果大于 0.3先调到 0 试试。很多格式问题就是随机性导致的。检查 Prompt 是否有歧义。比如“返回 JSON”和“返回 JSON 格式的结果”效果可能不同后者更明确。检查示例是否完整。示例里字段名、嵌套结构、空值处理都要覆盖。检查模型是否支持结构化输出。有些小模型对 JSON 格式的遵循能力较弱换模型或加 few-shot 示例。检查后处理逻辑。有时候模型输出是对的是解析代码写错了。按这个顺序走90% 的格式问题都能定位到。5.2 幻觉问题的分类与对策幻觉不是一种问题是好几类问题的统称。我把它分成三类对策各不相同幻觉类型表现对策知识型幻觉编造不存在的事实RAG 明确指示“不知道就说不知道”指令型幻觉忽略约束自由发挥强化系统提示用验证式提问格式型幻觉输出结构错误结构化输出方案 后处理校验分类之后排查就有方向了。我见过一个项目团队一直在调 Prompt 防幻觉结果发现是检索模块返回了错误资料模型只是“忠实地”基于错误资料回答。所以遇到幻觉先确认输入上下文是否正确再怀疑模型。5.3 成本与延迟优化的实战技巧当应用跑起来之后成本和延迟就是持续要优化的指标。我常用的手段有这几个Prompt 压缩。去掉冗余描述用更短的表达。我做过一个项目Prompt 从 800 token 压到 400 token效果不变成本直接减半。缓存。相同或相似的请求结果缓存起来命中缓存直接返回。对于 FAQ 类场景缓存命中率能到 40% 以上。模型分级。简单任务用小模型复杂任务用大模型。用一个分类器先判断任务难度再路由到不同模型。流式输出。首 token 延迟比总延迟更重要流式输出能让用户感觉更快。批处理。离线任务攒一批一起跑吞吐量能提升好几倍。这些手段叠加起来成本和延迟都能降一个数量级。关键是要先测量知道瓶颈在哪再针对性优化。5.4 一个真实项目的踩坑记录最后分享一个我印象最深的项目。任务是解析招标文件输出结构化的项目信息、资质要求、时间节点。最初方案是用 70B 模型加详细 Prompt准确率 85% 左右但有两个问题一是长文档超出上下文窗口二是页码和章节引用经常错。第一个问题的解法是分块处理把长文档按章节切分每块单独抽取最后合并。第二个问题的解法是在 Prompt 里明确要求输出原文片段和页码并在后处理时校验页码是否在合理范围内。改完之后准确率到了 93%但还有 7% 的错误集中在表格和扫描件上。这部分最后是加了 OCR 预处理和表格专项解析才解决的。这个项目让我深刻体会到Prompt 工程不是万能的数据质量、文档解析、后处理校验每一环都要做好最终效果才是各环节的乘积。提示文档解析类项目一定要先做数据质量评估。如果原始文档本身模糊、格式混乱再强的模型也救不回来。先解决数据问题再谈模型和 Prompt。6. 把 Prompt 当成代码来管理写到这里我想强调一个观念转变Prompt 不是“提示词”是“程序”。它和代码一样需要版本管理、测试、评审、回滚。我见过太多团队把 Prompt 散落在各个聊天记录和文档里改一次就丢一次出了问题无法追溯。我的做法是把 Prompt 纳入 Git 管理每次修改都走代码评审流程评估脚本作为 CI 的一部分自动跑。这样 Prompt 的质量就有了工程保障而不是依赖某个人的“手感”。具体来说我会给每个 Prompt 文件加头部注释记录作者、修改日期、适用模型、已知限制。评估脚本在每次提交时自动运行准确率下降超过阈值就阻断合并。这套流程听起来重但跑顺之后Prompt 迭代速度反而更快因为你知道每次改动的影响是什么。模型选型和 Prompt 工程本质上都是在不确定中寻找确定性。模型的能力边界是不确定的输出的稳定性是不确定的但通过系统化的选型流程、结构化的 Prompt 设计、工程化的管理手段我们可以把这些不确定性压缩到可接受的范围内。这就是「超体」系列想表达的核心不是追求某个完美模型或完美提示词而是建立一套让结果稳定可靠的工程体系。