企业官网建设流程全解析

开门见山说结论：UI Skill 有没有用，取决于你怎么定义“有用”。我拿 Codex 分别跑了三组 UI 任务，有 Skill 描述和没有 Skill 描述，结果差距大到让我有点意外，不是“画得漂不漂亮”这种审美问题，而是整个产物的结构、可维护性和返工次数完全不在一个量级上。

先说下背景，我平时主要折腾 AI 编程助手，Codex 是我最近用得比较多的命令行 Agent。它跟普通补全类工具不一样，能自己读文件、跑命令、多轮修改，像一个真的实习生。平时我用它写脚本、改配置、做点小工具，但一直没怎么让它正经做前端界面，因为我潜意识里觉得这种偏“审美”和“一致性”的活儿，Agent 干不好。直到我在官方文档里翻到 SKILL.md 这套自定义指令机制，又看到社区里有人用它做 UI 生成技能，才决定搭个带 UI Skill 的 Codex 环境，认认真真实测一轮。

这篇文章就把我这几天踩的坑、测的数据、以及与 UI Skill 相关的所有细节完整写一遍。适合正在摸索 Codex 自定义指令、想让 Agent 稳定产出前端界面、以及看了热搜上那些“Codex 安装/接入/报错”帖子还是一头雾水的人。

1. 先别急着实测：UI Skill 到底改变了什么

1.1 AI 写界面最大的痛点，不是“不会写”，是“每次都不认识上次的自己”

没用 Skill 之前，我让 Codex 画页面遇到过最典型的情况：第一次让它写一个商品卡片，它会认认真真把布局、渐变、阴影全画上，效果还能看。第二次让它加一个筛选按钮，它能为了加这个按钮，把整张卡片的圆角、字体、间距全部改一遍。你说它不懂 UI 吗？它什么都懂，但它没有任何“这套项目已经定下的设计约束”的概念，等于每次开工都在重新发明轮子。

这就好比一个外包设计师，每来一版需求都当成全新项目，根本不翻之前的交付规范。UI Skill 本质上是把这些“规范”固化下来，在每一轮任务开始前强制 Agent 先读一遍，把设计令牌、组件层级、响应式要求、代码结构全变成硬约束。这样一来，同一个 Agent 在不同轮次、不同页面之间的产出，才有可能保持统一。

1.2 为什么我用 Codex 做试验田，而不是其他工具

市面能跑 Skill 的工具不止一个，但 Codex 有几个特性非常适合做这种实测。第一，它是纯命令行 Agent，可以把整个交互过程、中间产物、报错信息完整记录下来，方便复盘，不像某些云端 IDE 把过程都封装在黑盒里。第二，Codex 支持自定义model_provider，可以接入第三方模型，这意味着 UI Skill 的有效性不完全绑定在单一模型上，我可以用不同模型跑同一份 Skill，横向比较效果。第三，Codex 的 SKILL.md 机制简单直接，一个文件夹、一个 Markdown 文件，规则全部写在明文里，对理解“指令注入”这件事特别友好。

1.3 实测环境准备：Codex 安装与基础配置

我系统是 Windows，直接装的桌面版客户端，平时跑自动化任务还是用 CLI 更方便。CLI 的安装方式很简单，官方推荐走 npm：

npm install -g @openai/codex

装完先登录：

codex login

登录态很关键，很多人装完发现“无法加载组织设置”，八成是这一步没有真正完成，或者浏览器弹窗被拦截了。

我想顺便试试第三方模型，所以配置了 DeepSeek 的接入。这一步比较适合放在实测前讲，因为后面跑 UI Skill 时如果模型调用有问题，会直接干扰测试结果。Codex 支持通过config.toml自定义模型供应商：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com" env_key = "DEEPSEEK_API_KEY"

然后把 Key 写进系统环境变量即可。注意base_url到域名即可，不要画蛇添足加/v1之类的后缀，具体版本要看模型服务商的兼容说明，配错了会在调用时直接爆连接错误。

2. 核心细节解析：UI Skill 描述文件到底该怎么写

2.1 SKILL.md 的结构与触发方式

Codex 的 Skill 机制核心是一个叫 SKILL.md 的 Markdown 文件，放在指定目录下。目录结构一般是：

~/.codex/skills/ └── ui-design/ ├── SKILL.md └── examples/ └── card.html

使用方式有两种，一种是在对话里明确喊出技能名，比如“使用 ui-design 技能”，另一种是把它做成AGENTS.md级别的常驻规则，只要进入对应目录就自动加载。我实测下来，UI 工作流更适合显式触发，因为不是每个任务都需要走整套 UI 流程，强制加载反而会拖慢简单脚本任务的响应。

