提示词为什么失败:规格说明的问题
大多数令人失望的 AI 回答,不是模型的失败,而是规格说明的失败。语言模型会用统计上最平均的解释来填补请求中的每一处歧义,而模糊请求的平均解释就是模糊的答案。"写点关于远程办公的东西"有几千种说得通的理解:博客文章、政策备忘、优缺点清单,给高管看还是给新员工看,200 词还是 2000 词。模型必须选一种,而它选的总是最平庸的那种。
工程上的洞见是:提示词就是一份规格说明,它的改进方式与规格说明的改进方式相同——把关键的自由度钉死。四颗钉子能解决大部分问题。任务:动词和交付物("写一封 600 词的入职欢迎邮件",而不是"写点关于入职的东西")。受众:谁来读,他们已经知道什么。约束:长度、语气、格式、需要排除的内容。上下文:模型猜不到的背景事实——你的产品、你的处境、上次失败的尝试。
"具体就有回报"这一点证据充分。实践中,仅仅加上明确的受众和长度约束,就能明显改变输出质量,因为它压缩了合法答案的空间。一个有用的习惯:写完提示词后问自己:"两个讲道理的人读了它,会不会期待两种不同的交付物?"如果会,模型必然让其中一人失望——而失望的是谁,由不得你选。
Before (vague — average answer guaranteed):
"Write about remote work."
After (specified — 4 pins):
"Write a 600-word article arguing that hybrid schedules
beat fully-remote for junior engineers.
Audience: engineering managers at startups (assume they
already know the standard remote-work pros/cons).
Tone: direct, conversational, no buzzwords.
Structure: hook, 3 arguments each with one concrete
example, one counterargument addressed, action-oriented
close. Do NOT discuss cost savings or real estate."有实测效果的技巧:角色、少样本与任务分解
提示词工程积累了经过检验的真技巧,也积累了不少民间传说。真正承重的部分如下。
角色设定("你是一位资深税务会计师,正在审查这份文件的错误")之所以有效,不是因为模型变成了会计师,而是因为它把输出分布推向了该行业文体的词汇、审慎程度和结构。它对语气和深度的校准最有效,对事实准确性最无效——扮演医生的模型不会更懂医学,只是听起来更像临床口吻。用角色来设定语域,别用它来制造权威。
少样本(few-shot)示例是对格式和风格杠杆最大的技巧。两三对输入-输出示例胜过成段的文字描述,因为它们规定了你根本想不到要说出口的东西——标签有多简短、边界情况长什么样、"好"到底意味着什么。示例要保持多样:模型会连同偏差一起,极其忠实地复制你示例中的模式(如果示例全是正面情绪,输出也会向正面倾斜)。
对任何多阶段任务,拆解都胜过单个巨型提示词。"读这份合同,找出风险条款,再起草一封邮件说明"混合了三个质量标准各异的任务;拆成三个提示词,你就能检查并纠正中间产物。同样,让模型先规划再动笔("先只列出章节,然后等我确认"),能在结构问题只需改一行时就发现它。
思维链指令("一步一步思考")对算术和逻辑类问题有帮助,但现代的推理特化模型往往已在内部完成这一步——如今更大的收益,是要求模型在定稿前对照你写明的约束逐条自查。
Few-shot format specification (2 examples do the work):
"Classify each support ticket. Respond in exactly this format.
Ticket: 'App crashes when I upload a photo over 10MB'
-> category: bug | severity: high | team: mobile
Ticket: 'Would love a dark mode option'
-> category: feature-request | severity: low | team: design
Ticket: 'I was charged twice this month'
->"输出模式:拿到程序读得懂的答案
一旦 AI 的回答要喂给下游的任何东西——表格、脚本、另一个提示词——自由散文就成了负债。解决办法是指定输出模式:把响应的确切形状,作为不容商量的条件写明。
三个做法能让模式真正被遵守。第一,展示模式,不要描述模式。"以 JSON 回复,包含键 title、risk_level(取值 low/medium/high 之一)、reasons(字符串数组)"不错;直接贴一个填好值的 JSON 示例更好,因为示例锁定了描述留下的空白——引号风格、大小写、空数组是否允许。第二,堵住逃生口。模型热衷于用 markdown 代码围栏包裹 JSON、在前面加一句"这是您要的 JSON:",或者补一句友好的结束语。要明说:"只输出 JSON 对象。不要代码围栏,前后不要任何解释。"第三,为失败留出口:在模式里给模型一个说"我做不到"的途径(status 字段、可为 null 的答案)——否则它不会留空必填字段,而是用貌似合理的编造去填满,而这恰恰是你检测不到的那种失败。
模式对非编程工作同样有益。要求"一个包含 X、Y、Z 三列的表格"或"恰好五条要点,每条以动词开头",会迫使模型组织思路,缺了哪块一眼可见。结构化的错误答案容易发现;雄辩的错误答案则不然。即便如此,凡是要机器解析的内容都要校验——现代模型的模式遵守率很高,但除非使用 API 级的结构化输出功能,否则没有保证。
"Analyze the review below. Output ONLY this JSON —
no code fences, no text before or after:
{
"sentiment": "positive",
"confidence": 0.92,
"topics": ["shipping", "packaging"],
"actionable_complaint": true,
"status": "ok"
}
If the text is not a product review, output:
{ "status": "not_a_review" }
and nothing else."迭代循环:像对待代码一样对待提示词
对真正重要的任务,没人能一次写出好提示词。持续拿到好结果的人都在跑一个循环:起草、测试、诊断、修改——和调试代码是同一个循环。
诊断才是真功夫。输出令人失望时,先给失败定性,再去动提示词。格式不对?加模式或示例。深浅不对?你的受众说明缺失或写错了。内容不对?你假设了模型不具备的背景,把背景事实补进去。指令被忽略?它可能被埋在提示词中段;模型对提示词开头和结尾的权重高于中间,所以把关键约束移到最前面,并在结尾把最重要的那一条重申一遍。事实错得理直气壮?没有任何提示词措辞能可靠地治好幻觉——你需要提供源材料,并指示模型只依据材料作答。
每次迭代只改一处。一次改五个地方,即使输出变好了,你也不知道是哪处起了作用——提示词和代码一样,迷信积累得飞快("我们一直加这段话,没人记得为什么")。
两个习惯把普通用户和熟手区分开来。维护一个提示词库:提示词奏效时,连同用途注记和一个输出示例存下来,你会用上好几个月。以及,在信任一个提示词之前,用不止一个输入测试它:只在单个例子上调出来的提示词,会像只用一个数据点训练的模型一样,悄悄地过拟合。
提示词治不了的病
一个精心构建的提示词能抬高模型产出的上限,但有些限制属于模型本身,假装它们不存在只会浪费时间。
没有任何提示词能让模型知道它没被训练过的东西:你昨天的会议、上周刚发表的论文、你公司的内部报价。如果答案需要这些信息,它们就必须出现在提示词里——由你提供,或由检索系统提供。与此相关:提示词不会赋予实时数据的访问权。问模型"现在的价格",它会产出一个长得像价格的数字。
没有任何提示词能消除幻觉;提供依据只是减少它。即便给了源材料,模型偶尔仍会把提供的事实和记忆里的事实混在一起。事实性工作的规则不变:模型起草,你来核实。要求它引用你提供的文本(段落编号很好用),抽查这些引用,并对那些具体、顺手、又无法验证的细节保持最高警惕。
没有任何提示词能让模型成为自己输出的可靠裁判。"你确定吗?"多半只会引出一次朝着你似乎想要的方向的礼貌自我修正——模型存在谄媚(sycophancy)倾向,即使用户的立场是错的也会附和。独立的检查(另开一段全新对话、换一个模型、或你自己的专业判断)比对话内的任何安抚都更有价值。
认清这些边界本身就是提示词技能:最好的实践者把力气花在措辞有用的地方——规格、示例、模式、拆解——在措辞无能为力的地方,则换用别的工具。