第一个任务：让 AI 读代码改代码

目标

用一个真实场景跑通全流程：给一个已有项目加上错误处理。

不写“Hello World”这种玩具任务——那种演示看完你还是不会用。

准备工作

找一个你自己的小项目（有 git 的更好，改错了能回滚）。没有的话随便 clone 一个：

git clone <你的仓库地址> ~/WorkBuddy/demo-project

在 WorkBuddy 里把这个目录设为工作区。

任务 1：先让它读懂项目

别一上来就说“帮我改代码”。先确认它真的理解了项目结构，否则改出来的东西大概率跑偏。

提示词模板：

读一下这个项目，告诉我：

1. 技术栈是什么
2. 入口文件在哪
3. 数据是怎么流转的（从请求进来到响应出去）
4. 现在有没有错误处理，在哪里

这一步用 Ask 模式就行——只读不改，零风险。

验收标准：它能说出具体文件名和函数名，而不是泛泛的“这是一个 Web 应用”。说不出细节，说明上下文没喂够，看上一篇上下文与文件。

任务 2：让它定位具体问题

找到所有调用外部 API 的地方，列出哪些没有处理请求失败的情况，按文件名和行号给我。

这一步产出的应该是一份清单。清单对不对，你自己扫一眼就知道——这是你介入成本最低的时刻。

任务 3：动手改（切 Agent 模式）

方案确认后再执行：

按上面的清单，给每个外部 API 调用加上错误处理：

• 网络超时设为 10 秒
• 失败重试 2 次
• 重试仍失败就记录日志并返回友好提示，不要让程序崩掉
• 不要改动与错误处理无关的代码

最后一句很重要。不加这句，它可能顺手给你“优化”一堆别的东西，diff 变得没法看。

任务 4：验收

改完别急着合，做三件事：

1. 看变更清单 右侧结果区会列出改动的文件。数量对不对？有没有改到不该改的文件？

2. 看具体 diff 重点看它有没有：

• 删掉原有逻辑
• 引入你项目里没用的依赖
• 用了一致的命名风格

3. 跑一遍验证

cd ~/WorkBuddy/demo-project && npm test

或者让它自己跑：

运行测试，如果有失败的，告诉我失败原因并修复。

完整提示词模板（可抄）

任务：[一句话说清目标]

背景：
- 技术栈：[xxx]
- 相关文件：[xxx]
- 现在的问题：[xxx]

要求：
1. [具体要求 1]
2. [具体要求 2]
3. 不要改动与本次任务无关的代码

验证方式：[怎么算做完了]

新手最常犯的三个错

1. 任务描述太短 “优化一下这段代码” → AI 不知道什么叫优化。要写清楚优化什么指标。

2. 不看 diff 直接合 它改的东西不一定对，尤其是不熟悉的领域。至少要扫一眼关键行。

3. 一次给太多任务 “重构整个项目 + 加测试 + 更新文档” → 中途出错你要回滚一大片。拆成三次跑，每次可验证。

下一篇

上下文与文件：怎么喂料——决定 AI 输出质量的关键变量。