本文翻译自 Thorsten Ball 的文章：Amp is now available. Here’s how I use it.（2025年5月15日）
从今天开始，Amp——我们的前沿编程代理——向所有人开放了。等待列表已经取消，快去注册使用吧！
过去 10 周，Amp 一直是我开发软件的主要工具。正如我们使用的工具最终会改变我们一样，它从根本上改变了我开发软件的方式。
所以我想借此机会写下我个人是如何使用 Amp 的。
在 VS Code 中使用(In VS Code)
你可以在 Visual Studio Code 中将 Amp 作为扩展使用，也可以作为 CLI 使用。我主要在 VS Code 中使用它，始终在右侧边栏打开，不断地按 ⌘I 和 ⌘L。
如果四个月前有人告诉我，我会把 VS Code 作为主力编辑器，我是不会相信的。但现在就是这样。我唯一的解释是：我用哪个文本编辑器对我来说已经不那么重要了。虽然没有确切的数字，但我估计现在我提交的代码中有 70-80% 是 Amp 写的。
没错——我几乎不再手写代码了。如果我敲代码，那都算是稀罕事。
涂色式编程(Paint-by-numbers programming)
我把用代理编程想象成涂色式编程：我画出数字和线条，代理就去填上颜色。
代理不会为我做架构决策，不会在没有密切监督的情况下编写关键代码，不会给代码库引入全新的结构。这些是我做的事。但一旦我知道应该是什么样子，我就把我知道的一切 - “架构、可能的边界情况、约束条件、要添加和扩展和运行哪些测试”，都放进提示词中，然后让代理去执行。
保持小型 Thread
一般来说——我很快会给你一些例外情况——我会尽量保持 thread（与模型的对话）简短。
目前，我们底层使用的模型是 Claude Sonnet 4。对于 Claude 3.7 Sonnet（我们之前使用的），我预计 Claude Sonnet 4 也是如此，当上下文窗口达到 100k tokens 后，事情开始变得模糊、不精确。当上下文窗口太大时，Claude 会开始忘记第一个提示词中的指令，或者进入科学家们所说的"死循环"——就是它一遍又一遍地尝试修复同一个测试，却没什么成功。
有时我只是让它从暂存的代码中删除调试语句。其他时候我想让它实现一个我知道不会涉及太多文件的小功能，比如给这个网站添加 RSS feed。或者我想让它简化单个 UI 组件的设计。
再次强调，一般来说，我认为很多刚开始使用代理的人遇到的问题，都可以追溯到他们没有足够频繁地开启新 thread。
添加新功能
这可能是最经典的用例：让代理实现新功能，或修改现有功能。
过去几周有人多次问我：现在有了代理，你觉得我们是不是不需要再学习软件开发了？
我说，不，不是的，当我为代理写提示词时，我关于软件开发的所有知识都汇聚在一起：我对架构的思考、我怀疑陷阱在哪里、我知道相关代码在哪里、我认为重构应该如何进行、什么是好的测试、什么是必要的权衡、如何呈现给用户。
我不会写这样的提示词：
Build a batch tool into the agent而是这样的：
I need your help implementing this: https://raw.githubusercontent.com/anthropics/anthropic-cookbook/refs/heads/main/tool_use/parallel_tools_claude_3_7_sonnet.ipynb
We have tools defined in core/src/tools/tools.ts (and the other files) and now I want to implement this batch tool. I imagine that it'll be a bit tricky to figure out the types, so I want you to deeply think about that and find a practical solution that doesn't lead to a lot of complicated types. We should start really simple and then evolve what we have.或者这样：
A user ran into this bug that you see in the screenshot. The problem seems to be in core/src/threads/thread-worker.ts and core/src/inference/backends/anthropic.ts
It looks like we need to make sure that we don't send thinking blocks along when we error.
I know that we already have some logic for thinking blocks, but I want you to analyze how we handle thinking blocks so far.然后我跟进：
What's our current logic for removing thinking blocks? Don't we remove them somewhere in core/src/threads/thread-worker.ts or core/src/threads/thread-delta.ts ?最后，我说：
Okay, make that change!让它截图！
这是我使用代理时最喜欢的事情之一：给它们关于工作的视觉反馈。而且，你猜怎么着，当你只是给它们一个要打开的 URL 时，它们可以自己截图。
在我们的 Amp 代码库中，我们有一个用于 UI 组件的 storybook。我总是让它运行在 http://localhost:7001，当我打开那个 URL 时，我可以看到我们的大部分组件整齐地排列着，以它们可能处于的不同状态呈现。
所以如果我想让代理改变一个 UI 组件，我会告诉它去看 storybook —— 一旦你在设置中添加了 Playwright MCP 服务器，它就可以做到——并通过截图检查它的工作。
让我给你举个例子。几天前，我想让代理更新我们 storybook 中的一个现有 story。这是我的提示词：
提交后，代理去修改了 storybook 以包含这些更改。以下是它如何确认所做的更改有效：
“文件更改现在正确显示了！“它在截图后惊呼 —— 活在这个时代真是太棒了，对吧？
但还有更好的。我认为当代理所做的更改没有生效时，截图作为反馈效果特别好。因为在截图上，或者在浏览器的控制台中，它会看到错误并再次尝试，直到成功。试试看，这很神奇。
运行构建并修复错误
有时我的提示词就这么简单：
Run the build and fix all the errors由于"构建"是什么在 AGENTS.md 中有记录，代理就会运行命令然后修复错误。
审查代码
我经常让代理做以下事情：
Run `git diff` to see the code someone else wrote. Review it thoroughly and give me a report当然，那个"别人"不是别人 ——鼓声响起—— 正是代理自己！但它不知道，对吧？所以它去运行 git diff 并说代码看起来不错，或者很干净，或者有一些 bug。如果有，我会在考虑分析是否正确后让它修复其中一个 bug。
清理代码
假设我让代理写了数百行代码，在中间我让它添加一些调试语句，这样我们就能弄清楚为什么它不能完全按我们想要的方式工作。
我通常不知道它在哪里添加了这些调试语句，而且我没有打开任何文件。所以一旦我知道功能可以工作并且准备提交时，我会打开一个新 thread，让另一个代理实例删除调试语句：
Run `git diff` to see what has been changed then remove the debug statements粘贴截图
我确实喜欢截图，Amp 也是：
没错：你可以使用 ⌘-v/ctrl-v 粘贴截图，代理会"读取"它们。
我经常使用这个功能，粘贴过有人报告 bug 的 Slack 消息截图、我无法整齐复制粘贴的错误消息（或者我懒得复制）、UI 中的 bug。
它对文本效果最好，因为这些模型真的很擅长"读取"截图中的文本，但我之前也让代理"翻转这个截图中标记的两个按钮”，它也搞定了。
无论如何：这很有趣。
用图表解释代码
Amp 内置支持 Mermaid 图表。当你想弄清楚某些代码是如何工作的时候，这非常方便。
我是说，来看看这个：
只需要这个提示词：
Walk me through the code in this branch (compared to `main`) and explain to me how the autocompletions are hooked up into vscode and basically walk me through the lifecycle of an autocompletion via the code措辞不是很优雅，对吧？而且我甚至没有说它应该创建图表，但在这种情况下它神奇地做到了。（在其他情况下，当我知道我想要什么时，我会特别告诉它使用图表。）
阅读提交
单个 git commit 包含大量元信息：谁做的更改、他们如何描述更改、哪些文件一起更改、文件的路径、部分文件中的内容。
Fred Brooks 在《人月神话》中写道：
“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”
现在我要说：给我看一个 commit，我就知道足够多的信息来构建类似的东西。
我经常利用原始 commit 包含如此多信息的事实，通过简单地让代理在做任何事情之前查看特定的 commit，将相关上下文注入提示词。
这是一个例子：
This test web/src/lib/components/thread/thread-sharing-dropdown-menu.test.ts has recently been broken by this commit: 3ec95344d5d5a55ab2342d5daa53f3c3155391dd
Run
pnpm -C web test --run thread-sharing
to see the test fail.
Then examine the commit.
Then tell us how to fix the test或者我让代理为我找到一个 commit 然后阅读它：
Look at the git history of core/src/tools/builtin/filesystem/edit_file.common.ts
At some point I removed the vscode implementation in that file.
Find that vscode implementation and explain to me how we did file reloading after edit in it.之后，我们就有了进行实现更改所需的所有相关上下文。
搜索代码
有时我只是想找出某些代码在我们代码库中的位置，而不想让代理改变任何东西。
在这种情况下，我只是告诉它：
Find the code that ensures unauthenticated users can view the /how-to-build-an-agent page too或者，这是几周前的：
Where in the codebase do we define the database default so that new users have 0 invites? I think it's a database migration or something. You need to look in `server`我知道我可以想出一些关键词来搜索，但代理通常更快。而且如果我想改变什么，你猜怎么着？一切都已经在上下文中了。
与同事分享 Thread
能够与同事或公众分享 thread 是非常方便的。
当然是为了知识共享，或者解释你和你的代理是如何构建某些东西的，但也可以，你知道的，当代理第一次就做对时炫耀一下。我是说，看看这个：
告诉它我想要什么
当人们在使用代理时遇到困难时，问题通常可以归结为：
我以为代理会这样做，但它没有，为什么？
好吧，无论多么令人印象深刻，代理并不是无所不知的。它们可能对世界略知一二，但如果你不告诉它们，它们就不知道你想要什么。
所以与其想"我希望代理会使用 super-build --dry-run 命令，但它没有”，不如直接告诉它！
与其模糊地说：
Can you figure out who wrote this component?不如告诉它你想让它做什么：
Use git blame to tell me who wrote this component构建一个然后扔掉
有了代理，现在构建一个然后扔掉变得更加可行（或者至少：不那么痛苦）。不再有沉没成本的感觉告诉你"但实际上没那么糟，对吧？我们真的应该把它全部扔掉吗？"
相反，你可以让代理实现它，等五分钟，看看代码，然后决定保留还是扔掉。
我已经这样做过很多次了。很多时候我学到的最重要的事情是我不想如何构建这个功能。或者我了解到我根本不知道我想要什么。
使用 git 暂存区
我不认为在过去 10 年里我像过去 10 周那样频繁地使用 git 暂存区。事实证明它非常方便。谁会想到呢？
但为什么？
我们不采用检查点和应用/拒绝(apply/reject)模式来与代理交互（我们不认为这仍然是正确的方法），而是让代理做它的事情。安全网始终是版本控制——这是我们永远不想搞乱的安全网。
这反过来意味着你可以尽可能地利用 git 让代理做某事，看到它很好，暂存它，然后要求别的东西，看到它不好，然后清除未暂存的更改。
编写 SQL
拥有一个连接到你数据库的代理，非常非常接近你在它截图并迭代 UI 组件时感受到的喜悦。
以下是如何做到的。
首先，告诉代理使用 psql（或任何其他 CLI 工具）或 postgres MCP 服务器（或你数据库的任何其他 MCP 服务器）提供的工具连接到你的数据库。
然后，问它这样的事情：
Update my user account (email starts with thorsten) to have unlimited invites或者：
Return me a list of users with the most number of threads, sorted by number of threads代理会尽其所能返回那个列表：弄清楚数据库的模式，尝试这个查询，尝试那个查询。
看，这里我想改变我的本地开发数据库。它不知道模式是什么，所以它首先尝试弄清楚，它做到了——通过并行运行四个命令：
太棒了。
这是一种不同的、仍然陌生的编码方式
让代理做这个，让代理做那个，这里截图，那里截图，几乎不打字 —— 是的，听起来确实很奇怪，不是吗？
作为一个穿过印有文本编辑器 logo T 恤的人，让我来说：像这样编程感觉很奇怪。
Quinn 和我在播客的几乎每一集都谈到了这种感觉。我们都编程很长时间了，现在我们正在重新学习如何通过代理来做这件事，这感觉就是很奇怪。
因为它确实很奇怪。它是新的。需要一些时间来适应。你需要学习如何做。我打赌至少在接下来的六到十二个月里，你仍然需要学习如何很好地提示(prompt)。
但这是另一个赌注：一旦你看到代理做了你认为还不可能的事情，那就是它从"我不确定我是否喜欢这个……“转变为"好吧，哇，我还能用这个做什么，我打赌它也可以 “的时候。
那就是它从陌生转变为令人振奋的时候。
那就是你意识到，当用代理编程时，引用 Mary Rose Cook 的话，“每一步都比一步大。你离开地面。它需要更多的预先思考，但是，因为你每一步都取得更多进展，它感觉像在飞翔。”