一个人坐在工位前同时开着五六个终端窗口每个窗口里都是一个正在干活儿的 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 的各个组件上。实操下来我是这样分工的团队角色Claude Code 里的对应物职责说明项目经理主会话Main Session拆解需求、分配任务、汇总结果、做最终验收专职工程师子代理Subagent代码实现、测试修复、文档整理各司其职手和脚终端命令执行跑测试、构建、静态检查、git 操作交接文档CLAUDE.md把项目背景、命令约定、禁区规则写进去AI 每次干活前自动读员工手册安全网git 与分支策略让 AI 放手改改坏了随时回滚外接工具MCP / 各类 API访问外部系统、浏览器、数据库、第三方服务这套映射关系想清楚了之后一个人带一队 AI就不再是噱头而是具体的管理动作你要做的是项目经理的事——写清需求、盯进度、审核产出、处理异常。AI 之间不需要互相聊天它们通过文件、git 分支和你的指令来完成协作。这一点很重要别指望让两个 AI 在同一个终端里开会那不是它们擅长的协作方式。2. 工作区全貌目录、记忆与上下文2.1 CLAUDE.md 就是团队的交接文档Claude Code 工作区最容易被忽略、但价值最高的文件就是项目根目录下的CLAUDE.md。每次新开会话它都会自动读取这个文件把它当作长期记忆。换句话说它就是你和 AI 团队之间的交接文档。我自己的CLAUDE.md一般包含这几块内容项目是干什么的、技术栈和目录结构、常用的构建测试命令、编码规范与禁区。写清楚命令和禁区尤其重要因为 AI 不知道你项目里哪些目录是生成物、哪些文件绝对不能动。# 项目名订单中心服务 ## 技术栈 - Go 1.22 Gin前端 Vue3 Vite - 数据库 PostgreSQLORM 用 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 只是把这个过程做成可视化配置。具体操作一般是这样在 CC Switch 里新增一个 Provider把对应厂商的 API 地址填进去比如 OpenAI 兼容格式的https://api.example.com/v1这类地址。填入模型名称和你自己的 API Key。保存后CC Switch 会帮你把ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY等环境变量写好。重启 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 高频问题速查表折腾这套工作区我踩过的坑不少整理成一张速查表遇到问题对号入座现象最常见原因处理思路启动时报订阅权限相关错误账号没有 Claude Code 访问权限或被组织策略限制检查账号订阅类型确认是否开通了 Claude Code 权限联系管理员或改用有效 API Key切换第三方模型后报 400模型接口协议不兼容确认是否走 Anthropic 兼容格式必要时加转换网关响应越来越慢、行为反常上下文被大文件塞满用忽略规则排除生成物和日志拆分任务减少上下文占用本地模型输出重复、答非所问模型参数量太小或生成参数设置不合理换更大的模型调低 temperature减少一次生成的长度要求终端命令一直卡住权限确认没通过或网络不通检查白名单配置确认 API 地址可达AI 反复改但始终不满意需求描述太模糊没有验收标准给出清晰的验收标准限定文件范围一步一步来6.2 避坑心得实用习惯比技巧更重要工具本身没什么门槛真正拉开体验差距的是使用习惯。我自己最重要的几条规矩如下。第一开工之前必须有提交点。每次重要任务开始前先git commit干净当前状态再开新分支。这样 AI 怎么折腾都不怕最坏也就是git reset --hard重来。第二一个会话只做一件事。任务之间互相切换会让上下文变脏影响 AI 的判断。第三给 AI 的指令里一定要写清楚做什么、改哪些文件、怎么算完成这跟给真实实习生派活是一样的。还有一个很多人不知道的小技巧每天工作结束时让 Claude Code 把当天改动和结论追加到CLAUDE.md或者一个NOTES.md里。这样一来第二天开新会话时 AI 就能继承前一天的上下文不用从零开始理解现状项目隔几天再继续也不怕失忆。另外AI 写出来的脚本、命令、正则表达式凡是会对外部环境产生影响的我都要求自己先肉眼扫一遍再执行。人工智能不是不会犯错只是错起来比较自信。你对它的每一次盲目信任最终买单的都是自己的项目。这套工作区用了小半年我最大的收获不是代码写得更快了而是心态变了以前遇到重复劳动总想着忍一忍就过去了现在第一反应是这事能不能拆成一个 AI 工单。Claude Code 本质上把一个人从所有事都得自己干变成了所有事都得有人管后者恰恰是我们在真实团队里早就练过的技能。如果你也在折腾属于自己的 AI 工作区欢迎把你踩过的坑跟我交流我也会持续更新这套配置心得。