文章
提示词工程优化思考
大模型帮你生成的提示词，往往看起来辞藻华丽、规则罗列得密密麻麻。你手里的这套提示词已经写得很规范了，但为什么会卡在 70% 的准确率动不了？
因为大模型写提示词，往往是以“文学家”的视角在堆砌形容词；而真正的提示词工程（Prompt Engineering），其实是“程序员”的逻辑工程。你把它当成写代码的重构过程，思路立马就通了。
要将这套提示词的成功率从 70% 拔高到 90% 以上，不需要你精通什么魔法，只需要掌握以下 4 个工业级的调优核心：
🚀 核心一：引入“思考链”（Chain of Thought），打破模型的“强直输出”
这是你目前提示词里最大的性能瓶颈。 你在提示词里严格要求：请严格输出合法的 JSON 数组，不要包含任何 Markdown 标记，如果通过则保持沉默。
- 为什么卡在70%： 质检是一个高难度的推理任务，需要对比 5 大类红线。你让大模型“一眼看到底”，不给它任何思考和喘息的空间，要求它在脑子里推理完直接蹦出最终的 JSON 结果。这会导致模型在处理长文本或复杂语境时，大脑直接“过载”，从而漏检或误判。
- 调优方案（90%的核心）： 允许模型先“碎碎念”，再给结果。
💡 重构思路： 修改输出格式，允许模型先输出一个 <thinking> 标签，在里面让它一条条写下推导过程，最后再输出 JSON。
修改后的输出示例：
<thinking>
正在分析第 1 条数据...
问题没有残留。但答案中出现了“根据参考材料可知”，触发了第一大类第4条红线。判定：Fail。
</thinking>
[
{
"original_question": "...",
"fail_reasons": ["触发第一大类第4条红线：包含依赖外部材料的话术"]
}*注：后续你可以用 Python 脚本非常轻松地用正则把 `<thinking>` 标签里的内容切掉，只保留 JSON，但模型的准确率会因为这几十个 Token 的思考过程获得飙升。*🚀 核心二：Few-Shot 提示（少样本提示）—— 给模型打样
你目前的提示词完全是 Zero-Shot（零样本） 的，全是死板的规则文字。大模型对自然语言的“描述”理解是有偏差的，它最擅长的是模仿。
- 为什么卡在70%： 比如你写了“局部细节未抽象”，大模型在某些 ERP 场景下，很难界定到底什么算“局部制度”，什么算“通识流程”。
- 调优方案： 在提示词里贴心地加上 1个 Pass 示例 和 2个典型的 Fail 示例。
💡 重构思路： 在“Workflow”之前，加入一个 ## Examples 模块：
## 示例说明
### 示例 1（误判高危区 - 应该判定为 Fail）
输入：{"user": "ERP采购流程是什么？", "assistant": "根据参考内容显示，我方A公司需要..."}
输出思考：答案开头使用了“根据参考内容显示”，且包含了具体局部实体“A公司”，触发红线。
输出JSON：[{"original_question": "...", "fail_reasons": ["材料话术开头", "包含局部实体"]}]
### 示例 2（合格数据 - 应该判定为 Pass）
输入：{"user": "如何优化采购前置时间？", "assistant": "优化采购前置时间可以通过建立长效供应商评价机制、规范审批链条来实现..."}
输出思考：全篇使用抽象通识词汇，无任何元数据和指代残留。合格。
输出JSON：[]🚀 核心三：建立你的 “Bad Case 账本”（错误驱动优化）
调优提示词千万不能瞎试（试一次好，下一次可能又崩了）。我们要像修复 Bug 一样，进行错误驱动开发。
具体做法：准备一个 Excel 表格或者本地 Markdown 文件。每次你“眼瞅标题”或者抽检发现模型漏检、误判的数据，把它们记下来：
- 漏检 Case 1： 答案里漏掉了“详见附录A”，模型打成了 Pass。
- 原因分析： 提示词里只写了“第X章”、“条目”，没写“附录”。
- 修复动作： 回到提示词第一大类第2条里，把“附录”这个词精准地补进去。
只要你积累了 20 个典型的 Bad Case，并针对性地微调提示词里的关键词，准确率会非常稳健地逼近 90%。
🚀 核心四：权重聚焦 —— 别让指令淹没在长文本里
你现在的规则非常长，从第一大类到第五大类，包含了上百个关键词（如“Chunk”、“文本块”、“根据原文”等）。大模型在处理完这几百个关键词后，到了后面就会开始“注意力涣散”。
- 调优方案： 越是绝对不能犯的致命错误，越要放在提示词的开头和结尾（末尾偏见效应）重复强调。
- 可以使用 Markdown 的加粗（）或者给核心词加上引号，向模型释放强烈的信号：“注意，这是高频雷区！”