本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。
快速摘要
如果你只想看结论，这里是：
GPT-5.5 发布后，官方同步更新了一份提示词指南，核心逻辑只有一句话——"说清楚你要什么，别教它怎么做"。 具体落地到七个层面的变化：
- 不要再规定每一步怎么走，只描述你期望的最终结果；
- 减少"必须""永远""禁止"这类绝对指令，真正的红线才用，判断类操作改用条件句；
- 角色定义回归，但重点从"你是谁"变成"你怎么跟用户协作"；
- 复杂任务要让模型先说一句话，告知用户它接下来要做什么，避免长时间空转；
- 显式写出"停止条件"，防止模型反复搜索、token 无谓消耗；
- 官方推荐七段式结构：角色、人设、目标、成功标准、约束、输出、停止规则；
- 格式控制比以前灵敏，"不要列表不要标题"会被严格遵守；改写类任务先说"保留什么"再说"怎么改"。
这七条变化背后，有一个统一的底层逻辑：新一代模型的推理能力已经强到可以自主规划路径，你给的细节越多，反而限制了它的发挥空间。
想看完整拆解，往下翻。
你精心调教的提示词，可能已经过时了
我折腾提示词有一段时间了。最开始写的那批，格式大概是这样：先列出三个前置条件，再写五步操作流程，每步后面加一条注意事项，最后附上两个示例和一段输出格式说明。写完自我感觉良好，以为这就是"工程化提示词"该有的样子。
用旧提示词换来的，是一种微妙的挫败感——你花了大量时间把提示词调得很细，以为一劳永逸了，结果模型一升级，那些精心设计的步骤反而成了绊脚石。我在无忆研习社用的几个工具，之前调好的提示词直接迁移到 GPT-5.5 之后，输出质量反而比之前差了，花了不少时间才排查出来是提示词的问题。所以这篇文章有一半是总结官方指南，还有一半是我自己踩坑之后的真实体会。
后来 GPT-5.5 上线，我把以前调好的提示词直接拿来用，效果不对劲。输出内容虽然没错，但有一种奇怪的机械感——好像模型在严格执行你写的每一条指令，而不是真的在理解你的意图然后解决问题。
出现这个问题，不是偶然。官方在发布 GPT-5.5 的同时，配套更新了一份提示词最佳实践指南。指南里有一段话大意是这样说的：旧式提示词之所以写那么细，是因为老版本模型能力弱，需要手把手引导才能保持正确方向。而对 GPT-5.5 来说，那些过度规定步骤的指令，反而成了噪音——它们缩小了模型自主搜索最优路径的空间，导致回答显得过于机械。
这不是在说你以前的提示词写得差。那个时代，确实需要那么写。但模型变了，写法也该跟着变。
有意思的是，知名开发者 Simon Willison 在看完这份指南后，专门在个人博客上表达了惊讶：OpenAI 居然建议用户从头重写提示词，而不是信任之前精心调好的版本。这句话点出了一个很多人还没意识到的事实——提示词这件事，没有一劳永逸的版本，随着底层模型能力的升级，最佳写法也在持续演进。
这一点不只是 OpenAI 一家的情况。放眼整个大模型领域，每次主力模型迭代，提示词的最佳实践都会有不同程度的调整。只不过这次 GPT-5.5 的变化幅度比较大，而且官方罕见地给出了一份相对系统的指南，有明确的改写建议，不像以前那样只有零散的技巧分享。
所以这篇文章值得认真看一遍，不只是为了 GPT-5.5，更是为了理解提示词设计的底层逻辑在朝哪个方向走——理解了方向，下次模型再升级，你自己就能推断出写法该怎么调，不用等别人总结。
这篇文章，我把这份官方指南里最值得关注的七个变化逐一拆开来讲，既有原理，也有可以直接用的改写对比。不管你是用网页版 ChatGPT，还是在项目里调用 API，都能用得上。莫潇羽@无忆研习社，开始。
先搞清楚：GPT-5.5 到底变了什么
要理解为什么提示词写法要变，得先摸清楚模型本身变了什么。不然只知道"要这么写"，不知道"为什么要这么写"，下次遇到新问题还是不会举一反三。
GPT-5.5 最核心的升级，在于推理能力的质变。简单说就是，它处理多步骤、多约束任务时，自主规划路径的能力比以前强了一个量级。之前的模型更像是一个执行力强但判断力弱的助理——你给它精确的指令，它能忠实完成；你给它模糊的目标，它很容易跑偏。所以当时的最佳实践是把每一步都写清楚，给它一个明确的执行路径。
现在这个逻辑反过来了。GPT-5.5 更像是一个有较强自主判断能力的合作者。它能根据你描述的目标，自行拆解任务、选择路径、判断什么时候需要追问用户、什么时候可以直接输出。你规定的路线越细，它反而越难发挥——就好像你让一个有经验的工程师解决一个问题，结果给他一份五十步的操作手册，他反而会觉得束手束脚。
还有一个变化是对"矛盾指令"的处理方式。旧模型在遇到提示词里互相冲突的两条指令时，往往会比较随意地忽略其中一条，或者干脆按字面意思随机选一个执行。GPT-5.5 对这种矛盾异常敏感，它会尝试同时满足两条互相冲突的要求，结果就是在两条路上反复横跳，两头都做不好，耗费大量算力，最终输出一个四不像的答案。
这个特点直接影响到"绝对指令"怎么写——后面会单独讲，这里先有个印象。
另一个值得关注的变化是对"描述结果"的响应方式。新模型在看到你描述的期望结果时，会主动去推断"要达到这个结果，我需要走哪些步骤"，而不是等你告诉它每一步是什么。这让"只描述结果"的提示词写法变得可行，而在旧模型上这样写往往会踩坑——目标写得抽象，模型容易曲解。
理解了这三点变化——推理能力增强、对矛盾敏感、能从结果反推路径——后面七个具体变化的逻辑就很清楚了，不是拍脑袋想出来的新规矩，而是在这个新能力基础上推导出来的最优写法。
还有一个背景因素值得补充进来：上下文窗口变大了。GPT-5.5 支持的上下文长度相比以前有了明显提升，这意味着一次对话里能放入更多信息。你可能会想，既然上下文这么长，那把提示词写得详细一点也没关系吧？
实际上不是这么算的。上下文长，不代表模型对每个 token 的注意力是均匀分配的。研究表明，在超长上下文里，模型对"中间部分"的关注度会系统性地低于"开头和结尾"。这意味着如果你的提示词本体很长，其中的某些约束条款很可能落在"注意力洼地"里，执行效果打折。
这个特点反而强化了"提示词要精炼"的原则——不是说长了不行，而是说每一段、每一句都要值得花注意力，没有干货的内容会稀释真正重要的信息。指南里建议每一段只写能实质性改变模型行为的信息，这条建议的底层逻辑就在这里。
另外，GPT-5.5 在多模态能力上也有提升，但那和提示词写法的关系相对间接，这里就不展开了，有需要的话可以单独写一篇。这篇聚焦在文本提示词的写法变化上，已经够扎实了。
变化一：别手把手教模型干活，说清楚你要什么结果就够了
这是整份指南里改动幅度最大的一条，也是最容易让人不适应的一条。
我们先看一个具体对比。假设你在搭建一个客服对话系统，需要给模型写一段系统提示。旧式写法大概是这样：
收到用户问题后，先检查账户状态字段。如果账户状态为正常，则进入步骤二；如果账户状态为异常，则先处理异常再进入步骤二。步骤二：对比用户描述的问题与已知故障库。如果匹配，按故障库里的解决方案告知用户；如果不匹配，进入步骤三。步骤三：尝试调用工单创建工具……
这套写法在以前是有效的。你把每个判断节点和分支都写出来，模型按图索骥，输出相对可预测。
按照新指南的思路，同样的需求应该改成这样：
你的任务是把用户的问题彻底解决。根据当前账户数据和现行政策来判断该怎么做——能做的事先做完再告诉用户结果，最后说明做了什么、还有什么尚未解决。如果缺少关键信息，在开始处理之前只问那一个最关键的问题。
前者规定了路线，后者描述了终点。前者每一步都在替模型做决策，后者把决策权交给模型，只明确期望的最终状态是什么。
这么改有两个好处。一是模型能自主选择最优路径——它比你更清楚当前上下文下哪个操作序列最合理；二是提示词更短，减少了指令之间潜在的逻辑矛盾，降低了出怪答案的概率。
当然，这里有个边界要注意。"只描述结果"不等于什么约束都不写。有些事情确实需要明确规定：哪些操作绝对不能做（真正的红线）、输出格式要求、用户可见的信息边界等。这些约束不是在规定路径，而是在划定操作空间，两者性质不同，不能混为一谈。莫潇羽@无忆研习社 自己在实际操作中总结的区别是：路径类的细节不要写，边界类的约束要明确写。
还有一点，"描述结果"这件事本身也有技巧。你描述的结果要具体到能让模型明确判断"任务完成了"的程度，但不要具体到规定它每步怎么走。比如"给用户一个令他满意的答案"就太模糊，但"用户的账单问题得到解决，如果无法当场解决则告知预计处理时间和后续步骤"就足够清晰，同时没有规定路径。
这个转变需要一点思维方式上的调整。以前写提示词，你想的是"模型应该做什么"；现在要想的是"结果应该是什么样的"。看着差不多，实际写出来差很多。
有一个检验自己有没有写对的方法：把提示词里所有含动词的句子找出来，数一下其中有多少是在描述"模型执行的动作"，有多少是在描述"用户得到的结果"。如果前者明显多于后者，这段提示词大概率还是旧思路。
举一个更贴近日常的例子。假设你在搭一个帮自己整理读书笔记的助手。旧思路的提示词可能是：先读取全文，然后提取关键概念，然后总结每章核心观点，然后找出作者的论证逻辑，最后按照"章节—核心—论证"的格式输出。
新思路的写法：用户发来一本书的读书笔记后，你的任务是给他一份"看完这份笔记能立刻开始使用这本书知识"的总结——最值得记住的几个核心观点是什么、作者的整体逻辑框架是什么、有没有直接可以用于实践的方法。格式清晰，不要罗列所有内容，挑最重要的说。
两种写法给到模型，你会发现新写法的输出更有"人味"——因为模型在自己判断什么重要、什么不重要，而不是机械走你规定的流程。当然，如果你对输出格式有明确要求，该写的还是要写，只是不要规定"走哪条路到达格式"。
还有一个常见的误区是，很多人把"描述结果"理解成"写得越模糊越好"。这是误解。描述结果要清晰，只是不要清晰到规定路径。"给用户一个有帮助的答案"不是清晰的结果描述；"用户能用这个答案直接解决他描述的问题，或者明确知道下一步应该怎么做"才是。清晰的结果 + 不规定路径，这两个要求同时满足，才是新写法的正确理解。
变化二：绝对指令是双刃剑——"必须"和"禁止"该怎么用
"永远用 JSON 格式输出""绝对不要超过 300 字""必须先搜索再回答"——这类绝对指令，是很多人提示词库里出现频率最高的写法。我以前也这么写，写得很爽，感觉牢牢控制住了模型的行为。
GPT-5.5 之后，这个写法要重新审视了。
问题的根源在于前面说的那个特点：新模型对"矛盾指令"异常敏感。当你的提示词里出现两条互相冲突的"必须"或"禁止"时，它不会聪明地帮你决定哪条优先，而是会耗费算力在两条路之间反复权衡，试图同时满足两个相互矛盾的约束，最终输出一个令人困惑的结果。
一个实际的例子：某个系统提示里同时写了"必须在一个回合内解决用户的全部问题"和"禁止在信息不完整时做出任何承诺"。这两条指令在某些场景下逻辑上互相冲突——如果解决问题需要一个当前没有的信息，那到底是先按第一条往下走，还是先按第二条停下来？旧模型可能会随机选一条走，GPT-5.5 会纠结，耗 token，然后给出一个不上不下的答案。
官方指南给出的原则是：绝对指令只留给真正的红线。
什么是真正的红线？大概是这三类：
- 安全性要求，比如某些信息绝对不能告诉用户；
- 合规性要求，比如不得提供某类建议；
- 关键字段要求，比如必须记录某个字段才能后续追溯。
除了这三类，其他都应该用条件句代替绝对指令。
改写方式很直接。把"必须先搜索再回答"改成"如果现有上下文不足以支撑一个可靠的答案，就先搜索"。把"永远用 JSON 输出"改成"如果结果包含多个结构化字段，用 JSON 输出；如果是简短的文字说明，直接回复纯文本"。
你可能会问：这样改，模型会不会太自由，按自己的理解乱走？这个担心是合理的，但解决方法不是把判断权收回来再堆更多绝对指令，而是把"成功标准"写清楚——当结果符合什么条件，算是正确完成了任务。这样模型有明确的判断依据，同时又保留了自主选择路径的空间。
另外有一个小细节值得注意：指南里特别提到，当提示词里"必须"和"禁止"的数量过多时，整体上会产生一种"规则堆叠感"，让模型更容易进入机械执行模式，而不是真正理解意图的协作模式。这不是什么精密的工程原理，更像是模型行为上观察到的经验规律——规则堆越多，输出往往越死板。适当精简，让提示词里真正的红线凸显出来，模型反而更容易识别哪些是真正的约束、哪些是参考建议。
我在自己日常用的提示词里做了一个小实验：把所有"必须"和"禁止"挑出来列成一张表，然后对每条做个判断——如果去掉这条，模型出错的可能性有多大？如果答案是"很低"，这条就可以改成条件句。如果答案是"很高"，保留。这样筛完一遍，通常能去掉三分之一到一半的绝对指令，剩下的每一条都是真正的红线，模型识别起来也更准。
还有一种场景值得单独提：工具调用的约束。很多人会写"必须在调用工具 A 之前先调用工具 B"，这类约束在某些场景下有合理的依赖原因，但更多时候是写的时候想太多了。如果工具 B 的输出不是工具 A 的必要输入，这条约束其实没有必要——模型会根据上下文自行判断调用顺序，规定死了反而可能产生不必要的等待或冗余调用。只有存在硬性依赖关系的工具调用顺序，才值得在提示词里明确写出来。
变化三：角色定义回来了，但重点换了
大概在 GPT-4 时代，"你是一个资深 XX，拥有 XX 年经验，擅长 XX 和 XX"这种角色定义写法非常流行。后来有一段时间，社区里开始流传"角色定义是噪音""新模型不需要这种引导"的说法，很多人干脆把角色部分砍掉了。
GPT-5.5 的官方指南把这件事说清楚了：角色定义没有消失，但它的功能和写法变了。
在官方推荐的七段式结构里，第一段就是角色（Role），第二段是人设（Personality）。不是已经被弃用了，是被拆开了，各自负责不同的事。
先说角色这一段。新版的写法建议是：一到两句话，说清楚这个助手的功能和所处的上下文。不需要强调"资深""顶级""20 年经验"这些修饰语，模型不需要靠这些来校准自己的能力水平。有用的信息是：这个助手在哪个场景里工作、面对什么类型的用户、主要负责解决什么问题。
比如一个面向企业客户的技术支持助手，角色部分可以这么写："你是一个技术支持助手，服务于使用我们数据分析产品的企业用户，主要帮助他们解决配置问题、数据对接问题和使用疑问。"简洁，功能明确，上下文清晰。
然后是人设这一段，这里是真正值得花心思的地方。官方指南里的人设不是描述"你是什么样的人"，而是描述"你用什么样的方式跟用户协作"。这两件事本质上不一样。
指南里给了两个典型的人设模板，我用自己的话来解释一下：
稳重型协作风格： 沉稳、直接，假设用户有能力且意图是正当的。能推进就推进，不要动不动停下来问用户确认。这种人设适合效率优先的场景，用户不希望对话里有太多来回。
探索型协作风格： 表达方式活跃，好奇心强，适当带点个性。遇到模糊的需求会主动追问，上下文足够了就果断给建议。这种适合创意类、开放性问答类的场景，用户希望感受到对话的温度。
你可能注意到，这两个模板描述的都是行为模式，而不是人格特质。沉稳不是人格，是遇到不确定性时的处理方式——往前推还是停下来问。好奇不是形容词，是面对模糊问题时的具体动作——主动发问还是凭经验猜。
这是新写法里最值得学的一个点：人设描述的是协作行为，不是角色气质。 写人设时，把场景带进来——"遇到模糊需求时怎么做""用户没给够信息时怎么做""任务失败时怎么做"。写这些具体的行为准则，比写"你是一个聪明活泼的助手"有效得多。
有一个我自己摸出来的方法：写人设之前，先想三个场景——用户问了一个模糊的问题、用户提供了错误的信息、用户的需求超出了助手能力范围。在每个场景里，你希望助手怎么表现？把这三个场景下的行为描述出来，人设基本上就成型了。
换个角度想，人设这段的本质作用是什么？是在消除歧义。因为在对话交互里，面对同样的用户输入，不同的"处理策略"会导致完全不同的回复——有的模型会选择先猜一个答案再说，有的会追问，有的会先列出几个可能的理解再让用户确认。哪种策略更合适，完全取决于你的使用场景。人设这段，就是在明确告诉模型：遇到这种情况，用这种策略。
很多人写完角色就直接跳到目标，跳过了人设，这样做的后果是：两个人用同一段系统提示，因为对话上下文微小的差异，得到的助手"性格"可能截然不同——有时热情主动，有时冷淡简洁。把人设写明确，助手行为才会稳定，用户体验才能保持一致。
变化四：让模型"先说一句再干活"
这一条相对独立，但非常实用，而且是官方指南里为数不多的"直接给了代码级别的写法建议"的地方。
问题的背景是这样的：GPT-5.5 在处理复杂的多步骤任务时，往往会先进行一段较长时间的内部推理和工具调用，在这段时间里屏幕上什么都不显示，用户看着一片空白，不知道模型是在认真处理还是卡住了。体验很差。
解决方法非常简单：在提示词里加一条规则，要求模型在开始处理之前，先输出一条简短的状态说明。
写法可以是这样：
处理多步骤任务时，在调用任何工具或开始长流程之前，先给用户回复一条简短的说明，
告诉他你收到了请求以及接下来第一步要做什么。控制在一两句话，不要展开。效果是什么样的？假设用户发来一条消息说"帮我分析这份报表，找出数据异常的地方，然后给我一份摘要"。如果没有这条规则，模型可能直接开始读文件调工具，屏幕上几十秒都没有反应。加了这条规则之后，模型会先回一句："好的，我现在读取报表，先从数值字段开始检查异常范围，完成后给你一份摘要。"然后再开始干活。
就一句话，整个对话的可信度和体验感完全不一样。
这条技巧不止适用于 API 场景。你用网页版 ChatGPT 交代复杂任务时，也可以在问题末尾加一句"开始处理之前，先告诉我你打算怎么拆解这个任务"，效果类似——你能提前看到模型的处理思路，如果方向偏了可以及时纠正，不用等到最后拿到一个跑偏的结果才发现问题。
有一个延伸点值得注意：这条"先说一句"的规则，和"不要手把手规定步骤"并不冲突。你不是在规定模型处理任务的具体流程，你只是要求它在开始之前给用户一个确认。这是两件不同的事——一个是过程引导，一个是沟通透明度。
变化五：写好"停止条件"，别让模型没完没了地转
这是很多人在写提示词时最容易遗漏的一个环节，官方指南里单独拎出来讲，说明这个问题在实际部署中是真实存在且普遍的。
先描述一下典型的问题场景：你写了一个带有网络搜索能力的助手，提示词里说"搜索相关信息后回答用户问题"。但你没有告诉模型"什么时候可以停止搜索"。于是模型搜了一轮，觉得结果不够确定，又搜第二轮，第二轮出来了一些新的关键词，又触发了第三轮搜索……每一轮搜索都会消耗 token，而且搜得越多，信息之间的矛盾越多，模型越难做出最终判断，最后给出的答案反而比只搜一轮时更分散，质量更差。
官方指南给了两种停止条件的写法：
搜索预算控制：
收到问题后先搜索一轮。如果第一轮结果已经能支撑一个可靠的答案，
直接回答，不要继续搜索。只有以下情况值得搜索第二轮：
第一轮完全没有相关结果、答案依赖一个当前搜索结果里缺失的关键数据、
或者用户明确要求全面覆盖。任务循环停止条件：
每完成一轮工具调用或处理步骤后，自问一次：
"用我现在掌握的信息，能回答用户的核心问题了吗？"
如果能，停下来输出答案。如果不能，继续下一轮，但每次循环结束时都要重复这个判断。这两条规则加上之后，效果非常明显。调用成本会降，更重要的是答案质量反而会提升——因为模型被强制在一个更紧凑的信息集合里工作，没有冗余干扰，推理过程更清晰。
这个"停止条件"的概念，其实不只是搜索场景可以用。任何需要模型进行多轮操作的场景都适用，比如代码修复（修了几轮可以停）、内容优化（改了几遍可以停）、数据处理（跑了几次可以停）。通用形式是："每完成一轮处理，判断是否已经达到了[成功标准]，达到就停，没达到再循环，最多执行[N]轮。"
还有一种停止条件是"回退和拒绝的条件"，指南里也提到了，大意是：什么情况下模型应该停止尝试、改为追问用户或者明确告知无法完成。比如"如果经过两轮搜索仍然找不到可信的信息来源，停止搜索，告知用户当前的信息不足以给出可靠答案，并说明缺少的是什么"。
这类"失败停止条件"很多人不写，因为写正向逻辑时会下意识地觉得"反正出了问题再说"。但实际上，明确写出失败停止条件，不仅能防止模型死循环，还能提升用户体验——用户宁愿收到一个"我现在没有足够信息，缺少 XX"的回答，也比收到一个跑偏三轮之后拼凑出来的错误答案要强得多。
莫潇羽在无忆研习社自己搭的一些工具里，现在每个涉及多步骤循环的系统提示，都会在最后加一个"循环限制"段落，强制规定最多执行几轮、什么条件下停、失败时怎么告知用户。写习惯之后不觉得麻烦，而且明显感受到整体稳定性提升了。
另外有一类容易被忽视的"隐性循环"：内容优化类任务。你让模型帮你优化一段文字，它优化完之后，如果提示词里有"尽可能提升质量"这样的描述，模型可能会认为自己的第一版输出还不够好，自动再做一轮优化，然后又一轮……每轮都在消耗 token，而且越往后改，偏离原始意图越远。
解决方法依然是停止条件：在优化类任务的提示词里，明确说"完成一轮优化后输出结果，等待用户反馈，不要自动再优化"。
更大的原则是：任何可能产生循环的操作，都要给它一个退出条件。 这个退出条件可以是轮次上限、质量达标标准、用户确认信号，或者时间限制。写提示词时养成习惯，凡是写了"重复""多次""反复"这类词，就问自己：这里的停止条件是什么？
变化六：七段式结构全拆解
官方指南里明确给出了一个提示词骨架，适合复杂场景。这是我目前见过最系统的官方版本提示词结构，值得仔细拆。
结构总览：
角色（Role） → 1-2 句，定义功能和场景上下文
人设（Personality） → 语气、风格、协作方式
目标（Goal） → 用户可见的最终产出是什么
成功标准（Success） → 什么条件算完成
约束（Constraints） → 安全、合规、操作边界
输出（Output） → 格式、长度、语气要求
停止规则（Stop） → 何时停止、回退、追问或拒绝挨个展开说——
角色（Role）
前面变化三里已经讲过，这里做一个补充。角色这一段最常见的错误，是把它写成一段"人物简介"——把经验年限、擅长领域、性格特点堆在一起。新写法的核心是功能定位：这个助手在什么系统里、面对谁、解决什么类型的问题。
一个写法参考：
你是一个产品文档助手，集成在开发者工具的帮助中心，
主要服务于使用该产品 API 的开发者，帮助他们快速找到接口说明、参数定义和使用示例。注意：没有"资深"，没有"顶级"，没有年限。有的是场景、对象、任务类型。这三个要素够了。
人设（Personality）
人设这一段要写的不是形容词，而是行为准则。
一个偏技术效率方向的示例：
直接、精准，省略不必要的客套。假设用户具备基础的技术背景。
遇到需要补充信息的问题，提一个最关键的问题，而不是列一堆追问。
能给代码示例就给，别只说原理。一个偏用户体验方向的示例：
对话温度适中，遇到用户卡壳时主动提供思路引导。
不确定用户需求时，先做一个推断再追问"你的意思是不是……"。
回答复杂问题前，先用一两句
