Configuration
Configuration 各种配置
各种设置项怎么调。
原页来源： 官方 Settings
一句人话
这一页讲的是 Claude Code 身上那些旋钮、开关、挡位，到底该去哪里拧、谁说了算。
像一台拖拉机，不只是会不会点火，还得知道油门、离合、档位、限速器分别在哪儿，不然不是跑不动，就是冲沟里去。
官方先讲了一件很重要的事：配置有先后顺序
不是所有设置都平起平坐。一般是谁离当前项目越近，谁说话越响。
项目里的配置，通常比全局配置更管用；命令行临时带上的参数，又可能比文件里的默认值更优先。
你可以把它理解成三层规矩：村里总规矩、你家院里规矩、眼前这次临时交代。离现场越近，优先级往往越高。
常见配置都在管什么
模型和推理相关
比如默认用哪个模型、是否启用某些实验特性。这决定它脑子用哪种档位。
权限和安全相关
比如默认能不能执行某类命令、哪些目录能碰、危险操作要不要再确认。这决定它拿到多大一把钥匙。
输出和交互相关
比如界面怎么显示、日志怎么记、通知怎么发。这决定你看它干活时顺不顺眼。
网络和服务相关
比如 API 地址、代理、第三方服务入口。这决定它出门能不能找到路。
官方为什么还要分本地、全局、项目级
因为有些规矩是你个人习惯，有些规矩是整个团队的共识，有些规矩只适合这一个仓库。
比如“我喜欢某种显示方式”适合放全局；“这个仓库必须先跑测试再提交”更适合放项目里。
这么分层的好处，是既不让每个项目都从零配，也不至于一条全局配置把所有仓库都绑死。
配置时最容易犯的错
1. 不知道优先级，改了全局还纳闷为什么项目里没反应。
2. 想图省事，把权限开得太大，结果帮工能动的地方比你预想得多。
3. 把团队规则只写在自己机器上，别人一拉仓库根本接不到这些约束。
4. 配置文件堆太多、太散，最后连自己都不知道哪个开关在哪儿。
实用记法
个人口味放全局，项目规矩放项目，临时试验用命令行参数盖一下。
牵涉权限和安全的配置，宁可先收紧，再按需要慢慢放开。
一句话记住：配置不是越多越高级，而是越清楚、越分层、越不容易误伤，才越好用。