你知道 Code 有多少个配置文件吗？

不是 .md 。也不是 .json 。

要是你仅仅接触过这两个文件, 那么你大约仅仅运用了Code 30%的能力。

还剩下百分之七十隐匿于一堆你不见得会翻找得到的目录当中, 这些目录分别是, .// , ./hooks/ , .local.json , -.json。

在前两天的时候, 我想着要给Code增添一个具备“写完代码自动格式化”特性的功能, 于是就在.md里面耗费了好长的时间去撰写规则, 结果却发现一点作用都没有产生, 尽管我反复阅读了, 而且也理解了相关内容, 然而写出来的代码依旧没有被格式化。

后来一点点地翻找至 ./ 的深度层级目录里, 这才发觉那个真正必须要修改的地方, 压根就不被称作 .md。

我想对我说的那5种配置, 是这篇文章。每一种, 都是我自己踩了坑才发现得出的。

一、 以.md为后缀的那个相关条件语法, 大部分人在写到整整200行的时候, 仍然还在持续地往上堆积罗列。

Code最先读的文件是.md, 每一次加载是在每段对话开始的时候。

然而, 存在一件众多人并不了解的事情, 那就是: 60行属于甜点范畴, 200行乃为天花板界限。

越过200行往后, 后半截的规则会被展开成——“静默降优先级”。并非是忽略, 而是优先级低至你难以去依赖。你觉得是不听话, 实际上是它压根就没“看见”那一行。

可是好多之时, 我们确切是存有一大把规则得去写, 这规则处于不同的语言范畴, 处于不同的目录范畴, 处于不同的场景范畴, 那该如何去做?

答案：条件规则 + 分层文件 。

条件规则的写法长这样：

-不要裸起 goroutine。用 errgroup 或 WaitGroup。-context 必须是第一个参数，命名为 ctx。

处理 Go 文件之际, 这些规则是能够看见的, 在写作的时候, 整块的内容就仿佛是不存在的。 有。

分层文件的思路更简单：

my-service/├── CLAUDE.md # 根目录：通用规则，~30 行├── api/│ └── CLAUDE.md # REST 约定、错误码├── internal/│ └── CLAUDE.md # 包命名、接口模式

代码会进行递归操作, 以此来读取目录树当中的.md文件, 并且处于子目录下的情况会自动将父目录原来所规定的原则予以覆盖。

这好似一个厨房, 主厨去确定大方向那般（根.md）, 切菜之人有着其自身的操作规范呢（api/.md）, 而洗碗这个区域又存在另一套那样的规矩呀（/.md）。于同一厨房之中, 各个区域所实行的管理并不相同。

可问题在于, 百分之九十九的人并不晓得条件语法以及分层文件是存在着的, 所以呢, 所有的规则都被写在了一个文件当中, 一直堆积到三百行的时候, 还在疑惑为啥它不听话。说实在的, 真的挺让人崩溃的, 你耗费了二十分钟去写规则, 却仅仅花了三秒就将它给忽略掉了。

实际呈现的效果是, 在运用了条件的语法以及进行分层之后, 我的根.md文件, 从原本的一百八十行一下缩减到了四十五行, 然而在此时的情况之下, 对于规则所具备的遵从程度, 反过来是获得较大幅度提升的。

二、 Hook——你以为改代码是终点，其实它只是个起点

Code 有四种 Hook ，但大多数人一个都没配过。

四种 Hook 是：

Hook 触发时机 干什么用

工具调用前

拦截危险命令

工具调用后

自动格式化、 lint

Stop

任务完成时

质量门禁、测试验证

会话启动时

环境初始化

至关重要的是, Hook运行于, 的主要推理循环之外, 不会消耗Token。

不能够出现于其中的表述是“写完代码自动格式化”, 要做好Hook的配备事宜, 在每一次Write操作完成之后, 自动运行gofmt或者是--fix, 消耗的Token数量为零。

最简单的例子：

{"hooks":{"PostToolUse":[{"tool":"Write","condition":"filePath.endsWith('.go')","action":"run","command":"gofmt -w ${filePath}"}]}}

还有 ——配一个就能拦截灾难性操作：

{"hooks":{"PreToolUse":[{"tool":"Bash","condition":"command.includes('rm -rf') || command.includes('--force')","action":"block","message":"危险命令被拦截：--force 和 rm -rf 需要手动确认"}]}}

中止钩子更厉害。存在一个令我记忆极为深刻的事例: 作者要求编写三个应用程序编程接口, 声称已然写完，然而其中两个所存在的空错误处理情况（错误不为空时后面什么内容都没有）根本未曾处理。倘若配置上中止钩子并接入测试覆盖率检查, 在宣称“完成”的那一刹那便会被拦截, 进而持续修改直至真正通过。

讲真, Hook属于那种极为严重被低估的配置。这和做饭情况完全相同, 就是完全没必要每次都特意去提醒不要加过量的盐、不要把火开得过于大。你实际所需的是一整套厨房的自动保护体系, 也就是温度一旦达到既定数值就要自动发出警报, 计时器发出响声之后也就需要自动关闭火源的这类系统的。

三、 的权限隔离——物理上不能写文件，对话里怎么说都没用

是 Code 里最能减少翻车风险的机制。

但是, 占据多数的人们所采用的方式为, 于.//之中放置一个文件, 撰写几句描述语句, 而后任由其自行发挥了。

他们漏掉了最关键的一件事： 权限硬隔离 。

