半年重度使用编码 Agent 的六条实战心得

作者用 Cursor、Claude Code 和 Codex 在半年里上线了多个产品，把踩坑经验整理成一套可复用的方法论：瓶颈从写代码转移到了决策，框架要小，计划要写排除项，记忆要沉淀进仓库。文章有具体做法和亲身教训，读完能直接照着调整自己的 Agent 工作流。

瓶颈从实现转向了决策

• 过去想法要几周才能变成可判断的东西，现在一两天就能有能跑的版本
• 真正变慢的是决定：值不值得做、最小版本是什么、什么必须保持成立
• 写代码成了很有说服力的拖延方式——一周能产出大量软件，却不一定创造价值
• 能跑的第一版只是廉价证据，真正的验证是用户回访、付费和信任

放弃大框架，改用 13 个小 skill

• 早期试过各种 agent skill 集合，动辄三十个 skill 加各种阶段和流程，记不住就弃用了
• 流程越繁琐，产出的代码越带没人要的抽象层和配置项
• 自建 fstack：13 个 skill、直白命名、每个约 150 行，超了就说明它管太多
• 最常用的是 /fstack-simplify，只做删减：死文件、单调用者的抽象、没人要的配置，并说明删掉会失去什么——答案通常是没什么

计划里最有用的是'不做什么'

• 每份计划固定四段：做什么、步骤、不做什么、怎么算完成
• Agent 擅长扩展想法：抽象、设置页、fallback、仪表盘，听起来都合理但大多不需要
• 排除清单给任务划了硬边界，清单外的一律不进任务
• review diff 时对照计划，既找漏做的，也找没批准却多做的

仓库要记住，聊天不会

• 新会话没有昨天记忆，会猜错包管理器、跑错测试命令、改生成文件
• 每次重复纠正的内容写进 AGENTS.md；设计原因写进决策记录
• 最有价值的是那些奇怪事实：必须匹配托管项目的配置名、看着像生成但其实不是的目录、必须留在文件末尾的重定向规则
• 维护有陷阱：命令过期会让 Agent 学会无视整个文件；偏好写成硬规则会让 Agent 分不清轻重
• 用 Git post-commit hook 自动填一份按日期和项目分组的纯文本工作日志

Agent 多不等于产出多

• 五个 Agent 没有结构就是五种理解：一个改数据模型、一个发明设计系统、两个改同一文件
• 有效结构是管理者加工人：一个强推理模型读全库、定计划、拆任务；工人拿有边界的任务、明确文件所有权、必须交报告
• 最省时间的规则：独立文件并行，共享契约串行
• 多数时候还是单任务单 Agent；多开像空中交通管制，只用于批量机械性工作
• 用 Herdr 看哪些 Agent 在跑、哪些在等，目标是保持工作可理解、错了能拒

看文件不看汇报，先问再写

• Agent 说做了不等于做了：自己打开文件、读 diff、跑构建
• 每个委派任务三选一：Accept（符合要求）、Patch（当场修小问题）、Re-brief（方向错了就重写任务说明）
• 悄悄替 Agent 修大问题什么都改进不了，坏 brief 会带来同样的失败
• 代码评审尽量开新会话：写代码的会话已有'为什么能跑'的故事，新会话只看 diff 和仓库
• 让 Agent 写代码前先提问：webhook 来两次会怎样、返回 200 用户真拿到权限了吗；并要求输出分'已确认行为'和'猜测'两部分