我是如何使用agents进行工作
引言
作者 Thorsten Ball 是来自德国的资深软件工程师，曾参与 Zed 和 Amp 的开发。想要精进自己的 Vibe Coding 技巧，站在巨人的肩膀上无疑是最好的学习方式之一。本文整理了作者分享的 15 条 Vibe Coding 实战技巧，希望能给大家带来一些启发。
正文
1. 告诉 AI「要做什么」，而不是「怎么做」
Prompt the What, not the How.
描述你想要实现的目标，而不是一步步告诉 AI 应该如何实现。
这样往往能得到更好的结果。
例如：
让字节码编译器和虚拟机尽可能快。不要停下来，直到性能提升到原来的两倍。
这是我希望它最终实现的运行效果……
核心思想是：明确目标，把实现方法交给 Agent 探索。
2. 让 Agent 看清整个软件开发生命周期
Make the whole SDLC legible to the agent.
是什么阻止了 AI 幻觉？
答案是：工具调用（Tool Calls）。
工具让 Agent 能够真正接触现实世界。
如果 Agent 看不到某样东西，它就可能凭空编造。
所以，应该让 Agent 能够：
- 端到端运行和测试自己构建的东西。
- 读取生产环境日志。
- 部署应用并观察发布过程。
- 正式发布软件。
- 开启或关闭功能开关（Feature Flags）。
- 排查用户提交的 Bug 报告。
- 给客户发送邮件。
任何你能够看到的信息，都应该尽可能让 Agent 也能看到。
3. 不要让自己等待 Agent，而要让 Agent 等待你
Don’t wait for your agents. Let them wait on you.
如果你总是在担心 TTFT（首个 Token 的响应时间），那么你的工作方式可能出了问题。
应该充分利用异步执行。
给 Agent 更大的任务，设定更有挑战性的目标。
尽量批量安排任务，而不是不断进行一问一答式的交流。
理想状态是：Agent 在持续工作，需要你决策时才来找你，而不是你一直盯着它的输出。
4. 要求 Agent 提供无可辩驳的证据
Ask for irrefutable proof.
这是改变我工作方式最大的一件事。
Agent 非常擅长生成能够证明工作成果的证据，例如：
- 完整的端到端操作演示。
- 功能演示视频。
- 优化前后的性能数据对比。
你需要逐渐建立对 Agent 的信任，同时培养判断证据是否可靠的直觉。
甚至可以直接在 AGENTS.md 中写入：
“这不算证据。”（This is not evidence.）
以此明确哪些内容不能被当作任务完成的有效证明。
5. 为 Agent 提供覆盖软件开发生命周期的工具
Give it tools for the SDLC.
我们开发了一些自定义插件，让 Agent 能够完成以下工作：
- 处理 Bug 报告。
- 给用户发送邮件。
- 检查系统是否健康运行。
- 为用户开启特定功能（Feature Flags）。
这些工具使 Agent 不再只是编写代码，而是能够真正参与整个开发与运营流程。
6. 不要和 Agent 一次次来回试错，让它自己构建试验工具
Don’t iterate with the agent. Let it build tools to iterate.
不要采用这样的工作方式：
我们先试试这个。
啊，不对，那再试试另一个。
相反，你应该这样要求：
生成 20 种不同的方案，再做一个简单的网页，让我可以自由组合、测试这些方案。
这种方式不仅适用于探索解决方案，也适用于分析问题本身。
例如：
提出四种可能导致系统运行缓慢的原因，然后逐一验证这四种假设。
不要让自己成为每一次试验的中间人，而要让 Agent 自动完成探索和验证。
7. 自动化、定时任务、唤醒和心跳机制是杀手级功能
Automation/schedules/wake-up/heartbeat are killer feature.
以前我没有意识到这些功能有多重要。
但当它们被关闭之后，我才发现自己有多么离不开它们。
我现在经常使用这些能力。
例如：
两小时后检查一次日志。
功能正式上线后通知我。
每天上午 9 点进行一次检查。
这些功能让 Agent 从一个需要手动调用的工具，变成一个能够持续跟进任务的助手。
8. 不要再手动管理上下文
Stop manually managing context.
你花在思考下面这些问题上的时间，基本都是浪费：
现在上下文已经使用了 30 万 Token，还是 38 万 Token？
上下文压缩（Compaction）已经表现得非常出色。
不要再手动管理它。
我的原则是：
一个对话线程（Thread）对应一个任务。
有些线程只有 46 条消息，有些则长达 3,714 条消息。
这都没有关系。
9. 对话线程就是公司的知识记忆
Threads are your company memory.
在 Amp 中，你可以问：
我们当初为什么要这么做？
团队使用 Amp 的人越多，积累的知识就越多，而且这些知识能够不断产生复利效应。
对话线程还会与 Git Commit 关联起来。
这是一个改变工作方式的功能。
它能够帮助团队避免重复劳动。
10. 不要让 Agent 替你写面向人类的内容
Don’t let agents write for humans.
有一些例外，例如：
- 调试步骤。
- 事故报告。
- 某些技术文档。
这些相对机械化的内容，对接收者是否为人类的考量没有那么高。
但对于真正面向人的沟通和表达，不应该完全交给 Agent。
11. 只审查影响范围大的代码
Review only code with high blast radius.
整个项目中，真正核心的文件通常不到五个。
这些文件，我会亲自审查。
数据库迁移？是的，我也会审查。
但对于下面这些问题，我已经不再那么关心了：
- 使用闭包还是类？
- 类型定义是否还能更优雅？
- 变量名是否足够好？
- 代码是否存在一些重复？
我现在更关心的是：
代码能正常运行吗？
我是否能从架构图和模块关系的层面理解它？
Agent 是否完成了端到端测试？
一个月之后，我还能轻松修改它吗？
如果这些问题的答案都是肯定的，那么我可能才会考虑是否需要进一步审查代码。
12. 使用最新、最强大的模型
Use the latest and greatest models.
其他所有选择都可能是在浪费时间。
假设一个模型有 10% 的概率出错，问题在于，你根本不知道它会在哪 10% 的情况下出错。因此，你最终不得不反复尝试。
你真的愿意雇用一个价格便宜 50%，但能力却会随机下降 20% 的通才吗？
现在还有谁在用 Opus 4.5？答案不言而喻。
13. 不要再担心 AI 会不断制造垃圾代码
Stop worrying about accumulating slop.
有人说：“AI 会把你的代码库变成一个无法维护的烂摊子。”
也许六个月前确实如此。
但现在呢？我并不认为 AI 一定会制造垃圾代码。
即使它确实产生了一些质量不高的代码，我也不认为最终的代码库就一定无法维护。
14. 验证 Agent 是否真的会使用积累的知识
Eval agentic knowledge.
随着项目发展，知识会不断积累在代码库中，例如：
AGENTS.md文件- Skills（技能）
- Scripts（脚本）
- Docs（文档）
但问题是：Agent 真的会使用这些知识吗？
可以通过实验验证。
启动五个彼此独立、不了解实验目的的 Agent，设置对照组和实验组，然后比较结果。
Agent 非常、非常擅长执行实验。
15. 现在，本地开发环境反而让人感觉很别扭
Local dev feels yucky now.
每个 Agent 都应该能够自行安装和运行完成任务所需的任何工具。
在远程机器上，这件事很容易实现。
但在本地开发环境中，就会变得很麻烦。
尤其是当你希望多个 Agent 同时执行端到端测试时，很难避免本地资源冲突。