提示词工程这个词，2026 年已经和"写一段让 AI 听话的话"不是一回事了。它更像一门工程：提示词有版本、有测试集、有分数，改一版要能看出是变好还是变坏。这篇不讲玄学，给一套生产里真正用得上的组合：结构化输出、few-shot、评测闭环，最后列几个最常见的坑。

结构化输出

判断写进第一句：只要你的下游要解析结果，就别让模型自由发挥格式，直接用 JSON schema 或 function calling 把它钉死。

自由文本的最大问题是"基本对、偶尔格式乱"，解析代码里塞一堆容错，越写越脆。把格式约束交给模型本身，解析成本直接砍掉一大半。下面是一个自拟的抽取器：

SYSTEM = (
    "你是新闻标题抽取器。输入一条新闻标题，输出 JSON。"
    "输出字段：tickers 是标题里字面出现的股票代码数组（1-5 位大写字母），"
    "companies 是标题里出现的公司名数组。"
    "规则：tickers 只收字面出现的代码，不要从公司名反推；都没有就返回空数组。"
)

USER = "标题：{{ headline }}"

注意那条规则——"不要从公司名反推代码"——它比格式本身更重要。结构化输出解决的是"能不能解析"，这条规则解决的是"解析出来对不对"。两者都要写。

few-shot 比指令管用

对于非平凡的任务，几个精选的例子比长篇指令更有效。原因是模型对"格式"的理解靠模仿，不靠描述。你要的是分类标签、抽取边界、风格，直接给输入输出对，比解释十遍"请注意边界"都稳。

EXAMPLES = [
    ("苹果发布新款 MacBook Pro", '{"tickers": [], "companies": ["苹果"]}'),
    ("NVDA 股价创历史新高", '{"tickers": ["NVDA"], "companies": []}'),
    ("特斯拉与蔚来同日宣布降价", '{"tickers": [], "companies": ["特斯拉", "蔚来"]}'),
]

三个细节。一是例子要覆盖你真正头疼的边界，不是最普通的那条——比如"公司名里带代码字母"这种。二是格式要严格一致，例子之间连空格和引号都要统一，模型才能照抄。三是例子数量别贪，三到五个就够，十个以上收益递减还费 token。

推理任务用 CoT

对数学、逻辑、多步推理这类任务，让模型"先想再答"能稳定提分，公开评测里 20 到 30 个百分点的提升很常见。但反过来，简单分类和创意写作加 CoT 只会浪费 token 和延迟。

有一个容易被忽略的点：现在的推理型模型很多内部已经会做这件事，显式再写"一步一步想"收益不大。判断标准是看任务——需要拆步的是推理，不需要的是抽取和生成。别一刀切。

self-consistency 是 CoT 的加强版：同一个 prompt 温度大于零跑多次，取多数票。数学和逻辑上比单次明显更准，代价是贵。适合高风险的分类场景，不适合每一条请求都上。

提示词当代码管

真正的护城河是评测集，不是某一条提示词。建 20 到 100 条带标准答案的输入，每改一版 prompt 就全量跑一遍、打分，分数变差就回滚。

PROMPTS = {
    "extract_v3": {"system": SYSTEM, "examples": EXAMPLES},
}

def eval_prompt(name, test_set):
    score = 0
    for inp, expect in test_set:
        out = run(PROMPTS[name], inp)
        score += 1 if out == expect else 0
    return score / len(test_set)

这几十行看着简陋，但它把"我觉得这版更好"变成了"这版从 0.92 涨到 0.94"。没有测试集，你迭代提示词就是在凭感觉瞎调，改了坏了都不知道。

模型更新还会带来"提示词腐烂"——某条提示词在 GPT-4.5 上好好的，换到新模型就崩。所以评测集要持续跑，模型一换就回归。可以顺带看 logprobs 这类置信度信号，均值突然掉往往是腐烂的早期征兆。

几个高频误区

一是往 system prompt 里塞三十条指令。模型过了某个阈值就开始忽略后面的条目，重要的规则被淹没。把条件挪进用户消息，或者拆成多次链式调用。

二是全大写加感叹号威胁。"你必须绝不……"这类写法往往没用甚至有害，平实的指令加一句理由，比吼叫有效。

三是分离指令和数据没做好。用户输入或检索回来的文本，要用明确的分隔符包起来、放在末尾，否则既容易混淆，也容易被 prompt 注入。检索增强也一样：文档少于二十万 token 时，直接贴进上下文加分隔符，比上向量库更省事；RAG 是为规模和新鲜活，不是默认动作。

四是总想一个 mega-prompt 干完所有事。把大任务拆成小调用，每步可控、便宜、好回滚，一步失败也不会全盘重来。

五是只读输出不跑评测。凭五条输出说"看起来不错"，下一版大概率就退化了。凡是要长期维护的提示词，都用固定测试集说话。

这套东西的边界也清楚：提示词工程的能力上限大概在 85% 到 90%，再往上要的是微调或专用模型。当你的痛点变成"极深的领域知识、严格的风格、毫秒级延迟"时，就该考虑从提示词切到 LoRA 微调，而不是继续抠字眼。