Outcomes
学完这一阶段，你应该能做到什么
不要求一次到位，但你至少应该把这几个判断和动作练熟。
- 能独立完成终端、Git、包管理器和项目运行环境的最小配置。
- 理解为什么分支、提交、PR 和回归测试必须进入主线流程。
- 知道如何给 Codex CLI 提供稳定、可重复的执行环境。
Lessons
核心课时
每节课都为一个工程动作服务，而不是只堆定义。
Course Content
正式课程内容
下面这部分才是这个阶段真正要读、要练、要做的正文。建议先顺序读，再回头做 mission 和 quiz。
很多人把 AI 辅助编程的问题归咎于模型，其实大量失败发生在更早的一层：本地环境不稳定、脚本约定混乱、分支策略混乱、测试缺失。环境不稳定时，AI 只会把混乱加速。
这一阶段的任务很务实：让你先建立一个“能跑、能测、能回滚、能解释”的最小工程闭环。只要这条链路打通，后面的 AI 协作才会越来越可靠。
终端与文件系统基础
先能看懂自己站在哪个目录、项目有哪些文件，再谈让 AI 在仓库里工作。
这一课要掌握什么
- 理解工作目录和相对路径。
- 知道怎样快速定位文件、查看内容和确认当前环境。
- 避免在错误目录下运行命令。
正式讲解
终端看起来很“程序员”，但本质上只是你和文件系统打交道的界面。AI 在 CLI 里工作时，也是在当前目录里读文件、运行命令和写结果。所以如果你自己不知道当前目录是什么，AI 也很容易在错误上下文里工作。
最基础的动作包括：确认当前路径、查看目录结构、定位关键文件、理解哪些脚本在项目根目录运行。很多新手会在某个子目录里直接跑命令，结果配置和依赖都找不到。
你不需要先学很多复杂 shell 技巧，只要先能稳定完成三件事：找到项目根目录、看清关键文件结构、知道一条命令到底会在哪个目录生效。
Practice
练习：确认项目根目录
- 进入一个项目目录，写下你认为的根目录位置。
- 列出你认为最关键的 5 个文件或文件夹。
- 解释为什么这些位置对开发与 AI 协作重要。
Homework
课后作业：终端与文件系统基础
- 把这节课的方法应用到你自己的开发环境或仓库中。
- 写下你当前环境里最容易出错的一个点，并给出规避方法。
- 把本课内容整理成一份你以后会重复使用的操作清单。
交付一份“可执行环境说明”或“操作清单”，而不是纯概念总结。
Test
离开这节课的原例子后，你还能稳定完成相关操作吗？
你应该能回答
- 请描述这节课解决的核心问题是什么。
- 请举出一个常见错误场景，并说明如何排查。
- 请说明你会用什么检查动作证明自己已经掌握。
通过标准
- 能独立完成相关操作，不依赖原文一步步照抄。
- 知道常见错误会出现在哪。
- 能用脚本、日志、检查项来验证结果。
Evaluation
优秀
你已经能把这节课的方法纳入自己的工程习惯，并能指导别人避坑。
达标
你能独立完成这节课要求的最小闭环。
还需加强
你知道概念，但真正操作时仍然经常迷路或跳步。
学完自检
- 我知道当前终端在哪个目录。
- 我能找到项目根目录。
- 我知道关键文件通常放在哪里。
Git 与 GitHub 最小闭环
版本控制不是高级附加项，而是接收 AI 改动时最基本的安全网。
这一课要掌握什么
- 理解分支、提交、diff 和 PR 的作用。
- 知道为什么 AI 生成改动必须进入版本控制。
- 建立最小的分支与提交习惯。
正式讲解
AI 辅助编程会让改动速度明显变快，这时候 Git 的价值会被进一步放大。没有 diff，你很难看清到底改了什么；没有提交点，你很难回滚失败尝试；没有分支，你很难把实验性改动和稳定版本隔开。
GitHub 则把这套过程拉到协作层。就算你一个人开发，PR 和 review 的工作方式仍然值得借鉴，因为它会逼你把改动和验证说清楚。
你可以把 Git 看成 AI 协作的第一道护栏：先保存当前状态，再引入 AI 改动；先看 diff，再决定是否接受。这个顺序越早形成越好。
Practice
练习：为一次小改动设计版本控制流程
- 假设你要修一个小 bug，先写下分支名。
- 再写下这次提交的信息应该怎么写。
- 最后写出你会怎样用 diff 检查改动。
Homework
课后作业：Git 与 GitHub 最小闭环
- 把这节课的方法应用到你自己的开发环境或仓库中。
- 写下你当前环境里最容易出错的一个点，并给出规避方法。
- 把本课内容整理成一份你以后会重复使用的操作清单。
交付一份“可执行环境说明”或“操作清单”，而不是纯概念总结。
Test
离开这节课的原例子后，你还能稳定完成相关操作吗？
你应该能回答
- 请描述这节课解决的核心问题是什么。
- 请举出一个常见错误场景，并说明如何排查。
- 请说明你会用什么检查动作证明自己已经掌握。
通过标准
- 能独立完成相关操作，不依赖原文一步步照抄。
- 知道常见错误会出现在哪。
- 能用脚本、日志、检查项来验证结果。
Evaluation
优秀
你已经能把这节课的方法纳入自己的工程习惯，并能指导别人避坑。
达标
你能独立完成这节课要求的最小闭环。
还需加强
你知道概念，但真正操作时仍然经常迷路或跳步。
学完自检
- 我知道为什么 AI 改动必须进入 Git。
- 我能解释 diff 和提交的意义。
- 我不会在主分支上无保护地堆改动。
Node、pnpm 与项目脚本
脚本是人和 AI 共用的操作面，越统一，越容易稳定协作。
这一课要掌握什么
- 理解 Node、包管理器和项目脚本之间的关系。
- 知道为什么要统一 dev/build/check 入口。
- 学会用脚本而不是临时命令表达团队约定。
正式讲解
Node 和包管理器只是基础，真正关键的是你有没有把开发、构建、检查这些动作统一成清楚的脚本。因为无论是人还是 AI，最终都要依赖这套入口来运行项目。
如果每个人都凭记忆敲不同命令，AI 也很难知道应该走哪条主线。统一脚本能把“怎么启动、怎么检查、怎么构建”变成一份清晰的项目契约。
这也是为什么成熟项目会在 `package.json` 或类似位置提供稳定脚本。它不只是方便你自己，而是在给协作建立一个公共接口。
Practice
练习：设计 3 个最小脚本
- 为一个新项目设计 `dev`、`build`、`check` 三个脚本。
- 写下每个脚本的用途和触发时机。
- 判断 AI 在什么任务里最需要调用哪一个脚本。
Homework
课后作业：Node、pnpm 与项目脚本
- 把这节课的方法应用到你自己的开发环境或仓库中。
- 写下你当前环境里最容易出错的一个点，并给出规避方法。
- 把本课内容整理成一份你以后会重复使用的操作清单。
交付一份“可执行环境说明”或“操作清单”，而不是纯概念总结。
Test
离开这节课的原例子后，你还能稳定完成相关操作吗？
你应该能回答
- 请描述这节课解决的核心问题是什么。
- 请举出一个常见错误场景，并说明如何排查。
- 请说明你会用什么检查动作证明自己已经掌握。
通过标准
- 能独立完成相关操作，不依赖原文一步步照抄。
- 知道常见错误会出现在哪。
- 能用脚本、日志、检查项来验证结果。
Evaluation
优秀
你已经能把这节课的方法纳入自己的工程习惯，并能指导别人避坑。
达标
你能独立完成这节课要求的最小闭环。
还需加强
你知道概念，但真正操作时仍然经常迷路或跳步。
学完自检
- 我知道脚本是公共操作面。
- 我能解释 dev/build/check 的差异。
- 我不会依赖只存在自己脑子里的命令。
测试与日志是第一层真相
在定位问题时，测试结果和错误日志通常比“我感觉哪里不对”更重要。
这一课要掌握什么
- 理解为什么日志和测试是高质量 AI 输入。
- 知道最小失败测试的价值。
- 学会先收集证据，再请求修复。
正式讲解
AI 对模糊描述的响应很容易看起来合理，但要想得到真正靠谱的修复，最有效的输入通常是具体错误日志、复现步骤和失败测试。因为这些信息直接界定了问题边界。
日志帮助你回答“系统实际发生了什么”，测试帮助你回答“期望行为应该是什么”。两者结合起来，AI 才能在明确边界内工作，而不是靠猜补全。
所以比起说“页面好像坏了”，你更应该先问：控制台报了什么、接口返回了什么、最小复现是什么、有没有一条能失败的测试。
Practice
练习：把一个模糊问题改成可诊断问题
- 先写一句模糊描述，比如“列表页有问题”。
- 补上报错、复现步骤和目标行为。
- 再写一条最小失败测试或手动检查步骤。
Homework
课后作业：测试与日志是第一层真相
- 把这节课的方法应用到你自己的开发环境或仓库中。
- 写下你当前环境里最容易出错的一个点，并给出规避方法。
- 把本课内容整理成一份你以后会重复使用的操作清单。
交付一份“可执行环境说明”或“操作清单”，而不是纯概念总结。
Test
离开这节课的原例子后，你还能稳定完成相关操作吗？
你应该能回答
- 请描述这节课解决的核心问题是什么。
- 请举出一个常见错误场景，并说明如何排查。
- 请说明你会用什么检查动作证明自己已经掌握。
通过标准
- 能独立完成相关操作，不依赖原文一步步照抄。
- 知道常见错误会出现在哪。
- 能用脚本、日志、检查项来验证结果。
Evaluation
优秀
你已经能把这节课的方法纳入自己的工程习惯，并能指导别人避坑。
达标
你能独立完成这节课要求的最小闭环。
还需加强
你知道概念，但真正操作时仍然经常迷路或跳步。
学完自检
- 我知道日志和测试为什么重要。
- 我会先收集证据再找 AI 帮忙。
- 我能写出最小复现或失败检查。
Deep Dive
这一阶段真正要建立的工程习惯
读完下面这些部分，再去做练习和复盘，学习效率会高很多。
为什么环境一致性很重要
AI 工具能提速，但前提是你提供的环境稳定。Node 版本、包管理器、脚本命名和目录结构不统一时，模型输出往往会出现“看起来合理、实际跑不动”的情况。
把开发、测试、构建命令固化进 package scripts，也是在给 AI 建立可靠操作面。
Git 不是可选项
当 AI 开始生成越来越多改动时，没有分支和提交历史，你很快就会失去判断依据。Git 让你能看 diff、回滚失败尝试、拆开任务，并与团队协作。
这也是为什么本教程后面强调 `/review`、PR 与 Cloudflare 预览：真正的交付一定依赖版本控制。
测试先于优化
很多新手会先让 AI 重构，再补测试。顺序应该反过来：先有可运行的基线和最小测试，再让 AI 帮你加功能或重构。
一旦你这样做，AI 的产出风险会明显下降，因为每次改动都有明确反馈。
Mission
搭一条最小开发闭环
创建一个包含 dev、build、check 三个脚本的项目约定，并写下每个脚本的作用和触发时机。
- 明确本地开发脚本与生产构建脚本的区别。
- 写清楚什么时候必须运行检查脚本，例如提交前或 PR 前。
- 把这套约定写成项目 README 的一部分。