把提示词当「规格说明书」写,而不是当聊天

平时跟 ChatGPT 聊天,提示词写得随意点没关系,不满意再追问就是。但一旦提示词进了生产工作流,情况完全不同——它每天要被调用成千上万次,输出还要被下游系统接着处理。这时候你要的不是「灵光一闪的好回答」,而是「稳定、可复现、有据可查」的结果。提示词,这时候更像一份工程规格说明书。

先想清楚:什么样的输出算「好」

动笔之前,先定标准。生产场景里,「好」往往不是指文采,而是:同样的输入能给出一致的输出、结果能追溯到依据、格式规整到下游能直接解析。把这几条想明白,提示词才有优化的方向,而不是凭手感反复改。

三段式:指令 + 输入 + 输出格式

一个可靠的提示词,大体是三部分:任务描述(让模型知道要干嘛、扮演什么角色、有什么约束)、示例(可选,但给一两个好例子往往立竿见影)、以及任务上下文和明确的输出格式。一个好记的公式是:指令 + 输入 + 输出格式。越具体,输出越稳。

“把提示词写成「你是个专业贴心的助手」,等于什么都没说;写成一份带角色、约束、示例和输出格式的说明书,模型才接得住。

把「规则」和「内容」分开放

系统提示词放那些永久不变的规则:角色、格式要求、硬约束;用户提示词只放每次具体的请求内容。两层分开,既好维护,也能减少用户输入「污染」系统设定、把模型带跑的风险。

对付幻觉:把话说死

想让模型少编,就得在提示词里把要求和证据讲死:明确告诉它「只能依据给定的资料回答,资料里没有就说不知道」,要求它给出的结论必须能在输入里找到依据。含糊的指令,换来的就是含糊甚至编造的回答。

让输出结构化、再顺手省点 token

如果输出要给程序接着用,就让模型按 JSON schema 输出,字段定清楚,既方便自动化,也方便测试。最后别忘了,提示词不是越长越好——在讲清楚的前提下尽量精简,能省 token、降延迟,这在高频调用的工作流里是实打实的成本。

给几个例子,胜过讲一堆道理

提示词里最被低估的一招,是「示例」(few-shot)。与其用一长串文字去描述你想要什么格式、什么风格,不如直接给模型一两个「输入长这样、输出该长这样」的范例。模型从例子里学到的,往往比从规则里学到的更准。尤其是输出格式、判断口径这种不好用语言讲清楚的东西,一个好例子,顶得上一整段说明。

把提示词纳入版本管理

提示词是会变的——你改一个词,输出可能就不一样。所以在生产里,我们把提示词当代码一样管:记录每次改动、能回滚、上线前用固定的测试集跑一遍对比。这样某次「优化」反而让效果变差时,你能立刻发现、立刻退回,而不是上线后被用户投诉了才察觉。提示词工程的「工程」二字,一半就体现在这种纪律上。

一个提示词扛不住,就拆开

新手常犯的一个错,是想用一个超长的提示词,让模型一口气完成「分类 + 提取 + 总结 + 生成」一连串事。结果提示词越堆越长,模型顾此失彼,哪一步都做不稳。更可靠的做法,是在工作流里把它拆成几步——每一步用一个简短、专注的提示词只干一件事,前一步的输出当后一步的输入。每个提示词职责单一,既好写、好调,也好排查是哪一步出了问题。

这其实是把「写好一个复杂提示词」的难题,转化成了「设计好一条清晰的工作流」。Dify 的工作流恰好擅长这个。与其和一个臃肿的提示词较劲,不如把任务拆开,让每个节点都简单可控——这往往比单纯堆提示词技巧,更能让结果稳下来。

我们做 Dify 工作流时,有个习惯:提示词写完先拿同一批输入反复跑几遍,确认它「每次都给一样的、对的结果」,再放进生产。把提示词当工程来对待,而不是当一次性的创作,这是 LLM 应用能不能稳的分水岭。

留下你的场景和痛点,我们帮你判断从哪一步开始。