像带实习生一样带AI：任务与工作流

你说得越清楚，AI干得越漂亮——任务拆解、Plan Mode、会话管理的实战手册

阅读时长约12分钟 | 教程型 | 智能编码进化论 03/10

---

导读

上一篇搞定了CLAUDE.md——你给AI写好了岗位说明书，它每次开工自动读取。但"知道规则"和"干好活"之间，还差一步：你怎么给它派活。

想象你带了一个实习生。实习生很聪明，学东西快，但他没有你的经验。你说"把这个功能做了"，他可能做完才发现方向不对。你说"随便优化一下"，他可能花三天重构了你不想动的代码。问题不在实习生笨，而在你没说清楚。

和AI协作也是一样。本章讲三件事：怎么把任务说清楚（结构化输入）、怎么让AI先想再做（Plan Mode）、怎么管理会话不跑偏（上下文管理）。

读完这篇你会发现，和AI协作最关键的能力不是写Prompt，而是管上下文。

一、结构化任务输入：四要素法则

为什么你的指令总被打折扣

先看两组指令的对比。

模糊版：

把登录功能优化一下

Agent收到这条指令，会怎么理解？"优化"是指性能优化、代码重构、还是UI改进？是指登录接口的响应速度、还是前端的交互体验？需要改哪些文件？改到什么程度算"优化完了"？

Agent只能猜。猜错就是你的问题。

精确版：

在 src/auth/login.ts 中，当前登录接口没有做输入验证。 添加邮箱格式校验和密码长度校验（最少8位）。 参照 src/auth/register.ts 里的验证逻辑。 写完之后运行 npm test 确认测试通过。

这条指令，Agent能直接执行。因为四个关键信息都给到了。

四要素：目标、约束、范围、验证

每个有效的任务指令，都包含四个要素：

要素	含义	你需要回答的问题
目标	要做什么	最终交付物是什么？
约束	有什么限制	不能动什么？必须遵守什么规则？
范围	在哪做	涉及哪些文件或目录？
验证	怎么确认做对了	跑什么命令？看什么结果？

四要素不需要每次都写全。简单的任务，给目标+范围就够了。复杂的任务，四个都给。

几个实战例子：

修Bug：

目标：修复用户登录后偶发的 500 错误 范围：检查 src/auth/ 目录下的 token 刷新逻辑 验证：写一个能复现问题的测试用例，修复后测试通过

重构：

目标：将 utils.js 中的旧语法重构为 ES2024 标准 约束：不改变任何对外接口的行为，保持向后兼容 验证：重构后运行完整测试套件，全部通过

写测试：

目标：为 NotificationService 中未覆盖的函数添加测试 范围：只测边缘条件——空输入、超大输入、网络超时 约束：不用 mock，用真实的测试数据库 验证：npm run test:notification 通过

核心原则：你给的信息越精确，Agent需要猜测的越少，出错的可能就越低。 Agent不是你的上司，它不会追问"你到底想要什么"——你不说，它就按自己的理解来。

用 @ 引用文件，别用文字描述路径

"去看一下 src/auth/login.ts 里第45行附近的代码"——这句话让Agent自己去读文件，可能读错行，也可能读了不相关的部分。

更好的做法是用 @ 引用：

查看 @src/auth/login.ts 的 token 刷新逻辑

@ 会把文件内容直接注入上下文，Agent不需要猜测你指的是哪部分。同理，引用目录也行：

理解 @src/components 的组件结构

这会把目录列表给你，Agent知道有哪些文件可以选择。

二、Plan Mode：先想清楚，再动手

什么是Plan Mode

上一章提到过Agent循环三阶段：理解 → 执行 → 验证。默认模式下，Agent收到任务就直接进入执行阶段——动手改代码。

但有时候你不希望它一上来就改。你希望它先研究一下代码库，理解上下文，制定一个方案，你确认之后再动手。这就是Plan Mode的作用。

Plan Mode = Agent只看不改。 它可以读文件、跑命令探索，但不会编辑你的源代码。

进入Plan Mode有两种方式：

方式一：启动时指定

claude --permission-mode plan

方式二：会话中切换

按 Shift+Tab 在不同模式间切换，切到 plan 即可。或者用 /plan 前缀：

/plan 帮我分析一下添加 Google OAuth 需要改哪些文件

推荐的四步工作流

这不是我发明的，是Anthropic官方推荐的Best Practice：

第一步：探索（Plan Mode）
→ Agent只读代码库，理解架构和依赖

第二步：规划（Plan Mode）
→ Agent输出实施方案，列出要改的文件和步骤

第三步：执行（退出Plan Mode）
→ Agent按方案改代码，写测试

第四步：提交（Default Mode）
→ Agent提交代码，创建PR

举个完整的例子。

第一步：探索

/plan
分析一下 src/auth 目录的认证架构。
我们的 session 和 login 是怎么处理的？
环境变量怎么管理密钥的？

