达灵感
设计体验5 阅读

如何用 Codex 把设计规范转成项目规则？

很多团队都有设计规范：Figma 里有颜色、字号、组件、间距、按钮状态、弹窗样式，甚至还有一整套设计系统。但项目做着做着，代码里仍然会出现新的 hex 色值、新的按钮尺寸、新的卡片样式、新的表单间距。

发布时间 2026/07/04

如何用 Codex 把设计规范转成项目规则？

开头：设计规范没有进入代码，最后等于没有规范

很多团队都有设计规范：Figma 里有颜色、字号、组件、间距、按钮状态、弹窗样式，甚至还有一整套设计系统。但项目做着做着，代码里仍然会出现新的 hex 色值、新的按钮尺寸、新的卡片样式、新的表单间距。

原因很简单：设计规范如果只停留在 Figma 或文档里，它对开发过程没有强约束。开发者写页面时不会每次都打开规范对照，AI 写代码时也不会自动知道你的组件边界。于是规范变成“参考资料”，不是“执行规则”。

这就是 Codex 适合介入的地方。Codex 不是只用来写功能，它更适合把“人脑里的项目习惯”变成可重复执行的工程约束：哪些组件必须复用，哪些颜色不能硬编码，哪些间距必须来自 token，移动端怎么处理，页面改完后要怎么验收。OpenAI 官方把 Codex 定义为用于软件开发的 coding agent，可帮助写代码、理解代码库、代码审查、调试以及自动化重构、测试等开发任务。

本文的核心不是“让 Codex 帮你重新设计一套 UI”，而是让 Codex 把已经确定的设计规范，转成项目内长期生效的规则。以后每次改页面、加组件、重构样式，都按这套规则执行。

什么叫把设计规范转成项目规则

把设计规范转成项目规则，不是简单地把 Figma 文档复制进 README。真正有效的项目规则至少要满足三个条件：

  • Codex 能读取：规则需要放在 Codex 会读取或你会明确 @ 提到的位置，比如 AGENTS.md、docs/design-rules.md、docs/component-rules.md、src/components/AGENTS.md。

  • 开发能执行：规则不能只有“高级、干净、有品质感”，而要变成颜色变量、字号等级、组件 API、禁止事项、验收命令。

  • 改动能验证：每次 Codex 修改 UI 后，都要能通过 lint、typecheck、页面检查、响应式检查、组件复用检查来判断是否符合规范。

OpenAI 官方 AGENTS.md 文档说明，Codex 会在开始工作前读取 AGENTS.md，并可以通过全局规则、项目根目录规则、子目录覆盖规则形成一条指令链。因此，把设计规范写进 AGENTS.md 或相关规则文档，比每次在提示词里重复写“请保持设计统一”更稳定。

设计规范应该如何映射成项目规则

设计规范内容转成项目规则落地位置Codex 执行方式
颜色规范主色、语义色、状态色、禁用色、背景层级tokens / tailwind.config / CSS variables统一命名并替换硬编码颜色
字号规范标题、正文、辅助文字、按钮文字、行高typography tokens / text utilities扫描随意字号并改为规范类名
间距规范页面边距、区块间距、卡片内边距、组件间距layout rules / spacing scale限制新增 magic number
组件规范Button、Card、Input、Modal、Tabs 的变体和状态components/AGENTS.md / docs/components.md约束调用方式，不允许复制粘贴新组件
响应式规则断点、移动端列数、菜单收纳、触控热区docs/responsive-rules.md每次 UI 修改后检查移动端
无障碍规则焦点态、对比度、label、键盘可访问性AGENTS.md / a11y checklist修改交互组件时同步检查可访问性
文案风格按钮文案、空状态、错误提示、确认弹窗docs/copywriting-rules.md避免中英文混用和模糊提示

第一步：先把设计规范整理成 Codex 能读懂的输入

