一、前言

前面讲了Cursor、Codex、Claude Code的区别,当我们选定开发辅助工具,接下来就是通过高效准确的语言(Prompt)、技能(Skill)来提高我们的效率,接下来这篇文章介绍怎么使用Prompt高效使用AI Agent。

二、什么是 Prompt

Prompt 是用户输入给大语言模型(LLM)的指令或问题,是人与 AI 协作的核心界面。

工作原理简述:LLM 本质上是一个"下一个词预测器"。Prompt 的作用是约束模型的输出空间,引导它在正确的方向上生成内容。一个好的 Prompt 相当于给模型划定了明确的范围和目标,让模型知道"你要什么、不要什么"。

三、Prompt 的基本结构

一个完整的 Prompt 通常包含以下要素:

要素 说明 示例
角色(Role/Persona) 让模型扮演特定身份,激活对应领域的知识分布 “你是一名资深后端架构师”
任务(Task) 明确告诉模型要做什么 “帮我审阅以下 SQL 语句”
上下文(Context) 提供背景信息、约束条件、输入数据 “数据库是 MySQL 8.0,表数据量约 500 万行”
格式要求(Format) 规定输出的结构和形式 “请用表格列出问题及修复建议”
约束(Constraints) 限制输出的范围或风格 “每条建议不超过 50 字,不要提建索引以外的方案”

示例对比

差的 Prompt

帮我看看这段代码有什么问题。

好的 Prompt

你是一名 Java 后端开发。以下是项目中的 SQL 生成方法,请审查是否有 SQL 注入风险、性能问题或逻辑缺陷。如果有问题,请用表格列出:问题位置、问题描述、修复建议。代码:

...

四、核心技巧

4.1 Zero-shot Prompting(零样本提示)

不提供示例,直接描述任务。适合简单、通用的任务。

将以下句子翻译成英文:"今天天气真好。"

4.2 Few-shot Prompting(少样本提示)

提供 1-3 个示例,帮助模型理解期望的输出模式。适合需要特定格式、风格或复杂推理的任务。

将以下中文短语转为英文驼峰命名:

"用户名称" → userName
"订单编号" → orderNo
"登录时间" → loginTime
"部门列表" →

4.3 Chain of Thought(思维链)

在 Prompt 中加入"让我们一步一步思考"或给出带有推理步骤的示例,引导模型逐步推理。对数学、逻辑、多步推理任务效果显著

问题:小王有 15 个苹果,给了小李 3 个,又买了 5 个,然后吃掉了 2 个。
他最后有几个苹果?

让我们一步一步思考:
1. 初始:15 个
2. 给小李 3 个:15 - 3 = 12 个
3. 买了 5 个:12 + 5 = 17 个
4. 吃了 2 个:17 - 2 = 15 个
答案:15 个

比直接问 “15 - 3 + 5 - 2 = ?” 的准确率显著更高。

4.4 角色设定(Persona)

为模型赋予专业身份,可以激活该领域的语料分布,显著提升专业任务的输出质量。

你是一名经验丰富的 DBA,日常工作是为 MySQL 数据库做性能优化。
请审查以下慢查询,给出优化方案。

4.5 输出格式控制

明确指定输出格式,减少后处理成本。

  • 结构化:“请以 JSON 格式返回”、“输出为 Markdown 表格”
  • 分段:“分三个部分:问题、原因、解决方案”
  • 字数/行数限制:“用一句话总结,不超过 50 字”
  • 正负面约束:“不要使用专业术语”、“请包含代码示例”

4.6 分步分解(Step-by-Step)

将复杂任务拆成多个步骤,在单次 Prompt 中描述完整流程。

请按以下步骤分析这段代码:

1. 先总结这段代码的主要功能(一句话)
2. 列出所有潜在的性能问题
3. 针对每个问题给出修复方案
4. 最后给出修复后的完整代码

五、进阶策略

5.1 Self-Consistency(自洽性)

对同一问题多次采样,取多数投票结果。适用于推理类、有确定答案的任务。在代码层面实现(调用 API 时 temperature > 0,多次请求再聚合),而非 Prompt 本身。

5.2 Tree of Thought(思维树)

让模型在关键节点探索多条推理路径,比较后选择最优路径继续。适用于复杂规划、创意任务。

问题:如何在 3 天内完成一个团队的代码审查流程搭建?

请列出 3 种不同的推进思路,比较每种思路的优劣,然后选择最优方案详细展开。

5.3 ReAct 模式(Reason + Act)

