提示词工程指北：从第一性原理出发

前言

自从我开始接触大模型应用开发，已经有一年多的时间了。在这期间，我陆续使用过 OpenAI、Anthropic、Google、DeepSeek 等厂商的模型，也亲手构建过不少大模型应用。提示词工程在我的开发工作中始终占据着核心地位，是我让大模型输出符合业务需求的关键手段。

也许你已经在各个平台上看过不少关于提示词工程的指南，那为什么我还要写这篇文章呢？我认为，目前市面上的许多指南大多停留在表层，更多是罗列各种技巧和方法，很少深入探讨这些做法背后的原理和有效性；有些指南则主要面向日常使用者，并不适合大模型应用开发者。此外，我还注意到，很多流行的提示词技巧其实源自几年前针对早期大模型的研究论文，未必适用于如今参数规模和泛化能力大幅提升的模型。

尤其是自去年底 OpenAI o1 模型发布、思考模型成为行业新趋势以来，无论是 OpenAI 还是 Anthropic 都明确指出，思考模型的提示词工程方法与非思考模型存在显著差异，许多以往的提示词指南在新模型上已不再适用，甚至可能影响模型的正常发挥。

本文将从第一性原理出发，分享我作为开发者在使用当前大语言模型（尤其是思考模型）过程中的一些思考和经验。我不会简单罗列技巧清单，而是希望通过原理性的讨论，帮助读者理解我如何看待和使用这些模型，从而能够自行推导出适合自身问题的提示词方法。由于我并非专业的算法工程师，文中不会深入涉及大模型的底层原理，但我会尽量保证所分享的经验既有理论依据，也能在实际生产中发挥作用。如果文中有表达不当之处，欢迎大家批评指正。

根据 MBA 智库百科，第一性原理，简单来说，就是把问题拆解到最基本的要素，从本质出发分析，找到实现目标的最优路径。这个概念最早由亚里士多德提出，认为每个系统都有不可违背的最基本命题。

这个词之所以流行，很大程度上归功于埃隆·马斯克。他在采访中强调，第一性原理思考法的核心是跳出「别人怎么做我也怎么做」的比较思维，回到事物的本质，重新思考解决方案。用他的话说，就是「像物理学家一样，一层层剥开表象，直达本质，再从本质出发构建新的方法」。

在正式展开讨论之前，想特别感谢一路以来和我共事的同事们。正是因为有你们在日常工作中的坦诚交流、批评和支持，我才能不断成长、反思和进步。每一次项目中的讨论和碰撞，都让我收获了新的视角，也不断激励我优化自己的方法。希望这篇文章能为大家带来一些启发，也期待我们今后继续携手成长。

第一性原理

在我看来，在当前阶段，大模型应用开发者不应把主要精力放在死记硬背各种「技巧」上，比如「Let's think step by step」、few-shot 示例，或者「你是一位杰出的作家」这类角色设定。这些技巧的有效性高度依赖于模型的训练范式和底层技术，而这些基础正在快速演进，许多曾经广为流传的方法，如今未必还能带来理想效果。更重要的是，很多技巧本身有复杂的适用前提和细节，实际使用时容易出错，甚至可能相互干扰或产生矛盾。盲目追求现成技巧，其实就是陷入了马斯克所说的「比较思维」，并不能让开发者持续高效地创造价值。

与其如此，不如将注意力聚焦在理解当前模型的基本特性上。模型的工作机制、训练方式和技术瓶颈，决定了它在不同场景下的表现，也决定了我们应当采用哪些方法去激发其潜力、服务于业务目标。换句话说，技巧不是提示词工程的起点，模型的基本性质才是。随着模型不断进化，我们也需要不断回归本质，持续反思和优化最佳实践，这正是「从第一性原理出发」的意义所在。

模型能够自己找到解决方式

我要介绍的第一条基本性质是：当今的大多数思考模型，以及最新的一些非思考模型，在面对复杂问题时，具备一定的「综合各种约束和现状，自行寻找解决方式」的能力。关于思考模型的介绍，及其与非思考模型的本质区别，参见我的文章《聊聊 Deep Research、思考模型和 Agentic 技术》，本文的许多讨论基于其中论述的内容。

在当前的大模型研究界，强化学习（RL）已经成为了非常热门的研究范式，被认为是思考模型能够产生 aha moment 的基础。Andrej Karpathy 对 SFT 和 RL 之间的区别提供了一个非常浅显易懂的例子：

人类和 AI 的学习方式主要有两种——模仿学习（观察与重复，如预训练，或监督微调）和试错学习（强化学习）。最典型的例子是 AlphaGo：前者模仿职业棋手走法，后者通过自我博弈掌握制胜策略。

几乎所有震撼业界的 AI 突破都源于后者。试错学习能产生真正的魔法：它能教会 AI 在《打砖块》中打出「穿墙击球」的神操作，让 AlphaGo 击败李世石，也使 DeepSeek 等模型在思维链中涌现出「重新评估假设——回溯——尝试新路径」的解题策略。这些策略具有涌现性，无法通过模仿习得——因为 AI 的认知逻辑与人类标注者存在本质差异，人类根本无法预判这些策略的具体形态。它们只能在强化学习过程中，通过结果导向的统计验证被自主发现。

这种自我迭代的思考方式，正是当前大语言模型最令人惊叹的创新之源。

在 OpenAI o1 之前发布的模型，如 GPT-4 和 Claude 3，它们使用的后训练方式主要是 SFT，即通过大量的「问题-答案对」进行学习。而在 RL 中，人们通常会在 SFT 模型的基础上额外使用「问题-奖励函数」对进行训练，使得模型在最终输出答案之前，获得包括但不局限于这样的能力：

先对问题和现状进行思考，以确保充分理解了它们
对解决问题的若干条可能路径进行评估，选择最可能成功的路径
遇到困难时，尝试调整解决思路，或者回溯到之前对现状的分析，选择另一条路径

这样的能力是很难通过 SFT 获得的，正如 Andrej Karpathy 在前文说的，模型很难凭借人们标注「问题-答案对」去学会人的思考方式，却可以在奖励函数的激励下学会一些既能解决实际问题，又符合自身思考方式的路径。我认为，这种自主搜索解决方式的能力是思考模型相比过去的非思考模型最大的不同。假设我们要求模型生成一个关于「猫如何拿到高处架子上的鱼」的简短故事：

一个主要通过 SFT 训练的模型，可能会生成猫尝试跳跃、喵喵叫寻求帮助，或者推倒旁边某个东西来够到鱼的故事

