把开发习惯交给Qoder这件事我想了很久才动手。以前用AI写代码都是问一句答一句让它生成一个接口它给一段能用但不完全符合我风格的代码让它重构一个模块它改完我反而要花更多时间review。问题不在于AI不够强而在于我从来没有把我是怎么工作的告诉它。直到我决定换个思路——与其把Qoder当成一个随叫随到的代码生成器不如把它当成一个需要带教的新同事。新人入职要学公司的代码规范、目录约定、提交习惯AI凭什么不需要于是有了这个系列的第一篇怎么从零开始把我自己的开发习惯一点点交给Qoder然后让它陪我从零搭出一个Spring Boot 3.5的脚手架。这篇分享适合所有想把AI编程工具用深一层的人不只是会用而是让它真正接手一部分日常工作。1. 数字同事和免费AI助手之间差的是一套习惯先说一个我观察到的现象。很多人包括一年前的我用AI编程工具状态是这样的遇到不会写的代码复制报错进去问要写个CRUD描述几句让它生成不满意就继续改提示词。用完关掉下次再问AI什么也不记得又是一轮从零开始。这种用法不能说没用但它本质上还是搜索引擎加强版——AI没有积累你也没有积累每次对话都是陌生人见面。真正让我意识到问题出在哪的是一件小事。我的项目里统一用Result 包装接口返回值这是团队约定。某天我让AI帮我写一个新的查询接口它老老实实返回了裸数据。我说按项目规范来它道歉然后改对了。再下一次换一个会话它又返回裸数据。那一刻我忽然明白我在反复教它一件我早就知道的事但AI根本没有记忆于是它每次都在等我把规则再说一遍。这不是AI笨是我的工作方式有问题——我没有给AI建立一个入职档案。所谓教AI上班本质上就是把一个开发者的隐性知识显性化。你的代码风格、你偏好的分层方式、你习惯的异常处理策略、你常用的工具类库、你写提交信息的方式这些在你脑子里可能不算什么但对于一个没有任何背景的AI来说都是需要明确告知的规则。Qoder这类工具之所以能成为数字同事而不是聊天机器人关键就在于它有没有一套吸收这些规则、然后持续遵守这些规则的机制。那具体怎么落地我的做法分三层项目级规则在项目根目录放规则说明把代码风格、目录结构、依赖选型这些写在明面上每次让Qoder读一遍再动手。会话级上下文每次开始一个任务前不要急着让它写代码先把任务背景、涉及文件、验收标准描述清楚把聊天当任务工单而不是闲聊。经验级沉淀凡是踩过坑、返过工的地方把原因和正确做法总结下来回填到规则里。教AI和带新人的区别就在这——新人能自己悟AI永远等你喂。这一篇讲的就是第一层和第三层的完整落地过程用搭建Spring Boot 3.5脚手架作为第一个实战任务。为什么选脚手架因为它规则性强、样板代码多、覆盖面广——从目录结构到依赖管理从异常处理到统一返回正好可以逼着我把平时怎么写代码这件事一条条讲清楚。2. Qoder到底是个什么工具凭什么能当同事在讲实操之前先花点时间把我对Qoder的理解说清楚免得后面看得一头雾水。如果你已经用过可以跳过这一节直接看下一部分如果你只是听说过AI编程工具但还没上手这节能帮你建立基本的判断。2.1 它不是补全插件是个能理解项目上下文的对话式编程工具很多人一听到AI编程工具第一反应是IDE里那种自动补全代码的插件。Qoder给我的感觉不太一样——补全只是它最浅的一层能力。它更核心的用法是在对话窗口里说出你的需求它能去项目里找相关文件、读代码、改代码甚至执行一些命令。我说帮我把UserController里重复的校验逻辑抽成一个工具类它不是凭空给我一段代码而是真的会在项目里搜索相关方法、分析重复模式、然后给出改动方案我再确认要不要应用。这个差异很关键。普通补全插件是你说上句我接下句Qoder这种工具是你先说需求我翻了你的代码再干活。正因为有这个能力差异它才值得你花心思去教——教会了它能按照你的代码风格来改代码而不是生成一段孤立的新代码塞进来。2.2 关于技能Skill和规则这是教AI最关键的两个抓手我的实际使用经验里Qoder有两个能力对教AI上班这件事至关重要。第一个是规则/上下文说明可以把它理解为放在项目里的员工手册AI在开始工作前会先读它第二个是技能库可以把它理解为岗位技能培训材料——比如你希望AI做代码审查就把审查的标准写成技能希望AI按你的规范生成代码就把规范写成技能。网上有人问Qoder做科研要装什么skill说明很多人已经把skills当成一种可安装可分享的经验包在用了。我自己也试过把一套Spring Boot项目开发规范写成技能让Qoder在动手前默读一遍效果比每次对话里临时说按项目规范来稳定得多。具体怎么组织这些规则内容后面第三节我会完整展开。2.3 版本差异和上手门槛说点大实话必须承认Qoder的很多能力跟版本绑定不同版本可能界面不一样、入口不一样甚至某些功能只在特定版本开放。我去翻官方文档的时候也发现版本更新很快我今天说的某个菜单位置可能过两个月就变了。所以下面所有实操步骤我尽量讲思路而不是死记点哪里——你拿到手上找到对应的入口即可。另外它跟主流的IDE都有集成我用的是JetBrains系如果你用VS Code也能走通类似流程就是界面细节略有差别。要上手的话我的建议是从一个小项目开始不要一上来就指挥它重构你的核心系统。先拿个demo项目把建项目—写规则—让它干活—验收这个闭环跑通再慢慢放大任务。这样即使出了幺蛾子损失也可控。接下来我就要详细说我是怎么准备员工手册的。3. 把我怎么写代码翻译成AI能读懂的规则主题是把开发习惯交给Qoder那第一个问题来了我的开发习惯到底有哪些如果问自己我的代码风格是什么大多数人会愣一下。我一开始也说不出来于是做了个很笨的事——翻自己最近写的三个项目看看到底有什么共性。3.1 翻代码把自己的习惯一条条列出来我最终列出的清单大概是这样的给你做个参考技术栈固定偏好Spring Boot 3.x MyBatis-Plus MySQL Redis不用JPA不喜欢MyBatis XML写复杂SQL能用注解和LambdaQueryWrapper就不写XML。目录结构按controller/service/mapper/entity/dto/vo分包不喜欢按功能模块分包配置类放config工具类放utils常量放constant。统一返回结构所有接口返回Result code为0表示成功非0为失败错误信息不直接抛给前端统一用异常处理器转换。异常处理规范业务异常用自定义BizException参数校验不手动判断用Validated 注解全局异常处理器里分类处理。命名风格类名、方法名、变量名都遵循Java常规命名但有一个额外习惯——布尔字段不用is开头避免序列化问题DTO不做继承避免字段混乱。日志规范业务关键操作打info日志异常统一由全局处理器打error日志不在业务代码里到处写log.error。这些都是我写代码时下意识在做的事但如果没人告诉AI它一定会写出一套看起来没错但跟你的项目格格不入的代码。比如它大概率会直接返回一个User对象而不是Result 包一层——不是它不行是它不知道你们组有这规矩。3.2 把清单写成员工手册规则文件的结构化列出来之后就要把这份清单组织成AI能稳定理解的内容。我没有写成长篇大论的文章而是做成了一个结构化的规则文件主要分这样几个板块项目概述这个项目是什么、技术栈是什么、核心业务模块有哪些。代码规范命名风格、注释要求、代码格式约定。架构约定分层架构、目录结构、包名规范、禁止事项比如禁止在Controller里写业务逻辑。接口规范统一返回结构、分页参数约定、接口命名规则。异常处理规范异常类型、全局异常处理器、错误码约定。数据库规范表命名、字段命名、主键策略、逻辑删除约定。常用依赖和工具本项目允许用的工具类、推荐库、禁止引入的库。提交规范commit message格式、分支命名、合并要求。注意第8条往往容易被忽略。如果你的目标是让AI帮你写代码commit规范似乎无关紧要。但既然要把AI当数字同事那它帮忙提交代码、写PR描述都是迟早的事——规范早定后面省心。3.3 规则不是一次性写好就完要持续喂下去规则文件写完之后并不是一劳永逸。我的习惯是每完成一个任务如果过程中AI犯了一个有意思的错、或者我发现某个规范忘记写进去了就顺手更新规则文件。比如有一次我让AI生成一个定时任务它直接用了Scheduled(cron ...)写死在代码里——我项目里的约定是cron表达式要放在配置中心于是我把这条写进了规则定时任务的cron必须从配置中心读取禁止硬编码。类似这样规则文件越来越像一本真正的手册而不是一开始就完美。这个过程很像带实习生。你不会第一天就把所有事情都告诉他但你会在每一次他犯错之后告诉他正确的做法是什么。AI也一样你多喂一次它就少犯一次。有了这本员工手册下一步就是让它上岗干活了。接下来我完整演示一遍我是怎么用Qoder从零搭出一个Spring Boot 3.5脚手架的——从一句话需求到最后验收中间踩了哪些坑为什么这么设计都会讲到。4. 实战带着Qoder从零搭Spring Boot 3.5脚手架终于到核心环节了。如果你是照着学的建议先建一个空白目录把Qoder挂到IDE上然后跟我一步一步来。4.1 第一步不是让它写代码是先让它知道我们接下来要干嘛我先做了一件事新建一个项目文件夹然后在Qoder对话框里说明任务目标和约束。那段话大概是这样的我们要从零搭建一个Spring Boot 3.5的项目脚手架。目标后续所有业务模块都基于这个脚手架开发。要求Maven项目Java 17依赖使用spring-boot-starter-web、validation、mybatis-plus、mysql-connector、redis、lombok、springdoc-openapi。分包按controller/service/mapper/entity/dto/vo/config/utils/constant。统一返回结构Result code0表示成功。全局异常处理器统一处理异常。先不要急着建文件等我把约束说清楚。注意我特别说了先不要急着建文件。这点非常重要——AI对话工具天然倾向于尽快给出结果如果我不拦一下它可能在我还没说完需求的时候就先建了五个文件然后我发现目录结构不对又要推倒重来。先对齐目标再动手这个顺序能省下大量无用功。它听完后通常会给一个计划摘要比如好的我将按以下步骤创建项目结构1. 创建pom.xml2. 创建目录结构3. 创建通用类...。到这里我才会说可以开始。先规划再执行这个习惯哪怕用在人类同事身上也一样有效。4.2 第二步分模块生成不要让AI一口气写完所有文件很多人让AI生成项目喜欢一句话帮我生成一个完整的Spring Boot项目。实测下来这通常会得到一堆看起来完整但细节全糊弄的代码。我这次的做法是分阶段推进每个阶段只做一件事做完先简单验收再做下一件。阶段一pom.xml和目录骨架我先让Qoder生成pom.xml要求包括我指定的那些依赖并且把Java版本设为17。生成之后我过了一遍发现有两个问题groupId和artifactId它默认填了一个示例值不符合我们公司的命名规范。依赖的版本号它用了引用父POM的方式这没问题但Spring Boot 3.5对应的MyBatis-Plus版本用哪个它给的未必是最新稳定版。解决方式group/artifactId我手动改MyBatis-Plus版本我直接告诉它用3.5.7当时我查过的最新稳定版让它重新生成。在生成pom的阶段我还顺便让它把maven-compiler-plugin的release参数设为17避免编译踩jdk版本的坑。阶段二通用返回结构和异常处理这部分是脚手架的核心价值之一我要求它先写这两个类ResultT和GlobalExceptionHandler。同时约定了错误码成功0参数错误400未认证401无权限403业务异常500系统异常999。这里我特意强调了一点业务异常要区分类型处理BizException走errorCode映射参数校验异常MethodArgumentNotValidException要把字段名拼进错误信息。让我意外的是它生成的GlobalExceptionHandler基本符合预期但有一处不符合我的习惯它把所有异常都打成了error日志包括参数校验异常。参数校验失败是用户输入问题不属于系统错误打error会污染日志监控。我让它改成BizException和校验异常打warn只有未知异常打error。这就是前面说的规则喂养——如果没有那本员工手册我大概要在对话里重新解释一遍我们的日志规范是什么。阶段三配置类和基础工具类到这一步我让它生成了这样几个类MybatisPlusConfig配置分页插件、乐观锁插件避免在业务代码里手撸分页逻辑。RedisConfig配置RedisTemplate的JSON序列化器。这块有个坑默认的JDK序列化器会把Redis里的数据变成不可读的二进制我要求的是String序列化key、Jackson序列化value。BaseEntity所有实体类的公共父类包含id、createTime、updateTime、deleted四个字段配合MyBatis-Plus的自动填充和逻辑删除。BeanCopyUtilsDTO和Entity互转的工具类基于Spring的BeanUtils封装不额外引入MapStruct把依赖控制在最小范围。这里要说一个我在实际用Qoder过程中发现的规律AI生成配置类的能力整体上是高于生成业务代码的能力的。因为配置类往往规则明确、样板化AI见过足够多这样的代码生成出来基本能用。真正的难点反而在于你应该让它生成哪些配置类——这需要项目经验。比如我让它配MybatisPlusConfig分页插件是因为我知道MyBatis-Plus默认不带分页不配的话Page对象查询出来数据是空的。这种坑AI不一定知道你的项目会踩但你知道。阶段四示例模块——用CRUD验证脚手架是否可用光有骨架没有肉没法验证脚手架好不好用。我让Qoder做了一个最小可用的示例模块一张user表对应实体、Mapper、Service、Controller包含分页查询、新增、更新、删除四个接口。这既能验证脚手架里的Result、异常处理、MyBatis-Plus配置是否真的生效又给后续业务模块打了个样。生成这个模块时我对它提了几个具体约束用户名的唯一性校验放在Service层不放在Controller层。分页请求参数用专门的PageQuery类不直接用MyBatis-Plus的Page类暴露给前端。新增和更新分开DTO避免用同一个DTO导致字段校验互相干扰。删除用逻辑删除不是物理DELETE。这段代码生成之后我开始做真正的验收——直接跑起来测试。跑到这一步AI的表现已经比较稳定了因为它有了前面的规则文件和几个阶段的上下文它写出来的代码基本是按照我的风格走的。但它依然出现了一个新同事会犯的错分页查询的排序字段没有做白名单校验直接把前端传的orderBy拼进了排序条件。我项目里的规范是排序字段必须在代码里显式指定不允许前端传。我把它加进了规则文件并在对话里纠正了一次。这个案例也说明AI生成的代码绝不是无脑可用你仍然需要把握住安全边界。4.3 第三步让AI写README和初始化SQL把收尾工作也交给它脚手架搭完之后还有两件事如果不做后面团队接手时会很痛苦一是初始化数据库的SQL脚本二是项目说明文档。SQL我不能完全交给AI——因为表结构设计需要业务知识但基础的角色表、用户表、字典表完全可以让它先生成我再调整。README则是它的强项把项目技术栈、目录结构说明、启动步骤、配置项含义、接口文档地址都写清楚这种重复性的文档工作交给AI再合适不过。这一步很多人会漏掉。实际上脚手架的价值不只在代码本身也在于团队拿到手之后能不能快速跑起来。文档、初始化SQL、环境变量示例这些都被我纳入了数字同事的工作范围。至此一个能用的Spring Boot 3.5脚手架就搭起来了而且它每一行代码背后都有明确的技术选型理由和我的个人风格印记。5. 实测中的意外与磨合AI搭建脚手架的五个教训这趟实操下来我对教AI上班这件事有了更多体感。它不是一个设定好规则就一劳永逸的过程更像是一场持续的磨合。挑几个有代表性的问题分享一下都来自实测过程中的真实场景希望能帮你少走弯路。5.1 教训一AI对包名和目录结构的理解不如你想象中稳定我要求分包按controller/service/mapper/entity/dto/vo结果它在com.example.project下面建了一堆子目录。这事本身不复杂但如果你不提前说清楚groupId和包名它就会用看起来合理但不符合你要求的命名。而且AI改正的方式是一次性新建目录不会智能迁移——如果文件已经生成了你就要手动移动很烦。解决方式在让它生成任何代码之前先把groupId、包名基路径写进规则文件的第一行。这属于入职第一天就该知道的信息不要等入职三个月才发现。5.2 教训二AI默认生成的异常处理日志级别和错误码语义经常不对前文提到了日志问题这里再补充一个AI很喜欢把所有异常都归为系统错误返回code999。但实际业务里参数错误、未登录、无权限都应该有独立的错误码和HTTP状态码。如果你不显式告诉它这些映射关系它生成的GlobalExceptionHandler会非常粗糙——能用但语义混乱前端无法通过错误码区分问题类型。这根教新人异常处理是同一个思路不光要告诉它要有全局异常处理器还要明确什么异常对应什么错误码打什么级别的日志。5.3 教训三配置类生成容易踩版本兼容性坑最典型的例子是MyBatis-Plus和Spring Boot 3.5的兼容版本问题。Spring Boot 3要求使用mybatis-plus-spring-boot3-starter而不是原来的mybatis-plus-boot-starterAI有时会混淆。分页插件配置在3.5.x版本里也有新的写法。遇到这种版本兼容问题不要指望AI凭记忆给你完全正确的答案——正确做法是让它去查官方文档如果工具支持联网搜索或者你自己确认后在规则文件里记下本项目MyBatis-Plus用法版本为xxx注意xxx。5.4 教训四一定要让AI解释为什么这么写而不是只看结果我让Qoder生成一个带缓存的用户查询时它用Redis做了缓存这本身是合理的但它没有考虑缓存穿透和缓存击穿的问题。我追问了一句为什么没处理缓存穿透它才补充了布隆过滤器方案。这说明了一个现象AI倾向于给出在普通场景下看起来正确的答案不会主动考虑极端情况除非你明确要求。所以我现在的习惯是每次让它干活之前先列一个验收标准清单把要考虑哪些边界情况写进去——比如幂等性、并发控制、缓存失效、安全校验。这个过程和带新人一模一样光说写个接口远远不够你得告诉他写接口要考虑什么。5.5 教训五规则文件要是活的不是死的我第一次写完规则文件就以为万事大吉结果发现AI在后续任务中还是偶尔违背规则——不是因为它无视规则而是因为我的规则写得不够具体。比如分页参数用PageQuery类这条我没有规定这个类应该包含哪些字段、排序参数应该在哪里校验AI自然无法执行到位。规则不是愿景它是可执行的操作说明。每次AI犯错后我会把正确的做法补进规则文件下一次它就会遵守。这个迭代过程重复三次之后它的表现会开始稳定——那时候你才真正拥有了一个数字同事。6. 进一步扩展从脚手架到真正的数字同事脚手架搭完了规则文件也跑通了下一步是什么很多人到这里会停住觉得AI能帮我生成项目骨架已经很不错了。但我想多说两句——数字同事远不止搭脚手架这一件事。6.1 让它参与代码审查是性价比极高的使用方式我自己开始尝到数字同事甜头的时刻是让Qoder做Code Review。脚手架搭好之后我在上面写了一个新的业务模块写完请求它做代码审查。它找出了我忽略的几个问题一个空指针隐患、一个事务注解被内部调用绕过的经典问题Transactional通过this调用不生效、一处并发场景下的数据覆盖风险。这几类问题以前靠人肉Review不一定每次都能发现交给AI做第一轮审查、人做第二轮之后质量确实上了一个台阶。当然它的审查也有局限性——它会漏掉业务语义层面的问题也会偶尔给出过度设计的建议。所以我的定位是它是负责标准检查的新同事我是负责业务判断的老同事两者配合而不是谁替代谁。6.2 让AI帮你维护规则文件本身规则文件维护这件事也可以反手交给AI来做。我会定期把新增的代码片段给Qoder看让它识别这段代码体现了什么规则然后对比现有规则文件找冲突、找遗漏。它会提出类似你规范里说日期时间用LocalDateTime但这段代码用了Date需要统一吗的问题。这种元层面的互动才是教AI上班真正有趣的地方——它不只是执行者也逐渐变成了你的流程助理。6.3 未来方向多AI协作和Skill共享搜索词里出现了多AI协作这个词我认为这正是数字同事概念的下一站。单个AI负责一个完整任务往往不如多个AI各司其职——一个做需求分析、一个写实现代码、一个做审查、一个写测试最后再由人来验收汇总。Qoder的Skills机制其实很适合做这件事把代码审查标准做成一个Skill把接口开发规范做成另一个Skill任务分发给不同的Skill去执行确实更接近真实团队的分工方式。我准备在后面的系列文章里详细讲这个方向这篇先留个引子——脚手架本身就是一个很好的试验田你可以在它上面测试各种Skill的效果。6.4 关于AI会不会让程序员失去基本功的一点想法最后说说我自己的心态变化。以前有人问我你让AI写这么多代码是不是自己代码能力退化了我的回答是恰恰相反。因为我要把习惯讲清楚给AI就必须重新审视那些我习以为常的写法——为什么用这种异常处理为什么不做字段继承为什么这个配置要这么设这些审视反而加深了我对基本功的理解。AI没有抢走我的基本功它逼我把基本功讲成了一本手册而这本手册让我自己的思路也清晰了。这正是我理解的数字同事的最终形态它不是我偷懒的工具而是让我不断升级工作方式的镜子。
