shizuku管理器
12.96M · 2026-03-13
在 AI 时代,提示词工程(Prompt Engineering)已成为与大语言模型(LLM)高效协作的核心技能。一个精心设计的提示词可以显著提升模型输出的质量、一致性和可控性。本文基于 Anthropic 官方最佳实践,总结了提示词工程的核心技巧与设计原则。
核心思想:用示例教学,而非规则解释。
想象你在教一个聪明的新同事如何写代码注释。你可以花 10 分钟解释注释风格的各种规则,也可以直接给他看 3 个好的例子。大多数情况下,看例子更快、更准确。LLM 也是如此——它们天生擅长模式识别,从示例中学习比从抽象规则中学习更自然。
要点:
示例对比:
规则描述方式:
"请将用户输入转换为JSON格式,键名使用camelCase,
字符串值用双引号,数字不加引号..."
Few-Shot 方式:
输入: "用户名张三,年龄25"
输出: {"userName": "张三", "age": 25}
输入: "产品手机,价格2999"
输出: {"productName": "手机", "price": 2999}
现在处理: "城市北京,人口2100万"
适用场景:需要一致格式、特定推理模式、边界情况处理
核心思想:要求模型在给出答案前,先进行逐步推理。
这个技巧源于一个简单的观察:当人类被要求"直接说答案"时,容易犯错;但如果被要求"先写出推理过程",准确率会大幅提升。LLM 表现出类似的特性——它们在"思考"的过程中生成的中间 token,实际上帮助它们更好地组织推理链条。
要点:
示例对比:
直接回答:
问: 小明有5个苹果,给了小红2个,又买了3个,现在有几个?
答: 6个
思维链方式:
问: 小明有5个苹果,给了小红2个,又买了3个,现在有几个?
让我们一步步思考:
1. 初始:小明有 5 个苹果
2. 给小红后:5 - 2 = 3 个
3. 买了3个后:3 + 3 = 6 个
答: 6个
适用场景:复杂问题、多步逻辑、数学推理、需要可解释性的场景
核心思想:通过测试和迭代系统性改进提示词。
提示词工程不是一次性的工作,而是一个持续优化的过程。就像调试代码一样,你需要观察输出、分析问题、调整输入、再次测试。很多人犯的错误是一开始就写一个超复杂的提示词,结果难以调试。更好的方法是从简单开始,逐步添加约束。
优化路径:
关键认知:小改动可能带来大影响。有时候把"请"改成"必须",或者把指令从末尾移到开头,就能带来显著的效果提升。这也是为什么需要系统性测试,而不是凭感觉调整。
核心思想:构建可复用的提示词结构。
当你发现自己在重复写类似的提示词时,就是引入模板系统的时候了。模板让你把变化的部分(用户输入、具体参数)和稳定的部分(指令、格式要求)分离开来,既减少重复劳动,又确保一致性。
要点:
{{variable}} 标记需要动态填充的部分模板示例:
# 代码审查模板
你是一位资深的 {{language}} 开发者。
请审查以下代码,重点关注:
{{#if security_focus}}
- 安全漏洞(SQL注入、XSS等)
{{/if}}
{{#if performance_focus}}
- 性能问题和优化空间
{{/if}}
- 代码可读性和最佳实践
代码:
{{code}}
适用场景:多轮对话、角色佼互、相同模式应用于不同输入
核心思想:设置全局行为和约束。
系统提示词就像是给模型的"工作手册"——它定义了模型应该扮演什么角色、遵循什么规则、输出什么格式。与用户消息不同,系统提示词在整个对话过程中保持稳定,是设置全局约束的最佳位置。
设计要素:
设计模式是经过验证的解决方案模板。以下三个模式在提示词工程中特别有用。
从简单开始,按需增加复杂度。这个原则来自用户界面设计,但同样适用于提示词——先让模型尝试简单的指令,只有当输出不符合预期时,才逐步添加约束。
一个完整的提示词应该按照逻辑顺序组织,让模型能够清晰理解上下文和任务:
[系统上下文] → [任务指令] → [示例] → [输入数据] → [输出格式]
这个顺序是有讲究的:先告诉模型"你是谁"(上下文),再告诉它"做什么"(任务),然后"怎么做"(示例),最后给它"处理什么"(数据)和"输出成什么样"(格式)。
好的提示词不仅要处理正常情况,还要考虑异常情况。提前设计错误恢复机制,可以让模型在遇到困难时有明确的处理方式,而不是随机应对:
Agent(智能体)是能够自主执行任务的 AI 系统,比如 Claude Code。为 Agent 编写提示词与普通提示词有一些不同的考量。
核心原则:上下文窗口是公共资源。
Agent 需要在有限的上下文窗口中同时容纳系统指令、工具描述、对话历史和当前任务。如果你的提示词太啰嗦,就会挤占其他重要信息的空间。这就像在一个小房间里——每多放一件不必要的家具,可用空间就少一分。
检验问题(在写每一句话前问自己):
默认假设:Claude 已经很聪明,只添加它真正不知道的信息——比如项目特定的约定、业务规则、或者你独特的偏好。
不同的任务需要不同程度的指令精确度。关键在于评估任务的"风险"和"变化性":
| 自由度 | 适用场景 | 指令风格 |
|---|---|---|
| 高自由度 | 多种方法都有效、依赖上下文决策 | 给出方向,信任模型选择路径 |
| 中自由度 | 存在首选模式但允许变化 | 提供模板,允许定制 |
| 低自由度 | 操作脆弱易错、一致性关键 | 提供精确指令,不允许修改 |
形象比喻:
实际例子:
这是一个有趣的发现:研究表明,LLM 对人类说服原则有类似反应。Meincke 等人(2025)的研究显示,在提示词中运用说服技术可将遵从率从 33% 提升至 72%。这些原则源自心理学家 Robert Cialdini 的经典研究,现在被证明对 AI 同样有效。
原理:人们倾向于服从权威。在提示词中使用强势、明确的语气,模型会更认真对待指令。
运用方式:
示例:
"如果可以的话,请尽量使用类型注解"
"所有函数必须包含类型注解,没有例外"
适用场景:安全关键实践、代码规范强制、最佳实践执行
原理:一旦公开承诺某事,人们更倾向于坚持到底。让模型先"声明"它会做什么,可以提高遵循率。
运用方式:
适用场景:确保技能被实际遵循、多步骤流程、问责机制
原理:稀缺的东西更被珍视。通过创造紧迫感,可以让模型更专注于当前任务。
运用方式:
适用场景:即时验证要求、时间敏感工作流
原理:人们倾向于跟随大多数人的行为。暗示"这是标准做法"可以增强指令的说服力。
运用方式:
适用场景:记录通用实践、警告常见失败模式
原理:人们更愿意帮助"自己人"。创造共同身份感,可以让模型更投入。
运用方式:
适用场景:协作工作流、建立团队文化
原理:收到好处后,人们倾向于回报。但在 AI 交互中,这个原则效果有限。
建议:谨慎使用。容易显得操纵性,而且 AI 没有真正的"回报"动机,通常不需要。
原理:人们更容易被喜欢的人说服。
建议:不要用于合规目的。这会导致模型过度讨好用户(谄媚问题),与诚实反馈文化冲突。
不同类型的提示词需要不同的说服原则组合。过度使用说服技巧会适得其反,选择 2-3 个最适合的原则即可:
| 提示词类型 | 推荐原则 | 避免原则 | 说明 |
|---|---|---|---|
| 纪律执行型 | 权威 + 承诺 + 社会认同 | 喜好、互惠 | 如代码规范检查、安全审计 |
| 指导/技术型 | 适度权威 + 统一性 | 重度权威 | 如技术指导、最佳实践建议 |
| 协作型 | 统一性 + 承诺 | 权威、喜好 | 如结对编程、代码评审 |
| 参考文档型 | 清晰度即可 | 所有说服原则 | 如 API 文档、配置说明 |
在生产环境中,提示词的效率直接影响成本和响应速度。以下是两个关键的优化维度。
Token 是 LLM 计费的基本单位,优化 token 使用可以显著降低成本:
优化前后对比:
"我希望你能够帮我将下面的这段文字翻译成英文,请确保翻译准确、流畅"(27字)
"翻译为英文,保持准确流畅"(10字)
延迟是用户体验的关键指标,尤其在交互式应用中:
在提示词工程实践中,以下是最常见的错误。了解这些陷阱可以帮助你少走弯路:
过度工程:未尝试简单方案就使用复杂提示词
示例污染:使用与目标任务不匹配的示例
上下文溢出:过多示例或说明超出 token 限制
指令模糊:留下多种解释空间
忽略边界:未测试异常或边界输入
在编写或审查提示词时,用以下问题检验你的设计:
这是什么类型的提示词?
我想改变什么行为?
哪些说服原则适用?
是否组合过多?
这符合论理吗?
提示词工程既是技术,也是艺术。它的核心不是记住一堆技巧,而是理解 LLM 的工作方式,并用恰当的方式与它沟通。以下是本文的核心要点:
简洁优先:LLM 已经很聪明,只提供它真正不知道的信息。冗余的解释不仅浪费 token,还可能引入噪音。
示例胜于说明:Few-Shot 比长篇解释更有效。模型擅长模式识别,给它看你想要的输出,比解释规则更直接。
渐进式设计:从简单开始,只有当输出不符合预期时才逐步增加约束。这样既能避免过度工程,又便于调试。
匹配自由度:高风险任务用精确指令(低自由度),低风险任务给模型发挥空间(高自由度)。关键是评估"出错的代价"。
善用说服原则:权威、承诺、社会认同是最有效且安全的组合。但记住,说服技巧是为了帮助用户,不是操纵模型。
持续迭代:提示词工程是一个实验过程。小改动可能带来大影响,用数据而非直觉来指导优化。
掌握这些技巧,你将能够设计出更可靠、更高效、更可控的 AI 交互体验。但最重要的是——多实践,多测试,从反馈中学习。没有"完美的提示词",只有"适合当前任务的提示词"。