这些都是人类标注者在提供「问题-答案对」时，基于对猫常见行为的观察或简单直接的解决思路。SFT 的本质是模仿人类已有的经验和常识，因此它很难超越人类标注者的想象力和经验边界，生成的方案往往局限于人类已经想到的那些路径。
一个额外经过 RL 训练的思考模型，则可能构思出一个更曲折的方案：猫观察到可以通过一系列连锁反应（比如，推下一个小球，小球滚动击中杠杆，杠杆撬动木板，最终使鱼缸滑下来）来达成目标

这种复杂的、非显而易见的策略，人类标注者可能很难预先想到并包含在 SFT 的训练数据中，但模型却可能在以「拿到鱼」为目标的强化学习过程中自主地「发现」它。也就是说，RL 让模型有机会跳出人类经验的框架，通过试错和奖励信号，探索出人类未曾设想过的创新解法。

这种自我迭代的思考方式，正是当前大语言模型最令人惊叹的创新之源。正如我在《聊聊 Deep Research、思考模型和 Agentic 技术》中讨论的，思考模型已经成为今年以 OpenAI 的 Deep Research 功能爆火以来，Agentic 应用新一轮浪潮的底层强力支撑。思考模型带来了一种全新的大模型使用范式：以模型的 Agentic 能力为核心，让大模型自主进行任务规划和决策，而非依赖预设的工作流程。

在这种范式下，提示词的重心从「堆砌具体操作的指令」转向了「清晰描述问题本身及其背景」。以往，当大模型尚未具备强大的复杂问题解决能力时，我们习惯用「教导」式的提示词——通过详细的操作指令让模型按部就班地执行，这本质上是「模仿学习」的思路。在这种背景下，诸如「将任务拆解为有序步骤列表」等提示词技巧应运而生，并在早期模型上取得了不错的效果。但随着用户场景日益复杂、边界模糊、标准答案稀缺，这种「手把手教模型做事」的方式很快就暴露出明显的瓶颈。

例如，假设我们需要大模型调研「2024 年中国新能源汽车市场的整体情况，包括主要厂商、市场份额和最新发展趋势」。对于早期的这些大模型，我们可能需要提供非常详尽的指令，例如：

使用搜索引擎检索关键词：「2024 中国新能源汽车市场」、「2024 China NEV market」、「中国新能源车市场份额」等。
优先查阅来自中国汽车工业协会、工信部、主流财经媒体（如第一财经、财新）、以及知名市场研究机构（如中汽数据、乘联会）的报告或新闻。
如果找不到权威报告，尝试搜索行业分析文章或企业发布的年报，关键词如「新能源汽车销量排行」、「主要厂商市场份额」。
从收集到的资料中，提取主要厂商名单、各自的市场份额、销量数据和代表车型。
进一步检索「2024 新能源汽车行业趋势」、「技术创新」、「政策支持」等相关内容，了解最新发展动态。
汇总所有信息，注意区分官方数据与第三方分析，标明数据来源和时间。

即便如此，模型也很难判断哪些新闻报道更可靠，哪些报告是最新且最相关的，或者在搜索结果不理想时如何调整策略。如果某个关键报告是 PDF 格式，或者网页结构复杂，模型可能无法有效提取信息。遇到模棱两可的信息或数据冲突时，它也不知道如何处理，除非我们预先设定了复杂的决策树来指导它应对每一种可能出现的问题。我们几乎无法通过「教」的方式让它掌握这种高度依赖经验和直觉的网页信息筛选能力。

作为替代，像 GPT Researcher 这样的早期的大模型应用大量采用了「工作流」式的设计思路：开发者会将复杂任务拆解为若干个细粒度的步骤，每一步都由大模型单独完成。例如，先让模型负责检索资料，再让模型对检索结果进行筛选，接着让模型提取关键信息，最后再由模型进行总结和归纳。每个环节都通过单独的提示词和调用串联起来，开发者在流程中充当「调度者」，把控每一步的输入输出。

这种方式的优势在于可以最大程度地规避模型在复杂任务中的不确定性和泛化能力不足的问题，通过人为拆解和流程控制，提升整体的可控性和稳定性。但它的缺点也很明显：开发和维护成本高，流程僵化，难以适应需求的快速变化，而且每一步的信息传递和上下文衔接都容易出现丢失，导致最终结果的质量受限。我在会后文对工作流进行进一步的讨论。

如今，思考模型具备强大的且可泛化的问题解决能力，它在接收到同样的调研任务后，更有可能自主规划研究路径。它可能会：

自行选择更优的搜索关键词组合，甚至使用多语言搜索。
在内部评估信息来源的权威性。
如果初步搜索结果不佳，它可能会尝试更广泛的查询，或者聚焦于特定政府部门的公告。
遇到无法直接访问的内容（如需要登录的网站），它可能会寻找替代信息源或总结可用的摘要信息。
它能够更好地整合来自不同报告、新闻和分析的信息，形成一个更连贯的答案，甚至能指出信息中的不确定性或争议点。

这种自主规划、评估和适应的能力，意味着我们已经不再需要像训练一个新手研究员那样，事无巨细地为模型制定每一步操作指令。相反，如果我们依然沿用「教模型做事」的传统方法，反而可能抑制模型本身的推理和创新能力。原因有以下几点：

首先，正如前文猫抓鱼的例子所示，人类的解决问题方式和模型通过强化学习获得的认知逻辑之间存在天然的差异。人类习惯于用经验和常识拆解任务，而模型则可能在奖励驱动下发展出截然不同、甚至超越人类直觉的解题路径。如果我们用人类的思维定式去「硬性规定」模型的操作步骤，实际上是在人为设限，阻碍了模型自主探索更优解的可能性。

其次，「硬编程」式的提示词设计虽然在早期模型上能提升可控性，但其泛化能力较为有限。思考模型的强大之处在于能够根据不同情境灵活调整策略，而过度细化的流程指令会让模型陷入机械执行，难以适应复杂多变的实际需求。这种做法很容易导致模型表面上模仿了人类的操作流程，实则丧失了自身的推理优势，出现「东施效颦」的尴尬局面。

另外，让人类去编写准确、有效的操作指令本身就是一件非常困难的事情，这些指令往往维护成本高，随着需求变化容易出现自相矛盾或逻辑冲突。一旦流程复杂，开发者很难保证所有细节始终一致，指令之间也容易互相掣肘，导致模型执行时出现混乱或不可预期的结果。