Agent会读文件、理解架构，给你一个分析报告。

第二步：规划

我想加一个 Google OAuth 登录。
基于你对认证架构的理解，列出需要改动的文件和具体步骤。

Agent输出一份实施计划。你可以按 Ctrl+G 在编辑器里直接修改计划，调整优先级或删掉不需要的步骤。

第三步：执行

按 Shift+Tab 退出Plan Mode，回到Default Mode。

按你的计划实施 Google OAuth。
写完之后运行测试套件，确保没有引入回归问题。

第四步：提交

提交代码，commit message 写清楚改了什么、为什么改。
创建一个 PR。

什么时候该用Plan Mode

不是每次都要走四步。判断标准很简单：

场景	用不用Plan Mode
改一个 typo	不用，直接改
加一行 log	不用，直接加
重命名一个变量	不用，直接改
修一个明确的 bug（知道哪行代码有问题）	不用，直接修
改动涉及3个以上文件	用，先看再改
不确定改法对不对	用，先研究
接手新项目，不了解架构	用，先探索
添加一个需要设计的新功能	用，先规划

一句话总结：如果能用一句话描述你想要的 diff，跳过Plan Mode。否则，先计划再执行。

三、Prompt模板集：五个常见场景

理解了原理，下面是五个高频场景的即用模板。先通读一遍有个印象，需要时回来查。如果时间有限，优先看模板2（修Bug）和模板4（写测试）——这两个用得最多。

快速查找：

• 刚接手项目，想快速上手 → 模板1
• 用户报了Bug，你知道大概在哪 → 模板2
• 用户报了Bug，完全不知道原因 → 模板2（诊断模式）
• 老代码要升级语法 → 模板3
• 新写了功能还没写测试 → 模板4
• 代码改完了要提交 → 模板5

模板1：理解代码库

给我一个这个项目的整体概览。
主要用了什么架构？数据模型有哪些？怎么跑测试？

进阶版——带方向性的理解：

trace the login process from front-end to database

从用户点击登录按钮开始，一直追踪到数据库写入，理解整个链路。

模板2：修Bug

用户反馈登录超时后会报 500 错误。
复现步骤：登录后等待30分钟不操作，再点击页面。
检查 src/auth/ 的 token 刷新逻辑，特别是 refresh token 的过期处理。
写一个能复现问题的测试，然后修复它。

关键要素：症状 + 复现步骤 + 指定范围 + 要求写测试。

如果不确定问题在哪，可以用诊断模式：

运行 npm test 的输出如下：
[粘贴错误日志]

定位根因，不要压制错误。修复后确认构建通过。

模板3：重构

重构 utils.js，使用 ES2024 语法。
保持所有对外接口不变。
每改一处就跑一遍相关测试。
最后跑完整测试套件确认无回归。

关键要素：改造目标 + 保持兼容 + 逐步验证。

模板4：写测试

为 src/services/NotificationService 中未覆盖的函数添加测试。
重点覆盖：空输入、超大输入、网络超时三个边缘条件。
遵循项目中已有测试的风格和框架。
运行测试确认全部通过。

关键要素：指定范围 + 明确测试重点 + 匹配现有风格。

模板5：创建PR

总结一下我这次改动的内容。
然后创建一个 PR，描述写清楚：
- 改了什么
- 为什么改
- 有什么风险需要注意

Agent会自动用 gh pr create 创建PR，commit message 也一并生成。建议分两步走：先让Agent总结，你确认总结准确后再让它创建PR——commit message的质量更高。

验证是最高杠杆的事。 Anthropic官方明确说：让Agent能验证自己的工作（跑测试、比对截图、检查输出），是提升质量最有效的方法。没有验证标准的任务，Agent可能产出"看起来对但实际不对"的结果——而你成了唯一的反馈环。

四、会话管理：上下文是最稀缺的资源

上下文窗口：你的硬盘，不是你的内存

Agent的上下文窗口有大小限制。你说的每句话、Agent读的每个文件、跑的每条命令输出，都在消耗这个窗口。窗口满了会怎样？Agent开始"忘记"之前的指令，犯错概率上升。

这不是Agent笨，是物理限制。就像你的电脑硬盘满了会变慢一样。

核心原则：上下文窗口是最重要的资源，管理它比优化Prompt更重要。

/clear：最被低估的命令

/clear 重置整个会话上下文。很多人舍不得用——"我刚给Agent解释了半天项目架构，清了不白说了？"

但现实是：一个塞满无关信息的上下文，比一个干净的上下文更危险。Agent在杂乱的上下文中会混淆当前任务和之前的历史，产生幻觉。

什么时候该 /clear：

• 上一个任务完成了，开始新任务
• Agent连续两次犯了同一个错误
• 会话已经跑了一个多小时

/compact：选择性压缩

不想完全清空，又想释放一些空间？用 /compact：

/compact 重点保留我修改的文件列表和测试命令

