提示词工程 prompt engineering

刚上手大模型的人常遇到这种情况：同一件事别人问一句就出结果，自己问三遍还是绕圈子，于是怀疑是不是模型不行。多数时候差在提示词的写法上。这篇把提示词工程拆成能落地的几步：先弄清它和随手写一句的区别，再按角色、任务、约束、示例、输出格式的顺序搭结构，最后给一份改稿自查清单，让你知道哪一步没写到位。

刚上手大模型的人常遇到这种情况：同一件事别人问一句就出结果，自己问三遍还是绕圈子，于是怀疑是不是模型不行。多数时候差的不是模型，是提示词的写法。提示词工程不是玄学，它只是把「我想要什么」翻译成模型能一格一格执行的结构。

这篇给刚接触大模型的人一条能照着走的路径：先弄清它和随手写一句的区别，再按角色、任务、约束、示例、输出格式搭结构，最后给一份改稿自查清单，让你知道哪一步没写到位。全程不要求你背术语，只要求你改完能自己判断结果稳没稳。

提示词工程到底在做什么

一句话区分：随手写提示词是「提要求」，提示词工程是「把要求拆成模型能执行的结构」。前者关心这次能不能出结果，后者关心换个时间、换个人问，还能不能出一致的结果。可控和可复现，是它和随口一句最本质的差别。

输出跑偏

模型答的不是你要的那件事，说明任务描述太宽或者缺输出格式

输出不稳定

同一句话跑几次结果差很多，通常是约束和示例没写死

每次结果差太多

多轮对话里上下文被冲淡，需要考虑把关键要求固定成系统提示词

什么情况下不适用：一次性闲聊、开放式头脑风暴这类你本来就不想要固定结果的任务，硬套结构反而会压住模型的发散。这里的目标是「别跑偏」，而发散任务的目标恰恰是「允许跑偏一点」。

四块内容：角色、任务、约束、输出格式

角色交代身份和视角，任务说清要做什么产物，约束限定范围和不许做什么，输出格式定下交付形状。四块的顺序建议按「角色→任务→约束→示例→输出格式」排，模型读起来更顺，你也更容易发现哪块漏了。

• 每块只写一句核心话，长了就拆行，别把几件事糊在一句里
• 约束宁可少而硬，不要堆一堆互相打架的规则，规则越多越容易被选择性忽略
• 输出格式写到「几个字段、每段几行」这种程度，而不是「简洁一点」
• 写完自己按顺序回读一遍：角色、任务、约束、示例、格式，缺哪块补哪块

什么情况下不适用：如果任务本身还在探索阶段，结论未定，那就先把任务和输出格式定死，角色和约束可以留白。过早锁死约束，会把还没想清楚的探索也一起锁住。

什么时候必须给示例

输出格式复杂、判断标准主观、需要模仿特定语气时，给一两个输入输出对照，往往比写十句描述管用。示例的价值在于把「我理解的合格」变成模型能看到的具体样子，减少它在灰色地带自己猜。

1. 先定正例挑一个你最满意的输出，标清哪些部分必须保留，哪些可替换
2. 再补边界例加一个「这种也算合格」和一两个「这种要判为不合格」，覆盖模糊地带
3. 检查冲突逐条比对文字规则和示例，两者不一致时先统一，再拿去跑
4. 验证稳定性同一份示例跑两到三遍，看边界例是否都能被正确区分

示例和文字规则冲突时，模型通常更信示例，所以两者要一起改，不能只改一边。什么情况下不适用：事实问答、算术这类有唯一正确答案的任务，示例往往多余，写了反而占上下文还容易把格式带偏。

改稿自查：改完先过这五条

改完提示词先别急着发出去，按下面五条过一遍，大部分「怎么又问不对」的问题在这一步就能定位。

• 任务是否只有一个明确产物，出现「顺便再看看」就拆成第二次请求
• 约束里有没有互相排斥的条款，比如既要极简又要覆盖全部细节
• 输出格式是否写到了具体字段、行数或段落数，而不是「简洁一点」
• 有没有交代信息不足时怎么办：是追问、还是标注不确定，别让它自由发挥
• 跑两到三遍看结果是否稳定，只跑一遍看不出是提示词起作用还是碰巧

这套自查不承诺结果一定对，只帮你把「运气好」变成「可解释」。涉及专业结论、合规判断的内容，提示词写得再好也替代不了人工核对来源，这一点不用抱侥幸。

这些情况别硬套方法论

模型换代或长上下文能力提升后，部分靠堆约束补出来的写法会变得多余。要定期回头精简，而不是越写越长；一份提示词从几十行瘦到几行还跑得稳，通常说明你抓对了核心。

多轮对话里系统提示词和用户提示词的分工不同，把两者混在一段里会导致后半段被忽略，分开写更清楚。至于当前各家模型在长上下文、指令遵循上的实际表现，不要凭记忆下判断，到站内的模型资料库核对当时的说明更稳妥。

另一类不该硬套的场景是跨版本迁移：旧提示词换个模型或换条线路后表现变了，先怀疑接口和参数，再怀疑提示词。想知道不同接入方式的稳定性差异，可以到 /sites 看中转站的实测记录，再决定是改词还是换路。