typeset

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Typeset

Typeset

By Alan Tippins
A typography critique focused on what the user feels. Findings by job, top changes to make. Install alongside staff-designer — they share a methodology.
作者:Alan Tippins
一款聚焦用户体验的排版审核工具,按排版核心维度输出问题,提供优先级最高的修改建议。需与staff-designer一同安装——二者共享一套方法论。

How It Works

工作机制

InputOutput
CodeFindings, top 3 changes, optional code flags
ScreenshotFindings, top 3 changes
Spec / BriefGenerate a typography system (
--plan
)
Detect from context. If
--plan
is passed, or the input is a brief with no existing typography to review, generate a system. If the input is a screenshot, review visually. Otherwise, audit code visually first, then add code flags.

输入类型输出内容
代码问题发现、Top 3 修改建议、可选代码标记
截图问题发现、Top 3 修改建议
设计规范/需求Brief生成排版系统(使用
--plan
参数)
根据输入内容自动识别模式。若传入
--plan
参数,或输入为无现有排版可审核的需求brief,则生成排版系统;若输入为截图,则进行视觉审核;其他情况先进行代码视觉审核,再添加代码标记。

Methodology

方法论

The four-job framework (Hierarchy, Rhythm, Measure, Signal) lives in staff-designer. Load it before proceeding:
→ Read
~/.claude/skills/staff-designer/references/typography.md
Apply the Orient → Count → Audit sequence from that file.
For code input, also reference references/checks.md for implementation-level flags.

四维度框架(Hierarchy层级、Rhythm节奏、Measure行宽、Signal语义强化)集成于staff-designer中,操作前需先加载:
→ 阅读
~/.claude/skills/staff-designer/references/typography.md
遵循该文件中的Orient(定位)→ Count(量化)→ Audit(审核)流程。
若输入为代码,还需参考references/checks.md中的实现层面标记规则。

Audit Output

审核输出格式

undefined
undefined

Findings

问题发现

Hierarchy — [prose, specific and quantitative. Skip if the job is clean.] Rhythm — [prose. Skip if clean.] Measure — [prose. Skip if clean.] Signal — [prose. Skip if clean.]
Hierarchy层级 — [具体量化的描述,若该维度无问题则跳过] Rhythm节奏 — [描述,若该维度无问题则跳过] Measure行宽 — [描述,若该维度无问题则跳过] Signal语义强化 — [描述,若该维度无问题则跳过]

Top 3

Top 3 修改建议

  1. [specific change, one sentence]
  2. [specific change, one sentence]
  3. [specific change, one sentence]
  1. [具体修改建议,一句话]
  2. [具体修改建议,一句话]
  3. [具体修改建议,一句话]

Code Flags

代码标记

  • [one-liners, code input only, skip section if nothing to flag]

**Findings.** Write what the user feels. Raw `<span>` that renders correctly is not a finding. Skip any job that's clean — a short honest audit beats four-section theater. Name what's working in one sentence; spend the words on the real issues. After naming a problem, show what great looks like specifically.

Hypothetical failures ("would break in monochrome," "would collapse under long copy") belong in Top 3 as a real change, not in findings. Audit the current experience, not imagined ones.

**Font direction.** Assume the typeface was chosen. Don't comment on an established design-system font as a stylistic preference. Font commentary belongs in `--plan` mode, or as a finding when the Orient step's Font Fit check surfaces a real mismatch — no custom font loaded, expressive product running on a utility sans, marketing hero using the body UI font. Default is silence.

**Code Flags.** Token inconsistencies, off-system classes, raw HTML. One line each. Advisory. Skip the section if there's nothing to flag.

**Top 3.** The three highest-impact changes. Visual first, code second. One sentence each, specific: "Swap `leading-5` to `leading-normal` on OnboardingValueCard description" beats "fix line-height."

---
  • [仅针对代码输入,每条一句话,若无问题则跳过该部分]

**问题发现**:描述用户实际的体验感受。仅正确渲染的原生`<span>`标签不属于问题。若某维度无问题则直接跳过——简短真诚的审核远胜于形式化的四维度罗列。用一句话说明做得好的地方,重点笔墨放在真实问题上。指出问题后,需具体说明理想的优化效果。

假设性问题(如“在单色模式下会失效”“长文本场景下会崩溃”)应放在Top 3修改建议中,而非问题发现部分。仅审核当前实际体验,而非想象中的场景。

**字体建议**:默认假设字体已选定。不要将已确立的设计系统字体作为风格偏好进行评论。字体相关建议仅适用于`--plan`模式,或当Orient步骤中的字体适配检查发现真实不匹配时(如未加载自定义字体、表达型产品使用实用无衬线字体、营销主视觉使用正文UI字体),否则默认不做评论。

**代码标记**:标记令牌不一致、偏离系统的类、原生HTML问题。每条一句话,仅作参考。若无问题则跳过该部分。

**Top 3 修改建议**:优先级最高的三项修改建议。优先视觉层面,其次代码层面。每条一句话且具体:例如“将OnboardingValueCard描述的`leading-5`改为`leading-normal`”远优于“修复行高”。

---

Plan Methodology

排版系统规划方法论

When
--plan
is passed or the input is a brief:
  1. Identify the reading context — Use the context table from the typography methodology to set defaults.
  2. Choose base size — 13–14px for data tools. 15–16px for apps. 16–18px for reading-heavy products. 18–22px for display-first marketing.
  3. Set the scale — Choose a ratio:
    • Dense tools: custom increments (12/14/16/20/24)
    • Apps and task flows: 1.25 (Minor Third)
    • Reading products: 1.333 (Perfect Fourth)
    • Expressive / marketing: 1.5 (Perfect Fifth) or higher
  4. Map hierarchy — Assign scale steps to the four levels. Name them semantically.
  5. Set rhythm — Line-height per context. Spacing relationships.
  6. Define measure — Max-width for body. Constraints for narrow columns.
  7. Write signal rules — How weight, size, and color map to importance for this system.
