🧠 如何写出“高上下文提示词”让 AI 不再乱猜？以及提升AI Agent性能的8个提示技巧

🎯 为什么“上下文”这么重要？

AI 并不会主动发问。你不给，它就乱猜。

一个模糊的提示词，例如：

“Enable JSON parser for chat backend.” “为聊天后端启用 JSON 解析器。”

听起来简单，但 Agent 会：

• 修改错误的文件
• 漏掉关键类如 LLMOutputParsing
• 使用你根本没写的配置项

因为你没有告诉它：

• 要改哪个文件？
• 有没有参考例子？
• 用户的最终目标是什么？

🧭 编写高上下文提示词的 4 个关键要素

4 Keys to High-Context Prompting

1. 明确目标 | Clear Goals

• ❌ “Write tests for ImageProcessor.”
• ✅ “Write tests for ImageProcessor. Follow the style in text_processor.py.”
• ✅ “为 ImageProcessor 编写测试，参考 text_processor.py 中的写法。”

2. 提供上下文文件 | Provide Relevant Files

• 将你希望 Agent 处理的代码文件或类名附上
• 🧾 示例：image_processor.py, config.yaml

3. 给出示例 | Give Helpful Examples

• 举例说明“什么是好的答案”
• ✅ “参考下面这个函数结构进行实现”

4. 添加约束 | Add Constraints

• 告诉它必须/不能做什么
• ✅ “不要修改现有配置文件”、"只使用标准库"、"接口需向后兼容"

🛠️ 高上下文提示词模板（中英文）

以下是你可以直接套用的提示词结构：

🔧 任务描述 Task：
请为模块 X 添加 Y 功能。  
Add Y feature to module X.

📁 相关文件 Relevant Files：
- x_module.py
- config/settings.py

📌 示例 Example：
请参考 `z_module.py` 中的实现方式。  
Follow the pattern used in `z_module.py`.

🧩 约束 Constraints：
- 不要引入第三方库  
- 不要修改其他模块  
- 保持函数签名不变  
Do not add external libraries.  
Do not change unrelated modules.  
Keep the function signature unchanged.

💡 小贴士 Tips

• 不确定上下文？就多给一点。
• 有范例代码？千万别藏着。
• Agent 不需要“聪明”的提示词，它需要“完整”的提示词。

✨ 提示词增强工具推荐：Prompt Enhancer

为了解决提示词信息不足的问题，AugmentCode 团队开发了 Prompt Enhancer 插件，它能：

• 自动从代码库提取上下文
• 重写提示词
• 支持 VS Code 和 JetBrains

只需一键 ✨，写出更清晰的 prompt，提升你的开发效率！

✅ 总结

高上下文提示词 = 更准确的 AI 执行结果

记住下面这句话：

Agents don’t need perfect prompts. They need complete ones.

快试试看，把你平时写的 prompt 套进上述模板，看看效果是不是立竿见影！

好的，以下是对这篇文章《How to Prompt Your Agent: 8 Tips on Improving AI Agent Performance》的更详细、专业化的逐条总结，并配有示例说明和背景解析。总结将分为以下结构：

如何为AI Agent书写提示——提升AI Agent性能的8个技巧

✅ 什么是 Prompt Engineering？

Prompt 是供模型使用的输入集合，包含多个部分：

• System prompt（系统提示）
• Tool definitions（工具定义）
• Tool outputs（工具输出）
• User instructions（用户指令）
• 历史轮次的模型输出

Prompt Engineering 的核心是：通过优化提示各组成部分，提升模型完成任务的表现。

例如：

• 系统提示可以包含一般性指导，用以引导模型采取不同风格、行为或自主程度；
• 工具定义可以告诉模型哪些场景下该使用某工具；
• 工具输出可以指示模型错误状态；
• 用户指令可以在展示前重写（Meta-Prompting）；
• 历史输出可以压缩或截断以节省 token，但截断方式对质量有影响。

如何看待模型

