四个开发者必知的提示工程模式

刚开始写提示时，我总以为大语言模型（LLM）‘无所不知’，理应每次都给出完美输出。基于这种期待，早期提示给了模型过大的发挥空间，结果输出飘忽不定，让我怀疑自己用的AI和别人夸赞的是不是同一个。

后来我意识到，问题出在我自己身上。如果你也因LLM输出不稳定而头疼，别担心——解决方案就在这里。

什么是提示？

提示就是你向LLM提出的任何要求。技术上讲，它是发送给模型的任何输入，可以是一个单词，也可以是一段详细的系统消息。

在提示工程（Prompt Engineering）的语境下，提示是一种经过设计的输入，旨在引发可靠的输出。

提示工程到底意味着什么？

以前我以为提示工程就是向模型倾诉想法，指望它能把模糊的输入变成项目的成品。但这并不是提示工程。

举个例子，‘画一只猫’这个提示每次都会给出不同的结果。但如果你真正想要的是一张黑猫微笑、系着红色领结的图片，那就应该明确提出来。虽然每次结果仍会不同，但会更接近你的预期，而且你和模型可以在此基础上迭代改进，而不是一次次推倒重来。

这虽然是个简单的用户提示例子，却清晰展示了设计不佳的提示。当任务变得更复杂时，比如‘设计一个处理用户认证的系统’，问题就暴露得更明显：网站有多少用户？是微服务（Microservices）架构吗？需要OAuth、JWT还是会话认证？

说到底，设计一个好的提示就是为了减少方差，提高可靠性。

LLM如何处理提示

LLM并非魔法读心术。人类眼中的思考或推理，在LLM这里只是遵循训练中学到的统计模式。它们擅长将输出与输入提示进行模式匹配，而如果你能帮它们找到想要的模式，效果会更好。

LLM遵循指令时有一个权重层级：

• 系统指令（System Instructions）权重最高
• 开发者指令（Developer Instructions）次之
• 用户输入（User Input）最后

如何构建更好的提示

如果你需要构建一个具体工具，比如让团队能用纯英语查询数据库的内部工具，动手写提示前先做好调研。明确工具到底需要做什么，先问自己几个棘手问题：需要处理多表连接吗？应该在执行前验证查询吗？谁有访问权限？查询无结果时如何处理？动手前想得越清楚，后续让模型返工的时间就越少。

你不必是专家，LLM可以帮你做调研。但动手建网站前，务必先研究清楚，明确想让LLM构建什么。

强提示指令包含以下要素：

明确指令：清楚知道自己要什么，并明确提出来。‘构建一个待办事项应用’给模型的自由度太大。‘构建一个待办事项应用，任务勾选后能从屏幕清除，并带日历功能以便按天分配任务’则能细化输出。

上下文：给模型提供完成任务所需的信息。不必要的上下文会增加噪音，但信息太少会导致输出过于通用。如果你在构建面向工程师的后端工具，告诉模型：‘用户是专注于分布式系统的高级后端工程师。’这一行就能改变语气、词汇和假设的知识水平。

约束：没有约束，模型就会自行填补空白，从而扩大可能的输出范围。强约束能让输出可能性与你的期望保持一致。

输出格式：写代码时这点尤其重要。不指定格式，就无法可靠地解析输出。即使模型90%的时间返回看似合理的结果，剩下10%也可能在最糟糕的时刻破坏你的流水线。务必指定你期望的结构。

开发者必知的提示模式

我们不必每次向LLM提需求时都从头发明轮子。

少样本提示（Few-Shot Prompting） 为模型提供一个小型数据集，其中包含你期望的输出、结构、语气和风格。如果你发现自己正在长篇大论描述输出期望，不妨换成少样本提示。

思维链提示（Chain-of-Thought Prompting） 在你不太确定需求时很好用。这类提示要求模型在回答前逐步推理。这不仅能提升需要判断的任务的质量，还能让你与LLM成为思考伙伴。

角色提示（Role Prompting） 在为目标受众构建内容时能改善模型输出。为新手和专家构建的东西肯定不同。通过包含‘你是一名主要使用Snowflake数据、专注于产品分析的数据分析师（Data Analyst）’来设定领域上下文，这将影响词汇选择、假设知识和可能的权衡。

工具增强提示（Tool-Augmented Prompting） 通过赋予模型访问你工具的权限，使其成为真实信息的来源。只要提供相应的查询函数，比如 get_ci_build_status(pipeline_id: str) -> BuildResult 供其调用，工具增强提示就能帮你回答诸如‘上次构建的部署流水线返回了什么？’这类具体问题。

专业建议

因为学会做某事会让它看起来比实际更容易。

• 评估也很重要。不测量就不知道提示是否有效。
• 验证。验证输入。验证输出。对模型返回意外结果时该怎么做要有预案。

结语

总结这篇文章最好的方式，就是对比一下好提示和模糊提示的区别。

模糊提示：

好提示：