第 2 章 贴身搭档：VS Code 里的 Claude 插件工作流

插件形态的 Claude 像坐在你旁边的搭档：它看得到你的项目，改动直接落在你的文件上。正因为它离你的真实代码这么近，工作循环比什么都重要。六步，每一步都有存在的理由：

第一步，把需求说清。用第一册第 13 章的骨架（背景、目标、约束、例子），并且尽量指名道姓：引用具体文件、选中具体代码块再提问，永远好过凭空描述。"改一下登录逻辑"和"改 login.ts 里 handleSubmit 这个函数"是两个世界。第二步，先要计划。"先告诉我你打算改哪些文件、怎么改，别动手。"看过计划再放行。**第三步，逐文件审差异。**它改完后，用第 1 章学的差异视图一个文件一个文件看：先扫文件清单——它动的范围和计划一致吗？有没有碰不该碰的东西？（红线思维，时刻在线）——再看红绿内容本身。**第四步，接受或打回。**不满意就具体地说哪里不对，别勉强接受再自己补救。**第五步，跑起来验证。**按第一册第 14 章的金字塔：能跑、功能对、边界情况。**第六步，commit 存档。**验证通过立刻存档，给下一轮实验垫好回滚点。

再加两条会话纪律。其一：一个会话只干一件事。修 bug 的会话别顺手聊新功能——上下文混了，两件事都容易走样。其二：新任务开新会话。会话太长，早先的约定会被挤出 AI 的视野（第一册第 12 章讲过它的"遗忘"）；新会话等于给它一张干净的桌子。

关键领悟

插件的价值不是"它改得快"，是"你审得住"。六步循环里，属于你的是第一、三、五步——说清、审查、验证，这三步恰好是 AI 替代不了的。

试一试

下一个任务，强制自己走完整六步——尤其别跳过"先要计划"。数一数它的计划和你的想象差了几处。