Code-First 与 Agent-First 的分工边界

真正容易让人纠结的，不是该选 Code-First 还是 Agent-First，而是一个任务究竟处在“编辑”还是“委派”的边界上。两者看似都能改代码，承担的却不是同一种工作：前者放大开发者已经形成的判断，后者则试图接手一段尚未厘清的调查过程。

当你已经定位到函数，知道问题大概如何修，也清楚改完该看什么结果时，Code-First 往往更合适。此时让 AI 补全、重写局部逻辑、解释陌生写法，节奏会很顺。人仍盯着编辑器里的每一处变化，架构取舍和业务语义没有离开自己的视线。对小范围重构、明确报错或重复性修改来说，额外启动一轮检索、规划和执行，反而可能显得绕。

但如果手里只有一个现象，例如某项行为在特定条件下异常，却不知道入口、调用链和状态变化藏在哪里，任务就开始越过 Code-First 的舒适区。这里最费时间的通常不是写出修复代码，而是建立证据链：哪些模块相关，哪种猜测更值得先验证，第一次尝试失败后该往哪里继续查。Agent-First 的价值，正在于把这些零散步骤串成一个可迭代的任务循环。

不过，适合委派不等于适合放手。跨文件修改的风险并不只在于改错，还在于它可能用一段看似周全的兼容逻辑掩盖真正的问题，或者为了通过现有测试而改变不该改变的业务语义。因此，给智能体的任务描述最好不是一句“修好它”，而应包含不可触碰的范围、预期行为和验收方式。它应当先说明调查路径，再提出改动；修改完成后，也应能交代影响范围与验证依据。

一个实用的判断方法是看开发者是否已经能回答三个问题：改哪里、为什么这么改、怎样确认它有效。三个答案都明确，就让 Code-First 加速手上的编辑；若其中任何一个仍模糊，尤其是根因可能跨多个模块时，Agent-First 更值得介入。

最终，分工边界并非由某个产品名称决定，而是由任务的不确定性决定。Code-First 适合人在驾驶时的快速协作，Agent-First 更像把一段排查工作交给副驾驶。真正成熟的用法，也许不是二选一，而是在调查完成后重新回到人的判断与审阅之中。