模型是“人工智能”的。与其说是在编程，不如说是在和人对话。 模型对“世界”的理解完全来自 Prompt。你越是提供完整、一致的世界观，它的表现就越好。

模型接口是自然语言，不等同于传统编程语言。这种接口是一个抽象层，可以用来：

• 呈现正常结果；
• 报告错误；
• 通知状态变化；
• 一般性交流。

示例

如果模型调用了一个工具，但参数错误，不要抛出异常。 而应返回提示信息，如：“工具调用失败，缺少必要参数 xyz”，模型会理解并重试。

如何评估 Prompt？

靠“感觉”（Vibes）。 通常无法自动化评估 prompt 效果，除非是非常特定任务。

建议：

• 设计多种测试场景；
• 验证 prompt 更改是否会造成退化。

八大 Prompt 工程技巧

1️⃣ 优先提供上下文（Focus on Context First）

要点：

• 上下文 = 用户提供的信息 + 工具结果 + 系统设定。
• 模型擅长从冗长信息中筛选关键内容，所以宁可多给，不要少给。
• 好的上下文能极大提升模型判断力。

示例：

如果你提供一个很长的命令输出，默认可能截断后缀，但有用的信息（如报错的 stacktrace）可能就在后缀，因此应该截断中间部分而非结尾。

2️⃣ 呈现完整的世界观（Present a Complete Picture of the World）

要点：

• 明确告诉模型它“身处”怎样的环境。
• 包括角色定义、可用资源、行为期望。
• 这有助于模型建立稳定一致的内部认知。

示例 system prompt：

You are a software agent operating in a Unix environment. You have access to a filesystem, execution tools, and an IDE state API.

3️⃣ 提示之间保持一致性（Be Consistent Across Good Prompts）

要点：

• 不同组件（系统提示、工具定义、默认参数）要语义一致。
• AI很容易因矛盾而“误判”，尤其涉及路径、状态、默认值时。

示例：

如果 system prompt 说当前路径是 $CWD，那么工具定义中也应将参数 cwd 默认设为 $CWD。

4️⃣ 对齐用户视角（Align the Model with the User’s Perspective）

要点：

• 模型的“感知”应贴近用户当前状态（如IDE操作、时间、地点）。
• 有助于模型理解任务意图，更智能地回应用户。

示例：

在 IDE 中添加状态：

The user works in an IDE. The current IDE state:‍

The file foo.py is open.
The IDE is of type VSCode.

描述 IDE 状态的更详细系统提示示例：

The user works in an IDE. The current IDE state:

The IDE is of type VSCode.

The currently open file is foo.py.
Lines 134 through 179 are visible on the screen.
Here is the currently visible text, with the cursor location denoted by <CURSOR>:

134 def bar(): 135 print("hell<CURSOR>o") ... 179 # TODO implement this

There is no selected text.
There are 14 open tabs. Here they are from most recently to last recently visited:
foo.py
bar.py ...
xyz.py

⚠️ 提醒：这并不是说其中某个提示一定比另一个更好。详细提示的潜在缺点是模型可能会过于关注 IDE 状态，而这并不总是用户意图的最佳信号。所以这取决于你优化的目标是什么。

5️⃣ 详细无妨，详尽更好（Be Detailed）

要点：

• 模型不怕“信息冗余”，详尽说明任务更有助于完成。
• 当前上下文窗口足够大，冗长描述不是问题。

示例：

解释如何使用 graphite 工具时，把参数、限制、边界条件全部列清楚，模型反而表现更稳定。

### Be detailed

Models benefit from detailed prompts, and are unlikely to get confused even if there’s too much detail.

Do not worry about prompt length. Current context lengths are long and will keep increasing: You cannot make a dent in the prompt budget by writing longer prompts.

Example of a mostly successful and detailed prompt, that teaches the model how to use Graphite:

Using Graphite for version control

We use Graphite for version control on top of git. Graphite helps manage git branches and PRs. Graphite maintains stacks of PRs: changes to a PR automatically cause rebases on higher PRs in the stack, saving a lot manual effort. Each section below describes how to perform a common version control workflows using Graphite and GitHub. If the user asks you to perform such a workflow, follow these guidelines.

