从 Copilot 到 Agent：我的开发工作流正在被颠覆

前两年我用 Copilot，更多是把它当成一个“更聪明的代码补全”。

写一个函数，它帮我补参数；写一段注释，它帮我猜实现；写 React 组件，它能把useState、useEffect、接口类型一路顺下来。

那个阶段，AI 像是坐在副驾驶上的人。方向盘还在我手里，它偶尔提醒我“这里可以这样写”，我觉得省事，但谈不上颠覆。

真正让我感觉不一样，是最近开始把一些 Issue 丢给 Agent 之后。

以前我面对一个 Bug，大概是这样的流程：先读需求，再翻代码，再本地启动，再打断点，再改，再跑测试，再提 PR。中间任何一步卡住，都得自己切上下文。尤其是一些“不难但烦”的活，比如补单测、修边界条件、改文案联动、补空状态、处理 lint 报错，技术含量不高，但会吃掉很多碎片时间。

现在我会先问自己一句：这件事是不是一定要我亲手写？

如果答案是否定的，我就把它整理成一个 Issue，交给 Agent。

我现在给 Agent 的 Issue，通常不会写得很随便。以前我们给人派任务，可能一句“修一下列表分页问题”就完了，因为人会追问、会脑补、会结合业务经验判断上下文。但 Agent 不一样，它很能干，也很容易一本正经地走偏。

所以我会把 Issue 写成这样：

背景： 订单列表在筛选状态下，翻到第二页后切换筛选条件，页码没有重置，导致接口请求 page=2，页面为空。 期望： 切换任意筛选条件后，page 重置为 1，并重新请求数据。 范围： 只修改订单列表页相关逻辑，不调整接口结构，不改全局分页组件。 验收： 1. 切换状态筛选后 page=1 2. 切换日期筛选后 page=1 3. 保留原有分页切换能力 4. 补充或更新相关单测

这样的任务丢给 Agent，成功率明显比一句“修分页 Bug”高很多。

这也让我意识到，AI Agent 时代的核心能力，不是“会不会提问”，而是“会不会定义任务边界”。

PR 不再是我从零写出来的，而是我审出来的

以前一个 PR 的诞生路径很清晰：我写代码，我自测，我提交，我等别人 Review。

现在变成了：我写 Issue，Agent 出 PR，我 Review。

这个变化很微妙。

刚开始我会很不放心，总想把 Agent 改过的每一行都看一遍。后来我发现，真正重要的不是盯着它有没有写出“我会怎么写”的代码，而是看它有没有破坏系统原有的约束。

比如我 Review Agent 的 PR，会重点看几个地方：

第一，它有没有改超范围。

很多 Agent 最大的问题不是不会写，而是太积极。你让它修一个筛选 Bug，它顺手重构了列表状态；你让它补一个单测，它顺手调整了组件结构。代码看起来更“优雅”，但对真实项目来说，这种优雅有时候就是风险。

第二，它有没有理解业务语义。

技术上通过，不代表业务上正确。比如“订单取消”和“订单关闭”在 UI 上可能都是灰色，但在业务流转里完全不是一回事。Agent 很容易从命名和表象推断逻辑，但老系统里的很多规则，恰恰藏在历史包袱里。

第三，它有没有补对测试。

我不太喜欢那种“为了覆盖率而覆盖率”的单测。断言了一堆 DOM 是否存在，却没有覆盖真正的业务边界。Agent 写单测很快，但我会要求它围绕 Bug 本身补测试：原来会失败，现在应该通过。

慢慢地，我发现我的时间从“写实现”转到了“看设计是否合理、边界是否完整、风险是否可控”。

这不就是架构师和 Reviewer’s 工作吗？

写单测，是我最愿意交给 Agent 的事

如果说现在有什么开发任务最适合交给 AI Agent，我个人会选单测。

原因很简单：单测有明确输入输出，有现成上下文，也有即时反馈。Agent 写完之后，测试跑不跑得过，结果很直观。

我经常这样用它：

“请阅读这个组件和现有测试风格，为新增的筛选重置逻辑补充单测，不要重构组件代码。”

这句话里我会特意加上“阅读现有测试风格”。因为在团队项目里，测试代码最怕风格不统一。有的人喜欢data-testid，有的人喜欢按文本查找；有的人喜欢 mock hook，有的人喜欢 mock service。Agent 如果不先看现有写法，很容易写出一份“能跑但不像这个项目”的测试。

