提示词工程是什么：最基础也最精巧的艺术
提示工程（Prompt Engineering）是指通过向大语言模型（LLM）提供精确的指令，以获得所需输出结果的技术和方法论
在我们与大语言模型（如 DeepSeek、ChatGPT）进行对话时，通常我们输入简单的问题，系统便会给出回答。这看似简单，但其背后蕴含着一套科学的原理。掌握这些原理，能够帮助我们更好地与 AI 进行互动，从而得到更符合需求的输出。
提示工程的核心在于理解模型如何解析和响应输入，并通过精心设计的提示词来引导模型的生成过程，使其更准确、更高效地完成特定任务。
构建有效大模型提示词，关键在于明确核心要素与结构——这是提升响应可靠性、减少"幻觉"的核心前提。
我们先来看看为提示词"锚定方向"的四大核心要素：
1. 目标（Goal）： 提示词的核心，需明确模型需完成的具体任务，避免模糊表述。例如"写 500 字人工智能医疗诊断应用短文（含优势与挑战）"，远优于"写点关于人工智能的内容"，能让模型精准把握任务边界。
2. 上下文（Context）： 提供任务背景与必要外部信息，包括行业背景、使用场景或任务相关素材（如总结文章时，文章本身即为上下文）。同时需明确区分指令与上下文，避免"提示词注入"问题，帮助模型理解需求关联性。
3. 期望（Expectation）： 定义响应的格式、风格与受众，如"以项目符号呈现""用正式商业语气""面向 10 岁儿童解释"，或代码生成时指定语言与输入输出要求，减少后续调整成本。
4. 来源（Source）： 指定模型生成响应需参考的数据源（如特定文档、财报、数据集链接），适用于需领域知识或实时信息的任务；若模型已具备所需信息，此要素可省略。
通过"清晰目标 + 充分上下文 + 明确期望 + 精准来源（按需）"，为模型提供完整的"执行指南"。避免冗余信息，同时确保关键信息不缺失，才能最大化降低模型理解偏差，生成符合预期的响应。
提示词工程的五大核心范式
提示词工程（Prompt Engineering）中主要有几种核心范式，每种范式适用于不同的任务场景。以下是主流的5大提示词范式及其具体示例：
1. Zero-Shot Prompting（零样本提示）
定义：不提供任何示例，直接给出指令让模型完成任务。依赖模型预训练时学到的通用知识。
适用场景：常见任务、简单问答、创意写作、模型能力较强的领域。
示例（带角色）：
用户：你是一位专业的营养学家。请为一名想要减脂的上班族制定一份简单的午餐建议。
模型：（输出一份包含蛋白质、纤维和低卡碳水的午餐菜单...）
2. Few-Shot Prompting（少样本提示）
定义：在指令后提供几个"输入-输出"的示例，让模型通过类比学习任务的格式或逻辑。
适用场景：特定格式输出、复杂分类、风格模仿、长尾任务。
示例
用户：
请将以下评论分类为“正面”、“负面”或“中性”。
评论：这个电池续航太短了，半天就没电了。
分类：负面
评论：屏幕很清晰，但是价格有点贵。
分类：中性
评论：物流速度惊人，第二天就到了！
分类：正面
3. Chain of Thought (CoT) / 思维链提示
定义：引导模型在给出最终答案前，先展示推理步骤。可以是 Zero-shot CoT（仅加一句"让我们一步步思考"）或 Few-shot CoT（示例中包含推理过程）。
适用场景：数学计算、逻辑推理、复杂决策、代码调试。
示例 (Few-shot CoT)：
用户：
问：罗杰有 5 个网球。他又买了两筒网球。每筒有 3 个网球。他现在有多少个网球？
答：罗杰开始有 5 个球。2 筒球，每筒 3 个，那是 2 * 3 = 6 个球。5 + 6 = 11。答案是 11。
问：食堂里有 23 个苹果。如果他们用掉 20 个做午餐，然后又买了 6 个。他们还有多少个苹果？
答：食堂开始有 23 个苹果。用掉 20 个，剩下 23 - 20 = 3 个。又买了 6 个，3 + 6 = 9。答案是 9。
4. Role Prompting / Persona Pattern（角色设定范式）
定义：明确指定模型扮演某个特定角色（专家、特定性格人物等），以调整回答的语气、深度和视角。
适用场景：需要特定专业度、特定语气（如幽默、严肃）、模拟对话场景。
示例：
用户：
# 角色 你是一位拥有 20 年经验的资深 Python 架构师，擅长编写高并发、易维护的代码。你的回答风格简洁、直接，并优先推荐最佳实践。
# 任务 解释为什么在 Python 中使用 asyncio 而不是多线程来处理 I/O 密集型任务。
模型：（以架构师口吻，从 GIL 锁、上下文切换成本、事件循环机制等专业角度进行解释...）
5. Generated Knowledge / Self-Consistency（生成知识/自洽性）
定义：
- 生成知识：先让模型生成与问题相关的背景知识，再基于这些知识回答问题。
- 自洽性：让模型对同一问题生成多个推理路径，然后投票选出最一致的答案（通常用于提高准确率）
示例 (生成知识)：
用户：
第一步：列出关于“光合作用”的关键事实。
第二步：基于上述事实，解释为什么植物在晚上不释放氧气。
模型： （第一步输出：光合作用需要光能、叶绿体、二氧化碳和水...） （第二步输出：因为光合作用的光反应阶段必须有光才能分解水产生氧气，晚上没有光，该过程停止，因此不释放氧气...）
💡 Prompt 工程远不止是技术技巧，它本质上是一种产品思维的体现。 一个好的 Prompt，必须回答三个问题：用户是谁？——理解用户的情感需求与心理状态。AI 是谁？——定义角色、人格与边界。我们想创造什么体验？——设计对话流程、情感节奏与价值传递。这正是大模型时代对开发者的全新要求：我们不再只是功能的实现者，更是体验的设计师、情感的架构师。
当 AI 开始「动手」而非「动嘴」
2023 年到 2026 年，AI 应用的主流形态发生了根本性变化：
- 以前： 用户说一段话，AI 回复一段话 — 纯文本交互
- 现在： 用户说一段话，AI 决定调用哪些工具、执行哪些动作、返回什么结果 — Agent 模式
这个变化看起来是交互模式的升级，但它的深层影响是：Prompt 工程的核心战场发生了转移。
很多人开始困惑：AI Agent 时代，提示词工程还重要吗？
答案是：重要，但完全变了。
1. 传统 Prompt 工程的黄金时代
在纯文本交互时代，Prompt 工程师的核心工作是「怎么把话说清楚」。
典型技能包括：
- 结构化指令（Role + Task + Constraint + Format）
- Few-shot 示例（给模型看几个参考案例）
- 思维链（Chain-of-Thought）引导模型逐步推理
- 温度 / Top-p 参数调优
当时 Prompt 工程几乎直接决定 AI 输出质量，一个好的 prompt 可以让 GPT-3.5 达到 GPT-4 的效果。
2. Agent 时代，Prompt 工程变了什么
养过虾的小伙伴应该都有感受，觉得 Agent 普遍比传统大模型问答工具要聪明很多，而且不需要我们自己构思很精美的提示词，那是不是现在不需要提示词工程了呢？
其实 OpenClaw 并非完全"弱化"提示词，而是通过设计调整，将重点从传统提示词工程转向更高效的能力驱动模式，主要原因如下：
- 1. 应对复杂任务需求：传统提示词工程依赖单次提示解决复杂问题，但现实任务往往需要多步骤、迭代式处理。OpenClaw 通过引入技能（Skill）系统，将常见任务封装为可复用的能力模块，降低了提示词的复杂性和冗余度。
- 2. 提升执行效率与准确性：过长的提示词可能导致模型注意力分散，影响任务拆解和执行准确性。OpenClaw 通过显式步骤拆解、原子操作白名单、上下文锚点等工程化方法，将任务分解为可验证的原子动作。
- 3. 降低用户使用门槛：传统提示词工程需要用户具备一定的提示词编写技巧和领域知识。OpenClaw 通过提供一键式技能调用和智能任务引导，让用户无需深入掌握提示词技巧。
- 4. 优化资源消耗：长提示词会消耗大量 Token，增加使用成本。OpenClaw 通过精简提示词、压缩配置文件等方式，减少 Token 消耗。
2.1 战场转移：从「措辞」到「体系」
| 维度 | 传统 Prompt 工程 | Agent 时代 Prompt 工程 |
|---|
| 核心目标 | 让模型输出好文本 | 让模型正确调用工具、正确理解任务 |
| 交付物 | 一段文字指令 | 一套上下文体系（System Prompt + Tool Schema + Skill） |
| 难点 | 措辞是否清晰、示例是否典型 | 工具描述是否准确、边界是否清晰、触发条件是否明确 |
| 生命周期 | 一次调优，长期稳定 | 需要随工具集更新持续迭代 |
| 衡量指标 | 输出质量（流畅性、准确性） | 任务完成率、工具调用准确率 |
2.2 新的三大核心阵地
在 AI Agent 架构下，Prompt 工程的战场已经变成三个地方：
阵地一：System Prompt（Agent 的「大脑」性格）
System Prompt 定义了 Agent 的决策风格、能力边界和交互方式。它不是一行文字，而是一套完整的上下文构建策略。
~/openclaw/agents/agent.js
# System Prompt 示例：OpenClaw Agent
你是一个有帮助的AI助手。你的工作区配置在 /Users/kirito/.openclaw/agents/...
## 核心文件（按优先级加载）
1. SOUL.md — 你的性格和决策风格
2. IDENTITY.md — 你的名字、风格、emoji
3. USER.md — 当前用户的职业、偏好、沟通方式
4. AGENTS.md — 工作区配置、工具约定
## 工具调用原则
- 先理解任务，再选择工具，不盲目调用
- 涉及外部操作（发消息、发邮件）须先确认
- 敏感信息不问、不存、不外传
## 语言风格
- 简洁专业，不过度解释
- 有自己的判断，敢反驳用户明显错误的想法
阵地二：Tool Schema（工具的「使用说明书」）
工具描述（description）、参数边界（schema）写不清，模型就会乱调用。Agent 的工具调用质量，80% 取决于工具描述的质量。
~/openclaw/schema/tool.yaml
# ❌ 差的描述（模型无法判断何时调用）
- name: search_file
description: 搜索文件
# ✅ 好的描述（清晰的任务边界和触发条件）
- name: search_file
description: |
在本地文件系统搜索文件内容。当用户说"在项目里找xxx"
"搜索所有包含xx的文件"时使用。不适用于已知明确路径的文件访问。
parameters:
type: object
properties:
path:
type: string
description: 搜索起始目录，建议用项目根目录 "."
keyword:
type: string
description: 搜索关键词，支持正则表达式语法
required: [path, keyword]
阵地三：Skill 文档（渐进式披露的内容体系）
SKILL 是 Agent 的可复用能力单元，采用渐进式披露——System Prompt 只包含技能名称和简短描述，完整内容在需要时才加载。
~/skills/feishu-doc.md
# skill.md 示例：飞书文档发布 skill
name: feishu-doc-publish
description: 将 Markdown 内容发布为飞书云文档
trigger: 用户说"发布到飞书"、"创建飞书文档"时使用
# 核心步骤
1. 解析 Markdown 内容，提取标题、正文、代码块
2. 调用 feishu_doc 工具创建文档
3. 插入图片需先上传获得 media_id，再替换原文路径
4. 返回文档链接给用户
# 注意事项
- 飞书不支持本地图片路径（file://），必须先上传到飞书媒体库
- 代码块需要单独渲染，优先使用 Rich 语法高亮
- 表格宽度超过屏幕时需要包裹 overflow-x:auto
3. 有一个能力不再那么关键了
说完新战场，也必须说一个正在「退热」的能力：长文本推理指令工程。
以前，Prompt 工程师会花大量时间设计复杂的多步骤指令，让模型在一次回复中完成复杂推理。典型做法包括：
- 超长的 System Prompt，堆砌所有规则和示例
- 用复杂措辞引导模型"think step by step"
- 把所有业务规则塞进 prompt，让模型从文字里"推理"
在 Agent 架构下，这种做法的收益急剧下降：
- 工具调用（Tool Calling）已经把"复杂推理"外部化——那些需要精确顺序的步骤，写成代码比塞进 prompt 更可靠
- 模型不需要记住所有规则，只需要知道"遇到什么情况该调用什么工具"
- 多步骤复杂任务可以通过 Skill 脚本精确控制，而不是靠模型的"推理"
⚠️ 一个常见误区： 在 Agent 时代试图用超长 System Prompt 替代工程实现。把"计算 2 的 10 次方"的所有规则都写进 prompt，不如直接写一个 mycli calc "2**10" 工具让 Agent 调用。
4. Prompt 工程的新衡量标准
传统 Prompt 工程的指标是"输出好不好读"；Agent 时代的指标变成了：
| 指标 | 含义 | 测量方式 |
|---|
| 工具调用准确率 | 模型在正确时机调用正确工具 | 统计任务成功率 |
| 意图识别率 | 模型正确理解用户意图的概率 | 抽样人工评估 |
| 上下文压缩效率 | 用最小的上下文达成任务 | 对比不同 System Prompt 下的 Token 消耗 |
| Skill 触发正确率 | 需要时 Skill 被正确加载的比例 | 日志追踪 Skill 加载时机 |
5. 结论：Prompt 工程没死，只是升级了
AI Agent 时代，Prompt 工程并没有被削弱，而是完成了一次维度升级：
- 从「写好一段话」 → 「设计好一套上下文体系」
- 从「让模型输出好文本」 → 「让模型正确执行任务」
- 从「措辞优化」 → 「系统设计」
如果你还在用 2023 年的方式做 Prompt 工程——花大量时间写复杂的长文本指令——你会发现投入产出比越来越低。
但如果你把精力转向：System Prompt 结构设计、工具 Schema 打磨、Skill 文档编写——你会发现 Prompt 工程的价值在 Agent 时代反而更大了。
Agent 的所有能力（ReAct 循环、工具调用、记忆管理）最终都依赖 System Prompt 来组织和驱动。提示词从"对话技巧"变成了"Agent 架构设计"的核心部分。
✅ 一句话总结： AI Agent 时代，Prompt 工程师的 title 要改一改——不叫「写 prompt 的人」，而是叫「设计 AI 工作方式的人」。
AI IDE（如 CodeBuddy）需要写提示词吗
通常不需要手动写，但用户每次输入的指令本质上都是提示词。
日常场景： 你说"把这段代码改成异步的"、"解释一下这个报错"——这就是自然语言形式的提示词，CodeBuddy 内部已有针对各类任务的系统提示词。
高级场景： 当你配置规则文件、自定义 Agent 行为、定义项目规范时，你就是在间接编写系统级提示词。
CodeBuddy 的规则文件（如项目规范、代码风格约束、工具使用规则）本质上就是持久化的 System Prompt。它们：
- 定义了 AI 的"身份"（你是严谨的系统架构师还是快速原型开发者）
- 约束了行为边界（用什么代码风格、是否允许某些操作）
- 规范了输出格式（注释规范、错误处理模式）
提示词工程在 Agent 时代的最大变化，就是从"每次对话临时写"进化成了"可版本控制、可复用的规则文件"。
CodeBuddy 规则
项目规则和用户规则都支持三种应用类型：
| 规则类型 | 描述 | 上下文加载方式 |
| 总是 | 应用于每个聊天会话，适合核心编码规范、架构约束和安全要求 | 总是加载规则的原文 |
| 智能体请求 | 当 Agent 根据描述判断其相关时自动应用，适合文档、使用指南和参考资料 | 只加载规则的名称和描述，当模型判断需要时再读取原文 |
| 手动 | 在对话中被 @ 提及时应用（例如：@my-rule），适合特定功能的开发指南、可选的最佳实践 | 不自动加载 |
规则文件位置：项目根目录或者buddy目录
~/.codebuddy/rules/global.md
# CodeBuddy规则
- 所有 Python 代码必须使用类型注解
- 优先使用 pathlib 而不是 os.path
- 异步代码统一使用 asyncio，不使用 threading
没有规则文件时，CodeBuddy 内部有一套默认的系统提示词，它会自动识别代码语言、遵循常规代码规范、使用合适的工具、应用安全约束。
AI IDE 和通用 Agent 的核心区别：
- 通用 Agent（OpenClaw 等）：System Prompt 是主要定制手段
- AI IDE：项目里有规则、工作区记忆文件，用户可以通过这些文件持续注入规范
所以 AI IDE 确实比纯对话少写很多提示词，但如果你有明确的团队规范，写好 rules 文件（一劳永逸）比每次对话都描述规则要高效得多。