不要一上来就让 Codex “根据设计规范优化全站”。这类指令太大，容易出现两个问题：一是 Codex 不知道哪些是硬规则，哪些只是审美参考；二是它可能一次性修改太多文件，导致你很难审查。

更稳的方法是先准备一个设计规范输入包。它不一定复杂，但必须结构化。

  • design-spec.md：用文字整理颜色、字号、间距、圆角、阴影、组件状态、响应式规则。

  • figma-tokens.json：如果你有 Figma Variables 或 Tokens Studio，可以导出 token JSON。

  • screenshots/：放首页、列表页、详情页、移动端页面截图，方便 Codex 结合视觉目标。

  • docs/current-components.md：列出现有组件，比如 Button、Card、Input、Tabs、Modal、Navbar。

  • package.json、tailwind.config.ts、src/components/：让 Codex 对照项目真实结构，而不是凭空制定规则。

OpenAI 的 Codex Prompting 文档也强调，提交 prompt 时应包含 Codex 可使用的上下文，例如相关文件和图片；Codex 在工作过程中也会从文件内容、工具输出和已经完成的步骤中收集上下文。

可复制 Codex 指令 1：先提取设计规范，不要改代码

请先不要修改任何代码。请阅读以下设计规范相关文件，并把它们整理成一份 Codex 可执行的项目规则草案：

