3.5 和 AI 一起写代码的正确姿势
⭐ 这是全课两篇「重点长文」之二，也是这门课最值钱的一节。
工具会过时，模型会换代，这一节的方法不会。
🔁 重要提示：你第一遍大概率吸收不了——因为你手上还没有真项目，这些方法没地方落地。这很正常。 第 5、8、9 三个项目章的开头都会放回链把你带回这一页。它是一页需要读三遍的文档，第一遍混个脸熟，第二遍开始有感觉，第三遍你会发现每一句都在说你踩过的坑。
页内目录
一、本节你会做出什么
你会拿到一套可复用的协作方法，并当场写出属于你自己的规则文件。
📷 效果位：同一个需求的两种说法，以及两种截然不同的产出
先看一个真实对照。同样想做一个联系表单：
| ❌ 大多数人的说法 | ✅ 学完这节的说法 |
|---|---|
| 「帮我加个联系表单」 | 「在首页底部 Footer 上方，加一个联系表单区块。 包含：姓名、邮箱、留言三个字段，一个提交按钮。 暂时不做后端，点提交只弹一个「已收到」的提示。 样式和页面其他区块保持一致（卡片式、圆角、居中最大宽度 720px）。 手机端字段要竖排。 只新增这一个区块，不要改动页面现有内容。」 |
| 结果：它自作主张接了个后端服务、装了两个依赖、顺手把你的页脚重写了 | 结果：一次就对，git diff 只动了一个文件 |
差别不在 AI，在那段话。 这一节就是教你写出右边那段话，并在它做完之后验收它。
二、开始前你需要
三、跟着做
3.1 先认清一件事：AI 不缺聪明，缺的是信息
新手总以为，AI 做得不对是因为“它不够聪明”。几乎从来不是。
真正的原因是：你脑子里有一幅画面，而你只说出了其中的 10%。
你说“帮我加个联系表单”的时候，你脑子里其实有：要哪几个字段、放在页面什么位置、点了提交要干嘛、长什么样、手机上怎么排……你自己知道，所以你以为不用说。
AI 拿到的只有那八个字。剩下的 90%，它只能猜。猜十次错八次，你就觉得“AI 不行”。
🔑 本节的底层逻辑：
AI 的产出质量 = 你给的信息质量 × 你的验收质量
这两个你都能控制。这也是 1.2 说的“你的角色是提需求和验收”的具体含义。
一个提醒：说得具体 ≠ 说得专业。 你不需要会任何术语。“卡片圆角一点、鼠标放上去有点浮起来的感觉”就是好描述——它具体、可验证。
3.2 需求怎么描述：五要素模板
把脑子里那 90% 倒出来，靠这五个问题：
| 要素 | 回答什么 | 不说会怎样 |
|---|---|---|
| ① 做什么 | 具体要出现什么东西 | 它做出个八竿子打不着的玩意 |
| ② 放在哪 | 页面的哪个位置 / 哪个文件 | 它随机找地方塞，或者新建一堆文件 |
| ③ 什么样 | 样式、交互、文案 | 它按自己的审美来，你再改十遍 |
| ④ 不要做什么 | 边界在哪 | 它顺手重构了你的半个项目 |
| ⑤ 怎么算对 | 你会怎么验收 | 你俩对“做完了”的理解不一样 |
④ 和 ⑤ 是新手最常漏、也最致命的两条。 尤其是 ④——终端 Agent 的所有翻车现场，几乎都能追溯到“没说清边界”。
一个模板，照着填
【做什么】我想在项目里加一个 ____________
【放在哪】位置：____________（页面的哪个区域 / 哪个文件）
【什么样】- 包含这些内容：____________- 样式要求：____________- 交互行为：点击/悬停时 ____________- 手机端：____________
【不要做什么】- 不要改动 ____________- 不要新增依赖包，需要的话先问我- 不要顺手"优化"我没提到的地方
【怎么算对】做完之后我会检查：____________三组改写对照，感受一下差距
| ❌ 原话 | ✅ 改写后 |
|---|---|
| 「把样式改好看点」 | 「把景点卡片的圆角从直角改成 12px，鼠标悬停时整张卡片上浮一点、阴影加深。只改卡片，别动其他区块。」 |
| 「这个报错帮我修一下」 | 「页面白屏了，控制台报错原文是【整段粘贴】。先告诉我原因，不要直接改代码，我确认后再动手。」 |
| 「做一个后台管理页」 | 「先只做第一步：一个 /admin 页面，用表格列出所有景点的名称和标签，暂时读本地写死的数据，不做增删改，不做登录。样式简单能看就行。」 |
💡 第三组体现的是下一节要讲的拆分——“做一个后台管理页”不是一个需求，那是一个项目。
一个反直觉的技巧：描述“结果”，而不是“做法”
| ❌ 指挥做法 | ✅ 描述结果 |
|---|---|
| 「用 flex 布局把这三个元素排成一行」 | 「这三个元素我想让它们横着排成一行，平均分配宽度，手机上变成竖着排」 |
你不懂技术细节，就不要假装懂。 描述你要的结果，让 AI 选实现方式——这是它比你强的部分。你负责的是“要什么”，不是“怎么做”。
3.3 任务怎么拆：一次只交付一个可验收单元
为什么必须拆
「帮我做一个旅游网站」这种需求，AI 会给你一个看起来什么都有、实际上哪儿哪儿都不对的东西。然后你面对 20 个文件，不知道从哪儿改起，也不知道是哪一步开始歪的。
拆开之后完全不同：每做完一小步，你验收一次、commit 一次。出问题时你永远知道是刚才那一步的问题，回滚也只损失几分钟。
🎯 一句话标准：
拆到“做完这一步，我能亲眼看到点什么变化”为止。
如果一步做完你看不到任何变化，那这一步太抽象，还得再拆。
三条拆分线
| 拆分线 | 怎么拆 | 例子 |
|---|---|---|
| 按页面区块 | 一次做一块，从上到下 | Header → Hero → 卡片区 → 页脚 |
| 按“能看见”到“能用” | 先静态后交互，先假数据后真数据 | 先把卡片摆出来（写死数据）→ 再改成循环渲染 → 再接真数据 |
| 按前端到后端 | 先做出样子，再让它有功能 | 先做表单界面 → 再做提交逻辑 → 再存进数据库 |
一个完整的拆分示例
❌ 一句话需求：「做一个成都旅游网站，有景点介绍和路线推荐」
✅ 拆成 7 步（这正是第 5 章的实际路径）：
1. 创建项目骨架，能跑起来看到空白页 ← 能看到：一个空页面2. 做顶部导航 Header ← 能看到：导航栏3. 做首屏 Hero（大图 + 标题 + 按钮） ← 能看到：首屏4. 做一张景点卡片（数据先写死） ← 能看到：一张卡片5. 抽成组件，用数组循环渲染出 6 张 ← 能看到：六张卡片6. 加页脚、补齐其他区块 ← 能看到：完整单页7. 做详情页与页面跳转 ← 能用：点进去有内容每一步之间，都插一次 验收 + git commit。
⏱️ 拆分的粒度参考：一步 10~20 分钟。超过半小时还没能验收，说明这一步该再拆。
让 AI 帮你拆
你不会拆？拆分本身就可以交给 AI——而且这是它很擅长的事：
我想做：【一句话描述你的目标】
先不要写任何代码。请把它拆成一系列小步骤，要求：1. 每一步都是我能亲眼验收的（做完我能看到什么变化）；2. 每步大约 15 分钟的工作量；3. 按依赖顺序排列，前一步是后一步的基础；4. 标出哪些步骤有风险、容易返工。
用表格给我，我确认后我们一步步来，我说"下一步"你才做下一步。⚠️ 最后那句「我说“下一步”你才做下一步」非常关键。不加这句，它会把七步一口气全做完，你又回到了面对 20 个文件的处境。
3.4 先方案后动手：全课投资回报最高的一句话
这是一句话带来的最大改善，没有之一：
「先不要写代码，先告诉我你打算怎么做。」
为什么它这么有效
| 不说这句 | 说了这句 |
|---|---|
| 它花 3 分钟改了 6 个文件，你花 20 分钟发现方向错了，回滚重来 | 它花 20 秒给你一段方案，你花 30 秒看出方向错了，纠正一句 |
| 你事后审代码（看不懂） | 你事前审方案（看得懂，因为是大白话） |
| 错误已经写进文件里 | 错误还停在对话框里 |
审方案比审代码容易一百倍，因为方案是中文，代码不是。这是零基础学员少有的、能真正行使判断力的环节。
方案里该看什么
它给你方案之后，重点看四件事：
| 看什么 | 发现问题的信号 |
|---|---|
| 要改哪些文件 | 你只要加个按钮，它要动 8 个文件 → 🚨 |
| 要不要装新东西 | 一个小功能要装三个依赖 → 🚨 先问它有没有不装的做法 |
| 有没有理解错 | 方案里出现了你没说过的功能 → 它在自由发挥 |
| 有没有更简单的做法 | 直接问：“有没有更简单的方案？为什么不选那个？” |
什么时候可以跳过
不是每件事都要过方案。判断标准：
| 情况 | 要不要先出方案 |
|---|---|
| 改个文案、改个颜色 | ❌ 不用，直接做 |
| 涉及 2 个以上文件 | ✅ 要 |
| 你自己也不确定该怎么做 | ✅ 一定要 |
| 修一个你看不懂的报错 | ✅ 要，让它先讲原因（第 6 章重点） |
| 涉及钱、涉及数据、涉及上线 | ✅ 一定要 |
3.5 规则文件怎么写
3.2 和 3.3 都让你建过规则文件（AGENTS.md 或工具对应的规则目录）。现在讲怎么写才真的有用。
它解决什么
每次会话都要重复说的话，写进去一次，以后自动生效。
该写什么：三类内容
# 项目约定
## 一、这是个什么项目（让 AI 有背景）- 面向零基础读者的成都文旅介绍网站- 技术栈：Next.js（App Router）+ TypeScript + Tailwind CSS- 包管理器用 pnpm，不要用 npm 或 yarn
## 二、协作方式（最重要的一类）- 所有回复用中文，不要用技术黑话，我是零基础- **涉及 2 个以上文件的改动，先给方案等我确认，不要直接动手**- **不要擅自新增依赖包**，需要装什么先告诉我并说明理由- 不要修改和当前任务无关的文件- 每次改完，用一句话列出你改了哪些文件、分别改了什么
## 三、代码约定（AI 容易忘的具体规矩）- 组件放在 components/ 目录，一个组件一个文件- 样式一律用 Tailwind 的 class，不要写单独的 css 文件- 所有面向用户的文案用简体中文- 图片统一放 public/images/五条写作原则
| 原则 | ❌ 反面例子 | ✅ 正面例子 |
|---|---|---|
| 要可执行 | 「代码要写得优雅」 | 「一个组件文件不超过 150 行，超了就拆」 |
| 要可验证 | 「注意性能」 | 「图片必须用 Next.js 的 Image 组件」 |
| 要说“不要什么” | 只写想要的 | 「不要擅自新增依赖」「不要改我没提到的文件」 |
| 要短 | 写三千字没人（包括 AI）认真看 | 控制在 30~50 行，它每次都要读 |
| 要长出来，不要一次写完 | 开局憋一份完美的 | 每次被同一个问题烦到，就往里加一条 |
🔑 最后一条是精髓：规则文件是长出来的，不是设计出来的。
它第三次擅自装依赖把你惹毛了 → 加一条「不要擅自装依赖」。 它老是把中文写成英文 → 加一条「面向用户的文案一律中文」。
你的规则文件里每一条，都应该是一道你流过血的疤。
规则文件 vs Skill（3.4 讲过，这里再强调一次）
| 规则文件 | Skill | |
|---|---|---|
| 加载时机 | 每次都读 | 按需读 |
| 该放什么 | 短小、永远适用 | 长的、特定任务才用 |
| 写太多的后果 | 挤占上下文，让 AI 变笨 | 没什么后果，不用就不加载 |
别忘了
改完规则文件要 /reload 或重启工具才生效。而且——它也要 git commit，它是项目资产的一部分。
3.6 成果怎么验收：四种验收
“AI 说做完了”不等于做完了。 验收是你的活儿，有四种，从快到慢：
① 眼睛验收：看效果对不对
最快。刷新浏览器，看你要的东西出现了没、长得对不对。
但它只能发现“明显不对”，发现不了“看起来对但其实坏了”。所以还需要 ②③④。
② 操作验收：把关键路径走一遍
别只看，要动手点。
| 改了什么 | 至少要点什么 |
|---|---|
| 加了按钮 | 点一下，看有没有反应 |
| 加了链接 | 点进去，再点浏览器后退 |
| 加了表单 | 填一次提交；再试一次什么都不填直接提交 |
| 改了样式 | 把浏览器窗口拖窄到手机宽度看看有没有乱 |
| 任何改动 | 打开控制台（1.3 学的）看有没有红字 |
🔑 最容易被跳过、也最容易出事的是最后一条：页面看着好好的，控制台里一片红。养成改完就瞄一眼控制台的习惯。
③ diff 验收：看它到底动了什么（最关键）
这是 2.3 那节的正式用途，也是四种里最不能省的一种。
git diff --stat # 先看范围git diff # 再看细节你要回答一个问题：改动范围和我的要求匹配吗？
| 现象 | 判断 |
|---|---|
| 只要求改文案，只改了 1 个文件几行 | ✅ |
| 只要求改文案，动了 6 个文件 300 行 | 🚨 立刻停下，别管它效果对不对 |
| 出现了你没听说过的新文件 | 🚨 问清楚那是什么 |
package.json 变了 |
🚨 它装了新东西，问清楚为什么 |
为什么“效果对了也要看 diff”：AI 完全可能“为了实现你要的效果，顺手删掉了你昨天写的另一个功能”。页面上你看不出来，因为你根本没往那儿看。diff 会告诉你。
④ 追问验收：让 AI 自己交代
让它做自己的第一个审查员：
你刚才的改动，请回答我：1. 逐个文件说明你改了什么、为什么；2. 有没有改到我没要求的地方？如果有，说明原因；3. 这次改动有没有可能影响到页面的其他部分？4. 有没有新增依赖或修改配置文件？5. 你觉得哪里最可能出问题？第 5 问特别值钱——AI 对自己的薄弱环节常常有判断，但你不问它不说。
⚠️ 追问验收不能替代 diff 验收。 AI 可能漏报、也可能报了你没发现的问题（第 6.4 节专门讲“怎么识别 AI 在胡编”）。眼见的 diff，永远比它的自述可信。
四种验收怎么配
| 改动类型 | 该做哪几种 |
|---|---|
| 改个文案/颜色 | ① |
| 加个区块/组件 | ① ② ③ |
| 涉及多文件、加了功能 | ① ② ③ ④ |
| 碰了数据、密钥、上线相关 | ① ② ③ ④ 全做，而且要慢慢做 |
验收通过 → git commit。这是一个完整回合的终点。
3.7 上下文管理：为什么聊得越久它越笨
现象
你一定会遇到：
- 聊到第 20 轮，它忘了你开头定的规矩
- 同一个 bug 改了五轮，越改越乱
- 它开始“幻觉”，提到项目里根本不存在的文件
原因
AI 的“记忆”（上下文）有容量上限。而一次会话里，你说的每句话、它读过的每个文件、跑过的每条命令的输出，全都堆在这个容量里。
堆满之后，早期的信息会被挤掉或压缩——包括你开头交代的那些要求。
💡 一个好用的类比：上下文像一张办公桌。刚开始桌面干净，你要什么它拿什么；干了三小时，桌上堆满废纸，它要找你刚才那份文件都得翻半天。
/new就是把桌子清空重来。
五个手段
| 手段 | 怎么做 | 什么时候 |
|---|---|---|
| ① 换事就换会话 | /new（IDE 里点「新建对话」） |
最重要的一条。做完一个功能，开始下一个之前 |
| ② 卡住三轮就重开 | /new + 换个说法重新描述 |
同一个问题改三轮还没对——继续纠缠成功率极低 |
| ③ 精确引用，别全给 | 用 @文件名 指到具体文件 |
任何时候。让它读整个项目很浪费 |
| ④ 把结论沉淀下来 | 重要约定写进规则文件，而不是靠对话记住 | 发现自己在重复交代时 |
| ⑤ 主动给“上下文交接” | 新会话开头，用三句话交代清背景 | 每次 /new 之后 |
手段 ⑤ 的模板（很实用）
/new 之后，第一句这么说：
背景交接：- 项目：【一句话说明】- 我刚才做完了：【上一步的成果】- 现在要做：【这一步的目标】- 相关文件：@【文件1】 @【文件2】
请先读一下这几个文件，然后告诉我你的理解对不对，再开始。这比“继续刚才的”有效得多——新会话里没有“刚才”。
一个反直觉的建议
不要心疼一次会话。
新手总想“都聊这么久了，再试一轮吧”。沉没成本谬误。 一个已经乱掉的会话，越往后越差。
git restore .+/new+ 重新描述，三十秒，比你纠缠半小时管用。第 6.5 节会把这条讲透。
3.8 完整演练：把七件事串成一次改动
把上面所有内容串一遍。跟着做一次，你就有了肌肉记忆的雏形。
# 【0】动手前：存档（2.3 规矩一）git add -A && git commit -m "演练前的存档点"【1】开一个干净会话
/new【2】按五要素描述需求
【做什么】在首页最下方、页脚上方，加一个"联系我"区块
【放在哪】app/page.tsx 里，现有内容的最后
【什么样】- 一个标题「联系我」，下面三行：邮箱、微信、GitHub（内容先用占位文字）- 居中显示，最大宽度 720px- 和页面现有区块的风格保持一致
【不要做什么】- 不要改动页面已有的任何区块- 不要新增依赖包- 不要新建文件，就在 page.tsx 里加
【怎么算对】刷新页面能在底部看到这个区块，手机宽度下不会横向溢出【3】要求先出方案
先不要写代码，告诉我你打算怎么做、要改哪些文件。我确认后再动手。→ 看方案：只改 1 个文件？没装新东西？理解对了吗？
【4】确认动手
可以，动手吧。【5】四种验收
# ③ diff 验收（先做这个，最客观）git diff --statgit diff# ① ② 眼睛 + 操作验收pnpm dev# 浏览器打开 localhost:3000# → 看到区块了吗？# → 窗口拖窄到手机宽度，乱了吗？# → 打开控制台，有红字吗？# ④ 追问验收（回到 AI 对话框）你刚才改了什么？有没有动到我没要求的地方？有没有新增依赖？【6】通过 → 存档
git add -A && git commit -m "首页底部新增联系方式区块"【7】沉淀
这次它有没有干什么让你不爽的事？有的话，现在就往 AGENTS.md 里加一条。
📷 截图位 1：完整演练的七步流程图
这就是本课接下来 9 章的标准作业流程。 项目会变大，步骤不变。
3.9 十条坏习惯对照表
自查用。每一条都是真实发生过的。
| # | ❌ 坏习惯 | ✅ 正确做法 | 后果 |
|---|---|---|---|
| 1 | 一句话交代大需求 | 五要素描述 + 拆成小步 | 返工到怀疑人生 |
| 2 | 不说“不要做什么” | 明确划边界 | 它顺手重构半个项目 |
| 3 | 直接让它动手 | 先方案后动手 | 错误已经写进文件了才发现 |
| 4 | 动手前不 commit | 每次大改前存档 | 改坏了回不去 |
| 5 | 不看 diff，只看效果 | diff 验收永不省略 | 它悄悄删掉了别的功能 |
| 6 | 一个会话聊到底 | 换事就 /new |
它越来越笨、越来越幻觉 |
| 7 | 同一个问题纠缠十轮 | 三轮不对就回滚重开 | 时间和钱一起烧 |
| 8 | 每次重复交代同样的要求 | 写进规则文件 | 每天重复劳动 |
| 9 | 它说“改好了”就相信 | 自己点一遍 + 看控制台 | 上线后用户先发现 |
| 10 | 假装自己懂技术，指挥它用什么方案 | 描述结果，让它选做法 | 把它带进你臆想的坑里 |
📌 把这张表截图存下来。 第 5 章做项目时贴在旁边，比读十遍理论管用。
四、完成的标志是
- 我理解「AI 产出质量 = 信息质量 × 验收质量」这句话的含义
- 我能说出需求描述的五个要素，尤其是 ④ 不要做什么 和 ⑤ 怎么算对
- 我知道任务拆分的标准是“每步都能亲眼验收”
- 我知道那句投资回报最高的话：「先不要写代码，先告诉我你打算怎么做」
- 我写好了自己的规则文件，包含“项目是什么 / 协作方式 / 代码约定”三类
- 我知道规则文件要短（30~50 行）、要可执行、要慢慢长出来
- 我能说出四种验收分别是什么，并知道 diff 验收不能省
- 我知道为什么会话越长 AI 越笨，以及
/new的使用时机 - 我完整走了一遍 3.8 的七步演练
- 我看完了 3.9 的十条坏习惯，并认出了至少两条自己会犯的
五、卡住了看这里
Q：每次都写这么长的需求，不是更累吗？ 第一周会累，之后会快。而且账要这么算：写 2 分钟需求 vs 返工 20 分钟。等你熟了，五要素会变成一种条件反射，不用真的打那么多字——但“不要做什么”这条永远值得多打一行。
Q：我按五要素写了，它还是做歪了。
三步排查：① 需求里是不是有你以为说清了、其实有歧义的地方（把需求贴给 AI，问它“这段需求有哪些地方不明确”）；② 会话是不是太长了 → /new 重来；③ 这一步是不是太大了 → 再拆。
Q：「先方案后动手」它老是不听，直接就开始改。 把这条写进规则文件，别只在对话里说。还不听的话，在需求最后单独加一行：「再强调一次：现在不要动任何文件，只给方案。」重复和位置都有效——放在最后一句比放在中间管用。
Q：规则文件写了，好像没生效。
① 文件名和位置对不对（Pi 读根目录 AGENTS.md，IDE 各有各的规则目录，3.2 / 3.3 讲过）；② 改完要 /reload 或重启；③ 内容是不是太长了——写了三千字，它读到后面前面就淡了，砍到 50 行以内；④ 直接问它：“你现在读到的项目规则是什么？”
Q：我不知道该怎么验收，我根本看不懂代码。 你不需要看懂代码就能完成四种验收里的三种半：眼睛看效果、手点一遍、控制台有没有红字、diff 的文件数量是不是合理——这些都不需要懂代码。看不懂 diff 的具体内容没关系，用 2.3 那条「让 AI 翻译 diff」的提示词。
Q：拆得太碎，做一个小功能要来回十几次，好烦。 说明粒度过细了。标准是一步 10~20 分钟。文案、颜色这类小改动根本不用拆，直接做。拆分是给“你看不清全貌”的任务用的。
Q：这一节我记不住。 不用记。 记住三句话就够，其余等你做项目时回来查：
- 说清楚“不要做什么”
- 先方案，后动手
git diff验收，通过才 commit
六、本节提示词
📚 完整的模板库在 [附录 E]（新建功能 / 修 Bug / 重构 / 解释代码 / 验收清单），做项目时随时回查。这里给四条最核心的。
① 需求描述模板（五要素，最常用）：
【做什么】我想在项目里加/改一个 ____________
【放在哪】位置：____________
【什么样】- 包含的内容：____________- 样式要求：____________- 交互行为：____________- 手机端表现：____________
【不要做什么】- 不要改动 ____________- 不要新增依赖包，需要的话先问我- 不要"顺手优化"我没提到的地方
【怎么算对】我会这样验收：____________
请先告诉我你打算怎么做、改哪些文件，我确认后再动手。② 任务拆分：
我想做：【目标】
先不要写代码。把它拆成一系列小步骤：1. 每一步做完我能亲眼看到什么变化；2. 每步约 15 分钟；3. 按依赖顺序排列；4. 标出哪几步风险高、容易返工。
用表格给我。确认后我们一步步来，**我说"下一步"你才做下一步**。③ 生成你的规则文件（本节交付物）：
请为我的项目生成一份规则文件（我用的是【Pi，放 AGENTS.md / Cursor，放规则目录】）。
项目情况：【技术栈、做什么的】我的情况：零基础，看不懂代码，需要你用中文解释
内容包含三部分：1. 项目背景与技术栈（从项目里读出真实情况，不要编）；2. 协作方式：中文回复、大改动先给方案等我确认、不擅自加依赖、不动无关文件、改完列清单；3. 代码约定：目录结构、样式写法、文案语言等。
要求：**控制在 50 行以内**，每条都要具体可执行，不要写"代码要优雅"这种空话。写完直接创建到正确位置，并告诉我怎么让它生效。④ 验收追问（四种验收里的第四种）：
你刚才的改动，请如实回答：1. 逐个文件说明你改了什么、为什么；2. 有没有改到我没要求的地方？如果有，说明原因；3. 有没有新增依赖包或修改配置文件？4. 这次改动可能影响到页面/功能的哪些其他部分？5. 你自己觉得哪里最可能出问题？
请直说，不要为了让我放心而报喜不报忧。🔑 本节一句话
AI 负责实现，你负责“要什么”和“对不对”。这一节教的，就是这两件事怎么做得专业。
🎉 第 3 章完成
三章 13 课时，“上路准备”到此结束。回头看你拿到了什么：
| 章 | 你拿到的 |
|---|---|
| 第 1 章 | 一次完整闭环：生成 → 修改 → 上线 |
| 第 2 章 | 终端、Node、Git 这张安全网、必备账号 |
| 第 3 章 | 一个能干活的 AI 搭档 + 一套指挥它的方法 |
接下来是正课。
第 4 章讲前端基础——目标不是让你会手写代码，而是让你能看懂 AI 写了什么、能定位问题在哪、能把指令下得更准。学完它，你在 3.5 里的“验收”会从“看效果”升级成“看得懂”。
然后第 5 章，你会用这一切做出「遇见成都」——一个真正上线、能发给朋友看的网站。
🔁 记得回来：这一页在第 5、8、9 章的开头都会再次链接过来。第二遍读的时候，它会完全不一样。
上一节 ← 3.4 MCP 与 Skills 下一章 → 4.1 AI 时代的前后端核心概念