一个好 Prompt 和烂 Prompt 的差距有多大？
直接给数字：同一个模型 GPT-4o，同一个任务（撰写一份竞品分析报告），一个合格的 prompt 产出的是结构清晰、有数据支撑、可直接交付的文档。一个随意的 prompt 得到的是三段泛泛而谈的废话。这不是模型能力的差距，是使用方式的差距。
Prompt engineering 被翻译成"提示词工程"其实容易误导——它不代表你需要像个工程师一样写代码。它本质上是一种精确表达的元技能：你会不会把事情说清楚、让一个没有上下文的聪明助手准确理解你的意图。
核心原则只有一条：消除歧义
一个 LLM 没有你脑子里的背景信息。你觉得自己说得很清楚的东西，对它来说可能充满了歧义。优秀的 prompt 做的就是一件事：把每一个可能被误解的点堵死。
举例：你说"帮我写个产品介绍"。歧义包括但不限于——什么产品？面向谁？什么场合用？多长？什么语气？需要包含哪些信息？要不要CTA？要不要对比竞品？
所以，好的 prompt 不是"写得花哨"，而是信息密度足够高。以下是我在实践中反复验证有效的六个具体策略。
策略一：角色 + 场景 + 任务，缺一不可
最简单的框架是：你是谁（角色）→ 在什么情境下（场景）→ 要产出什么（任务）。
差："帮我写一篇关于SaaS增长的文章。"
好："你是一位有5年B2B SaaS增长经验的营销负责人。你的CEO让你在明天晨会前准备一份一页纸的增长策略简报，包含3个核心增长杠杆、每个杠杆的关键数据支撑、以及未来30天的执行优先级。目标读者是高管团队，他们喜欢数据驱动、讨厌空话。格式要求：Markdown，每个杠杆不超过200字。"
你会发现，好的 prompt 几乎在帮模型"解题"——它不用猜你的场景、对象、深度和格式，所有精力都可以放在内容质量上。
策略二：给出输出模板，而不是描述它
很多人告诉模型"用表格输出"，然后不满意格式。更有效的做法是直接给模板：
请按以下格式输出：
【核心发现】（不超过50字的一句话总结）
【数据支撑】（列出3条关键数据，每条格式：指标名 + 数值 + 变化幅度）
【行动建议】（按优先级排序的3条建议，每条包含：建议 + 理由 + 预期效果）
模板给得越具体，输出的可用性越高。这条对于需要批量处理的任务尤其关键——你可以直接把结果复制到表格里，不需要二次加工。
策略三：Chain-of-Thought，但别泛泛地说"一步步思考"
"Let's think step by step"已经是老生常谈了。它的原理是通过要求模型展示中间推理过程来减少错误——但泛泛地说"一步步思考"效果有限。
有效的做法是定制化思维链——告诉模型具体按什么步骤思考：
请按以下步骤分析这份数据：
1. 先识别数据中的异常值（列出那些明显偏离均值的数据点）
2. 分析异常值的可能成因（是数据录入错误、季节性波动、还是结构性变化）
3. 排除异常值后，计算核心趋势指标
4. 给出结论和建议
你指定的步骤越贴合具体任务，模型的推理质量越高。这比一句通用的"think step by step"效果好得多。
策略四：Few-shot 不要只用成功案例
给模型看几个你想要的输出示例（few-shot），是提升一致性最直接的方法。但有一个常见的坑：只给"好"的例子。更好的做法是同时给一个反例，并标注"不要这样"。
比如你让模型写商品描述：
✅ 好例子：iPhone 15 Pro专用MagSafe保护壳，0.8mm超薄、支持无线充电、航空级铝合金边框。
❌ 不要这样：这是一款非常好看的保护壳，质量很好，推荐大家购买。
一个反例的价值有时候超过三个正例，因为它直接画出了你不能接受的边界。
策略五：约束先行，不要放在最后
人的阅读习惯是从上到下，但模型对 prompt 不同位置的权重并不均匀。实践表明，把关键约束放在 prompt 开头比结尾更有效——特别是在长 prompt 中，模型倾向于"忘记"末尾的约束。
如果你的约束放最后（"注意：不要超过500字"），模型在生成过程中会一路奔放地写下去，最后才想起来要截断——结果就是内容头重脚轻、结尾生硬。把字数限制、格式要求、必须包含/排除的内容放在 prompt 前1/3的位置，输出的遵守率显著提高。
策略六：用"反向验证"减少幻觉
让模型一条 prompt 直接出最终结果，不如多加一步验证。做法很简单：
步骤1：请基于以上资料，列出你对这个主题的5个核心判断。
步骤2：针对每个判断，从原始资料中找到直接引用的原文段落作为支撑。
步骤3：如果某个判断找不到原文支撑，标注为"推测"而非"事实"。
这套"声明→验证→标注"的三步流程，能显著减少模型把推测当事实输出的情况。对于研究报告、法律文档、医学信息等对准确性要求高的场景，这一步不是可选，是必须。
一个实用的 Prompt 模板
把这些策略整合起来，我日常用的 prompt 骨架是这样的：
【角色】你是 [具体角色，包含经验年限和专业领域]
【场景】你的 [老板/客户/团队] 需要你在 [时间] 内产出 [交付物]
【约束】字数：[X] 字以内 | 格式：[Markdown/JSON/纯文本] | 必须包含：[A, B, C] | 禁止使用：[X, Y, Z]
【任务】[清晰的单一任务描述，不要在一句 prompt 里塞多个任务]
【输出模板】[具体的格式模板]
【参考示例】[1个正例 + 1个反例]
这个模板看起来很长，但填完之后也就是200-300字。相比于你事后反复修改、纠正、重写的时间投入，写 prompt 多花的那3分钟是最划算的投资。
最后：Prompt Engineering 不是魔法
prompt 再优秀也有上限——模型本身的能力边界就在那里。如果你让 GPT-3.5 做高等数学证明，prompt 写得再漂亮也没用。好的 prompt 是让你榨干当前模型的能力上限，而不是突破它的天花板。
一个检验标准：如果你的 prompt 在 GPT-4o 和 Claude 上输出质量差异很大，说明你的 prompt 质量没问题，你需要做的是选对模型。如果你的 prompt 在同一个模型上一次好一次烂，说明你的 prompt 还有歧义，需要继续打磨。