妙虹 Java 云底座后端

要解决什么问题

在 miaohong-cloud-base 这类多模块 Java 云底座里，常见痛点不是「不会写 Spring」，而是每次换任务都要重新确认：模块边界在哪、Controller 该怎么写、Feign provider 和 API 模块谁改、Mapper XML 实际放在哪条路径。仓库根目录的 CLAUDE.md 与若干 references/*.md 已经沉淀了约定，但若一次性全塞进上下文，既浪费 token，也容易和旧习惯打架。

技能如何工作

本技能把协作流程写死成可复用的步骤：先确认改动范围，再按需加载文档，而不是默认通读整个仓库。

• 生成或审查后端代码前，优先读根目录 CLAUDE.md；若与技能内说明冲突，以 CLAUDE.md 为准。
• 用 references/module-map.md 定位根模块、运行时服务与入口；用 references/commands.md 做定向 Maven 构建、运行与验证（优先 -pl / -am，避免无谓全量构建）。
• 按任务类型追加：conventions.md（实现与重构）、controller-style.md（接口层）、provider-style.md（Feign 契约与实现）、mapper-xml-style.md（Mapper 与 XML SQL）、exception-style.md（校验与错误传播）、troubleshooting.md（启动、Nacos、网关、Mapper）。
• 工作面以 src/main、src/test 为准，默认忽略 target/；配置理解为 本地 yml + Nacos（bootstrap.yml 与 application.yml 分工不同）。
• 跨服务行为变更时，对照分层：miaohong-common（共享基础设施）、miaohong-modules-api（对外契约与 Feign DTO）、具体业务模块（miaohong-modules / miaohong-auth / miaohong-gateway）。

边界与注意点

技能假设 Java 17 + Maven，且运行时依赖可访问的 Nacos 命名空间与导入配置。包结构以业务包为先（如 com.miaohong.ai.user），不少 *Mapper.xml 在 src/main/java/.../mapper/xml，不要按「只在 resources 下找 XML」的习惯漏改。对外或共享契约变更时，需同时审视 provider 模块与对应 API 模块。接口文档倾向 方法上方 Javadoc，而非 Swagger 注解；请求形态以 CLAUDE.md 为准（例如不用 @PutMapping / @DeleteMapping / @PathVariable，POST 用 @RequestBody DTO，GET 限单参数查询，避免 Map 作入参或出参）。本仓库生成类使用 @author bianruhao；服务实现上避免循环依赖，优先抽到公共模块或通过 mapper/provider 解耦。