Claude 连接本地开发环境：完整配置指南

先让它自己读一遍项目

进入项目目录再启动：

cd <你的项目目录>
claude

第一句话不要让它改东西，先做初始化：在会话里输入 /init。它会扫目录、读依赖清单、找已有脚本，然后生成一份项目记忆文件的草稿，通常包含技术栈、启动与测试命令、目录结构。

草稿只是起点，不是答案。逐条核对：命令是不是真的能跑，目录说明是不是过时，有没有把生成产物当成源码。错的地方直接删，缺的补上。十分钟的校对，能省掉后面几十次纠正。

如果你接手的是老项目，连依赖都装不上，先修环境，再谈配置。工具读得懂代码，但跑不起来的项目只能让它猜。想先看一次完整的协作流程，可以读第一次改代码。

把命令写成可执行的清单

项目记忆文件里最值钱的部分是命令。写清楚「做什么」和「用哪条命令」，不要只写意图。

场景	写法	注意
装依赖	完整命令行	注明包管理器，别让它猜
本地启动	完整命令行	写清端口和前置服务
跑测试	完整命令行	单文件与全量分开列
静态检查	完整命令行	与提交前流程一致

前端项目还要补构建与类型检查；后端项目补迁移、日志查看、接口自测；多包仓库写清每个包的路径与过滤方式。命令越长越要单独成行，放进代码块，避免它从上下文里拼错参数。

一个常见的坏习惯是写「用 npm 跑一下测试」。它可能试三种写法，浪费两轮对话。直接给最终命令，省下的是你自己的时间。

容器、数据库与外部服务

如果开发环境在容器里，记忆文件必须说明三件事：怎么启动容器、怎么进入容器执行命令、哪些服务跑在宿主机上。

数据库要写清连接方式来自哪个环境变量，以及哪些操作需要人工确认。迁移、清库、重置种子数据都属于高风险动作，明确写成「先问再做」。

外部服务同理：本地有没有 mock，测试环境地址从哪来，哪些接口不能打真实请求。把这些写清楚，它才不会在测试里误伤线上数据。

版本控制与提交边界

把团队的分支习惯写进去：分支怎么命名、提交信息用什么前缀、合并前要过哪些检查。没有明说时，它可能按自己的理解提交，风格和仓库历史对不上。

几条硬边界值得单独列：

• 不允许强制推送；
• 不允许直接改动主干分支；
• 不允许修改版本库内部目录；
• 提交前必须看一遍差异。

最后一条尤其重要。它会在总结里说「已完成」，但真正的事实藏在差异里。改动范围、顺手改的无关文件、被删掉的测试，都只能从差异看出来。

环境变量与凭据

项目里放一份 .env.example，列出需要的变量名和用途，值全部留空。真实的环境文件不提交，也不让它改。

在记忆文件里加一句：「缺变量时先问我，不要自己编一个值。」这句话能挡掉很多「看起来能跑、其实连的是假服务」的事故。

凭据只从环境读取，不写进代码、不写进记忆文件、不写进测试夹具。需要新增变量时，让它给出变量名和示例值，由你手动写入真实文件。

验证集成是否真的成功

配置完成后，给一个组合任务，而不是只问一句「你读到了什么」：

先告诉我这个项目怎么启动、怎么跑测试。然后按顺序执行：跑一次全量测试，汇总失败项，不要修改任何文件。

观察三件事：命令是否正确、有没有先征求确认、总结是否对得上真实输出。三项都对，说明环境集成基本可用。

之后把只读命令与测试命令加入放行清单，日常协作会顺很多。再往下是网络层的准备：如果你所在网络访问服务端不稳定，先看国内使用与网络配置。