AI Agent软件开发的新原则

1. 永远使用最新、最强的模型

其他选择可能都是在浪费时间。

如果一个模型有 10% 的概率出错，问题在于你根本不知道它会在哪 10% 的情况下出错。结果就是，你不得不反复尝试，才能得到正确的结果。

你真的会愿意雇用一个便宜 50%、但能力却随机下降 20% 的通才吗？

现在还有谁在用 Opus 4.5？答案不言自明。

2. 别再过度担心 AI 生成的低质量代码（Slop）

有人会说：「AI 生成的代码会让你的代码库变成一团无法维护的垃圾。」

也许六个月前确实如此。但现在呢？

我并不确信 AI 还会持续制造那么多低质量代码。即使确实会产生一些，我也不认为这些代码就一定无法维护。

3. 告诉 Agent「要做什么」，而不是「怎么做」

描述你想实现的目标，而不是指导 Agent 具体应该如何实现。这样往往能获得更好的结果。

例如：

把这个字节码编译器和虚拟机优化到极致。不要停下来，直到性能提升到原来的两倍。

这是我希望最终实现的效果……

重点是明确最终目标和验收标准，而不是提前限定实现路径。

4. 让 Agent 看见软件开发的整个生命周期

是什么减少了 AI 的幻觉？

工具调用。

工具让 Agent 能够真正接触现实世界。

如果 Agent 看不到某个东西，它就可能凭空编造。

因此，你应该让 Agent 能够端到端地运行自己构建的系统，包括：

• 运行和测试自己编写的代码
• 读取生产环境日志
• 执行部署并观察上线过程
• 发布正式版本
• 开启或关闭功能开关
• 处理 Bug 报告
• 给客户发送邮件

任何你能够观察和操作的东西，都应该尽可能让 Agent 同样能够观察和操作。

5. 为 Agent 提供覆盖整个软件开发生命周期的工具

我们开发了一些自定义插件，让 Agent 可以直接完成软件开发过程中的各种操作，例如：

• 获取和处理 Bug 报告
• 向用户发送邮件
• 查询「我们的系统现在是否健康？」
• 管理和授权功能开关（Feature Flags）

Agent 不应该只拥有写代码的能力，而应该具备完成整个开发、交付和运维流程所需的工具。

6. 用实验评估 Agent 的知识体系是否真正有效

随着项目演进，代码仓库中会积累大量知识：

AGENTS.md文件、Skills、脚本、文档等。

但关键问题是：Agent 真的会使用这些知识吗？这些知识真的能提高 Agent 的表现吗？

可以启动五个彼此独立、不知道实验分组情况的 Agent，设置对照组和实验组，然后实际测试效果。

Agent 非常、非常擅长运行实验。

不要仅仅因为编写了文档或 Skill，就假设它一定有价值。应该通过实验验证。

7. 本地开发环境正在变得越来越别扭

每个 Agent 都应该能够自由安装和运行完成任务所需的任何工具、依赖和服务。

在远程机器上，这件事相对容易实现。

但在本地开发环境中，体验就很糟糕。

尤其是当你希望多个 Agent 同时进行端到端测试时，很难避免资源冲突。

8. 不要亲自陪 Agent 一轮轮试错，让它构建自动迭代的工具

不要再这样和 Agent 互动：

「我们先试试这个。」

「嗯，不太对，再试试那个。」

「还是不行，再改一下。」

更好的方式是：

「生成 20 种不同的方案，再做一个简单的页面，让我可以自由组合、比较和测试它们。」

这个原则不仅适用于寻找解决方案，也适用于探索问题本身。

例如：

「针对系统运行缓慢的问题，提出四种不同的原因假设，然后逐一验证。」

不要把 Agent 当作一个需要你不断指导的执行者，而要让它成为能够自主探索、实验和迭代的系统。

9. 要求 Agent 提供无可辩驳的证据

这是改变游戏规则最大的一点。

Agent 非常擅长生成能够证明结果的证据，例如：

• 端到端的操作演示
• 产品演示视频
• 优化前后的性能数据
• 可复现的测试结果