因此，想要进一步发挥推理模型的潜力，我们应当转变思路：尝试为模型提供尽可能充分、准确的上下文信息，让它自主决策、灵活应对。根据这个思路，接下来我将介绍另一个基本性质：模型希望获得充足的上下文。

模型希望获得充足的上下文

无论在应用中使用何种大模型，我们的开发流程在逻辑上均可分为三步：描述问题——解决问题——返回答案。在前一节我们讨论到，当今的思考模型具备一定的自主寻找解决方案的能力：它们擅长从某个起点出发，通过对解决路径的探索（有时还会经历回溯和调整），最终抵达一个它认为足够好的终点。因此，这个「起点」的质量——即我们提供的上下文是否清晰、准确且包含了所有必要的约束——将直接决定模型后续路径探索的效率和最终答案的质量。

关键在于：模型需要解决的问题，其核心约束和特定背景往往只有我们开发者最为清楚，这些信息深藏于业务逻辑、目标用户画像以及具体的技术实现细节之中。如果这些关键信息没有被准确传递给模型，它就像一个能力很强却目标模糊的执行者，难以发挥出最佳效果。

一个定义模糊或信息缺失的起点，往往会导致模型在解决路径的选择上表现出较大的随机性。例如，如果我们对前文提到的 Andrej Karpathy 的推文仅使用「总结这个推文」这种模糊的请求，模型在内部就需要做出一系列「选择题」：

侧重点：是关注技术细节、行业影响，还是个人观点？
语言风格：是正式报告、通俗解读，还是快速笔记？
核心概念的诠释：对于推文中的专业术语，应如何翻译或解释才能符合预期受众的理解水平？
输出长度与格式：应该是一段话、几个要点，还是更详细的分析？

缺乏明确的上下文指引，模型就只能基于其训练数据中的泛化理解去「猜测」这些问题的答案。读者有时会在模型的思维过程（CoT）中看到它对这些「选择题」作出的内部判断和选择，就像一个3D弹球，在各层挡板（即各种可能性）中不断碰撞、选择方向，最终落到底部形成一个答案。这个答案也许在某些通用场景下是可接受的，但往往难以精确满足我们作为开发者在特定业务场景下的具体需求。

DeepSeek 针对上述例子输出的思维链

又以「特朗普的就职演讲对全球有什么影响」为例。若不指明是针对 2017 年的演讲还是未来可能发生的 2025 年演讲，模型就必须进行猜测。用户的真实意图（研究历史事件、预测未来趋势，或两者兼顾）是模型无法自行探知的关键上下文。这种情况下，模型可能会选择一个「最安全」或「最常见」的解读，但这很可能与用户的真实需求南辕北辙。

越是智能的推理模型，越可以被视为一个「掌握了海量通用知识且学习能力极强的实习生」。我们不需要从头教他如何写邮件、如何做研究，但他迫切需要了解的是当前任务的具体背景：这个产品概念的确切内涵是什么？我们的目标用户有何特征？项目当前阶段的关键目标是什么？现有系统支持哪些特定的接口或功能？这些高度聚焦于当前业务的上下文，才是引导模型将其强大能力正确应用到我们特定问题上的关键。因此，我倾向于在提示词中，将重心放在清晰、准确地提供这类业务相关的核心信息上，而非泛泛的指令。我会在后文详细展开如何组织这些信息。

大模型和人类存在沟通漏斗

作为大模型应用开发者，我们会根据业务需求设计提示词，并将其与用户实际输入的请求结合后，一同发送给大模型，由模型理解、执行并返回答案。这个过程本质上是一种人机协作的沟通流程。但正如人与人之间的交流会受到表达和理解差异的影响，开发者、用户与大模型三方之间的信息传递同样面临着这样的问题——如何确保信息在各个环节都能准确无误地传递，是一项核心挑战。我将这种现象比喻为「沟通漏斗（Communication Funnel）」：信息在每一次传递时，都有可能发生损耗和扭曲。

具体来说，信息的丢失和变形主要可能出现在以下几个关键环节：

1.从原始意图到书面表达的损耗：

开发者侧：开发者脑海中的业务需求往往是复杂且多维的。在将其转化为书面提示词时，可能因为过度简化、遗漏关键约束、未能清晰阐述隐性背景知识，或对模型能力的不当预期，导致提示词未能完全承载原始意图。

例如，开发者希望模型扮演能处理复杂金融衍生品咨询的资深客服，并能根据用户风险偏好调整解释的深度。但在提示词中可能仅写道：「你是一个专业的金融AI助手，请回答用户问题。」这就丢失了「衍生品专项」、「资深程度」、「风险偏好调整」等关键限定，模型可能给出过于宽泛、初级或不相关的回答。

又如，开发者希望大模型在得到用户提供的网页链接时，判断用户是否有权限访问，如果是则调用特殊的工具来浏览内容。然而，开发者并没有在提示词中定义什么是「有权限访问」，也没有提供判断的工具。
用户侧：普通用户在向大模型应用提出请求时，往往更难一次性完整、准确地表达自己的真实需求。他们可能使用模糊的词汇，缺乏领域术语，或者对期望结果的形态没有清晰概念。

例如，用户想找「一家安静、环境好、能待久一点的咖啡厅」，但可能只输入了「附近咖啡馆」。模型可能会推荐一家热门但嘈杂的网红店，或者一家很早就关门的咖啡馆，或者完全忽略了「适合长时间工作」这些核心需求。

从提示词到模型内部表征的偏差：

即便提示词和用户请求的文本本身是清晰的，模型在理解这些文本时也可能产生偏差。这可能源于模型训练数据中存在的偏见、对特定上下文组合的理解局限、对歧义词汇的错误消歧，或是未能准确把握指令间的优先级和关联性。

例如，用户想让模型推荐一款「适合新手、价格实惠且能拍出好看照片的相机」。模型可能过度侧重「价格实惠」，推荐了一款功能非常基础、画质一般的入门相机，而忽略了用户对「拍出好看照片」的期望可能意味着对画质有一定要求。或者，模型可能不清楚「好看的照片」具体指什么（是色彩鲜艳、背景虚化，还是夜景模式强大？），也不完全理解「新手」对于操作复杂度的真实需求（是追求全自动傻瓜操作，还是愿意学习一些基本的手动功能？）。
从模型内部表征到最终行动和输出的变形：

模型即便在内部形成了一个相对准确的任务理解，其后续的规划、决策、调用工具和构思回复的过程也可能引入新的偏差，导致最终输出的结果与预期不符。

