调Prompt三个月，感觉在盲人摸象，求一套系统方法论

这个问题我太有共鸣了，之前做信息抽取也经历过一模一样的阶段。后来发现关键在于把“调prompt”变成“设计评测”，先别急着改措辞，而是花时间搞清楚模型到底在哪些样本上错、错的原因是什么。比如合同模板换了就崩，很可能是模型依赖了固定位置或格式线索，而不是真正理解条款语义。这时候可以做一个错误分类表，把失败案例按“漏抽、错抽、格式错”分个类，针对性补few-shot或者加后处理校验。至于CoT和角色设定，它们本质上是在改变模型注意力的分配，但效果取决于任务是否真的需要多步推理，抽取类任务有时候加CoT反而引入噪声。我的经验是先用最小可用prompt跑一批测试集，再逐个维度做消融，比如只加示例、只加约束、只改顺序，看哪个变量真正带来提升。资料的话可以看看OpenAI的prompt engineering guide和Anthropic的prompting文档，但更管用的是自己攒一套回归测试集，每次改动都跑一遍，不然真的就是盲人摸象。

别光调prompt，先把任务拆成抽取+校验两步，稳定性靠eval集说话。

我之前也卡在这个阶段，后来发现关键是别把prompt当咒语念，得当成信息路由设计。你那个合同抽取的例子，换模板就崩，大概率是few-shot里的例子太具体了，模型学到的是表面格式而不是抽取逻辑。可以试试把任务拆成两步：先让模型识别合同里有哪些条款类型，再按类型分别抽，这样泛化会好很多。另外稳定性验证别只看准确率，多跑几组不同来源的样本，看失败案例集中在哪，比盲目调措辞有用。

这个坑我去年也蹲了挺久，后来发现关键不是继续堆技巧，而是先退一步把任务本身拆清楚。你说的合同抽取，其实模型要同时干三件事：定位条款位置、判断条款类型、再输出结构化字段，混在一个prompt里当然换个模板就崩。我现在的习惯是先写一个最笨的baseline，然后按维度单独测，比如只换措辞不换例子看波动多大，只换例子不换schema看哪块掉分，这样至少知道是泛化问题还是格式问题。few-shot失效往往是因为例子太像同一个模板，模型学到的是表面格式而不是判断逻辑，得刻意放几个结构差异大的负例进去。CoT也不是万能的，抽取类任务里它有时候反而让模型自由发挥，不如直接把字段定义和边界条件写死。验证稳定性别只看一次准确率，同一批数据跑五遍看方差，方差大的方案直接放弃。至于资料，与其找方法论不如去翻LangSmith或者OpenAI evals那套评估思路，把调prompt变成跑实验，心态会稳很多。

我一般先按任务分类型再挑结构，合同抽取这种强Schema的，直接上function calling比抠prompt稳多了。

我之前也卡在这个阶段，后来发现关键是先把任务拆成“定位+抽取+格式化”三层，每层单独测。few-shot换模板就崩，大概率是示例里带了模板特有的噪声，换成抽象示例或者只给字段定义会稳很多。另外别光看准确率，要固定一批对抗样本反复跑，看波动在哪。可以翻翻OpenAI的prompt engineering guide和Anthropic的文档，里面任务分类那块挺有参考价值。

我一般会先把任务拆成“模型到底缺什么信息”和“输出格式怎么卡死”两块，比如合同抽取，先固定schema再补例子，比一上来堆技巧稳。few-shot换模板就崩，多半是例子没覆盖字段边界，可以拿几个失败case反推该补哪类样本。CoT不是万能，结构化抽取有时直接给字段定义加约束更管用。建议搞个小测试集，每次只改一个变量，不然真不知道是哪个改动起了作用。

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。