我合作过的一个团队曾有一个 JSON 提取提示词，其中包含 11 个手工调优的 few-shot 示例。在之前的模型上，这些示例将精确匹配准确率提升了 6 个百分点。模型升级后，同样的 11 个示例反而让准确率下降了 2 个百分点。没有人更改过提示词。没有人更改过评估集。这些示例就是失效了——而且更糟的是，它们开始产生误导。
这种退化并不是新模型的 bug。它是提示词本身的一种“腐化”模式。每当团队在迁移模型版本时将提示词视为固定资产，这种现象就会出现。Few-shot 示例并不是提示词独立的一部分，它们是“模型-提示词对（model-prompt pair）”的一部分。在不重新评估另一方的情况下迁移其中一方，会产生任何绑定在单一模型版本上的评估套件都无法捕捉到的退化。
询问大多数工程师为什么在生产环境中使用 Few-shot 提示词，你会听到类似这样的回答：“它看起来效果更好。” 询问他们为什么要加入思维链（Chain-of-thought），答案通常是：“我读到过它有助于推理。” 这些回答并不完全错误。但它们只是披着工程外壳的惯例。关于每种提示词技术何时真正胜出的证据已经足够具体，你可以系统性地做出决定——而正确的选择可以将 Token 成本降低 60–80%，或者防止你甚至没察觉到的性能退化。
以下是研究结果，以及如何将其应用到你的技术栈中。
关于少样本提示，最常见的建议是：加入示例，质量就会提升。这个建议经常是错的，错到你不能不加以实测就随意信任它。在实践中，示例数量与模型性能之间的关系是非单调的——在某个点达到峰值之后就会下降，有时候下降幅度相当大。
2025 年的一项实证研究追踪了 12 个 LLM 在多项任务中的表现，发现 Gemma 7B 在漏洞识别任务中，随着示例数量超过最优值，准确率从 77.9% 跌至 39.9%。LLaMA-2 70B 在同类任务中从 68.6% 跌至 21.0%。在代码翻译基准测试中，功能正确性通常在 5 到 25 个示例之间达到峰值，之后便开始下降。这并非个别模型的特例——研究人员将其命名为"少样本崩溃"（few-shot collapse），这一现象普遍存在。
当一个团队在系统提示开头硬编码三个示例输入输出对时，这看起来是合理的工程决策。这些示例经过人工验证，格式统一，模型行为也可预期地有所改善。六个月后，同样这三个示例还在那里——能很好地覆盖 30% 的输入查询，其余的则是敷衍了事，而且没有人去统计到底哪些是哪些。
静态少样本提示是生产 LLM 系统中最被忽视的性能黑洞。另一种方案——根据查询的语义相似度按需选择示例——在各类任务中的质量表现持续优于固定示例，差距往往达到两位数百分比。但这个迁移过程既不免费，也不无风险，而且动态方案的失败模式比静态方案更难察觉。
本文将介绍研究数据的实际结论、生产中检索栈的工作方式、大多数从业者忽视的排序和投毒风险，以及静态示例应该获胜的具体场景。
思维链（Chain-of-thought）提示词工程是应用大语言模型（LLM）工程中最重大的发现之一。让模型“一步步思考”，它在数学、逻辑和多跳推理任务上的准确率就会大幅提升。这项技术已变得如此标准，以至于许多团队在系统中几乎是本能地将其应用于每一个提示词——分类、提取、摘要、路由——而从未考虑过它是否真的有帮助。
事实通常并非如此。沃顿商学院生成式 AI 实验室（Wharton's Generative AI Lab）的最新研究显示，在三分之一的模型任务组合中，思维链（CoT）并没有带来统计学上的显著提升，而在其他一些组合中，它甚至会损害性能。与此同时，每一次 CoT 请求都会让你的 Token 账单膨胀 2 到 5 倍，并增加数秒的延迟。对于处理数百万次请求的生产系统而言，这已经不是一种提示策略，而是一个未经审计的成本中心。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
