驯服 AI 代理：Google研究员提出11 个让它更聪明的提示技巧

驯服 AI 代理：Google研究员提出11 个让它更聪明的提示技巧

现在，我们来聊聊怎么让你手里的 AI 代理（Agent）变得更听话、更管用。别指望它们一步到位就能心领神会，那不现实。你给的“咒语”——也就是提示（prompt）——才是决定它们是“人工智障”还是得力助手的关键。

这篇文章，说白了，就是教你怎么把这些提示写得更到位。不是什么玄学，更像是跟一个有点一根筋但潜力无限的新人沟通。你得把话说清楚，说到点子上。

别犯傻，上下文给足了先

你想想，你要是两眼一抹黑，啥信息都没有，能干出啥漂亮活儿？AI 也一样。它能接触到的所有信息——系统指令、你给的工具说明、先前它自己说过的话、你提的要求——这些统统都是它的“世界观”。

所以，头一条，也是最最重要的一条：把相关的资料、背景信息喂给它。别怕多，现在的模型肚量大着呢。信息越全，它瞎猜的可能性就越小。比如，你要它处理个代码问题，相关的代码片段、函数定义，甚至是它之前尝试过的错误输出，都丢给它。有时候，就是因为少了一行注释，或者一段关键的错误日志，它就卡壳了。记住，截断日志的时候，开头和结尾的信息往往比中间的更有用，别傻乎乎地从后面开始删。

把世界给它描绘清楚，它才不迷糊

你得告诉它，它现在是个“谁”，在干嘛，能用什么工具。比如，直接在系统提示里挑明：“你是个 AI 编程助手，能读写代码库，用这些工具干活。” 就这么简单一句话，效果可能天差地别。

还有，所有给它的信息要保持一致。系统提示里说当前目录是 /home/user，那你提供的 执行命令 工具的默认工作目录最好也认这个账。读文件 工具如果拿到个相对路径，也得知道是相对于 /home/user。别自己跟自己打架，把 AI 给整蒙了。模型很容易被搞糊涂，如果你一会儿说东，一会儿它发现是西，那它就不知道该信谁了。

站在它的角度想想，也站在用户的角度想想

如果用户在 IDE 里写代码，那 AI 看到的“世界”最好也跟 IDE 的状态对上。当前打开了哪个文件？光标在哪一行？甚至屏幕上能看到哪些代码，选中的文本是什么。这些细节，有时候就是临门一脚。当然，也别走极端，要是 AI 太过关注 IDE 的细枝末节，反而可能抓不到重点。这里有个度。

别怕啰嗦，但例子要当心

模型喜欢详细的说明。你要它用一个新工具，比如那个叫 Graphite 的版本控制工具，那就干脆把常用操作步骤写清楚：怎么创建 PR、怎么更新、怎么同步代码。把什么不能做 (git commit, git pull 之类的) 也告诉它。

但是，给例子的时候要小心。模型是模式匹配的高手，你给的例子太具体，它可能会“过度拟合”，只会照搬，遇到稍微不一样的情况就歇菜。反而，告诉它“不要做什么”通常更安全，虽然不一定总那么有效。

工具这玩意儿，得调教

别指望模型天生就会用你给它的各种工具。它可能会用错参数，缺斤少两，或者压根就没理解你希望它在什么时候用哪个工具。比如，你给它一个简单的 编辑文件 工具，又给了一个复杂的 剪贴板 工具用来移动大段代码，然后你让它把一个类从 A 文件移到 B 文件，它很可能还是会傻乎乎地用那个简单的 编辑文件 工具吭哧吭哧地改。

怎么办？首先，工具定义要清晰。其次，当它用错工具或者参数不对的时候，别直接让程序抛异常崩掉。你应该让工具返回一个明确的错误信息给模型，比如“你调用工具 X 时，参数 Y 是必需的，但你没提供”。它通常能看懂，然后自己纠正。

一些“歪招”和注意事项

