Claude Code实战：一人搭建多AI协作工作区

一个人坐在工位前，同时开着五六个终端窗口，每个窗口里都是一个正在干活儿的 Claude Code 会话：有的在改前端样式，有的在修后端测试，有的在翻一份几十页的接口文档，还有一个在跑我前一天留下的代码审查。这听起来像带了一支小队，其实全程就我一个人。把这套东西搭起来之后，我最大的感受是：Claude Code 不是又一个"智能问答框"，而是一个真正能落地的 AI 工作区。这篇文章就把它的完整面貌拆开讲——从安装、目录结构、模型切换，到子代理分工、终端命令授权，再到我实际跑过的几个项目，说具体一点，让看完的人能直接照着自己的项目复刻一套。

1. Claude Code 的核心逻辑：为什么它能变成一支队伍

1.1 它是执行者，不是顾问

很多人第一次用 Claude Code 的时候，还停留在"问一句、答一句"的思维里，结果体验很一般。问题不在于模型不强，而在于用法错了。

普通的聊天式 AI 是顾问：你问它"这段代码有什么问题"，它给你列三点建议，然后你自己去改。Claude Code 是执行者：你告诉它"把 main.py 里这段逻辑抽成独立函数，跑通现有测试再回来"，它会真的读取仓库、定位代码、动手重构、执行测试，如果测试挂了还会自己看报错、继续修，直到满足你的验收条件。

这个差异决定了工作区的形态。顾问只需要一个对话框，执行者需要一套围绕项目仓库的管理体系：工作目录、长期记忆、工具权限、任务边界。Claude Code 把这些东西整合进了一个命令行工具里，所以它天然适合当"一人团队的底层操作系统"。

打个比方：聊天 AI 是坐在你旁边的专家，随叫随到但不动手；Claude Code 是领了工牌的实习生，你给它开了门禁权限，它真的会去工位上干活儿，干完还会向你汇报。你要做的，是决定给它开哪扇门、让它动哪张桌子。

1.2 一个人的工作区怎么组成"一队人"

一个人带一队 AI，靠的不是玄学，而是把传统团队里的角色映射到 Claude Code 的各个组件上。实操下来，我是这样分工的：

这套映射关系想清楚了之后，"一个人带一队 AI"就不再是噱头，而是具体的管理动作：你要做的是项目经理的事——写清需求、盯进度、审核产出、处理异常。AI 之间不需要互相聊天，它们通过文件、git 分支和你的指令来完成协作。这一点很重要，别指望让两个 AI 在同一个终端里开会，那不是它们擅长的协作方式。

2. 工作区全貌：目录、记忆与上下文

2.1 CLAUDE.md 就是团队的交接文档

Claude Code 工作区最容易被忽略、但价值最高的文件，就是项目根目录下的CLAUDE.md。每次新开会话，它都会自动读取这个文件，把它当作长期记忆。换句话说，它就是你和 AI 团队之间的交接文档。

我自己的CLAUDE.md一般包含这几块内容：项目是干什么的、技术栈和目录结构、常用的构建测试命令、编码规范与禁区。写清楚命令和禁区尤其重要，因为 AI 不知道你项目里哪些目录是生成物、哪些文件绝对不能动。

# 项目名：订单中心服务 ## 技术栈 - Go 1.22 + Gin，前端 Vue3 + Vite - 数据库 PostgreSQL，ORM 用 GORM - 目录结构：/internal 放核心业务，/cmd 放入口，/web 放前端 ## 常用命令 - 启动后端：go run ./cmd/server - 跑测试：go test ./... - 前端构建：npm run build ## 编码规范 - 错误处理统一用 errors.New，不要裸 panic - 所有对外接口必须写 Swagger 注解 ## 禁区 - 不要修改 /internal/config 下的生产配置模板 - 不要把凭据、密钥硬编码进任何文件 - 不要动 /vendor 目录，除非我明确要求

花十分钟写这个文件，换来的是之后每次会话 AI 都"懂规矩"。我踩过的坑是：一开始没写禁区，AI 有一次把我手工维护的配置文件格式改了，几轮对话下来才意识到是它干的。有了 CLAUDE.md 之后，这类越界行为少了很多。

2.2 会话、子代理与并行安排

Claude Code 的会话（Session）是工作管理的基本单位。我的习惯是一个功能一个会话，绝对不把两个不相关任务塞进同一个会话里。原因很简单——上下文一旦混在一起，AI 很容易"串台"，改着 A 模块的时候还在惦记 B 模块的旧需求。

在这个基础上，我会用子代理（Subagent）来承担专职角色。子代理的配置放在项目目录下的.claude/agents/文件夹里，每个文件定义一个角色。典型的配置文件长这样：

