Prompt 工程十大误区：从过度设计到缺少评测
Prompt 工程十大误区：从过度设计到缺少评测
基础设施不需要漂亮话。
Prompt 工程被很多人当成一门玄学，也有人觉得它是调参的艺术。实际上 Prompt 工程的核心矛盾是两个：过度设计和缺少评测。过度设计让 Prompt 变得不可维护，缺少评测让你根本不知道 Prompt 改动有没有效果。这篇文章列了十个常见误区，每个都附带具体表现和修正方向。
一、背景：Prompt 工程为什么容易走偏
Prompt 是模型行为的控制接口，但它不像代码有编译器检查，不像配置有 schema 验证。Prompt 的效果取决于模型理解，而模型的理解和人的意图之间永远有偏差。这种偏差让人不断加条件、加约束，最终 Prompt 变成一篇小论文，但效果反而更差。
过度设计和缺少评测互为因果：没有评测标准，就只能凭感觉调 Prompt；凭感觉调 Prompt，就越调越复杂；越复杂越不好测；不好测就更凭感觉。
二、过度设计类四个误区
误区 1：堆砌约束条件，Prompt 越长效果越差
典型表现：一个简单的分类 Prompt，从 50 个字膨胀到 500 个字。加了"你必须仔细分析""不要输出任何无关信息""格式必须严格遵守""分三步思考""如果不确定就说不确定"……结果模型把精力花在理解约束上，反而忘了核心任务。
实测数据：同一个分类任务，50 字 Prompt 的准确率 92%，500 字 Prompt 的准确率 85%。因为模型在长 Prompt 中会混淆优先级，次要约束干扰了主要任务。
修正方向：Prompt 只写必要的约束。每加一条约束，问自己：这条约束删掉后，输出会变差吗？如果不确定，删掉它，然后测一下。
误区 2：追求万能 Prompt，一个 Prompt 打天下
典型表现：试图写一个 Prompt 同时处理多种任务——分类、总结、翻译、问答。万能 Prompt 的结果通常是：每样都能做，每样都不好。
模型对任务类型越明确，执行质量越高。"你是一个分类器"比"你是一个智能助手"效果好得多，因为后者给模型的指令空间太大，模型会在多种可能的行为之间摇摆。
修正方向：一个 Prompt 只做一件事。不同任务用不同 Prompt，通过路由逻辑分发。路由逻辑可以是一个轻量分类器（甚至是关键词匹配），成本远低于万能 Prompt 的质量损失。
误区 3：过度依赖格式要求，格式和内容冲突
典型表现："你的回答必须是一个 JSON 数组，每个元素包含 title、content、score 三个字段，score 必须是整数……"模型花了大量 Token 满足格式要求，内容质量反而下降。
更严重的情况：格式要求和内容逻辑冲突。比如要求"每个回答至少列出 5 条"，但某些场景只有 2 条有效内容，模型只好编造 3 条凑数。
修正方向：
- 格式要求尽量简单，只指定最关键的结构。
- 用 Output Schema（如 JSON Schema）而不是在 Prompt 里写格式说明，让框架层面做格式校验和修复。
- 不要强制数量约束（"至少 N 条"），让模型按实际情况输出。
误区 4：忽视模型特性，不同模型用同一套 Prompt
典型表现：给 GPT-4 写的 Prompt 直接拿去给 Llama-3 用。GPT-4 对复杂指令理解能力强，Llama-3 对简洁直接的指令响应更好。同样的 Prompt，GPT-4 准确率 90%，Llama-3 只有 70%。
不同模型的最佳 Prompt 策略差异明显：
| 模型 | 最佳策略 | 不适合的策略 |
|---|---|---|
| GPT-4 / Claude | 多步骤推理链 | 过度简化 |
| Llama-3 / Mistral | 简洁直接指令 | 长篇约束 |
| 小模型 (<7B) | 模板化 Prompt | 开放式任务 |
修正方向：Prompt 要按目标模型调优。如果同一 Prompt 需要适配多个模型，用适配层做轻量转换，而不是用一套万能 Prompt 强行兼容。
三、缺少评测类三个误区
误区 5：没有评测集，靠感觉判断 Prompt 效果
典型表现：改完 Prompt 后，手动试几个例子，觉得效果不错就发布了。问题是：3 个例子覆盖不了所有场景。你改了 Prompt 解决了一个边界情况，但可能破坏了 10 个正常情况。
修正方向：建立评测集。最少 50 个测试用例，覆盖正常场景、边界场景和典型错误场景。评测集的维护成本不高：从生产日志中抽取真实用户输入和期望输出，标注后作为评测集。
误区 6：只看单样本效果，不看统计指标
典型表现：评测集里某个 Prompt 在 90% 的用例上表现很好，但在剩下 10% 的用例上完全失败。有人只看 90% 的成功案例，忽略了 10% 的灾难性失败。
更常见的错误：只看平均分数，不看分布。平均准确率 85%，但某些场景只有 30%。30% 准确率的场景可能恰好是最重要的业务场景。
修正方向：评测指标不能只有一个数字。至少看三个维度：
- 整体准确率：所有用例的平均表现
- 最低场景准确率：最差场景的表现，这是风险底线
- 一致性：同一 Prompt 多次调用同一输入，输出的稳定性
误区 7：不做回归测试，Prompt 改动破坏已有能力
典型表现：为了优化场景 A 的效果改了 Prompt，场景 A 效果提升了 5%，但场景 B 的效果下降了 30%。因为没人跑场景 B 的评测，下降了两周才被用户投诉发现。
修正方向：每次 Prompt 改动后，跑全量评测集。评测集的覆盖率要足够广，不能只覆盖当前要优化的场景。建立 Prompt 变更的 CI 流程：改 Prompt → 跑评测 → 对比结果 → 准确率不低于基线才能发布。
四、方法论类三个误区
误区 8：把 Prompt 当代码写，追求结构化到极致
典型表现：Prompt 用 Markdown 格式写，分章节、有目录、有代码块标记、有变量占位符。看起来很专业，但模型不读 Markdown 目录。模型对 Prompt 的理解是连续的语义流，不是结构化的文档。
过度结构化的 Prompt 有两个问题：一是模型会忽略"章节"之间的关联，二是格式标记本身消耗 Token 却不提供语义信息。
修正方向：Prompt 用自然语言写，只在必要的地方用分隔符（如---或###）划分逻辑段落。不要为了好看而加格式，为了语义清晰才加结构。
误区 9：忽略版本管理，Prompt 改了不知道改了什么
典型表现：Prompt 改动在聊天记录里，没有 Git 版本，没有变更说明。两周后效果变差了，想回滚但不知道上一次有效的 Prompt 是什么版本。
修正方向：Prompt 和代码一样走 Git 管理。每次改动有 commit message 说明改了什么、为什么改、评测结果是什么。Prompt 文件放在代码仓库里，和业务逻辑一起版本化。
| 维度 | 不做版本管理 | 做版本管理 |
|---|---|---|
| 回滚 | 不知道回滚到哪个版本 | 一条命令回滚 |
| 排查 | 不知道哪个改动引入问题 | diff 定位问题改动 |
| 协作 | 多人各改各的 Prompt | PR Review 合并改动 |
| 审计 | 无法追踪变更历史 | 完整变更日志 |
误区 10：缺少团队协作规范，Prompt 各写各的
典型表现：三个工程师各写一套 Prompt，风格不同、约束不同、评测标准不同。上线后不知道用的是谁的 Prompt，排查问题时发现三个人写的是三个版本。
修正方向：制定 Prompt 写作规范：
- 格式规范：统一使用
{role}: {instruction}格式开头。 - 评测规范：统一评测集和评测指标，所有 Prompt 变动都跑同一套评测。
- 变更规范：Prompt 改动走 PR 流程，至少一个 Reviewer 确认评测结果。
- 命名规范：Prompt 文件按业务场景命名，如
customer_service_classifier.prompt.md。
五、总结：Prompt 工程的核心是评测不是设计
十个误区的共同根源：缺乏评测体系。没有评测，过度设计是唯一的选择——你不知道哪个约束有用，只好全部加上。没有评测，万能 Prompt 是自然的结果——你不知道不同场景的表现差异，只好一锅炖。没有评测，版本管理是多余的——你不知道改动效果，回滚无从谈起。
正确的优先级：
- 先建评测集：50 条以上，覆盖多场景。
- 用评测集驱动调优：每次改动有数据支撑。
- Prompt 保持简洁：只写必要约束，多余约束删掉。
- 版本化管理：Git + CI，改动可追踪可回滚。
- 按模型适配：不同模型用不同策略，不要一刀切。
基础设施不需要漂亮话，Prompt 的好坏用数据说话，不是用长度说话。