写提示词写到一定量,你会发现每次都在重抄同一套东西:角色、任务、约束、输出格式。这篇不讲入门概念,只讲模板怎么搭、哪些块该固定、哪些块该随任务换,以及模板什么时候反而拖后腿。适合已经能写出可用提示词、想把它们沉淀成可复用资产的人。
写提示词写到一定量,你会发现每次都在重抄同一套东西:角色、任务、约束、输出格式。这时候模板的价值才真正显现——不是让你少打字,而是让同一套判断标准能跨任务复用。这篇不讲入门概念,只讲模板怎么搭、哪些块该固定、哪些块该随任务换,以及模板什么时候反而拖后腿。
适合已经能写出可用提示词、想把它们沉淀成可复用资产的人。下面所有做法都可以直接套到你的工作流里,但每条都附了「什么情况下不适用」,别当成万能公式。
模板拆成哪几块,每块的职责边界
把模板拆成六块:角色、任务、输入、约束、输出格式、示例。顺序不建议乱调,因为这个顺序对应的是模型从「你是谁」到「你要什么」到「你别干什么」的认知路径。乱序不是不能跑,但出问题时排查起来会多一层干扰。
- 角色
- 限定模型调用哪部分知识和语气,越具体越稳,比如「做过支付对接的后端」比「资深工程师」更有指向性
- 任务
- 一句话说清要做的事和交付物,不要在这里塞背景,背景放输入块
- 输入
- 放待处理的原文、数据、上下文,明确边界符,避免和指令混在一起
- 约束
- 写成可判定的条件,比如「不超过三句话」「只输出 JSON」,别写「尽量简洁」这类没法对照的标准
- 输出格式
- 字段名、顺序、语言、长度、禁止项都要写死到能直接解析的颗粒度
- 示例
- 可选件,给一个正例往往比三行约束更有效,但示例本身要和输出格式块一致,否则模型会照着示例跑偏
骨架必须留的是任务、输入、输出格式三块,缺了任务模型不知道干什么,缺了输出格式下游没法用,缺了输入就只能瞎编。角色和约束是可选件,但一旦你发现同一类任务反复出错,通常就是这两块没写清。示例块属于加速件,短任务里加上它性价比最高。
| 块 | 必须留 | 常见写法错误 | 怎么改 |
|---|---|---|---|
| 角色 | 否 | 写「你是一个专家」,没有领域指向 | 加具体领域和场景,比如「做过电商对账的运营」 |
| 任务 | 是 | 一句话里塞了三件事 | 拆成主任务加子步骤,一件一件说 |
| 约束 | 否 | 写「简洁一点」「专业一些」 | 改成可判定的:字数上限、禁止词、必须包含的元素 |
| 输出格式 | 是 | 只说「用表格」,不说列名 | 把列名、顺序、每列内容写死,最好给一行样例 |
约束块最容易写成一堆废话,判断标准很简单:把这条约束拿给同事看,他能不能在不问你的情况下判断一条输出是否违规。能判断就留,不能判断就改成能判断的写法,实在改不了就删掉,含糊的约束只会占用注意力。
哪些地方该留空位,哪些地方该写死
把模板里的内容分成变量位和常量位。常量位是这套模板成立的前提,比如输出格式、判断标准、禁止项;变量位是每次任务会换的,比如主体、受众、语气、长度。改版时只动变量位,常量位不要随笔一改,否则你就失去了模板的复用价值。
同一模板跨任务复用,改法只有三条:换示例、换约束、换输出格式。换示例最快,适用于任务形态没变、只是风格不同;换约束适用于任务目标变了但交付形态没变;换输出格式适用于下游消费方式变了。三条改法动的东西不一样,改之前先确认是哪一类,别三样一起动。
模板失效的几种情况,以及怎么退回去
模板不是越用越好。任务本身很短、很明确的时候,套模板反而会把关键指令稀释在一堆结构里。判断标准:如果一句话就能说清要什么,而且输出格式你自己心里有数,那就别上模板,直接写。
另一个失效场景是模型或接口换了。原先靠措辞压住的约束可能不再起作用,这时候不要急着加约束,先跑几条最有代表性的输入,看输出格式有没有跑偏、有没有照抄占位符。要对比不同模型或接口的表现,可以到 /rankings 看当时的评测结果,但最终还是要用你自己的任务样例验证。
- 先跑三条例行输入用模板跑三条你最常处理的任务,检查输出格式、字段名、禁止项有没有被遵守
- 再跑两条边界输入空输入、超长输入、格式不规范的输入各跑一条,看约束块还稳不稳
- 对比不用模板的版本同一批输入直接裸写提示词,看输出质量差多少;差距不明显就说明模板该退场了
- 决定降级还是重写如果模板只是某块失效,删掉那块继续用;如果整体都不如裸写,就把它降级成素材库
多轮对话里模板应该在前几轮就退出。第一轮把角色、任务、约束、输出格式交代清楚,后面几轮只发增量信息,不要每轮重发一遍完整模板。每轮重发会把旧约束反复叠加,模型反而容易在中间轮次开始摇摆。
失效的模板不要删掉,降级为素材库:把还能用的角色句、约束句、输出格式片段挑出来,存成片段库,下次搭新模板时直接引用。这样你不会因为一次失效就丢掉积累,也不会因为舍不得删而继续用一个拖后腿的骨架。
模板的价值不在于它有多完整,而在于你能清楚说出哪一块是常量、哪一块是变量,以及它什么时候该退场。下一步把你的模板拿去和站内的模型与接口资料对照,确认当前接口对结构化输出的支持程度,再决定哪些约束要留在提示词里、哪些可以交给接口层解决。→
常见问题
模板越长效果越好吗?
不是。模板的长度应该跟任务复杂度匹配。任务简单时,长模板会把关键指令埋在一堆背景描述里,模型反而抓不住重点。判断标准是:删掉这一段,输出会不会明显变差,不会就删。
同一个模板换模型还能用吗?
大体结构能用,但约束和输出格式那两块要重测。不同模型对指令的敏感度、对格式的服从度不一样,同一句约束在 A 上管用,在 B 上可能被忽略。换模型后先跑一遍旧模板,看输出格式有没有跑偏,再去站内模型库核对对应模型的参数与限制。
模板放系统提示还是用户提示里?
固定的骨架部分放系统提示,每次变的输入和变量放用户提示,这样能减少重复。但要注意优先级:用户提示里的具体指令通常会盖过系统提示,所以别把关键约束只写在系统提示里就不管了。站内已有文章拆过两者的分工,可以先看那篇再决定。