例如，我们要求模型「根据用户输入的公司名，查找其最新的财报并提取主要财务指标」。模型已经准确理解了任务，但在实际操作时，错误地调用了新闻检索工具而不是财报检索工具，导致最终输出的内容与预期不符。

也许你会觉得这个例子有些离谱，但类似的情况在我的基于 Claude 3.7 Sonnet 模型的应用中确实多次出现过！

信息漏斗示意图

从最初的需求萌芽到最终的答案呈现，中间贯穿着多方参与和多重转换。我们需要在每一个环节都努力减少信息的丢失和变形，才能尽可能提升大模型的性能。特别是当问题的描述主要来自我们服务的最终用户时，这个挑战尤为突出。我们无法苛求每位用户都能像经验丰富的提示词工程师那样，一次性就能清晰、完整、无歧义地表达自身的复杂意图（事实上，作为开发者的我们自己也很难时刻做到）。因此，这个问题在很大程度上超出了单纯的提示词工程的范畴，而演变成了一个更深层次的产品设计问题。

一个优秀的大模型应用，其产品设计本身就需要具备引导用户更清晰地表达意图、允许用户在交互过程中逐步澄清和补充上下文信息、甚至让用户能够对模型的中间步骤或初步结果进行反馈和调整的机制。OpenAI 的 Deep Research 功能在这方面进行了一些探索，它会让用户在发出任务后收到大模型关于任务细节的追问，这正是为了弥合用户意图与模型行动之间的潜在鸿沟，尽管这种交互方式看上去有些原始。

至此，我们已经探讨了提示词工程背后的一些第一性原理。这些原理主要源于笔者在成文时（2025 年 5 月）对市面上主流推理模型（如 Claude 3.7 Sonnet、Claude 4 Sonnet、Gemini 2.5 Pro 及 OpenAI o3）的观察与实践。值得注意的是，本节中关于上下文理解和沟通代沟的讨论，其普适性不止于此。对于诸如 DeepSeek V3 0324 这类较新的非推理模型，鉴于它们可能通过借鉴思考模型蒸馏数据的后训练方法，获得了部分相似能力，因此这些讨论同样具有重要的参考价值。更进一步而言，这些关于上下文和代沟的洞察，也适用于理解和优化大模型在各类应用场景中的普遍表现。

在掌握了这些第一性原理之后，接下来我会结合自身实践，分享一些基于这些原理总结出的提示词工程技巧。当然，读者也可以据此原理，结合实际场景，探索出适合自己的有效方法。但无论采用哪种技巧，我都希望大家牢记：这些方法并非凭空而来，而是建立在对大模型工作机制深入理解的基础之上。同时，我们也要意识到，随着技术的快速发展，我们对这些机制的认知也在不断更新迭代。回顾过去一年的探索与实践，我愈发体会到：在大模型领域，唯一不变的就是变化本身。我们需要尽可能把握变化背后的规律，不断提升自己的认知能力。

基本技巧

本节将分享我在实践中总结的一些常用提示词工程技巧。你会发现，这些方法本质上更像是沟通的艺术——如何让自己的意图被对方（无论是人还是大模型）准确理解和执行。这与前文提到的「沟通漏斗」概念一脉相承。即使未来大模型的智能和能力不断提升，人与模型之间的沟通障碍逐渐消弭，但人类自身表达和理解的局限依然存在（当然，前提是大模型依然服务于人类，而不是反过来！）。因此，提升沟通的清晰度和有效性，始终是提示词工程的重点。

接下来，我会依次围绕「说什么」（即明确传达任务的核心内容和真实场景）、「说多少」（即把握信息量，既不遗漏关键信息，也避免冗余）以及「怎么说」（即如何清晰、结构化、高效地表达），系统梳理和分享我在提示词工程实践中的具体经验和技巧。

描述真实场景

直接描述问题

在第一性原理的讨论中，我提到大模型希望获得充足的上下文。基于这个认知，我建议开发者在编写提示词时，应当优先尝试将任务的前因后果、背景信息和关键约束完整、准确地表达出来，看看模型是否能够基于这些信息自主理解和解决问题。而不是一开始就尝试用角色扮演、比喻或其他间接的方式来「包装」任务。

下面的观点来源于 Anthropic 的开发者们在 AI prompt engineering: A deep dive 中的相关讨论，孔某人为这场 Podcast 提供了中文脱水版。

Anthropic 的 Amanda Askell 认为，随着模型能力的增强和对世界理解的加深，对模型「说谎」或伪装任务已无必要。她举例说，如果开发者正在构建语言模型的评估数据集，就不应该假装自己是老师在为儿童设计测验。模型实际上已经从其训练数据（如互联网上的信息）中充分理解了「语言模型评估」这类概念，甚至能详细解释并给出示例。因此，她更倾向于直接、清晰地沟通实际任务，就像在现实工作中不会对同事说「你是一个老师，你在给学生出题」，而是会直接问「你能写那封邮件吗？」。如果模型能够理解任务，就应该直接告诉它真实的需求。

对此，Zach Whitten 提出，有时使用「思考的比喻」而非完全「说谎」可能更有帮助。他分享了一个经验：在让 Claude 评估图表质量时，最有效的提示是让模型采用「高中作业的评分标准」来评判。他强调，这并非要求模型扮演高中老师，而是指示模型「这是我希望你使用的分析方式，就像老师使用的评分标准类似于我想要的评分标准」。

然而，David Hershey 指出，构思出恰当的比喻本身就很有挑战性。他观察到，在企业级提示词中，开发者常常用一个看似相似但并非完全一致的任务来替代真实任务，可能是因为觉得模型对替代任务（如高中测验）有更多「经验」，但这往往会导致产品细节和任务的微妙之处在沟通过程中丢失。随着模型能力的提升，他强烈建议开发者非常明确地描述实际情况。例如，与其笼统地说「你是一个乐于助人的助手在写文档」，不如清晰地定义模型的具体身份和任务背景：「你在这个产品中，代表这家公司写作，你是产品中的支持聊天窗口。你是语言模型而不是人类，这没问题，但要非常明确地描述具体使用场景。」

David Hershey 担心，人们将角色提示词作为完成任务的捷径，当模型未能正确完成任务时便会感到惊讶，但实际上是因为开发者指示模型执行的是另一个任务，而没有提供真实任务的足够细节，从而放弃了让模型更好表现的可能性。他认为，随着模型规模的扩大和智能化程度的提高，能够区分更多主题，清晰沟通的需求也愈发关键。

