一个人带一队 AI 干活听起来像科幻片但把 Claude Code 的工作区配好之后这已经是我每天打开终端就看到的工作状态。这篇文章不聊什么宏大叙事就讲讲我手里这个 AI 工作区的全貌从目录结构、模型接入到多个 AI 角色之间怎么分工协作能直接抄作业的部分我都尽量写出来。适合正在用 Claude Code、或者刚打算用它管理复杂项目的人哪怕你是第一次听说“AI agent”概念看完也能知道这东西到底能替你扛多少活。1. 一个人带一队 AI为什么要搭一个“工作区”1.1 单人团队的核心痛点我先说一个很现实的问题如果你只是偶尔让 AI 帮你改一小段代码那随便开个对话框就够了但当你一个人要维护一个完整项目需要 AI 帮你做需求分析、写代码、跑测试、查资料、写文档这时候单个聊天窗口根本不够用。原因很简单。每一次跟 AI 的长对话背后都是一整段上下文。你跟它讲“这个模块要重构”它记住了但等你看完别的东西回来再问它“刚才那个方案你怎么想的”它已经忘了大半。上下文一乱AI 就会开始一本正经地胡说八道——不是它蠢是你没给它一个“稳定的工作环境”。这就是工作区存在的意义。它不是简单的“把项目代码放在某个文件夹里”而是一整套指挥系统让 AI 知道自己在干什么、项目规则是什么、哪些工具可以用、哪些任务该找哪个“同事”帮忙。说得直白点Claude Code 工作区就是给 AI 小队立规矩的地盘。1.2 工作区不是文件夹是一套“指挥系统”我见过不少人以为往项目里塞一个CLAUDE.md文件就算配置了工作区结果 AI 该乱跑还是乱跑。实际上一个完整的工作区至少包含四层东西第一层是项目规则也就是CLAUDE.md这类记忆文件告诉 AI 这个项目用什么语言、什么风格、哪些目录不能动第二层是工具与权限限定 AI 能用哪些命令、不能在哪些路径上操作第三层是角色列表也就是 subagent子代理定义相当于你手里有几个“外包专员”各有各的擅长方向第四层是模型接入与上下文策略决定这队 AI 用哪个大脑、上下文空间怎么分配。这套东西配好之后你的工作方式会从“跟 AI 聊天”变成“管理一队 AI”。你不再需要事无巨细地交代每一步只需要下发任务、验收结果、在它们跑偏的时候拉一把。1.3 为什么偏偏是 Claude Code现在终端里的 AI 编程工具不少各有各的拥趸。我选 Claude Code 当“领队”主要是看中三点第一它是终端原生的。我所有项目本来就是 git 终端的工作流AI 直接在终端里跑能复用我已有的工具链不用把代码搬到另一个编辑器里干活。第二它对长任务和代码库的理解比较强。改一个大项目时它能把跨文件的影响面盘清楚而不是盯着一个文件硬写。第三它的工作区机制足够灵活可以通过配置把多个角色揉进同一个项目里这正好戳中我“一个人带一队 AI”的需求。当然工具这东西各有偏好但不管你用哪家的 agent工作区的设计思路都是通用的。下面这些配置思路换成其他同类工具也能参考。2. 工作区核心配置目录、规则与模型接入2.1 先搞清楚 .claude 目录里到底放什么Claude Code 在项目根目录下会有一个.claude/目录这是整个工作区的心脏。我按自己的使用习惯把它分成几个块.claude/ ├── CLAUDE.md # 项目总规则、记忆、行为边界 ├── settings.json # 权限、模型、环境变量等运行配置 ├── commands/ # 自定义斜杠命令比如 /review、/todo └── agents/ # subagent 定义每个角色一个 .md 文件这个结构不是写死的但你最好按“规则—配置—命令—角色”四个维度去组织。我见过有人把什么都塞进一个超大的CLAUDE.md结果 AI 每次读规则要消耗大量上下文还没开始干活就快把窗口用完了。规则文件只写“稳定不变”的东西容易变的放 settings这是很关键的一条经验。另外说一句CLAUDE.md放在项目根目录除了.claude/里那一份你还可以在子目录里放局部的CLAUDE.md专门约束某个子模块的规则。AI 进入那个目录工作时会自动加载相当于给每个子项目单独发了一本“员工手册”。2.2 CLAUDE.md 怎么写不是写作文是立规矩很多第一次用的人喜欢把CLAUDE.md写成“自我介绍”——“你是 Claude一个 AI 助手”。这完全是浪费。真正有效的写法是把它当成“新员工入职手册”要包含三类信息一是硬性边界。比如“禁止修改vendor/目录下的任何文件”“数据库迁移文件必须经过我确认”“所有对外接口变更必须更新 README”。AI 是执行力很强的员工你不写边界它就会很勤快地把不该碰的文件改了。二是惯用写法。比如项目里的错误处理规范、命名习惯、测试怎么写。这些事你挨个项目交代很累写在规则里之后AI 每次都会自带这些背景知识。三是项目地图。比如“核心业务逻辑在app/services/公共工具在lib/utils/测试在tests/”让 AI 一进来就知道该去哪找东西。我自己的经验是每条规则尽量一句话说完不要写长段落。AI 处理短句规则的效果比处理长篇大论稳定得多。还有一条很实用的技巧——规则数量控制在 30 条以内太多之后 AI 容易“选择性失忆”反而不知道该遵守哪条。2.3 模型接入官方 API、第三方兼容接口、本地模型Claude Code 默认走 Anthropic 官方接口但工作区里很可能需要接不同的“大脑”。我的做法是通过settings.json里的env字段统一管理环境变量而不是散落在 shell 里。{ env: { ANTHROPIC_MODEL: claude-sonnet-4-5, ANTHROPIC_BASE_URL: https://api.xxx.com/v1, ANTHROPIC_AUTH_TOKEN: sk-xxx } }这里有个很容易踩的坑如果你搭了第三方兼容接口要确认它是 Anthropic 协议格式还是 OpenAI 协议格式。Claude Code 默认说 Anthropic 的语言强行把 OpenAI 格式的接口塞进来大概率会在请求头或者消息格式上栽跟头。对策也简单——要么选经过适配的网关要么像我用本地模型时那样在前面加一层协议转换的网关服务把 OpenAI 兼容的本地端点翻译成 Claude Code 认识的协议。以调用 LM Studio 里的本地模型为例我常用的链路是# 1. LM Studio 启动本地推理服务默认暴露在 1234 端口 # 2. 用一个协议转换网关指向 LM Studio export ANTHROPIC_BASE_URLhttp://localhost:4000 # 网关地址 export ANTHROPIC_AUTH_TOKENlocal # 本地网关通常不校验 token export ANTHROPIC_MODELqwen3-coder这样做的好处是同一个工作区可以随时在不同模型之间切换只需要改settings.json里的env不用改代码也不用重新打开项目。坏处是本地模型的推理速度、指令遵循能力跟云端旗舰模型有差距所以我把本地模型定位成“干杂活”的角色——批量重命名、格式整理、生成测试数据这类体力活儿放在本地跑又便宜又私密真正需要深度理解代码的任务还是切回旗舰模型。2.4 上下文管理窗口再大也经不起乱塞不少教程爱吹“1M 上下文”听起来挺吓人好像什么都能往里装。可真在项目里干活就知道上下文窗口再大也是个有限资源。你塞进去一整个仓库的代码AI 真正“专注”的注意力反而会被稀释回答质量会肉眼可见地下降。我的上下文管理原则有三条第一能用规则文件承载的信息就不在对话里重复。项目规范写在CLAUDE.md里AI 需要时会主动读而不是我每次在 prompt 里啰嗦一遍。第二任务按时切分做完一个阶段就/clear开新会话。旧会话的结论沉淀成文件新会话从文件续接而不是硬拖着一个二万字的对话继续聊。第三让 subagent 去“外挂记忆”。某个角色需要的背景知识写进它的定义文件里它每次被调用时自动加载不占用主会话的空间。Claude Code 自带/compact这类自动压缩功能上下文快满时会自动提炼重点继续干活。我个人的经验是别等它自动触发感觉对话超过一小时主动手动压缩一次提前把关键决策写进记忆文件这比自动压缩更可控。3. 从零搭建多角色 AI 团队配置实操3.1 安装与初始化环境安装本身不复杂我当前用的环境是 macOS VS Code 终端并存但 Claude Code 核心是终端工具所以重点说终端里的配置。# 安装任选一种方式 npm install -g anthropic-ai/claude-code # 验证是否装好 claude --version装完之后先在项目目录里跑一次claude它会自动引导你完成登录/鉴权。这里我要特别强调一个我一直坚持的习惯不要直接往系统环境变量里写 key尤其不要把 key 提交到 git 仓库。正确做法是把密钥写进项目里的.claude/settings.json并且确保.gitignore忽略掉有可能泄露的文件。团队项目还可以用更安全的密钥管理服务让 Claude Code 通过环境读取——方法很多但底线是“密钥不进 git”。跑通之后第一件事就是在项目根目录初始化规则文件claude # 进入交互界面后可以用 /init 生成初始 CLAUDE.md # 也可以直接用编辑器新建 .claude/CLAUDE.md3.2 定义自己的“外包小队”subagent 实战单人带一队 AI最有价值的就是 subagent 机制。它相当于定义一批召之即来的“专项外包人员”每个都专注一个细分领域。我在一个项目里常驻这几个角色资深审查员只读代码、找问题不直接改代码重构专员专门做重命名、拆分函数、抽取公共模块这类结构性调整测试工程师负责写测试、跑测试、汇总失败用例文档写手负责 README、注释、变更日志调研情报员负责查文档、查 API 用法把结论总结回来。每个角色就是一个 markdown 文件放在.claude/agents/下。简化版长这样--- name: reviewer description: 资深代码审查员负责从正确性、安全和可维护性角度审查代码改动只输出审查结论不修改代码 tools: Read, Grep, Glob model: claude-sonnet-4-5 --- 你是一位有 10 年经验的资深代码审查员。收到代码改动后按以下顺序审查 1. 先理解改动意图再检查实现是否与意图一致 2. 检查边界条件异常输入、空值、并发场景 3. 检查安全风险注入、越权、敏感信息泄露 4. 检查可维护性命名、结构、重复代码 输出格式 - 问题清单按严重程度排序 - 修改建议 - 结论通过 / 需修改后再审 绝对不要直接修改代码文件你的职责是审查和提建议。定义好之后我在主对话里调用它干活就像喊一个外包同事reviewer 请审查一下刚才 refactor-billing 分支上的全部改动它就会按自己的规则去读代码、输出审查意见主对话的上下文不会跟着膨胀。这种“专人专事”的做法让整个工作区的效率上了一个档次。3.3 用任务列表做编排把大项目拆成流水线带一队 AI 干大活最忌讳的是“一起上”。多个 AI 同时改同一批文件结果就是互相覆盖、git 冲突满天飞。我的做法是在主对话里用 todo 列表做编排把任务串成流水线。一个典型的重构流程长这样- [ ] 阶段 1由重构专员拆分 payment_service.py拆分结果逐文件列出 - [ ] 阶段 2由测试工程师为拆分后的模块补单元测试 - [ ] 阶段 3由资深审查员审查全部改动输出问题清单 - [ ] 阶段 4我确认后由文档写手更新 README 和 API 文档每完成一个阶段我都会在对话里推进下一步并让 AI 把阶段性结论写进项目里的.claude/记忆文件。新阶段开工前我要先确认前一个阶段的产物真实存在、测试真的通过——AI 偶尔会“幻视”自己跑过测试实际根本没跑。这个坑后面细说。3.4 权限与安全设置别让它乱跑命令默认情况下Claude Code 执行命令前会问你“是否允许”。一个人带了那么多 AI 角色如果每个角色执行每条命令都要你点头那你的“管理工作量”就大了。但反过来如果放权放得太狠AI 可能执行危险命令。我的做法是分层授权{ permissions: { allow: [ npm run test, git status, git diff, ls ], deny: [ rm -rf, git push --force ], ask: [ npm install, git commit ] } }这套配置的逻辑很简单高频、低风险的操作直接允许危险操作直接拒绝连问都不问有风险但有时必须做的操作保留“每次询问”。实际操作中我还会把deploy、migrate这类影响生产环境的命令放进 deny 列表非要执行时手动到终端里跑。这是我对“AI 干活”最基本的底线可以替你写代码但关键生产动作必须掌握在人手里。4. 高频坑位与排查速查表4.1 鉴权报错403、organization disabled 这类问题怎么定位用 Claude Code 最常撞见的就是鉴权类报错。常见提示里有这么一句your organization has disabled claude subscription access for claude code。第一次遇到容易慌其实这类提示的意思是“当前使用的账号/组织没有开 Claude Code 的访问权限”属于组织策略限制不是代码问题。排查步骤我总结成一个固定套路先确认当前实际用的是哪个 key、哪个账号。很多人环境变量里残留了旧 key导致请求根本没走到预期账号检查组织后台里 Claude 相关权限是否对当前账号开放确认ANTHROPIC_BASE_URL指向正确如果用了第三方或本地网关报鉴权错很可能不是账号问题而是网关的 key 配错了最后再看命令行日志claude --debug或打开 verbose 日志看具体是哪一层的鉴权失败。按这个顺序排查90% 以上的鉴权问题五分钟内都能定位到根因。顺便说一句我遇到最多的其实不是账号权限而是环境变量互相覆盖——shell 里一个 keysettings.json里又一个 key最终生效的是其中某一个指向的账号还没权限就会报出各种奇怪错误。4.2 subagent 不干活工具权限与隐藏依赖有时候你明明定义好了 subagent喊它干活它却“只读不改”或者干脆说“我没有权限”。这时候八成不是它偷懒而是定义文件里的tools字段没给够。每个 subagent 能用的工具是白名单制它在自己的规则文件里声明要用哪些工具。比如重构专员需要Edit、Write这类写文件的工具审查员只需要Read、Grep、Glob。我遇到过最尴尬的一次给“测试工程师”只配了读工具结果它看完代码说“建议补充测试”完全不写测试——不是它不想是它工具列表里压根没有Write。解决办法也很简单角色定义文件里把工具列全同时在settings.json的权限配置里给该角色放行相关命令。我习惯在定义文件里加一句“如果你缺少执行任务所需的工具请明确告知不要尝试用工具有限的方式硬做”——这句话能让 AI 在权限不足时主动曝光问题而不是憋着干成半吊子。4.3 模型换着用风格丢失与参数调优如果你像我一样经常在工作区里切换“大脑”一定会发现一个现象同一个任务换了个模型产出风格完全不一样。原来负责审查的角色切到本地小模型之后审查意见明显变浅甚至开始说套话。我目前的调优思路是双轨制对质量要求高的角色资深审查员、重构专员固定用旗舰模型不轻易切对批量杂活重命名、格式整理、生成测试数据才允许切到本地模型或廉价接口。同时角色定义文件里要写清楚“输出标准”比如审查员必须输出“问题清单 严重程度 修改建议”不管背后是哪个模型这个模板不能变。还有一个小技巧第三方兼容接口的模型名称要写对。不同网关对模型名的映射规则千奇百怪写错一个字母请求可能直接失败或者悄悄给你换到默认模型——你以为在用 Qwen实际在跑一个低配底座效果能好才怪。4.4 多会话并行怎么避免“三个 AI 改同一个文件”一个人带一队 AI最刺激的时刻就是开了好几个终端会话每个会话各带一个角色分头并行干活。这套玩法效率很高但翻车也很快。我踩过最大的坑就是三个会话同时改同一个模块改完一看互相覆盖得面目全非。现在我的并行策略是“文件级隔离”在每个会话开工前先明确这个会话的“势力范围”在 prompt 里指定它只能碰哪些文件其他一律只读。本次任务你只能修改 src/billing/ 目录下的文件。 其他目录的文件一律只读资料整理可以读但不许写。 需要跨目录改动时停下来告诉我由我协调。配套措施是开工前先git checkout一个新分支每个会话用独立分支最后我来合并裁决。这样即使某个角色跑偏影响也局限在分支内不会拖垮主干。经过几轮教训我现在对并行 AI 的态度是能串行就串行非要并行必须画清边界。4.5 一些我坚持了很久的习惯个人向最后分享几条我已经固化成肌肉记忆的操作习惯。第一任何 AI 告诉我“已经完成”的任务涉及关键文件的我必须亲眼扫一眼 diff。不是我信不过 AI是 AI 的“完成”和我的“完成”之间经常隔着一层理解偏差。第二每天的 AI 会话结束后花两分钟把当天的重要决策写进CLAUDE.md或者项目里专门的DECISIONS.md。这是给未来的自己和未来的 AI 留遗产比任何“记忆功能”都可靠。第三定期检查 subagent 定义文件看看哪些角色已经不需要了哪些角色的描述跟实际用途不一致。工作区是活的东西不是配一次就完事的。带一队 AI 干活本质上是在建设一套“人机协作的小型组织”。一开始我也不知道该给它多少权限、该定义几个角色、该在哪一步停下自己动手全靠一次次跑偏和踩坑试出边界。你要问我什么最重要我的答案不是工具也不是模型而是“边界感”——知道哪些事完全可以交给 AI哪些事必须自己拍板。把这条想清楚你的工作区才能越用越顺。