把AI编码代理当外包员工之前，先学会给它上锁

我对比了直接给AI代理开全权限干活和给它套个隔离环境干活这两套流程，实际各跑了一周，这边把经验写下来。先说明一下，我现在用的是Claude Code这一类命令行工具，原理上别的编码代理也适用。

先说结论：把AI编码代理当外包程序员用这个思路是对的，但绝大多数新手第一步就错了，直接在自己电脑上让它随便跑。我这边测下来，正确做法只有一条，给它一个一次性的、用完就扔的工作环境。你想想，你也不会给一个刚来的实习生你电脑的全部权限对吧。

具体操作分三步。

第一步，给代理开一个独立文件夹。不要在你现有的项目目录里直接用，新建一个目录，把需要改的代码复制进去，让代理在这个副本里干活。我这边用Python写脚本测试的时候出过一次事故，代理为了fix一个bug，把我另一个模块的文件也改了，因为它觉得“这样更合理”。改完还不告诉我。你要是在原项目里跑，这种改动直接污染主分支。

第二步，设置权限边界。大部分编码代理工具都支持配置，比如允许读哪些目录、不允许执行哪些命令。我这边测试下来，需要把所有网络请求、包安装命令、git推送操作的权限全部关掉。这一步很容易被忽略，因为默认设置通常是全开。建议配置成每次要执行命令时都向用户请求确认。虽然会打断节奏，但比起让代理自己装了一堆依赖把环境搞坏，这点成本可以接受。

第三步，把任务拆小。这步最反直觉。给代理一个大任务，比如“帮我重构这个模块”，它大概率会构建一个巨大、漂亮、但完全不符合预期的东西。真正的做法是把任务拆到不能再小，一次只让它做一个功能点，比如“把这个函数改成支持传入可选参数，改动范围不超过20行”。任务越具体，产出越可控。

踩坑环节。最容易出错的地方发生在第一步，有人觉得自己用git管理代码，不用复制，直接在分支上让代理干活就行。我试过，代理会忘记自己在哪个分支，直接commit到master上。所以每次跑之前，先确认工作目录是不是那个一次性文件夹，确认完了再开代理。另一个坑是代理在处理完任务之后会自动帮你合并代码，有些工具甚至会自动改配置文件或启动服务。解决方式是把代理的自动操作权限全部关掉，让它只输出diff变更内容，你自己手动审查合并。

数据方面，我这边测下来，给代理隔离环境之后，单次任务的返工率从大约六成降到了两成左右。所谓返工是指它产出的代码需要你重新改一遍才能用。没有隔离环境的时候，它决策错误造成的连带影响特别难排查。

这个领域正在快速变化，各家工具都在往多代理协作的方向走，一个代理写代码，另一个代理审查，还有一个代理跑测试。我这边测下来，多代理协调本身消耗的精力不比写代码少，目前还看不到能完全自动化的迹象。

学完这个，下一步可以试着给代理分配一个不需要碰核心代码的小任务，比如更新README文档或者写单元测试。等它适应了你项目的风格，再慢慢让它碰真正的业务逻辑。记住一条原则，代理只做机械劳动，判断和决策永远是人的活。

---

本文编译自 Hacker News，原文：I treat my AI coding agents as subcontractors — karavox devlog
版权归原作者所有，本文为基于公开报道的编译与独立分析。