XY 问题

除了上述讨论提到的问题，我在实践中还发现许多开发者在提示词中容易陷入「XY 问题」的陷阱：他们专注于描述表面现象或期望的输出形式，却忽略了真正需要解决的根本问题。这种错位往往导致模型朝着错误的方向努力，即便「完美执行」了提示词，也无法达成开发者的真实目标。

以我遇到的一个典型案例为例：某位开发者在提示词中反复强调「你必须在生成的报告中为所有信息加上来源链接，这是强制要求，你必须遵从」。结果大模型确实「遵从」了这个指令，但却开始编造不存在的链接——它理解了「必须有链接」这个表面要求，却无法获得真正的链接来源。

问题的根源在于，开发者实际想解决的是引用溯源问题（X 问题），但在提示词中表达的却是格式要求（Y 问题）。真正的需求是：当模型引用了通过搜索和浏览工具获得的网页内容时，应该同时提供对应的原始链接。这是一个关于信息流转和工具使用的问题，而不是简单的输出格式问题。如果开发者能够清晰地描述这个信息处理流程，模型就能准确理解何时、如何提供链接，而不会陷入「为了链接而链接」的误区。

上述例子其实还揭示了一个我过去常犯的错误：试图使用包含「必须」、「强制」等强硬措辞的指令来弥补上下文描述的不足。与其不断加强语气，不如退一步思考：模型为什么没有按预期行动？是因为它不理解任务的本质，还是因为我们没有提供足够的背景信息？我会在后文继续讨论这个话题。

只有将问题有条理、无歧义地表达出来，并连贯地解释其来龙去脉，才能为大模型提供有效的上下文。如果连自身都对问题感到模糊不清、难以描述，那么期望大模型能够准确理解并完美解决无疑是不现实的。在评价模型表现之前，开发者应首先自我审视：是否真正理解了任务本身，是否提供了足够的上下文，让一个（即便非常聪明的）新同事能够快速上手。如果自身都无法清晰阐述问题，也很难期待模型给出令人满意的答案。

关于 Few-Shot Prompting

此外，我个人也很少使用 Few-Shot Prompting，因为我在实践中发现，只要任务描述得足够好，绝大多数情况下模型都能很好地理解并执行，不需要额外的例子。我在实践中观察到了一种倾向：人们似乎将它视为一种逃避清晰、详尽地描述任务的「捷径」或「许愿手段」。他们期望通过提供几个输入输出的范例，模型就能奇迹般地领悟那些未曾言明的复杂业务逻辑。这与本节的原则相悖，因为过度依赖样本，有时反而会模糊了对任务本质的明确定义，甚至可能因为示例的局限性而误导模型。

Anthropic 的 Amanda Askell 对此有更深入的思考。她指出，她的目标是让模型能够处理各种认知任务，真正理解任务的本质，而非仅仅模仿示例。因此，她甚至会：

我会故意使用与实际数据不同的例子，避免模型给出过于一致的输出。我的目标是让模型能够处理各种认知任务，真正理解任务本质。比如，在提取事实文档信息的任务中，我会用儿童故事作为例子。我不使用 few-shot 示例，是因为这种方式更适合预训练模型，而不太适合对话模型。我希望模型能够真正理解任务本质，而不是简单地模仿示例。

Amanda 的观点强调了 Few-Shot Prompting 的一个潜在风险：如果示例选择不当或模型仅学会了表面模仿，那么它可能并未真正「理解」任务。因此，即便使用这种技巧，也应将其视为对清晰任务描述的一种补充或佐证，而非替代。我们的核心目标应当始终是帮助模型构建对任务的准确内部表征，这往往始于我们对任务的深刻理解和清晰表达。如果基础的任务描述本身就是模糊的，那么再多的样本也可能只是空中楼阁。

工具执行结果

在大模型应用开发中，工具的执行结果往往是模型决策的重要依据。然而，我发现许多开发者在处理工具异常或特殊结果时，容易忽视一个关键问题：如何让大模型准确理解工具执行状态，并据此做出合理的后续决策。这个问题对于依靠模型 Agentic 能力的应用相当重要，参见我在《聊聊 Deep Research、思考模型和 Agentic 技术》中的讨论。

最常见的问题是，当工具执行失败或返回异常结果时，开发者往往只是简单地将空值或错误信息直接传递给模型，而没有提供足够的上下文说明。这会导致模型误解当前状况，进而做出不合适的响应。以搜索工具为例，考虑以下几种常见的处理方式：

搜索无结果时，直接返回空字符串。
搜索超时时，返回简单的错误信息，如「Error: Timeout」。
网络异常时，返回原始的报错，如「Failed to connect」。

这些处理方式的问题在于，模型很难从这些简单的返回值中准确判断发生了什么，也不知道应该采取什么后续行动。模型可能会误以为搜索成功但没有相关内容，或者不清楚是否应该重试、换用其他工具，还是直接向用户说明情况然后放弃后续的行动。我的想法是：将工具的执行状态转化为模型能够理解的「事实描述」，并在必要时提供可选的后续行动建议，如下面的例子所示：

搜索无结果

「搜索完成，但未找到与查询相关的结果。你可以尝试调整关键词重新搜索，或使用其他工具继续研究」。
搜索超时

「搜索工具响应超时，可能是网络问题或查询过于复杂。建议稍后重试，或尝试使用更简单的关键词」。
网络异常

「搜索工具暂时无法连接，请向用户说明当前技术问题，并建议稍后重试」。

当然，在将异常情况返回给大模型之前，开发者还应该尝试在编程层面解决问题，比如对网络超时或临时性错误实现自动重试、当主要工具不可用时自动切换到备用方案等。对于需要模型参与决策的情况（如搜索结果不理想、需要调整策略），则应该将充分的上下文信息传递给模型，让它自主选择最合适的应对方式。这样的处理方式不仅能提升模型的决策质量，也能让整个应用的用户体验更加流畅和可靠。

从指令到事实

在我的实践中，我发现大模型提示词可以用一条坐标轴来理解，这条轴的两端分别是「事实」和「指令」。每条提示词都位于这个坐标轴上的某个位置：

事实：主要为大模型提供理解业务场景和自主决策所需的背景与上下文，例如工具的功能介绍、当前环境的状态描述、业务规则的解释等
指令：直接规定模型在特定情况下必须采取的具体行动，通常以「你必须...」、「请务必...」等强制性语言表达。

