\n\nClickHouse CTO 总结了一年来团队应用 AI 智能体编程的实战经验与适用场景（如修复测试、代码审查），并提出七大实用建议，强调 AI 是辅助思考的工具。
译自：What ClickHouse learned from a year of coding with AI agents
作者：Alexey Milovidov
有人会告诉你，智能体将抢走我们所有的工作。另一些人则坚持认为它们毫无用处。许多公司的领导层强制要求“使用 AI”，却不解释这具体意味着什么，让工程师们感到困惑。
我们在 ClickHouse 使用编程智能体。它们确实有效。但它们并非万能，而且在 2025 年期间，“使用智能体”和“别费劲了”之间的界限移动了好几次。以下是我们的最终结论以及我们是如何得出这一结论的。
AI 辅助编程的三个级别
将这个领域划分为三个级别会有所帮助。
级别 1：从聊天窗口复制粘贴。 你在浏览器标签页中向模型提出问题，然后将代码片段粘贴到编辑器中。自 2023 年以来，许多工程师一直在这样做。它对于探索仍有用处。但与智能体相比，它已经过时了。
级别 2：命令行（CLI）或集成开发环境（IDE）中的智能体。 智能体读取你的代码库、运行命令、编辑文件、构建、测试并提交。对于困难的任务，你需要引导它；而对于常规任务，则让它自行运行。这是我们大部分日常工作发生的地方。
级别 3：隔离环境中的自主智能体。 反馈循环中的多个智能体、规范驱动的开发以及编排的多智能体设置。我们在生产环境中有几个例子，但工具链仍在成熟中，长时间自主循环产生的结果可能是不确定的。
如果你在六个月前尝试过智能体，但它在你的代码库上失败了，你可能会得出“智能体只是玩具”的结论。在当时，这个结论是合理的。但在现在，它已不再合理。
是什么改变了我们的看法
在 2025 年的大部分时间里，我都对在 ClickHouse C++ 主代码库上使用智能体持怀疑态度。早期的 Claude Code（2025 年 2 月）在编写 JavaScript 样板代码和一次性 Python 脚本时很有用。但在我们的 C++ 代码中，它迷失了方向。甚至在 2025 年 10 月的工程团队线下聚会上，大约有一半的团队成员从未认真使用过智能体。当时有一些零星的成功，但没有系统性的胜利。
“自 Opus 4.5 以来，智能体已经可以用于大型 C++ 代码库的日常工作。2025 年是工具之年。2026 年应该是生产力提升之年。”
随着 2025 年 11 月 Claude Opus 4.5 的发布，情况发生了改变。我开始给它分配一些小型的、规格描述过于详细的 C++ 任务。接着是根据 CI 日志进行 Bug 调查。然后是开发一些小功能。每次它都超出了我的预期。自 Opus 4.5 以来，智能体已经可以用于大型 C++ 代码库的日常工作。2025 年是工具之年。2026 年应该是生产力提升之年。
智能体目前在哪些场景对我们有效
以下是目前价值已经非常明确的几个场景：
样板代码和集成。 重复性的构建系统修改、跨多个文件的配置编辑、繁琐的 JDK 安装步骤、Kubernetes 配置清单。在这类工作上，智能体犯的错误比人类少，而且它们不会感到厌倦。对于任何刚开始尝试的团队来说，这都是一个切入的合适场景。
合并冲突。 在几乎 100% 的情况下，智能体解决合并冲突的效果都比人类好。“智能体操作，你来审查”的模式比你自己亲自敲代码产生的代码质量更高，因为审查自己刚刚写完的代码，要比审查别人（或别的东西）写好的代码困难得多。
代码审查。 我们尝试过集成 GitHub Copilot、Cursor 的 bugbot 等工具。最终，我们自己编写了一个机器人，通过脚本调用 Copilot CLI，并配上我们自己的审查指令。其质量至今仍让我感到惊讶。现在，人类审查者专注于架构；而机器人负责捕获资源泄漏、竞争条件和边缘情况。
修复不稳定性测试（Flaky Tests）。 ClickHouse 的 CI 每天在约 600 次提交和 300 个拉取请求（PR）中运行 2000 万到 8000 万个测试。我们从不屏蔽不稳定性测试，也不重新尝试它们，因此每次失败都必须进行调查。多年来，我们一直应接不暇。在 2026 年 1 月和 2 月，在智能体的帮助下，我提交了大约 700 个修复测试和 CI 基础设施的拉取请求。我们的不稳定性测试问题从每天大约 200 个减少到每 1000 万次测试运行中仅有 3 到 5 个。现在，我们还有两个自主智能体负责提交 PR 并寻找边缘用例。仅这一个用例就足以证明所有的投入都是值得的。
调查 Bug。 智能体擅长阅读日志、提出假设，并在受到提示时提出反驳。但它们也擅长产生“看似合理但实际错误”的假设，这就是危险所在。结果很大程度上取决于工程师的判断：经验丰富的 SRE 能更快地找到正确答案，而经验不足的同事可能会跟着一个听起来很自信的错误线索走。一个曾挫败了人类三次尝试的棘手并发 Bug，最终在经过大约一小时的推理后，被 Opus 4.6 用一行代码的改动修复了，并附带了完整的解释和测试。
建议
如果你想从这一年的经历中获得一条实用的收获，请收下这七条。
- 将 AI 视为思考的工具，而不是思考的替代品。 它是你编辑器的延伸，而不是你工程判断力的延伸。
- 它是一个放大器。 优秀的工程师在使用智能体时会变得更敏锐，而较弱的工程师则可能会造成更多破坏。理解问题没有任何捷径可走。
- 从小处着手，逐渐提高期望。 从样板代码、合并冲突和重复性重构开始。当这些进展顺利时，再推向更难的任务。直接跳到大型复杂任务的怀疑论者只会进一步证实他们的怀疑。
- 时刻进行验证。 更多的测试、更多的测试方法、更多的模糊测试、更多的随机化。智能体辅助工作的提升空间在于你的 CI，而不是提示词（Prompt）中。
- 使用最新模型，并至少准备两个服务商备用。 模型服务商会遇到停机，有时甚至是每天发生。在 Claude Code、Codex CLI 和其他工具之间灵活切换。
- 将指南保存到 CLAUDE.md 或 AGENTS.md 中，但要保持简短。 冗长的指令文件会被忽略。避免告诉模型不要做什么，因为这往往会产生与你预期相反的效果。
- 要具体。 智能体更青睐完整的规范。具体说明哪些文件、哪些函数以及采用哪种方法，比模糊的提示词能获得更好的效果，并且在此过程中还能保留你的工程技能。
“将 AI 视为思考的工具，而不是思考的替代品。”
下一步计划
我们仍处于早期阶段。除了 CLI 智能体之外，我们正在部署用于初步分类 Bug 报告、自动回滚不良更改、对新功能进行智能体化测试以及对问题工作负载进行持续分析的智能体。级别 3（真正的自主编程循环）是今年的工作重点。
在 2025 年，对智能体化编程持怀疑态度是合理的。现在不再合理了。模型能力足够，工具已经成熟，而在善用智能体的团队与不善用智能体的团队之间，生产力差距正在拉大。如果你是一位不怕 AI 的优秀工程师，现在正是予以关注的好时机。工智能
