Thorsten Ball 整理了自己与 Agent 协作的 15 条经验：怎样交代任务、怎样判断工作完成，以及哪些代码还值得亲自审查。下面是《How I work with Agents》的完整翻译。
用最新、最强的模型。 用其他模型，都可能是在浪费时间。如果一个模型有 10% 的时候会出错，你并不知道是哪 10%，最后就得反复尝试。一个通才便宜 50%，但会随机笨上 20%，你什么时候真想雇这样的人？现在还有谁在用 Opus 4.5？对，就是这个意思。
别再担心垃圾代码越积越多。 “它会把你的代码库搞得一团糟，根本没法维护。”六个月前也许是这样。现在呢？我不太相信它会制造那么多垃圾代码。即使会，我也不觉得结果就无法维护了。
提示词写清要什么，而不是怎么做。 描述你想要的结果，而不是你会怎样实现，往往能得到更好的结果。“把字节码编译器和虚拟机优化到你能做到的最快速度。速度没提升到两倍，就不要停。”“最终应该这样工作。”
让 Agent 看懂整个软件开发生命周期。 是什么抑制了幻觉？工具调用。它让 Agent 能够接触我们的现实世界。Agent 看不到的东西，就会自己编。所以，让它从头到尾运行自己构建的东西，让它读取生产日志、部署、观察上线过程、发布版本、切换功能开关、分诊缺陷报告，以及给客户发邮件。你能看到的，Agent 也应该能看到。
给它覆盖软件开发生命周期的工具。 我们有自定义插件，用来处理缺陷报告、给用户发邮件、回答“我们的系统健康吗？”，以及为用户开放功能开关。
评估 Agent 到底用没用上这些知识。 知识不断堆进代码库：AGENTS.md、技能、脚本、文档。但 Agent 真会用它们吗？启动五个不知实验分组信息的 Agent，分成对照组和实验组，试试就知道了。Agent 真的非常擅长做实验。
本地开发现在让我有点难受。 每个 Agent 都应该能安装和运行完成任务所需的一切。在远程机器上很容易，本地开发就很别扭。当你想让多个 Agent 做端到端测试时，本地很难不发生资源冲突。
别跟着 Agent 一轮轮试，让它先造出迭代工具。 不要“我们试试这个……啊，不行，再试试那个”。换成：“生成 20 个变体，再做个小页面，让我能组合、测试它们。”这不只适用于寻找解决方案，也适用于查明问题：“提出四种解释，说明为什么它这么慢，然后把四种都验证一遍。”
要求无可辩驳的证据。 这是变化最大的一点。Agent 非常擅长拿出证据：端到端的操作演示、演示视频、前后对比数据。你得逐渐建立起对这件事的信任和直觉。在 AGENTS.md 里写上：“这不算证据。”
别等 Agent，让它等你。 如果你还在担心首个 token 的响应时间（TTFT），你大概哪里做错了。多用异步。给它更大的任务，胆子再大一点。把事情打包交给它，而不是不断来回对话。
自动化、定时任务、唤醒和心跳机制是杀手级功能。 以前没意识到，等到用不了的时候，才发现自己多么离不开它。我一直在用：“两小时后检查日志。”“上线了告诉我。”“每天九点检查一次。”
别再手动管理上下文。 每次琢磨“它用了 30 万还是 38 万个 token”，都是在浪费时间。上下文压缩已经好用得惊人。不必手动管理上下文。一条会话对应一个任务。有的会话有 46 条消息，有的有 3,714 条。
会话就是公司的记忆。 在 Amp 里，你可以问：“我们当时为什么这么做？”团队越多人使用 Amp，知识就越能不断积累。会话和 Git 提交关联起来，这带来了巨大变化，也避免了重复劳动。
别让 Agent 写给人看的文字。 例外是：调试步骤、事故报告和一部分文档。也就是那些偏机械的内容，接收它的人是谁，没有那么重要。
只审查影响范围大的代码。 核心文件不到五个，我会审查。数据库迁移，也会。用闭包还是类、类型能不能更漂亮、变量名，甚至重复代码，我已经不太在意了。能用吗？我能在“画出框图和箭头”这个层面理解它吗？Agent 做过端到端测试吗？一个月后我还能改吗？如果都能，我也许会看一眼代码。
参考链接
-
原文：https://x.com/thorstenball/status/2114386050638336082