工作流 on Time Friend

这五类任务别交给 Agent

Sun, 22 Mar 2026 08:50:00 +0000

用了几个月 agent, 很容易进入一种状态: 什么东西都想扔给它干。

但有些任务真的不适合——不是 agent 能力不够, 是让它干的风险和收益不成正比。

直接在生产数据库上跑 SQL——哪怕是 SELECT——我不放心。Claude 不会故意搞破坏, 但它可能因为理解偏差, 扫了全表导致数据库打嗝。操作生产环境的配置、直接改线上服务的部署配置——这类事我坚持自己来。回滚一次的时间比让 agent 操作省的时间多得多。

改登录逻辑、权限校验、加密解密——这些我从来不交给 agent。不是因为 Claude 写不对, 而是这类代码出事就是大事, 而且漏洞往往不在明面上。

我的做法: agent 可以写 draft, 但每一行我都要亲自 review, 并且要额外找个同事再看一遍。不信任叠加——两层人眼比一层可靠。

“这个按钮是放左边还是右边"“这个错误信息用户能看懂吗"“这个 API 的返回值要不要加个字段”——这些没有对错之分, 只有"合不合适"的问题。

Agent 没有产品 sense, 也没有用户的上下文。让它在两套方案里选一个, 它选的方案可能从技术角度看最优, 但从产品角度看完全不对。

“帮我看看这个项目有什么可以改进的地方”——没有范围、没有标准、没有截止条件。Claude 会去读几百个文件, 然后把上下文塞满, 最后给你一个泛泛的报告。

如果你真的想做代码审查, 给范围: “只看 src/api/ 下的错误处理逻辑, 找潜在的空指针风险”。

需要改 A 服务、等 B 服务部署完、再看 C 服务的响应有没有变化——这种跨系统的流程, agent 做不了。不是因为技术不行, 而是每一步之间可能有你无法预料的依赖, agent 不知道什么时候该等、什么时候该继续。

当然, 这些"不适合"的边界不是固定的。随着你越来越了解 agent 的能力边界, 有些之前不敢放手的任务, 后来发现其实可以。

Sat, 14 Mar 2026 15:40:00 +0000

刚用 Claude Code 的时候, 我花了不少时间纠结一个问题: 它到底是 agent 还是 assistant?

看了不少文章, 大部分试图给这两个词划一条清晰的线——assistant 一次一步, agent 自主完成目标。但实际用下来的感受是, 大多数工具两种模式都能切, 分界线没那么分明。

真正有意义的区别不是产品叫什么, 而是谁发起、谁控制、在哪里跑。

用 Claude Code 最基础的用法就是这样: 你打一句 prompt, 它动一下, 你看一眼, 然后你打下一句。

你在每一轮都掌握控制权。你决定下一步做什么, agent 只是执行。这种模式下:

把目标扔给 Claude, 它自己去读代码、改代码、跑测试, 最终给你一个结果。

这时候你的角色变了——你不再是驾驶员, 而是定目标的人和审结果的人。中间的过程你不需要每步都看。

这种模式下:

抛开理论, 实际工作中最好用的区分方式其实是谁触发的:

我自己最有价值的体会是: 不用纠结它该叫 agent 还是 assistant, 而是建立一条 pipeline——用 assistant 模式试出一个可靠的工作流, 然后把它变成定时跑的 agent 任务。

Thu, 08 Jan 2026 10:30:00 +0000

刚用 Claude Code 的时候我有个毛病: 打开终端, 直接敲一句话告诉它帮我改什么, 然后看着它一顿操作, 最后发现方向完全不对。

后来想明白一个道理——Agentic Coding 和写代码是两套不同的技能。写代码的时候你的手跟着脑子走, 但用 agent 的时候, 你的价值在于"定义目标"和"审核结果", 而不是替它打字。

那怎么让 agent 不走偏? 我总结了四个步骤: 探索 → 规划 → 编码 → 提交。

Plan 模式是 Claude Code 的只读模式。启动的时候加个参数:

claude --permission-mode plan

会话里按 Shift+Tab 可以在 Plan 和 Accept-Edits 之间切换, 或者直接打 /plan。

为什么要先探索? Claude 对项目的理解完全取决于你给了什么上下文。让它自己把相关文件读一遍, 画出一张地图, 比你凭直觉说"去改那个文件"要靠谱得多。

碰到特别棘手的架构问题, 我习惯在 prompt 里加一句 “think carefully before proposing anything”。多数情况下, 它前面的推理越仔细, 后面的返工就越少。

不过也别教条。如果任务很小——修个 typo、改个变量名、加一行日志——直接让它做就行, 不需要走完整个 plan 流程。官网文档也说了: 如果你能用一句话描述完改动内容, 那就跳过 plan。