--- name: code-reviewer description: 负责代码审查，专门检查变更中的逻辑错误、安全隐患和风格问题 tools: Read, Grep, Glob, Bash(git diff) --- 你是一名严格的代码审查员。收到审查请求时，先看 git diff 确认变更范围， 然后逐个文件检查。重点关注：逻辑分支是否完整、错误处理是否缺失、 是否存在注入或越权风险。输出格式为：问题列表 + 严重程度 + 修改建议。

这样配置之后，在主会话里我可以直接说"让 code-reviewer 审查一下我刚才的改动"，Claude Code 就会调用这个子代理来干活儿。它不会干扰主会话正在做的事，输出结果再回到主会话里，由我来判断哪些要采纳。

我实际排的"班表"一般是：一个主会话负责统筹，一个 code-reviewer 子代理专门挑刺，再开三到四个独立终端窗口并行做不同模块。并行的时候注意分工别撞车，我会按目录或按功能模块切开，比如前端一个人负责、后端核心逻辑一个人负责、脚本工具一个人负责，这样大家改的文件不重叠，git 合并的时候才不头疼。

2.3 1M 上下文怎么用才不浪费

Claude Code 支持大上下文窗口，最近更是有人把整个仓库塞进去做分析。我试过把一个大中型项目的主要源码全部喂进去，确实能做全仓级别的跨文件审查和重构，这种场景下大上下文是杀手锏。

但大上下文不是免费的。上下文越长，单次请求的 token 开销越大，响应速度也会变慢。我的策略是分场景：全仓审查、跨模块架构调整、长文档分析，用大上下文模式；局部改 bug、写个小脚本、快速问答，用小上下文模式，速度快、成本低、也更稳。

更重要的是学会给上下文"瘦身"。Claude Code 支持类似.gitignore的忽略机制，应该把node_modules、dist、__pycache__、日志文件这些无关内容排除掉，不然 AI 会把大量 token 浪费在垃圾信息上，还容易被大文件干扰判断。

提示：如果你发现 AI 突然变得反应迟钝、行为怪异，先检查是不是上下文里混入了大日志文件或二进制文件。排掉这些东西，症状通常立刻缓解。

3. 从安装到接入各种模型：搭建一个合身的工作区

3.1 安装与 IDE 环境

Claude Code 的官方安装方式很简单，前提是你本机有 Node.js 环境。在终端里执行：

npm install -g @anthropic-ai/claude-code

安装完成后运行claude --version确认版本，然后在项目根目录执行claude就能进入工作区会话。注意一点：一定要在项目根目录启动，因为 Claude Code 会把当前目录当作工作区边界，只有在这个目录里的内容它才会读写。你要是第一次用，可以先用一个小项目练手，把整个工作流跑顺了再上重量级项目。

编辑器方面有三条路：纯命令行、VS Code 扩展、桌面版。我个人主力是 VS Code 扩展，因为它能直接在编辑器侧边栏里看到会话输出，鼠标点一点就能把代码文件喂给 AI，还能在改动后直观看到 diff。桌面版适合不喜欢命令行的人，本质上是给 Claude 套了个图形界面，功能上差别不大。

首次启动会要求登录授权，用自己的 Anthropic 账号或者配置 API Key 都行。这一步过了之后，工作区的基础设施就算搭好了。

3.2 用 CC Switch 切换 DeepSeek、Qwen、GLM

只用一个官方模型会有点"绑定感"，成本也容易压不住。社区里有个很常用的工具叫 CC Switch，专门用来切换 Claude Code 背后的模型供应商，我拿它接过 DeepSeek 系列、Qwen 系列、GLM 系列，都跑得不错。

接入思路本身不复杂，Claude Code 支持通过环境变量指定 API 地址和密钥，CC Switch 只是把这个过程做成可视化配置。具体操作一般是这样：

1. 在 CC Switch 里新增一个 Provider，把对应厂商的 API 地址填进去，比如 OpenAI 兼容格式的https://api.example.com/v1这类地址。
2. 填入模型名称和你自己的 API Key。
3. 保存后，CC Switch 会帮你把ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY等环境变量写好。
4. 重启 Claude Code 会话，新模型就生效了。

换模型之后，最直观的感受是：不同模型在代码能力上确实有差异。我一般让 Claude Code 的默认模型干重活儿、写核心逻辑，让国产模型处理批量任务、跑测试、做文档格式化，这样成本更均衡。谁擅长什么就用什么，这才是"一队 AI"的正确用法。

注意：Claude Code 默认使用的是 Anthropic Messages 协议，第三方模型如果只提供 OpenAI 兼容接口，通常需要一个转换网关把格式翻译过来。如果一换模型就报 400 之类的格式错误，大概率就是协议不匹配，不是模型本身的问题。

3.3 本地模型：LM Studio 与离线/隐私场景

