企业官网建设流程全解析

Agent 模式刚出来那阵，我是抱着「终于可以躺着了」的心态用的。一句话下去，它自己找文件、自己改、自己跑命令，看着确实爽。

用了一段时间之后心态变了：爽的时候很爽，翻车的时候收拾起来比自己写还累。

后来我给自己定了几条判断标准，什么活儿交给它、什么活儿自己来。这篇记一下这几条，以及两次翻车的经过。

一、三个文件是我的分界线

最简单的一条：改动涉及三个文件以内，我自己用 Cmd+K 一个个来；超过三个，才考虑开 Agent。

原因不是 Agent 改不好，是审查成本。两三个文件的改动，我扫一眼 diff 就知道对不对；十个文件的改动，不管谁改的，我都得老老实实一个个看。

既然横竖都要看，那不如让它一次改完，我集中审。反过来，两三个文件的活儿让 Agent 去做，光是等它探索文件就比我自己改慢了。

在 wescode 里我是按Ctrl+Shift+K切 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。两边各自看都没问题，本地验证也都过，合在一起就是坏的。

另外它限制了委派的嵌套深度，子任务不能无限往下再派。这个限制我一开始觉得多余，后来想想——没有限制的话，一个模糊的任务可能会裂变出一堆子任务，最后你完全不知道它在干什么。

六、我现在的实际用法

综合下来，我日常的分配大概是这样：

最后一条要展开说一句。架构层面的决定——要不要拆包、接口怎么设计、分层怎么划——我不交给 Agent。不是它做不了，是这类决定的影响周期太长，出错的代价不对称。改错一个函数可以回滚，架构走偏了要还半年债。

这类事我会在 wescode 的 Chat 里让它给几个方案对比，最后自己拍板。

七、什么情况下 Agent 完全不值得开

探索性的活儿。你自己都还不知道要改成什么样，先想清楚再说。

需要频繁确认的活儿。如果每改一步都要你判断一次，那 Agent 的自动化就没意义了，不如用 Chat 一问一答。

存量代码很少的新项目。没有历史包袱，直接写比让它探索快。

你没打算认真审查的时候。这条最重要——如果你不准备逐行看 diff，就别开 Agent。接受一堆没看过的改动，风险远大于省下的那点时间。

小结

用下来最大的体会是：Agent 不是「更强的 AI」，是一种把多步操作打包执行的方式。

打包的前提是这些步骤都明确、可验证、能回滚。满足这三条，它能帮你省掉大量机械劳动；不满足，它就是个更快制造混乱的工具。

我现在的判断很简单：这活儿如果交给一个刚入职的实习生，我敢不敢放手让他做完再检查？敢，就交给 Agent；不敢，那自己来。

文中的 Agent 模式切换、子任务并行和全局一致性检查都是 wescode 里的能力，官网是 weisyn.com。你们把什么任务交给 AI Agent，有没有翻过车，欢迎评论区聊聊。