提示词工程怎么做才不靠感觉？内训里验证过的系统方法和五个误区

提示词工程这个词，容易让人把注意力放在「高级技巧」上——收集一堆厉害的句式，套个模板就完事。我做了两轮团队内训之后，判断反而更简单了：它就是把写提示词这件事，从碰运气变成可复现的流程。句式是末梢，流程才是根。

为什么非得这么较真？因为一句提示词在我们产品里每天要跑几千次。今天输出正常、明天格式跑偏，用户不会管你那天模型心情如何，他只觉得这功能不行。手感写作撑不起这种量。

提示词工程到底在「工程」什么

它工程的是四样东西：输入有边界、输出有格式、改动有版本、好坏有测试集。做到这四条，一条提示词才算从「灵感作品」变成了「工程品」。句式优化是最后才轮到的事。

拆开说。一条能扛事的提示词，至少要写清楚三块：任务定义（干什么、不干什么）、输入边界（用户可能塞什么进来，遇到缺信息的输入怎么处理）、输出约束（格式、字段、长度）。我给团队内训时让每个人把自己最常用的一条提示词照这三块重写，重写完大家自己先愣住了——原来的提示词有一半篇幅在和模型寒暄。

对了，任务定义那块如果涉及系统指令的写法，可以参考站内那篇提示词设计六条原则，和这里的三块划分是配套的，一个管结构一个管措辞。

我个人的类比：凭手感写提示词像在家做菜，咸了加点糖照样能吃。工程化写提示词像连锁店出餐——不是要求你厨艺更高，而是要求同一道菜一千家店端出来一个味。你的提示词上线之后，就是那家「一千家店」。

好提示词是评出来的，不是写出来的

判断提示词好坏要靠固定测试集：攒20到30条真实输入，每次改版全量跑一遍，按漏字段、编数据、格式跑偏几个维度数通过条数。没有测试集的改版，等于闭着眼睛调琴。

拿我们产品里的周报生成功能举例。第一版提示词写完，团队觉得挺顺眼，上线前我让它跑了20条真实用户输入（从内测用户里抄来的原话，包括好几条语病和缺字的）。结果只过了12条：3条漏了「本周风险」字段，4条把用户没填的数据编圆了，1条直接把周报写成了散文。

改了三轮。第一轮把「必须包含风险项」从温馨提示改成硬约束，过16条；第二轮给缺数据的字段加了「留空并标注」的兜底规则，过18条；第三轮把输出格式改成逐字段列点，格式跑偏清零。剩下那2条，翻输入才发现是用户压根没填内容——这不是提示词能救的，转头把前端改成了必填项。

内训那天我把这20条输入投在屏幕上，让大家猜第一版能过几条。最高猜18，最低猜15。实际是12。这大概就是「评出来的」和「写出来的」之间那道缝。整个测试集搭建加三轮改版，一个下午搞定，其中搭测试集本身只花了40分钟——这是整件事里回报率最高的40分钟。

评估维度不用多，我常用四个，数条数就行：

四个维度按条数打勾，20条输入一轮跑完十分钟，谁好谁坏一目了然。别搞什么百分制打分，数数最诚实。

五个常见误区，每个我都见人踩过

最常见的五个误区：堆角色话术、一稿定终身、拿单条输入下结论、要求塞成一坨、用追问当校验。每一个都有更省事的替代做法，对照下表自己排查。

第1条得认个错——我自己早期就犯过。我们产品最早的提示词开头塞了将近两百字的人设描写，写得有鼻子有眼。后来做测试集的时候顺手试了下把人设整段删掉，通过率一条没掉。那两百字，纯粹是我写的时候爽。

第5条多说一句。追问「你确定吗」偶尔管用，但它是抽奖，不是流程。你没法把「抽奖」写进团队规范，也没法跟投资人解释为什么同一个输入今天好明天坏。易错的点直接写成约束，比如「用户没提供的数字一律留空，禁止推算」，比追问十次都稳。

说回开头那个问题：提示词工程是不是就是学句式？句式当然有用，就像厨师的花刀，好看，也确实快一点。但决定一道菜能不能上连锁菜单的，从来不是花刀，是出餐流程。测试集就是你的出餐流程——它不保证每一份都惊艳，它保证的是没有一份会吓到客人。