这五类任务别交给 Agent
用了几个月 agent, 很容易进入一种状态: 什么东西都想扔给它干。
但有些任务真的不适合——不是 agent 能力不够, 是让它干的风险和收益不成正比。
一、涉及生产数据的操作
直接在生产数据库上跑 SQL——哪怕是 SELECT——我不放心。Claude 不会故意搞破坏, 但它可能因为理解偏差, 扫了全表导致数据库打嗝。操作生产环境的配置、直接改线上服务的部署配置——这类事我坚持自己来。回滚一次的时间比让 agent 操作省的时间多得多。
二、安全敏感的变更
改登录逻辑、权限校验、加密解密——这些我从来不交给 agent。不是因为 Claude 写不对, 而是这类代码出事就是大事, 而且漏洞往往不在明面上。
我的做法: agent 可以写 draft, 但每一行我都要亲自 review, 并且要额外找个同事再看一遍。不信任叠加——两层人眼比一层可靠。
三、需要人类判断的决策
“这个按钮是放左边还是右边"“这个错误信息用户能看懂吗"“这个 API 的返回值要不要加个字段”——这些没有对错之分, 只有"合不合适"的问题。
Agent 没有产品 sense, 也没有用户的上下文。让它在两套方案里选一个, 它选的方案可能从技术角度看最优, 但从产品角度看完全不对。
四、模棱两可的"看看”
“帮我看看这个项目有什么可以改进的地方”——没有范围、没有标准、没有截止条件。Claude 会去读几百个文件, 然后把上下文塞满, 最后给你一个泛泛的报告。
如果你真的想做代码审查, 给范围: “只看 src/api/ 下的错误处理逻辑, 找潜在的空指针风险”。
五、跨多系统的协调
需要改 A 服务、等 B 服务部署完、再看 C 服务的响应有没有变化——这种跨系统的流程, agent 做不了。不是因为技术不行, 而是每一步之间可能有你无法预料的依赖, agent 不知道什么时候该等、什么时候该继续。
当然, 这些"不适合"的边界不是固定的。随着你越来越了解 agent 的能力边界, 有些之前不敢放手的任务, 后来发现其实可以。
但有一个建议: 宁可保守, 不要激进。让 agent 从风险最低的改写入门, 慢慢建立信任, 而不是第一次就让它去动生产配置。