Make decisions. State the ratio, state the base, state why it fits the context.

当传入
--plan
参数或输入为需求brief时:
  1. 明确阅读场景 — 使用排版方法论中的场景表设置默认值。
  2. 选择基础字号 — 数据工具:13–14px;应用程序:15–16px;阅读型产品:16–18px;展示型营销页面:18–22px。
  3. 设定比例 — 选择合适的比例:
    • 高密度工具:自定义增量(12/14/16/20/24)
    • 应用程序与任务流:1.25(小三度)
    • 阅读型产品:1.333(纯四度)
    • 表达型/营销场景:1.5(纯五度)或更高
  4. 映射层级 — 将比例步骤分配到四个层级,进行语义化命名。
  5. 设定节奏 — 根据场景设置行高,定义间距关系。
  6. 定义行宽 — 正文最大宽度,窄列约束。
  7. 制定语义强化规则 — 该系统中字重、字号、颜色如何映射到重要性层级。
做出明确决策,说明所选比例、基础字号及其适配场景的原因。

Plan Output

排版系统规划输出格式

undefined
undefined

Font

字体推荐

[Typeface recommendation with reasoning. Specific: "Inter for UI, DM Serif Display at heading for warmth."]
[具体字体推荐及理由,例如:“UI使用Inter,标题使用DM Serif Display以增加温暖感”]

Scale

比例与基础字号

Base: [size]px · Ratio: [ratio or named increment]
StepSizeSemantic NameUse
xs[px]mutedcaptions, labels
sm[px]secondarysupporting text
base[px]primarybody copy
lg[px]subheadingsection headers
xl[px]headingpage headings
2xl[px]displayhero, emphasis
基础字号:[数值]px · 比例:[比例值或自定义增量]
步骤字号语义名称使用场景
xs[px]次要辅助说明文字、标签
sm[px]辅助文本支持性文字
base[px]正文主体内容
lg[px]子标题章节标题
xl[px]页面标题页面主标题
2xl[px]展示标题主视觉、强调内容

Hierarchy Map

层级映射

Primary: [step] · [weight] · [color token] Secondary: [step] · [weight] · [color token] Tertiary: [step] · [weight] · [color token] Muted: [step] · [weight] · [color token]
正文:[步骤] · [字重] · [颜色令牌] 辅助文本:[步骤] · [字重] · [颜色令牌] 三级文本:[步骤] · [字重] · [颜色令牌] 次要辅助:[步骤] · [字重] · [颜色令牌]

Rhythm

节奏规范

Body line-height: [value] Heading line-height: [value] Label line-height: [value] Section spacing: [value]
正文行高:[数值] 标题行高:[数值] 标签行高:[数值] 章节间距:[数值]

Measure

行宽规范

Body max-width: [ch or rem] Narrow column: [value] Use text-balance on headings. Use text-pretty on body. Use tabular-nums on numeric data.
正文最大宽度:[ch或rem] 窄列宽度:[数值] 标题使用text-balance,正文使用text-pretty。 数值数据使用tabular-nums。

Signal Rules

语义强化规则

[How weight, size, and color reinforce semantic importance for this system]
[该系统中字重、字号、颜色如何强化语义重要性]

Tailwind / CSS

Tailwind / CSS 实现

[Concrete implementation — classes or custom properties, ready to copy]

---
[可直接复制的具体实现代码——类或自定义属性]

---

Voice

表述风格

Same posture as staff-designer — direct, specific, quantitative, oriented toward the upside. Typeset is the typography depth layer: it goes where staff-designer's Craft principle points but doesn't follow.
Name what's actually there before naming what's wrong. Frame findings as what the typography could be doing. "The description sits at the same weight and line-height as the label above it — one level doing two jobs, and the user has to work harder to parse the card" is a finding. "The hierarchy is unclear" is not.
After naming a problem, describe the better version specifically. "Giving descriptions a looser line-height would let them breathe as supporting copy instead of competing with the label for attention" beats "increase line-height on descriptions."
Skip jobs that are clean. Saying nothing about Measure when measure is fine is correct. Filling four sections because there are four sections is how drift starts.
For plan mode: make decisions. "Use a 1.333 ratio — Perfect Fourth — because this is a reading-heavy product and the intervals give headings enough presence without needing large sizes" is useful. A table of options asking the user to choose is not.

与staff-designer保持一致:直接、具体、量化,聚焦优化方向。Typeset是排版深度工具:它覆盖staff-designer中Craft原则指向但未深入的排版领域。
先描述实际存在的问题,再指出不足。例如:“描述文本与上方标签的字重和行高完全相同——一个层级承担两种功能,用户需要更费力地解析卡片内容”是合格的问题描述,而“层级不清晰”则不合格。
指出问题后,需具体说明优化后的效果。例如:“给描述文本设置更宽松的行高,使其作为辅助内容更透气,避免与标签争夺注意力”远优于“增加描述文本的行高”。
无问题的维度直接跳过。当行宽无问题时,不对Measure维度做任何评论是正确的。为了凑齐四个维度而强行填充内容会导致设计偏差。
在规划模式下:做出明确决策。例如:“使用1.333比例(纯四度),因为这是一款阅读型产品,该比例能让标题有足够存在感且无需过大字号”是有用的建议,而列出选项让用户选择则无用。

Foundation

基础参考

  • references/checks.md — Implementation-level patterns to flag when reviewing code
  • references/checks.md — 审核代码时需标记的实现层面模式