Claude Code 完整工作流：让我真正放弃手动改代码的那套配置
之前我为什么一直没改用
我不是没试过 AI 编程工具，但每次都是同一个循环：装好，跑起来，写一段 prompt，然后盯着它生成一堆看不懂的代码，改不动，最后还是自己手写。
问题不在模型，在我根本没有一套能稳定复用的工作方式。
这次决定花一周专门搞这件事，把环境、参数、目录约定全部固化下来，才算真正跑通。
环境准备
先说要装什么，别一上来就配 API key，那是最后一步。
- Node.js 20 以上
- 一个能用的 API key（我用的是中转，因为要连多个模型对比）
- 一个空的 git 仓库 —— 这个很重要，后面会救你
我的目录约定
myproject/
├── .claude/
│ ├── settings.json # 项目级配置，提交进 git
│ └── CLAUDE.md # 项目说明，给它读的
├── src/
└── README.md.claude/ 这个目录要提交到 git。团队里每个人都能用同一套配置，不用互相口述。这一点我一开始做错了，同事没法用我写的提示词。
CLAUDE.md 比你想的重要
第一次用的人基本都会跳过这个文件，然后抱怨"它不了解我的项目"。
CLAUDE.md 就是你写给它的项目说明书。放这些东西进去：
- 项目是做什么的，一两句话
- 用什么技术栈、什么版本
- 代码风格要求（缩进、引号、命名）
- 哪些文件不要动 —— 比如配置文件、迁移脚本
- 常用命令（怎么跑测试、怎么构建）
我的实际写法举例：
# 项目说明
## 是什么
一个内部数据看板，后端 FastAPI + 前端 React 18。
## 技术栈
- Python 3.11
- 前端 Vite + TypeScript，禁止用 any
- 包管理用 pnpm，不要用 npm
## 风格
- 双引号，2 空格缩进
- 组件用箭头函数
## 不要动
- `migrations/` 目录
- `.env` 及任何含密钥的文件
## 命令
- 测试：pnpm test
- 构建：pnpm build有了这个之后，它改代码的方式明显稳了。这是我这次最大的感受变化。
三个实际踩的坑
坑一：上下文窗口会被一次撑爆
我第一次让它读一个大文件，它直接把上下文塞满了，后面所有回答都开始胡说。
解决办法： 让它一次只处理一个模块，用具体文件名指路，不要说"看下整个项目"。
坑二：改动太大，不好回滚
它可能一次改十几个文件。出问题时你根本不知道从哪开始看。
解决办法： 我现在每完成一个功能就 commit 一次，commit message 写清楚改了什么。出问题直接 git revert，干净。
坑三：不敢让它碰数据库相关代码
迁��脚本、schema 变更这类，出错的代价太大。
解决办法： 明确写在 CLAUDE.md 里"不要动 migrations/"。写了两遍之后它就会遵守。
多 Agent 协作
单个 Agent 处理大任务会上下文吃紧。我的做法是拆开并行：
- 一个 Agent 负责写实现
- 一个 Agent 专门做 review，找边界情况
- 我自己作为"主Agent"负责合并和最终确认
关键在于每个 Agent 的任务描述要足够独立，不能依赖上一个 Agent 的对话上下文。因为它们之间不共享记忆。
参数备忘
几个我天天用的：
| 参数 | 作用 |
|---|---|
--continue | 接着上一次的会话继续，不重开 |
--resume | 从历史会话里挑一个恢复 |
--print | 不进交互界面，直接输出结果，适合脚本化 |
用--continue 这个功能省了我大量时间——不用每次重新描述项目背景。
目前的实际状态
现在写代码的流程变成：写清楚需求 → 它实现 → 我 review → 不行就让它重来。
真正省下来的不是打字时间，是查文档和写样板代码的时间。这两个占据了以前我大概一半的编码时间。
如果你也想试，建议先别从大项目开始，拿一个自己熟悉的小工具练手，出问题时你还能判断它错在哪。
三个可能对你有用的链接
下面这些是我实际安装和配置时参考的资料，工具本身的下载入口放在右边的工具箱里了。
一个补充说明
关于权限设置：如果你让它执行命令，建议在 CLAUDE.md 里把允许的命令列清楚，而不是全部放开。我自己是用白名单模式，只允许跑测试和构建，别的一律拒绝。