这两种提示词都能够控制大模型的行为，但它们的工作机制截然不同：事实性描述影响的是模型选择下一步行动的思考过程，而指令性规定直接影响模型对行动的选择结果。随着大模型应用场景的复杂化，我们面临一个根本性挑战：复杂的动态决策场景无法通过穷举指令来覆盖。以 Deep Research 类应用为例，用户期望获得深入的研究报告，这要求模型能够：

根据搜索结果的质量动态调整策略
在多个信息源之间进行权衡和选择
遇到信息缺失时自主寻找替代路径
判断何时需要深入分析、何时能够得出结论

这种复杂的推理链条中，每一个决策点都可能衍生出无数种可能的情况组合。当我们试图用指令来预设所有可能的「如果...那么...」规则时，不仅提示词会变得冗长难维护，这些规则之间还很容易产生冲突、遗漏或覆盖不全的问题。

更关键的是，过度依赖指令实际上是在用人类的思维模式限制模型的推理能力。正如我在第一性原理中提到的，思考模型通过强化学习获得的问题解决路径，往往超越了人类的直觉和经验。当我们用详细的操作指令「手把手」教模型时，实际上是在阻止它发挥自身的推理优势。

基于这个认知，我在我的实践中会让提示词的整体表达更偏向「事实」一端。这通常会通过以下方式实现：

将强制指令转化为背景描述

例如，指令式的提示词会说：「当搜索结果不完整时，你必须使用浏览工具获取完整内容」，而事实式的则会说：「搜索工具返回的是网页片段摘要，如果需要完整信息，可以使用浏览工具获取全文内容」。
用能力介绍替代使用规定

例如，指令式的提示词：「当用户提问涉及时事、新闻等内容时，你必须先使用搜索工具查找最新信息」，而事实式：「搜索工具能够提供实时信息，这有助于提供更准确和时效性强的回答」。
提供判断标准而非执行命令

例如，指令式的提示词：「如果用户问题模糊，你必须主动提问以澄清用户的需求」，而事实式：「当用户需求不够明确时，通过提问去收集更多细节通常能够更好地帮助回答用户」。

在今年的早些时候，我在开发类似 Deep Research 的功能时为模型配备了两个工具：搜索工具，它能够根据关键词搜索并返回网页 URL 和简短摘要（通常只有几句话）；以及浏览工具，它能够获取单个网页的完整文字内容。我的期望是模型能够先搜索筛选，再深入浏览获取详细信息。但在测试中发现，模型往往只使用搜索工具，拿到摘要后就直接给出结论，很少主动深入浏览。

我最初的解决方案是添加强制性的指令：「当你进行搜索后，请务必在结果中挑选那些看上去包含更多信息的网页，然后使用浏览工具获取它们的全文。」这种方法虽然解决了不浏览的问题，但因为是无条件指令，导致模型在任何情况下都会尝试浏览，即使很多时候搜索结果已经足够让模型作出完整的回答。

后来，我改为事实性描述：「搜索结果仅包含网页中截取的相关片段。如果你从片段中发现某些网页可能包含更多你需要的信息，可以使用浏览工具获取完整内容，这样能帮你获得更全面的信息进行分析」。

这样的描述让模型真正理解了两个工具的关系和使用场景，能够根据实际情况自主判断是否需要深入浏览。模型开始表现出更智能的行为：当搜索摘要已经包含足够信息时不会过度浏览，当发现关键信息可能在某个网页的完整内容中时会主动深入获取。

这种方法的核心在于：让思考模型在推理过程中自然地将我们提供的工具和背景信息融入思考，启发它探索出更优的解题路径。我们的角色从「控制者」转变为「信息提供者」，为模型的自主决策提供充分的上下文支撑。

当然，这并不意味着完全放弃指令。在某些明确的边界条件（如安全限制、格式要求）下，指令仍然是必要的。关键是要找到合适的平衡点：用事实性描述构建模型的认知框架，用必要的指令设定不可逾越的边界。这种转变需要我们对模型能力有更深的信任，也需要我们更精准地理解和表达业务场景的本质。我的实践让我坚信：当我们给予模型足够的上下文和决策空间时，它往往能找到比我们的指令更优雅、更有效的解决方案。

控制信息量

在实际的提示词工程实践中，我观察到一个非常普遍的误区：许多开发者误以为，系统提示词越长越好，写得越详细、越「面面俱到」，模型的表现就会越理想。实际上，决定提示词有效性的往往不是字数的多少，而是信息量的多少——也就是你传递给模型的关键信息是否足够清晰、准确、必要，这往往和提示词的长短无关。

许多开发者的这种「越长越好」的心态，往往还体现在对各种「提示词生成器」工具的依赖上。他们希望通过自动化的方式生成一大段结构化的提示词模板，仿佛只要把所有可能的规则和要求都写进去，就能万无一失。但在我看来，这其实是一种偷懒和逃避思考的表现。真正有效的提示词，往往不是靠堆砌模板和冗余信息得来的。

回顾我自己过去一年的实践，我最大的转变在于：我开始真正信任大模型的能力。早期，我在写系统提示词时，总是习惯于用「白名单」式的罗列——「你必须这样做、那样做」，把所有细节都写死。但随着我对模型理解的加深，以及模型能力的不断提升，我逐渐转向了以「黑名单」为主的约束——强调哪些事情不能做，并补充必要的上下文去解释应用的功能，其它的交给模型自由发挥。实践证明，给模型留出足够的空间，它往往能找到更优的解决方案。

这背后其实涉及一个核心问题：我们到底该在提示词里说什么、不该说什么？我越来越体会到，好的提示词往往是「尖锐」的——它精准地指出任务的核心要求，避免泛泛而谈。那些「正确的废话」，比如「请你认真、详细、准确地完成任务」，对今天的大模型来说几乎没有增量价值。模型已经足够聪明，真正需要的是你告诉它哪些信息是关键、哪些边界不能逾越。

进一步说，如果让你为多款完全不同的应用分别编写提示词，你会发现这些提示词之间几乎没有什么内容是完全相同的。正是这些不同的部分，定义了每个应用的独特性和核心价值。那些真正需要写进提示词的信息，往往就是区分不同应用、决定模型行为的关键要素。反之，如果你发现自己写的提示词在不同场景下大部分内容都可以复用，说明你写的很有可能是模型的通用常识，甚至可能是无关紧要的废话。