你需要逐步建立对 Agent 的信任，同时培养自己判断证据是否可靠的直觉。

甚至应该在AGENTS.md中明确写上：

「这不算证据。」

让 Agent 明白，不能仅仅声称「功能已经完成」「测试已经通过」，而必须拿出真正可验证的结果。

10. 不要让自己等待 Agent，要让 Agent 等待你

如果你还在纠结首个 Token 的响应时间，那你的工作方式可能出了问题。

应该主动拥抱异步工作模式。

给 Agent 更大、更有挑战性的任务，让它们独立推进。

把任务批量交给 Agent，而不是不断进行短促的来回对话。

理想的工作方式不是人等待 AI 完成下一步，而是 AI 完成工作后等待人的决策。

11. 自动化、定时任务、唤醒和心跳机制是杀手级功能

以前没有充分意识到这些功能有多重要，直到它们被关闭，才发现自己有多么离不开它们。

我现在几乎一直在使用。

例如：

「两个小时后检查一下日志。」

「等这个功能正式上线后通知我。」

「每天上午 9 点检查一次。」

Agent 不应该只在你打开对话框时才工作。

它应该能够在指定时间自动唤醒、检查状态，并在必要时主动联系你。

12. 不要再手动管理上下文

你花在思考「当前上下文到底用了 30 万还是 38 万 Token」上的每一分钟，都是浪费。

上下文压缩（Compaction）已经非常有效了。

不要再手动管理上下文。

只需要遵循一个原则：

一个对话线程（Thread）对应一个任务。

有些线程只有 46 条消息，有些线程则长达 3,714 条消息。

这并不重要。

重要的是让任务在同一个线程中持续推进，而不是被上下文管理问题打断。

13. 对话线程就是公司的知识记忆

在 Amp 中，你可以直接询问：

「我们当初为什么要这么设计？」

随着团队越来越多地使用 Amp，知识会不断积累，并产生复利效应。

尤其重要的是：对话线程能够与 Git Commit 关联起来。

这意味着你不只是知道「代码发生了什么变化」，还可以追溯：

• 当初为什么要做这个改动？
• 当时讨论过哪些方案？
• 为什么选择当前实现？
• 曾经发现过哪些问题？

这是一项改变游戏规则的能力。

它能够减少团队中的重复劳动，避免相同的问题被一遍遍研究和解决。

14. 不要让 Agent 写那些需要面向人类读者的内容

除了一些特殊场景，例如：

• 调试步骤
• 故障事件报告
• 某些技术文档

这些偏机械化、对文字的人性化表达要求没那么高的内容，可以交给 Agent。

但对于真正需要面向人类读者、需要考虑表达效果和沟通质量的内容，不应该完全交给 Agent 编写。

15. 只审查爆炸半径大的代码

整个系统中，真正需要我重点关注的核心文件不到五个。

这些文件，我会亲自审查。

数据库迁移脚本？会审查。

但以下这些细节，我已经不那么在意了：

• 使用闭包还是类（Closure vs. Class）
• 能否定义一个更优雅的类型
• 变量命名是否足够漂亮
• 是否存在一些重复代码

我现在关注的是：

它能正常工作吗？

我能否在架构图的层面理解它？

Agent 是否真正完成了端到端测试？

一个月之后，我还能轻松修改它吗？

如果这些问题的答案都是「是」，那我最多只是考虑一下是否还需要进一步审查代码。

核心思想

这 15 条原则背后，其实是软件开发范式的一次转变：

从「人指导 AI 写代码」，转向「人定义目标、Agent 自主执行并提供可验证的结果」。

传统开发关注的是：代码如何实现、实现是否优雅、人如何一步步推进任务。

Agent 驱动的开发更加关注：目标是否清晰、环境是否可观测、工具是否完整、结果能否验证，以及系统能否持续自主运行。

其中最值得关注的变化是：

开发者不再需要管理 Agent 的每一个动作，而是需要设计一个让 Agent 能够自主工作、自动验证、持续迭代的环境。

这意味着未来软件工程的重要能力，可能不再只是「如何写出好代码」，还包括「如何构建一个能够持续产出可靠软件的 Agent 工作系统」。