有些场景不适合把代码交给云端：客户项目保密要求高、工作环境网络受限、或者单纯想省钱。这时候可以用本地模型顶上。我试过用 LM Studio 起本地推理服务，再接进 Claude Code 工作区。

LM Studio 本身是一个本地模型管理工具，可以在自己的机器上下载模型、启动本地 API 服务。新版本直接提供了 Anthropic 兼容接口，Claude Code 里把ANTHROPIC_BASE_URL指到http://localhost:1234就能用；如果版本较老只提供 OpenAI 兼容接口，就需要一个轻量转换层来翻译消息格式。按当前社区的常见做法，能直接填 Anthropic 兼容地址就先填，不能就套网关，两条路由我实测都走得通。

不过说句实话，本地模型在复杂代码任务上，跟云端大模型还是有明显差距。我对本地模型的定位是"干杂活"：做文本摘要、代码片段生成、变量命名、简单脚本编写、日志初步分析。核心架构设计和复杂业务逻辑还是交给云端更强的大模型。这样搭配，又省钱又够用，隐私敏感的部分也能留在本地。

3.4 终端命令授权：给 AI 的权限划红线

Claude Code 最大的杀伤力在于它能直接执行终端命令，这意味着它能跑测试、能构建、能提交 git，但同时也意味着它有"搞破坏"的能力。权限边界一定要提前想清楚。

默认情况下，Claude Code 对终端命令是逐条询问的——它要跑npm test，会先问你同不同意，你点了同意它才执行。如果嫌频繁点击太烦，可以启动时用白名单，比如：

claude --allowedTools "Read, Edit, Bash(npm test), Bash(git diff), Bash(git log)"

这样它跑测试、看 diff 就不用每次问你，但删除文件、任意执行脚本这类高危操作仍然会被拦下来。还有一种--dangerously-skip-permissions模式，会跳过所有权限检查，我只建议在隔离的 CI 环境或一次性容器里用，本地开发环境千万别开。

我在实际项目里的红线是：允许读写代码文件、允许跑测试和构建、允许 git add/commit/diff，不允许执行删除类命令、不允许 curl 下载并运行未知脚本、不允许连接生产数据库。这些规则不一定对所有人都适用，但"先收紧再放松"一定比"先放松再补救"安全得多。

4. 多 AI 协作的实操要点

4.1 让子代理真正干活儿的配置细节

子代理配置看起来简单，但门槛在两个容易踩坑的地方：一是描述写得太泛，二是工具权限给得不对。

description字段一定要写清楚这个代理在什么场景下被调用，因为主会话是根据描述来决定要不要调它的。我一开始写的是"审查代码"，结果主会话遇到什么问题都不太想到它；改成"负责代码审查，专门检查变更中的逻辑错误、安全隐患和风格问题"之后，调用频率明显高了。

工具权限也要匹配角色。审查类子代理只需要读权限和git diff，不需要编辑权限，否则你让它审查代码，它可能会忍不住自己动手改。建议审查代理只配Read, Grep, Glob, Bash(git diff)，让它看问题、出报告，不要让它直接改文件。实现类子代理才配Edit权限。

4.2 多人并行不打架的排班方法

并行执行是"一个人带一队 AI"效率最高的地方，也是最容易翻车的地方。如果两个会话同时改同一个文件，后改的会覆盖先改的，git 冲突能让人崩溃。

我现在的标准流程是这样：先在主会话里把大需求拆成任务清单，每个任务标明涉及的文件范围；然后开独立终端窗口，每个窗口对应一个任务，各自建独立分支；AI 在各自的分支里随便折腾，改坏了不影响主干；完工后我统一做代码审查和合并。这样并行度拉满，安全系数也高。

如果项目够大，还可以配合git worktree把同一个仓库的多个分支放在不同目录里，每个 AI 会话各占一个目录，完全物理隔离，谁都碰不到谁的文件。这一招在多人协作时尤其好用。

4.3 换模型当"内审员"：交叉验证 AI 的产出

单一 AI 容易犯错，而且一种模型的错误往往有固定模式。有个简单有效的土办法：让 A 模型写代码，让 B 模型来审查。因为不同模型的训练数据和擅长点不一样，第二双眼睛往往能发现第一双眼睛的盲区。

实操上很简单：Claude Code 写完一轮代码之后，我用 CC Switch 切到另一个模型重新开个审查会话，把改动丢给它看。国产模型在代码审查上给我的惊喜不少，它们对边界条件、资源泄漏这类问题的敏感度跟主流模型不完全一样，交叉验证之后能明显减少漏网之鱼。

提示：不要在同一会话里频繁切换模型，环境变量改了之后旧会话不一定能干净地继承。更稳的做法是关掉会话、切换模型、再重新开会话。

5. 实战记录：我用这套工作区干了哪些活儿

