它越像同事，越容易让人误会

第一次用 coding agent 写出一段像样代码时，很多人都会下意识把它往“初级工程师”那个方向想。它会改文件，会跑测试，会继续尝试，看起来确实很像一个能干活的新同事。

但 Simon 这篇最重要的提醒，恰恰是把这个幻觉往回拽了一下。coding agent 更像一个会把你的清晰和混乱一起放大的系统。你说得越清楚，它越像帮手；你说得越糊，它越像一个努力把事情搞得更乱的实习生。

差别往往不在模型，在操作者

同样一个 coding agent，在熟练工程师和新手手里，经常像两种产品。

熟练工程师会补关键上下文，会限定修改范围，会明确指出哪些文件不能动，也会在第一次失败后迅速缩小问题。新手则更容易给一个大而模糊的目标，然后期待系统自己一路做对。

所以 Simon 其实在讲一个有点刺耳、但非常现实的判断：coding agent 的上限，不只取决于模型，也取决于操作者的水平。

开发者最容易低估的那部分工作

对开发者来说，这篇最值钱的地方，是它重新给“带 agent 干活”定了价。

很多人以为真正值钱的是写出那条 prompt，其实往往不是。更值钱的是下面这些动作。

• 先把问题切到可控范围。
• 明确不能碰的边界。
• 根据失败结果继续逼近根因。
• 知道什么时候该停下来自己接手。

这些动作以前也是开发能力，只是现在被 agent 放到了台前。

产品和测试也不是旁观者

产品和测试在这件事里并不只是围观技术人玩新工具。你写任务和写问题的方式，会直接决定 coding agent 的可用性。

产品如果只给一句“把这个流程做顺一点”，agent 大概率会四处乱跑。测试如果只给一句“这里不对”，agent 也很难真正收口。可一旦目标、约束、失败现象和复现条件被讲清楚，整个协作就会稳定很多。

所以这篇也在偷偷改写一个共识：会不会把事说清楚，正在变成跨角色的硬能力。

这件事在日常工作里其实特别明显。一个产品同学如果能把需求写成“支付失败后要保留购物车、埋点不能丢、优惠券状态不能被重复消费”，工程 agent 的表现往往会立刻稳定一截。测试如果能给出“只有 iOS 旧版本复现、切后台再回来概率更高、日志里会出现某个错误码”，agent 也更可能帮你迅速收敛，而不是在仓库里瞎翻。

你甚至可以把它理解成一种新的“协作 literacy”。以后很多团队里最能把 agent 用稳的人，未必是代码写得最快的人，往往是最会把任务讲清楚的人。

对 Agent Engineer 最像产品设计课的一面

这篇给 Agent Engineer 的提醒很实际。好系统不只是要提升 agent 本身的能力，也要降低操作者提出好任务、看懂中间状态和快速纠偏的门槛。

也就是说，agent 体验设计的一部分，其实就是操作者教育设计。系统如果只在高手手里好用，那它还远没有成熟。

今天就能试的一步

下次再让 coding agent 干活时，不要只写“帮我修这个问题”。多补三样东西：目标文件、不能改的部分、你最担心的失败点。然后看看它是不是一下子稳了不少。哪怕只是修一个登录页样式错位，这三样信息也常常比“请尽快修好”有用得多。

更新附注

• 版本：v1.1
• 更新日期：2026-03-20
• 更新原因：为系列文章补充统一阅读序号，方便读者在方法篇之后继续进入操作者视角。