脚手架阶段很容易让人产生一种错觉：AI 几分钟就能生成目录、依赖、配置和样板代码，所以这里应该是最容易提效的地方。事实正好相反。骨架一旦搭歪，后面所有需求、实现、测试和文档都会沿着歪掉的结构继续累积成本。
真实研发场景
新服务启动时，最容易高估“以后可能会用到什么”
一个常见的新项目启动画面是：还没确定第一版要交付哪些能力，就已经开始讨论要不要先建 api、application、domain、infra、adapter 多层目录，要不要把消息队列、缓存、搜索、异步任务、审计日志一次性接好。AI 非常擅长把这些“以后可能会用到”的想法快速生成成一个很大的骨架。
问题在于，大骨架并不等于好骨架。对于一个刚起步的 Spring Boot 服务，真正重要的是：第一版要解决什么问题、最少要有哪些依赖、哪些模块现在不建也完全不影响后续扩展。
本课的核心不是“搭得快”，而是“搭得轻”
骨架设计阶段最值得问的问题不是“还可以再补什么”，而是“哪些结构现在不需要存在”。AI 在这里应该扮演候选方案生成器和清单整理器，而不是一次性把终态架构全搭出来。
传统做法的痛点
过度脚手架会把未来的自由度提前锁死
| 表面收益 | 实际代价 |
|---|---|
| 目录很多，看起来很专业 | 新人根本不知道哪些包真的有职责 |
| 依赖一次性配齐 | 项目一开始就背上不必要复杂度 |
| 配置项准备得很全 | 维护者不清楚哪些配置已生效、哪些只是预留 |
| 所有层都先建好 | 后续为了“符合结构”而不是“符合需求”写代码 |
AI 会把这种倾向放大，因为模型天然偏向给出“看起来完整”的结果。
脚手架阶段最常见的三个错误
- 为未来可能存在的能力提前建模块
- 把依赖和配置一次性拉满，缺少最小可运行基线
- 目录是按理论分层建的，但和实际职责没有对应关系
AI 能提效到哪一步
AI 适合帮你快速起草这些内容
- 最小模块候选：第一版需要哪几个包或职责区域
- 依赖清单草稿：真正会被当前版本使用到的 starter 或库
- 配置对象草稿：哪些环境参数现在就需要抽出来
- 样板入口代码：应用启动类、配置绑定类、基础 health 接口
但这些事仍然要人工收口
| 内容 | 必须人工判断的原因 |
|---|---|
| 模块边界 | 取决于当前版本范围，不是理论最优图 |
| 依赖是否引入 | 影响构建速度、维护成本和后续演化 |
| 目录颗粒度 | 取决于团队规模和当前复杂度 |
| 预留能力 | 预留过多会制造“空架构” |
一个实用标准是：如果某个目录、配置或依赖在第一版没有直接被使用，就默认先不要加。
推荐工作流
从 MVP 倒推骨架，而不是从理想架构正推
推荐先写一份最小范围清单：
- 第一版要暴露哪些接口
- 第一版一定会访问哪些基础设施
- 第一版需要哪些测试或启动验证
- 第一版暂时明确不做什么
在这份清单基础上，再让 AI 起草骨架，效果会稳定得多。
五步最小骨架法
| 步骤 | AI 产出 | 人工要做什么 | 验证方式 |
|---|---|---|---|
| 1. 列 MVP 范围 | 模块候选清单 | 删除“以后再说”的内容 | 是否能用一句话说清每个模块职责 |
| 2. 起依赖草稿 | pom.xml 依赖候选 | 砍掉当前版本用不到的依赖 | 项目依赖是否仍然最小 |
| 3. 起配置草稿 | application.yml 与配置对象草稿 | 统一命名和前缀 | 配置是否与代码绑定一致 |
| 4. 起入口样板 | 启动类、基础 controller、配置类 | 确认不引入无用抽象 | 是否能快速读懂启动路径 |
| 5. 校验基线 | 构建、测试、启动检查清单 | 删除未使用结构 | 是否形成可运行最小基线 |
一个避免“脚手架垃圾”的检查清单
- 这个目录如果删掉，第一版是否仍可交付
- 这个依赖有没有立即使用的代码
- 这个配置项是否已经被绑定和读取
- 这个抽象层是不是为真实复杂度服务，而不是为想象中的未来服务
与仓库代码和模板的映射
- 构建基线：
../demo/pom.xml适合观察一个教学友好的 Spring Boot 服务最小依赖集合长什么样。 - 应用入口：
../demo/src/main/java/com/example/ainative/AiNativeBackendApplication.java适合讨论应用启动类应保持多轻。 - 配置绑定：
../demo/src/main/java/com/example/ainative/bootstrap/config/InfraProperties.java适合练习“哪些配置值得抽成对象，哪些不需要”。 - 配置来源：
../demo/src/main/resources/application.yml适合观察命名、前缀和环境变量占位如何组织。 - 对应练习：
../课后练习/第3课/练习.md
常见误用与风险
误用一：让 AI 一次性生成“企业级骨架”
结果通常是目录很多、职责很空、未来没来，维护成本先来了。
误用二：把预留能力当成已知需求
缓存、消息队列、搜索、异步任务都可能有价值，但不代表第一版都要先建。
误用三：有配置文件，却没有配置绑定和使用路径
这类“假配置”会让团队误以为某项能力已经接好。
误用四：骨架验收只看目录，不看可运行基线
真正应该检查的是能否构建、能否测试、能否启动，而不是目录树是否漂亮。
课后练习
建议直接在 ../课后练习/第3课/练习.md 中完成本课练习，并使用 ../课后练习/通用提交模板.md 保留 AI 输入、人工删改和验证结果。
如果你只做最小版交付，也至少保留四样东西：结构化输入、AI 产出摘要、人工判断记录、最终验证结果。
基础题
为一个新的后端小服务写一份 MVP 范围说明，只保留第一版真正需要的能力。
进阶题
让 AI 起一版最小 pom.xml 和模块清单，再人工删除你认为多余的依赖和目录，并解释原因。
挑战题
对照 demo/ 的配置与启动结构，设计一个“最小可运行骨架检查表”，用于你团队后续新服务启动。