5.1 嵌入式开发：STM32 外设初始化

多数人觉得 Claude Code 是搞 Web 开发的，其实嵌入式也能用，而且效果超出预期。我接过一个 STM32 外设初始化需求，要做一套定时器 PWM 输出的底层配置。

我把芯片型号、参考手册里相关的寄存器描述和项目已有代码片段喂给 Claude Code，让它生成初始化函数。它很快给出了包含时钟使能、引脚复用、定时器参数配置的代码，还主动检查了预分频系数和自动重载值的匹配性。整个流程里最有价值的部分是报错处理——编译报错直接丢给它，它顺着报错定位到寄存器配置问题，改完再编，几个来回之后就通过了。

但这里要提醒一句：嵌入式硬件配置，AI 也可能一本正经地胡诌。引脚号、外设时钟来源、中断优先级这类信息，生成之后一定要对着数据手册人工核对。我自己的原则是：AI 生成的代码我默认当成"待验证的初稿"，编译通过只是第一步，逻辑正确要靠人确认。

5.2 AI 建站：一个人从零把站点立起来

我做过一个完整的工具站项目，从目录初始化到上线部署，基本都是在 Claude Code 工作区里完成的。建站这类任务特别适合交给 AI 团队，因为它由一系列独立的子任务组成：页面结构、样式调整、SEO 文案、响应式适配、部署脚本。

我的做法是拆成几个会话并行：一个会话负责页面骨架和路由，一个会话负责样式和视觉细节，一个会话专门写文案和 meta 信息。最后主会话统一 Review，提出修改意见再打回给对应会话。整个过程下来，我主要负责提需求和拍板，重复的布局调整、兼容性微调、脚本调试全被 AI 消化了。

印象最深的是响应式适配环节。我让 AI 自己跑本地预览，根据我的反馈修改断点，它连续迭代了七八轮，每一轮都能明确告诉我改了什么、为什么这样改。这种"自主迭代"能力，才是工作区真正省时间的地方。

5.3 文档与专利辅助：把零散素材整理成规范文本

除了写代码，Claude Code 在文书类工作上的表现也很值得说。我帮朋友处理过专利申请前的技术交底书整理，这事本身不涉及审查意见，纯粹是素材结构化。

原始素材是十几段随手记录的技术描述，包括功能点、实现细节、流程图草稿，乱得很。我把素材丢给 Claude Code，让它按交底书常见的结构框架组织成：背景技术、发明内容、具体实施方式、技术效果对比表，还要求它把口语化描述改写成书面化的专利语言。它输出的初稿质量相当高，我再对照原始记录逐条核对技术细节，修改大约三分之一的内容之后就能用了。

这个场景的核心提醒是：AI 擅长的是格式化和文案润色，不擅长判断技术事实本身。所有涉及数据参数、工艺流程、结构关系的描述，必须人工逐条核对，不能因为文字读着顺就直接用。我把 AI 的文档产出定位成"高质量草稿"，正式文本永远要过一遍人的眼睛。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

折腾这套工作区，我踩过的坑不少，整理成一张速查表，遇到问题对号入座：

6.2 避坑心得：实用习惯比技巧更重要

工具本身没什么门槛，真正拉开体验差距的是使用习惯。我自己最重要的几条规矩如下。

第一，开工之前必须有提交点。每次重要任务开始前，先git commit干净当前状态，再开新分支。这样 AI 怎么折腾都不怕，最坏也就是git reset --hard重来。第二，一个会话只做一件事。任务之间互相切换，会让上下文变脏，影响 AI 的判断。第三，给 AI 的指令里一定要写清楚"做什么、改哪些文件、怎么算完成"，这跟给真实实习生派活是一样的。

还有一个很多人不知道的小技巧：每天工作结束时，让 Claude Code 把当天改动和结论追加到CLAUDE.md或者一个NOTES.md里。这样一来，第二天开新会话时 AI 就能继承前一天的上下文，不用从零开始理解现状，项目隔几天再继续也不怕"失忆"。

另外，AI 写出来的脚本、命令、正则表达式，凡是会对外部环境产生影响的，我都要求自己先肉眼扫一遍再执行。人工智能不是不会犯错，只是错起来比较自信。你对它的每一次盲目信任，最终买单的都是自己的项目。

这套工作区用了小半年，我最大的收获不是"代码写得更快了"，而是心态变了：以前遇到重复劳动总想着忍一忍就过去了，现在第一反应是"这事能不能拆成一个 AI 工单"。Claude Code 本质上把一个人从"所有事都得自己干"变成了"所有事都得有人管"，后者恰恰是我们在真实团队里早就练过的技能。如果你也在折腾属于自己的 AI 工作区，欢迎把你踩过的坑跟我交流，我也会持续更新这套配置心得。