需要阅读：

  • docs/design-spec.md

  • docs/current-components.md

  • tailwind.config.ts

  • src/components/**

  • 如存在 tokens、theme、styles 目录，也一起阅读

输出要求：

  1. 提取颜色、字号、间距、圆角、阴影、布局、响应式、组件状态、无障碍、文案风格规则。

  2. 区分“硬规则”和“建议规则”。

  3. 标出当前项目里已经存在的 token、组件和工具类。

  4. 标出设计规范里有，但代码里还没有承载位置的规则。

  5. 不要修改代码，只输出规则草案和建议的文件落点。

第二步：让 Codex 先审计现有项目，而不是直接重构

设计规范转项目规则的第二步，是让 Codex 对照现有代码做差距审计。这个步骤很重要，因为很多项目的问题不是没有规范，而是规范和代码之间断层太大。比如：

  • Figma 里只有 6 个颜色角色，代码里却有 40 多个 hex 色值。

  • 设计规范里只有 3 种按钮尺寸，代码里每个页面都在自定义 padding。

  • 组件库里已经有 Card，但业务页面仍然复制 div + border + shadow。

  • 移动端断点没有统一，有的页面用 640px，有的用 768px，有的完全没有适配。

  • 错误提示、空状态、loading 状态没有统一文案和视觉样式。

这一轮审计的目标不是让 Codex 改代码，而是输出“规则缺口清单”。有了清单，后面才能把规则写进 AGENTS.md、docs 和组件约束里。

可复制 Codex 指令 2：审计设计规范和代码的差距

请基于设计规范和当前代码，做一次“设计规范落地差距审计”。

审计范围：

  • 颜色是否有硬编码 hex / rgb / hsl

  • 字号、行高是否脱离设计 scale

  • spacing 是否大量出现 magic number

  • Button / Card / Input / Modal / Tabs 等是否重复实现

  • 响应式断点是否统一

  • 页面是否存在移动端横向溢出风险

  • 状态样式是否完整：hover、active、focus、disabled、loading、error

  • 无障碍是否缺失：label、aria、键盘焦点、对比度

输出格式：

  1. 发现的问题

  2. 影响范围

  3. 建议转成哪类项目规则

  4. 应该写入哪个文件

  5. 是否需要先补 token / 补组件 / 补文档

限制：

  • 这一步只审计，不改代码。

  • 不要提出大规模视觉重设方案。

  • 所有建议必须基于当前项目已有技术栈。

第三步：生成项目级 AGENTS.md，让 Codex 每次都先读规则

当你已经有规则草案和差距审计结果后，就可以让 Codex 生成项目级 AGENTS.md。这个文件不应该写成设计说明书，而应该写成 Codex 的执行协议。

项目级 AGENTS.md 推荐包含这些模块：

  • 项目定位：项目是什么类型，目标用户是谁，UI 风格不能偏到哪里。

  • 技术栈：React、Next.js、Tailwind、shadcn/ui、CSS Modules 或其他实际栈。

  • 设计系统规则：颜色、字号、间距、圆角、阴影、组件复用。

  • 禁止事项：禁止硬编码颜色，禁止重复实现基础组件，禁止随意新增断点。

  • 修改流程：先审计，再计划，再小步修改，再运行检查。

  • 验收标准：lint、typecheck、build、页面检查、移动端检查。

注意：AGENTS.md 不需要把所有设计细节塞进去。过长会降低可读性，也容易被忽略。根目录 AGENTS.md 放核心规则，详细设计规范放在 docs/design-rules.md，组件规则放在 docs/component-rules.md 或 src/components/AGENTS.md。

可复制 Codex 指令 3：生成 AGENTS.md 和设计规则文档

请根据前面的设计规范草案和项目审计结果，生成一套项目规则文件。

请创建或更新：

  • AGENTS.md

  • docs/design-rules.md

  • docs/component-rules.md

  • docs/ui-review-checklist.md

写作要求：

  1. AGENTS.md 只保留 Codex 每次工作必须遵守的高优先级规则。

  2. docs/design-rules.md 详细记录颜色、字号、间距、圆角、阴影、响应式、状态样式。

  3. docs/component-rules.md 记录 Button、Card、Input、Modal、Tabs 等组件的使用边界。

  4. docs/ui-review-checklist.md 写成可执行验收清单。

  5. 所有规则必须具体、可检查，不要写“高级感”“更好看”“保持统一”这类模糊描述。

  6. 本次只生成规则文档，不修改业务页面代码。

完成后请列出：

  • 新增/修改了哪些文件

  • 每个文件解决什么问题

  • 后续如果要落地到代码，建议分几步做

AGENTS.md 示例：把设计规范写成项目规则

AGENTS.md

Project context

This is a production UI project. UI changes must preserve the existing product direction and follow the design system documented in docs/design-rules.md and docs/component-rules.md.

Tech stack

  • React / Next.js / TypeScript

  • Tailwind CSS

  • Shared UI components in src/components/ui

  • Page-level components in src/components/sections

Design system rules

  • Do not hardcode hex, rgb, hsl, font-size, radius, or shadow values in page files.

  • Use existing design tokens, Tailwind theme values, or CSS variables first.

  • New design tokens must have semantic names, such as color.surface.card, color.text.muted, radius.card, space.section.

  • Reuse existing Button, Card, Input, Badge, Modal, Tabs, EmptyState, and Loading components before creating new UI.

  • Do not create one-off button, card, input, or modal styles inside business pages.

  • Keep desktop, tablet, and mobile behavior consistent with docs/ui-review-checklist.md.

Component rules

  • Before creating a new component, search src/components/ui and src/components/sections for reusable components.

  • If a component needs a new variant, add it to the shared component API instead of copying styles into a page.

  • Component props must stay typed and predictable. Avoid boolean prop combinations that create unclear visual states.

Responsive rules

  • Use the project’s existing breakpoints. Do not introduce a new breakpoint without documenting why.

  • Mobile layouts must avoid horizontal overflow.

  • Clickable targets on mobile should not be smaller than 44px in height when they behave like primary actions.

Verification

After modifying UI code, run the relevant checks:

  • npm run lint

  • npm run typecheck if available

  • npm run build when layout or shared components are changed

Also report what pages/components need manual visual review.

第四步：把设计 Token 落到代码，而不是只写文档

规则文档只是第一层，真正让项目稳定的是 token。颜色、字号、间距、圆角、阴影这些基础规范，应该进入 Tailwind theme、CSS variables、tokens.ts 或主题配置文件。

这里要避免一个坑：不要让 Codex 一口气把全站所有样式都替换掉。更稳的做法是先建立 token，再选一个页面或一组组件做试点，验证没有视觉跑偏后，再逐步替换。

建议分三轮：

  • Token 建模：把颜色、字号、间距、圆角、阴影转成语义 token。

  • 组件接入：先让 Button、Card、Input 等基础组件使用 token。

  • 页面清理：再把页面里的硬编码样式替换成组件和 token。

可复制 Codex 指令 4：把设计规范转成 token，不动页面

请根据 docs/design-rules.md，为当前项目建立或完善设计 token。

目标：

  • 颜色、字号、间距、圆角、阴影必须有统一承载位置。

  • 命名必须使用语义命名，不要使用 blue1、gray2 这类无法表达用途的名字。

  • 优先复用当前项目已有 theme / tailwind / tokens 结构。

限制：

  • 本次不要修改业务页面。

  • 本次不要重写视觉风格。

  • 如果发现规范和当前代码冲突，先列出冲突，不要自行决定替换。

请输出：

  1. 计划修改的 token 文件

  2. 新增/调整的 token 命名表

  3. 是否影响现有组件

  4. 建议下一步先接入哪些基础组件

完成后请运行 lint/typecheck，或说明当前项目没有对应命令。

第五步：把组件使用边界写清楚

很多 UI 不统一，不是 token 问题，而是组件边界不清楚。比如 Button 已经有了，但业务页面仍然手写 <button className="...">；Card 已经有了，但列表页又写了一套 border + shadow；Input 已经有了，但登录页、搜索页、设置页各用一套错误提示。

所以组件规则要回答四个问题：

  • 这个组件解决什么场景？

  • 允许哪些变体？

  • 哪些情况必须复用它？

  • 哪些情况不能使用它，应该新建更高阶业务组件？

这类规则非常适合放在 docs/component-rules.md 和 src/components/AGENTS.md。OpenAI 的 AGENTS.md 文档说明，Codex 会从项目根目录一路读取到当前工作目录，越靠近当前目录的规则越晚出现，也就更适合写子目录专用约束。因此，组件目录可以有更细的规则。

src/components/AGENTS.md 示例

src/components/AGENTS.md

Component directory rules

  • Prefer extending existing shared components over creating new visual primitives.

  • Do not create duplicate Button, Card, Input, Modal, Badge, Tabs, Tooltip, EmptyState, or Loading components.

  • If a new variant is required, update the existing component API and document it in docs/component-rules.md.

  • Keep component props small and explicit. Avoid unclear props such as fancy, modern, beautiful, special.

  • Every interactive component must include disabled, focus, hover, and loading/error states when applicable.

  • Do not import page-specific data fetching logic into shared UI components.

  • Shared components must be presentation-oriented and reusable across pages.

Review checklist before editing components

  1. Search for existing usage.

  2. Confirm the change will not break current variants.

  3. Keep public component APIs stable unless explicitly asked.

  4. Add or update examples when a new variant is introduced.

  5. Run lint/typecheck and report affected pages.

可复制 Codex 指令 5：生成组件使用规则

请扫描 src/components，并基于当前组件结构生成一份组件使用规则。

重点检查：

  • 哪些组件是基础组件

  • 哪些组件是页面区块组件

  • 哪些组件已经重复

  • 哪些组件应该合并

  • 哪些组件应该只允许在特定场景使用

  • 哪些页面正在绕过共享组件直接写样式

请更新：

  • docs/component-rules.md

  • src/components/AGENTS.md

限制：

  • 这一步先写规则和清单，不要重构组件。

  • 如果发现重复组件，请列出重构优先级。

  • 不要删除任何组件。

一条好规则和一条坏规则的区别

类型不建议这样写建议这样写
颜色页面要高级一点，颜色要统一。禁止在业务页面直接写 hex 颜色。新增颜色必须先进入 tokens/colors.ts，并说明语义角色。
按钮按钮样式要好看。新增按钮必须使用 Button 组件；只能使用 primary、secondary、ghost、danger 四种 variant。
间距留白多一点。页面一级区块上下间距使用 64/80/96px；卡片内边距使用 16/24/32px，不允许随意写 17、23、41px。
响应式移动端要适配。小于 768px 时，列表改为单列，筛选栏收纳为抽屉，按钮触控高度不低于 44px。
验收检查一下有没有问题。运行 lint、typecheck，检查首页/列表页/详情页在 desktop、tablet、mobile 三档视口下无横向溢出。

第六步：让 Codex 按规则小步修复，而不是一次性全站改造

规则文件建立好以后，不要马上发一句“按规则优化整个项目”。更稳的方式是按问题类型分批处理。OpenAI Codex Workflows 文档也强调，Codex 更适合在明确上下文、清晰完成标准和可验证步骤下工作；复杂任务可以先规划，再交给 Codex 分阶段执行。

推荐的落地顺序：

  • 先修硬编码颜色：范围清楚，风险较低。

  • 再修 Button / Card / Input 的重复实现：收益高，但需要组件 API 稳定。

  • 再修页面间距和响应式：需要视觉验收，不要和功能修改混在一起。

  • 最后再做大规模组件结构整理：需要测试和人工 review。

可复制 Codex 指令 6：按规则检查违规代码

请根据以下规则文件检查当前项目是否有 UI 规范违规：

  • AGENTS.md

  • docs/design-rules.md

  • docs/component-rules.md

  • docs/ui-review-checklist.md

本次只检查以下问题：

  1. 页面中硬编码颜色、字号、圆角、阴影

  2. 绕过共享 Button / Card / Input 组件的重复实现

  3. 明显不符合项目 spacing scale 的 magic number

  4. 移动端可能横向溢出的布局

输出格式：

  • 违规文件

  • 违规位置

  • 违反了哪条规则

  • 建议修复方式

  • 修复风险等级：低 / 中 / 高

限制：

  • 这一步只输出报告，不修改代码。

可复制 Codex 指令 7：选择一个低风险批次执行修复

请从上一步报告中选择“低风险”的问题做第一批修复。

修复范围：

  • 只处理硬编码颜色和明显可替换的设计 token

  • 不修改业务逻辑

  • 不调整页面结构

  • 不改组件 API

  • 不做视觉重设

要求：

  1. 每个修改都说明对应的设计规则。

  2. 修改后运行 lint/typecheck。

  3. 输出变更摘要和需要人工视觉检查的页面。

  4. 如果某处无法安全替换，请保留并说明原因。

第七步：把 UI 验收也变成规则

很多人只把“怎么写”写成规则，却没有把“怎么验收”写成规则。结果 Codex 改完代码后，lint 通过了，但页面视觉仍然乱。

UI 验收规则建议至少包含：

  • 组件复用：是否使用共享组件，是否出现重复基础组件。

  • Token：是否出现新的硬编码颜色、字号、圆角、阴影。

  • 响应式：桌面、平板、移动三档视口是否无横向滚动。

  • 状态完整：hover、focus、disabled、loading、empty、error 是否完整。

  • 视觉一致：卡片、按钮、表单、弹窗的间距和层级是否一致。

  • 无障碍：表单 label、aria、键盘焦点、对比度是否存在明显问题。

  • 构建验证：lint、typecheck、build 是否通过。

可复制 Codex 指令 8：生成 UI 验收清单

请根据 AGENTS.md、docs/design-rules.md 和 docs/component-rules.md，完善 docs/ui-review-checklist.md。

清单要求：

  • 按页面级、组件级、响应式、状态样式、无障碍、代码质量分类。

  • 每一项都要可检查，不要写抽象描述。

  • 标出哪些可以由命令检查，哪些必须人工视觉检查。

  • 增加“Codex 修改 UI 后必须汇报的内容”模板。

同时在 AGENTS.md 中补充一句：

Codex 修改 UI 后必须按照 docs/ui-review-checklist.md 输出验收结果。

Codex 修改 UI 后的汇报模板

UI change report

Changed files

  • ...

Rules followed

  • Used design tokens from ...

  • Reused shared components from ...

  • Followed responsive rules from ...

Verification

  • lint: passed / failed / unavailable

  • typecheck: passed / failed / unavailable

  • build: passed / failed / unavailable

Manual visual review needed

  • Page: ...

  • Viewports: desktop / tablet / mobile

  • Areas to check: spacing, overflow, states, alignment

Risks

  • Low / Medium / High

  • Reason: ...

第八步：不要把所有设计感觉都塞进规则

设计规范转项目规则，要克制。不是所有设计判断都适合写成规则。比如“高级感”“年轻化”“更有科技感”“不要太普通”，这些词可以作为风格方向，但不能作为 Codex 执行规则。

真正适合写成规则的是可约束、可检查、可复用的内容。

  • 适合写：颜色角色、组件变体、间距 scale、断点、状态样式、命名规范、禁止事项、验收命令。

  • 不适合直接写：高级、干净、年轻、精致、强烈、活泼、像某某网站。

  • 可以转换后再写：把“高级感”转成低饱和色、少边框、明确留白、弱阴影、统一字体层级。

换句话说，Codex 需要的是工程语言，不是审美形容词。设计师可以给方向，但落到项目规则时，必须变成可执行约束。

可复制 Codex 指令 9：把模糊设计语言改成可执行规则

请把以下模糊设计描述转成可执行的项目规则。

输入描述：

  • 页面要更高级

  • 视觉要统一

  • 卡片不要太乱

  • 移动端要舒服

  • 按钮要有点击感

转换要求：

  1. 每条规则都必须可执行。

  2. 每条规则都要说明适用范围。

  3. 尽量对应到 token、组件、布局、响应式、状态样式或验收标准。

  4. 不要使用“高级感”“更好看”“舒服”作为最终规则描述。

  5. 输出可直接写入 docs/design-rules.md 的 Markdown。

常见错误：为什么有些项目规则写了也没用

错误 1：规则太抽象

“保持风格统一”不是规则。Codex 不知道统一到什么程度，也不知道哪些现有样式是标准。要写成“新增按钮必须使用 Button 组件，不允许在页面中手写按钮尺寸和颜色”。

错误 2：规则太长

把整套设计说明书塞进 AGENTS.md，反而会让关键规则被淹没。根目录 AGENTS.md 只放高优先级约束，细节放到 docs 或子目录 AGENTS.md。

错误 3：规则没有和代码结构绑定

如果规则只说“使用设计 Token”，但项目里没有 token 文件、没有 Tailwind theme、没有 CSS variables，Codex 只能临时发挥。规则必须绑定到真实文件。

错误 4：没有验收标准

Codex 改完 UI 后，如果只看代码 diff，很容易漏掉视觉问题。至少要让它说明哪些命令已跑，哪些页面需要人工检查，移动端是否存在溢出风险。

错误 5：把设计系统重构和业务功能混在一起

不要一边让 Codex 加新功能，一边让它顺手统一设计系统。这样 diff 会变得很大，出现问题也难定位。设计规则落地应该作为独立任务。

一套推荐的文件结构

project-root/

├── AGENTS.md

├── docs/

│ ├── design-rules.md

│ ├── component-rules.md

│ ├── ui-review-checklist.md

│ └── copywriting-rules.md

├── src/

│ ├── components/

│ │ ├── AGENTS.md

│ │ ├── ui/

│ │ └── sections/

│ ├── styles/

│ │ ├── tokens.css

│ │ └── globals.css

│ └── lib/

│ └── design-tokens.ts

├── tailwind.config.ts

└── package.json

这个结构的好处是：根目录 AGENTS.md 负责“项目级约束”，docs 负责“规范细节”，components/AGENTS.md 负责“组件目录规则”，token 和 theme 负责“代码执行层”。这样 Codex 不会只看到一堆设计描述，而是能知道规则在哪里、代码应该改哪里、改完怎么验收。

完整工作流：从设计规范到项目规则

  • 准备设计规范输入包：设计文档、token、截图、现有组件说明。

  • 让 Codex 提取设计规则草案：只分析，不改代码。

  • 让 Codex 审计当前项目差距：找出硬编码、重复组件、响应式问题。

  • 生成 AGENTS.md 和 docs 规则文档：把规则写成可执行约束。

  • 建立或完善设计 token：让颜色、字号、间距有代码承载。

  • 写清组件使用边界：哪些必须复用，哪些可以扩展。

  • 按低风险批次落地：不要全站一次性大改。

  • 每次修改后验收：lint、typecheck、build、响应式、视觉 review。

  • 持续维护规则：新增组件、新增 token、新增页面时同步更新规则。

FAQ：关于 Codex 和设计规范转项目规则

1. 没有完整设计系统，也能用 Codex 生成项目规则吗？

可以，但不要伪装成“完整设计系统”。你可以先从最小规则开始：颜色、字号、间距、按钮、卡片、表单、移动端断点。项目越早把这些基础规则固定下来，后面越不容易失控。

2. AGENTS.md 和 README 有什么区别？

README 主要给人看，AGENTS.md 主要给 Codex 这类 coding agent 看。README 可以介绍项目背景和启动方式，AGENTS.md 更应该写执行规则、禁止事项、验证方式和目录级约束。

3. 设计规范要不要全部写进 AGENTS.md？

不建议。AGENTS.md 应该短而硬，只写每次任务都必须遵守的核心规则。详细规范放到 docs 文件中，再在 AGENTS.md 里引用。

4. Codex 可以直接读取 Figma 吗？

取决于你的环境和接入方式。更稳定的做法是把 Figma 中的 Variables、Token、组件说明、关键页面截图导出成文件，再让 Codex 读取这些文件。不要让 Codex 只凭一句“参考 Figma”执行。

5. 设计师应该怎么参与这个流程？

设计师要做的不是写代码，而是把模糊审美判断翻译成规则。比如“不要太乱”要转成卡片层级、边框、阴影、间距、信息密度和状态样式规则。Codex 负责把规则落进项目，设计师负责确认规则是否准确。

6. 什么时候不应该让 Codex 自动修改？

涉及大规模视觉重设、品牌方向调整、组件 API 破坏性变更、设计系统迁移时，不应该直接让 Codex 执行。应该先让它产出计划和影响范围，再人工确认后分阶段处理。

7. 项目规则需要多久更新一次？

只要新增了基础组件、新增了设计 token、调整了响应式策略、改变了按钮或卡片体系，就应该同步更新规则。项目规则不是一次性文件，而是设计系统和代码之间的同步层。

总结：设计规范只有进入规则层，才能真正影响项目

用 Codex 把设计规范转成项目规则，本质上是在解决一个长期问题：设计系统如何持续影响代码。

设计规范只在 Figma 里，开发会忘；只在口头沟通里，AI 不会知道；只在 README 里，执行力度不够。把它转成 AGENTS.md、docs 规则、设计 token、组件边界和验收清单之后，Codex 才能在每次任务开始时读取规则，在修改代码时遵守规则，在完成后按规则汇报。

真正成熟的做法不是让 Codex “帮我优化 UI”，而是让 Codex 明确知道：这个项目允许什么、禁止什么、优先复用什么、改完怎么证明没有偏离规范。

一句话结论：设计规范负责定义“应该长什么样”，项目规则负责约束“代码以后必须怎么写”。Codex 的价值，就是把这两者连接起来。

参考资料

Codex设计系统AGENTS.md项目规则设计体验