不要急着开发功能：先搭一个真正跑得起来的项目骨架
第三天上午的任务不是完成商城功能，而是搭建脚手架。对习惯追求“看得见成果”的学生来说，这一步显得不够兴奋，却是整个开发过程里非常关键的风险前置。
脚手架不是 AI 创建了一堆文件，而是最小技术链路已经真实运行。
为什么先跑通再开发
如果前端、后端和数据库分别开发几天后才第一次连接，很多环境问题会集中爆发：端口不一致、接口路径错误、跨域失败、数据库权限不足、配置文件缺失、依赖版本冲突。
这些问题与业务代码无关，却会让团队误以为功能实现失败。更好的顺序是先建立一个最小闭环：页面调用一个真实接口，接口读写真实数据库，再把结果返回页面。
链路一旦成立，后续功能是在可运行基础上增长，而不是到最后才拼装。
脚手架至少验证三个入口
课程里我要求学生分别打开：
- C 端前台页面。
- 后台管理页面。
- API 接口文档或健康检查地址。
如果项目包含数据库，还要确认接口确实从数据库读取测试数据，而不是前端写死了一组假数据。
“终端没有报错”不能作为成功标准。浏览器能打开、接口能调用、数据能返回，才是实际证据。
前端和后端通常是两个独立进程，启动后必须记录终端实际打印的端口，而不是继续沿用文档或 AI 猜测的端口。先分别验证前端首页、后端健康检查，再让前端发起真实请求，可以把“服务没启动”“地址配错”和“业务代码错误”分开处理。
一个最小可运行闭环
可以用商品列表做脚手架验证：
- 数据库存在一张最简商品表和两条测试数据。
- 后端提供 GET 商品列表接口。
- API 文档能够直接调用并返回结果。
- 前端请求真实接口并展示商品名称。
- 后台页面能访问，哪怕暂时只有占位结构。
这不是正式业务实现，而是验证架构、配置和依赖能够协同。
健康检查只是第一层证据
健康检查返回 200，只能说明服务进程能够响应；它不能证明数据库可用、迁移已执行或核心业务能够完成。骨架验收应该逐层增加证据：服务存活、数据库连接、最小写入、读取回显、页面展示。每一层失败，都能把排查范围缩小。
持久化也不等于“必须使用 MySQL”。课程可以依据环境选择本地文件、SQLite、MySQL 或托管数据库，但必须说清数据是否需要跨重启保存、是否支持并发、如何备份和迁移。技术选择服务于交付约束，不是为了模仿某种标准答案。
测试数据要与真实数据隔离
脚手架阶段常要反复创建用户、商品和订单。不要为了让测试重新运行而清空共享数据库，更不能操作生产库。应使用独立测试数据库、事务回滚、带唯一前缀的测试账号或可重复装载的 fixture，让每次验证都从可控状态开始并只清理自己创建的数据。
这项约定应该在开发第一个功能前写进 README。否则测试数量越多，数据相互污染越严重，最后出现“单独运行通过、一起运行失败”的假随机问题。
遇到环境问题怎样判断
AI 自动执行时，最容易顺手选择它熟悉的环境。例如机器已经有本地 MySQL，它仍可能尝试安装 Docker。开发者必须盯住执行过程，根据真实机器条件纠偏。
常见问题可以这样处理：
- 无权创建数据库：确认当前账号权限和目标数据库配置。
- 接口返回 404：核对后端路由、前端请求路径和代理配置。
- 页面没有数据：先直接调用 API，再检查数据库是否有测试数据。
- 服务启动但访问失败：确认实际端口和当前运行进程。
- AI 说已修复但页面不变：确认浏览器访问的是最新服务，不是旧进程或缓存。
定位顺序应该从真实运行表面逐层进入代码，而不是看到红字就让 AI 随机修改。
Git 从第一天就应该存在
脚手架跑通后立刻提交到远程仓库，它就是第一个可回退基线。
后续每完成一个独立功能，都先验证并提交，再开始下一个。这样注册功能被登录修改破坏时，可以清楚看到差异，也能恢复到最近可用版本。
提交信息应该说明完成了什么业务结果，而不是“update”“修改代码”。版本记录不仅保护文件，也是项目决策和变更历史。
数据库结构也需要版本
只让 AI 直接在本地创建表，会让数据库变化脱离代码。到了新环境，团队不知道应执行哪些 SQL，也无法确认字段是否已经升级。
使用 Flyway 等迁移工具，可以把每次建表和改表保存为有序脚本，随代码一起提交。后端启动时检查并执行未应用迁移，使不同环境拥有可追踪的结构变化。
这不只是“企业规范”，而是在避免非常现实的问题：代码依赖新字段，生产数据库却没有更新，最终在用户操作时才暴露事故。
脚手架完成清单
- 前台、后台和 API 都能从浏览器访问。
- 前端确实调用后端，不是静态假数据。
- 后端确实访问数据库，并能返回测试数据。
- 配置不包含提交到仓库的真实密钥。
- 数据库初始化有迁移脚本。
- 项目启动命令和端口有文档。
- 代码已提交远程仓库，能够重新拉取和启动。
- 临时 Demo 表、接口和数据有后续清理计划。
讲师判断：脚手架的验收对象是整条链路
目录创建成功、依赖安装完成，都不能证明脚手架可用。我会让学生在一台没有项目缓存的环境里重新拉取仓库，只依赖文档完成配置，然后从页面发起请求，经后端写入数据库，再读回一条测试数据。任何一步需要作者口头补充，都说明可复制性还不够。
骨架阶段还应该建立最小工程纪律：环境变量示例、数据库迁移、统一日志、错误处理、格式检查和构建命令。它们看起来不像业务功能，却决定后续二十次 AI 修改是在同一条轨道上前进，还是不断制造新的启动方式和隐性依赖。
课后练习
为一个新项目只搭建最小闭环，不实现正式功能。换一个空目录重新拉取仓库，按照文档启动前端、后端和数据库。如果仍能看到真实测试数据，这个脚手架才算具备可复制性。