制作公司让 Claude Code 改客户网站前的权限检查表

制作公司每天都会遇到小修改：LP 按钮、主标题、活动日期、案例导语。Claude Code 可以很快改完，但客户网站最先需要的不是速度，而是边界：它到底能碰哪里？

这份检查表适合维护 WordPress、Astro、Next.js、静态落地页和带表单活动页的团队。

要点

• 编辑前先把文件分成只读、可编辑、禁止。
• 差分、构建、链接检查和移动端检查可以交给 Claude Code。客户确认和发布判断必须由人做。
• 客户数据、广告标签、表单提交地址、分析代码、支付设置和法律文案要保护。
• 个人先用免费 PDF；团队统一流程用 setup guide；多人客户项目适合咨询。

把权限分成三层

代理商事故常常不是技术事故，而是范围事故。客户说“改这个按钮”，结果共用 header、追踪代码或表单地址被改了。

先写三层表。

层级	含义	例子
只读	可以看，不可以改	现有 LP、设计参考、旧 CTA
可编辑	本次允许修改	目标页面、文案数据、测试文案
禁止	不需要就不打开，绝不修改	.env、客户列表、广告像素、支付设置

这个表会让提示词稳定很多。AI 不擅长猜边界，写出来才可靠。

Claude Code 做什么

Claude Code 可以生成差分、修改按钮文案、保持链接、跑构建、检查手机宽度。

人要判断品牌语气、法务表达、广告承诺和是否发布。客户确认也是人的节点。

可复制指令

只修改这个客户落地页的 CTA 文案。

可编辑:
- site/src/pages/campaign.astro
- site/src/content/campaign-copy.ts

只读:
- site/src/layouts/BaseLayout.astro
- site/src/components/Header.astro

不要触碰:
- .env*
- 表单提交地址
- analytics / ads / pixel 代码
- 价格、合同、法律、隐私政策

任务:
1. 缩短 CTA 标题
2. 按钮改为“预约免费咨询”
3. 链接仍然保持 /training/
4. 运行 npm run build
5. 报告差分和验证结果

重点是把只读和可编辑分开。Claude Code 可以读上下文，但读不等于允许修改。

小型保护脚本

const diff = process.env.DIFF_TEXT || "";
const forbidden = [".env", "gtag(", "fbq(", "stripe", "customer_email"];

const hits = forbidden.filter((word) => diff.includes(word));
if (hits.length) {
  console.error("疑似禁止区域差分:", hits.join(", "));
  process.exit(1);
}

console.log("禁止词检查通过");

实际使用时把 git diff 传入 DIFF_TEXT。它不完美，但能早发现广告、支付、客户数据相关误改。

三个场景

1. 修改 LP 按钮文案
只允许目标页面。表单地址、标签、价格禁止。发布前检查移动端按钮是否换行崩坏。

2. 缩短案例页导语
旧案例只读，目标文章可编辑。客户名、成果数字、行业表述由人确认。

3. 替换活动结束日期
日期也会影响 OGP、结构化数据、CTA 链接和表单截止。让 Claude Code 列影响范围，人来批准发布。

常见坑

坑1：用“帮我优化一下”开始
这会导致大范围修改。先列文件。

坑2：没有禁止清单
.env、广告、支付、表单必须明确保护。

坑3：构建成功就发布
构建看不出 CTA 链接和 canonical 是否错。要查公开 URL、h1、链接和手机显示。

坑4：未经批准强化宣传语
“第一”“保证”“最低价”需要依据。AI 写出来也要人挡住。

CTA：下一步

个人练习先拿免费速查 PDF。制作团队要统一 CLAUDE.md、权限、hooks 和设置习惯，可以看Setup Guide。

多人客户项目建议用导入咨询把只读、可编辑、禁止区域按真实项目设计出来。相关可读权限指南和团队导入风险台账。

按客户保留一页操作备忘

制作公司使用这份清单时，最好每个客户保留一页备忘。每次重新判断会让边界随着负责人变化而漂移。备忘里写清可编辑目录、必须检查的公开 URL、禁止配置文件、审批人和回滚方法。

带表单的 LP 要把表单提交地址、感谢页、统计事件和广告落地链接当作一组。只改按钮文案也可能让事件名或链接目标错位，最后广告报告和咨询数量都会失真。

给 Claude Code 的指令中还要指定报告格式。让它用五行报告修改文件、没有触碰的禁止区域、build 结果、手机宽度检查、CTA 链接目标。这样负责人审核时不会只看页面是否能打开。

上线流程要从小范围开始。先让一个负责人审核两次同类修改，确认稳定后，再把轻量修改交给其他成员。不要一开始扩到所有客户项目。

即使不修改统计代码，CTA 文案变化也会改变数字含义。比如按钮从“下载资料”改成“预约咨询”，同一个点击事件背后的意图已经不同。制作团队应在客户备忘里记录修改日期、旧文案、新文案和想推动的行动。

给客户看的报告不要只贴 git diff。更实用的是四行摘要：改了什么文案、链接是否保持、表单是否未触碰、手机端是否能正常点击。这样非技术负责人也能参与审核。

回滚方法也要在开工前写好。目标文件、回滚命令、回滚后检查的 URL 写成一行即可。越是在紧急发布前，越不能临时寻找回滚路径。

复盘时还要看客户是否容易确认。技术团队习惯看 diff，但客户负责人通常只想知道按钮、表单、链接和展示是否符合要求。把确认语言翻译成客户能读的四行摘要，能减少发布前来回确认的时间。

如果一个客户项目经常需要相同修改，可以把这份清单写进该项目的 CLAUDE.md。这样 Claude Code 每次启动都能先看到边界，不需要靠担当者记忆。

把收入路径也放进代理商检查

代理商项目里，权限检查不能和收入路径分开。修改 CTA、增加资料下载按钮、放置 Gumroad 教材链接、引导到咨询表单，看起来只是文案或链接变化，但会直接影响客户如何计算销售线索。

所以给 Claude Code 的任务里，要写清可以修改的 UI，也要写清不能破坏的统计。表单提交事件、感谢页 URL、广告参数、商品链接和联系邮箱都应该进入检查清单。公开确认时，不只看页面是否打开，还要确认读者能不能进入下一步。

每次发布后，用一行记录客户名、负责人、公开 URL、主要 CTA 和回滚方法。这个小记录会让下个月优化和换人交接都更稳。

最后还要把发布后的咨询数量放进复盘。只确认页面显示正常，会漏掉按钮可见但没有人进入表单的问题。权限、显示、点击和表单到达要一起看。

实际试过的结果

我用这份清单测试了一次 LP CTA 修改。可编辑文件限制为两个，表单地址和追踪代码列入禁止，再检查构建和移动端。

最有效的是只读和可编辑的分离。Claude Code 能看足够上下文，但差分仍保持很窄。代理商场景里，边界写法和模型能力一样重要。