SKILL.md 本身不挑格式，Codex 只要求它是 Markdown，剩下全靠内容质量说话。一个合格的 UI Skill 描述文件，至少要讲清楚三件事：这个技能负责什么、执行任务时按什么流程走、有哪些硬性设计约束必须遵守。

2.2 一个可直接抄作业的 UI Skill 描述文件

下面这个版本是我实际调了几轮以后稳定下来的，核心思路就两个字：约束。给 Agent 越具体的边界，它的输出越不容易飘。

# UI Design Skill ## 职责 - 将自然语言描述转化为可运行的 HTML/CSS/JS 单文件原型 - 保持视觉一致、语义清晰、响应式可用 ## 执行流程 1. 拆解需求，输出组件树 2. 定义设计令牌（Design Tokens）：主色、次色、间距单位、圆角、字号 3. 按组件树顺序实现：布局、样式、交互 4. 自检：断点测试、对比度、可点击区域 ## 硬性设计约束 - 禁止使用内联 style，全部样式写入 <style> 块 - 颜色一律使用 CSS 变量，禁止魔法值 - 间距必须基于 4px 网格，常用倍数：4/8/12/16/24/32 - 字体家族使用系统字体栈，不引入外部字体库 - 响应式断点至少覆盖 375px / 768px / 1280px - 交互反馈必须有明确状态：hover、active、disabled

这里几个细节值得展开讲一下，它们直接决定 Skill 的成败。

先说“禁止内联 style”。没有这条约束时，Codex 很容易偷懒，在每个标签上直接塞样式，后面想改主题色能改到人崩溃。强制写进<style>块，至少保证了样式和结构分离，后续维护成本立刻降一个量级。

再说 CSS 变量和 4px 网格。这两个约束本质上是建了一套“设计原子”。实测下来，有这套原子约束的 Agent 产出，改主题色只需要改--primary一个变量；没有的话，它会把颜色散落在几十个地方，每次修改都是一场全量替换事故。

2.3 描述文件挂载后 Codex 的行为变化

挂载 UI Skill 之后，Codex 的任务处理方式会发生一个明显变化：它不再直接甩代码，而是先输出一段“计划”，把组件树、颜色变量、布局策略列出来，然后才动手实现。这不是我调教出来的，而是 SKILL.md 里的流程起了作用——它把“先规划再实现”写进了任务应走的步骤里。

这种变化在第一轮交互中尤其明显。没用 Skill 时，你说“做一个购物列表”，它直接生成一坨标签和样式；用了 Skill 后，它会先给你看组件树：

ProductList ├── FilterBar │ ├── CategorySelect │ └── SortButton ├── ProductCard (repeat) │ ├── ProductImage │ ├── ProductInfo │ │ ├── Title │ │ ├── Price │ │ └── Tag │ └── AddToCartButton

看着像多了一步，实际上省了后面无数次“布局不对、再改”的来回拉扯。我个人的体会是：界面生成类任务，最贵的时间点就在返工，而大部分返工都源于一开始没有统一结构和规范。UI Skill 用一次强制规划，就把这部分成本压了下去。

3. 实操过程：三组真实对比实验全记录

3.1 实测场景设计：难度递增的三个 UI 任务

为了测出 Skill 的真实价值，我特意挑了三个不同类型的 UI 任务，避免只在“画个好看的卡片”这种低难度场景里自嗨：

• 任务 A：做一个带筛选功能的商品卡片列表，包含图片、标题、价格、标签、加入购物车按钮。
• 任务 B：做一个仿主流应用的登录页，包含 Logo、输入框、密码可见切换、忘记密码链接、第三方登录按钮。
• 任务 C：做一个数据仪表盘，至少三个统计卡片、一个趋势折线图、一个状态切换交互，且在不同屏幕宽度下要能正常显示。

每个任务我都跑两轮：一轮不加载 UI Skill，直接描述需求；一轮加载 UI Skill，完全相同的描述。评估标准不看我主观“好不好看”，而是看四个客观指标：视觉整体性（页面不同部分风格是否统一）、代码可维护性（样式是否抽离、是否用变量）、响应式完成度（缩窄窗口是否崩）、返工次数（从第一版到最终版本经过了多少轮修改）。

3.2 对比结果汇总：数据说话

三组任务跑完，结果非常清晰：

数字背后的体感差异更直观。没有 Skill 时，任务 A 的商品卡片经常出现标题长度不一时布局就崩掉的情况；任务 C 的仪表盘在手机端直接横向溢出，图表宽度硬编码成了固定像素。而加载 Skill 后的版本，这些问题在第一版就基本规避掉了。

3.3 实测现场：一次完整的有 Skill 对话拆解

