排版Skill：用一套可执行的排版审查流程，把「好看」变成「好读」
- 它是什么：排版Skill（英文名 typography，技能ID 11767）是一个面向 UI 排版决策的 AI 技能，聚焦字体选择、CSS 排版审查、可读性提升、链接可发现性修复与对比度风险控制。
- 它的依据：核心规则来自 NN/g（尼尔森诺曼集团）的排版与链接可视化指南，不是凭感觉给建议。
- 它能干活：自带启发式审计脚本，可扫描 CSS / SCSS / 含
<style>的 HTML，报告字号过小、行高过紧、对比度不足、字体家族过多、链接弱可发现性、缺少:visited样式等常见风险。 - 它的产出：落到标记与规则级别的具体修改建议，并解释对可读性的影响、标注有意的取舍（品牌约束、设计系统兼容性、边缘例外）。
- 适合谁用：前端工程师、设计系统维护者、UI/UX 设计师、以及需要为后台数据密集型界面做排版决策的团队。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能身份信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 排版Skill |
| 技能英文名 | typography |
| 技能ID | 11767 |
| 核心定位 | UI 排版审查与可读性优化 |
它解决什么问题
在实际项目里，排版问题往往不是「不好看」，而是「不好读」：正文字号偏小、行高过挤、浅灰文字压在白底上、链接去掉下划线后完全看不出可点击、字体家族越加越多导致视觉噪音。这些问题单个看起来都是小事，叠加起来就是可用性与可访问性风险。排版Skill 的作用，就是把这类模糊的「感觉不太对」变成一条条可核查、可修复的规则。
「一键安装」AI 技能提升开发效率的思路
AI 技能的价值在于「装一次，随时调用」——把一套稳定的专业判断固化成技能，之后每次遇到排版问题不必重新组织上下文、重新解释标准。安装思路可以概括为三步：
- 确认安装前提：你需要在支持 AI 技能的客户端或平台中使用（具体支持范围以官方说明为准）；如果技能涉及本地脚本审计，还需要本地具备 Ruby 运行环境，以便执行捆绑的审计脚本。
- 执行安装 / 启用：在技能市场或技能管理入口中，通过技能名称「排版Skill」或技能ID
11767定位该技能，按平台提示完成添加与启用。具体命令与入口地址以官方说明为准。 - 验证是否生效：启用后发起一次最小测试，例如直接问「帮我审查这段 CSS 的排版可读性风险」，并附上一小段样式代码。若回复中出现了基于 NN/g 指南的规则判断（字号、行高、对比度、链接可发现性等维度），说明技能已正常工作。
该技能的主要功能和特点
- 排版问题诊断：针对「UI 文本难读、排版不一致、链接看不出可点击、对比度决策损害可用性」等典型症状给出判断与修复方向。
- 基于 NN/g 指南决策：内置对 NN/g 相关指南的引用，涵盖易扫读字体、字体配对、衬线体与无衬线体在高分屏上的差异、链接可视化规范、低对比度问题等主题，避免拍脑袋选字体。
- 类型角色体系：推动建立清晰的角色划分——显示/标题、正文、元数据/支持文本，并主张字体系统保持简单，通常控制在 1–2 个字体家族。
- 可读性三要素核查：优先检查字号是否足够、行高是否足够、对比度是否足够，即「先能读，再谈美」。
- 链接可发现性审查：检查链接是否有明确的点击性提示、是否有相关的已访问状态样式，专门针对「去掉下划线又没有替代方案」这类高频坑。
- IL1 测试支持：针对数据密集、字母数字混排的界面，可从现有字体家族生成 IL1 样本页面，用于验证字体选择是否合适。
- 自带审计脚本：通过脚本批量扫描样式文件，把风险点列成清单，且支持混合文件类型扫描。
- 护栏式结论：脚本结果被视为「护栏」而非最终判决，技能明确要求在真实 UI 上下文中做视觉复核。
如何使用该技能？
第 1 步：盘点现状
先把当前排版相关的标记与规则整理出来——字体家族声明、字号体系、行高、颜色与背景色、链接样式。可以只贴关键片段，不必贴全站样式。
第 2 步：明确类型角色
让技能帮你把样式映射到角色：显示/标题、正文、元数据/支持文本。如果发现同一个角色有多种字号或多个家族并存，这就是需要收敛的信号。
第 3 步：核查可读性基础
输入示例：
body { font-size: 12px; line-height: 1.15; color: #9a9a9a; background: #ffffff; }
.meta { font-size: 11px; color: #b0b0b0; }
a { text-decoration: none; color: inherit; }
期望输出：技能会指出字号偏小、行高过紧、浅灰文本在白色背景上对比度不足，以及去掉下划线且颜色继承导致的链接弱可发现性，并给出规则级修改建议。
第 4 步：核查链接呈现
重点确认两件事：链接是否有清晰的点击性提示（下划线、颜色、字重等替代方案）；是否为已访问链接定义了 :visited 颜色样式。
第 5 步：对数据密集型界面做 IL1 检查
当界面是表格、报表、监控面板这类字母数字密集场景时，运行脚本生成 IL1 样本页面，用实际字形做判断，而不是靠想象。
第 6 步：运行审计脚本
ruby scripts/typography_audit.rb "app/assets/stylesheets/**/*.css"
需要生成 IL1 样本页面时：
ruby scripts/typography_audit.rb "app/assets/stylesheets/**/*.css" --il1-html /tmp/il1.html
脚本会报告常见风险：小字号、紧凑行高、低文本/背景对比、字体家族数量过多、弱链接可发现性（例如移除下划线且无替代）、缺少 :visited 颜色样式。
第 7 步：在真实界面复核并落地
把脚本结果当作护栏，回到真实页面截图或预览中做视觉复核，再输出最终的修改方案。
输出预期：一次合格的调用应产出三部分内容——具体的排版更改（标记/规则级别）、对可读性与理解的影响说明、以及任何有意的权衡（品牌约束、设计系统兼容性、边缘情况例外）。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 排版Skill（typography） | 排版决策 + 审查的 AI 技能 | 基于 NN/g 指南的排版诊断、类型角色梳理、链接可发现性检查、IL1 样本生成、捆绑审计脚本 | 需在支持技能的客户端启用；跑脚本需 Ruby 环境 | 字体选型、CSS 排版审查、可读性与可访问性风险排查 | 优势：给出规则级建议并解释影响与取舍，覆盖「决策」而非只报错；不足：脚本为启发式护栏，仍需人工视觉复核 |
| 人工对照 NN/g 指南自查 | 方法论 | 阅读指南后逐条比对 | 无工具门槛，但需要专业知识与时间 | 小团队、一次性审查 | 优势：理解最深、无依赖；不足：耗时、易漏项、标准难在团队内统一 |
| 通用大模型直接提问 | 通用对话 | 让模型凭经验点评样式 | 极低 | 临时的、非严格的排版问题 | 优势：随手可用；不足：结论不稳定、缺少统一依据，难以形成可复用的审查标准 |
| 可访问性扫描工具（如浏览器内置的审计面板、axe 类工具） | 自动化规则扫描 | 检测对比度等可访问性问题 | 低，装扩展或开面板即可 | 上线前的合规检查 | 优势：自动化程度高、可集成到流程；不足：偏「是否违规」，对字体角色体系、链接可发现性、IL1 字体选择这类设计决策覆盖有限 |
| CSS 静态检查规则（如 stylelint 类工具） | 代码规范约束 | 按自定义规则约束样式写法 | 需配置规则集 | 工程化约束、CI 卡口 | 优势：可强制执行、适合规模化；不足：规则需自行设计，无法解释「为什么」以及可读性影响 |
可以看出，排版Skill 的差异点在于：它既提供可执行的脚本检查，又覆盖字体角色体系、字体选型与权衡说明这些「设计决策层」的内容，介于纯自动化扫描与纯人工判断之间。
该技能的典型应用场景与实际体验情况
场景一：前端工程师接手遗留样式
痛点：项目迭代多年，字号从 10px 到 20px 杂乱并存，浅灰文字遍布，没人说得清哪套是对的。使用方式：把主要样式文件交给技能审查，或直接跑审计脚本拿到风险清单。实际体验：上手难度低，脚本一次扫描就能把「字体家族过多」「行高过紧」这类系统性问题暴露出来；注意事项是要挑真正影响 C 端页面的文件，不要被第三方库样式淹没。
场景二：设计系统维护者收敛字体体系
痛点：每来一个新页面就多加一种字号或一种字体家族，设计系统逐渐失控。使用方式：让技能按「显示/标题、正文、元数据」三类角色重新梳理，并给出收敛方案。实际体验：效果体现在「有据可依」——建议能对应到 NN/g 的指南条目，推动跨团队达成一致更容易；注意事项是遇到品牌规范强约束时要明确说明例外，技能本身也会提示权衡点。
场景三：后台报表与数据面板的字体选择
痛点：表格里全是数字和编号，字体一换可读性差别很大，但很难说清哪种更好。使用方式：用 --il1-html 从现有字体家族生成 IL1 样本页面，直接对比。实际体验：这是该技能比较有特色的一环，把「凭感觉选字体」变成「看样本选字体」；注意事项是样本要在真实字号与行高下观察，否则结论会失真。
场景四：内容页链接可发现性修复
痛点：为了视觉干净去掉了下划线，链接和正文混在一起，用户点不到也找不到。使用方式：让技能检查链接样式与 :visited 状态，输出替代方案。实际体验：修复成本低、收益直接；注意事项是修复后要同步更新设计规范文档，避免下一版又被改回去。
该技能能为用户带来的价值
把排版从「审美争论」变成「可验证的规则」。以往关于字号、行高、颜色的讨论容易变成主观偏好之争；引入 NN/g 依据之后，讨论可以落在「是否足够可读」「链接是否足够可发现」这类可验证的判断上，减少来回拉扯。
审查效率的可见提升。一条审计脚本命令即可扫描整个样式目录，把散落在几十个文件里的字号、行高、对比度、家族数量、链接样式问题一次性列出，替代逐文件人工比对；同时 --il1-html 一键生成样本页，省去手工搭建字体对比页面的时间。
降低专业门槛。不是每个团队都配有专职的排版或可访问性专家。技能把「先优化可读性、保持字体系统简单、保持链接可发现、避免低对比度正文」等核心规则固化成可调用的流程，让普通开发者也能做出有依据的排版决策。
减少长期维护成本。字体家族数量收敛、类型角色明确之后，新增页面不需要再发明新字号；同时因可读性与链接可发现性引发的用户困惑、误点与反馈会相应减少。
风险前置。对比度不足、字号过小属于典型的可访问性隐患，在开发阶段就被脚本标出来，比上线后被动修要便宜得多。
常见问题 FAQ
Q1：排版Skill 怎么安装？
在支持 AI 技能的客户端或技能管理入口中，通过技能名称「排版Skill」或技能ID 11767 查找并启用。若希望使用捆绑的审计脚本，本地还需具备 Ruby 环境。具体安装命令与入口以官方说明为准。
Q2：这个技能收费吗？ 技能详情中没有提供价格信息，是否收费取决于你使用的技能平台与分发方式，请以官方说明为准。
Q3：它会不会直接改我的代码？ 从技能的输出预期看，它的产物是「具体的排版更改建议（标记/规则级别）」，并附带可读性影响说明与取舍提示；实际是否落盘修改由你或你所用的工具决定。建议把它当作审查与决策助手，改动仍走正常代码评审流程。
Q4：审计脚本报出的问题必须全部修吗？ 不必。技能明确把脚本结果定位为「护栏」，并强调始终要在真实 UI 上下文中做视觉审查。品牌约束、设计系统兼容性、边缘情况例外都可能构成合理的有意取舍，关键是取舍要被说明清楚。
Q5：它和可访问性扫描工具、CSS 检查工具怎么选？ 三者关注点不同：可访问性扫描工具偏合规检测，CSS 静态检查偏代码规范约束，而排版Skill 覆盖的是字体选型、类型角色体系、链接可发现性、IL1 字体验证这些「设计决策 + 审查」的中间地带。实践中可以叠加使用：扫描工具做底线卡口，排版Skill 做方案评审。