仅使用Agents编写代码的六个月

# 完全使用智能体编写代码的六个月 来源：https://blog.exe.dev/engineering-with-ai 今年二月，我给自己定了一条规矩：不再手动写代码。我已严格遵守这条规则六个月了。 ## 系统全在我脑中 早在 2024 年，AI 尚未普及时，我的核心能力在于透彻理解整个系统架构，尤其是不同组件间的接口逻辑。若有人提出想构建某功能或修复某缺陷，我通常能直接指出关键代码行，并说明需要修改之处。我还记得那些看似怪异的设计决策背后的缘由，以及那些从未被记录下来的假设。这是我历经数月乃至数年深入代码库积累的知识——来之不易，却价值连城。它让我能快速且（更重要的）安全地构建功能。代价是我必须持续跟进所有变动：随着贡献者增多，我花费大量时间阅读变更以维持心智模型。更大的代价在于打字：每当我想构建某功能，脑中已浮现代码，但手指总是跟不上思维速度。 打字速度只是问题的一部分——一个功能很少只涉及单次编辑。即便是小改动也可能跨越多个层级，涉及处理器、数据结构、测试和文档。而这些编辑的风险并不均等：错误的处理器可以回滚，但错误的迁移操作可能留下难以清理的烂摊子。因此，手动编码意味着必须谨慎地将每个决策贯穿到所有相关位置。 Copilot 自动补全立即带来了帮助：文档注释能快速生成初稿（虽常出错，但总比面对空白文件强）。Cursor 的 Tab 补全功能效果更显著。模型能力显然在飞速提升。Claude Code 的改变尤为突出——我只需描述一次需求，智能体就能批量编辑多个文件，大幅减少了打字量。 但“少打字”不等于“少工作”：我仍然仔细审阅模型生成的每处改动，确保其符合我心中的预期状态。智能体仍会频繁出错或进行不必要的修改。增量式开发能帮助它们保持正确方向，这意味着我仍需手动调整部分生成代码——毕竟每行合并的代码都需由我负责，模型不会承担责任。 今年初，模型能力突然突飞猛进。GPT-5.3 和 Opus 4.6 能以更少的引导处理更复杂的改动，且产出质量终于达到可投入使用水平。因此我定下新规矩：不再手动编写代码。如果智能体卡住，我不允许自己接手编码，而必须找出智能体缺失的能力——并针对性修复。 我并非通过阅读编程指南变得擅长编码，而是通过大量实践：编写代码、运行测试、观察失败、调试修复、循环迭代。智能体本质上仍是软件，若不实际使用就无法真正理解它们。我必须在真实工作中运用它们，观察其失败点，调整提示词、工具或环境，然后再次尝试。这条规则强制我完成了这些练习。 我曾打破规矩一次，持续了三分钟。我打开代码写了数行，感觉美妙极了——我怀念这种感觉。但当我意识到后续仍有大量输入工作时，我果断放弃了。 ## 从一个智能体到十几个 一旦停止亲手编写代码，我开始发现大量空闲时间。我给智能体分配任务，然后在其工作期间我便无事可做。与其等待，我转而启动另一个智能体处理其他事务。接着又启动第三个……我并非有意构建并行系统，只是想填补任务间的空隙（我患有注意力缺陷多动障碍，容易分心）。 想象一下：多位开发者共享一台开发机，却互不沟通且同时工作——这就是我最初的并行配置。智能体们修改相同文件与 Git 状态、安装依赖包、争夺端口占用、遗留后台进程。我还需要协调每个智能体何时测试、推送或部署。更糟的是，我常常因等待运行时间最长的智能体而阻塞其他任务。原本为避免等待而启动的多个智能体，反而创造了新的等待方式。 我向朋友和同事请教解决方案，大家都分享了变通方法。首先想到的是工作树（Worktrees）：每个智能体获得独立检出副本和分支，基本解决了源代码冲突。但工作树仅处理了 Git 层面的问题，智能体仍共享数据库、端口、进程及机器资源。于是人们用 AGENTS.md 配置文件打补丁：使用随机端口、创建临时数据库、不操作其他智能体的进程。每种冲突都新增一条指令，智能体却将大量上下文浪费在避免冲突上，而非完成任务。 容器方案更接近理想：隔离了端口、进程和本地状态。但边界存在泄漏风险：凡是笔记本电脑能访问的资源，容器也可能访问到。错误命令的影响范围未被限制，我仍需审批每条命令。最糟糕的是，一旦合上笔记本电脑，所有工作便戛然而止。 ## 我合上笔记本，工作仍在继续 此时我已加入 exe.dev 团队。我们制造能在数秒内启动的 Linux 虚拟机（https://blog.exe.dev/meet-exe.dev），且预装 SSH 和 HTTPS 服务。因此将智能体迁出笔记本电脑成为自然选择：每个任务独享一台机器。我可以合上电脑离开，而工作持续运行。 但这带来了新问题：如何为智能体可靠地搭建完整开发环境？启动脚本的三次迭代：每次创建新虚拟机，循环验证环境就绪 秉持不手动编码的原则，我让 Claude 编写启动脚本：说明需求后，指令其循环执行直至成功。脚本安装工具链、克隆仓库、配置 Claude Code 和 Codex，将全新虚拟机转化为开发环境。随后执行验证循环：创建新机器、运行脚本、检测故障、修复脚本、重复尝试。 智能体机器虽能正常工作，但每个智能体拥有独立 tmux 会话。我不得不保持十几个终端窗口打开，以监控各智能体状态，并在它们之间跳转——检查哪个完成、哪个卡住、哪个需要协助。我需要统一管理界面，于是构建了 `botd`。 我为 `botd` 设定三条原则：首先，它必须运行在笔记本电脑之外（确保合上电脑后智能体持续工作）；其次，移动端必须是一等公民（https://blog.exe.dev/building-software-from-your-phone）——管理智能体不应受限于终端屏幕；第三，必须保存所有对话记录，以便回溯分析智能体卡点、有效指令及重复问题。 `botd` 负责智能体机器的创建与销毁、驱动底层智能体、追踪所有任务。它清晰展示哪些智能体在运行、哪些卡住、哪些等待指令。通过手机或电脑，我能检查对话、发送后续指令、审阅代码差异。原本需管理十几个终端会话，现在只需一个界面。 ## 一切通过，我仍不放心 若需审批每个工具调用，这套系统将失效——我会再次成为瓶颈。由于每个智能体运行在隔离的临时虚拟机中，我允许其以 YOLO 模式运行：可执行 bash 命令、安装软件包、启动服务、修改所需配置。环境损坏仅损失一台虚拟机，成本极低。 但仅限于操作自身虚拟机的智能体价值有限。我仍需要智能体读取日志、从 Git 拉取代码、调用 Anthropic/OpenAI 接口、检查 Stripe 数据。这些访问权限才是风险所在，而虚拟机无法限制此类访问。智能体读取不可信内容时可能遭受提示词注入攻击；任何可被触及的资源都可能被泄露或破坏。我清楚存在未填补的漏洞。 因此每项外部访问权限都需回答同一个问题：最坏情况是什么？读取权限基本通过（智能体仅获只读访问）。写入权限则被严格限制在测试环境——最坏情况仅是测试数据损坏。我也不希望凭证存储在虚拟机内（https://blog.exe.dev/oauth-for-agents）。借助 exe.dev 集成方案（https://blog.exe.dev/http-proxy-secrets），智能体请求经代理转发，代理添加凭证后返回响应，智能体全程无法接触密钥。 ## 验证困境 我曾同时运行约二十台虚拟机（并非全部活跃）。部分任务启动后闲置数周，最终因认知负荷过高且优先级不足而被放弃。这种规模下，手动验证完全不可行：我无法重建每个分支、重跑测试、亲自检查应用。但智能体可在隔离环境中运行测试、触发完整 CI 流水线、启动应用并通过浏览器操作，最终向我发送完成工作的截图。 然而智能体仍在自我评审——若其误解需求，可能构建错误功能、编写错误测试，却自信地宣称一切通过。因此能够访问运行环境至关重要：我可亲自操作，端到端测试新 UI，确保其按我的预期（而非智能体声称的效果）运行。 当多个智能体同时完成任务，我面对的是待审阅代码队列：完整变更需被理解才能合并。而我自己编写代码时，提交评审前早已理解变更——每个决策都是亲手制定。使用智能体时，整个差异突然涌现。即便测试通过、截图良好，仍是陌生代码。 让其他智能体审阅代码（https://blog.exe.dev/review-the-reviews）效果出乎意料：它们偶尔能发现真实缺陷，且执行多轮审阅成本低廉。但我不能仅因智能体批准就合并代码——我必须理解变更，我仍然为合并的代码负责。 有时我确实理解了变更：测试全绿、截图美观、UI 符合需求、数据结构合理、所有审阅智能体一致通过。但我仍可能丢弃它。或许无人需要此功能；或许它为已有功能引入了重复实现；或许这点小便利会带来持续数年的复杂度。工具能告诉我变更有效，却无法判断其是否值得纳入系统。 下线功能远比上线困难：海勒姆定律（Hyrum's Law）开始显现——当系统用户足够多时，每个可观察行为都会被依赖（即使你从未意图将其作为契约）。移除功能会破坏你未知的用户脚本和工作流。部署变得容易，决策变得重要。 ## 并非所有智能体都编写代码 以上讨论均围绕代码部署。但我们的部分高价值智能体（https://blog.exe.dev/inventory）根本不涉及代码编写。有必要重新定义“智能体”——这个词的重量超过了其实际含义：智能体本质是工具循环中的模型（https://sketch.dev/blog/agent-loop）。流程仅为：向模型发送消息→若请求工具调用则执行并返回结果→循环。模型赋予循环智能，赋予其真实计算机的 bash 权限后，它能安装缺失组件、适配参数差异、持续工作直至完成任务。循环永不改变，工具决定智能体的能力边界。 开发智能体需要完整计算机环境：命令行、编译器、浏览器及自由安装软件的权限。剥夺这些能力则智能体毫无用处，你将退回审批每个操作的原始状态。我的起点是：给予智能体开发者所拥有的一切。优秀的开发者工具往往也是优秀的智能体工具。至于最佳智能体工具最终是否仍属于开发者工具，时间会证明。需要警惕的并非单一工具，而是组合：私人数据、不可信内容、外部通信——任意两者组合尚可管理，三者集于一身则会导致密钥泄露。这正是西蒙·威利森（Simon Willison）所称的“致命三重奏”（https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/）。 因此我并非盲目限制工具：我隔离环境，并监控组合风险。 **案例一：问题调查** 当客户报告问题时，我使用这样的提示词（直接引用至关重要）：“客户报告：\。请使用 ClickHouse 日志查明发生什么。”若我总结报告，智能体会继承我的解释及盲点。直接使用客户原话后，它查询日志、阅读相关代码、重建事件真相。随后由我决策：有时选择方案，有时证据表明“符合预期”（修复方式可能是文档或邮件而非代码）。无论如何，我基于证据决策，而非猜测。 **案例二：攻击测试** 我们的红队智能体收到唯一指令：尝试入侵系统。它成功发现了我们认为已限制的开放网络路径，并展示了如何仍可访问。我们在外部无人察觉前修补了漏洞。这比理论漏洞列表更有价值——它基于运行时系统检验了我们依赖的假设，而该假设被证伪。 **案例三：部署监控** 部署令人恐惧，但不部署危害更大。我们分批发布，编写完美的继续部署规则几乎不可能——生产环境会以诡异方式失败。因此雅典娜（Athena）（https://blog.exe.dev/athena-deploys-exe）监控每次部署：读取差异、指标和日志，观察滚动发布。某次部署中，它发现问题并调查，确认是基础设施问题而非新代码所致。它没有盲目停止发布，而是继续向其他机器部署。 分批部署中；雅典娜在中期发现基础设施问题并继续推进发布 我能否做得更好？我不再确定。雅典娜比我更专注：不分心、不急躁、永不停歇。它不知疲倦。 ## 在智能体编写代码前设计系统 智能体如今能近乎瞬时设计并构建整个系统，设计可能还很出色。但若我简单接受成果，我是否了解其工作原理？何处可能崩溃？做出了哪些妥协？同意了哪些取舍？此刻，我继承的其实是一个崭新的遗留代码库。这就是“氛围编码”（vibe coding）。 智能体工程（Agentic engineering）（https://blog.exe.dev/claude-is-not-a-compiler）是先与智能体协作设计系统架构、接口、约束和权衡。当代码生成时，我已理解即将接手的内容。智能体工程没有统一答案：每个人工作方式不同，每个模型特性各异……