导语：会用 AI 写代码 ≠ 会跟 AI 协作。这一篇是全系列的方法论支柱——把需求拆给 AI、验收它给的代码，一套五步工作流，之后所有实战篇都按它走。
前面 21 篇你学会了工具、环境、部署，但还差最关键的一环：怎么指挥 AI 干活。
很多人和 AI 协作的感受是"它总不按我想的来"。问题不在 AI，在于需求没说清、上下文没给够、输出没验证。这篇给你一套标准动作。
一、核心心法：AI 是"聪明的实习生"
把 AI 想象成一个聪明但容易自作主张的实习生：
- ✅ 你给清楚任务、给足上下文、说明验收标准，它能干得很好。
- ❌ 你只说"做个登录功能"，它会自由发挥——做得可能完全不是你要的。
所以你的角色不是"写代码的人"，是**"项目经理"**：拆任务、给上下文、验收、纠偏。这不是降低要求，这正是 AI 时代编程的核心能力。
二、五步工作流
| 步骤 | 做什么 | 一句话 |
|---|---|---|
| ① 拆任务 | 把大需求拆成能一次完成的小任务 | 一次只让 AI 干一件事 |
| ② 给上下文 | 项目结构 + 报错 + 期望 | 让 AI 站在你这边看问题 |
| ③ 先讲思路 | 让 AI 先说方案再写代码 | 确认方向对了再动手 |
| ④ 验证输出 | 跑起来、看结果、问解释 | 别盲信，验收过才算完成 |
| ⑤ 迭代回滚 | 不满意就迭代，改坏就回滚 | 有 Git 存档，大胆试 |
① 拆任务：一次只干一件事
别让 AI 一口气做一个"完整系统"——需求太大，AI 容易漏、容易偏。把大需求拆成小任务，一次一个：
❌ "帮我做一个博客网站。"
✅ "先做第一步：写一个能发布文章的页面，其它功能后面再说。"
经验：拆任务的颗粒度是"一次对话能完成、你能验收"。每个小任务做完跑通，再进下一个——这是和 AI 协作的核心节奏。
② 给上下文：让 AI 看见你的世界
AI 不知道你的项目长什么样，你要告诉它。三种必给信息：
| 信息 | 例子 |
|---|---|
| 项目结构 | "我的项目是 Flask + MySQL，目录是 xxx" |
| 报错原文 | "报错：ModuleNotFoundError: No module named 'flask'" |
| 期望行为 | "注册成功返回 JSON，失败提示'用户名已存在'" |
经验：报错永远贴原文，别转述"它报错了"——AI 认字不认情绪，原文能让它直接定位。
③ 先讲思路：方向对，代码才对
写代码前先问一句："你打算怎么实现？" 让 AI 先说方案（用什么技术、分几步、文件怎么组织）。
为什么？ 5 分钟听方案，能避免 30 分钟白写。方向不对，AI 写的代码再漂亮也是废的。
④ 验证输出：跑起来才算数
AI 给的代码，永远要验证，三件事：
- 跑起来：本地/服务器运行，看有没有报错。
- 看结果：功能真的符合预期吗？（注册能成功吗？数据存进去了吗？）
- 问解释：让 AI 讲清楚"这段代码在干嘛"——讲不明白的地方，多半有隐患。
经验：验证不过就带着报错原文回去找 AI（回到②），别自己瞎改。
⑤ 迭代与回滚：有存档，放心试
不满意就继续迭代（"还是不行，报错是 xxx，再帮我改"）。改坏了就回滚（第 20 篇的 Git：改前先 commit，坏了一键还原）。
三、3 个「好需求 vs 烂需求」对比
案例一：登录功能
- 烂："帮我做一个登录功能。"
- 好："我的项目是 Flask + MySQL，已有 users 表（id/username/password_hash）。帮我写注册和登录接口：密码用 bcrypt 哈希存储，登录成功返回 token，失败返回中文错误提示。"
- 差在哪：烂需求没给技术栈、没给表结构、没说期望——AI 只能猜。
案例二：排查报错
- 烂："网站打不开了，帮我看看。"
- 好："网站部署在 Ubuntu + Nginx，访问首页报 502。Nginx 的 error.log 最新几行是：……（贴原文）。帮我分析原因并给修复步骤。"
- 差在哪：烂需求没有环境信息、没有报错——AI 只能隔空猜。
案例三：改页面
- 烂："把这个页面改好看点。"
- 好："当前是 index.html。我想把顶部导航改成居中、背景白色、正文 16px。只改这一个文件，别动其它文件。"
- 差在哪：烂需求没有范围、没有具体目标——"好看"是主观词，AI 无从下手。
规律：好需求的共同点 = 给了技术栈 / 给了上下文 / 给了期望 / 限了范围。四样占全，AI 基本一次到位。
四、避坑清单
- 需求一次别太大：拆成小任务逐个推进，比一次让 AI 做全套靠谱十倍。
- 别嫌上下文啰嗦：多给一行项目结构，省一次来回；报错贴原文，别转述。
- 代码必须验证：AI 写的代码 ≠ 对的代码。跑起来、看结果、问解释——三关都过才算完成。
- 讲不清的代码要追问：AI 解释不清的地方，多半是糊弄或埋雷——让它重写或拆开讲。
- 改前先 commit（第 20 篇）：和 AI 协作的底线安全网，有存档才敢大胆试。
- 别让 AI 碰敏感信息：密钥、密码、数据库凭证——上下文里别给，代码里别让它写死。
总结
- 心法：AI 是聪明的实习生，你是项目经理——拆任务、给上下文、验收、纠偏。
- 五步工作流：拆任务 → 给上下文（结构+报错+期望）→ 先讲思路 → 验证输出（跑/看/问）→ 迭代回滚。
- 好需求四要素：技术栈、上下文、期望、范围——四样占全，AI 一次到位。
- 避坑六条：需求拆小、上下文给够、代码必验证、讲不清要追问、改前先 commit、敏感信息不给 AI。
10 分钟小任务：挑一个你手头的小需求（哪怕是"给页面加个按钮"），按五步工作流写一份"好需求"：技术栈 + 上下文 + 期望 + 范围，然后发给 AI 试试——感受一下和以前"随便问"的差别。下一篇开始实战：打开 Trae，从零做一个待办应用。
下一篇：用 Trae 从零做一个待办应用（上）：让 AI 帮你写后端。