拿任务 B 登录页举例，加载 UI Skill 后，我输入的原始需求只有一句话：“做一个现代风格的登录页，左边品牌展示，右边登录表单，手机端上下堆叠。”Codex 的第一轮输出就不是代码，而是方案摘要：

风格定调：清爽 SaaS 风格，主色 #4F46E5，圆角 12px，间距遵循 4px 网格。左区品牌展示，包含标语与产品优势点；右区卡片式表单，表单项含浮动标签。移动端隐藏左区，仅保留表单居中。

这就是 SKILL.md 里“先拆解需求、再定义设计令牌”的流程起效了。对比同一需求下没有 Skill 的 Codex 第一轮回复，它直接给了一整套代码，样式倒是看着完整，但颜色用了至少五种不相关的色相，间距全靠模板代码在撑，改起来两眼一抹黑。

后续修改环节差异更大。我提了一个诉求：“把主色换成偏绿的色调。”有 Skill 的版本确实只改了一个--primary变量，全局联动；无 Skill 的版本改了六处，漏了两处硬编码的颜色，出来效果花里胡哨。这个实操细节几乎是 UI Skill 价值最有力的证明。

3.4 一个容易忽略的点：Skill 不是万能的

说了这么多好话，也得泼盆冷水。UI Skill 能约束流程和规范，但弥补不了模型本身的审美上限。同样一份 SKILL.md，用不同模型跑，视觉质量差距依然存在。Skill 保证的是“稳定”，不是“惊艳”——它能让一个 70 分的模型稳定输出 70 分，但不会帮你把 70 分变成 95 分。

另外，写 SKILL.md 本身是有成本的。第一版描述文件我反复调了四五次，才达到“基本不用怎么返工”的状态。如果你只是想快速生成一次性页面，不打算长期维护，那花在写 Skill 上的时间可能比直接生成代码还要多。权衡下来，UI Skill 更适合那些会重复打开、反复迭代的项目型界面，不适合一锤子买卖的临时原型。

4. 绕不开的坑：安装、连接与模型调用实战排错

4.1 热搜里那些 Codex 报错，真实情况是什么

最近关于 Codex 的热搜词里，十个有八个是报错和安装问题。我在实测过程中也踩了一部分，整理成了一张排查表，按出现频率排了序，方便直接对照。

这份表其实只是“急救手册”。我更想强调的是排查思路，因为报错信息千变万化，背答案不如会方法。

4.2 排错思路：先隔离变量，再谈解决

遇到 Codex 相关报错，我个人的调试顺序是从外到内，先环境后配置最后才是模型。第一看网络连通，比如上面那个 local proxy 报错，本质是 Codex 发往端点的请求没有正常到达，排查第一步应该是确认代理环境变量指向的服务是否存活，而不是去翻代码配置；第二看配置项，比如base_url、env_key是否匹配；第三才怀疑模型本身支不支持。很多人在第一步第二步就直接把问题归咎于“AI 不行”，方向错了，浪费的时间都是白搭。

还有一个小技巧，Codex CLI 的日志输出通常比界面上的提示详细得多。遇到不确定的问题，直接关掉界面上那一层精简提示，去终端里看原始输出，往往真正的报错原因就藏在前面几行。

4.3 避坑建议：日常折腾 Codex 的几条心得

最后分享几条我自己总结的实操习惯，应该能帮你少走弯路。

第一，Skill 目录里别只放一份 SKILL.md。强烈建议建一个examples/子目录，把一两次觉得效果好的输出放进去当样例。实测下来，Agent 在生成时会参考目录下的例子，效果好得出奇。

第二，模型选择直接影响 UI Skill 的上限。如果只是写代码逻辑，轻量模型完全够用，但跑 UI Skill 这种设计密集型任务，建议用最强模型兜底。省下来的返工时间，远远比那点 API 花费值钱。

第三，Skill 描述要定期迭代。不是写完一次就结束了。每次使用后复盘一下，如果发现 Agent 反复在同一个点上出错，说明 SKILL.md 里少了对应规则，赶紧补进去。比如我初次使用时发现它老是不做窄屏适配，就在约束里加了“至少覆盖 375px / 768px / 1280px”这一条，之后基本没再犯过。

回到最开始的问题：UI Skill 到底有没有用？我的答案是有用，而且是非常具体的那种“有用”——它把 AI 写界面的随机性压了下去，把质量下限拉高了一大截。但它不是一个能让你躺平的魔法开关，需要你花时间把规则写清楚、把样例放进去、把流程跑顺。我个人的体会是，凡是需要跨多轮、反复改的前端任务，UI Skill 值得作为标配存在；而如果你只是偶尔生成一个丢到临时目录里的原型，那要不要上这套机制，就看心情吧。