现如今，AI 写代码的能力已经无人质疑。但是又有人提出了新的疑问：Coding Agent 似乎把开发过程中最有意思的部分（写代码）接管了，但是把各种杂活、烂活都交给了人类，比如配置环境、部署、维护……似乎现在变成了人给 Agent 打工。
如果事实真的是这样，那人可就太苦了。经过一段时间的尝试，我发现：除了写代码，这些其他相关的杂活也完全可以让 Agent 一起做掉。Agent 把这些工作「包圆」之后，整体的效果反而更好了。
当然，这一切的前提是，你需要设计 Agent 友好的工作流程。
这篇文章会分享我在实践中的一些经验，包括如何让 AI 自己完成：
- 测试
- 代码评审
- 项目管理
- 部署运维
- 调试
测试
测试可能是最急需 Agent 自己完成的一项工作。原因无他，在 AI 带来开发效率急剧上涨的情况下，测试的工作量也急剧上涨了。如果还是让 AI 写代码，人肉测试，那么人注定只能疲于奔命了。
幸运的是，测试也是一种代码。既然 Agent 可以写代码，那么它也可以写测试。
说到这里，可能会有很多人想到单元测试（unit test），想到测试驱动开发（TDD）。但是我发现，在 AI 编程时代，我们最需要的不是单元测试，而是端到端测试（e2e test）。
端到端测试，会从系统的整体功能出发，测试完成功能链路的测试。例如，调用某个 API ，带着所有的功能逻辑和数据库一起运行，观察结果是否符合预期。当 AI 接管了代码编写，再去深究每个单元测试就变成了刻舟求剑。而端到端测试，才能让我们去审视系统的各个功能，从宏观的角度去把控 AI 写的代码。
我使用的测试驱动开发的方式也是 e2e 测试驱动的。在让 Agent 开发新功能的时候，把 e2e 测试写好。这样每次修改代码时，都重新跑一遍 e2e 测试做检查。这样的自动化测试，不仅能测试各种边界场景，还能在代码改出问题的时候及时发现。
代码评审
实话说，现在已经几乎不会直接评审 AI 写的代码了，因为 AI 评审代码的效果比我更好。
我最喜欢的代码评审工具是 GitHub 上的 Codex。Codex 的评审是包含在 ChatGPT 的订阅套餐里的，顺便就能使用，而且评审的质量很高，经常能发现一些代码中的盲点。
唯一的要求是，你需要在 GitHub 上使用，通过打开 PR 的方式触发评审。
为了适应这一点，原本我自己的项目是图省事直接 push 代码的，现在都统一改成提交 PR 了。没想到，PR 的方式反而更省事了，不仅可以享受 Codex 代码评审，还可以通过 CI 跑前面说的 e2e 测试。一套组合拳下来，代码里的低级问题可以很容易揪出来，再也不用担心一不小心把系统改坏了。
所以说，用 AI 做代码评审，最大的技巧不是用什么工具，而是规范你的开发流程。
顺带一提，代码评审意见也不用自己盯，我一般是让 Agent 自己去 PR 里看评审意见，然后自己修复和回复：
处理当前 PR 的 Codex 评审意见，按以下步骤处理：
1. 观察评审状态，等待评审结束
2. 如果评审无问题，且所有评审意见都已 resolved，直接结束
3. 分析所有评审意见，判断是否需要修复
4. 对于不需要修复的评审意见，直接评论并 resolve
5. 对于需要修复的评审意见，修复问题，然后评论并 resolve项目管理
你有多少时间是在做项目的搬运工？对于需求和 bug，先是把它们的信息从系统里搬出来，喂给 Agent。Agent 解决问题之后，再把结果在系统里同步修改……
慢着，既然你的代码和评审已经放在了 GitHub 上，那为什么不把项目管理也放到 GitHub 呢？答案就是 GitHub Issue，如果项目复杂，再加上 Github Project。
借助万能的 GitHub CLI，遇到一个 bug，只需要记在 GitHub issue 上，在 issue 评论里补充相关的信息，然后跟 Agent 说：「修复 issue 123，修复完成后，提交 PR，并关联上 issue」。Agent 自己就能拿到所有相关的信息，然后写好代码。提交 PR 的过程中，又能自然地触发评审和测试。PR 合并后，issue 便可自动关闭。
没错，这便是 GitHub 多年固定下来的项目管理流程。这套流程，AI 早已经烂熟于心，只要你稍微动动嘴皮子，它就可以一套连招帮你完成。在这种情况下，又何苦另起炉灶，自己苦哈哈地当个信息搬运工？
很多时候，并不是 Agent 做不了这些事情，而是你给它配置了不合适的系统和工具。
部署运维
如果说前面都只是一些常规操作的话，那么这里就到了真正的难点。部署运维的操作，都是分散在不同的系统，各种一次性操作，这怎么接进 Agent 里？
这时候就要请出我们的大杀器：Terraform 了，它的理念是：Infrastructure as Code （基础设施即代码，IaC），也就是说，把基础设施的状态抽象成配置文件（代码），部署运维的过程就是修改代码的过程。本来 Terraform 只是一个小众领域的工具，然而在 AI 时代，它的特性跟 Agent 出奇地相符：
不是基础设施即代码吗？我 AI 最擅长的就是写代码了！
没错，各种运维过程，不需要给 Agent 接入什么功能，只需要把 Terraform 项目配置好，然后让 Agent 写 HCL 配置代码就可以了。无论是 AWS 集群、Cloudflare，还是 GitHub 仓库，都可以用这种方式操作。写好代码之后，只需要一步 terraform apply 就可以完成部署操作。
你可能还会疑问：为什么要费大劲把各种东西都变成代码呢？这么一圈下来，可能还不如我直接去页面上点一点来得快呢。
答案在于「任务完整性」和「上下文」。
如果你总是把运维的动作手工来做，那么就限制了 Agent 只能写代码。当一个任务需要穿插写代码和运维的时候（例如，先写一版代码，再部署，观察效果之后，继续改进），你就必须人工参与到这个任务中：先让 Agent 完成一部分写代码的工作，然后自己手工做运维，再让 Agent 继续工作。
这个过程不仅很麻烦，而且 Agent 永远不知道：你究竟在运维那部分手工做了什么。因为缺失了上下文，Agent 可能会做出一些错误的决策。例如，如果 Agent 知道你把网站部署在了 Cloudflare Pages 上，就会知道你想要的是纯静态网站，就不会写出动态的路由。
所以说，让 Agent 工作的最好方式是给它完整的工具和上下文，让它从头到尾完成一个任务。这样既省心省力，也能提高任务的成功率。
调试
在很多人的脑海里，调试技能最强的人是那个团队里最有资历的人，知晓系统里各种犄角旮旯的特性，当疑难杂症出现时，靠着不可言说的经验一下子就定位了问题。反观 Agent，这个被比喻成「实习生」的角色，所有项目背景都是刚醒来现场学的，怎么可能比得过有经验的人类？
非也！有没有一种可能，并不是那个人的经验有多丰富，而是因为系统没有任何文档，各种重大决策靠口口相传，出问题没有日志全靠猜。新员工根本没法摸清楚问题该如何入手排查，只能靠老员工凭借模糊的记忆进行猜测？
对于 Agent 也是一样，Agent 排查问题的效果好不好，取决于它能拿到多完整的上下文。
曾经我把问题现象进行描述就让 Agent 进行分析，Agent 没有任何观测手段，只能看代码。这时候它经常会给出错误的结论，只有 GPT xhigh 在经过长时间的苦思冥想，能给出正确率比较高的回答。
现在我发现，把完整的上下文信息给到 Agent 之后，它排查出问题原因的概率大大提升了。这些上下文包括：
- 项目部署的情况（直接把上一章节说的 Terraform 代码给它看）
- 日志目录
- 数据库连接信息
当 Agent 可以一边看代码、一边分析日志和数据库的时候，它一般就能综合多方信息找出问题原因了。大约 80% 的问题都可以通过这种方式排查出原因。
对于更加疑难的问题，有可能现有的日志并不足以给出足够的证据。我会让 Agent 像人排查问题的过程一样进行思考：
- 首先，根据问题现象给出若干个原因的假设
- 对每个假设，在关键的地方添加打印日志代码
- 再运行一遍，根据新的日志，看看是维持还是推翻这些假设
我把这样的假设-分析的流程写成了一个 skill，你可以去这里安装并访问这个 skill：
https://github.com/nettee/ai-collection#skills
如果你能够把 Agent 自动调试的流程玩得转，那么在 Agent 领域就可以跻身高手行列了。
总结
AI 编程的好处在于解放生产力，把人们从枯燥的写代码过程中解放出来，去创造更有意思、更有价值的软件。假如 AI 只把「好活」拿走，而把「脏活」留给人类，那我们拥抱 AI 的意义何在？
如果你还在沉迷于给 AI 打杂，帮它解决各种脏活累活，请立即停下来。我们不应该把宝贵的精力放在这些事情上面，而是应该全面地指挥 AI 完成工作，而让自己取挥洒创造力。
有了这样的意识，你才能真正迈入 AI 编程的下一个阶段。