Claude Code 实战：把 AI 编程变成一条可复用的工作流
当任务从「做一个网页」升级到「改一堆文件、重构一个真项目」，关键就不再是提示词写得多漂亮，而是流程怎么设计。这篇讲五件事：项目约定文件、规划与执行分离、截图驱动、多文件指令、验收与回滚。
为什么要在终端里跑 AI，而不是只在编辑器里
一段很常见的经历：你在编辑器里用 AI 补全，单个函数写得飞快；但要改的东西一多，麻烦就来了——这个文件改完，那个文件没同步，报错一个接一个，你得手动把碎掉的代码一块块接回去。
编辑器里的 AI 更像一支笔，擅长局部；终端里的 AI 编程助手（比如 Claude Code 这一类）更像一个能自己跑命令、翻文件夹、改多个文件的临时同事。它们不是互相替代，而是分工不同。
| 维度 | 编辑器内 AI | 终端类 Agent |
|---|---|---|
| 典型能力 | 自动补全、内联改写 | 跑长任务、批量改多文件 |
| 工作范围 | 当前文件或选中的几行 | 整个项目目录 |
| 人的介入 | 每改一处都要确认 | 给出目标，让它自己推进 |
| 最适合 | 边写边补、快速试错 | 重构、批量替换、加功能 |
一个高频翻车场景：你在编辑器里用 AI 改着 A 文件，又让终端里的 Agent 去重构同一批文件。两边互相覆盖，谁都不知道对方改了什么，最后代码是一团乱麻。
约定好分工：让终端 Agent 干活的时候，你先别手动编辑同一个目录。任务结束、结果确认之后再接手。
安装与项目初始化：先跑通再谈效率
终端类 AI 编程助手的安装方式、支持的系统、登录方式和依赖要求，以官方最新文档为准。这里不写死具体命令和版本号——这类工具迭代很快，旧命令照抄经常直接报错，跟着官方文档走最稳。
安装完之后，真正影响体验的不是「装没装成功」，而是你有没有在一个项目目录里使用它。这一点很多人会忽略：一个靠谱的 AI 编程助手，需要知道「当前项目的技术栈、目录结构、有哪些约定」。它了解得越多，改得越准。
所以初始化大概是这样一条链：进到你的项目文件夹里 → 让它先通读一遍现有代码，摸清结构 → 生成一份项目约定文件 → 以后每次任务都带着这份约定走。第一次用，别急着让它改代码，先让它「读」。
项目约定文件：该写什么，不该写什么
这是整套工作流里回报最高的一步。在项目根目录放一份约定文件（很多工具默认读 CLAUDE.md，也有工具读别的同义文件，以官方最新文档为准），把你希望它永远记住的东西写进去。写一次，以后自动生效。
它解决的是一个根本问题：AI 每次对话都是「失忆」的。你不写在文件里，它每次都得重新猜你的技术栈、你的代码风格、你的禁忌。写进文件，就相当于给它发了一本员工手册。
# 项目约定 ## 这是什么项目 [一句话说明：比如「一个面向用户的作品集网站，纯静态，无后端」] ## 技术栈 - 语言/框架：[比如 原生 HTML/CSS/JS，不引入构建工具] - 运行方式：[比如 直接双击打开，或说明本地预览命令，以官方文档为准] ## 目录结构 - /src 放源码，/assets 放图片等静态资源 - 主入口是 index.html ## 代码风格 - 变量命名用英文小驼峰，注释用中文 - 函数保持短小，一个函数只做一件事 - 不用任何外部 CDN 依赖 ## 禁忌（很重要） - 不要重命名已有文件，除非我明确要求 - 不要删除任何现有功能，改动前先说明影响 - 不确定的地方，先问我，不要自行决定 ## 我的偏好 - 改代码前先给「改动计划」，我确认后再动手 - 每次改完，列出「本次改动清单」
注意「禁忌」和「我的偏好」两节。这两节才是这份文件真正的价值所在——技术栈和目录结构 AI 自己也能摸索出来，但「不许干什么」和「我希望你怎么干」，只有你能告诉它。
- 写约束，不写教程：别把框架文档抄进去，只写「这个项目特有的规矩」
- 短而具体：一行一条，越具体越有效；模糊的话（如「代码要优雅」）等于没说
- 随项目进化：每次发现它犯同一个错，就把对应规则补进去，让它下次不再犯
把「规划」和「执行」分成两轮
这是拉开熟练度和新手差距的地方。新手喜欢一句话说完然后让它直接改；熟练的人会先让 AI 只做规划、不做修改，确认方向之后再放它执行。
为什么？因为 AI 一旦开始动手，就会在错误的路上越走越远，改完一堆文件你才发现方向就不对。而规划阶段是廉价的——它只输出文字，你一眼就能看出对不对，及时喊停的代价几乎为零。
我有个需求，但这一步请你【只做规划，先不要修改任何文件】。 【需求】给作品列表加上「按标签筛选」的功能，点标签只显示对应分类的作品。 请输出： 1. 你打算改动哪几个文件，每个文件改成什么样（用文字描述意图） 2. 需要新增哪些文件、哪些数据 3. 这个改动可能影响到的现有功能（有没有连带风险） 4. 你打算按什么顺序做，为什么是这个顺序 先只给我这份计划。我问的问题答完、我说「开始」之后，你再动手。
计划看下来，你可能会说「第 3 步先别做，先做第 1、2 步」，或者「方案 B 更简单，按 B 来」。这些都是在便宜的时候纠偏。等它把文件都改了再返工，代价要高得多。
计划没问题，按这个执行，但有个调整： - 第 3 步的数据结构先按方案 B 来，简单优先 - 每改完一个文件，停下来告诉我改了哪里，等我确认再继续下一个 开始吧。如果执行中发现计划里没预料到的情况，先停下来告诉我，不要自己拍板。
「一个一个来、每步确认」在任务里看起来慢，但它让你始终掌控节奏。真要快，等你们配合熟了，再逐步放手让它连续做几步。
截图驱动的视觉修改与多文件任务
改样式这件事，文字描述永远比不过一张图。终端类 AI 助手大多支持你给它一张截图，这一点用好了效率翻倍——尤其是「这里看起来不对」这种说不清的问题，截图 + 圈重点比一百句话都管用。
做法很简单：把当前页面截下来，标出你不满意的地方，让它对着改。可以再附一份「参考截图」，告诉它你想变成哪种感觉。
我发了两张图： - 图 1 是现在的页面（红框圈出的地方我不满意） - 图 2 是我想要的参考感觉 【要改的点】 - 红框区域：卡片排布太挤，参考图 2 里卡片之间更松散 - 整体希望更接近图 2 的「留白多、层次清楚」的感觉，但保持我们现在的配色 请对照两张图，说明你准备改哪几处、每处怎么改，然后只改 CSS 相关部分， 其他逻辑一律不动。
多文件任务是终端 Agent 的主场，但也最容易失控。核心心法是：给它明确的「改动范围」和「不许触碰的边界」。范围讲得越清楚，它越不会顺手牵羊改一堆不该改的东西。
做一个跨多文件的改动：把所有页面里旧的品牌名「XX」统一替换成「YY」。 【范围】只处理 /src 目录下的 .html 和 .js 文件 【不要动】图片文件、配置文件、以及 /assets 里的任何东西 【要求】 - 替换前，先列出所有命中的文件和出现位置，让我看一眼 - 我确认后，你再逐个文件改 - 每改一个文件，报告：文件路径 + 改了几处 - 全部改完，给一份汇总清单 如果某个文件里的「XX」其实不该被替换（比如它是别的东西）， 先停下来问我，不要擅自决定。
批量改动的危险在于「误伤」。比如统一替换一个词，可能顺手改掉了某个不该动的变量名或注释，而且它不会主动告诉你。
养成习惯：动手前让它列出命中的文件和位置，你看一眼有没有误伤，再放行。这一步花两分钟，能帮你省掉几小时的排错。
验收与回滚：永远给自己留退路
复杂系统里，AI 改得再好，也必须人工验收。这不是不信任它，而是任何自动化改动都需要一个「确认真的没问题」的环节。这里的底线是：无论它做了什么，你都能退回去。
最稳妥的退路是版本控制（比如 Git 这类工具）。如果你还没用，强烈建议在让 AI 大改之前先启用一次，这样任何一步都能回退。具体命令和用法以官方最新文档为准。
这一步先别改代码，帮我做好验收和回滚的准备： 1. 列出这次改动涉及的所有文件清单 2. 告诉我「怎么验证改对了」——我该打开哪个页面、点哪里、看什么现象 3. 如果改坏了，怎么退回改动前的状态（简要说明步骤，命令以官方文档为准） 4. 帮我起草一段提交信息（commit message），说明这次改了什么 然后我按你说的去验证，有问题我再回来找你。
验收的顺序建议固定下来：先看它有没有跑起来，再看功能对不对，最后看有没有误伤其他部分。很多问题不是「新功能坏了」，而是「老功能被顺手改坏了」，所以「回归检查」这一步不能省。
把 AI 编程用稳的关键，从来不是让它一次做对，而是让它每一步都做得可观察、可确认、可回退。规划与执行分开、改动范围写清、动手前看影响面、动手后留退路——这四件事做到了，你才敢把真项目交给它。
下一篇聊「用 AI 写自动化脚本，干掉重复劳动」——把同样的思路，用到那些你每天手工做、做完还容易出错的琐碎活上。