某个处于正常状态、具备与主 Agent 相同权限的存在, 这种权限涵盖能够进行文件书写操作、能够执行命令、能够访问网络。然而, 要是你所针对的它是用于代码审查用途, 那么其根本无需具备写权限。

这时候应该创建一个 只读 ：

权限：Read 工具 + Grep + Glob。无 Write 工具。无 Bash 执行。无网络访问。物理上不能修改代码，不管对话里怎么要求它。

从此 里再也不用写"只读不改"。

更进一步—— : fork 。在 的 里加一行：

context:fork

此大杀器所代表的是, 于隔离的子进程里运行, 当读取到40个文件并完成分析报告之后, 上下文即刻被丢弃。主Agent仅能看到干净的摘要。

不需要手动 / ，不需要开新会话。

我在尝试运用这一配置过后, 所获的最大感受便是, 一个并未携带 :fork 的代码审查场景会发生, 它会将包含 40 个文件的内容拖拉至主对话之中, 后续每一次操作都需要为这些展现情况承担费用。关于上下文污染此类问题, 老实讲相较于 token 账单而言更能惹人生气冒火, 钱财是能够赚取回来的, 然而对话一旦遭遇卡顿无法继续前进便只能选择使用 /clear 以重新开始, 如此一来先前所有的对话记忆便全部白费了。当配备上 fork 之后, 在整个过程里主对话始终能够保持干净的状态。

四、权限有着三级控制, 这并非是关于“能”与“不能”, 而是涉及“能”、“问”以及“不能”。

那些.json格式的字段, 好多人觉得仅仅是去设置个“allow”就完成了这件事情。

但实际是三级权限：

deny → ask → allow

第一个命中的规则决定结果。

这意味着你可以写得非常细：

{"permissions":{"allow":["Bash(npm run lint)","Bash(npm run test *)","Read(~/.zshrc)"],"ask":["Bash(git push *)"],"deny":["Bash(curl *)","Read(./.env)","Read(./.env.*)","Read(./secrets/**)"]}}

读取（点斜杠点环境变量文件）被拒绝阻挡了, 巴什（运行npm测试星号）直接予以通行, 巴什（执行git推送星号）在执行之前询问你一下。

仅配置了allow却没有deny, 这等同于不存在防火墙, 好多人使用着缺省配置还自认为「我没有需求」, 但实际上并非没有需求, 而是你不清楚存在这个隐患。

还有一个被严重低估的配置： 。

{"sandbox":{"enabled":true,"autoAllowBashIfSandboxed":true}}

开启之后, 于隔离状态的环境里, 全部Bash命令施行运作, 审查批准之门限大幅度下降, 经过实际测试, 权限弹出窗口减少了84%。

不好的消息是, 沙箱里系统的访问存在限制, 然而, 老实讲, 绝大多数平常的编码任务根本不会触及到这个界限。

五、那些你可能从来没用过、但一用就回不去的优化开关

将这几个配置留存下来, 却不存在统一的主题, 这些配置是我在翻动 ./ 目录之际, 由一个个那种“卧槽原来有这个”的察觉所构成的。

1. ：让上下文自动瘦身

{"autoCompactEnabled":true}

当对话的长度过长之际, Code会自行对历史予以压缩, 将关键信息留存下来, 把过程细节舍弃掉, 切勿使用手动方式 /。

2. ：控制会话存活时间

{"cleanupPeriodDays":20}

原先设定为 30 天, 现改为 20 天, 如此这般能够减小磁盘以及索引方面的占用。可以设定的最小值为 1 天。

3. ：按任务调节推理深度

/effort low # 简单任务，减少 20-30% token/effort high # 复杂架构，火力全开

对于一个 JSON 文件进行重命名之时, 是不值得运用高推理模式的。而针对一个跨模块的重构方案来讲, 同样不值得采用低推理。

4. Cache ：缓存命中折扣高达 90%

这并非是一个“开关”, 而是属于一种使用习惯。被缓存的内容依照优先级来进行排列哟:

- 系统提示词

- .md 内容

- 被加载的

- 对话历史的早期部分

建议实操是这样, 将项目核心信息书写于.md之中, 而非去实行每次逐一手动进行输入之举, 这些相关内容会被系统开展自动缓存的操作, 在后续对话进程里几乎不会产生额外需要计费的情况。

是不是听起来挺基础的? 然而依照我所见到的搜索数据来看, 绝大多数人还是会在每一段对话当中刻意手动重新表述项目的那些已然明确在.md里被缓存的技术栈以及编码规范之类的内容。

5. ：每次编辑前自动快照

{"fileCheckpointingEnabled":true}

默认状态下予以开启。每一次在 Write 进行之前 , 均会自动去保存文件的快照。若出现改坏的情况 , 能够借助 / 进行回滚操作。此种开关在默认情形下就是处于 on这种状态 , 然而有许多人却不清楚具备这一功能。

收个尾

这上面, 5个配置所关联的改动, 我进行了计数统计, 其加在一起, 不会超出30分钟的时长。

但它们对于Code的日常体验所产生的影响, 或许会比你花费整整一日进行调试的情况更加显著, 还要大。

终究来讲是同样的道理, 你并非需要去告知, 每一步具体该如何去做, 你仅仅只需将“规矩”放置在它启动之际会自动进行读取的那个地方。

然而, 每当翻到这些配置之际, 我都会萌生出一个并非太过舒畅的想法, 那便是: 如此优良的事物, 为何要藏匿得这般隐蔽呢?

剩下的，它自己会看。