Claude Code 指令为何不生效

Claude Code 明明读到了自定义规则，行为却没有变化，问题可能出在配置放错了位置。原文给出的核心思路是：先区分系统提示词、项目上下文、输出风格和权限，再决定规则该写在哪里。

这套分类对日常 AI 编程很有用，但文章也把一些实现细节讲得过于确定。尤其是 output styles、hooks 和会话快照参数，原文没有提供足够证据，不能把示例直接当成可运行配置。

想加一条规则，为什么不该直接替换默认提示词

原文认为，Claude Code 的默认系统提示词在运行时由多个来源组装，并不存在一个可以直接编辑的完整文件。它包含助手身份、工具使用指导、编码约定和输出要求等内容。

自定义入口首先分成两组：

• --system-prompt 和 --system-prompt-file 用于替换默认提示词。
• --append-system-prompt 和 --append-system-prompt-file 用于追加指令。

日常编码只想增加约定时，追加通常比整体替换更合适。

原因很直接：你可能只想让代码审查检查异步错误处理、硬编码配置、生产环境的 console.log，并输出带 file:line 的问题列表。为此重写助手身份和工具指导，维护成本明显更高。

原文把替换描述为丢弃默认身份、工具指导和提示词中的安全说明。但这里必须区分「指导文字」与「执行机制」：删掉如何使用 Bash 的说明，不会改变 Bash 工具的参数；删掉权限相关描述，也不等于获得执行权限。

对于「稳定规则放文件，临时要求放命令行」的需求，原文给出了组合方式：

// 组合文件指令与行内指令
// Shell command:
// claude --append-system-prompt-file ./style.md --append-system-prompt "Always reply in French"

// Claude 收到的顺序：
// 1. 默认系统提示词
// 2. 空行
// 3. style.md 的内容
// 4. 空行
// 5. "Always reply in French"

要留意同时使用两个参数的那一行。原文明确说，这种组合要求 Claude Code v2.1.283 或更高版本，文件内容排在行内文本前面。这是文章给出的版本条件，并非文中展示过验证过程的结论；排列靠后也不能简单理解为必然覆盖所有前面的规则。

项目约定、输出风格和工作流应该分别放哪

CLAUDE.md 是原文最想澄清的部分：它提供项目上下文，不是一个持久化的系统提示词替换文件。大白话解释，它负责告诉助手「这个仓库是什么、做事要遵守什么约定」。

原文的项目示例使用 Express 4.18、TypeScript 5.3、Jest、Zod 和 Prisma 5.x，要求测试覆盖率达到 80%+；路由位于 src/routes/，数据库模型使用单数名称，环境变量缺失时启动失败，错误响应遵循 RFC 7807 Problem Details。这些信息放在 .claude/CLAUDE.md，比每次启动都拼进命令更容易随仓库维护。

不过，「作为上下文注入」不代表它不能影响表达方式。原文进一步建议，把工具使用或回复格式要求全部移出 CLAUDE.md，这个结论过强。更合理的取舍是看规则的用途：项目长期共享的约定适合随仓库保存，某次任务的特殊要求适合临时追加。

文章还介绍了三种机制：

• Output styles 用于持续调整回复风格、结构或角色表现。
• Skills 用于按需加载专门任务的说明和上下文。
• Hooks 用于在特定生命周期事件发生时执行代码。

原文用 TypeScript 文档生成串起它们：项目约定要求导出函数具备 JSDoc 的 @param、@returns；skill 用 find src -name "*.ts" -not -path "*/test/*" 收集文件；输出按函数名、参数、返回值组织；最后通过 writeFile('./docs/api.md', response.text) 写入文件。

这个例子适合帮助理解职责分工，但不能直接复制成工程配置。它没有给出 hook 的注册方式，也没有证明 after-response.ts、context.skill、response.text 就是实际支持的事件入口和字段。

此外，文章声称 output styles 在模型生成回复之后才生效，但它自己引用的说明却是「改变每次回复使用的指令」。两种说法并不一致。把 output styles 理解成输出后再套模板的处理器，缺乏文内证据。

规则没有生效，先查会话和权限

原文提出了一个容易忽略的排查方向：恢复旧会话时，新的启动参数未必按预期替换已有提示词。

按作者的描述，Claude Code 会在首个请求时记录系统提示词，后续请求以及通过 --resume、--continue 恢复的会话继续使用它，直到上下文压缩。作者建议用下面的命令迭代规则：

// 不开启新会话，迭代系统提示词措辞
// Shell command:
// claude --append-system-prompt "Draft rules v3" --system-prompt-snapshot off --continue

// 每次运行都用新文本重建提示词
// 适合测试不同措辞

这里最需要核对的是 --system-prompt-snapshot off。文章没有提供对应版本、运行输出或前后对比，因此只能把它当作待确认的排查线索。实际操作前应先确认本机是否支持；新建会话也是隔离旧上下文影响的直接办法。

另一类问题属于权限。提示词要求「读取 package.json 时不要询问」，并不能推翻项目对 Read 操作的审批要求。原文建议通过 settings.json 中的 allow/ask/deny 规则处理权限，而不是反复强化措辞。

提示词能够影响模型如何选择行动，不能直接修改工具权限和 API 限制。

同样，Bash、Read、Write、Edit 的工具签名不会因为一段文字改变，token 上限、速率限制和模型能力也不能靠要求「无限上下文」来增加。

排查时，原文建议用 /status 查看 Setting sources，再用 claude --debug 查加载来源和相关日志。这些信息用于确认配置是否被加载，不能证明模型一定逐条执行。若 skill 名称存在零宽字符、控制字符、改变文字方向的字符、异常空白或 <、>，还应检查名称是否被拒绝。

我的判断

这篇最有价值的是排查顺序：先确认规则加载，再看是否与旧会话、其他指令或权限冲突，最后才调整措辞。相比往系统提示词里不断堆「必须」「始终」，这种做法更容易定位问题。

但原文没有展示团队实测，也没有不同配置方式的成功率对照。所谓「放错层就失效」，更多是解释框架，不能据此断定某条规则绝不适合写进 CLAUDE.md。

文章对 hooks、output styles 的边界，以及「系统提示词无法完成动态读写文件」的表述也过于绝对。提示词可以指导助手调用工具；真正执行动作的是工具和运行时。是否需要 skill 或 hook，应看你是否需要复用、自动触发或确定性的执行步骤。

我会接受它的分工建议，同时把具体参数、文件路径和事件示例视为需要核验的部分。原文没有说清的地方，不值得用更多配置去补猜测。

能拿来做什么

• 给前端或 Node 仓库整理一份精简的 CLAUDE.md，写清实际技术栈、目录约定、验证命令和错误处理规范，让规则随项目一起维护。
• 做一次性代码审查时，用 --append-system-prompt-file 追加检查项和结果格式，并让问题附带文件位置，方便人工复核。
• 发现指令无效时，先检查加载来源、会话恢复方式和权限规则，再修改提示词；使用原文中的新参数前，确认本机版本支持。
• 搭建文档生成流程时，先跑通读取源码、提取 JSDoc、生成 Markdown 和写文件，再决定哪些步骤封装为 skill，哪些需要通过已支持的 hook 自动执行。