提示词工程进阶实测：Few-shot、CoT 与自洽性解码的组合使用边界

一个真实的团队场景：同事把「让我们一步一步思考」加进了所有提示词，包括一个二分类的舆情标签任务。结果延迟翻倍、token 费用上涨，准确率却没有可感知的变化——模型被迫为「这条评论是正面还是负面」写出了三行推理，偶尔还在推理里自己绕晕。另一个极端是 Few-shot：为同样的分类任务精心挑了五个示例，全挑了表达直白的好样本，上线后那些阴阳怪气的反讽评论全军覆没。

Few-shot（示例引导）、CoT（思维链）与自洽性解码（Self-Consistency，多次采样后投票）是提示词工程最常用的三板斧。它们各自解决不同的问题，也各自有明确的适用边界——用对地方是杠杆，用错地方是纯开销。这篇文章把三种技术放在三类典型任务下对比，给出可操作的选择框架。

方案对比：三类任务 × 三种技术的收益矩阵

任务类型	Few-shot	CoT	自洽性解码
简单分类 / 情感判断	有收益，统一标签口径	基本无收益，纯增开销	收益有限，成本翻倍不划算
信息抽取 / 格式转换	高收益，示例即格式规范	一般无需	仅在字段复杂时考虑
多步计算 / 规则判断	辅助收益	高收益，核心手段	高收益，显著降低偶发错误
有标准答案的高风险判断	辅助收益	必配	必配

规律很清晰：Few-shot 解决「格式与口径」问题，CoT 解决「推理过程」问题，自洽性解决「单次采样的方差」问题。任务越接近客观运算，后两者收益越大；任务本身就是主观判断或模式识别，强行上推理链只会让模型产生更多「发挥空间」。

组合使用时还有一条成本视角的排序原则：先上便宜的，确认不够再加贵的。Few-shot 只花提示词 token，CoT 增加输出 token，自洽性则把整次调用成本乘以采样路数——三者的开销差着量级。实践中大量任务走到「Few-shot + 明确格式约束」就停住了，真正需要 CoT 的是推理链可枚举的多步判断，而自洽性通常只留给「错一次代价很高」的少数环节。反着来（全套叠加再往回砍），砍的时候没人敢拍板，成本就永久沉淀下来了。

实操第一步：Few-shot 的示例选择三原则

Few-shot 的效果九成取决于示例质量，三原则如下。第一，同分布：示例要与线上真实查询的风格、长度、难度一致——示例全是规整短句，模型遇到口语化长句就失灵。第二，覆盖难例：刻意放一两个边界样本（反讽评论、字段缺失的表单），示例的多样性比数量更重要，通常三到五个精选示例胜过十个平庸示例。第三，示例即规范：示例中体现的输出格式、标签口径会被模型严格模仿，示例之间的格式必须完全一致，任何一处不一致都会成为模型的「合法发挥空间」。

实操第二步：CoT 的正确打开方式

CoT 不是加一句「一步一步思考」就完事，要让推理过程服务于答案提取。关键设计是规定推理格式与结论分隔符，保证答案可以被程序稳定解析：

你是合规审核助手。请按以下结构输出：
1. 逐条核对规则清单，写出每条规则的核对过程（引用原文关键句）；
2. 最后一行严格按「结论：通过/拒绝」格式给出最终判断。

规则清单：
1. 金额超过 5 万元必须双人复核
2. 跨境付款必须附合同编号
...

两个要点：其一，要求「引用原文关键句」能让推理锚定在事实上，减少模型凭空演绎；其二，结论行用固定格式收尾，下游解析只认这一行，推理过程再长也不影响程序消费。

实操第三步：自洽性解码——多数投票压制单次方差

对有标准答案的任务（计算、合规判断、有唯一解的分类），自洽性解码用多次采样取多数结论，能有效压制单次推理的偶然错误：

from collections import Counter

def self_consistency_answer(client, question: str, n: int = 5) -> str:
    """自洽性解码：多路采样后对最终结论做多数投票"""
    answers = []
    for _ in range(n):
        resp = client.chat.completions.create(
            model="gpt-4o",
            temperature=0.7,   # 必须保留采样多样性，温度为 0 时投票失去意义
            messages=[
                {"role": "system",
                 "content": "先写出关键推理步骤，最后一行严格按「答案：X」格式给出结论。"},
                {"role": "user", "content": question},
            ],
        )
        text = resp.choices[0].message.content or ""
        answers.append(extract_final_answer(text))  # 只取「答案：」后的结论参与投票
    winner, votes = Counter(answers).most_common(1)[0]
    return winner if votes > n / 2 else "多数不一致，转人工复核"

实现里有三个容易被忽略的细节：temperature 必须大于 0，采样完全一致时投票就是自我确认；参与投票的只能是提取出的最终结论，整段推理文本是无法投票的；当多数票不构成压倒性一致时（比如五票里三票各不相同），正确动作是升级人工而不是硬选一个——分歧本身就是重要的质量信号。

避坑总结

1. 示例偏置是 Few-shot 的头号杀手。示例全挑简单样本，模型对边界 case 的错误率会系统性偏高；示例集要覆盖难例，并随线上 badcase 持续替换。
2. 别给简单任务上 CoT。二分类、格式转换类任务加推理链，延迟和成本增加而准确率原地踏步；判断标准是——这个任务的中间步骤能被写出来吗？写不出来就不需要推理链。
3. 自洽性只对客观答案有效。文案风格、创意生成这类主观任务，多数投票毫无意义；它适合计算、判断、有唯一解的选择题。
4. 警惕上下文预算被示例吃掉。示例、推理说明与用户输入共享上下文窗口，Few-shot 示例过多会把真正重要的当前问题挤到注意力边缘；示例在精不在多。
5. 先建评测集再迭代提示词。准备 30~50 条覆盖典型与边界场景的样本，每次改动后回归跑一遍对比通过率；「我觉得变好了」是提示词工程里最贵的错觉。

写在最后

提示词工程的进阶不是把所有技巧叠上去，而是知道每种技巧为什么有效、在什么条件下失效。Few-shot 管格式与口径，CoT 管推理过程，自洽性管采样方差——按任务性质选对工具、用评测集验证效果，比任何「万能模板」都可靠。技巧是招式，评测才是内功。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。