目录一、三个文件是我的分界线二、任务得有客观的验收标准三、必须能回滚四、两次翻车五、多个子任务并行真正有用的场景六、我现在的实际用法七、什么情况下 Agent 完全不值得开小结Agent 模式刚出来那阵我是抱着「终于可以躺着了」的心态用的。一句话下去它自己找文件、自己改、自己跑命令看着确实爽。用了一段时间之后心态变了爽的时候很爽翻车的时候收拾起来比自己写还累。后来我给自己定了几条判断标准什么活儿交给它、什么活儿自己来。这篇记一下这几条以及两次翻车的经过。一、三个文件是我的分界线最简单的一条改动涉及三个文件以内我自己用 CmdK 一个个来超过三个才考虑开 Agent。原因不是 Agent 改不好是审查成本。两三个文件的改动我扫一眼 diff 就知道对不对十个文件的改动不管谁改的我都得老老实实一个个看。既然横竖都要看那不如让它一次改完我集中审。反过来两三个文件的活儿让 Agent 去做光是等它探索文件就比我自己改慢了。在 wescode 里我是按CtrlShiftK切 Agent 模式切换成本很低所以这个判断基本是随手做的。二、任务得有客观的验收标准这条是我最看重的。适合交给 Agent 的任务有个共同特点做完之后有办法自动判断做对没有。比如这几类我会放心交出去批量补类型标注 —— 编译过不过是硬标准统一错误处理写法 —— 有既定模式可以对照给一批函数补测试 —— 测试跑得通就算数批量重命名 —— 编译 全局搜索能验证这几类有个共同点交给 wescode 的 Agent 之前我心里已经知道「怎么算做完了」。而下面这类我不交「优化一下这个模块的性能」 —— 优化到什么程度算好没标准「把这块代码写得更优雅」 —— 优雅是主观的「看看有什么可以改进的」 —— 没有终点它会一直改下去没有验收标准的任务Agent 会一直「做下去」而你没办法判断它什么时候该停。这种活儿还是自己来或者先拆成有明确标准的小任务。三、必须能回滚在 wescode 里开 Agent 之前我一定先 commit 一次哪怕是个临时提交。道理很简单它一次改十几个文件万一方向错了一个git reset比逐个撤销快得多。这个习惯是吃过亏才有的。有次我在一堆未提交的改动上直接开了 Agent它改完之后我想退回去结果分不清哪些是我自己改的、哪些是它改的最后花了二十分钟手动挑。四、两次翻车第一次编译过、测试过但语义变了我在 wescode 里让 Agent 批量给一组 handler 补统一的日志。跑完扫了一眼文件数对、格式对就全接受了。后来 code review 时同事指出有两个文件里的错误处理被改了——原来是 wrap 之后往上抛它改成了记日志然后返回 nil。编译过测试也过因为那两个分支没有测试覆盖。这次之后我加了一条规矩Agent 跑完先git diff整体过一遍不看单个文件的 diff 预览。单个文件看起来都合理放在一起才能发现风格不一致的地方。第二次并发不是越多越好有次做批量迁移我想着并发开大点快一些。结果几个子任务同时跑互相抢终端和文件整体反而更慢中间还出现了两个子任务改同一个文件的情况。wescode 默认的并发上限是 3我当时觉得保守。后来明白这个默认值是有道理的——子任务共享同一个工作区文件系统并发越高冲突概率越大收益却不是线性的。现在我不动这个默认值了。五、多个子任务并行真正有用的场景说完坑说说什么时候并行确实值。最典型的是按模块能切干净的批量改动。比如把一批 API 从旧版本迁到新版本users 相关的、orders 相关的、测试相关的彼此不怎么重叠这种拆开并行是有意义的。wescode 在这块做了件我觉得挺必要的事子任务各自改完之后会有一次全局的一致性检查而不是各自改完就算数。这个检查能抓到单个子任务发现不了的问题。举个例子子任务 A 改了 service 层期望下层返回 error子任务 B 改了 repository 层把错误改成了 panic。两边各自看都没问题本地验证也都过合在一起就是坏的。另外它限制了委派的嵌套深度子任务不能无限往下再派。这个限制我一开始觉得多余后来想想——没有限制的话一个模糊的任务可能会裂变出一堆子任务最后你完全不知道它在干什么。六、我现在的实际用法综合下来我日常的分配大概是这样任务类型我的做法单点修改、小重构CmdK 就地改一两个文件的改动Chat 里问自己应用跨文件批量改有明确标准Agent 模式大规模迁移模块间能切干净Agent 并行子任务涉及架构决策的改动自己来最多让它给方案最后一条要展开说一句。架构层面的决定——要不要拆包、接口怎么设计、分层怎么划——我不交给 Agent。不是它做不了是这类决定的影响周期太长出错的代价不对称。改错一个函数可以回滚架构走偏了要还半年债。这类事我会在 wescode 的 Chat 里让它给几个方案对比最后自己拍板。七、什么情况下 Agent 完全不值得开探索性的活儿。你自己都还不知道要改成什么样先想清楚再说。需要频繁确认的活儿。如果每改一步都要你判断一次那 Agent 的自动化就没意义了不如用 Chat 一问一答。存量代码很少的新项目。没有历史包袱直接写比让它探索快。你没打算认真审查的时候。这条最重要——如果你不准备逐行看 diff就别开 Agent。接受一堆没看过的改动风险远大于省下的那点时间。小结用下来最大的体会是Agent 不是「更强的 AI」是一种把多步操作打包执行的方式。打包的前提是这些步骤都明确、可验证、能回滚。满足这三条它能帮你省掉大量机械劳动不满足它就是个更快制造混乱的工具。我现在的判断很简单这活儿如果交给一个刚入职的实习生我敢不敢放手让他做完再检查敢就交给 Agent不敢那自己来。文中的 Agent 模式切换、子任务并行和全局一致性检查都是 wescode 里的能力官网是 weisyn.com。你们把什么任务交给 AI Agent有没有翻过车欢迎评论区聊聊。