我第一次跑通 Claude Code 的时候说实话第一反应不是“AI 真厉害”而是“这东西根本不是一个聊天框它像是一个刚入职、能力很强但不太懂规矩的新工程师”。它能自己翻文件、能跑命令、能改代码、能提交 Git但你要是不给它讲清楚项目规矩它就会自作主张地帮你“优化”掉一些不该动的东西。后来我花了不少时间把 Claude Code 从“一个智能终端助手”调教成“一支能听指挥的 AI 工程团队”——主代理负责调度子代理分别负责实现、测试、评审、文档CLAUDE.md 当团队章程Skills 当技能库权限矩阵当门禁。这篇文章想把我整套配置思路和踩过的坑完整写出来供打算深入使用 Claude Code 的人参考。适合看这篇的人很明确一个人干全栈的独立开发者、想把 AI 编程工作流化的小团队、以及被官方文档里零散的命令搞得头大、想要一套可落地配置方案的工程师。我不会只讲安装重点会放在“怎么把多个 Agent 组合成一个团队机制”这件事上。1. 先把“团队成员”的工位装好Node.js 与 Git 的版本功课很多人装 Claude Code 失败不是 Claude Code 本身的问题而是工位没装好。这个工位就是 Node.js 运行时和 Git 环境。我在不同机器上装过十几次几乎每次出问题都出在这两层。1.1 Node.js 版本不是装上就行得看 18 的要求Claude Code 的 CLI 是基于 Node.js 构建的官方长期支持版本的要求是 Node.js 18 以上。但我的实际体验是如果你手头正好是 Node 18 的某个老版本与其折腾不如直接上 Node 20 或 22 的 LTS。原因很实际Claude Code 内部会加载插件、跑子代理、调用各种系统工具链老版本 Node 在一些原生模块上会出现 OpenSSL 相关的编译或运行错误最常见的就是ERR_OSSL_EVP_UNSUPPORTED。这种报错表面上是 Claude Code 崩了实际上是底层 Node 在做哈希计算时和老版本 OpenSSL 不兼容。检查当前版本的方式很简单node -v npm -v如果版本不够我推荐用 nvm 来管理而不是直接去官网下一个安装包。nvm 的好处是可以在多个版本之间横跳避免你在两个项目之间切换时被 Node 版本卡住。装好之后执行nvm install 22 nvm use 22这里很容易踩一个后续问题你用 nvm 切换 Node 版本后之前通过 npm 全局安装的工具会突然“找不到命令”因为 npm 全局二进制目录和当前 Node 版本的目录绑在一起。后面我会在踩坑记录里专门讲这个问题。1.2 Git 与 shellAI 提交代码和跑命令的底层依赖Claude Code 深度依赖 Git 来做代码回滚、diff 分析和提交信息生成。第一次进入一个新目录时它甚至会主动提示你初始化 Git 仓库。如果机器上的 Git 没装好或者user.name和user.email没配置AI 提交代码时就会报错因为它没有“身份”。我在一台新机器上就遇到过这种情况AI 改完代码想提交结果 Git 直接报Please tell me who you are而 Claude Code 不会替你做这个决定它只会懵在那里反复尝试。所以建议先把 Git 全局身份配好git config --global user.name 你的名字 git config --global user.email youexample.com在 Windows 上还有两个额外细节。第一是 PowerShell 的执行策略默认是 Restricted会拦截 Claude Code 内部需要调用的一些脚本建议在管理员终端里执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser第二是 Git 的行尾配置Windows 上如果core.autocrlf没设对AI 克隆下来的项目可能改一个文件就把整个文件的行尾全变了diff 看起来就像重写了整个文件。建议设置git config --global core.autocrlf inputmacOS 和 Linux 上一般不需要处理行尾但要确保git在 PATH 里并且 shell 能正常启动。Claude Code 执行命令走的是系统 shell如果你用的是 zsh.zshrc里有语法错误Claude Code 跑命令时很可能直接失败而且报错信息还特别隐晦。2. Claude Code 本体安装三种方式选一种别用错地方Claude Code 的安装方式现在主要有三种官方脚本、npm 全局安装、原生安装桌面端。它们不是互斥的但适用场景差异很大。我自己的主力机器上同时装了 npm 版和桌面版前者用来在终端里快速调用后者用来做会话管理。2.1 官方脚本一键装适合 Linux/macOS 主力机在 macOS 和 Linux 上官方推荐的安装方式是通过脚本安装curl -fsSL https://claude.ai/install.sh | bash装完之后二进制会放在~/.local/bin下这个目录不一定在系统 PATH 里。如果你执行claude提示找不到命令八成就是这个原因。解决办法是把下面这行加入你的 shell 配置export PATH$HOME/.local/bin:$PATH脚本安装的版本会自动更新日常使用最省心。但在公司电脑上如果对安全策略比较严格直接管道执行远程脚本这种方式可能会被拦这时候就轮到 npm 方式。2.2 npm 全局安装适合已有 Node 工具链的人如果你机器上已经通过 nvm 管理了 Node.js那直接npm install -g anthropic-ai/claude-codenpm 方式的优点是用npm update -g anthropic-ai/claude-code就能手动升级而且不会在~/.local/bin里留下多余文件。缺点是它依赖 Node 环境换 Node 版本后需要重新 link否则会像前面说的“找不到命令”。一个常见操作是在某个项目里想快速验证某个版本可以用npx直接跑npx anthropic-ai/claude-code这种方式不污染全局环境但每次启动会多一层解析稍微慢一点。我一般只在测试新版本时用。2.3 原生安装与桌面端适合不想碰命令行的使用者如果你用的是 Windows或者实在不想维护 Node 环境可以直接用 Claude Code 的桌面端应用。桌面版自带运行时不需要预先安装 Node它把终端、文件树、会话列表、以及多项目管理工作都做进了图形界面里。热词里出现很多“claude code桌面版”“claude code客户端”说明大家找这个入口找得很勤。安装完成后先跑一下版本验证claude --version能看到版本号就说明安装成功。接下来可以跑一次claude进入交互界面它会引导你完成登录和首次配置。三种安装方式的选择建议安装方式适合场景主要注意点官方脚本Linux/macOS 主力开发机确认~/.local/bin在 PATH 中npm 全局已有完整 Node 工具链切换 Node 版本后要重新 link桌面端Windows / 不愿维护 Node更新走应用内更新配置目录与其他方式一致3. 登录认证与配置目录给 CLI 一个安全可信的起点安装只是万里长征第一步真正让 Claude Code“认人”的是登录认证。这一步做不对后面所有配置都可能找不到正确的用户上下文。3.1 认证方式和会话管理首次运行claude时它会引导你登录。目前主流的登录方式有两种一种是使用 Claude 账号订阅服务直接授权另一种是使用 Anthropic Console 的 API Key。登录之后凭证存在系统的密钥链里正常使用不会再频繁要求重新登录。如果你选择用 API Key 方式可以把 Key 放进环境变量而不是写进任何配置文件export ANTHROPIC_API_KEY你的key这时候要注意如果既登录了 Claude 账号又设置了ANTHROPIC_API_KEY环境变量通常会覆盖账号登录态。实测中出现过一种很迷的情况我明明账号登录成功了但因为旧 shell 里 export 过一个无效 Key导致所有请求都报 401。排查了很久才意识到是环境变量优先级的问题。遇到鉴权类报错时先检查环境变量里有没有ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN这些残留。3.2 首跑生成的配置目录团队档案的骨架就位登录完成后Claude Code 会在你的用户目录下创建一整套配置结构。理解这些目录和文件的用途是往“AI 工程团队”方向配置的第一步~/.claude/settings.json用户级配置管权限、hooks、环境变量。~/.claude/CLAUDE.md用户级长期记忆文件所有项目都会读取。~/.claude/agents/子代理定义目录一个 .md 文件对应一个“团队成员”。~/.claude/skills/技能目录放可复用的技能包。~/.claude/hooks/事件钩子脚本比如在某个命令执行前做检查。项目级目录.claude/项目根目录下创建里面同样可以有settings.json、CLAUDE.md、skills/、agents/。我第一次看到这个结构的时候脑子里一下子就把团队组织方式映射进去了settings.json 是行政制度CLAUDE.md 是员工手册agents 目录是组织架构skills 是培训课程。后面我做的所有“团队配置”本质上都是在往这几个目录里填充内容。4. 团队档案 CLAUDE.md一个文件把成员性格和工作方式定下来如果说 Claude Code 是一群 AI 成员那 CLAUDE.md 就是这群新员工的入职手册。不写这份手册它的表现就是一个“什么都懂一点但什么都不熟的实习生”写了之后它才像一个入职三个月的靠谱工程师。4.1 CLAUDE.md 写给谁看写什么CLAUDE.md 会在每次对话开始时被自动加载也会在 AI 操作文件时被参考相当于整个会话的长期记忆。很多人的误区是把它当成 README 的副本写一堆项目介绍和软件架构图。但 Claude Code 真正需要的是“工作指令”不是“产品介绍”。我建议一个 CLAUDE.md 至少包含这五块内容项目一句话说明和技术栈清单。高频命令安装依赖、启动开发服务、跑测试、构建、部署。目录约定哪些目录是业务代码、哪些是生成物不要动、新代码应该放在哪。编码规范命名习惯、错误处理要求、提交信息风格。常见陷阱在项目里最容易踩的坑比如“数据库迁移脚本不能直接对生产库跑”“某些文件是软链不要删除”。举个实际例子。一个前后端一体项目里我写的 CLAUDE.md 开头大概长这样# 项目概览 这是一个面向小型团队的在线协作白板应用。 技术栈TypeScript、React、Node.js、Prisma、PostgreSQL。 # 常用命令 - 安装依赖: pnpm install - 本地开发: pnpm dev - 运行测试: pnpm test - 数据库迁移: pnpm prisma:migrate # 目录约定 - src/services 放业务逻辑路由层只做参数校验 - src/generated 是由工具生成的代码禁止手动修改 - 新业务模块先在 src/services 下建文件再在路由层注册 # 编码规范 - 函数命名用动词开头变量命名用名词 - 禁止在 catch 里直接吞掉错误必须记录日志后重新抛出 - 提交信息使用 conventional commits 格式 # 常见陷阱 - 本地开发连接的是 localhost:5432 的测试库不要改成生产连接串 - public 目录下某些静态资源是运行时生成的不要手动编辑 - 修改 Prisma schema 后必须执行 pnpm prisma:generate否则类型不更新加上这份档案之后最明显的变化是 AI 生成的代码终于不再“看着像样但跑不起来了”。它能记住用 pnpm 而不是 npm能记住不碰 generated 目录能记住提交信息的格式。这些细节如果你不写它就每次都要猜。4.2 多层级 CLAUDE.md 的优先级Claude Code 支持用户级和项目级两种 CLAUDE.md而且它们会同时生效。我的用法是用户级~/.claude/CLAUDE.md写“通用工作偏好”比如“我习惯先写测试再写实现”“遇到不确定的设计问题不要直接开写先给我三个方案”。项目级.claude/CLAUDE.md写“这个项目的具体规则”。两级叠加之后AI 的行为就变成“既知道这个人喜欢怎么工作又知道这个项目该怎么处理”。很多让我惊艳的时刻都发生在它主动遵循用户级偏好的时候比如我让它修一个 bug它修完后顺手补了测试因为它知道这是我的习惯。另外如果某个子代理负责特定领域可以给子代理单独指定 CLAUDE.md或者直接在子代理定义里写明它该遵循的规则。这个技巧在下一章会详细展开。4.3 把决策记录也写进去我还习惯在 CLAUDE.md 里维护一个“决策记录”小节。每次 AI 做了一个技术选型或者我拍板定了一个方案就让 AI 把结论和理由追加进去。比如# 决策记录 - 2025-06-01: 后端改用 Prisma 作为唯一 ORM禁止再写裸 SQL。 - 2025-06-15: API 返回结构统一为 { code, data, message }。效果很直接下次新会话开始时AI 不需要重新问“这里为什么不用 SQL”它直接看到决策记录就知道边界在哪。这对于跨会话的团队协作非常重要毕竟每个 AI 会话都是新的“上班第一天”。5. 给每个“专家成员”分配子代理与 Skills团队能力矩阵落地CLIUDE.md 解决的是“团队章程”问题但一个团队不能只有章程还得有不同角色的人。这里就要用到两个核心机制子代理Subagents和技能Skills。5.1 子代理机制在主线之外开辟专用工作线程子代理是 Claude Code 里一个非常重要的概念。简单说主对话是“主工程师”子代理是“被主工程师临时请过来的专家”。主工程遇到需要跑测试的时候可以调用 tester 子代理需要评审代码的时候可以调用 reviewer 子代理。每个子代理有独立的系统提示、独立的任务描述甚至可以限制它能用什么工具不能用什么工具。子代理的定义方式是创建一个 Markdown 文件放在~/.claude/agents/目录文件名就是代理名。文件头部用 YAML frontmatter 写元信息正文写角色描述。下面是我在项目里实际用过的一个测试工程师子代理--- name: tester description: 负责运行测试、分析失败原因并修复测试代码。适合在业务代码改动后调用。 tools: Read, Grep, Glob, Bash(pnpm test:*), Edit --- 你是一名测试工程师。你的职责是保证测试套件稳定通过。 工作流程 1. 先运行 pnpm test 查看当前测试状态。 2. 如果有失败用例先定位是业务代码问题还是测试代码问题。 3. 如果是测试代码问题直接修复测试文件。 4. 如果是业务代码问题只输出失败原因分析不要修改业务逻辑。 5. 无论结果如何最后输出一份简洁的测试报告。这里的关键是tools字段。我故意没有给 tester 开所有编辑权限只让它能编辑测试文件相关的内容这样它在实际执行中就不会越界去改业务逻辑。配置完成后在主对话里输入tester 帮我跑一下用户模块的测试Claude Code 就会把这个任务交给 tester 去执行并在完成后把结果汇报回主对话。5.2 Skills把可复用的流程打包成技能Skills 和子代理是配合使用的关系。子代理定义“谁来做”Skills 定义“能调用什么能力”。每个 Skill 是一个目录放在~/.claude/skills/或项目级.claude/skills/下。目录里至少有一个SKILL.md文件描述技能的使用场景和步骤也可以附带模板文件或脚本。举个例子我写了一个“生成 Changelog”的 Skill--- name: changelog description: 根据 git log 生成标准化的 CHANGELOG.md 内容。 --- 1. 运行 git log --oneline --since7 days ago 获取最近一周提交。 2. 对每条提交根据 conventional commits 的类型归类 - feat: 新功能 - fix: 修复 - docs: 文档 - refactor: 重构 3. 将结果追加到 CHANGELOG.md 顶部格式为 ## [日期] - 版本号 ### 新增 / 修复 / 变更 4. 如果没有 recent commits直接输出“无变更”。之后我在对话里说“按 changelog 技能更新一下版本记录”AI 就会自动按这个流程跑。不用每次重新解释步骤。社区里也有现成的 Skills 可以装。我现在常用的几个包括代码评审 Skill把当前分支 diff 拉出来逐个文件检查潜在问题。提交信息生成 Skill根据 diff 生成符合 conventional commits 的提交信息。测试生成 Skill为新功能模块自动生成测试骨架。5.3 团队能力矩阵我实际用的配置组合把子代理和 Skills 组合起来我就搭出了一套轻量级的“四人团队”角色职责常用工具 / 技能主工程师接收需求、拆分任务、综合决策全部基础工具测试工程跑测试、修测试、输出报告Bash(pnpm test:*), Edit代码评审检查 diff、提问题、打分Read, Grep, Glob, review skill文档写作更新 README、CHANGELOG、技术文档Read, Edit, changelog skill实际使用中我会在同一个会话里连续呼叫多个子代理。比如先让主代理实现一个功能然后立刻调用 tester 跑测试再调用 reviewer 审查 diff最后一并提交。整个过程很像在一个小型敏捷团队里流转任务。6. 权限矩阵给 AI 成员划定“能做和不能做”的边界AI 团队成员能力再强也得有边界。没有权限控制的 Claude Code就像给了实习生服务器 root 密码虽然大多数时候不会出事一旦出事儿就是大事。所以配置权限矩阵是构建 AI 工程团队时绝对不能跳过的一步。6.1 权限模式理解四种运行状态Claude Code 提供了几种权限模式通过claude --permission-mode或者在项目的 settings.json 里配置。我用下来最直观的理解是默认模式常用操作会被自动批准危险操作会弹窗询问。acceptEdits自动接受所有文件编辑不需要逐个确认。适合在已经信任的项目里跑批处理任务。plan只读模式AI 只能分析和规划不能改文件、不能执行命令。适合做代码评审和技术方案设计。bypassPermissions完全绕过所有权限确认所有操作直接执行。这是最危险的模式。我自己平时主要用默认模式和acceptEdits只有在对一个项目非常熟悉、而且已经提交过代码、能随时回滚的时候才会临时开acceptEdits。plan 模式用于给不熟悉的代码库做体检绕过模式基本不在日常开发中用。6.2 用 settings.json 做白名单与黑名单比全局模式更精细的是命令级别的白名单和黑名单。在项目的.claude/settings.json里可以这样写{ permissions: { allow: [ Bash(npm run lint), Bash(git status), Bash(pnpm test:*), Read(~/work/my-project/src/**), Edit(~/work/my-project/src/**) ], deny: [ Bash(rm -rf *), Bash(git push --force), Edit(~/.ssh/**) ] } }allow 里面我用的是通配符Bash(pnpm test:*)表示所有以pnpm test:开头的命令都可以直接执行不需要每次都问。deny 里面是几个高危操作。实际运行中你会发现allow 规则写得太死AI 干活会频繁卡在权限确认上很烦写得太宽又等于没管。我的经验是先放开项目目录内的读和编辑权限命令类权限只放开与当前项目相关的常见命令其他命令让它弹窗问。跑几天之后根据实际弹出的授权请求再把那些“确实安全且高频”的命令加入白名单。6.3 安全实践密钥保护与 hooks 兜底很多人在 settings.json 里直接写环境变量这不是好习惯因为配置文件可能被提交进 Git 仓库。正确做法是用系统环境变量或者在~/.claude/settings.json里配置env字段但值不从明文文件里读取。另外Claude Code 的 hooks 机制可以给权限系统加一道兜底。比如我写过这样一个 PreToolUse hook拦截危险命令#!/bin/bash if [[ $CLAUDE_TOOL_USE_NAME Bash ]]; then case $CLAUDE_TOOL_USE_INPUT in *git reset --hard*) echo 禁止执行 git reset --hard exit 2 ;; esac fi exit 0把这段脚本放到~/.claude/hooks/目录并在 settings.json 里注册对应事件即使 AI 通过某种方式试图执行危险命令也会被钩子拦下来。对于一个“AI 团队”来说这是最后的保险丝。7. 集成到 VSCode 与桌面端让团队在编辑器里直接运转Clauaude Code 用起来最顺手的场景还是在编辑器里。热词中“vscode配置claude code”和“claude code桌面版”的搜索量一直很高说明这是大部分人的第一道门槛。7.1 VSCode 插件配置让 CLI 和编辑器共用一套配置在 VSCode 扩展市场里搜索 “Claude Code”安装官方插件后建议做两件事第一确认插件能找到claude可执行文件。如果你是通过 npm 全局安装的插件通常能自动识别如果提示找不到就手动指定二进制路径。这个路径可以用which claude查到。Windows 上则是where claude。第二插件和 CLI 共用同一个配置目录~/.claude。这意味着你在终端里写的 CLAUDE.md、配置的子代理、设置的权限规则在 VSCode 里打开 Claude Code 面板时全部生效。实测下来最舒服的工作流是在 VSCode 里选中代码、让 AI 解释然后在集成终端里跑完整交互会话两边不冲突。一个值得注意的点VSCode 插件跑任务时上下文不会自动带上你当前打开的文件。如果你想让它分析当前文件要么在对话里文件名明确引用要么把文件内容贴进上下文。不要指望它“读心”。7.2 桌面端多项目会话的集中管理如果你同时维护多个项目桌面端是比终端更合适的入口。桌面版把每个项目抽成一个独立会话卡片你能看到哪个项目还挂着进行中的任务也可以随时暂停、恢复。和 CLI 一样桌面端读取的也是同一套~/.claude配置所以你不用为桌面端重复配置一遍团队规则。我在桌面端的习惯是给每个项目建一个固定的会话命名成“user-authentication模块开发”这样隔几天回来还能通过--resume或界面上的历史列表接着干上下文不会丢。7.3 实测一个完整的“派单-编码-评审-提交”流程我把这套流程固化成了一个实际的开发循环在项目根目录建一个todo.md需求文件写下本周要做的任务。主代理读取任务拆分出子任务逐一分配给子代理。implementer 子代理完成代码修改自动跑pnpm test。reviewer 子代理对照 todo 逐项检查完成度输出问题清单。主代理根据问题清单让 implementer 迭代修复。全部通过后主代理生成 conventional commit 并推送。整个过程里我本人只做两件事审核需求文件和最终 review diff。AI 团队成员把中间过程全部消化掉了。这种工作方式在以前是不可想象的但现在几乎成了我的默认开发节奏。8. 把 AI 团队嵌入真实开发流程评审、自动化与工作日志前几章说的都是配置能力这一章讲怎么把这些能力真正接到日常开发和团队协作流程里。毕竟 AI 团队不能只在你手动敲命令的时候存在它应该融入到 Git、CI、文档这些常规动作中。8.1 用非交互模式做代码评审和检查Claude Code 支持claude -p形式的非交互执行能够直接调用一个任务然后输出结果。这是做自动化的关键。比如在提交 PR 之前我会手动跑claude -p 请 review 当前分支相对 main 的 diff重点检查1. 是否有安全漏洞2. 是否有明显的性能问题3. 是否符合项目的编码规范。输出问题清单不要修改代码。 --output-format json输出 JSON 格式可以直接被脚本解析再配合命令行工具把结果贴到 PR 评论区。把这条命令放进 npm scripts就能形成标准动作{ scripts: { ai:review: claude -p \请 review 当前 diff输出问题清单不要修改代码。\ } }8.2 用 Git hooks 把 AI 嵌进工作流Git hooks 是让 AI 团队“被动参与”开发流程的好方法。我主要用两个pre-commithook在提交前让 AI 检查暂存区里有没有明显问题比如不小心提交了密钥、调试日志或者生成的构建产物。如果发现问题直接阻止提交。prepare-commit-msghook让 AI 根据 diff 生成符合 conventional commits 的提交信息。这样我只需要跑git commit剩下的描述交给 AI。写好 hook 脚本后放在.git/hooks/目录下并给脚本加上执行权限。注意 hooks 目录不会随仓库同步如果团队要共用可以把脚本放到项目里的scripts/hooks/目录然后用一个 setup 脚本把它们复制过去。8.3 团队工作日志让上下文跨会话延续AI 会话本身有上下文上限长任务跑到一半前面的内容就可能被截断。我有一次做大规模重构AI 弄到一半就没上下文了而且新的会话完全不记得之前做了什么。从那以后我开始维护一个WORKLOG.md。规则很简单每个任务结束后让 AI 用几句话把已完成的工作、关键决策、下一步计划追加到.claude/WORKLOG.md。下次新会话开始时只读这个文件就能快速恢复“记忆”。这比依赖一门心思保存会话上下文要可靠得多也顺便解决了多人协作用同一台机器时的上下文交接问题。9. 踩坑记录配置过程中值得记录的 7 个问题配置 Claude Code 的过程中我几乎把能踩的坑都踩了一遍。下面这几条是最有代表性、也最常被群里人问到的整理出来供你排查时参考。9.1 安装脚本中断与 PATH 问题官方脚本装到一半中断最常见的原因是网络不稳定或者目标目录没有写权限。重装之前先把~/.local/bin/claude和~/.claude/里残留的安装文件清理干净再重新跑脚本不要直接覆盖否则会出现“装了但版本号是旧的”这种灵异现象。9.2 nvm 切换 Node 版本后“claude: command not found”这个我在前面提过。npm 全局工具安装时会把可执行文件放进那个 Node 版本对应的全局 bin 目录。你切到另一个 Node 版本后PATH 指向的就变了自然找不到。解决办法是用当前版本的 Node 重新装一次或者执行npm link anthropic-ai/claude-code创建新的软链。9.3 权限弹窗太频繁AI 干活效率低下默认模式下AI 每执行一次文件编辑就可能弹一次确认窗口。频繁授权会严重打断流程让人怀疑“到底是我在写代码还是它在写”。解决方法是把高频且无害的命令和文件编辑加进项目级 settings.json 的 allow 列表。我一般先跑一个中等规模任务把弹窗时确认过的命令记录下来然后批量加白名单。9.4 上下文过长反而降智Claude Code 虽然能加载大量上下文但塞得太满时响应质量和速度都会下降甚至会忘记最早的任务目标。我现在会刻意控制单次任务的复杂度一次会话只聚焦一个模块不要让 AI 一口气重构整个项目。如果需要大范围改动先把任务文档化再让 AI 按步骤来。9.5 会话崩溃导致进度丢失长会话跑到一半终端崩溃是非常打击信心的事。Claude Code 有会话恢复机制命令是claude --resume它会列出历史会话让你选择。但恢复并不是 100% 无缝一些中途修改过的文件内容不会自动回到上下文中。所以重要节点一定要让 AI 更新 WORKLOG并且尽早提交代码。9.6 多个项目之间配置互相污染如果你的用户级 settings.json 里写了一个项目的精准 allow 规则在另一个项目里用同一个用户配置可能会出现授权过宽或过窄。最稳妥的做法是通用偏好放用户级和具体项目强相关的规则一律放项目级.claude/settings.json。同时项目级配置要提交进 Git方便团队其他人同步。9.7 AI 请求量超过预期成本失控把 Claude Code 当团队用之后API 调用量会比预想高很多因为每个子代理的任务都会消耗 token。我的控费建议是机械性任务优先用更小更快模型通过子代理的 model 字段指定遇到高难度的架构分析才让主代理使用更强的模型不要一上来就把整个仓库交给 AI 去读先用 Glob 和 Grep 定位相关文件再让 AI 精确读取。这一步省下的成本非常可观。把 Claude Code 配置成 AI 工程团队不是一个“装好就能用”的状态而是一个持续迭代的过程。我是从最简单的 CLAUDE.md 开始写了一页纸的项目说明书用完一周之后开始加第一个子代理 tester跑了两周之后才逐渐补齐了权限矩阵、Skills 和 hooks。你不用一步到位先让它比普通助手多做一件事——记住你的规矩然后再慢慢往里面加角色、加技能、加工作流。最终你会发现它不再是一个需要你逐条下达指令的工具而是一个能接住任务、自己拆解、自己执行的协作对象。