它补完以后，我一般只做三件事：

看测试名称是否表达业务意图。
看失败场景是否真的能暴露 Bug。
看有没有为了测试而修改生产代码。

第三点很关键。好的单测是验证代码，不是逼代码配合测试。

修 Bug：Agent 适合处理“局部明确”的问题

修 Bug 这件事，我现在会分层处理。

如果是样式错位、空值异常、状态没重置、接口字段兼容、表单校验遗漏，这类问题我比较放心交给 Agent。因为它们大多有清晰复现路径，影响范围也相对可控。

但如果是性能问题、架构问题、跨模块数据流问题，我不会直接让 Agent 自己改。我会先让它帮我做分析：

“请先不要修改代码，分析这个页面首次加载慢的原因，列出可能的瓶颈、涉及文件和验证方式。”

这个用法非常舒服。

以前排查问题，我要自己从入口文件一路翻下去。现在 Agent 可以先帮我扫一遍，把可能相关的组件、请求、缓存、渲染逻辑列出来。它的结论未必全对，但能帮我快速建立地图。

真正动手之前，我会让它停一下：

“先给出修改方案，不要提交代码。”

这个习惯很重要。Agent 越强，越不能让它一上来就大改。先让它讲方案，再决定要不要执行，这和带新人其实很像。

我越来越像一个任务拆解者

这段时间最大的感受是：开发的体力活在减少，但脑力活没有减少，只是换了形态。

以前我的价值更多体现在“我能不能把代码写出来”。
现在我的价值更多体现在“我能不能判断什么代码应该被写出来”。

这两句话差别很大。

一个成熟开发者，过去靠经验少写 Bug；现在还要靠经验防止 Agent 制造新的 Bug。

比如一个需求来了，我会先拆：

哪些可以交给 Agent？
哪些必须我自己设计？
哪些地方需要补文档？
哪些边界必须写进验收标准？
哪些改动必须拆成多个 PR？

我不再把 AI 当成“搜索答案的工具”，而是把它当成一个执行力很强、但需要明确上下文和边界的虚拟同事。

它不会累，不会嫌麻烦，补测试很快，改文档也快。
但它没有项目历史记忆，不知道某个奇怪判断背后曾经踩过坑，也不知道某个“看起来重复”的逻辑其实是为了兼容老客户。

所以我的角色变了。

我不是少工作了，而是从“写每一行代码的人”，变成了“决定哪些代码该存在的人”。

AI Agent 没有取代开发者，它取代的是低质量的开发流程

很多人问我，Agent 会不会让程序员不值钱。

我的感受刚好相反。它会让“只会等需求、写代码、交差”的开发方式越来越不值钱，但会让真正懂业务、懂架构、懂质量控制的人更值钱。

因为 Agent 可以快速产出代码，但它不能替你负责。

PR 合不合并，还是你负责。
线上出不出问题，还是你负责。
架构会不会越来越乱，还是你负责。
技术债是被清理还是被包装成“重构”，还是你负责。

AI Agent 把开发速度拉上来了，也把 Review 的重要性拉上来了。

以前代码写得慢，很多问题还没机会发生。现在代码生成得太快，如果没有边界、没有测试、没有审查，项目反而会更快变乱。

所以我现在越来越重视几件事：

Issue 写清楚。
任务拆小。
改动范围收窄。
测试必须跑。
PR 必须 Review。
重要逻辑必须人来拍板。

这套流程看起来慢，但它反而是让 Agent 真正可用的前提。

最后的真实感受

从 Copilot 到 Agent，我的工作流确实被改变了。

我不再满足于让 AI 帮我补几行代码，也不再把所有任务都攥在自己手里。很多过去我觉得“算了，我自己改吧”的小问题，现在会被我拆成 Issue，交给 Agent 去处理。

但我也越来越清楚，AI Agent 不是魔法。

它像一个速度极快的初中级开发，读代码很快，写代码很快，执行力很强，但需要你告诉它边界，需要你检查结果，需要你在关键位置做判断。

这对开发者其实提出了更高要求。

以前你写得快，是优势。
现在你拆得清楚、审得准确、守得住架构边界，才是优势。

AI 没有让我离代码更远。

它只是把我从“埋头写代码的人”，推向了“设计任务、控制质量、审查系统”的位置。

也许这就是下一阶段开发者的分水岭：

不是会不会用 AI，
而是能不能管理 AI 写出来的代码。