从 Zero-shot 到 Few-shot：我在处理非结构化采购数据时的 Prompt 进化史
`从 Zero-shot 到 Few-shot：我在处理"地狱级"采购数据时的 Prompt 进化史` 这篇文章记录了我在开发政府采购合规审计助手过程中，如何通过迭代 Prompt 方法，将模型准确率从70%提升到95%+的实战经验。
在搞那个政府采购合规审计助手的时候，我遇到的第一个下马威不是代码，而是那堆乱七八糟的采购公告。
几百页的 PDF，有的写着"供应商要求"，有的写着"准入条件"，格式五花八门。我当时想：既然模型都 GPT-4 级别了，直接丢给它不就行了？结果，这一路走来，我的 Prompt 经历了一场从"盲目自信"到"精雕细琢"的进化。
Zero-shot 阶段：我以为它是"神"，其实它是"复读机"
刚开始，我的 Prompt 极其简单粗暴："请提取以下采购公告中的供应商资质要求，并以 JSON 格式输出。"
结果呢？
- 幻觉满天飞：模型找不到信息时，会根据常识编造一些"注册资本不低于 XXX 万"。
- 格式不稳定：这一秒是 JSON，下一秒就带上了各种空行和废话，导致后端程序直接报错。
- 业务理解偏差：它分不清什么是"强制性要求"，什么是"加分项"。
💡 PM 总结：Zero-shot 适合写诗写段子，但在严肃的 B 端业务逻辑面前，这种"盲盒式"的交互太危险了。
约束加固阶段：给 AI 带上"紧箍咒"
为了解决格式问题，我开始在 Prompt 里疯狂叠 buff：
- "必须输出 JSON。"
- "如果找不到对应字段，请填充 null，严禁编造。"
- "禁止输出任何解释性文字。"
虽然格式稳定了，但提取的精准度还是上不去。模型就像一个刚入职、听不懂潜台词的实习生，你给它指令，它执行得战战兢兢，却抓不住业务的重点。
Few-shot 阶段：给 AI 一张"参考卷"
真正的突破发生在我引入 Few-shot（少样本提示）之后。
我不再只给指令，而是直接在 Prompt 里喂给它 3 组真实的"地狱级"采购公告片段，并附上我人工标注的最优输出。
Input: (一段极其混乱的文字)
Output: (我想要的标准 JSON 结构)
这招简直是降维打击。通过 2-3 个例子，模型瞬间"悟"到了：
- 哪些生僻词对应哪个字段；
- 遇到嵌套逻辑（如：A 情况选 B，C 情况选 D）时该如何归纳。
💡 我的实战感受：Few-shot 本质上是在定义标准。作为 PM，我发现自己不是在写提示词，而是在进行"业务建模"。我给出的例子越典型，AI 的输出就越像一个有 5 年经验的老采购。
终极奥义：思维链（CoT）与业务逻辑的融合
最后，我把 Few-shot 和 Chain of Thought 结合了。我要求模型在输出最终 JSON 前，先在内部做一遍"推理拆解"：
- 先识别公告类型；
- 提取所有的资质关键词；
- 根据合规库进行对标。
这样一搞，审计的准确率直接从 70% 飙升到了 95% 以上。
写在最后：AI PM 的核心竞争力是什么？
这段"Prompt 进化史"让我意识到：AI 时代的 PM，本质上是"高质量需求"的定义者。
很多人觉得 Prompt Engineering 只是说话的艺术，但我认为它更像是把模糊的业务语言，翻译成精准的逻辑蓝图。无论是 Zero-shot 还是 Few-shot，背后折射出的都是你对业务边界的理解。
📝 要点总结：
- Zero-shot：简单直接，但风险高，适合非严肃场景
- 约束加固：稳定格式，但精准度有限
- Few-shot：通过示例定义标准，大幅提升模型理解
- CoT + Few-shot：结合思维链推理，实现业务级准确率
- AI PM 的核心价值：把模糊的业务语言，翻译成精准的逻辑蓝图
如果一个 PM 说不清楚业务逻辑，那无论模型多强，吐出来的都只会是垃圾。