让模型交替进行"思考"和"行动"。"思考"判断当前状态并决定下一步做什么,"行动"从外部获取信息(工具调用 / RAG 检索),反复迭代直到完成。

你是一名技术支持工程师。请按以下方式解决问题:

Thought: 分析当前已知信息,判断还需要什么信息
Action: 描述需要查询什么
Observation: (填入查询结果)
...重复以上步骤...
最终给出解决方案

这是 Agent 系统(如 Claude Code)的工作原理基础。

5.4 结构化 Prompt 模板

在生产系统中,使用模板变量来标准化 Prompt:

## 角色
你是 {role}。

## 背景
{context}

## 任务
{task}

## 约束
{constraints}

## 输出格式
{format}

这样做的好处:可复用、可版本管理、可 A/B 测试、可团队协作维护。

5.5 反向 Prompt(让模型提问)

当需求不明确时,先让模型向你提问,澄清需求后再回答。

我想优化一个 SQL 查询的性能。在给出优化建议之前,请先问我几个关键问题,以帮助我描述清楚场景。

六、常见误区

误区 说明 正确做法
指令模糊 “帮我写个好的” — 模型不知道你的"好"是什么标准 给出具体标准:性能、可读性、安全性
信息过载 一次性塞太多无关上下文,模型抓不住重点 只提供与任务直接相关的信息
缺少约束 不限制输出长度/格式,结果冗长或格式不可用 明确格式、字数、结构要求
忽略边界情况 不给模型划定"不能做什么",可能产生不合适的输出 明确约束:语言、框架版本、禁止事项
一次做太多 单个 Prompt 塞 5 个不相关的任务 一个 Prompt 聚焦一个问题
过度依赖 Few-shot 给太多示例反而限制模型的泛化能力 简单任务 Zero-shot 即可,示例只在必要时加
忽视角色设定 模型没有方向,输出内容平庸 设定一个具体的专业角色

七、实战案例

案例 1:代码审查

你是项目技术负责人。请审查以下 PR 中的代码变更,重点关注:

1. 是否存在安全漏洞(SQL 注入、XSS 等)
2. 是否存在性能隐患(N+1 查询、内存泄漏等)
3. 是否符合项目已有的代码风格

### 代码变更
<diff>
...
</diff>

### 输出格式
用表格列出发现的问题(严重→轻微),每行标注问题位置和修复建议。

案例 2:技术文档写作

你要为项目的 API 接口写一份说明文档。目标读者是前端开发。

接口:GET /api/users/{id}
参数:id (Long), includeDeleted (Boolean, 可选)
返回:User 对象

### 要求
- 标题使用动词短语(如"获取用户详情")
- 必须包含:接口说明、请求参数表格、返回字段表格、调用示例、常见错误码
- 每个字段的说明不超过一行,清晰描述含义
- 附一个 curl 示例

案例 3:Bug 分析

应用环境:Java 17, Spring Boot 3, MySQL 8.0
现象:用户量从 100 升到 5000 后,首页加载从 200ms 飙升到 8s

请分析可能的性能瓶颈,按可能性从高到低列出,每种可能性附带:
- 排查方法(具体 SQL 或命令)
- 对应的优化方案

案例 4:学习 & 概念解释

我想理解 "CAP 定理"。

请用两种方式解释:
1. 先给一句话定义(不超过 30 字)
2. 再用一个具体的系统设计场景说明三者之间的取舍

最后推荐 3 个关键延伸概念,帮助我建立完整的分布式系统理论基础。

八、核心原则总结

  1. 明确 > 模糊:越想得到精准回答,越要给出精准指令
  2. 结构 > 长篇大论:用分隔符、编号、缩进组织信息
  3. 示例 > 解释:当你要特定格式/风格时,给例子比描述更快
  4. 角色 > 泛泛而谈:赋予身份能显著提升专业性
  5. 迭代 > 一次到位:好的 Prompt 是改出来的,不是一次写成的
  6. 约束 > 开放:在正确的地方说"不",效果比说"要"更好

九、参考资源

论文

指南 & 文档

工具

  • Claude Code(/prompt 命令可按模板生成和迭代 Prompt)
  • Anthropic Console(可视化 Prompt 调试和对比)
  • LangSmith / PromptLayer(Prompt 版本管理和评估)

最后一条建议:把 Prompt Engineering 当作"与一位聪明但缺乏上下文的新同事沟通"。你说得越清楚、越有条理、越具体,对方的产出就越接近你的预期。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