比如，假设你要做一个写作辅助工具，系统提示词除了说明「请根据用户输入生成高质量的文章」之外，还把「请注意语法正确、不要出现错别字、要有礼貌、要遵守道德规范、不得生成违法内容、要结构清晰、要避免重复、要考虑不同读者群体」等所有常见要求都一股脑写进去。实际上，这些内容大多数模型已经具备基本常识，无需反复强调。这样不仅让提示词变得冗长、信息密度低，还可能让模型忽略真正需要关注的核心约束。

反过来，也有不少人会把系统提示词写得非常简短。例如，有些人在系统提示词中写道「你不允许访问敏感信息」，却没有明确「敏感信息」具体指哪些内容。在这种情况下，模型可能会理解成用户的联系方式、财务数据，甚至是普通的用户名等。与其用宽泛的词语，不如直接列举清楚哪些信息属于敏感，哪些操作是被禁止的，这样才能让模型准确理解你的需求和边界。

因此，我建议大家在写提示词时，优先追求「清晰表达」——把任务的本质、背景、目标、约束说清楚。随着对模型能力的理解加深，你会逐渐知道哪些信息是必须说的，哪些可以省略。你的提示词也许会经历一个从「越写越长」到「越写越短」的过程。

小七姐在这条推文里总结得很到位：

一个完全的提示词新手可能要经历的提示词认知路径：从清晰表达认识到结构化表达的高效性，熟练掌握结构化表达后，再次回到简洁的表达。初始简洁是因为不知道如何表达，高阶简洁是因为知道什么不需要表达。高阶简洁保留了所有必要信息，建立在对 AI 能力边界的理解上，知道什么可以省略，什么必须说明。

Anthropic 的 Amanda Askell 也有类似的观点。她在编写提示词时常常使用一个思维实验：假设你有个任务，需要临时雇一个很有能力、但对你公司一无所知的人来做。你会怎么跟他说明？你不会把所有细节都写成操作手册，而是会用一些比喻、标准、关键要求来沟通。比如说「用高中老师的标准来评判图表」，而不是让对方扮演高中老师。她建议，先假设对方（模型）已经具备基本的常识和能力，只需要补充那些对完成任务至关重要的信息。如果发现模型理解有偏差，再逐步补充细节。很多时候，你会惊讶于模型第一次就能理解你的真实意图——前提是你把最核心的信息说清楚了。

总之，提示词的有效性不取决于长度，而取决于信息密度和表达的精准度。接下来，我会围绕本节的思想继续讨论一些技巧。

表达的基本性质

前文提到的「沟通漏斗」本质上反映了这样一个挑战：在提示词工程中，如何将业务需求精准、高效地转化为提示词，实际上就是一次将脑中想法清晰传达为自然语言的沟通过程。结合我的实践经验，我发现有几个关键点，许多开发者（包括我自己）在沟通时常常容易忽视，而这些恰恰是高效沟通不可或缺的基本功。

表达的可操作性

在提示词工程中，「可操作性」是一个非常关键但常被忽视的标准。它指的是：你的表达是否足够具体、明确，让大模型能够准确理解，并据此采取明确、可执行的行动。如果你的提示词描述得过于模糊、抽象，缺乏必要的细节和判断标准，模型就无法据此做出正确的决策或行动，这样的表达就是「不可操作」的。

不可操作的表达

例如「你不能用浏览工具访问用户的 Lark 账号没有权限访问的内部网页」。

这种说法看似设定了边界，但实际上充满漏洞：大模型知道 Lark 是什么吗？大模型如何知道用户的飞书账号有没有权限？又如何判断哪个网页是「内部网页」？模型本身并不具备判断标准，因此在实际工作中可能会出现许多预期外的行为。
可操作的表达：

例如「请将所有日期统一转换为 YYYY-MM-DD 格式输出。如果遇到无法识别的日期格式，请直接返回：日期格式错误」。

这种表达给出了明确的判断标准和操作指令，模型能够据此做出具体的行动。

因此，在编写提示词时，务必追求表达的可操作性。只有具备可操作性的表达，模型才能真正理解你的意图，并做出你期望的行为。「可操作性」= 能不能被准确理解 + 能不能被直接执行。

表达的完整性

表达的完整性，指的是：提示词是否把完成任务所需的全部关键信息都表达清楚，既没有遗漏重要的事实，也没有省略必要的操作指令。只有当提示词覆盖了任务的所有核心要素，模型才能准确理解我们的意图，并做出符合预期的行为。在实际提示词编写中，完整性主要体现在以下两个方面：

事实的完整表达

很多开发者在描述事实时，容易只陈述现象或限制，却没有补充解决方案或相关配套信息。例如，我过去在向模型介绍搜索工具时，只写了「该工具只能获取网页的部分片段，无法获得完整内容」。这样的描述虽然准确，但不完整——它只指出了局限，却没有告诉模型遇到这种情况时该怎么办。实际上，我当时还提供了浏览工具，可以访问完整的网页内容。我应该在提示词中补充说明：「如果你需要获取网页的全部内容，可以使用浏览工具访问对应的 URL」。
指令的完整结构

一条高质量的操作指令，通常应同时包含「条件」、「动作」和「异常处理」三要素。也就是说，需要明确说明：在什么情况下（条件）要执行什么具体操作（动作），以及如果出现异常或未达预期结果时应如何应对（异常处理）。

比如，我曾在提示词中只写了「请主动提问以收集用户的具体需求」，但没有说明「在什么情境下」需要提问（即缺少条件），结果导致模型不仅在收到用户请求时会主动提问，甚至在自主工作过程中也会频繁中断提问，而后者其实并非我期望的行为。此外，对于条件本身的表述也需要注意本节讨论的性质，避免出现大模型无法判断的条件。例如「如果时机合适，请主动提问以收集用户的具体需求」中的条件就非常模糊，大模型很难理解什么时机才是「合适」的。

异常处理中的「异常」通常由开发者定义，比如要求模型向用户提问，但用户没有回应。又如，对于一些可能出现「调用失败」等异常结果的工具（如网页浏览工具在链接无法访问时返回异常），模型往往会自行尝试解决，比如转向其它网页，或者多次失败后放弃该工具。如果你的工具异常情况较为特殊，建议在指令中明确告知模型遇到这些异常时应采取的具体措施，避免模型自行做出不符合预期的推断和处理。

表达的一致性

一致性，指的是提示词在各个部分之间不能出现自相矛盾、逻辑冲突或表达不统一的情况。只有保持前后一致、标准统一，模型才能准确理解你的意图，避免在执行过程中出现混乱或误解。

