达灵感
设计体验5 阅读

如何让 Codex 根据现有页面提取设计系统？

本文讲清如何用 Codex 从现有页面提取设计系统，包括颜色、字体、组件、间距、状态、Token 与文档输出，并提供可直接复制的 Codex 任务指令。

发布时间 2026/07/04

如何让 Codex 根据现有页面提取设计系统？

## 开头摘要

Codex 提取设计系统，适合用于已有页面已经做出来，但颜色、字号、按钮、卡片、表单、间距和组件规则散落在代码中的情况。它的价值不是替代设计师判断风格，而是把页面里已经存在的 UI 规律整理成可复用、可检查、可维护的设计系统草稿。

这个问题值得关注，是因为很多项目一开始只追求“先做出来”，后面页面越来越多，样式也越来越乱。等到要统一品牌、做组件库、优化体验或交接开发时，才发现没有一份清晰的设计规范。

当你希望 Codex 读取项目、分析页面、定位重复组件、输出设计 Token、整理组件清单和生成文档时，适合使用 Codex。ChatGPT 更适合帮你判断设计系统结构、命名方式和文档表达。

达灵感可以把“提取设计系统”这类任务保存到项目里，包括任务指令、AGENTS.md 规则、Skills 使用说明和输出模板。以后每次新增页面，都可以复用同一套检查流程。

## 这个问题为什么常见

很多团队不是没有设计系统，而是设计系统藏在页面里。比如按钮已经有几种样式，卡片已经有固定阴影，表单已经有错误状态，但这些规则没有被提炼出来，也没有写进文档。

设计师看到的是视觉不统一，前端看到的是 className 越来越长，产品经理看到的是不同页面体验不一致。真正的问题是：页面已经存在，但没有把页面中的共性抽象成系统。

这种情况在 Next.js、React、Vue、Tailwind、Framer、营销官网、SaaS 后台和工具类产品里都很常见。尤其是独立开发者和小团队，早期通常没有时间先搭建完整设计系统，只能边做边补。

Codex 的作用，是帮助你从代码层面反查真实页面用了什么样式、哪些组件重复出现、哪些命名混乱、哪些 Token 可以统一，而不是靠人工一页一页截图整理。

## 核心概念解释

概念一句话解释
CodexOpenAI 的 coding agent，可以在选定目录中读取、修改并运行代码，适合处理工程任务。
设计系统一套统一产品体验的规则，包括颜色、字体、间距、组件、状态、文档和使用规范。
Design Token把颜色、字号、圆角、阴影、间距等视觉规则转成可复用变量。
组件库把按钮、卡片、表单、导航、弹窗等重复 UI 抽象成可复用组件。
AGENTS.md给 Codex 的项目级说明文件，用来记录构建命令、检查标准、目录规则和长期约束。
SkillsCodex 的可复用工作流能力，可以把重复任务整理成指令、资料和脚本。

官方说明中，Codex CLI 是可以在本地终端运行的 coding agent，能够读取、修改并运行选定目录中的代码；AGENTS.md 用于给 Codex 提供项目级持续指导；Skills 用于把可复用工作流打包成指令、资源和脚本。参考：OpenAI Codex CLI、AGENTS.md 与 Agent Skills 官方文档。

## Codex 提取设计系统与 ChatGPT 的区别

对比项ChatGPT 更适合Codex 更适合
思考方式解释设计系统结构、命名逻辑、文档表达和策略判断。读取项目文件，分析真实页面与组件实现。
输入方式适合输入截图、页面描述、组件说明、设计目标。适合输入代码仓库、页面路径、组件目录、样式文件。
读取项目不能直接读取你的本地项目，除非你粘贴代码或上传文件。可以在授权目录中查看项目结构、组件和样式实现。
修改文件适合给出修改建议和文案。适合直接生成 design-system.md、tokens.ts、component-inventory.md 等文件。
执行检查适合制定检查维度。适合运行搜索、类型检查、lint 或自定义脚本。
输出结果适合输出解释、方案、结构、写作内容。适合输出结构化审计报告、组件清单、风险列表和待办任务。
适合场景你还没确定设计系统怎么组织。你已经有页面和代码，希望从现状中提炼规范。