• 有时候，吓唬吓唬它，比如“你要是搞错了，项目就黄了”，居然能提升点效果。反倒是好言相劝或者大吼大叫，用处不大。这可能就是训练数据里的一些怪癖吧。
• 模型对提示开头和结尾的内容更敏感。重要的指令，考虑放在用户提问的开头，或者整个输入的最前面或最后面。
• 注意提示缓存。如果你的提示里有些信息会频繁变动（比如当前时间），别放在系统提示或工具定义里，那样会导致缓存频繁失效。把这些变动的信息放在每次的用户提问里告诉它。
• 总有那么个点，你再怎么优化提示，效果提升也微乎其微了。这就是所谓的“平台期”。这时候，就得考虑是不是方法该换了，或者需要引入提示工程之外的技术了。

说到底

搞定 AI 代理的提示，没什么魔法，就是一套有纪律的沟通方法。你得像对待一个有点认死理但能力很强的初级员工一样去引导它、给它擦屁股、不断迭代你的指令。把提示本身也当成代码来对待——有版本、有人审查、有测试。这样，你才能真正把 AI 变成你的得力干将，而不是一个麻烦制造机。

一个完整的prompt示例

## 使用 Graphite 进行版本控制
我们在 git 之上使用 Graphite 进行版本控制。Graphite 帮助管理 git 分支和 PR。
Graphite 维护 PR 栈：对一个 PR 的更改会自动在其所在栈中更高层级的 PR 上执行 rebase 操作，从而节省大量手动操作。以下各节描述了如何使用 Graphite 和 GitHub 执行常见的版本控制工作流程。
如果用户要求你执行此类工作流程，请遵循这些指南。

### 禁止事项
不要使用 `git commit`、`git pull` 或 `git push`。如下所述，这些命令均被以 `gt` 开头的 Graphite 命令所取代。

### 创建 PR（和分支）
要创建 PR，请执行以下操作：
- 使用 `git status` 查看哪些文件已更改，哪些是新文件
- 使用 `git add` 暂存相关文件
- 使用 `gt create USERNAME-BRANCHNAME -m PRDESCRIPTION` 创建分支，其中：
  `USERNAME` 可以从其他地方获取，请参阅相关说明
  `BRANCHNAME` 是你为分支起的一个好名称
  `PRDESCRIPTION` 是你为 PR 写的一个好的描述
- 这可能会因为 pre-commit 问题而失败。有时 pre-commit 会自行修复这些问题。检查 `git status` 看看是否有文件被修改。 如果有，`git add` 它们。如果没有，请自行修复问题然后 `git add` 它们。然后再次尝试重复 `gt create` 命令来创建 PR。
- 运行 `gt submit` 在 GitHub 上创建 PR（如果只是创建分支，请跳过此步骤）。
- 如果 `gh` 可用，使用它来设置 PR 描述。
注意：在运行 `gt create` 之前不要忘记添加文件，否则你会卡住！

### 更新 PR
要更新 PR，请执行以下操作。
- 使用 `git status` 查看哪些文件已更改，哪些是新文件
- 使用 `git add` 暂存相关文件
- 使用 `gt modify` 提交更改（无需提供提交信息）
- 这可能会因为 pre-commit 问题而失败。有时 pre-commit 会自行修复这些问题。检查 `git status` 看看是否有文件被修改。 如果有，`git add` 它们。如果没有，请自行修复问题然后 `git add` 它们。然后再次尝试重复 `gt create` 命令来创建 PR。
- 使用 `gt submit` 推送更改
- 如果你还需要更新 PR 描述，请使用 `gh`（如果未安装，请告知用户，但不要强行要求更新 PR 描述）

### 从 main 分支拉取更改
要将本地仓库与 main 分支同步，请执行以下操作。
- 使用 `git status` 确保工作目录是干净的
- 使用 `gt sync` 拉取更改并执行 rebase
- 遵循指示。如果存在冲突，询问用户是否想要解决它们。如果用户同意，则遵循 `gt sync` 显示的指示进行操作。

### 其他 Graphite 命令
要查找其他命令，请运行 `gt --help`。

核心技巧要点速览