把开发习惯交给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 ，code=0表示成功。全局异常处理器统一处理异常。先不要急着建文件，等我把约束说清楚。"
注意，我特别说了"先不要急着建文件"。这点非常重要——AI对话工具天然倾向于尽快给出结果，如果我不拦一下，它可能在我还没说完需求的时候就先建了五个文件，然后我发现目录结构不对，又要推倒重来。先对齐目标，再动手，这个顺序能省下大量无用功。
它听完后，通常会给一个计划摘要，比如"好的，我将按以下步骤创建项目结构：1. 创建pom.xml；2. 创建目录结构；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版本的坑。
阶段二：通用返回结构和异常处理
这部分是脚手架的核心价值之一，我要求它先写这两个类：Result<T>和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的自动填充和逻辑删除。BeanCopyUtils：DTO和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很喜欢把所有异常都归为"系统错误"，返回code=999。但实际业务里，参数错误、未登录、无权限都应该有独立的错误码和HTTP状态码。如果你不显式告诉它这些映射关系，它生成的GlobalExceptionHandler会非常"粗糙"——能用，但语义混乱，前端无法通过错误码区分问题类型。这根"教新人异常处理"是同一个思路：不光要告诉它"要有全局异常处理器"，还要明确"什么异常对应什么错误码，打什么级别的日志"。
5.3 教训三：配置类生成容易踩版本兼容性坑
最典型的例子是MyBatis-Plus和Spring Boot 3.5的兼容版本问题。Spring Boot 3要求使用mybatis-plus-spring-boot3-starter而不是原来的mybatis-plus-boot-starter，AI有时会混淆。分页插件配置在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没有抢走我的基本功，它逼我把基本功讲成了一本手册，而这本手册让我自己的思路也清晰了。这正是我理解的"数字同事"的最终形态：它不是我偷懒的工具，而是让我不断升级工作方式的镜子。
