1. 先从定位讲起Claude Code 到底该放进你工作流的哪一层我一直有个观点Claude Code 这类工具的上限不取决于模型本身强不强而取决于你把它放在开发流程的哪个位置。很多人拿到手就让它写代码写了半天发现改来改去还是在原地打转于是得出“这玩意儿不靠谱”的结论。实际上问题不在工具在定位。在开始任何配置之前先想清楚一个问题你希望它在你的工作流里扮演什么角色。大概有三种典型用法。第一种把它当临时顾问。你遇到一个不熟悉的技术栈、一段看不懂的老代码、或者一个诡异的报错把上下文丢给它让它给分析、给思路、给改法。这种用法不需要任何权限配置不需要项目记忆文件装好就能用价值也很直接。第二种把它当结对程序员。你写需求它写实现你写测试用例它写代码你写代码它写 review 意见。整个过程是双向对话每一行代码你都过目、都理解它只是帮你把打字速度提升了一个量级。这种用法需要一点配置但不多核心是项目记忆文件和权限边界。第三种把它当自动驾驶。你给它一个完整需求让它自己拆任务、自己列计划、自己改代码、自己跑测试、自己修 bug——你在旁边当监工只在关键时刻踩刹车。这种用法对配置的要求最高也是最容易翻车的。我见过不少新人一上来就冲第三种去结果要么是代码质量失控要么是权限给太大AI 把不该动的文件改了回头还得靠版本控制来救命。所以我在这个系列的前两篇反复强调Claude Code 的“全链路配置”核心不是把工具装到能用而是把工具放进一个受控的工作流里。那到底什么是“全链路”我个人的理解是从环境准备、鉴权、全局配置、项目级记忆、权限边界到和 Git 工作流的耦合、和代码审查流程的衔接再到日常任务的实际执行——这一整条链路每一环都知道自己该干什么AI 才能稳定地输出价值。这篇文章就把这条链路完整走一遍每一步讲清楚为什么这么做以及我把哪些环节调到自己顺手的状态。2. 安装和环境校验装好不等于能用先过一遍最小可用路径很多人装完工具就急着开干结果第一句话就报错然后开始怀疑人生。其实 Claude Code 的安装本身不复杂麻烦的是装完之后的环境校验。这一节把最小可用路径捋一遍。2.1 安装前置条件Claude Code 作为一个命令行工具依赖本地的 Node.js 环境。我的建议是 Node 的版本别太老官方文档写的是要求某个长期支持版本以上但我的实际体验是尽量用当前主流的 LTS 版本太老的版本在某些输出解析上会有兼容问题而且一旦出问题报错信息往往不太直观排查起来很费劲。确认好 Node 环境之后安装就是一条命令的事npm install -g anthropic-ai/claude-code这里有一个小细节如果你用的是公司内网镜像源安装一般没问题但后续的版本更新会走同样一条路。我习惯在安装完看一眼版本号claude --version如果正常输出版本号说明安装这步已经通了。2.2 密钥配置别把密钥写进项目里安装只是第一步让工具能真正调用模型服务还需要配置访问凭证。这一步我用的是环境变量的方式export ANTHROPIC_API_KEY你的密钥在 Linux/macOS 下建议把它写进 shell 的配置文件比如.bashrc或.zshrc而不是每次手动 export。Windows 下则可以用系统环境变量面板来设置。这里我说一个比较重要的经验环境变量方式适合个人开发但如果你在多台机器之间同步配置或者有团队协作的需求更好的方案是使用工具自带的登录鉴权流程或者把密钥托管到本机的密钥管理服务里CLI 配置里直接引用那个服务的句柄。我不太建议把密钥明文写进任何会被版本控制追踪的文件尤其是项目目录下的.env文件——我知道很多人习惯这么干但一旦仓库泄露密钥就等于裸奔了。2.3 最小可用路径的验证配置完密钥之后别急着干正经活先跑一个最小验证claude 用一句话介绍你自己这一步的目的不是测试模型聪明不聪明而是确认三件事安装路径没问题、密钥鉴权能通过、模型服务的响应链路是通的。如果这一步能正常输出那环境就已经可用了。我遇到过一种很典型的“环境假死”情况命令行执行后没有任何输出也不报错光标就那么一直闪。这种时候先不用怀疑配置大概率是网络层面的问题。对应的我建议先确认当前环境的网络访问是通则再做下一步。这类问题我在后面的常见问题部分还会展开说。3. 三级配置的合并规则全局、项目、CLI 参数怎么排优先级装好工具、配上密钥之后接下来要面对的是配置体系。Claude Code 的配置不是单一文件而是分层的。搞清楚每一层是干什么的、谁覆盖谁是“全链路配置”的骨架。3.1 三层配置各自长什么样我按自己的使用习惯把配置分成三层全局配置存在用户主目录下影响这台机器上所有项目的会话。放那些你任何时候都不希望被覆盖的偏好比如默认模型、输出格式、通用权限策略。项目配置存在具体项目的.claude目录下会跟着仓库走。放那些只针对当前项目的约定项目的技术栈偏好、目录结构说明、可用的脚本命令、需要规避的文件路径。命令行参数每次会话启动时临时指定优先级最高。比如我有时会临时指定一个更强的模型参数跑复杂任务但不会把这个参数写进全局配置因为不是每个任务都需要它。这三层之间的关系我习惯用一句话来记越靠近命令行的越能覆盖远离命令行的。3.2 合并顺序的实践对照我画一张表方便你理解配置的合并顺序配置层级存放位置典型用途优先级全局用户主目录下的配置目录默认模型、全局权限、输出偏好低项目项目根目录的.claude目录项目说明、工具约束、本地脚本中命令行启动时附加参数临时切换模型、调整输出格式高这个优先级顺序是有讲究的。全局配置是“兜底”保证你随便进哪个项目都有一套可用的默认行为项目配置是“定制”让 AI 进入某个仓库时自动切换成该仓库的上下文命令行参数是“临时的例外”只在当前这次会话生效不污染其他配置。有一个细节值得注意项目配置是跟仓库走的也就是说它会进入版本控制。这是一个双刃剑——好处是团队成员共享同一套约定坏处是如果有人在里面写了相对路径的敏感信息等于把秘密提交进了仓库。我在实际使用中会把项目配置里涉及本地路径的部分全部用相对路径或环境变量引用避免团队成员的运行环境不一致导致配置失效。3.3 配置项里值得优先关注的几个字段settings.json 里有几个字段我几乎是每次新环境都要确认的model默认用的模型版本。我一般不会把这里设成最强的因为很多简单任务不需要那么强的推理能力设一个性价比高的默认值把强模型留到命令行参数里按需调用能省不少时间和成本。outputStyle输出风格。如果只是客观、可解析的回答我很在意输出格式的一致性和信息密度。permissions这块我单独在第 5 节展开先记住一个原则默认越严格越好。4. 项目记忆文件让 AI 从“懂代码”变成“懂你的项目”配置体系里我认为价值被低估最多的是项目记忆文件。很多人不知道有这个东西或者知道但从来不维护。实际上Claude Code 在项目里的表现很大程度取决于你有没有把项目的“潜规则”告诉它。4.1 记忆文件为什么比代码本身更重要代码本身AI 是可以读的。但它读到的只是“现在是什么样”而不是“为什么是这个样”。举个很常见的例子你进到一个老项目里发现某个模块的命名风格和标准规范不一样代码里也没有注释说明原因。AI 如果只读代码它就不知道这是历史包袱还是刻意的设计于是它在生成新代码时会“好心”地帮你统一成标准风格——结果你把一组互相依赖的接口全改乱了。记忆文件要解决的就是这个问题把代码里看不出来的项目背景、设计决策、约定俗成提前告诉 AI。我在项目的CLAUDE.md文件里一般会写这几类内容项目概述这个服务是做什么的服务谁 技术栈使用的主要框架、语言、运行环境 目录结构哪些目录是核心逻辑哪些是自动生成的哪些绝对不能动 开发命令测试怎么跑、构建怎么跑、有没有特殊的调试入口 代码约定命名规范、错误处理方式、注释语言 历史包袱哪些地方“看着不合理但你别动”4.2 用什么粒度来写记忆文件有一种常见的误解记忆文件写得越多越好。我曾经也觉得这是个“喂给 AI 的资料库”后来发现不是。写太多AI 在读取时反而会抓不住重点写太少又起不到约束作用。我的经验是控制在一屏到两屏之间而且要分层。第一层是“会话开始时自动加载的短说明”通常 200 到 400 字讲清楚项目是什么、技术栈是什么、动代码前必须注意什么。第二层是“需要时按路径提示加载的长说明”可以是一份详细的架构文档或者一份约定清单AI 在遇到相关任务时会主动去查。有几个地方我认为是必须写的项目里有哪些命令是不能随便跑的。比如某些脚本会清理数据库、某些命令会触发线上发布。AI 如果不知道这些你让它“帮忙跑一下测试”它可能顺手就把旁边的生产脚本给执行了。哪些目录是生成物。AI 经常犯的一个错误是去“修复”自动生成的代码改了半天一生成又没了。在记忆文件里明确写清楚哪些目录是生成物、哪些是真源码能省下大量的无效沟通。你对代码风格的主观偏好。比如你习惯用中文注释还是英文接口命名偏好动词开头还是名词开头这些属于项目约定但对 AI 来说只能靠记忆文件去约束。4.3 记忆文件需要动态维护还有一个容易被忽略的点记忆文件不是写一次就完了。项目结构会变、命令会变、技术栈会演进记忆文件如果过期反而会误导 AI。我自己的习惯是每次项目发生结构性变更时比如新增一个大的模块、换了一个构建工具、引入一个新的框架顺手更新一段到记忆文件里保持它和当前代码的真实状态同步。另外我会在每次重要会话结束前让 AI 自己总结“这次会话生成的代码和现有代码的关系”再决定要不要把这层关系沉淀到记忆文件里。很多有价值的信息就是在这些边角对话里产生的。5. 权限与沙箱哪些操作要放权哪些必须拦下来配置里我最看重的一块是权限设计。Claude Code 这类工具的最大风险不是它能力不够而是它权限太大——你给了它操作文件系统、执行命令、读写环境变量的能力它可能在不恰当的时机干出不恰当的事。5.1 权限模型的基本逻辑Claude Code 在读取项目时默认能访问项目目录内的文件但涉及系统命令、文件修改、环境变量等操作会触发权限确认或拦截取决于你设置的权限模式。我把这套逻辑理解为四个层次只读AI 可以看代码、读文件但不能修改任何东西也不能执行命令。适合做分析、做 review。询问AI 在做修改或执行命令之前会先询问你等你点头才继续。这是我最常用的一层。白名单事先声明哪些命令可以自动执行不用每次问。比如npm test、git status、python -m pytest——这些高频、低风险的操作进白名单能省掉大量无效确认。放行AI 可以自由执行命令和改文件不需要经过你。除非你在跑一个非常自动化的批处理任务否则我不建议长期开这个。5.2 我在实际项目里怎么设置以我自己在某个内部工具的日常开发为例我会在项目配置文件里维护一个白名单{ permissions: { allow: [ npm run test, npm run lint, git diff, git status, python -m pytest ], deny: [ rm -rf, git push --force, npm publish, dropdb ] } }我没见过有人这么用 JSON 写但意思大致是这样。核心思路是高频、低风险、可重复的命令放进去破坏性、不可逆的命令直接禁用额度剩下的全部默认询问。这里有个很实际的经验白名单命令不仅匹配命令本身还要注意参数展开。比如我允许了git push但如果参数里混进来git push --force我是希望它拦截的所以白名单的匹配规则要足够严格必要时用通配符精确控制而不是“命令前缀匹配就算放行”。5.3 你不希望 AI 碰的东西除了命令还有一类需要拦的是文件路径。我会在权限设置里明确禁止 AI 访问项目目录之外的路径比如系统配置、Shell 配置文件、密钥文件。不要觉得 AI “反正不会自己去找”——当它接到一个任务比如“帮我检查环境变量对不对”它完全可能去读取你的 shell 配置文件然后把内容输出到回复里。这个过程本身没有恶意但信息泄露的风险是真实的。另一个容易被忽略的场景是外部服务。AI 执行命令时如果命令本身会触发对某个服务器的请求——比如自动部署脚本、依赖安装命令、数据库迁移——你需要在白名单上把这类命令单独设一道确认而不是简单放行。6. 一个完整任务的实战复盘从需求描述到通过的测试前面讲了这么多配置这一节拿一个真实的任务进程来复盘看看“全链路配置”在一条完整开发链路里到底是怎么配合的。我拿一个虚构但不失真的场景一个内部团队的“任务工单面板——简单的命令行提醒工具”。需求很简单用户能添加一条带截止时间的提醒到时间后终端里弹出一条通知。6.1 需求描述与实际拆解我先在会话里扔给 Claude Code 一段需求描述做一个命令行待办提醒工具支持添加任务、查看未完成任务列表、标记完成。任务有截止时间到了时间在终端给我弹个提醒。这个需求如果直接丢给 AI它可能按自己的理解直接开写结果写出来的东西不一定合我意。所以我在描述里加上了上下文约束项目是一个 Node.js 命令行工具使用 thanos 风格、轻量级依赖不要引大型框架。请列出你理解的业务规则并提问你需要的澄清点然后再给实现方案。这一步的意义在于我在把“需求”转成“任务”。AI 需要先展示它理解了什么我来修正然后再进入编码阶段。它列出的澄清点包括提醒是在运行中的终端弹出还是通过系统通知任务数据存在本地文件还是内存里过了截止时间的任务是标记逾期还是自动置顶删除任务的功能需要吗这些问题看似细碎但都属于“需求文档里没写但实际做起来一定要定的事”。这个前置的确认环节比后面写出多少行代码都重要。6.2 生成代码与迭代修正确认完业务规则后我让它先给目录结构和模块划分再说实现方案最后才写代码。这样做的原因是我希望代码落在“项目的整体上下文里”而不是一个孤立文件。AI 给出的建议是拆成几个模块一个负责任务存储一个负责时间调度一个负责终端展示。之后是常规的写代码、跑测试、修 bug 循环。在这个过程里我发现它写的一个文件里使用了较长链式调用来处理任务状态转换读起来不够直观。我提出意见让它改成表驱动的方式它在几十秒内就完成了重构。接着我让它在测试里补上“截止时间到了之后提醒只触发一次”这个边界用例它自动生成测试并跑通。6.3 复盘时间都花在哪了整个过程中真正有价值的是最后复盘。我统计了一下如果把任务拆成“需求澄清 10%、方案设计 15%、代码生成 45%、测试修正 20%、代码 review 10%”那么——真正让 AI 写代码本身是最快的一步几乎不占时间。时间主要花在澄清需求、确认方案和修正测试这三个环节。这给了我一个比较明确的判断Claude Code 的“AI 驱动开发”本质上不是“AI 自动写代码”而是“人类把需求讲清楚、AI 把实现写出来、人类再把把关”。你越能在需求描述和验收标准上花工夫后面代码生成和修正的链路就越短。7. 和 Git 工作流搭在一起提交信息、Code Review、批量操作Claude Code 单聊代码生成只是基本操作真正让开发效率上台阶的是把它放进 Git 工作流里。7.1 生成提交信息与变更说明我现在的习惯是代码改完之后让 Claude Code 先看一下git diff然后让它按项目约定的格式生成提交信息claude 请根据当前 git diff 生成符合项目规范的 commit message要求区分 feat/fix/refactor 类型并简要说明变更原因这里有一个好处AI 会读完整段 diff而人通常只记得自己改了什么。很多时候我改完一个文件就忘了自己还顺手调整了另一个地方的格式Commit message 反而漏了它。AI 读 diff 生成信息能把这种“边角修改”也纳入提交记录提交历史的完整性好了不少。7.2 让 AI 做第一轮 Code Review在我提交代码前我会先让 Claude Code 自己做一轮 review。它给我输出的内容通常包括潜在 bug、边界情况、命名一致性、遗漏的错误处理。说白了它没法替代人类做架构评审但作为第一轮“自动冒烟”能把低级问题和风格问题提前过滤掉。实战中我比较常用的一种方式是请 review 最近一个 commit 的代码变更按以下维度输出正确性风险、边界情况、可维护性、命名一致性。只提建议不要改代码。这个“只提建议不要改代码”非常关键。如果不加这条AI 可能会顺手把代码改了然后给你一份“我已经帮你优化”的结果——这种主动是好事但有时会影响代码结构我反而要多花时间去核对它的改动是否合适。7.3 批量重构的小心机批量重构是 AI 很擅长的场景但也容易出问题。比如我需要把一个旧 API 的调用方式统一改成新 API涉及十几个文件。这种纯机械的重构AI 几乎不会出错但它会忽略“不应该被重构成新 API 的特殊文件”。我会在任务描述里加一条以下文件已在白名单中不要修改legacy/、generated/、third_party/让 AI 明确知道边界在哪比最后逐个检查 diff 要省力得多。不过要提醒一句批量重构一定不要只信 AI 你的自查跑完重构马上跑测试和 lint然后把 diff 从头到尾看一遍。没有这层防护任何工具都可能会在你不注意的地方产生意想不到的偏移。8. 我最终保留下来的配置和日常使用习惯最后分享几个我自己长期保留的配置习惯篇幅不长但都是我踩坑踩出来的。第一个习惯是全局配置里只留稳定偏好不留临时需求。我的全局配置里只有默认模型、输出格式、以及一个比较严格的默认权限策略别的都放项目级配置里。这样可以避免“这台机器上某个项目好使换个项目就各种报错”的混乱。第二个习惯是权限白名单宁少勿多。初期我会频繁把高频命令加入白名单后来发现失误往往都出在“太过放心的那个命令上”。现在白名单只保留了十几个经过几个项目验证的低风险命令其余操作统一走确认流程。第三个习惯是每次大任务结束前做一次记忆文件同步。我让 Claude Code 自己总结这次会话接触到的项目上下文、产出的变更、发现的注意事项由我决定哪些沉淀进项目记忆文件、哪些丢进版本控制说明。这个习惯一方面保持项目记忆文件的新鲜度另一方面也让我自己对任务全景保持掌控。对我来说Claude Code 的“全链路配置”不是一个一次性工程而是一套持续调优的工作流。它没法替你决定项目该怎么做但你给它定好边界、喂够上下文、管好权限之后它确实能帮你把那些耗时的、重复的、低认知负荷的环节大幅压缩。剩下的时间你可以拿去做真正需要人来做判断的事。
1. 先从定位讲起Claude Code 到底该放进你工作流的哪一层我一直有个观点Claude Code 这类工具的上限不取决于模型本身强不强而取决于你把它放在开发流程的哪个位置。很多人拿到手就让它写代码写了半天发现改来改去还是在原地打转于是得出“这玩意儿不靠谱”的结论。实际上问题不在工具在定位。在开始任何配置之前先想清楚一个问题你希望它在你的工作流里扮演什么角色。大概有三种典型用法。第一种把它当临时顾问。你遇到一个不熟悉的技术栈、一段看不懂的老代码、或者一个诡异的报错把上下文丢给它让它给分析、给思路、给改法。这种用法不需要任何权限配置不需要项目记忆文件装好就能用价值也很直接。第二种把它当结对程序员。你写需求它写实现你写测试用例它写代码你写代码它写 review 意见。整个过程是双向对话每一行代码你都过目、都理解它只是帮你把打字速度提升了一个量级。这种用法需要一点配置但不多核心是项目记忆文件和权限边界。第三种把它当自动驾驶。你给它一个完整需求让它自己拆任务、自己列计划、自己改代码、自己跑测试、自己修 bug——你在旁边当监工只在关键时刻踩刹车。这种用法对配置的要求最高也是最容易翻车的。我见过不少新人一上来就冲第三种去结果要么是代码质量失控要么是权限给太大AI 把不该动的文件改了回头还得靠版本控制来救命。所以我在这个系列的前两篇反复强调Claude Code 的“全链路配置”核心不是把工具装到能用而是把工具放进一个受控的工作流里。那到底什么是“全链路”我个人的理解是从环境准备、鉴权、全局配置、项目级记忆、权限边界到和 Git 工作流的耦合、和代码审查流程的衔接再到日常任务的实际执行——这一整条链路每一环都知道自己该干什么AI 才能稳定地输出价值。这篇文章就把这条链路完整走一遍每一步讲清楚为什么这么做以及我把哪些环节调到自己顺手的状态。2. 安装和环境校验装好不等于能用先过一遍最小可用路径很多人装完工具就急着开干结果第一句话就报错然后开始怀疑人生。其实 Claude Code 的安装本身不复杂麻烦的是装完之后的环境校验。这一节把最小可用路径捋一遍。2.1 安装前置条件Claude Code 作为一个命令行工具依赖本地的 Node.js 环境。我的建议是 Node 的版本别太老官方文档写的是要求某个长期支持版本以上但我的实际体验是尽量用当前主流的 LTS 版本太老的版本在某些输出解析上会有兼容问题而且一旦出问题报错信息往往不太直观排查起来很费劲。确认好 Node 环境之后安装就是一条命令的事npm install -g anthropic-ai/claude-code这里有一个小细节如果你用的是公司内网镜像源安装一般没问题但后续的版本更新会走同样一条路。我习惯在安装完看一眼版本号claude --version如果正常输出版本号说明安装这步已经通了。2.2 密钥配置别把密钥写进项目里安装只是第一步让工具能真正调用模型服务还需要配置访问凭证。这一步我用的是环境变量的方式export ANTHROPIC_API_KEY你的密钥在 Linux/macOS 下建议把它写进 shell 的配置文件比如.bashrc或.zshrc而不是每次手动 export。Windows 下则可以用系统环境变量面板来设置。这里我说一个比较重要的经验环境变量方式适合个人开发但如果你在多台机器之间同步配置或者有团队协作的需求更好的方案是使用工具自带的登录鉴权流程或者把密钥托管到本机的密钥管理服务里CLI 配置里直接引用那个服务的句柄。我不太建议把密钥明文写进任何会被版本控制追踪的文件尤其是项目目录下的.env文件——我知道很多人习惯这么干但一旦仓库泄露密钥就等于裸奔了。2.3 最小可用路径的验证配置完密钥之后别急着干正经活先跑一个最小验证claude 用一句话介绍你自己这一步的目的不是测试模型聪明不聪明而是确认三件事安装路径没问题、密钥鉴权能通过、模型服务的响应链路是通的。如果这一步能正常输出那环境就已经可用了。我遇到过一种很典型的“环境假死”情况命令行执行后没有任何输出也不报错光标就那么一直闪。这种时候先不用怀疑配置大概率是网络层面的问题。对应的我建议先确认当前环境的网络访问是通则再做下一步。这类问题我在后面的常见问题部分还会展开说。3. 三级配置的合并规则全局、项目、CLI 参数怎么排优先级装好工具、配上密钥之后接下来要面对的是配置体系。Claude Code 的配置不是单一文件而是分层的。搞清楚每一层是干什么的、谁覆盖谁是“全链路配置”的骨架。3.1 三层配置各自长什么样我按自己的使用习惯把配置分成三层全局配置存在用户主目录下影响这台机器上所有项目的会话。放那些你任何时候都不希望被覆盖的偏好比如默认模型、输出格式、通用权限策略。项目配置存在具体项目的.claude目录下会跟着仓库走。放那些只针对当前项目的约定项目的技术栈偏好、目录结构说明、可用的脚本命令、需要规避的文件路径。命令行参数每次会话启动时临时指定优先级最高。比如我有时会临时指定一个更强的模型参数跑复杂任务但不会把这个参数写进全局配置因为不是每个任务都需要它。这三层之间的关系我习惯用一句话来记越靠近命令行的越能覆盖远离命令行的。3.2 合并顺序的实践对照我画一张表方便你理解配置的合并顺序配置层级存放位置典型用途优先级全局用户主目录下的配置目录默认模型、全局权限、输出偏好低项目项目根目录的.claude目录项目说明、工具约束、本地脚本中命令行启动时附加参数临时切换模型、调整输出格式高这个优先级顺序是有讲究的。全局配置是“兜底”保证你随便进哪个项目都有一套可用的默认行为项目配置是“定制”让 AI 进入某个仓库时自动切换成该仓库的上下文命令行参数是“临时的例外”只在当前这次会话生效不污染其他配置。有一个细节值得注意项目配置是跟仓库走的也就是说它会进入版本控制。这是一个双刃剑——好处是团队成员共享同一套约定坏处是如果有人在里面写了相对路径的敏感信息等于把秘密提交进了仓库。我在实际使用中会把项目配置里涉及本地路径的部分全部用相对路径或环境变量引用避免团队成员的运行环境不一致导致配置失效。3.3 配置项里值得优先关注的几个字段settings.json 里有几个字段我几乎是每次新环境都要确认的model默认用的模型版本。我一般不会把这里设成最强的因为很多简单任务不需要那么强的推理能力设一个性价比高的默认值把强模型留到命令行参数里按需调用能省不少时间和成本。outputStyle输出风格。如果只是客观、可解析的回答我很在意输出格式的一致性和信息密度。permissions这块我单独在第 5 节展开先记住一个原则默认越严格越好。4. 项目记忆文件让 AI 从“懂代码”变成“懂你的项目”配置体系里我认为价值被低估最多的是项目记忆文件。很多人不知道有这个东西或者知道但从来不维护。实际上Claude Code 在项目里的表现很大程度取决于你有没有把项目的“潜规则”告诉它。4.1 记忆文件为什么比代码本身更重要代码本身AI 是可以读的。但它读到的只是“现在是什么样”而不是“为什么是这个样”。举个很常见的例子你进到一个老项目里发现某个模块的命名风格和标准规范不一样代码里也没有注释说明原因。AI 如果只读代码它就不知道这是历史包袱还是刻意的设计于是它在生成新代码时会“好心”地帮你统一成标准风格——结果你把一组互相依赖的接口全改乱了。记忆文件要解决的就是这个问题把代码里看不出来的项目背景、设计决策、约定俗成提前告诉 AI。我在项目的CLAUDE.md文件里一般会写这几类内容项目概述这个服务是做什么的服务谁 技术栈使用的主要框架、语言、运行环境 目录结构哪些目录是核心逻辑哪些是自动生成的哪些绝对不能动 开发命令测试怎么跑、构建怎么跑、有没有特殊的调试入口 代码约定命名规范、错误处理方式、注释语言 历史包袱哪些地方“看着不合理但你别动”4.2 用什么粒度来写记忆文件有一种常见的误解记忆文件写得越多越好。我曾经也觉得这是个“喂给 AI 的资料库”后来发现不是。写太多AI 在读取时反而会抓不住重点写太少又起不到约束作用。我的经验是控制在一屏到两屏之间而且要分层。第一层是“会话开始时自动加载的短说明”通常 200 到 400 字讲清楚项目是什么、技术栈是什么、动代码前必须注意什么。第二层是“需要时按路径提示加载的长说明”可以是一份详细的架构文档或者一份约定清单AI 在遇到相关任务时会主动去查。有几个地方我认为是必须写的项目里有哪些命令是不能随便跑的。比如某些脚本会清理数据库、某些命令会触发线上发布。AI 如果不知道这些你让它“帮忙跑一下测试”它可能顺手就把旁边的生产脚本给执行了。哪些目录是生成物。AI 经常犯的一个错误是去“修复”自动生成的代码改了半天一生成又没了。在记忆文件里明确写清楚哪些目录是生成物、哪些是真源码能省下大量的无效沟通。你对代码风格的主观偏好。比如你习惯用中文注释还是英文接口命名偏好动词开头还是名词开头这些属于项目约定但对 AI 来说只能靠记忆文件去约束。4.3 记忆文件需要动态维护还有一个容易被忽略的点记忆文件不是写一次就完了。项目结构会变、命令会变、技术栈会演进记忆文件如果过期反而会误导 AI。我自己的习惯是每次项目发生结构性变更时比如新增一个大的模块、换了一个构建工具、引入一个新的框架顺手更新一段到记忆文件里保持它和当前代码的真实状态同步。另外我会在每次重要会话结束前让 AI 自己总结“这次会话生成的代码和现有代码的关系”再决定要不要把这层关系沉淀到记忆文件里。很多有价值的信息就是在这些边角对话里产生的。5. 权限与沙箱哪些操作要放权哪些必须拦下来配置里我最看重的一块是权限设计。Claude Code 这类工具的最大风险不是它能力不够而是它权限太大——你给了它操作文件系统、执行命令、读写环境变量的能力它可能在不恰当的时机干出不恰当的事。5.1 权限模型的基本逻辑Claude Code 在读取项目时默认能访问项目目录内的文件但涉及系统命令、文件修改、环境变量等操作会触发权限确认或拦截取决于你设置的权限模式。我把这套逻辑理解为四个层次只读AI 可以看代码、读文件但不能修改任何东西也不能执行命令。适合做分析、做 review。询问AI 在做修改或执行命令之前会先询问你等你点头才继续。这是我最常用的一层。白名单事先声明哪些命令可以自动执行不用每次问。比如npm test、git status、python -m pytest——这些高频、低风险的操作进白名单能省掉大量无效确认。放行AI 可以自由执行命令和改文件不需要经过你。除非你在跑一个非常自动化的批处理任务否则我不建议长期开这个。5.2 我在实际项目里怎么设置以我自己在某个内部工具的日常开发为例我会在项目配置文件里维护一个白名单{ permissions: { allow: [ npm run test, npm run lint, git diff, git status, python -m pytest ], deny: [ rm -rf, git push --force, npm publish, dropdb ] } }我没见过有人这么用 JSON 写但意思大致是这样。核心思路是高频、低风险、可重复的命令放进去破坏性、不可逆的命令直接禁用额度剩下的全部默认询问。这里有个很实际的经验白名单命令不仅匹配命令本身还要注意参数展开。比如我允许了git push但如果参数里混进来git push --force我是希望它拦截的所以白名单的匹配规则要足够严格必要时用通配符精确控制而不是“命令前缀匹配就算放行”。5.3 你不希望 AI 碰的东西除了命令还有一类需要拦的是文件路径。我会在权限设置里明确禁止 AI 访问项目目录之外的路径比如系统配置、Shell 配置文件、密钥文件。不要觉得 AI “反正不会自己去找”——当它接到一个任务比如“帮我检查环境变量对不对”它完全可能去读取你的 shell 配置文件然后把内容输出到回复里。这个过程本身没有恶意但信息泄露的风险是真实的。另一个容易被忽略的场景是外部服务。AI 执行命令时如果命令本身会触发对某个服务器的请求——比如自动部署脚本、依赖安装命令、数据库迁移——你需要在白名单上把这类命令单独设一道确认而不是简单放行。6. 一个完整任务的实战复盘从需求描述到通过的测试前面讲了这么多配置这一节拿一个真实的任务进程来复盘看看“全链路配置”在一条完整开发链路里到底是怎么配合的。我拿一个虚构但不失真的场景一个内部团队的“任务工单面板——简单的命令行提醒工具”。需求很简单用户能添加一条带截止时间的提醒到时间后终端里弹出一条通知。6.1 需求描述与实际拆解我先在会话里扔给 Claude Code 一段需求描述做一个命令行待办提醒工具支持添加任务、查看未完成任务列表、标记完成。任务有截止时间到了时间在终端给我弹个提醒。这个需求如果直接丢给 AI它可能按自己的理解直接开写结果写出来的东西不一定合我意。所以我在描述里加上了上下文约束项目是一个 Node.js 命令行工具使用 thanos 风格、轻量级依赖不要引大型框架。请列出你理解的业务规则并提问你需要的澄清点然后再给实现方案。这一步的意义在于我在把“需求”转成“任务”。AI 需要先展示它理解了什么我来修正然后再进入编码阶段。它列出的澄清点包括提醒是在运行中的终端弹出还是通过系统通知任务数据存在本地文件还是内存里过了截止时间的任务是标记逾期还是自动置顶删除任务的功能需要吗这些问题看似细碎但都属于“需求文档里没写但实际做起来一定要定的事”。这个前置的确认环节比后面写出多少行代码都重要。6.2 生成代码与迭代修正确认完业务规则后我让它先给目录结构和模块划分再说实现方案最后才写代码。这样做的原因是我希望代码落在“项目的整体上下文里”而不是一个孤立文件。AI 给出的建议是拆成几个模块一个负责任务存储一个负责时间调度一个负责终端展示。之后是常规的写代码、跑测试、修 bug 循环。在这个过程里我发现它写的一个文件里使用了较长链式调用来处理任务状态转换读起来不够直观。我提出意见让它改成表驱动的方式它在几十秒内就完成了重构。接着我让它在测试里补上“截止时间到了之后提醒只触发一次”这个边界用例它自动生成测试并跑通。6.3 复盘时间都花在哪了整个过程中真正有价值的是最后复盘。我统计了一下如果把任务拆成“需求澄清 10%、方案设计 15%、代码生成 45%、测试修正 20%、代码 review 10%”那么——真正让 AI 写代码本身是最快的一步几乎不占时间。时间主要花在澄清需求、确认方案和修正测试这三个环节。这给了我一个比较明确的判断Claude Code 的“AI 驱动开发”本质上不是“AI 自动写代码”而是“人类把需求讲清楚、AI 把实现写出来、人类再把把关”。你越能在需求描述和验收标准上花工夫后面代码生成和修正的链路就越短。7. 和 Git 工作流搭在一起提交信息、Code Review、批量操作Claude Code 单聊代码生成只是基本操作真正让开发效率上台阶的是把它放进 Git 工作流里。7.1 生成提交信息与变更说明我现在的习惯是代码改完之后让 Claude Code 先看一下git diff然后让它按项目约定的格式生成提交信息claude 请根据当前 git diff 生成符合项目规范的 commit message要求区分 feat/fix/refactor 类型并简要说明变更原因这里有一个好处AI 会读完整段 diff而人通常只记得自己改了什么。很多时候我改完一个文件就忘了自己还顺手调整了另一个地方的格式Commit message 反而漏了它。AI 读 diff 生成信息能把这种“边角修改”也纳入提交记录提交历史的完整性好了不少。7.2 让 AI 做第一轮 Code Review在我提交代码前我会先让 Claude Code 自己做一轮 review。它给我输出的内容通常包括潜在 bug、边界情况、命名一致性、遗漏的错误处理。说白了它没法替代人类做架构评审但作为第一轮“自动冒烟”能把低级问题和风格问题提前过滤掉。实战中我比较常用的一种方式是请 review 最近一个 commit 的代码变更按以下维度输出正确性风险、边界情况、可维护性、命名一致性。只提建议不要改代码。这个“只提建议不要改代码”非常关键。如果不加这条AI 可能会顺手把代码改了然后给你一份“我已经帮你优化”的结果——这种主动是好事但有时会影响代码结构我反而要多花时间去核对它的改动是否合适。7.3 批量重构的小心机批量重构是 AI 很擅长的场景但也容易出问题。比如我需要把一个旧 API 的调用方式统一改成新 API涉及十几个文件。这种纯机械的重构AI 几乎不会出错但它会忽略“不应该被重构成新 API 的特殊文件”。我会在任务描述里加一条以下文件已在白名单中不要修改legacy/、generated/、third_party/让 AI 明确知道边界在哪比最后逐个检查 diff 要省力得多。不过要提醒一句批量重构一定不要只信 AI 你的自查跑完重构马上跑测试和 lint然后把 diff 从头到尾看一遍。没有这层防护任何工具都可能会在你不注意的地方产生意想不到的偏移。8. 我最终保留下来的配置和日常使用习惯最后分享几个我自己长期保留的配置习惯篇幅不长但都是我踩坑踩出来的。第一个习惯是全局配置里只留稳定偏好不留临时需求。我的全局配置里只有默认模型、输出格式、以及一个比较严格的默认权限策略别的都放项目级配置里。这样可以避免“这台机器上某个项目好使换个项目就各种报错”的混乱。第二个习惯是权限白名单宁少勿多。初期我会频繁把高频命令加入白名单后来发现失误往往都出在“太过放心的那个命令上”。现在白名单只保留了十几个经过几个项目验证的低风险命令其余操作统一走确认流程。第三个习惯是每次大任务结束前做一次记忆文件同步。我让 Claude Code 自己总结这次会话接触到的项目上下文、产出的变更、发现的注意事项由我决定哪些沉淀进项目记忆文件、哪些丢进版本控制说明。这个习惯一方面保持项目记忆文件的新鲜度另一方面也让我自己对任务全景保持掌控。对我来说Claude Code 的“全链路配置”不是一个一次性工程而是一套持续调优的工作流。它没法替你决定项目该怎么做但你给它定好边界、喂够上下文、管好权限之后它确实能帮你把那些耗时的、重复的、低认知负荷的环节大幅压缩。剩下的时间你可以拿去做真正需要人来做判断的事。
