Prompt 工程入门：让大模型稳定听懂你的指令
角色设定 · 上下文 · 示例 · 思维链 · 结构化输出 · 2026 实战模板
核心结论：大模型不读心。与其抱怨模型「不听话」，不如把任务拆成「角色 + 任务 + 上下文 + 格式 + 禁忌」五要素写清楚。本文给出可套用的模板与一份避坑清单。
一、写好提示词的五要素
- 角色（Role）：给模型一个身份，例如「你是一位有十年经验的跨境电商运营」，角色能显著收窄回答的语气与知识边界。
- 任务（Task）：用一句动词开头的指令说清要做什么，避免「帮我看看这个」这类模糊表达。
- 上下文（Context）：提供必要的背景、目标读者、约束条件。信息越贴合真实场景，输出越可用。
- 格式（Format）：明确要列表、表格还是 JSON，并给一个样例，模型会严格照做。
- 禁忌（Constraints）：写清「不要做什么」，比如不要编造数据、不要超过 200 字、不要使用专业术语。
二、通用模板（可直接复制）
角色：你是一位{职业/身份}。
任务：{用一句话描述要做什么}。
上下文：{背景、受众、已有材料}。
输出格式：{列表 / 表格 / JSON，附示例}。
禁忌：{不要编造、不要超字数、不要……}。三、进阶技巧
1. 思维链（Chain-of-Thought）
面对计算、推理、多步决策类任务，加一句「请一步步思考后再给出结论」，能让准确率明显提升。代价是输出更长、更慢，简单任务不必用。
2. 少样本示例（Few-shot）
在提示里放 2-4 个「输入→输出」范例，往往比长篇规则更有效。范例要覆盖典型与边界情况，且彼此一致。
3. 结构化输出
需要程序消费结果时，强制要求 JSON 并给出字段定义；若 API 支持 response_format 等结构化参数，优先用它而非纯自然语言约束。
⚠ 常见错误：把多个不相关任务塞进一条提示；用模糊代词（「这个」「那个」）；要求与示例自相矛盾；忽视输出长度导致截断。逐条对照五要素即可规避大部分问题。
四、常见问题
Prompt 工程需要懂编程吗？
基础用法不需要，会写清楚中文指令即可；但要批量调用或与业务系统结合，就需要通过 API 把提示词工程化、模板化。
不同模型对提示词敏感度一样吗？
不一样。能力越强的模型越能理解松散指令，小模型则更依赖结构化、少样本。同一套提示建议在不同模型上各测一遍。
提示词要每次都重写吗？
高频场景应沉淀为模板变量，仅替换动态部分，既稳定又可版本化管理。