Claude Code 用到一定阶段后，你会发现真正影响效率的，不只是提示词，而是项目配置。哪些命令可以跑、哪些文件可以改、团队规则放哪里、本地私有设置怎么处理，这些都应该写进清楚的 settings.json 体系里。
很多人只会临时对 Claude Code 说“不要乱改文件”“先运行测试”，但下一次换项目、换目录、换同事，规则又要重新说一遍。settings.json 的价值，就是把常用偏好、项目规则和权限边界固化下来，让 AI 编程更稳定。
本文基于 Anthropic 官方 Claude Code settings 文档，并结合站长和小团队项目维护场景，讲清楚 settings.json 怎么配置。你也可以搭配 Claude专题、AI编程工具专题 和 AI智能体与自动化专题 一起看。
先理解四层配置
官方文档把 Claude Code 的配置分成多个作用范围。对个人用户和小团队来说，最常用的是这几层。
- 用户设置：通常位于
~/.claude/settings.json，影响你自己的所有项目。 - 项目设置：通常位于仓库内
.claude/settings.json，适合提交到 Git，给团队共享。 - 本地项目设置：通常位于
.claude/settings.local.json，只影响当前项目里的你自己，适合放私有偏好，本地文件通常不提交。 - 托管设置：企业或团队由 IT 管理的统一策略，个人站长一般不用一开始就考虑。
简单理解：个人习惯放用户设置，团队约定放项目设置，本机私有内容放本地设置。不要把所有东西都堆进一个文件。
配置优先级怎么理解
官方文档说明，普通设置一般会按层级覆盖：命令行临时参数优先，其次是本地设置、项目设置，最后才是用户设置。也就是说，越靠近当前项目和当前会话，优先级越高。
但权限规则有一个特殊点：权限不是简单覆盖，而是会跨范围合并。这意味着你不能只看一个文件就判断最终权限，要理解用户、项目、本地配置叠加后的结果。
这也是为什么我建议新手不要一开始就写复杂权限。先把项目级规则写清楚，再用本地设置补充个人偏好，最后再逐步收紧危险命令。
哪些内容适合放用户设置
用户设置适合放“你在所有项目里都希望保持一致”的偏好。例如界面提示、常用行为、个人默认规则等。
个人站长或独立开发者可以把这些内容放在用户设置层：
- 默认输出偏好，例如回答要简洁、先列风险；
- 常用安全习惯，例如修改前先看 Git 状态；
- 自己常用的工具入口或全局 MCP 配置；
- 跨项目通用的只读优先原则。
但不要在用户设置里写某个项目的具体命令。例如 WordPress 博客的发布检查、前端项目的测试命令、公司内部路径，都不应该放到全局配置里。否则换项目后很容易误导 Claude Code。
项目设置应该写团队共识
项目设置通常放在仓库的 .claude/settings.json。它适合写“这个项目所有协作者都应该遵守”的规则。
比如一个 WordPress 内容站项目，可以在项目设置或项目说明里固定这些规则：
- 发布文章前必须检查摘要、SEO meta、特色图 alt 和正文 h1；
- 修改主题文件前先说明影响范围；
- 不要把真实密钥写进文档或草稿；
- 跑发布脚本前先确认草稿路径、分类和标签；
- 完成后必须执行页面检查并记录结果。
这类规则不是某个开发者的个人习惯，而是项目质量门槛。老达AI博客的发文流程就已经把这些内容沉淀在项目规则和发布脚本里，可以参考 AI自动发布 WordPress 文章流程 和 WordPress发布自动化复盘。
本地设置适合放什么
.claude/settings.local.json 适合放只对你当前机器有效的配置。它通常不应该提交到仓库。
适合放本地设置的内容包括：
- 本机路径、临时目录、个人工具偏好；
- 你自己愿意允许的本地命令；
- 临时调试配置；
- 只在当前项目、当前电脑上成立的设置。
这里有一个关键原则：凡是包含个人环境、账号路径、机器状态、临时权限的内容，都不要放进项目共享配置。团队共享配置应该让别人拉下来也能理解，而不是依赖你的电脑。
权限配置要从最小可用开始
Claude Code 的强大之处在于它能读文件、改文件、跑命令；风险也在这里。settings.json 里最值得认真设计的，就是权限边界。
新手可以按三层来设计。
第一层：只读分析
刚接手一个项目时，不要急着开放编辑和命令执行。先让 Claude Code 只读分析目录、依赖、入口文件和测试命令。这个阶段的目标是理解项目，不是改项目。
第二层：允许低风险修改
确认任务范围后，再允许它修改指定文件或低风险目录。例如文档、样式、小组件、测试文件。涉及数据库迁移、生产配置、批量删除、权限脚本时，不应该自动放行。
第三层：命令按风险分组
命令不要一刀切。可以把命令分成三类：
- 低风险：查看文件、列目录、运行只读检查；
- 中风险：安装依赖、运行测试、格式化、构建；
- 高风险：删除文件、改数据库、部署、修改服务器配置。
高风险命令必须保留人工确认。关于类似的权限设计，也可以看 MCP权限怎么设置 和 AI编程安全审查怎么做。
一个更实用的配置思路
不同版本的 Claude Code 可用字段可能会随官方文档调整，所以我不建议照抄网上来历不明的配置片段。更稳的思路是先写清楚配置目标，再按官方文档确认字段。
你可以按这个顺序整理：
- 先写项目规则：这个项目的目标、禁区、验证方式是什么。
- 再写共享配置：团队都需要的设置放进
.claude/settings.json。 - 再写本地配置：只影响自己的偏好放进
.claude/settings.local.json。 - 最后收紧权限：把危险命令、敏感路径和生产操作单独拦出来。
如果你还没有项目规则，可以先从 AI编程项目规则怎么分层 开始，把 AGENTS.md、CLAUDE.md、Cursor Rules 和项目设置的边界理清楚。
团队协作时最容易踩的坑
第一个坑：把本地配置提交到仓库。 本地路径、个人命令、临时权限一旦提交，别人可能完全用不了，甚至暴露敏感信息。
第二个坑：项目设置写得太宽。 为了省事把编辑、命令、网络都放开，短期方便，长期很难审计。AI 编程不是越自由越好，而是越可控越稳定。
第三个坑：规则分散在太多地方。 AGENTS.md、CLAUDE.md、settings.json、README、脚本注释都写一遍，内容还不一致，最后 AI 和人都会困惑。项目规则要有主入口，其他文件只做补充。
第四个坑：不做发布后检查。 settings.json 能减少误操作，但不能替代验收。改完代码仍然要跑测试、看页面、检查日志、确认回滚方式。
适合个人站长的一套做法
如果你是个人站长、内容创作者或独立开发者，可以用一套简单规则起步。
- 用户设置放个人偏好：简洁回答、先给计划、改完列验证结果。
- 项目设置放质量门槛：发文规范、内链要求、SEO 检查、禁止泄露密钥。
- 本地设置放私有路径和临时权限：例如本机预览命令、截图工具、调试目录。
- 危险命令保持人工确认：删除、部署、数据库、服务器配置都不要自动放行。
这样配置以后，Claude Code 才更像一个熟悉项目规则的执行者，而不是每次都要重新培训的新助手。
老达点评
Claude Code settings.json 的重点，不是写一个很炫的配置文件，而是把“哪些规则全局有效、哪些规则项目共享、哪些规则只在本机生效”分清楚。
AI 编程工具越强，越需要边界。真正成熟的用法不是让它想做什么就做什么，而是让它在明确权限、明确项目规则、明确验证方式下执行。这样你才能把 Claude Code 用进长期项目，而不是每次都靠临时提醒救场。