Agent会保留你指定的关键信息，压缩其余内容。相当于给上下文做了一次垃圾回收。

更精细的控制：按两次 Esc 或运行 /rewind，选择一个历史消息作为分界点，选择"从这儿开始压缩"或"压缩到这儿"。

跑偏了怎么办：三个急救操作

Plan Mode和会话管理是"预防"和"治疗"的关系：Plan Mode是预防——先规划再动手，减少跑偏的可能；会话管理是治疗——已经跑偏了，用/rewind或/clear重置。两者互补，预防为主，治疗为辅。

如果Plan Mode下规划好了，执行阶段出错了，优先用/rewind回退到执行前的检查点，而不是/clear重开——因为规划的上下文还有价值。只有当你发现规划本身就有问题时，才/clear重头开始。

Esc：Agent正在做的事情方向不对？按一次 Esc 停下来。上下文完整保留，你可以重新指示方向。

Esc + Esc 或 /rewind：Agent已经改了代码但改错了？双击 Esc 打开回退菜单，恢复到之前的对话状态和代码状态。Agent的每个操作前都会自动快照，你可以回到任意一个检查点。

"Undo that"：直接告诉Agent撤销上一步改动。简单粗暴但有效。

纠错法则：两次为限

如果你已经纠正Agent两次同一个问题，不要继续在同一个会话里纠错。上下文已经被错误的尝试污染了。

正确做法：/clear 清空上下文，写一个更好的初始指令，把前两次学到的教训直接写进去。

/claude

在这个React项目中，组件使用函数组件+hooks。
不要用class组件。
不要用默认导出，只用命名导出。
把 src/components/Header 组件重构为 TypeScript，
添加 props 类型定义。

一个干净会话 + 精确指令，几乎总是比一个充满纠正的漫长会话效果好。

会话延续

任务没做完要离开？Agent的会话是本地持久化的。

# 下次回来继续最近的会话
claude --continue

# 从列表中选择一个会话恢复
claude --resume

用 /rename oauth-migration 给会话起个名字，下次能快速找到。

子代理是探索的利器。 当你需要研究代码库时，用"用子代理调查 X"让Agent在独立上下文中探索，只把结论带回主会话。这样大量文件读取不会消耗你的主上下文。

五、避坑指南

坑一：厨房水槽式会话

一个会话里又修Bug又重构又写新功能，上下文里全是无关信息（厨房水槽式会话 = 把所有东西都扔进去，不分主次）。Agent分不清哪个是当前任务。

解法：一个任务一个会话。任务之间用 /clear 清空。

坑二：无限探索

"帮我调查一下这个代码库的架构"——Agent读了200个文件，上下文爆满，真正重要的信息被淹没。

解法：给探索设定范围。"只看 src/auth/ 目录，理解认证流程"比"调查整个代码库"好得多。或者用子代理来探索。

坑三：过度信任第一版产出

Agent给出的实现看起来没问题，但没处理边缘情况。你也没跑测试就直接用了。

解法：每次都提供验证手段——测试用例、lint命令、截图对比。如果无法验证，就不该提交。

坑四：纠正而不是重开

Agent做错了，你纠正它，它还是错，你又纠正，它又错——来回三次，上下文已经被污染。

解法：纠正不超过两次。第三次就 /clear，写一个更好的指令重开。

坑五：给了目标，忘了验证

"实现一个邮箱验证函数"——Agent写完了，但验证标准是什么？什么邮箱格式算合法？什么算非法？

解法：永远给出验证标准。

实现 validateEmail 函数。
测试用例：user@example.com → true，invalid → false，user@.com → false。
写完后运行测试确认通过。

结语

上一篇的结尾说："从下一篇开始，我们进入实战层面——怎么像一个带实习生的老手一样，高效地和Agent交互。"

这篇就是实战手册的核心。四件事：

把任务说清楚——目标、约束、范围、验证，四要素齐全。

先想后做——Plan Mode让Agent先研究再动手，避免方向跑偏。

管理上下文——/clear、/compact、/rewind 是你的三大武器。

给验证手段——让Agent能自己检查对错，而不是等你看。

这四件事做好了，你会发现AI从"需要反复纠正"变成"一次就做对"。不是因为AI变聪明了，是因为你说清楚了。

下一篇，我们换个角度：不是你给Agent派活，而是给Agent配工具箱——Skills技能系统，让你的Agent拥有项目专属的超能力。

互动话题

你平时给AI写指令时，最常踩的坑是什么？是"说了目标忘了约束"，还是"改来改去干脆自己写了"？来评论区聊聊你的血泪教训。

---

智能编码进化论 | 第3篇/共10篇

上一篇：AI岗位说明书：CLAUDE.md精讲

下一篇：给AI配工具箱：Skills技能实战

---

本文内容仅供学习交流，所述方法需结合实际场景灵活运用。 AI工具输出结果仅供参考，关键业务决策请结合人工判断。

本文由AI辅助创作，经人工审核编辑后发布。