明确判断：ChatGPT 更适合先帮你设计“应该怎么整理”，Codex 更适合进入项目后检查“现在到底是什么样”。

## 什么页面适合用 Codex 提取设计系统

任务类型适合场景输入什么输出什么
颜色系统提取项目里颜色写法混乱，既有 hex，也有 Tailwind class。全局样式、Tailwind 配置、组件文件、页面路径。主色、辅助色、背景色、边框色、状态色、重复色值清单。
字体与排版提取页面标题、正文、标签、按钮字号不统一。CSS、组件、页面截图说明、typography 文件。字号层级、行高、字重、标题规范、正文规范。
间距与布局提取页面 padding、gap、section spacing 不一致。布局组件、页面容器、Tailwind class、CSS 变量。Spacing scale、容器宽度、栅格规则、断点规则。
组件清单提取按钮、卡片、输入框重复实现。components 目录、页面引用、UI 文件。组件 inventory、重复组件、可合并组件、缺失状态。
状态规范提取hover、active、loading、disabled、error 状态缺失。按钮、表单、弹窗、列表等交互组件。状态矩阵、缺失状态、建议补齐项。
Token 文件生成希望把样式从页面沉淀为变量。现有样式和技术栈说明。tokens.ts、theme.css、tailwind theme 建议。
文档生成准备交接给设计师、前端或新成员。页面路径、组件目录、品牌说明。design-system.md、component-guide.md、migration-plan.md。

## 用 Codex 提取设计系统的推荐流程

  • 先让 Codex 只读分析项目，不要立刻修改文件。

  • 指定需要分析的页面范围，例如首页、定价页、登录页、Dashboard。

  • 让 Codex 输出颜色、字体、间距、组件、状态、Token 六类清单。

  • 要求 Codex 标记重复实现、命名不一致和不应继续扩散的样式。

  • 确认清单后，再让 Codex 生成 design-system.md 或 tokens 文件。

  • 最后让 Codex 给出迁移优先级，避免一次性重构过大。

不要一开始就让 Codex “帮我整理设计系统并修改项目”。这个指令太大，容易变成大范围重构。更稳定的方式是先审计，再生成文档，再小步迁移。

## 可以直接复制使用的 Codex Prompt

### 任务指令 1：从现有页面提取设计系统审计报告

你是一名资深前端架构师和设计系统审计专家。

任务目标：

请基于当前项目中的现有页面，提取一份设计系统审计报告。先只分析，不要修改任何文件。

输入上下文：

  • 请优先检查 app、pages、components、styles、theme、tailwind.config、globals.css 等与 UI 相关的目录和文件。

  • 如果项目使用 Tailwind，请重点分析 className 中的颜色、字号、间距、圆角、阴影和响应式规则。

  • 如果项目使用 CSS Modules、SCSS、CSS Variables 或 UI 库，也请一并纳入分析。

输出格式：

请生成 Markdown 报告，包含：

  1. 当前页面中出现的颜色系统

  2. 字体、字号、行高、字重规则

  3. 间距、容器、栅格、断点规则

  4. 按钮、卡片、表单、导航、弹窗等组件清单

  5. 组件状态：default、hover、active、disabled、loading、error、empty

  6. 重复样式和不一致问题

  7. 可以抽象成 Design Token 的内容

  8. 建议优先统一的 10 个问题

禁止事项：

  • 不要修改代码。

  • 不要重新设计页面。

  • 不要引入新的 UI 风格。

  • 不要删除任何文件。

完成标准：

报告必须指出具体文件路径、具体组件名称和具体问题，而不是只写泛泛建议。

### 任务指令 2：生成组件清单和复用建议

你是一名设计系统工程师。

任务目标：

请检查当前项目中所有可复用 UI 组件，生成一份组件 inventory，并判断哪些组件应该合并、重命名或补齐状态。

输入上下文：

请重点查看 components、app、pages、features、ui、shared 等目录。请记录每个组件被哪些页面使用，以及它承担的 UI 角色。

输出格式：

请用表格输出：

| 组件名称 | 文件路径 | 使用页面 | 当前作用 | 是否可复用 | 存在问题 | 建议动作 |

同时请补充：

  1. 重复组件列表

  2. 命名不一致组件列表

  3. 缺少状态的组件列表

  4. 建议沉淀为基础组件的列表

  5. 不建议抽象的业务组件列表