在多人协作的项目中，表达的一致性尤为重要。与传统代码不同，提示词的修改往往不会直接导致「能用」或「不能用」的二元结果，也不像性能优化那样有明确的线性指标。相反，提示词的变动带来的影响通常是非线性、模糊且难以预料的：一个小小的改动，可能会在某些场景下引发意想不到的问题，或者与其他部分的表达产生冲突。

一方面，对某一处提示词的调整，可能会和其他部分的描述或规则相矛盾，导致模型在不同指令之间摇摆不定。
另一方面，随着业务需求的变化，原有提示词可能已经无法准确反映最新的实际情况，而局部修改时又常常忽略了对整体一致性的维护。

相比于代码，提示词的维护更难以做到「局部无害」：我们很难孤立地评估某一处修改的影响，也很难用自动化测试或量化指标来衡量其效果。因此，我建议每当对提示词做出调整时，都要重新通读整体内容，检查是否存在前后不一致、表达冲突或遗漏更新的地方。事实上，我们可以利用大模型来帮助审阅提示词，我会在后文介绍这个技巧。

沟通克服偏差

要在实践中处理好前文提到的沟通漏斗、表达的可操作性、一致性、完整性等问题是相当困难的。无论是信息在开发者、用户和大模型之间的传递过程中出现的丢失和变形，还是各种表达标准的把控，现实中遇到的情况总是比我们能总结出来的要多得多。想用一套固定的规则彻底解决所有这些沟通和表达上的问题，几乎是不可能的，很多细节和例外都难以被完全覆盖。

因此，除了掌握前文提到的各种提示词优化技巧之外，我认为更本质、也更高效的做法，是让你的提示词在「人」和「模型」之间反复校验和迭代。具体来说：

让同事帮你审阅提示词

重点关注是否存在歧义、遗漏或表达不连贯的地方，尤其要让同事判断你的表达是否足够清晰、易于理解。同时，更重要的是，借此机会确认你对功能本身的理解是否准确，以及你的提示词用法是否合理。这一步不仅是为了发现表达上的问题，更是帮助你反思和校准对任务本身的把握，确保你和同事都能正确理解功能需求和提示词的实际用途。

需要特别指出的是，提示词和代码不同，代码的正确性通常是「对」或「不对」的二元状态，而提示词的效果则是高度非线性的：它可能在某些场景下表现良好，在另一些场景下却出现意想不到的问题。这种非线性和模糊性，导致多人协作时对提示词的维护比代码更考验团队的协作能力和团队文化。每个成员都需要对应用需求和提示词的细节有充分的理解，并在一些关键技巧和原则上达成共识。我们会在后文继续讨论这个话题。
让大模型以「自己的视角」审查提示词

请模型指出哪些地方表达不清楚、容易误解，或者可能导致它做出错误决策的细节。这一步主要针对「从提示词到模型内部理解」的偏差，帮助你发现那些只有模型自己才会注意到的理解盲区。实际上，有些细节可能连人类审查时都难以发现，但模型却能敏锐地察觉出来，因此让模型参与自我审查可以补足人类难以察觉的表达漏洞。

我目前最常用的审查方式是：在 Cursor 等 AI IDE 中，将项目的完整系统提示词（包括工具介绍等）提供给大模型，并询问它「这里是我的大模型应用的系统提示词，请你使用作为大模型的视角看待这些提示词，分析一下有没有哪些地方有问题？」。这里特别推荐 Gemini 2.5 Pro 模型，它的逻辑能力非常强，能够发现提示词中不同位置之间相互关联但存在冲突的表达。

这种「双重审阅」的流程，本质上就是在补足前文所说的「沟通漏斗」问题：既避免了人类表达时的模糊，也让模型有机会直接反馈它的理解困惑，从而最大程度提升提示词的清晰度和可操作性。

此外，在编写提示词时，可以借助写作能力强的大模型（如 GPT-4.1），将你想表达的内容讲述给它，让它帮你润色、优化为更清晰、表达更好的提示词。这样做的本质，是在优化人类表达的内容的同时，将人类的表达思路转化为大模型的表达思路，让提示词更贴合模型的理解方式，从而提升沟通的效果。

当你发现模型对提示词的理解或执行出现偏差时，有一个常被忽视的调试方法：保留出错时的提示词和上下文，在原有对话中直接添加一条新消息，向模型提问。例如：「现在进入调试模式，请结合你的系统提示词解释一下你刚才这样做的原因」，或者「你出现了预期外的行为，请告诉我系统提示词中哪些地方表达得不够清楚」。通过这种方式，可以让模型帮助你定位和改进提示词中的问题。

需要特别强调的是，模型自身对提示词的理解问题，最有能力发现和解释的或许就是模型自己。与其让开发者反复猜测模型的思路，不如直接让模型指出它在理解和执行过程中遇到的困惑或歧义，让模型主动挑出它认为不清楚或容易误解的地方，这样往往能更高效地定位和解决问题。

结语

在我看来，提示词工程的价值是让大模型朝着符合预期的方向表现出应有的能力，但它难以提升模型本身的智力。模型的底层能力仍然是决定性因素，这也是我总是选择和使用最先进的模型的原因。回顾本文的讨论，我想强调几个核心观点：

理解胜过技巧。与其死记硬背各种提示词模板和技巧，不如深入理解模型的基本特性和工作机制。当你真正理解了思考模型具备自主解决问题的能力、需要充足的上下文、以及人机沟通中存在的信息漏斗时，你自然能够推导出适合具体场景的有效方法。技巧会过时，但对原理的理解会持续指导你的实践。
变化是唯一的常数。大模型技术正在快速演进，从早期的 SFT 模型到如今的思考模型，从工作流式的应用设计到 Agentic 应用的兴起，我们的最佳实践也在不断更新。保持对变化的敏感性，持续反思和调整自己的方法论，比掌握任何单一技巧都更重要。
保持开放的心态。大模型的能力边界还在不断扩展，新的应用范式还在不断涌现。今天看似不可能的任务，明天可能就变得轻而易举；今天的最佳实践，明天可能就需要完全重新思考。保持学习的热情，保持对新技术的敏感，保持对自己认知局限的清醒认识，这些都比任何具体的技巧更珍贵。

最后，我想说的是：提示词工程不是一个孤立的技能，而是连接人类意图与机器能力的桥梁。即使未来真的出现了 AGI，我们自身也需要具备将复杂的业务需求转化为模型能够理解和执行的任务的技能。

希望这篇文章能为你的实践提供一些有价值的思考角度。如果你在实践过程中有任何心得或疑问，欢迎与我交流讨论。