写代码时用Prompt工程感觉像玄学，怎么系统提升命中率？

感觉还是得建个小测试集，固定几个输入看输出，不然改提示词全靠感觉。

我一般会先拿一个最精简的prompt跑一遍，然后每次只加一个变量（比如加例子、加约束、换措辞），记录哪次改动能稳定通过。如果加了few-shot反而更差，那大概率是例子有歧义或者格式不统一，不是模型的问题。量化的话可以自己攒个小测试集，跑个三五轮看通过率，比凭感觉靠谱多了。

我一般先固定几个测试用例跑几轮，看命中率是稳定还是随机，随机基本就是指令歧义不是模型问题。

我之前也折腾过一阵子，后来发现一个比较实在的切入点：把每次生成的输出当成测试用例来跑，而不是靠感觉判断“对不对”。比如生成正则就立刻拿预设的正负样本去匹配，SQL就直接在测试库上explain或者执行，能跑通就是硬道理，跑不通就回看是哪类错误。这个反馈一旦量化，你就能区分是模型能力边界还是指令歧义了。我自己统计过一轮，发现大部分翻车都出在“隐含约束”没说出来，比如正则的贪婪模式、SQL的方言差异，这些不点明模型就会按训练里最常见的来猜。至于指标，可以粗暴点用首次通过率，再细分到错误类型，比如语法错、逻辑错、边界漏，看两周趋势就知道提示词有没有改进。角色扮演和思维链不是没用，但它们解决的是推理路径问题，解决不了你需求本身没对齐的问题。所以与其继续堆技巧，不如先建立自己的小型回归集，每次改提示词都跑一遍，命中率自然会变得可追踪。

这事我太有同感了，尤其是正则和SQL这种对精确度要求高的任务，感觉GPT经常在“差不多对”和“完全错”之间反复横跳。后来我慢慢意识到一个问题，就是这类任务其实不太适合用自然语言去描述规则，因为语言本身就有歧义，模型理解的方向可能跟你想的完全不一样。我现在的做法是尽量把需求拆成输入输出对，直接给三五个例子让它照着写，比写一大段描述管用得多。至于判断是模型问题还是指令问题，我会先拿同样的prompt去跑几次，如果结果波动很大，那基本是指令不够收敛；如果每次错得都一样，那可能是模型能力边界到了，换个思路或者换模型更实际。量化指标这块我觉得可以自己搞个小的测试集，比如攒十几条典型需求，每次改完prompt就跑一遍看通过率，虽然土但挺有效。另外有个反直觉的点，few-shot给太多例子有时候反而会让模型过拟合到例子的表面模式上，三到五个通常就够了，多了容易适得其反。

我也常这样，后来发现把失败案例当测试集，改一版跑一遍看通过率，比凭感觉调靠谱多了。

我一般把prompt当代码测，固定几组案例跑回归，看哪句改动挂了，慢慢就摸清边界了。

我现在的做法是把prompt当成代码来对待，每次改动都记录版本，跑一批固定测试用例看通过率，而不是凭感觉判断有没有变好。你说的“看起来合理但跑不起来”其实很典型，模型对正则和SQL的边界条件天生就容易翻车，尤其是涉及转义、贪婪匹配、join顺序这些，光靠描述很难覆盖到。我的经验是别指望一次写对，而是让它先输出思路再输出代码，中间加一步自我检查，命中率会明显不一样。另外判断是模型问题还是指令问题，有个笨办法挺管用：把同样的prompt丢给另一个模型跑，如果都错那多半是指令有歧义，如果一个对一个错那可能是模型能力边界。量化指标的话，我会统计首次通过率、平均迭代轮数和失败类型分布，攒够几十条就能看出规律了。至于角色扮演和思维链，我觉得不是玄学，但得配对场景，few-shot给例子确实比纯描述稳，关键是例子要覆盖你踩过的坑，而不是随便找几个。

我之前也拿GPT-4写正则和SQL，确实感觉像开盲盒。后来我做了个笨办法：把每次成功的prompt存下来，再故意改几个变量看输出变化，慢慢就摸出哪些词是“有效信号”。另外可以试试让模型自己解释它写的正则每一步在干嘛，跑不通时对着解释定位，比反复重试靠谱。至于量化指标，我一般看“第一次就过测试用例的比例”，多攒几十条样本就能感觉出prompt改动的方向了。

我之前也这么觉得，后来发现关键是把“感觉”变成可复现的测试集。比如攒20个正则需求，每次改prompt都跑一遍，看通过率是涨是跌，比凭直觉靠谱多了。另外模型问题还是指令问题，可以固定prompt换模型试，或者固定模型把指令拆成不同颗粒度，基本能定位到是哪边的问题。别指望一套模板通吃，SQL和正则对上下文敏感度差挺多的。