最近因为工作需要，我开始认真研究怎么写好一个 Prompt。以前我是想到什么写什么，总觉得字写多一点、要求说得全一点总没错。后来发现不是那么回事。这段时间看了一篇讲 Prompt 原则的文章，把里面的东西整理成了笔记，也结合自己工作中遇到的情况，记录一下我现在的理解。

先说一下我的情况：工作中主要写 Java 后端，平时会用 AI 帮忙写代码、排查报错、做技术方案、写单元测试之类的，用得不少，但一直凭感觉写 Prompt，没系统了解过。这次认真研究的契机是有一次排查一个线上问题，让 AI 帮忙分析日志，Prompt 改了半天输出还是没到点上。回去的路上就在想，到底哪里出了问题。

先说两个我踩过的坑

Prompt 越写越长，输出反而越来越差

有一次让模型帮忙出一个对接第三方支付的技术方案。需求不复杂——我们的系统要接一个支付网关，需要设计接口交互和回调处理。

我一开始的 Prompt 写了大概四五百字，项目背景、需求说明、技术栈、注意事项全塞进去了。觉得写得挺全的。结果模型输出的东西很散——列了一大堆技术点，什么消息队列、分布式锁、幂等性全扯进来了，但我真正想让它重点设计的对接流程和回调处理反而一笔带过。

我当时第一反应是：是不是我写得不够清楚？于是又加了一段，把对接流程的要求写得更细，还加了一句"请确保方案可落地"。结果更散了，模型好像什么技术点都说一点，什么都不深，最后还给我来了一段"综上所述，建议采用微服务架构实现解耦"——说了跟没说一样。

当时已经搞了快两小时了，有点烦躁。我停下来想了一下，觉得可能不是内容不够，是内容太多了。于是试着反过来做——把项目背景删掉，只留核心任务和对接流程的要求，然后把"重点设计对接流程和回调处理方案，其他技术点简要提及"挪到 Prompt 最前面。输出确实好了一些，至少对接流程的篇幅上来了，废话也少了一些。

这个过程让我意识到：问题不在信息量不够，在于信息太多，重要的东西被淹没了。我一开始觉得"写全一点总没错"，这个想法本身就有问题。

后来看那篇文章的时候，里面提到"信息密度"这个说法，跟我的感受对上了。Prompt 不是写得越多越安全，写得越长，真正重要的东西反而越容易被稀释掉。

明明写了约束，模型就是不照做

另一个让我头疼的情况：我在 Prompt 里明确写了某个要求，模型还是不照做。

那次是让模型帮忙写一段 Java 代码，处理订单状态流转。我在 Prompt 里写了"不要用 Lombok，用 Java 8 语法，不要用第三方库"。结果模型输出的代码里全是 @Data、@Builder 注解，还用了 Java 14 的 record。

我以为是表达不够清楚，又把"不要用 Lombok"改成"严格不使用 Lombok，不要加任何 Lombok 注解"，还加了"请使用 Java 8 语法，不要使用 record"。还是照样给我加 @Data，还用了一个 var——Java 10 才有的。我又加了一条"注意：以上约束必须遵守"——然并卵，该用还是用。

当时挺纳闷的，明明白纸黑字写了"不要用 Lombok"，为什么模型就是不照做？我换了一个模型试，结果差不多。

后来看那篇文章的时候，里面提到了一个叫 “Lost in the Middle” 的现象——模型对 Prompt 开头和结尾的内容记得比较清楚，中间的内容容易被忽略。我回头看了看我那个 Prompt，"不要用 Lombok"和"用 Java 8 语法"这几个约束被我写在了中间偏后的位置，前面还有一大段需求说明和业务逻辑。

我试着把约束挪到 Prompt 最末尾，重新跑了一遍。这次 Lombok 注解没了，语法版本偶尔还会跑偏，但比之前好不少。

这个坑给我的教训是：约束的位置可能比约束的措辞重要。我之前以为只要写了就行，没想过放在哪里。

不过说实话，我也不确定这是不是完全准确的原因解释。“Lost in the Middle” 那个现象我是在讲 Prompt 原则的那篇文章里看到的，具体是哪篇不太记得了，可能是引用了某个研究。我的理解可能不完全对，但"把约束放首尾"这个做法确实对我有用。

我的理解：核心是界定边界，不是堆砌信息

踩完这两个坑之后再看那篇文章，有一句话我印象很深：一个好的 Prompt 基本由四要素构成——Role（角色）、Task（任务）、Context（上下文）、Format（格式）。

我现在写 Prompt 的时候会先想清楚这四件事：让模型扮演谁、要它做什么、有什么背景、结果按什么格式给。四件事想清楚了，Prompt 基本就成形了。不需要写很多，但每一句都要知道它在四要素里属于哪一块。

再结合前面那个"Lost in the Middle"的教训，现在写 Prompt 的时候，最重要的约束我会尽量放在开头或者结尾，不埋在中间。

