一名开发者读了 npm 包 @anthropic-ai/claude-code@2.1.87 的源码，发现一批官方文档没有写清、但当前版本里已经能用的配置项。

有意思的地方不在“挖到彩蛋”。而是这些配置能改写工具输入、注入上下文、自动批准或拒绝权限请求，还能影响 Claude Code 的自动批准判断。

这会让很多团队卡住：如果一个 AI 编程工具的真实配置边界比文档更宽，工程负责人到底该把它当生产力工具，还是当一段需要审计的自动化脚本？我的判断是，两者都是。

源码暴露的边界，比文档更宽

这批发现有一个很重要的前提：它基于 @anthropic-ai/claude-code@2.1.87。也就是说，它是当前版本快照，不是 Anthropic 对外承诺的稳定 API。

配置路径也值得注意。个人配置通常在 ~/.claude/，项目配置在 .claude/。后者可以随 git 提交，在团队里共享。

这意味着配置不只是个人偏好。它可能变成项目规范的一部分，也可能变成新的风险入口。

入口源码里看到的文档外能力直接影响
hooks可通过 stdout JSON 返回 updatedInput、additionalContext、permissionDecision改写工具输入、注入上下文、自动允许或拒绝权限请求
skillsfrontmatter 支持 model、effort、hooks、agent 等字段指定模型、推理强度，把技能交给特定 agent 执行
agents支持 memory、omitClaudeMd、criticalSystemReminder_EXPERIMENTAL 等字段让代理保留记忆，或改变它读取项目指令的方式
autoMode内部称为 YOLO Classifier，支持 allow、soft_deny、自然语言 environment用规则和环境描述影响自动批准判断

这里面最该先看的是 hooks。

官方文档已经说明 hooks 可以接收 stdin JSON，退出码 2 可以阻断操作。源码显示，它还可以通过 stdout JSON 反向影响后续动作。

比如，hook 可以把某个工具输入改掉，也可以补一段上下文，还可以直接给出权限判断。放在工程流程里，它很像一层夹在模型和工具之间的可编程拦截器。

这层拦截器好用，但不能轻看。它既能把 git push 之类操作改成更保守的命令，也可能在错误规则下放大误操作。

真正受影响的是开发者和工程负责人

对个人开发者，这批配置的吸引力很直接：少点确认弹窗，让 Claude Code 更懂项目，把重复检查交给脚本。

更现实的动作是三件事：锁住 Claude Code 版本；把 .claude/ 和脚本一起纳入 git；升级前检查 hooks、agents、skills 的行为有没有变。

对工程负责人，重点不是“开”或“关”。重点是把它当工程资产治理。

项目级 .claude/ 可以共享，这让团队能统一 Claude Code 的行为。比如共享 hooks，约束 Bash 执行；让特定 skill 在写文件后触发检查；让审查 agent 带着 memory 记住项目里的历史问题。

但这也带来一个对比：文档内配置更像产品功能，文档外配置更像源码能力。前者坏了可以按官方说明追责，后者坏了更多要靠团队自己兜底。

所以，团队更适合这样处理：

对象可以做什么不该做什么
正在重度使用 Claude Code 的开发者固定版本，给 hooks 写最小权限规则，升级前做一次行为检查把自动批准规则写得过宽，或默认信任持久记忆
负责 AI 编程工具治理的工程负责人审查项目级 .claude/，限制可共享 hooks，规定哪些 agent 能用 memory把未文档字段接进 CI、发布、生产权限审批等关键链路

我不太买账的是把这些能力直接包装成“隐藏高级功能”。对个人来说，它确实能提效；对团队来说，它先是一段会执行、会改写、会批准的配置代码。

能用和该不该默认放开，是两回事。

最大风险不是失效，而是权限被悄悄放大

未文档能力的第一层风险是版本不稳定。

字段里出现 EXPERIMENTAL，已经说明它可能改名、移动或被移除。后续版本如果调整内部结构，依赖这些字段的工作流可能直接断。

这不是最麻烦的部分。更麻烦的是权限边界会变模糊。

autoMode 内部称为 YOLO Classifier。它可以通过 allow、soft_deny 和自然语言 environment 来影响自动批准判断。

自然语言环境描述很方便。比如说明“这是本地开发机”或“测试数据库可以重复运行”，模型就可能更容易放行某些动作。

问题也在这里。只要环境描述过于乐观，自动批准链条就会建立在错误假设上。

再叠加 hooks 的命令改写、agents 的 memory、项目级 .claude/ 的 git 共享，风险半径会扩大。一次配置误判，可能不再只影响一个人的终端。

接下来最该看三个变量，不是泛泛等更新：

  • Anthropic 是否把 hooks 的 stdout 返回字段正式写进文档；
  • agent memory、omitClaudeMd、EXPERIMENTAL 字段是否得到稳定说明；
  • autoMode 的 allow、soft_deny、environment 是否有明确安全边界和版本承诺。

如果这些没有落文档，开发者仍然可以用。但管理方式要降一级：按“源码快照能力”管理，而不是按“平台稳定 API”管理。

这就是这件事的主线。Claude Code 的可配置边界已经超过公开文档，收益来自这里，风险也来自这里。利器在手，先问有没有鞘。