让 Codex 生成一个页面，布局、表格、表单都能像模像样，唯一容易露怯的是图标。

需求里一般不会指定图标，于是它只能自己拿主意。这个自己拿主意，恰恰是问题开始的地方。

图标混乱有三层，越往后越难收拾

第一层是视觉。同一个动作，有的地方用 emoji，有的地方用图标库，有的地方从网上下了一张 png。风格、粗细、颜色都不统一，页面拼在一起，一眼就能看出是拼凑的。

第二层是命名。同一个“删除”，代码里可能叫 delete、trash、remove，下次让 Codex 查“删除图标用在哪”，它得顺着三个名字找三遍。命名不统一，改起来就是满项目搜。

第三层是来源。图标路径是 Codex 猜出来的，写之前它不知道这个路径在项目里存不存在。结果就是图片 404、图标区域空白，或者加载一个本地根本不存在的文件，白白报错。

这三层不是平行的，来源乱会带来命名乱，命名乱会加剧视觉乱。越往后越难收拾，所以问题要往前堵。

Codex 为什么总在这一块翻车

图标是 Codex 写页面时少数几个“没有明确输入”的部分。页面结构、字段、接口它都能从上下文里找到依据，唯独图标，需求里通常一个字都没有。

没有依据就只能猜。猜一个常见图标名，运气好能找到；塞一个 emoji，永远显示；写一个自以为存在的路径，编译通过但页面空白。三种结果里，只有第一种算勉强可用。

这不是 Codex 能力不够，是它缺少“图标从哪来、用什么、怎么命名”的约束。没有约束的行为，质量只能靠运气。

图标不一致，为什么算代码质量

有人觉得图标是小事，能显示就行。但它是代码质量里很实在的一块。

视觉一致性影响观感。同一套 UI 里，图标风格不一致，用户不一定说得清哪里不对，但页面整体显得不专业。上一篇文章提到的 ui-ux-pro-max 里，就有一条明确规则：不用 emoji 当图标，用 SVG 图标，并且保持风格统一。图标属于 UI 质量的一部分，不是可有可无的装饰。

可维护性影响改动的成本。图标要换风格、换颜色，如果每个地方各写各的，改动就是满项目找图标。如果统一了来源和命名，一次替换就结束。

可靠性影响页面本身。图标路径猜错，控制台报 404，加载失败时留下的空白，比没有图标还难看。

把它纳入质量检查，比事后返工省钱

给 Codex 的验收清单里，值得固定加上图标这一项：有没有用 emoji 当图标、图标来源是不是统一的库、命名有没有和项目现状一致、路径是不是真实存在。

这些检查项不需要很深的技术含量，难的是有人把它写进验收标准。Codex 不知道图标算质量问题，是因为没人告诉它；一旦清单里有这一条，它写的时候就会收敛。

下一篇推荐一个专门解决这件事的 skill：better-icons。它负责让 Codex 不再猜图标——从一个统一的图标库里检索、拿到可用的 SVG，让来源和风格都有据可依。

本系列持续更新。推荐每个 skill 时，都回答同一组问题：它补哪类质量、和 Codex 怎么配合、边界在哪。