研究 Prompt 的这段时间：核心是界定边界，不是堆砌信息

最近因为工作需要我开始认真研究怎么写好一个 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 还有什么场景。还有一点我不确定四要素框架是不是适用于所有类型的任务我感觉复杂任务可能需要更多结构但具体怎么加我还没想清楚。这些都是我从那篇文章里整理出来的理解工作里实际撞过的主要是前面说的这两种情况。