如何编写一个结构化的提示词模板
同样问大模型,有人得到杂乱无章的回答,有人得到结构清晰、可直接用的结果。差别往往不在模型,而在提示词。这篇教程带你把”随口一问”升级成一套可复用的结构化提示词模板,每一步都给出可直接套用的写法。
为什么要结构化
零散的提示词有三个问题:模型猜不准你的意图、输出格式不稳定、换个任务又要重头想。结构化模板把要求拆成固定的几块,让模型每次都清楚”我是谁、要做什么、有什么限制、输出成什么样”。一个完整的结构化提示词由这几部分组成:
graph TD
A[角色 Role] --> E[完整提示词]
B[任务 Task] --> E
C[约束 Constraints] --> E
D[示例 Examples] --> E
F[输出格式 Format] --> E
步骤一:设定角色
用 system 消息告诉模型它扮演谁,角色决定了语气和专业度:
你是一位有 10 年经验的资深技术编辑,擅长把复杂概念讲得通俗易懂。 |
角色越具体,回答越贴合场景。”你是助手”远不如”你是资深技术编辑”。
步骤二:明确任务
一句话说清要模型做什么,用动词开头,避免歧义:
请把下面这段技术文档改写成面向初学者的科普短文。 |
不要写”处理一下这段文字”——“处理”太模糊,模型只能靠猜。
步骤三:列出约束
把边界条件逐条列出,模型会严格遵守:
约束: |
步骤四:给示例(Few-shot)
给一到两个”输入→输出”的例子,比一大段描述更有效:
示例: |
示例让模型”照葫芦画瓢”,风格和格式立刻对齐。
步骤五:规定输出格式
明确要什么结构,方便后续用程序处理:
请按以下 JSON 格式输出: |
步骤六:组装成可复用模板
把上面几块拼成一个带占位符的模板,用代码填充变量:
TEMPLATE = """你是{role}。 |
组装与使用的流程是:
graph LR
A[准备模板] --> B[填充变量]
B --> C[拼接待处理内容]
C --> D[发给大模型]
D --> E[按格式解析结果]
步骤七:迭代优化
第一版很少完美,按结果反推调整:
- 回答跑题 → 强化任务描述和约束
- 格式不对 → 补充更明确的示例
- 太啰嗦 → 加字数限制
- 每次只改一处,方便定位是哪部分起了作用
常见问题
- 提示词越长越好吗?不一定,无关内容会稀释重点,够用即可
- 一定要写满所有部分吗?简单任务可省略示例,但角色 + 任务 + 格式建议保留
- 用中文还是英文?看模型和场景,中文模型用中文通常更自然
小结
结构化提示词的本质,是把”我希望模型怎么做”拆成角色、任务、约束、示例、格式五块,再用模板固化下来。掌握这套方法,你就能把一次性的提问,变成可复用、可迭代的生产力工具。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站!
评论
WalineDisqus