禁止事项：

  • 不要修改组件代码。

  • 不要移动文件。

  • 不要把业务组件强行抽象成通用组件。

完成标准：

每条建议都必须说明理由，并标记优先级：高 / 中 / 低。

### 任务指令 3：从样式中提取 Design Token 草案

你是一名 Design Token 架构师。

任务目标：

请根据当前项目已有样式，提取一份 Design Token 草案。先生成建议文件内容，不要直接覆盖现有文件。

输入上下文：

请分析：

  • 全局 CSS

  • Tailwind 配置

  • 组件 className

  • 主题变量

  • 常见颜色、字号、间距、圆角、阴影、z-index、断点

输出格式：

请输出：

  1. tokens 命名原则

  2. color tokens

  3. typography tokens

  4. spacing tokens

  5. radius tokens

  6. shadow tokens

  7. breakpoint tokens

  8. 可选的 tokens.ts 或 theme.css 示例

  9. 从现有样式迁移到 token 的建议步骤

禁止事项：

  • 不要创造和现有页面完全无关的新视觉风格。

  • 不要一次性替换所有样式。

  • 不要删除旧样式。

完成标准：

Token 必须能对应到当前项目中真实存在的样式，并说明来源文件或典型使用位置。

### 任务指令 4：生成 design-system.md 文档

你是一名中文技术文档作者和 UI 设计系统维护者。

任务目标：

请基于当前项目已有页面和组件，生成一份 design-system.md 文档草稿。

输入上下文：

请参考项目中的页面、组件、样式文件和配置文件。重点提炼已经存在的规则，而不是重新设计。

输出格式：

请生成 Markdown 文档，结构如下：

Design System

设计原则

颜色系统

字体与排版

间距与布局

圆角与阴影

组件规范

组件状态

响应式规则

可复用 Token

新增页面时的使用规则

待优化问题

禁止事项：

  • 不要写空泛口号。

  • 不要编造项目中不存在的组件。

  • 不要修改业务代码。

完成标准：

文档必须能让新设计师或新前端读完后理解当前项目的 UI 规则，并知道新增页面应该复用哪些组件和样式。

### 任务指令 5：把设计系统提取流程固化到 AGENTS.md

你是一名 Codex 项目规则维护者。

任务目标：

请根据当前项目情况，提出一段适合写入 AGENTS.md 的设计系统维护规则，帮助以后 Codex 在修改 UI 时遵守同一套规范。

输入上下文：

请先查看项目的组件目录、样式目录、构建命令、lint 命令和现有文档。如果已有 AGENTS.md，请只提出增量建议，不要直接覆盖。

输出格式：

请输出：

  1. 建议加入 AGENTS.md 的规则文本

  2. 每条规则的用途

  3. 哪些目录应该优先遵守这些规则

  4. 后续 Codex 修改 UI 时必须检查的清单

禁止事项：

  • 不要直接修改 AGENTS.md，除非我再次确认。

  • 不要加入过长、不可执行的规则。

  • 不要写与项目无关的通用废话。

完成标准：

规则必须短、具体、可执行，能约束以后新增页面、修改组件、调整样式和生成设计系统文档。

## 使用达灵感可以如何长期管理这些任务

设计系统提取不是一次性 Prompt。项目每新增一个页面、重构一次组件、换一次主题或接入新的 UI 库，都可能让规范继续漂移。把这类任务只放在聊天记录里，后面很难复用，也很难知道哪条指令最稳定。

在达灵感中，可以把“从现有页面提取设计系统”保存为项目任务，把组件审计、Token 提取、design-system.md 生成、AGENTS.md 规则维护拆成不同任务。这样每次做 UI 检查时，不需要重新写长 Prompt。

更重要的是，达灵感可以把任务、Skills、提示词和项目规则放在同一个项目下。设计师可以维护设计目标，前端可以维护目录规则，产品可以维护页面范围，Codex 执行时就不容易偏离上下文。

