Claude Code CLAUDE.md 权限配方：减少重复说明和危险访问

很多 Claude Code 失败并不是模型弱，而是每次会话的项目规则都不一样。清晰的 CLAUDE.md 加上 permission recipe，可以减少重复上下文、危险修改和验证遗漏。

这篇文章介绍初学者第一版配方。目标不是把代理锁死，而是区分只读上下文、需要询问的区域、绝对不能碰的区域和自动验证命令。

相关阅读: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

为什么这个做法有效

CLAUDE.md 不是记忆，而是工作契约。它写清验证命令、受保护目录、免费 PDF、Gumroad 和咨询路径后，对开发和发布都有效。

permission recipe 把契约变成行为。把 read-only、ask-before、never-touch 和 auto proof commands 分开，可以减少 Claude Code 自行越界的概率。

实务流程

1. 在 CLAUDE.md 写目标、质量标准、验证命令和收入路径
2. 把文件区域分成 read-only、ask-before、never-touch
3. 写清 Claude Code 可自动执行的 proof commands
4. deploy、删除和不可逆操作必须人工确认
5. 发布后截图检查 h1、正文开头、CTA 和 Gumroad 链接

场景	安全做法	验证
个人网站	文章正文可编辑，表单和 API 需要先询问	build 和公开 URL
团队 PR	允许审查 diff，push 和 deploy 等明确要求	PR diff
收入页面	保护商品链接、价格和咨询表单	点击检查

可直接复制的提示词和代码

请为这个项目创建 CLAUDE.md permission recipe。包含 read-only、ask-before、never-touch、auto proof commands、公开 URL 检查，以及免费 PDF、Gumroad 商品和咨询路径的保护规则。

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

示例不是实际配置文件，而是用代码表达决策。真实项目要结合团队权限、CI 和部署流程调整。

三个真实例子

首次设置

先让 Claude Code 读取 README 和 package.json，再在第一次编辑前创建 CLAUDE.md。第一次编辑限制在一个文件，方便判断成败。

多语言文章

不要只相信 slug 和 frontmatter。规则里写明正文开头和 CTA 必须是目标语言，并用截图证明。

咨询前准备

带着权限表、禁止区域和验证命令去咨询，会议就会变成落地会，而不是抽象 AI 建议。

需要避免的失败例

• CLAUDE.md 只写价值观，不写具体禁止区域。
• 因为方便就允许自动 deploy 或删除。
• 把商品链接和咨询表单当成普通内容文件。

规则太长会被忽略。先保持短，每次真实失败后只增加一条规则。

如何连接免费 PDF、Gumroad 和咨询

基础操作还不稳时，把 免费速查表 放在手边。要整理 CLAUDE.md、权限、hooks、MCP 和 CI，Setup Guide 是最快的付费路径。

需要标准化 review 和 debug 请求时，用 50 Prompt Templates。需要设计团队规则或收入路径时，用 咨询。资源比较在 产品页。

发布前后要检查什么

发布前检查文章和新的 CLAUDE.md 规则是否与权限配方冲突。发布后用手机宽度查看各语言 h1、正文开头、CTA 和商品链接。

接下来要看的数字

观察 Setup Guide 点击、PDF 开始、咨询访问和权限相关文章回游。如果这个 slug 带来咨询增长，读者需要的是运用设计而不是更多模板。

30分钟运营复盘

把 CLAUDE.md 权限配方 放进真实工作后，最有价值的检查通常在第二天。先看运行记录，把允许范围、实际修改文件、验证命令和已经打开过的公开页面写成一条证据。不要只写“已检查页面”，要写清楚手机宽度的 h1、正文开头、CTA 区域、Gumroad 链接和咨询路径。

然后把工作者的安心和读者的行动分开看。工作者侧要确认禁止区域没有被碰、build 有证据、公开 URL 指向同一个 slug、翻译页面没有偷偷保留英文正文。读者侧要确认下一步明确：还在学命令的人拿免费 PDF，已经有重复瓶颈的人看 Gumroad，需要流程设计的人走咨询。

最后，把复盘变成下一次的一条规则。不要一次增加十条。只增加能避免这次问题的一条：改 layout 前先问、生产环境每个 Gumroad URL 都点击、每个语言都截图正文开头。每天能执行的小规则，比没人读的长政策更有价值。

留下一条小验证日志

如果要持续使用这个方法，最后只留一条验证日志。内容包括日期、slug、主 CTA、build 结果、公开 URL、截图确认过的语言，以及下一次要改的候选点。不需要写成长日报，越短越容易第二天读。下次再让 Claude Code 工作时，这一条记录就能说明上次确认到哪里、加强了哪条商品路径、哪种语言必须重点看。内容运营如果每天从零开始，很容易变形；小日志越多，免费 PDF、Gumroad 和咨询路径越容易稳定改善。

下周优先改哪里

下周优化时，先看已经有流量的文章。与其大改没人访问的页面，不如在已有搜索流量的文章里减少 CTA 犹豫。如果免费 PDF 有点击但 Gumroad 没有继续，就在商品说明前补一段“能省掉哪项工作”。如果 Gumroad 有点击但购买弱，就在文章里具体化交付物，而不是只谈价格。若有人进入咨询页，就说明读者需要流程设计，文章里应写清咨询前要准备的信息。