Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 能独立完成终端、Git、包管理器和项目运行环境的最小配置。
- 理解为什么分支、提交、PR 和回归测试必须进入主线流程。
- 知道如何给 Codex CLI 提供稳定、可重复的执行环境。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
35 分钟
终端与文件系统基础
学会读路径、切目录、看日志和理解当前工作区，避免让 AI 在错误上下文里工作。
55 分钟
Git 与 GitHub 最小闭环
分支、提交、PR、review 和回滚，是 AI 代码协作的安全护栏。
45 分钟
Node、pnpm 与项目脚本
用统一脚本执行开发、构建和测试，让 AI 输出更容易接入现有项目。
50 分钟
测试与日志是第一层真相
学会先看报错和测试结果，再让 AI 参与诊断，而不是相反。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
为什么环境一致性很重要
AI 工具能提速，但前提是你提供的环境稳定。Node 版本、包管理器、脚本命名和目录结构不统一时，模型输出往往会出现“看起来合理、实际跑不动”的情况。
把开发、测试、构建命令固化进 package scripts，也是在给 AI 建立可靠操作面。
Git 不是可选项
当 AI 开始生成越来越多改动时，没有分支和提交历史，你很快就会失去判断依据。Git 让你能看 diff、回滚失败尝试、拆开任务，并与团队协作。
这也是为什么本教程后面强调 `/review`、PR 与 Cloudflare 预览：真正的交付一定依赖版本控制。
测试先于优化
很多新手会先让 AI 重构，再补测试。顺序应该反过来：先有可运行的基线和最小测试，再让 AI 帮你加功能或重构。
一旦你这样做，AI 的产出风险会明显下降，因为每次改动都有明确反馈。
Mission
搭一条最小开发闭环
创建一个包含 dev、build、check 三个脚本的项目约定，并写下每个脚本的作用和触发时机。
- 明确本地开发脚本与生产构建脚本的区别。
- 写清楚什么时候必须运行检查脚本，例如提交前或 PR 前。
- 把这套约定写成项目 README 的一部分。