给 AI 界面改动划定文件权限

让 AI 把结算页标题的间距收紧一点，结果它顺手改了共享间距变量：标题看起来对了，设置页却跟着变挤。原文讨论的就是这种局部修补引发的全局变化。

作者的做法是默认冻结设计令牌（design tokens），只允许 agent 修改指定组件；确实需要调整共享尺度时，先提交文字提案。这套规则值得借鉴，因为审查 AI 生成的 UI 代码，不能只看目标页面是否变漂亮，还要看它动了多少地方。

为什么改一个标题，会影响整个站点

设计令牌是间距、颜色、字号等设计值的共享入口。组件引用同一个变量，就能保持一致；但修改这个变量，也会同时影响所有引用它的页面。

原文举的例子是：agent 为了调整 checkout header，除了改组件，还修改了共享文件里的 --space-3，理由是觉得 4px 更合适。标题的效果符合要求，设置页却悄悄压缩了。

作者认为，agent 容易把共享令牌当作正确的抽象层。模型见过大量「把间距放进主题」的建议，于是遇到局部间距问题，可能选择调整整套尺度。

这个解释属于作者的判断，原文没有实验验证。但它指出了一个实际的审查问题：修改位置越基础，影响范围越可能超出任务描述。

功能级 UI 调整应该先消费设计系统，修改共享尺度需要单独说明理由。

怎样把「别乱改」变成明确边界

作者给出三层约束：默认禁止修改令牌和主题模块；通过允许清单指定可改组件；需要修改令牌时，由人工指令明确解锁，或另开 PR。

下面这段提示词把文件边界和受阻后的处理方式一起写清楚，可以直接作为任务模板：

UI change only. Read-only paths (do not modify):
- src/styles/tokens.css
- src/styles/theme/*.css
- tailwind.config.* / @theme blocks that define the shared scale
- packages/design-tokens/**

Allowlist (edit only these):
- src/features/checkout/CheckoutHeader.tsx
- src/features/checkout/CheckoutHeader.module.css

If the design cannot be achieved without a new token, stop and propose the token
change in plain language — do not edit token files in this PR.

要留意最后两行：无法完成时，先停下来提出令牌变更建议。作者提醒，只禁止改共享文件，agent 可能转而塞入一次性的十六进制颜色或任意 Tailwind 值，把问题藏进组件。

允许清单也应写成路径。任务范围较大时，可以开放 src/features/checkout/**；涉及 Storybook，再加入对应 stories 文件。同时明确排除拥有共享尺度的 **/tokens*、**/theme* 和 **/*.config.*。

在 Monorepo 中，可以允许修改 apps/web/...，同时冻结 packages/ui/tokens。Tailwind v4 的 @theme、JS 主题模块和 CSS 变量一样，都需要按影响范围管理，文件格式不会缩小波及面。

审查先看改了哪些文件，再看页面效果

提示词表达了约束，审查机制负责发现越界。作者建议先打开文件变更列表：一个声称只做小幅 UI 调整的 PR，如果碰了共享尺度，应先处理范围问题，再讨论标题的 padding。

仓库可以在 tokens.css 或 design-tokens 发生变化时让检查失败，或发出明确警告；带有 tokens、design-system 标签的 PR 再走相应流程。另一种选择是为这些路径要求 OWNERS 式审批。

以下变化尤其需要解释：在功能 PR 中修改共享间距、颜色或字体尺度；声称某个令牌无人使用，却没有全仓搜索记录就重命名或删除；新增令牌后只用一次；为贴合设计稿，把「临时」硬编码值写进令牌文件。

合理的令牌修改当然存在。作者希望它有独立的审查范围，附上 RFC 或设计讨论，并提供多个页面、不同断点的前后截图。对于已经计划删除的旧主题文件，也可以记录明确的允许清单例外。

我的判断

我赞同把共享设计尺度与局部功能调整分开。组件效果正确，只能证明目标位置看起来合适，不能证明共享变量改得合理。独立的令牌 PR 能让审查者直接看到这次变更的影响范围。

但原文没有提供采用规则前后的缺陷率、返工量或效率对照，这是作者的实践经验，不能据此断言它一定能减少多少事故。

还要区分提示词里的「只读」和实际权限。贴上约束块，并不会自动获得文件系统级保护；原文也没有给出可直接运行的 CI 配置。

与完全放开修改相比，冻结能收窄审查范围；与彻底禁止设计系统演进相比，明确解锁又保留了调整空间。前提是团队愿意处理这些提案，否则规则可能只会把新增令牌的需求推成组件里的临时值。

能拿来做什么

• 下次让 AI 调整 React 组件样式时，把可改组件和样式文件逐项列出，并将共享令牌、主题模块及相关配置加入只读清单。
• 在提示词里加入「现有令牌无法实现时，先用一段话提出变更建议」，审查时同时检查是否出现绕过约束的硬编码值。
• 审查 UI PR 时，先看文件列表。发现共享尺度被改动，就要求补充影响说明；需要调整令牌的，拆出独立提交或 PR，并检查多个使用页面。
• 使用 Tailwind v4 或 Monorepo 时，确认共享尺度真正定义在哪里，再设置路径规则，避免只冻结 tokens.css，漏掉 @theme 或公共包。