用下来大半年，我觉得最该说清楚的反而是它不擅长什么。不是唱衰，是少踩点坑。下面三个场景，是我反复碰壁之后总结的，每次都付出了真金白银的时间。

一、需求本身模糊时，它会瞎编

有一次产品只说"做个导出 Excel 的功能"，我就直接丢给 agent 了。它很认真地写了一个用 EPPlus 的导出，字段、样式都齐。结果产品看了说"我要的是按当前筛选条件导出，还要带汇总行"。它基于一个我根本没说清的需求，把实现补全了，而补全的部分就是凭空猜的。那次我白写（其实是白生成）了两天，最后推掉重来。

后来我学乖了：需求没定清楚之前，绝不让它动手写，顶多让它列"要做这个功能需要我先回答哪几个问题"。

二、需要理解老系统的历史包袱

我们有一张表，某个状态字段存在"0 表示已废弃，但老数据里 0 其实是正常"的情况，这是三年前一次迁移留下的。让它加个新查询时，它完全按常理把 0 当成废弃过滤掉了，上线后一片投诉。

这种"为什么这里有特例"的知识，不在代码里，在人的脑子里。它读得再仔细也读不到没写下来的背景。

三、跨多个服务的一致性改动

最危险的是改协议。有回要改一个接口的字段含义，涉及订单服务、通知服务、报表服务三个仓库。我让 agent 改了订单服务的，它信心满满说"其它服务同理"。但通知服务那个字段走的是消息队列的旧格式，直接照改会静默丢消息。

跨服务的改动，边界和约定散在不同地方，没有一个人或一个文档能说全。这种活我现在坚持自己画改动清单，再小步分服务验证，不敢交给它一把梭。

（写完发现第二点的例子和第三点有点像，都是"它不知道背景"，但一个是历史数据、一个是跨服务约定，我还是分开留着，免得以后回看时混掉。）

四、那它到底适合干什么

把上面三个反面拎出来，反过来说它适合什么就清楚了：需求你已定死、上下文它读得到、改动范围在一个能看清的边界里。满足这三条，它省事；缺一条，我就把"它给的东西"降级成"参考草稿"，自己拿主意。

我也试过用规则规避：需求模糊的，先让它帮我列澄清问题；涉及老系统的，先把那段历史背景写进 CLAUDE.md 再让它碰；跨服务的，我手写改动清单逐项核对。这些都不是它自动做对的，是我提前把"人该操的心"补上了。所以结论还是那句：别神话，它不是来替你想的。