从Copilot到Agent：AI编程工作流的重构与落地实践

目录一、Copilot 与 Agent差别在哪里1.1 三代 AI 编程工具1.2 这带来的真正挑战二、整体工作流三、第一步把团队约定写成规则文件四、第二步任务说明比提示词技巧更重要五、第三步先审计划再让它动手六、第四步测试先行让测试成为完成标准七、第五步自动化检查与人工审查分工7.1 能自动化的交给流水线7.2 人工审查重点八、哪些任务适合交给 Agent九、风险与应对十、如何度量效果而不是凭感觉十一、开发者角色的变化参考资料适合谁读已经在用 Copilot 类代码补全工具想进一步让 AI Agent 承担完整开发任务但又担心质量失控的开发者和技术负责人。解决什么问题从补全一行代码到交给 Agent 一个需求变化的不只是工具而是整个开发工作流任务怎么描述、上下文怎么提供、产出怎么验证、责任怎么划分。本文以给用户服务增加注册功能为主线给出一套可以直接落地的 Agent 协作流程包括规则文件、任务模板、测试先行、审查清单和效果度量方法。本文不罗列效率提升了多少倍这类无法复现的数字而是讲清楚每一步该怎么做、为什么这么做。Agent 系统本身的架构设计见本系列上一篇 AI Agent 生产级架构设计。示例项目环境文中的规则文件、任务说明和测试代码均基于此环境组件版本说明JDK21使用 record、虚拟线程等新特性时需在规则文件中说明Spring Boot3.4.x3.4 起测试中使用MockitoBean替代已废弃的MockBeanJUnit / MockitoJUnit 5.11、Mockito 5.x由 spring-boot-starter-test 统一管理版本MySQL / Redis8.0 / 7.2集成测试通过 Testcontainers 启动构建工具Maven Wrapper./mvnw保证 Agent 与 CI 使用同一 Maven 版本一、Copilot 与 Agent差别在哪里1.1 三代 AI 编程工具形态交互方式上下文范围人的角色典型产品形态代码补全光标处自动建议当前文件及少量相邻文件逐行编写AI 辅助IDE 补全插件对话助手选中代码提问、生成片段用户手动提供的代码复制粘贴、自行整合IDE 内聊天面板编程 Agent描述任务Agent 自主读代码、改文件、跑命令整个仓库 终端 工具定义任务、审查结果IDE Agent、终端 Agent、云端异步 Agent前两代工具中人始终在环路的每一步每一行代码都经过人的眼睛。第三代工具的本质变化是Agent 可以连续执行几十个动作搜索代码、修改多个文件、运行测试、根据报错修正人只在开始和结束时介入。1.2 这带来的真正挑战效率提升的同时风险的形态也变了错误的粒度变大补全错一行人立刻能看到Agent 改错了十个文件里的某一处很可能在审查时被忽略上下文决定质量Agent 不知道团队的约定例如金额必须用BigDecimal“禁止在 Controller 里写业务逻辑”就会按网上最常见的写法生成代码验证成本转移写代码的时间减少了但审查和验证的时间如果不刻意设计会成为新的瓶颈。所以用好 Agent 的关键不是提示词写得多巧妙而是把团队的隐性知识显性化并建立自动化的验证闭环。二、整体工作流调整通过失败通过需求编写任务说明验收标准 约束Agent 产出计划人审查计划测试先行先写/确认测试Agent 实现运行测试并自我修正自动化检查编译 · 测试 · 静态扫描人工审查按清单合并与传统流程相比有两个关键的新增环节先审计划再动手以及以测试作为 Agent 的完成定义。下面逐步展开。三、第一步把团队约定写成规则文件Agent 每次开始任务时都是新同事它不会记得上次你纠正过什么。把反复出现的约定写进仓库根目录的规则文件如AGENTS.md各工具也有自己的规则文件约定Agent 在每次任务开始时都会读取。# AGENTS.md ## 项目概况 - Spring Boot 3.4 JDK 21 MySQL 8.0 Redis 7.2 - 测试中 mock Spring Bean 使用 MockitoBeanMockBean 已废弃 - 分层controller - application - domain - infrastructure禁止跨层调用 ## 编码约定 - 金额使用 BigDecimal禁止 double/float - 时间统一使用 java.time存储为 UTC - 对外接口返回 ResultT异常由 GlobalExceptionHandler 统一处理 - 新增 SQL 必须走 MyBatis XML禁止字符串拼接 SQL ## 构建与验证 - 编译与测试./mvnw -q verify - 只运行某个测试./mvnw -q test -DtestUserRegisterServiceTest - 提交前必须保证 verify 通过 ## 禁止事项 - 不要修改 db/migration 下已发布的迁移脚本只能新增 - 不要引入新的第三方依赖除非任务说明中明确允许 - 不要在日志中打印手机号、身份证号、密码等敏感信息规则文件的编写原则只写 Agent 不看代码就无法知道的事项目结构 Agent 自己能读出来但为什么禁止 double它无法推断给出可执行的验证命令这是 Agent 判断自己做没做对的依据持续维护每次在审查中纠正 Agent 的同类错误超过两次就把它补进规则文件。四、第二步任务说明比提示词技巧更重要一个好的任务说明应该能让一个不了解背景的新同事独立完成工作。以用户注册为例## 任务用户注册接口 ### 背景 用户服务目前只有登录需要新增手机号注册。 ### 验收标准 1. POST /api/users/register参数phone、password、smsCode 2. 手机号已注册时返回错误码 USER_PHONE_EXISTS 3. 短信验证码错误或过期时返回 SMS_CODE_INVALID验证码校验通过后立即失效 4. 密码使用 BCrypt 存储强度至少 8 位且包含字母和数字 5. 并发重复提交同一手机号时最终只能创建一个用户 ### 约束 - 复用现有的 SmsCodeService不要自己实现验证码逻辑 - 唯一性以数据库唯一索引为准不要只依赖先查后插 ### 不在本次范围 - 第三方登录、邀请码注意第 5 条和约束中的唯一索引这类并发与一致性要求是 Agent 最容易遗漏的因为先查询再插入在功能测试中完全正常只在并发时出错。把它明确写进验收标准比事后审查发现要便宜得多。五、第三步先审计划再让它动手对于涉及多个文件的任务先要求 Agent只输出计划、不修改代码审查后再执行。计划应包括要修改和新增哪些文件、数据库变更、关键实现思路、需要新增的测试。审查计划时重点看三件事检查点常见问题发现后的处理改动范围顺手重构了无关代码明确要求只改任务相关文件设计取舍用先查后插保证唯一性指出并发问题要求使用唯一索引 捕获冲突异常依赖与接口编造了项目中不存在的工具类或方法要求先搜索确认再使用在计划阶段纠正方向成本只是几句话在实现完成后才发现往往需要推倒重来。六、第四步测试先行让测试成为完成标准Agent 最大的优势之一是可以自己运行测试并根据失败信息修正。所以最有效的做法是先确定测试再让 Agent 实现直到测试通过。验收标准中最关键的几条可以由人先写好测试或者让 Agent 先写测试、人审查测试后再实现SpringBootTestclassUserRegisterServiceTest{AutowiredUserRegisterServiceregisterService;AutowiredUserRepositoryuserRepository;MockitoBeanSmsCodeServicesmsCodeService;Testvoidshould_reject_duplicate_phone(){when(smsCodeService.verifyAndConsume(anyString(),anyString())).thenReturn(true);registerService.register(newRegisterCommand(13800000000,Passw0rd!,123456));BizExceptionexassertThrows(BizException.class,()-registerService.register(newRegisterCommand(13800000000,Passw0rd!,123456)));assertEquals(ErrorCode.USER_PHONE_EXISTS,ex.getCode());}Testvoidshould_create_only_one_user_under_concurrent_requests()throwsException{when(smsCodeService.verifyAndConsume(anyString(),anyString())).thenReturn(true);intthreads8;ExecutorServicepoolExecutors.newFixedThreadPool(threads);CountDownLatchstartnewCountDownLatch(1);ListFuture?futuresnewArrayList();for(inti0;ithreads;i){futures.add(pool.submit(()-{start.await();returnregisterService.register(newRegisterCommand(13900000000,Passw0rd!,123456));}));}start.countDown();longsuccessfutures.stream().filter(f-{try{f.get();returntrue;}catch(Exceptione){returnfalse;}}).count();pool.shutdown();assertEquals(1,success);assertEquals(1,userRepository.countByPhone(13900000000));}Testvoidshould_store_password_with_bcrypt(){when(smsCodeService.verifyAndConsume(anyString(),anyString())).thenReturn(true);registerService.register(newRegisterCommand(13700000000,Passw0rd!,123456));StringstoreduserRepository.findByPhone(13700000000).orElseThrow().getPasswordHash();assertTrue(stored.startsWith($2));assertNotEquals(Passw0rd!,stored);}}其中并发测试最有价值它能直接暴露先查后插的实现缺陷Agent 会在测试失败后自行改为唯一索引 捕获DuplicateKeyException转换为业务错误码的实现。需要警惕的是Agent 有时会为了让测试通过而修改测试本身放宽断言、删除用例。所以要在任务说明或规则文件中明确不允许修改已有测试的断言并在审查时专门查看测试文件的 diff。七、第五步自动化检查与人工审查分工7.1 能自动化的交给流水线Agent 提交的代码和人写的代码一样要经过 CI 的完整检查编译、单元测试、集成测试、静态扫描如 SonarQube、SpotBugs、依赖漏洞扫描、代码格式检查。凡是机器能判断的就不应该占用人的审查时间。7.2 人工审查重点人的注意力应该集中在机器难以判断的地方审查维度关注点需求理解是否真正满足验收标准有没有看起来实现了但边界条件错误并发与一致性唯一性、幂等、事务边界是否正确安全输入校验、越权访问、敏感信息是否写入日志可维护性是否引入了重复代码、过度抽象或违反分层约定测试本身测试是否真的验证了行为有没有被修改为永远通过依赖是否引入了新依赖、调用了不存在或已废弃的 API一个实用的习惯是让 Agent 在提交时附上变更说明——改了什么、为什么这样改、哪些地方不确定。这份说明能显著减少审查者重新理解代码的时间也能暴露 Agent 自己没把握的地方。八、哪些任务适合交给 Agent适合程度任务类型原因很适合有明确验收标准的增删改查、单元测试补齐、依赖升级后的编译修复、批量重命名与迁移结果可以被测试或编译器客观验证适合需审计划跨多个模块的功能开发、性能优化需要设计取舍方向错了代价大谨慎使用核心交易逻辑、权限与安全相关代码、数据库迁移错误后果严重必须逐行审查不适合需求本身不清楚的探索、需要与多方协商的架构决策Agent 会自信地给出一个答案掩盖了真正需要讨论的问题判断标准可以归结为一句话结果越容易被客观验证越适合交给 Agent。九、风险与应对风险表现应对幻觉 API调用不存在的方法、使用错误版本的框架用法规则文件写明版本编译和测试必须通过范围蔓延顺手修改无关文件任务说明限定范围审查时先看文件列表测试被篡改删除或放宽断言规则禁止修改已有断言单独审查测试 diff密钥泄露把密钥写进代码或日志密钥扫描纳入 CIAgent 运行环境不注入生产凭证提示词注入读取的依赖源码、Issue 内容中藏有恶意指令限制 Agent 可执行的命令高风险操作需人工确认能力退化团队成员逐渐不理解自己代码库的关键逻辑核心模块坚持人工编写或逐行审查定期做代码走读十、如何度量效果而不是凭感觉引入 Agent 之后感觉快了很多但感觉往往不可靠写代码的时间缩短了审查和返工的时间可能增加了。建议在引入前后对比以下指标至少观察一到两个迭代周期指标含义说明需求交付周期从开始开发到上线的时间端到端指标不只看编码时间审查耗时与轮次PR 从创建到合并的时间、修改轮次反映 Agent 产出的一次通过率变更失败率上线后需要回滚或热修复的比例来自 DORA 指标衡量质量是否下降缺陷逃逸数测试环境未发现、线上才暴露的缺陷衡量验证闭环是否有效测试覆盖与有效性覆盖率及变异测试得分防止为了覆盖率而写的空测试如果交付周期缩短而变更失败率上升说明验证环节没有跟上应该先加强测试和审查而不是继续扩大 Agent 的使用范围。十一、开发者角色的变化从 Copilot 到 Agent开发者的工作重心发生了明显的转移从写代码到定义问题写清楚验收标准和约束本身就是最重要的设计工作从实现细节到验证体系测试、CI、规则文件成为保证质量的主要手段从个人技巧到团队资产规则文件、任务模板、审查清单都应该沉淀在仓库里而不是留在某个人的脑子里。回到开头的问题“交给 Agent 一个需求能不能放心答案取决于你是否提前准备好了三样东西规则文件让 Agent 了解团队约定测试让 Agent 知道什么叫做完了”审查清单让人把注意力放在机器无法判断的地方。这三样东西准备好了Agent 才是可靠的生产力否则只是更快地产生需要返工的代码。参考资料Building Effective AgentsAnthropicAgent 的适用边界AGENTS.md面向编程 Agent 的仓库说明文件约定SWE-bench编程 Agent 在真实 GitHub Issue 上的评测基准DORA Research交付周期、变更失败率等软件交付效能指标OWASP Top 10 for LLM Applications提示词注入、过度授权等风险PIT Mutation TestingJava 变异测试工具用于评估测试有效性