What NOT to do

Do not use git commit, git pull, or git push. These commands are all replaced by Graphite commands that start with gt, as described below.

Creating a PR (and branch)

In order to create a PR, do the following:

• Use git status to see which files were changed, and which files are new
• Use git add to stage the relevant files
• Use gt create USERNAME-BRANCHNAME -m PRDESCRIPTION to create the branch, where:

USERNAME can be obtained, see instructions elsewhere BRANCHNAME is a good name for the branch you come up with PRDESCRIPTION is a good description for the PR you come up with

• This may fail because of pre-commit issues. Sometimes pre-commit fixes the issues itself. Check git status to see if any files were modified.

If so, git add them. If not, fix the issues yourself and git add them. Then repeat the gt create command to try creating the PR again.

• Run gt submit to creae the PR on GitHub (if you're only creating the branch, skip this step).
• If gh is available, use it to set a PR description.

Note: Do not forget to add files before running gt create, or you will get stuck!

Updating a PR

In order to update a PR, do the following.

• Use git status to see which files were changed, and which files are new
• Use git add to stage the relevant files
• Use gt modify to commit the changes (no need to supply a message)
• This may fail because of pre-commit issues. Sometimes pre-commit fixes the issues itself. Check git status to see if any files were modified.

If so, git add them. If not, fix the issues yourself and git add them. Then repeat the gt create command to try creating the PR again.

• Use gt submit to push the changes
• If you also need to update the PR description, use gh (if it's not installed, tell the user but don't insist on updating the PR description)

Pulling changes from main

In order to synchronize your local repository with main, do the following.

• Use git status to make sure the working directory is clean
• Use gt sync to pull changes and rebase
• Follow the instructions. If there are conflicts, ask the user if they want to resolve them. If so, follow the instructions shown by gt sync.

Other Graphite commands

To find other commands, run gt --help.

---

### 6️⃣ **避免示例过拟合（Avoid Overfitting to Specific Examples）**

要点：

- 示例帮助模型理解，但也可能让模型“死记硬背”。
- 应多样化测试，并设置挑战场景来暴露模型是否过拟合。

建议：

- 尽量描述规则、流程，而非死板地写示例；
- 如果提供示例，确保它们能泛化或具有变体。

---

### 7️⃣ **处理工具调用的局限性（Consider Tool Calling Limitations）**

要点：

- 模型容易调用错误工具，参数缺失、格式错误等常见。
- 最好校验输入并**返回带错误信息的工具输出**，让模型自动修复。

示例：

{ "error": "Missing required parameter 'filename'. Please specify it to continue." }

- 模型会从此失败中恢复并尝试修复调用方式。

---

### 8️⃣ **注意提示缓存和强调竞争（Prompt Cache & Competing Emphases）**

要点：

🔄 Prompt Cache

- 模型会缓存提示（尤其是system prompt部分）；
- 如果中途状态变化（如时间），修改提示可能**失效整个缓存**；
- 更好的方式：通过**用户对话**告知新状态，而非修改system prompt。

🔊 Competing Emphases

- 重复强调（如“CRITICAL”）能提高权重；
- 但**强调越多，彼此之间效果越弱**；
- 建议只在真正重要信息上做强调，并使用位置技巧（放在开头或结尾）。

---

### 💡 补充建议与发现

- **条件判断需逐步逻辑展开**：不能只说“如果A则B”，要让模型自己写出逻辑步骤，提升推理成功率。
- **激发模型表现的小技巧**：
  - 唤起“共情”：例如告诉模型“你是我唯一的助手”；
  - 适度“威胁”：如“若你搞错，我可能会破产”；
- **提示设计是个系统工程**：涉及用户意图、模型认知、工具规范、状态一致性等多个维度。

---

🧠 核心一句话

> **Prompt 工程=与AI对话的艺术 × 系统设计思维 × 行为引导策略**

---