很多人写 prompt 的方式，本质上不是“设计任务”，而是在“堆要求”。他们会写很多形容词：专业一点、深入一点、像专家一点、清晰一点、详细一点、简洁一点。结果往往是，字数变长了，效果却没有明显变好。

原因很简单：模型更擅长执行清晰任务，不擅长猜测模糊期待。

所以，想写好提示词，第一步不是学华丽模板，而是学会把“我想要什么”拆成模型可执行的说明。真正有用的 prompt，通常都绕不开四个部件：目标、上下文、约束、示例。

一、先写目标：你到底要模型做什么

最常见的问题，是目标不清。比如一句“帮我分析这篇文章”，其实可能有完全不同的意思：

• 做摘要
• 提炼观点
• 判断逻辑漏洞
• 改写成公众号风格
• 提取结构化信息

这些任务表面相似，但对模型来说不是一回事。你写 prompt 时，应该尽量把动词写清楚。不是“处理一下”，而是“总结”“分类”“改写”“提取”“比较”“判断”“生成”。

一句不太好的 prompt：

帮我优化这段内容。

一句更好的 prompt：

请把下面这段产品介绍改写成面向开发者读者的博客开头，保留核心信息，删除营销措辞，控制在 200 字以内。

后者之所以更好，不是因为更长，而是因为它更可执行。

二、补上下文：模型不知道你脑子里的背景

很多 prompt 失败，不是因为指令错了，而是因为上下文不够。你知道这篇文章是写给独立开发者的，你知道这个产品是给内部团队用的，你知道这段代码不能改接口，但模型不知道。

上下文通常包括这些信息：

• 读者是谁
• 场景是什么
• 已有输入是什么
• 不能违背的背景条件是什么
• 你更在意什么结果

很多初学者写 prompt 喜欢一上来直接提要求，却省略背景。结果模型只能用平均经验去猜。你给得越少，它越容易往“通用回答”滑过去。

三、加约束：不是限制创造力，而是减少跑偏

我越来越觉得，写 prompt 的关键能力不是“启发模型”，而是“防止模型乱跑”。

所谓约束，常见有四类：

• 内容约束： 只能基于给定材料，不能补充外部事实。
• 风格约束： 面向开发者、克制直接、不要营销语气。
• 格式约束： 输出 JSON、Markdown、固定字段。
• 边界约束： 不确定时明确说明，不要编造。

很多人担心约束太多会让模型变笨。我的经验正好相反：对大多数业务任务来说，清晰边界通常比“自由发挥”更值钱。 创造力适合内容发散，交付任务更需要收敛。

四、给示例：少讲抽象要求，多给参照物

“写得自然一点”“别太像 AI”“结构更清楚一点”，这些要求都很抽象。你和模型对“自然”“清楚”的理解，很可能根本不是一回事。

这时候最有效的做法，通常不是继续解释，而是给一个示例。示例能提供两个价值：

• 告诉模型你要的输出长什么样
• 把抽象标准变成可模仿对象

这也是 few-shot prompting 到现在仍然很实用的原因。不是因为模型离不开示范，而是因为示范能显著减少理解偏差。

一个实用模板：按四段写 prompt

如果你暂时没有自己的写法，可以先用这个朴素模板：

任务：你要完成什么。
上下文：这件事发生在什么场景里。
约束：不能做什么，必须满足什么。
输出：返回格式、长度、结构、语气。

例如：

任务：把下面的会议纪要整理成研发待办。
上下文：读者是 5 人开发团队，目标是下周排期。
约束：只基于原文，不补充猜测；按优先级排序；每条待办不超过 30 字。
输出：用 Markdown 列表，分为 P0、P1、P2 三组。

这类 prompt 看起来不高级，但在真实工作里往往比“请你作为一个世界顶级顾问……”更有效。

写好 Prompt，不是写得长，而是写得可执行

很多人一学 prompt，就容易走向两个极端：要么一句话随手扔给模型；要么写成一篇像法律合同一样的长文。两边都不理想。

好的 prompt 不是越长越好，而是越接近“可执行说明书”越好。它应该让模型少猜、多按你的要求做事。

我的建议很直接：先别追求花样，先把目标、上下文、约束、示例这四件事写稳。 你会发现，很多所谓 prompt 技巧，其实只是这四件事的不同变体。

最后的结论

如何写好提示词，核心不在“说服模型”，而在“把任务定义清楚”。

对于开发者来说，prompt 写作最值得练的，不是文笔，而是任务拆解能力。你越能把模糊需求拆成目标、上下文、约束和输出契约，模型就越容易稳定地产出你要的东西。