这个框架对我来说挺有用的，至少写 Prompt 的时候心里有数了，不用每次都从头想。但也不敢说这是最优写法——那篇文章里讲的东西我还没完全消化，有些技巧没实际试过。

技巧没有万能的，按场景组合

那篇文章列了六种技巧：角色扮演、思维链（CoT）、少样本学习（Few-shot）、任务分解、结构化输出、XML 标签。

里面有一句话我印象很深：技巧服务于"稳定性"。我的理解是，用技巧是为了让输出稳定，而不是时好时坏地碰运气。所以没有一种技巧是万能的，得看场景来选。目前我自己的做法大致是：

简单任务，写个短 Prompt 就行；复杂一点的推理，用思维链，让模型把思考过程一步步写出来；对格式有严格要求的，用 Few-shot 给几个例子，或者直接给 JSON Schema；任务太长，就拆成几步，一步步来（Prompt Chaining）。

六种技巧里我实际用过的：

角色扮演用过一些，让模型扮演"有 10 年经验的 Java 后端工程师"来写代码，比不给角色的时候输出专业一点，至少不会给我写出一堆不能编译的伪代码。但也不是所有任务都需要——让它格式化一段 SQL 给不给角色区别不大。

CoT 用过几次，在排查问题的时候效果明显。比如有一次线上接口超时，我让模型分析可能的原因，加了"请一步步分析，先列出可能的性能瓶颈点，再逐一排查"之后，输出比直接问"为什么接口慢"要有逻辑。不过简单任务用不上，反而让输出变啰嗦。

Few-shot 我用得最多。对代码格式有要求的时候特别管用——给两三个方法示例放进去，模型就知道你想要什么风格了。有一次让模型按特定格式生成接口文档，我用文字描述了三遍格式它还是不对，给了两个示例就对了。那次之后我基本养成习惯，格式要求一律用示例说话，不再用文字描述了。

任务分解偶尔用。需求复杂的时候我会拆成几步来问——第一步先让它出接口设计，确认了再让它写实现代码，最后再让它补单元测试。不是每次都需要，但对于比较复杂的业务逻辑，分步来比一次性写完质量好。

结构化输出和 XML 标签我没怎么用过。结构化输出偶尔用，让模型输出 JSON 格式的接口定义时会指定一下字段。XML 标签不太熟，还没研究怎么用。

最后落到一句话：能用示例就别用文字，能拆分就别硬塞进一个 Prompt。这是我自己用下来最大的感受。

那篇文章和我的学习顺序

我说的"那篇文章"是一篇讲 Prompt 工程原则的长文，具体标题不太记得了，是公司技术群里有人分享的。里面讲了四要素、六种技巧、还有"Lost in the Middle"这些概念。对我帮助最大的是"信息密度"和"约束位置"这两个点，正好对应我踩的两个坑。

如果让我重新学一遍，我会先自己踩几次坑（这个好像避不开），然后看四要素框架，再一个一个试六种技巧。不要一上来就全部用——用了才知道哪个场景需要哪个。六种技巧里我觉得最先可以试的是 Few-shot，效果最直观，格式问题一给示例就解决。其次是 CoT，对排查类任务提升明显。其他的看需求。

刚学 Prompt 的时候最困惑的几个问题

Prompt 到底写多长合适？

我之前总觉得越长越全面越好，后来发现不是。我的经验是：能说清楚任务就行，别为了"全面"硬加背景和约束。四要素想清楚，每一句知道属于哪一块，差不多就够了。我现在的 Prompt 一般在一两百字左右，比以前短了不少，效果反而好一些。

要不要给模型一个角色？

看任务。需要技术深度的内容（写代码、做方案）给个角色有点用，给"有 10 年经验的 Java 工程师"角色之后，输出的代码至少能看，不会给你整一堆不存在的方法。简单任务（格式化 SQL、解释报错信息）给不给区别不大。我试过给"资深架构师"角色来格式化 SQL，输出反而变啰嗦了，加了一堆不需要的架构分析。

模型不按约束来怎么办？

先看约束放在 Prompt 的什么位置。如果是长 Prompt，约束可能被"中间淹没"了，试试挪到开头或结尾。还不行就给个示例（Few-shot），用示例来示范约束比用文字写约束管用。比如"不要用 Lombok"这个约束，与其写三遍"不要用 Lombok"，不如直接给一段没有 Lombok 注解的代码示例，模型照着写就不会加。

还没搞懂的

目前我就到这个程度。那篇文章里有些东西我还没完全消化——比如 XML 标签怎么用、任务分解和 Prompt Chaining 的边界在哪、结构化输出除了 JSON 还有什么场景。还有一点我不确定：四要素框架是不是适用于所有类型的任务？我感觉复杂任务可能需要更多结构，但具体怎么加我还没想清楚。

这些都是我从那篇文章里整理出来的理解，工作里实际撞过的主要是前面说的这两种情况。