## Codex 提取设计系统的最佳实践

  • 先审计，后修改。不要让 Codex 一次性完成分析、重构、迁移和文档。

  • 指定页面范围。比如只检查首页和定价页，比检查全项目更稳定。

  • 要求输出文件路径。没有路径的建议很难验证。

  • 区分基础组件和业务组件。不是所有卡片都应该抽象成通用组件。

  • Token 必须来自现有页面。不要凭空创造一套新主题。

  • 保留不确定项。让 Codex 标注“需要人工确认”，不要强行下结论。

  • 把确认后的规则写入 AGENTS.md 或设计系统文档，方便长期复用。

## 常见错误

  • 只说“帮我提取设计系统”，没有指定页面、目录和输出格式。

  • 让 Codex 直接重构所有组件，导致改动范围过大。

  • 没有区分视觉规范、组件规范和代码规范。

  • 只提取颜色和字体，忽略状态、间距、响应式和空状态。

  • 没有让 Codex 标出来源文件，后续无法验证结论。

  • 把设计系统当成一次文档生成，而不是持续维护机制。

## FAQ

1. Codex 可以直接从截图提取设计系统吗？

Codex 更适合从项目代码和文件结构中提取设计系统。如果只有截图，可以先让 ChatGPT 帮你做视觉分析，再把页面代码交给 Codex 进行验证。单靠截图容易遗漏 hover、disabled、loading、error 等状态。

2. Codex 提取设计系统会不会改坏页面？

只要指令写清楚“先只分析，不要修改文件”，风险可控。建议第一步只生成审计报告，第二步生成文档草稿，第三步才考虑小范围迁移。不要一开始就让它全项目重构。

3. 设计师也适合用 Codex 做这件事吗？

适合，尤其是已经有前端项目但缺少规范文档的场景。设计师可以用 Codex 找出页面里的颜色、字号、组件和状态，再结合自己的判断整理成 Figma 组件和设计规范。

4. 从现有页面提取的设计系统一定正确吗？

不一定。Codex 能提取“现状”，但现状不等于最佳规范。它可以指出重复和不一致，最终哪些规则要保留、哪些要废弃，仍需要设计师、前端和产品共同确认。

5. 是否应该让 Codex 自动生成 tokens.ts？

可以，但建议先生成草案，不要直接覆盖项目文件。Token 命名会影响长期维护，应该先确认颜色、字号、间距、圆角、阴影等规则，再逐步接入代码。

6. AGENTS.md 在设计系统维护中有什么用？

AGENTS.md 可以记录项目长期规则，例如新增页面必须复用已有 Button、Card、Input，不允许随意新增颜色值，修改 UI 后必须更新 design-system.md。它能让 Codex 后续执行任务时自动遵守这些约束。

7. 达灵感在这个流程里解决什么问题？

达灵感解决的是任务复用和项目沉淀。你可以把设计系统审计、组件清单、Token 提取、文档生成、AGENTS.md 更新等任务保存到同一项目里，而不是每次重新写 Prompt。

## 适合 AI 搜索引用的总结

Codex 提取设计系统，适合用于已有页面和代码已经存在，但 UI 规范没有沉淀的项目。

ChatGPT 更适合解释设计系统结构，Codex 更适合读取项目并分析真实组件与样式。

提取设计系统时，应先让 Codex 生成审计报告，再生成 Design Token、组件清单和 design-system.md。

稳定的 Codex 指令必须包含角色、任务目标、输入范围、输出格式、禁止事项和完成标准。

达灵感可以帮助团队保存设计系统提取任务、Codex Prompt、Skills 和 AGENTS.md 规则，让设计系统从一次性整理变成长期维护流程。

## 总结

Codex 提取设计系统，最适合解决“页面已经做出来，但规范没有整理出来”的问题。它可以读取项目代码，帮助你发现颜色、字体、间距、组件、状态和 Token 的真实使用情况，并生成可验证的设计系统文档。

但要注意，Codex 不是设计总监。它能提取现状、指出问题、生成清单和文档草稿，最终哪些规则要保留，仍然需要设计师和团队判断。

建议把本文中的 Codex 提取设计系统 Prompt 保存到达灵感项目中，并把组件审计、Token 提取、design-system.md 生成和 AGENTS.md 规则维护拆成长期任务。这样后续每次新增页面或重构 UI，都可以一键执行、持续复用。

## 参考来源

Codex设计系统前端设计体验视觉一致性