Coding Agent重塑工程师角色，实践聚焦验证与决策

随着Coding Agent深入软件开发，工程师的日常正从编写和阅读代码，转向查看多个智能体的进度、处理测试失败、审查PR并决定是否交付。11月8日，Anthropic Claude Code团队工程师Addy Osmani发文指出，选择任务、编写指令、跟踪执行、评估结果和决定上线，已经与管理工程团队高度相似。真正擅长使用Agent的人，不一定最会写提示词，而是能让其自主工作，同时建立可靠的验证机制。

Addy建议让Agent自行证明任务已经完成，而不是由工程师逐行检查所有代码。成熟团队依赖CI、自动化测试、Linter和代码审查，Agent工作流也应如此；UI任务还可让它直接打开浏览器检查效果。开发者可以在CLAUDE.md中记录测试命令，利用/goal复核目标、Stop Hook阻止类型检查失败的任务结束，或用/code-review安排独立子Agent审查。任务说明应补充背景、约束和成功标准，例如将万人组织的/team仪表盘p95加载时间降至2秒以内，同时不改动数据库Schema和API响应结构，并通过指定脚本验收。

重复出现的纠错经验可以写入CLAUDE.md或封装为Skill，重点保存验证命令、容易误解的代码、关键决策和常见错误，但规则不能无限堆积，应随模型和项目变化定期清理。对于“禁止修改生成代码”“必须运行检查”等硬性要求，可通过Hooks和Deny Rules强制执行；一般偏好则应减少干预，避免把人类微观管理复制到Agent身上。

在协作方式上，Addy强调“可以委派任务，但不能委派判断”。复杂工作应先进入Plan Mode讨论方案，必要时让第二个会话从资深工程师角度审查计划。/batch可把大型修改拆成5至30个相对独立的任务，并借助Git Worktree并行执行、创建PR，但人工仍要确认任务边界和共享接口。若Agent早期方向偏离，应尽快纠正；连续两次仍失败时，最好清除会话并重写提示词，/rewind则可恢复代码和对话状态。

自动化测试通过、代码审查完成，并不代表修改值得合并。Addy曾发现一项看似合理的竞品功能研究最终只会增加产品复杂度；即使面对600行命名规范、测试通过的代码，也不能忽略其产品价值、维护成本和安全风险。常规Bug修复、代码整理和单元测试可以交给Agent，但产品取舍、安全边界、合规要求及最终上线决定仍应由人负责，并尽量缩小每次变更范围。

同时运行五个Agent不等于获得五倍产出。无人值守流程上线前，应明确完成条件、验证方式、权限范围、执行轮数或费用上限，以及最终审批人，并先用三个文件进行小规模试运行。每增加一个Agent，工程师都要承担更多协调、审查、异常处理和上下文切换成本，这种额外负担被称为“编排税”。Addy通常会同时运行四五个后台Agent和数个本地会话，但人的注意力仍是并行规模的主要限制。