夜雨聆风副标题：从“会提问”到“会交代任务”，理解 Prompt Engineering 的真正价值与边界
图注：Prompt 的价值不是神秘咒语，而是把任务交代清楚，让模型少猜。
引言：为什么“换个问法”，AI 就像换了个水平？
如果你用过一段时间 AI，大概率会有过这种体验。
你随手问一句：
帮我写一个产品方案。
AI 很快就会给你一份看起来挺完整的方案：背景、目标、用户、功能、流程、风险，一个都不少。
但你读完会发现，它好像什么都说了，又好像什么都没真正说到。文字是通顺的，结构是完整的，可放到你的具体业务里，并不太能用。
于是你换一种问法：
我们要给连锁门店做一个会员运营工具，目标用户是区域运营经理。当前痛点是活动配置复杂、门店执行不可控、复盘数据分散。请写一版给业务负责人的产品方案，重点说明目标、核心流程、关键功能和风险，语气不要太技术化。
这一次，AI 的回答明显不一样了。它更贴近业务场景，也更知道该强调什么、不该展开什么。
你可能会有点惊讶：只是换了个问法，AI 怎么就像换了个水平？
这就是很多人第一次接触 Prompt Engineering 时的兴奋感。
于是，各种“神奇提示词”“万能 Prompt”“让 AI 智商提升 10 倍的咒语”开始流行起来。
但我觉得，Prompt 确实重要，只是它重要的原因并不神秘。
它不是暗号，而是在改变模型这一次生成时的任务条件。
在《重新理解 AI 01：LLM 是什么？不是搜索引擎，也不是数据库》里，我们讨论过，LLM 不是在答案库里查答案，而是基于当前输入生成回答。
在《重新理解 AI 系列02：LLM 是怎么选出下一个 Token 的？》里，我们进一步拆开过这个过程：模型的回答，是一个 token 一个 token 生成出来的。
在《重新理解 AI 系列03：为什么 AI 会一本正经地胡说八道？》里，我们又讨论了幻觉：语言上顺滑、结构上完整，不代表事实上一定正确。
把这三点放在一起，就能理解 Prompt 为什么有用：
如果模型每一步都在基于当前输入生成，那么你给它什么输入，它就会沿着什么条件去生成。
所以这一篇，我们先不急着进入更复杂的 Context Engineering、RAG、工具调用和 Agent。
我们先把最贴近日常使用的一层讲清楚：
Prompt Engineering 到底在解决什么问题？
我希望通过这篇文章，和你一起建立一个更稳的直觉：
Prompt 不是咒语，而是任务说明书。它的价值，是减少模型对任务目标、输出形式和判断标准的猜测。
一、Prompt 为什么真的有用？
我们先承认一件事：Prompt 真的有用。
同一个模型，面对不同的提示方式，确实可能给出完全不同质量的回答。
但这不是因为某个神秘句式“激活”了模型。
更朴素的解释是：
Prompt 是模型当前输入的一部分，它会影响模型如何理解任务、选择回答路径、控制输出形式。
如果你只说“写个方案”，模型大概率会生成一个最常见、最安全、最不容易出错的通用版本。它不会太离谱，但也不会太贴身。
因为它不知道你的行业、读者、目标，也不知道这份方案更像内部汇报、销售材料，还是产品需求说明。
人类协作也是一样。
你让一个同事“帮我写份方案”，他大概率也要反问你：写给谁？什么背景？要解决什么问题？什么时候要？要多详细？老板关心什么？研发关心什么？
如果这些都不说清楚，对方只能猜。
AI 也是在猜，只是它猜得很快、很顺、很像那么回事。
Prompt 的作用，就是减少这种猜测。
你补充目标、受众、格式、边界和评价标准，模型就更容易知道：
这一次到底要做什么。
所以，Prompt 有用，不是因为它是咒语，而是因为它让模型更清楚任务。
图注：Prompt 不是激活模型的暗号，而是在减少模型对任务的猜测。
二、好 Prompt 首先不是好句子，而是好任务说明
很多人一说到 Prompt，就会下意识去找“更高级的句式”：
要不要写“你是一位世界级专家”？
要不要说“深呼吸，一步一步思考”？
要不要加一句“如果你做得好，我会给你奖励”？
这些句子有时可能有点用，有时只是心理安慰，有时还会把提示词变得很啰嗦。
我觉得，真正值得先抓住的，不是句式，而是任务说明。
一个好 Prompt，通常至少要交代五件事。
第一，目标：你希望 AI 完成什么？
是解释概念、写文章、改代码、做总结、提炼观点，还是设计流程？目标越模糊，AI 越容易生成一份“看起来有内容，但不一定是你要的东西”。
第二，角色：你希望它以什么视角处理问题？
这不是让模型真的变成某个人，而是给它一个观察角度。比如“代码审查者”会更关注风险、边界和测试，“公众号编辑”会更关注可读性、节奏和读者理解。
第三，背景：这件事发生在什么场景里？
面向谁？为什么要做？前面已经发生了什么？很多 AI 回答之所以空，不是因为它不会写，而是因为它不知道这件事发生在哪里。
第四，约束：哪些必须遵守？哪些不能做？
比如只能基于给定材料，不要发散；比如不要堆术语；比如输出要适合给业务负责人看。
第五，输出：最终结果要长什么样？
是列表、表格、邮件、文章、PRD、代码片段，还是一份可以直接继续加工的正文？
我们看一个对比。
弱 Prompt：
帮我写一篇 AI 文章。
这个问题不是不能答，但它给 AI 留下了太多猜测空间。
更好的 Prompt：
我在写一个面向 AI 初学者的公众号系列，这一篇要解释 Prompt Engineering 的价值和边界。读者不是专业研究人员，但已经用过 ChatGPT、Claude 或 Cursor。请用作者和读者对话的方式写一篇文章草稿，避免堆术语，重点说明 Prompt 不是咒语，而是任务说明书。
你看，后一个 Prompt 并没有什么神秘词汇。
它只是把目标、读者、背景、风格和边界说清楚了。
所以，好 Prompt 的价值不是让模型更会猜，恰恰相反：
好 Prompt 的价值，是让模型少猜。
三、经典结构化提示词框架：它们有用，但不是因为缩写神奇
说到这里，就可以理解为什么网上会出现很多结构化提示词框架。
比如 RTF、RACE、CO-STAR。
这些框架看起来都是首字母缩写，很容易给人一种“掌握公式就掌握 Prompt Engineering”的感觉。
但我觉得，它们真正有用的地方，不在缩写本身。
它们更像一张防漏清单，提醒你别只丢一句模糊问题，而要把任务里最关键的几个部分补齐。
先看最简单的 RTF。
RTF 通常可以理解为：
- • Role：让模型以什么角色或视角处理任务。
- • Task：具体要完成什么任务。
- • Format：输出成什么格式。
比如：
你是一名产品顾问。请帮我分析下面这个会员运营工具的核心功能，并用表格输出“功能、用户价值、实现风险”三列。
这里面就有 Role、Task、Format。
它简单、好记，适合初学者快速避开“帮我看看”“帮我写写”这种过于模糊的说法。
再看 RACE。
RACE 可以理解为：
- • Role：角色或处理视角。
- • Action：希望模型执行什么动作。
- • Context：相关背景和材料。
- • Expectation：期待的结果、标准或边界。
它比 RTF 多强调了背景和期待。
比如：
你是一名公众号编辑。请基于下面这篇草稿，帮我检查表达是否顺畅。背景是：这是一篇给 AI 初学者看的系列文章。我的期待是：保留作者和读者交流的语气，不要改成学术论文风格；重点指出重复、跳跃和生硬的地方。
这个 Prompt 里，模型就不只是知道“要修改文章”，还知道为什么改、按什么标准改。
再看 CO-STAR。
CO-STAR 通常可以拆成：
- • Context：背景。
- • Objective：目标。
- • Style：风格。
- • Tone：语气。
- • Audience：受众。
- • Response：输出形式。
它特别适合写作、汇报、邮件、营销文案、公众号文章这类任务，因为这些任务不仅关心“说什么”，还很关心“对谁说、怎么说、用什么语气说”。
比如写一封邮件，给老板、给客户、给同事、给用户，哪怕内容差不多，语气也会完全不同。
CO-STAR 这类框架提醒我们的，就是不要只交代内容，也要交代受众、风格和输出形式。
不过，我想强调一点：
这些框架不是官方标准，也不是唯一答案。
网上类似框架很多，名字不同，拆法不同，侧重点也不同。你不用纠结哪个才是“正宗”。
关键是理解它们背后的共同逻辑：
结构化 Prompt 框架不是答案，而是检查表。它帮你发现：目标有没有说清楚？背景有没有给够？输出标准有没有交代？
如果你理解了这一点，就不会被缩写绑住。
你可以用 RTF，也可以用 RACE，也可以用 CO-STAR，也可以自己形成一套更适合自己工作的检查清单。
真正重要的不是缩写，而是任务是否被交代清楚。
图注：RTF、RACE、CO-STAR 的价值，不在缩写，而在提醒你补齐任务信息。
四、角色、示例、格式和步骤，分别在起什么作用？
除了这些结构化框架，Prompt Engineering 里还有几类非常常见的技巧。
比如角色设定、给示例、指定格式、要求分步骤。
这些技巧也不是魔法。它们的共同作用，还是降低任务的不确定性。
先说角色设定。
当你说“你是一名资深产品经理”“你是一名代码审查者”“你是一名科普作者”时，模型并不会真的变成那个人。
但它会更倾向于按照这个角色常见的表达方式和判断标准来回答。
“代码审查者”会让它更关注 bug、风险、测试和边界条件。
“科普作者”会让它更关注例子、类比和读者理解。
“投资人”会让它更关注市场、增长、商业模式和风险。
所以，角色设定的价值不是换皮，而是给模型一个回答视角。
再说 Few-shot 示例。
Few-shot 的意思，可以简单理解为：你给模型几个输入输出示例，让它照着这个模式继续完成类似任务。
比如你要它把用户反馈分类，不只是告诉它“请分类”，而是给它几条样例：
输入：页面加载太慢，每次打开都要等很久。
输出：性能问题
输入：我找不到订单退款入口。
输出：功能可发现性问题这样模型就更容易理解你期待的分类方式。
示例不是给它抄答案，而是让它看见你希望的模式。
再说格式约束。
如果你需要表格，就明确说表格。
如果你需要 JSON，就明确字段。
如果你需要文章，就说明标题、小标题、段落节奏。
格式约束会让模型知道答案应该组织成什么形状，尤其适合摘要、清单、表格、邮件、PRD、代码配置这类任务。
最后说分步骤要求。
这类提示常见于分析、检查、规划、推理任务。
比如：
先指出这段论证的核心观点，再检查逻辑跳跃，最后给出修改建议。
这比单纯说“帮我改一下”清楚得多，因为它把任务拆成了几个可执行的动作。
这些技巧表面上看起来很多，但底层逻辑其实很一致：
它们不是在触发模型隐藏能力，而是在告诉模型：你应该按什么视角、什么模式、什么格式、什么步骤来完成这件事。
图注：角色、示例、格式和步骤，本质上都在降低任务不确定性。
五、为什么提示词模板有用，但不能迷信模板？
理解了前面这些，我们就能更平衡地看待提示词模板。
提示词模板当然有用。
对初学者来说，它能提醒你别忘了角色、目标、背景、约束和输出格式；对重复任务来说，它也能减少很多重复沟通。
比如你经常让 AI 总结会议纪要、改写文章、检查代码、生成周报，一套固定模板确实能省心。
但模板也很容易让人偷懒。
你以为自己用了一个很高级的 Prompt，实际上只是套了一个很长的壳。
模板不理解你的真实任务。
它不知道你这次要写给谁，哪些材料最重要，哪些限制是硬边界，也不知道什么才算这次任务的好结果。
更麻烦的是，有些模板太长、太泛、太用力。
它会要求模型“从 10 个维度深度分析”“给出极其全面的答案”“像世界顶级专家一样思考”。
听起来很厉害，但如果你的任务只是写一篇轻量公众号文章，模型可能会被带成一篇又重又散的报告。
模板还可能带来无关约束。
比如你只是想让模型帮你润色一段话，但模板里要求它输出背景分析、风险评估、行动计划。结果模型就会做很多你并不需要的事情。
所以，模板是脚手架，不是自动驾驶。
真正会用 Prompt，不是收藏更多模板，而是知道什么时候该删、该改、该补。
如果模板帮你补齐任务信息，它就是有用的；如果模板开始掩盖任务本身，它就变成了噪声。
六、那些早期有用的“咒语”，为什么越来越没用了？
现在我们可以回到标题里的“咒语”。
早期使用大模型时，确实有很多提示词看起来很神奇。
比如：
Let's think step by step.
或者：
你是一位世界顶级专家，请深呼吸，认真思考，不要犯错。
再或者一些更夸张的说法：如果你回答得好，会得到奖励；如果你回答错了，会造成严重后果。
我们不必嘲笑这些提示词。
在早期模型上，它们有时候确实能改善输出。
比如 Kojima 等人在 2022 年提出的 Zero-shot-CoT，就展示过在问题后面加入 “Let's think step by step” 这类简单提示，可以提升一些推理任务上的表现。
为什么会这样？
因为当时很多模型对指令跟随、步骤拆解、格式控制、不确定性表达的能力还没那么稳定。用户显式提醒“分步骤”“认真检查”“不要编造”，确实可能把模型拉到一个更好的输出方向上。
但现在，情况正在变化。
随着模型训练、指令微调、对齐方式和产品层系统提示不断升级，很多过去需要用户显式写出来的“咒语”，正在变成模型默认更容易做到的能力。
比如，早期你可能需要反复提醒模型“按步骤分析”，现在很多模型本来就更擅长拆解复杂任务；早期你可能需要强调“请严格按照格式输出”，现在模型的格式跟随能力也普遍更强。
早期你可能要写一大段角色设定，模型才会进入某种回答风格；现在很多时候，只要给出明确任务视角，它就能理解你要它怎么处理。
早期你还可能反复说“不要编”，现在模型更容易表达不确定性，但这仍然不能替代事实来源。
所以，不是说这些提示词完全没用。
更准确的说法是：它们的边际价值在下降。
过去一些“咒语”可能是显著提升模型表现的技巧，现在更多时候只是锦上添花，甚至有时是多余的噪声。
对新模型来说，越是空泛、神秘、情绪化的句子，越不如清楚的目标、材料、约束和验收标准有用。
我更愿意这样总结：
模型越强，越不需要你用咒语把它“唤醒”；但它仍然需要你把任务交代明白。
这也是 Prompt Engineering 正在发生的变化：
从“寻找神奇句式”，转向“设计清晰任务”。
七、Prompt 的边界：它不能替代事实、上下文和验证
讲到这里，我们已经比较清楚 Prompt 为什么有用。
但也正因为它有用，很多人容易高估它，仿佛只要提示词写得足够好，事实、材料、验证都会自动补齐。
Prompt 可以改变模型怎么回答，但它不能凭空提供模型没有看见的事实。
你让模型：
请不要编，认真回答。
这当然比什么都不说要好。
但如果它没有可靠资料，它最多更谨慎，不代表一定更正确。
你让模型：
请基于最新资料回答。
听起来很严谨。
但如果你没有给它最新资料，它也没有接入检索或工具，那这句话并不会自动把最新事实变出来。
你让模型：
请严格按照官方文档写代码。
也很好。
但如果官方文档没有进入它的上下文，它就只能根据训练中见过的模式和已有知识来回答。遇到版本差异、小众库、新接口，就很容易出问题。
你让模型：
请仔细检查这段代码有没有 bug。
它可以分析，但如果没有运行测试、没有看到依赖、没有完整调用场景，它仍然可能漏掉关键问题。
这就回到了第三篇讲过的幻觉。
AI 可以生成看起来合理的文本，但事实正确性不是自动附赠的属性。
Prompt 能让模型更谨慎、更聚焦、更符合你的任务意图。
但它不能替代事实材料、外部文档、工具执行、结果验证，也不能替代人类在高风险问题上的判断。
所以，Prompt 的边界可以用一句话说清楚：
Prompt 能减少模型乱走的概率，但不能把不存在的地面变成可靠道路。
当任务需要事实材料、项目背景、历史状态、外部文档和执行结果时，问题就不只是“怎么写 Prompt”了。
问题会变成：
模型到底看见了什么？
这就自然进入下一层：上下文。
图注：Prompt 可以减少模型乱走的概率，但不能替代事实、上下文、工具和验证。
八、从 Prompt 到上下文：真正的下一步是什么？
Prompt Engineering 是使用 AI 的入口。
它教我们不要只丢一句模糊问题，而要把任务交代清楚。
但当任务变复杂时，Prompt 本身会变成上下文的一部分。
真正影响模型表现的，不只有你写给它的那一句指令，还包括它看见的材料、历史、文件、系统规则、工具结果、任务状态和验证标准。
比如你让 AI 写文章，Prompt 可以告诉它写给谁、写什么、什么风格、什么篇幅。但如果这是一篇系列文章，它还需要知道前几篇讲过什么、这一篇应该接住哪个问题、哪些内容不要重复。
比如你让 AI 改代码，Prompt 可以告诉它修复 bug、不要改无关逻辑。但它还需要看到相关文件、错误日志、测试结果、依赖版本和项目约定。
比如你让 AI 分析政策，Prompt 可以告诉它请严谨分析影响。但它还需要看到政策原文、适用地区、公司业务、时间范围和不确定信息。
所以，下一步不是否定 Prompt，而是把 Prompt 放回更大的框架里。
Prompt 是你对 AI 说的话，上下文是 AI 这一次完整看见的世界。
如果 Prompt 是任务说明书，那么上下文就是任务发生的现场。
说明书写得再清楚，如果现场材料不全，任务还是可能做错。
这就是为什么我们还要继续讨论 Context Engineering。
但在这篇文章里，我们先收住。
先把最重要的一点带走：
会写 Prompt，不是会念咒语，而是会把事情交代明白。
结语：好 Prompt 的本质，是让 AI 少猜
在本文中，我们讨论了 Prompt Engineering。
它并不是一套神秘咒语，也不是万能模板集合。
它的真正价值，是让模型少猜：少猜你要它做什么，少猜应该以什么视角做，少猜输出成什么样，也少猜哪些边界不能越过。
RTF、RACE、CO-STAR 这些结构化提示词框架是有用的，但它们不是万能公式，而是检查表。
角色设定、Few-shot 示例、格式约束、分步骤要求，也不是魔法，而是在帮助模型降低任务不确定性。
早期一些看起来有效的提示词“咒语”，随着模型能力提升，正在逐渐失去魔法。
模型越来越不需要你用夸张句式把它唤醒，但它仍然需要你把任务说清楚。
同时，我们也要记住 Prompt 的边界：
它不能凭空提供事实，不能替代上下文，不能替代工具，也不能替代验证。
所以，好 Prompt 的关键，不是把话说得更玄，而是把任务说得更清楚。
最后，我想把这一篇收在一句话上：
Prompt 不是咒语。它是你递给 AI 的第一份任务说明书。
参考资料
- • Takeshi Kojima et al., Large Language Models are Zero-Shot Reasoners, 2022. https://arxiv.org/abs/2205.11916
- • OpenAI, Prompt Engineering Guide. https://platform.openai.com/docs/guides/prompt-engineering
- • OpenAI Help Center, Best practices for prompt engineering with the OpenAI API. https://help.openai.com/en/articles/6654000-how-to-prompt-chatgpt
- • Anthropic, Claude 4 Prompt Engineering Best Practices. https://docs.anthropic.com/zh-CN/docs/build-with-claude/prompt-engineering/claude-4-best-practices
- • GovTech Singapore, Mastering the art of prompt engineering with Empower. https://www.tech.gov.sg/media/technews/mastering-the-art-of-prompt-engineering-with-empower/
