行业与业务背景从23年开始随着基础大模型的突破主流代码工具的迭代周期越来越快这些工具的创新持续推动整个研发效能提升。从最初的编译器代码补全、到Github Copilot代码助手、再到Cursor/Trae AI编程工具、再到Claude Code/OpenCode AI 编程代理工具一直都在极大的提升编码效率。而我们的业务场景和绝大多数团队面临的挑战一致金融系统承载资金的扭转、业务形态的多样化、需求迭代频繁、代码腐化风险高、团队协作密度大如何提升编码效率、保证代码质量、降低长期维护成本是我们使用AI工具的目标之一。1.2 演进历程总览入门期从编译器补全到Github Copilot 单个方法/函数的生成探索期Cursor/OpenCode Agent Coding全功能级代码生成成熟期Rules约束体系搭建建立AI的“项目规范”深水区SDD规格驱动开发的深度实践与边界探索本文将详细分享下我的使用历程、实践经验希望能给大家有所启发二、第一阶段入门期——代码智能补全与单方法改写这是我接触AI编码的起点核心是基于Github Copilot / 通义灵码 的代码智能补全能力解决局部代码的编写与优化问题。2.1 核心使用场景主要在两个高频场景使用也是所有人最容易上手的AI编码场景场景1标准化代码自动补全针对对象构建、模型转换等重复度极高的CRUD代码通过少量代码引导或者写好注释让AI完成全量补全示例如下// 开发者输入构建商品卡片注释 // AI自动补全以下代码 public ListItemCardVO buildItemCards(ListContentEntity entities) { ListItemCardVO result new ArrayList(); for (ContentEntity entity : entities) { ItemCardVO itemCard new ItemCardVO(); itemCard.setItemId(entity.getItemId()); itemCard.setItemTitle(entity.getTitle()); itemCard.setItemImg(entity.getPicUrl()); result.add(itemCard); } return result; }场景2单方法重构与优化针对冗长、可读性差的历史方法通过AI完成代码精简、规范对齐、逻辑优化示例如下// 原始代码冗长难读冗余校验 public String getDiscountText(Long finalPrice, Long nnPrice) { if (finalPrice null || nnPrice null) { return ; } if (finalPrice nnPrice) { return ; } Long discount finalPrice - nnPrice; if (discount 0) { return ; } String discountYuan String.valueOf(discount / 100.0); return discountYuan 元; } // AI重构后简洁优雅规范统一边界清晰 public String getDiscountText(Long finalPrice, Long nnPrice) { if (finalPrice null || nnPrice null || finalPrice nnPrice) { return ; } Money discount Money.ofFen(finalPrice).subtract(Money.ofFen(nnPrice)); if (discount.getCent() 0) { return ; } return String.format(%s元, discount.getYuan()); }2.2 收益效率提升在日常项目中代码补全在对象构建、模型转换场景减少40%-50%的键盘输入单方法重构速度提升50%。体验优化大幅减少API文档查找时间避免拼写错误、语法错误等低级问题让大家更聚焦于业务逻辑本身。当年2023年使用的时候实属惊艳2.3 暴露的核心问题这个阶段的能力本质是“局部优化”很快就遇到了无法突破的瓶颈能力边界局限仅能完成单个方法或代码片段的生成无法理解整体业务逻辑更无法处理跨类、跨模块的完整需求。上下文缺失不了解项目的架构规范、代码风格、团队约定生成的代码往往和存量代码格格不入。三、第二阶段探索期——Cursor/OpenCode全功能生成在24年到到现在由于生成式大模型的发展以及Cursor/Trae、Claude Code/OpenCode等编程工具的出现。我们希望AI不仅能帮我们完成‘局部优化’而是让AI从“补全代码”升级为“实现完整功能”也就是Agent Coding模式。3.1 核心落地方法我们基于Cursor Sonnet4.5/GPT模型通过对话构造不同的Prompt给AI明确的需求、背景、实现要求、技术细节约束让AI一次性生成完整的模块代码。Prompt描述需求用户查账记账功能 背景 - 业务背景 要详细描述 实现要求 1. 实现/manualAdjust接口方法和请求参数类 2. 查询账户、计算余额、更新账户、插入流水 3. 测试功能 具体细节 1. 用 DemoAccountMapper 查询条件user_no stk_ 企业ID product_second_type_code 0101 2. post_balance pre_balance - change_balance 3. 如果 post_balance 0记录错误日志并跳过此用户后续所有步骤直接跳过 4. 更新 demo_user_account 表balance post_balance 5. 等等 请生成完整的代码。AI生成的完整代码示例基于上述PromptAI可一次性生成全链路代码覆盖接入层、服务层、数据层等全流程// 1. 接入层实现 GetMapping(/manualRepairOrder) public CommonResultObject testGetOrderListForPageQuery( RequestParam(value orderNo, required false) String orderNo) { manualRepairOrder(Arrays.asList(orderNo)); return CommonResult.success(); } // 2. service层实现 private void manualRepairOrder(ListString testOrderList) { if(org.apache.commons.collections4.CollectionUtils.isNotEmpty(testOrderList)) { for(String orderNo : testOrderList) { OrderRecordListQueryPO queryPo new OrderRecordListQueryPO(); queryPo.setOrderNo(orderNo); queryPo.setStatusList(Arrays.asList(OrderStatusEnum.SUCCESS.getValue().intValue(), OrderStatusEnum.PROCESSING.getValue().intValue())); // 示例产品线A queryPo.setProductSecondCode(1234); PageHelper.startPage(1, 1); PageInfoOrderRecordPO pageInfo new PageInfo(orderRecordRepository.getOrderListForPageQuery(queryPo)); log.info([订单修复]查询订单返回订单号{}结果{}, orderNo, JSON.toJSONString(pageInfo)); if(org.apache.commons.collections4.CollectionUtils.isEmpty(pageInfo.getList())) { continue; } OrderRecordPO orderRecordPO pageInfo.getList().get(0); repairOneOrder(orderRecordPO); } return; } int pageNum 1; int pageSize 20; while (true) { OrderRecordListQueryPO queryPo new OrderRecordListQueryPO(); queryPo.setStatusList(Arrays.asList(OrderStatusEnum.SUCCESS.getValue().intValue(), OrderStatusEnum.PROCESSING.getValue().intValue())); // 示例产品线A queryPo.setProductSecondCode(1234); PageHelper.startPage(pageNum, pageSize); PageInfoOrderRecordPO pageInfo new PageInfo(orderRecordRepository.getOrderListForPageQuery(queryPo)); log.info([订单修复]查询订单返回pageNum:{}, pageSize:{}, 结果{}, pageNum, pageSize, JSON.toJSONString(pageInfo)); if(org.apache.commons.collections4.CollectionUtils.isEmpty(pageInfo.getList())) { break; } for(OrderRecordPO orderRecordPO : pageInfo.getList()) { repairOneOrder(orderRecordPO); } pageNum; try { TimeUnit.MILLISECONDS.sleep(50); } catch (InterruptedException e) { log.error(修数时线程休眠异常, e); } } }3.2 落地收益Agent Coding实现了开发效率的阶跃式提升通过Prompt驱动的自动代码生成替代了传统的全手动编写虽然Prompt设计需要额外投入时间但综合开发效率仍有非常显著的提升。3.3 快速暴露的致命问题在后续的需求迭代中这套模式的问题快速暴露甚至带来了更高的维护成本核心集中在3个方面问题1代码延续性极差同一个业务场景显然都能实现示例如下// 第一次生成简洁风格 private String buildDiscountText(Money discount) { return String.format(省%s元, discount.getYuan()); } // 第二次生成冗长风格 private String buildDiscountText(Money discount) { BigDecimal yuan BigDecimal.valueOf(discount.getCent()) .divide(BigDecimal.valueOf(100), 2, RoundingMode.HALF_UP); String yuanStr yuan.stripTrailingZeros().toPlainString(); return 省 yuanStr 元; }直接影响同一个项目内类似功能的实现方式五花八门代码腐化速度极快长期维护成本指数级上升。问题2代码风格与团队规范严重脱节AI不了解项目沉淀的代码规范、架构模式、命名约定生成的代码和存量代码风格不一致每次都需要人工大量修改反而增加了工作量。问题3AI不理解业务生成的代码不符合要求受限于AI上下文大小AI在编写老项目的时候并不理解代码背后的具体业务。一些同学可能把详细的业务全部喂给AI导致可能自己写代码反而更快一些同学可能简单描述下生成的代码需要大量修改甚至推倒重做本质上是每一个窗口就是一个‘干净’的上下文AI并不清楚每一行代码背后的业务逻辑、整个项目的背后业务。3.4 根因分析这些问题的本质不是AI能力不足(AI上限极高、天才型选手)而是我们没有给AI建立项目专属的上下文和约束没有统一的项目规范AI不知道项目的代码风格、架构模式、命名规范没有沉淀的领域知识AI不了解业务的特定术语、设计模式、边界规则没有可复用的历史经验每次生成都是“零基础”无法从历史代码和最佳实践中学习。基于这个根因因此我逐渐进入了第三个阶段通过Rules约束、AGENT业务描述、给AI建立一套完整的“项目规范”。四、第三阶段成熟期——Rules约束、建立AI的“项目规范”这个阶段的核心目标是把团队的项目规范、架构模式、领域知识背后业务通过标准化的Rules文件固化下来让AI的所有生成行为都在这套规则的约束内执行。 (注意受限于上下文rules不是越多越好尽量保证在500行以内)4.1 核心Rules文件内容示例1. 代码风格/编程规范# 编程规范 ## 命名风格 - 类名UpperCamelCase抽象类以 Abstract/Base 开头异常类以 Exception 结尾测试类以 Test 结尾 - 方法名/参数/变量lowerCamelCase常量UPPER_SNAKE_CASE - 枚举类名加 Enum 后缀成员全大写下划线分隔POJO 布尔字段不加 is 前缀 - 领域模型xxxDO数据对象/ xxxDTO传输对象/ xxxVO展示对象禁用 xxxPOJO - Service/DAO 方法前缀get单个/ list多个/ count统计/ save/insert插入/ remove/delete删除/ update修改 ## 常量 - 禁止魔法值直接出现在代码中必须先定义常量 - long/Long 赋值使用大写 LLong cnt 25L; ## 注释 - 类、类属性、类方法必须用 /** */ Javadoc 规范禁用 // 替代 - 方法内部单行注释用 //多行用 /* */与代码对齐 - 所有枚举字段必须有注释说明用途 - 所有抽象方法含接口方法Javadoc 需说明功能、参数、返回值、异常 ## OOP - 使用 constant.equals(obj) 或 Objects.equals(a, b)防止 NPE - POJO 类属性必须使用包装类型RPC 返回值和参数必须使用包装类型局部变量推荐基本类型 - 构造方法禁止包含业务逻辑初始化逻辑放 init() 方法 ## 集合 - 禁止在 foreach 中 remove/add使用 Iterator 操作 - 去重操作优先使用 Set而非 List.contains() 遍历 - Collections.EMPTY_LIST 仅作标志不可 add/get - 集合相关的尽量使用apache相关的API, 禁止使用hutool的任何API ## 并发 - 线程必须通过线程池管理禁止显式 new Thread() - 线程池必须用 ThreadPoolExecutor 创建禁止 Executors 工厂方法防 OOM - 多资源加锁保持一致顺序遵循一锁、二判、三更新、四释放原则 ## 异常处理 - 可预检查的异常NPE、越界等用条件判断规避不用 try-catch - 禁止用异常做流程/条件控制 - catch 后必须处理或向上抛出禁止空 catch - 级联调用 a.getB().getC() 需防 NPE推荐使用 Optional ## 代码质量强制 - 方法不超过 80 行绝对不超过 100 行 - 禁止重复代码、过大类、过长参数列每个函数只做一件事 - 不依赖 SNAPSHOT 包无特殊情况 - 金额统一用 BigDecimal(String) 构造禁用 BigDecimal.equals() 比较金额 - DB/后端交互金额单位为分前端展示为元 - 除非特殊情况不能在代码里面直接写org.apache.commons.collections4.CollectionUtils.xxx, 应该直接引入import xxx ## 安全与稳定性 - 对前端入参低信任后端必须独立校验 - 涉及个人数据接口必须有鉴权敏感数据按加解密规范处理 - 接口调用必须配置合理超时时间不使用框架默认值 - Redis 操作做好异常处理避免抖动影响主链路 - 对三方回调保持低信任考虑不回调、多回调、错误回调场景 - 资金出入链路仅明确终态错误码才可做终态处理否则查询接口或等回调2. 项目结构规范每个项目特有的会用最优秀的模型初始化让AI理解这个项目是做什么业务的解决什么问题的以示例管理台为例# Project Context ## Purpose XFP金融业务管理后台系统xfp-A-console为星辰科技集团提供统一的金融信贷管理接口服务。系统主要面向运营人员、财务人员、风控人员等内部用户提供产品配置、订单管理、额度管理、结算管理、资产处理等金融业务的完整管理功能。 核心目标 - 提供金融产品计划A、计划B、计划C等的全生命周期管理 - 支持多渠道、多角色的业务操作和数据权限控制 - 实现与集团内部多个金融系统的集成和协调 ## Tech Stack ### 核心框架 - Java 1.8 - Spring Boot 2.2.6.RELEASE - Maven 多模块项目 ### 星辰科技内部框架 - nova-boot-parent 2.10.1.RELEASE星辰科技统一 Spring Boot 基础框架 - StarRPC 2.10.1.RELEASEgRPC 框架用于服务间 RPC 通信 - nova-jaf-monitor-starter监控组件 ### 数据访问层 - MyBatis Plus 3.4.2 - MyBatis Spring Boot Starter 2.1.3 - PageHelper 1.3.0分页插件 ### 中间件与配置 - Apollo配置中心支持多环境配置动态更新 - Redis多数据源配置ARedis, stringARedis - Redisson分布式锁 - Kafka多源生产者和消费者用于日志审计、保单通知等 - RabbitMQ消息队列 ### 工具库 - Hutool 5.8.25Java 工具库 - Lombok 1.18.20代码生成 - EasyExcel 3.1.0Excel 导入导出 - GuavaGoogle 工具库 ### API 文档 - Swagger2 - Knife4jSwagger UI 增强 ### 测试 - Groovy用于测试脚本test 模块包含 148 个 .groovy 文件 ## Project Conventions ### 代码风格 - 包命名cn.startech.xfp.finance.console.{module} - 命名规范 - Controller 层XxxController - Service 层XxxService/XxxServiceImpl - BOBusiness ObjectXxxBO - VOView ObjectXxxVO - Req/RspXxxReq/XxxRsp - EnumXxxEnum - 注释要求使用中文注释包含业务说明和关键逻辑说明 - 日志规范使用 Slf4j关键操作记录入参和结果 - 常量管理统一在 common 模块的 constant 包下定义 ### 架构模式 采用分层架构Maven 多模块设计 text xfp-finance-console (父工程) ├── xfp-finance-console-common # 公共模块常量、枚举、工具类 ├── xfp-finance-console-dal # 数据访问层Mapper、Entity ├── xfp-finance-console-facade # 对外接口层RPC 接口定义 ├── xfp-finance-console-provider # 服务提供者Controller、启动类 ├── xfp-finance-console-integration # 集成层调用外部服务 ├── xfp-finance-console-service # 业务服务层Service 实现 └── xfp-finance-console-test # 测试模块Groovy 测试 **关键架构决策** - Web 层与 Service 层使用 BO 对象传递数据避免直接使用 VO 或 Entity - RPC 服务使用 StarRPC (gRPC) 框架扫描指定包下的服务实现 - 使用 Apollo 配置中心管理多环境配置配置命名空间application, business, overdueSmsConf, rolePrivilegeConf 等 - 多数据源 RedisfinanceRedis 使用 Jackson 序列化stringFinanceRedis 使用 String 序列化 - 统一异常处理使用 FinanceServiceException 和 BizResult 枚举 ### 测试策略 - 使用 Groovy 编写测试用例test 模块 - 单元测试覆盖核心业务逻辑 - 集成测试验证外部服务调用 - 测试环境使用独立的 Apollo 配置和数据库 ### Git 工作流 - 主分支main/master - 开发流程功能分支 → 提测 → 合并主干 - 提交信息简洁描述变更内容关联 JIRA/禅道任务编号 - 版本号管理使用日期版本号如 20251222_01 ## Domain Context ### 业务领域 **核心业务模块** 1. **产品管理catalog**金融产品配置包括计划A、计划B、计划C等产品的参数配置 2. **订单管理workflow**订单全生命周期管理申请、审批、处理、结算 3. **额度管理limitcenter**用户额度申请、审批、调整 4. **结算管理settlement**结算计划、结算记录、逾期管理、催收 5. **账户管理profile**个人账户、企业账户、员工管理、角色权限 6. **渠道管理gateway**渠道配置、渠道关系管理 7. **保障管理coverage**场景保障单的创建、变更、处理 8. **资产处理archive**逾期资产的处理流程 9. **方案中心planhub**产品方案的特殊业务逻辑 10. **账务管理ledger**账单生成、账单查询 11. **签章管理stamp**电子印章和合同签章 12. **运营管理campaign**活动和权益配置 **关键业务概念** - 二级产品分类计划APLAN_ALPHA、计划BPLAN_BETA、计划CPLAN_GAMMA、计划DPLAN_DELTA - 产品状态启用ENABLE、禁用DISABLE、草稿DRAFT - 用户类型运营用户、场景用户ASCENARIO_USER_A、门店用户、渠道用户 - 角色体系超级管理员、业务超级管理员、贷后主管、门店用户、渠道用户、催收专员等 **数据权限** - 基于角色的权限控制RBAC - 渠道级数据隔离不同渠道用户只能看到自己渠道的数据 - 操作审计关键操作记录到 Kafkasec_xfp_finance_log_audit ## Important Constraints ### 技术约束 - Java 版本固定为 1.8不可升级到更高版本公司标准 - 必须使用星辰科技内部框架nova-boot、StarRPC - 配置必须通过 Apollo 配置中心管理禁止硬编码 - 敏感操作必须记录审计日志到 Kafka - 文件上传限制最大 100MB ### 业务约束 - 金融产品配置变更需要经过审批流程 - 涉及金额计算必须使用 BigDecimal禁止使用 float/double - 订单状态流转必须符合状态机规则 - 数据权限必须严格校验防止越权访问 - 逾期数据涉及催收业务需特别关注合规性 ### 监管约束 - 用户隐私数据手机号、身份证号等必须脱敏展示 - 金融数据保留期限不少于 5 年 - 操作日志必须完整记录支持审计追溯 ## External Dependencies ### 内部服务通过 StarRPC RPC 调用 - **nova-finance-aurora**产品方案服务facade: 20251110_01 - **nova-finance-orbit**场景方案服务facade: 20251222_01 - **nova-finance-harbor**结算服务facade: 20251222_01 - **nova-finance-vector**额度服务facade: 20251222_01 - **nova-finance-pulse**订单服务facade: 20251211_01 - **nova-finance-anchor**协议服务facade: 20251201_01 - **nova-finance-shield**策略服务facade: 20251201_01 - **nova-finance-atlas**资产服务facade: 20251223_01 - **xfp-finance-profile**账户服务facade: 20251119_01 - **xfp-finance-mosaic**保障服务 - **xfp-finance-breeze**运营服务facade: 20240801_01 - **xfp-finance-insight**数据服务facade: 20251204_01 ### 基础设施 - **Apollo 配置中心**http://10.0.0.1:8080本地开发环境 - **Redis**ci-resource-id: redis.xfp-novafinance-core-api - **Kafka** - 生产者主题sec_xfp_finance_console_svc_log_audit日志审计、demo_operate_record_topic业务事件 - 消费者主题demo_async_notify_topic异步通知 - **RabbitMQ**ci-resource-id: rabbitmq.finance_msg_queue - **Maven 私服**https://maven.startech.work/repository/ ### 第三方服务 - **OSS 文件存储**用于文件上传和下载通过 EnableObjectStorageClient 启用 - **短信服务**通过 MessageFacadeService 调用 - **OCR 服务**用于证件识别 ### 运行时依赖 - 服务端口8093 - 数据库通过 Apollo 配置支持多环境DEV/STG/PRE/PRD - MyBatis Mapper 扫描路径cn.startech.xfp.finance.console.dal - SOA Provider 扫描包cn.startech.xfp.finance.console.service.core.rpc, cn.startech.xfp.finance.console.web.core.*.rpc3. 功能实现规范 (按需)主要给AI一个模板一个合格优秀的功能应该怎么实现# 功能实现规范 ## 数据服务层 - 必须实现 Service 接口 - 使用 Component 注解 - 调用下游服务必须在integration 示例 java Component public class AConfigServiceImpl implements AConfigService { Override public BasePageRspGuaranteeBlacklistDetailRsp pageGuaranteeBlacklist(GuaranteeBlacklistListReq req) { // 实现逻辑 } } ## 接入层 xxxxx4. 主/子AGENT因为模型问答越后面token越贵AI也会变得越来越‘智障’因此建议使用子agent来减少主agent的消耗让AI一直保持‘聪明’状态。--- description: 智能使用子agent明确何时需要、何时不需要及如何传递上下文 alwaysApply: true --- # 子Agent智能使用规则 ## 核心原则 **基于任务复杂度、并行性和专业性智能决策是否使用子agent。** 避免过度拆分导致上下文丢失也避免主会话承载过重任务。 ## 决策标准 ### 必须使用子agent | 场景 | 子agent类型 | 判断标准 | |-----|------------|---------| | 大范围代码探索 | explore | 不熟悉代码库 / 搜索多目录 / 理解整体架构 | | 并行独立任务 | 多个并行 | 互不依赖的模块 / 可同时进行的探索或测试 | | 专项能力 | shell/browser-use | 复杂git操作 / 浏览器测试 / 隔离实验 | | 超大任务 | generalPurpose | 100次工具调用 / 10个文件 / 完整模块开发 | ### 主agent直接处理 **代码修改**1-5个已知文件、单个方法/类、已定位bug、配置调整 **搜索查询**精确匹配类名/方法名、已知文件查找、特定错误消息 **验证检查**linter错误、命名规范、git状态 **简单任务**2-4步顺序操作、10次工具调用 ### 紧密上下文优先原则 **需要紧密上下文时主agent保持连续性** - 迭代调试记住上次错误和尝试 - 基于前一步结果立即决策 - 用户交互式指导 - 步骤间强依赖 **示例**修改代码 → 检查linter → 修复错误主agent连续执行 ## 快速决策检查表 启动子agent前检查任一项是则考虑子agent - [ ] 涉及5个文件或5步操作 - [ ] 需要大范围搜索或代码探索 - [ ] 需要专项能力shell/browser/隔离环境 - [ ] 有多个独立任务可并行 - [ ] 步骤松耦合且不需立即基于上一步决策 **全部否** → 主agent直接处理 ## 信息传递规范 ### Prompt结构模板 text 任务目标[一句话描述] 背景项目类型 / 相关目录 / 已知信息 具体要求 1. [步骤1] 2. [步骤2] 预期返回 ## [标题1] - [信息项] ## [标题2] - [信息项] ### 必需信息清单 - [ ] 任务具体目标不是笼统的分析 - [ ] 背景信息项目结构、技术栈 - [ ] 范围限定目录、文件、关键词 - [ ] 预期输出格式 - [ ] 约束条件只读/可写 ### 避免信息丢失 **子agent返回后** - 主agent明确总结关键发现 - 启动下一子agent时完整传递前序结果 ## 典型案例 ### 案例1: 简单功能主agent **任务**UserController添加查询余额接口 **执行**并行读取3个文件 → 添加方法 → 检查linter **原因**已知文件、简单关联、10次调用 ### 案例2: 线上bug混合 **执行** 1. explore子agent查询日志返回错误摘要/文件位置/调用链 2. explore子agent定位代码返回片段/依赖/修复建议 3. 主agent基于建议执行修改 4. shell子agent提交MR **原因**1-2需探索、3需上下文、4是独立操作 ### 案例3: 大型功能多子agent **任务**权限管理系统 **执行** 1. 并行2个explore探索现有代码 数据库结构 2. 主agentPLAN模式设计方案 3. 并行3个generalPurpose后端模块 拦截器 测试 4. 主agent审查集成 ## 子agent类型选择 | 类型 | 适用场景 | 传递重点 | |-----|---------|---------| | explore | 代码探索、搜索 | 关键词、目录、探索深度 | | generalPurpose | 复杂多步骤 | 完整需求、约束、预期 | | shell | Git、命令 | 具体命令、错误处理 | | browser-use | 浏览器测试 | 场景、交互步骤 | ## 常见错误 **❌ 过度拆分**修改端口 → 启动子agent读 → 启动子agent改 **✅ 正确**主agent直接读取并修改 **❌ 上下文断裂**子agent1找路径 → 主agent未保存 → 子agent2不知道 **✅ 正确**子agent1返回后主agent总结 → 传递给子agent2 **❌ 类型错误**探索代码用generalPurpose **✅ 正确**探索用explore专门优化 ## EXECUTE模式决策 **简单计划**2-4步、文件明确、紧密关联→ 主agent **复杂计划**5步、大范围、并行任务→ 子agent ## 平衡原则 1. 简单任务 → 主agent避免过度工程 2. 复杂探索 → explore子agent专业优化 3. 并行任务 → 多子agent提高效率 4. 超大任务 → generalPurpose子agent避免上下文爆炸 5. 紧密上下文 → 主agent连续减少信息丢失 **记住**子agent是工具不是目的目标是高效完成任务。4.2 落地收益所有生成的代码都遵循统一的命名规范 基本不存在两个一样的提示词生成的代码千差万别项目结构清晰模块划分明确代码风格保持一致代码实现时间从1天降低到2~3小时需要人工检查、收尾4.3 依旧存在的问题虽然Rules带来了显著改善但仍存在一些问题需求理解不够深入AI仍然是基于技术方案/Prompt翻译成代码对业务语义理解有限。如果业务描述不够清晰方向还是会走偏文档滞后代码变更后AGENT文档更新容易遗漏依赖关系管理对于复杂的模块依赖关系多服务情况AI处理不够智能五、第四阶段深水区——SDD规格驱动开发的深度实践今年初开始初步尝试SDDSpecification Driven Development规格驱动开发当时使用的是OpenSpec框架。5.1 什么是SDDSDD 是一种以“规范为先”的软件开发范式。其核心理念是在让 AI 编写任何代码之前必须先定义结构化的规格说明文档Specification。单一真理源规格文档被视为整个开发流程的唯一准则驱动后续的设计、实现、测试和部署。流程闭环它将模糊的自然语言想法通过结构化流程转化为清晰的需求和任务最终由 AI 生成可验证的高质量代码。也就是之前程序员开发是面向代码现在SDD开发是面向规格文档 有点像plan模式的大号版本就像30年前大家开发是面向汇编现在开发是面向编程语言未来可能是规格文档5.2 使用流程openspec init 创建项目的“宪法”文件。它包含项目的技术栈、编码准则和愿景。这是 AI 每次生成代码前必须遵循的全局约束。/opsx:propose 创建一个预案 创建4-5个文件/opsx:apply 执行预案严格执行task任务/opsx:archive 归档预案确保长期可维护性5.3 带来的收益代码层面所有代码都严格遵循规格说明消除了理解偏差 甚至可以在心中忘记有代码这一个东西永远面向文档不同开发者实现相同规格代码风格完全一致代码变更时必须先更新规格保证文档与代码同步业务层面产品、开发、测试对需求的理解高度一致。因为必须要有文档才能实施。减少了需求理解偏差导致的返工测试覆盖自动生成的测试用例覆盖了所有正常和异常流程测试用例与规格说明一一对应确保完整性边界条件和异常场景都有明确的测试用例文档层面规格说明就是最准确的文档任何变更都先更新规格再同步代码新人通过阅读规格说明就能快速理解功能5.4 SDD的问题与挑战问题1规格编写门槛高非常重新手写不好投入产出比低新手往往写不好规格过于技术化或过于模糊不合格的规格对后面的代码实现影响影响 对于简单需求写规格的时间甚至超过直接写代码。问题 2SDD工具链不成熟老项目集成困难新老代码混杂维护成本高我们的代码库已经有大量历史代码SDD更适合从零开始的新项目历史代码缺乏规格说明无法纳入SDD体系新老代码风格混杂维护成本反而增加可能一部分人用SDD一部分人用传统方式协作困难问题 3学习成本高写出合格的第一份规格说明平均需要3-5次迭代非常的麻烦写完一份合格的提案可能代码已经写完了因此大家可以去实践尝试理解SDD的思维但暂时不建议大家使用。六、总结与展望AI Coding 从来不是来替代后端工程师的而是在编码阶段来释放我们的生产力。它能帮我们摆脱重复的工作让我们有更多的时间和精力聚焦于业务理解、架构设计、业务创新与技术难点上面。可以预见的是未来随着基础模型的突破、上下文的增强、工具的创新可能以上都不再是问题。最后希望本篇文章可以给大家有所启发找到适合自己的 AI 编码方式谢谢大家。ps. 以上部分内容由AI生成七、附录参考Claude Code OpenSpec 正在加速 AICoding 落地从模型博弈到工程化的范式转移得物技术AI编码实践从Vibe Coding到SDDhttps://github.com/Fission-AI/OpenSpecGitHub - anomalyco/opencode: The open source coding agent. · GitHub免责声明本内容来自平台创作者博客园系信息发布平台仅提供信息存储空间服务。好文要顶 关注我 收藏该文 微信分享​编辑程序员博博粉丝 - 95 关注 - 21加关注00« 上一篇 我的2025总结 - 普通但不失收获» 下一篇 花了一晚上AI Coding 在不熟悉的领域使用AI帮同事解决了跳槽的小问题posted 2026-04-25 18:37 程序员博博 阅读(358) 评论(3) 收藏 举报