Back to Details

system-fit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

System Fit

系统适配

Prevent accidental design-system sprawl without forcing every problem into an existing component.
在避免设计系统无序扩张的同时，不强行将所有问题都套入现有组件中。

Always

必须遵循的原则

  • Context — inspect what is already known before asking the user to repeat it. Use 
    .ux/INTENT.md
    when product purpose or outcome can change the answer, and load only the additional project context the task needs.
  • User — ground the work in the people affected, their goal, task, context, and available evidence. Do not invent user needs, behaviors, or personas.
  • Evidence — keep known, inferred, assumed, unknown, and conflicted information distinct when the difference matters.
  • System — prefer established product language, components, patterns, and rules before inventing new ones.
  • Clear — lead with the useful point, use the minimum structure needed, and remove generic AI filler.
  • Trust — never invent evidence, requirements, rationale, implementation status, or compliance.
  • Outcome — for substantial multi-step work, keep intent active, use a small 
    .ux/STATE.md
    only when continuity needs it, prioritize the highest-impact unresolved gap before polishing, and verify the actual experience against intent before declaring completion.
Do not recite these rules to the user unless one of them materially affects the answer.
Do not introduce research questions, personas, or discovery work when the user and task are already clear or the missing information would not materially change the work.
  • 上下文 — 在要求用户重复信息前，先查看已知内容。当产品目标或结果会影响答案时，使用
    .ux/INTENT.md
    ，且仅加载任务所需的额外项目上下文。
  • 用户 — 基于受影响人群及其目标、任务、场景和现有证据开展工作。不得虚构用户需求、行为或角色。
  • 证据 — 当信息类型的差异至关重要时，需明确区分已知、推断、假设、未知和有冲突的信息。
  • 系统 — 在创建新组件或模式前，优先采用已确立的产品语言、组件、模式和规则。
  • 清晰性 — 先给出核心要点，使用最少必要的结构，剔除通用AI生成的冗余内容。
  • 可信度 — 不得虚构证据、需求、理由、实施状态或合规性相关内容。
  • 结果导向 — 对于复杂的多步骤工作，需保持目标明确；仅当需要维持工作连续性时，使用小型的
    .ux/STATE.md
    ；在优化细节前，优先处理影响最大的未解决缺口；在宣告完成前，需验证实际体验是否符合预期目标。
除非这些原则会对答案产生实质性影响，否则无需向用户复述这些规则。
当用户和任务已明确，或缺失的信息不会对工作产生实质性改变时，无需引入研究问题、用户角色或探索性工作。

Inspect the real system

检查真实系统

Use 
.ux/DESIGN-SYSTEM.md
when available and inspect authoritative sources such as Storybook, component packages, token definitions, design documentation, implementation examples, and contribution rules. Load other project context only when it can change the system-fit decision.
Do not assume Figma, Storybook, or code is the source of truth. Use the project's documented hierarchy or flag the ambiguity.
若
.ux/DESIGN-SYSTEM.md
可用，请使用该文件，并查阅权威来源，如Storybook、组件包、令牌定义、设计文档、实现示例和贡献规则。仅当其他项目上下文会影响系统适配决策时，才加载相关内容。
不要默认Figma、Storybook或代码为唯一可信来源。需遵循项目文档中规定的层级，或标注存在歧义的情况。

Classify the fit

适配分类

Prefer this order:
  1. Reuse — an existing component or pattern already solves the need.
  2. Compose — existing primitives solve it when combined in an established way.
  3. Extend — an existing component needs a legitimate new state, behavior, variant, or documentation update.
  4. Create — the need is meaningfully distinct and reusable enough to justify a new system asset.
  5. Feature-local — the solution is too specific to become a shared system component.
Do not create a new component merely because the exact visual arrangement is new.
优先遵循以下顺序：
  1. 复用 — 现有组件或模式已能满足需求。
  2. 组合 — 将现有基础组件按既定方式组合即可满足需求。
  3. 扩展 — 现有组件需要新增合理的状态、行为、变体或更新文档。
  4. 创建 — 需求具有显著独特性，且具备足够复用价值，值得新增系统资产。
  5. 功能专属 — 解决方案过于特定，无法成为共享的系统组件。
不得仅因视觉布局新颖就创建新组件。

Check the gap

检查缺口

If the existing system almost fits, identify the precise missing behavior: state, accessibility behavior, data scale, responsive behavior, content rule, interaction, or API.
Consider whether the gap is documentation rather than implementation.
若现有系统几乎能满足需求，需明确指出具体缺失的行为：状态、无障碍行为、数据规模、响应式行为、内容规则、交互方式或API。
需考虑缺口是否仅存在于文档层面，而非实现层面。

Output

输出要求

Lead with the classification and recommendation. Name the existing assets involved, the gap, and any design-system contribution that should accompany the feature.
If the system source cannot be verified, make the recommendation conditional rather than pretending certainty.
先给出分类结果和建议。指明涉及的现有资产、存在的缺口，以及功能应向设计系统做出的贡献。
若无法验证系统来源，需给出有条件的建议，而非假装确定。

Contrast example

对比示例

Bad:
Create a new 
SearchableStationPicker
component because the design system does not have that exact component today.
Good:
Compose. The existing Autocomplete handles station search and the existing selection/chip pattern handles chosen values. The gap is not a new component; it is documented behavior for no-results, async loading, and keyboard selection. Add those states to the existing pattern before proposing a new system component.
Why: the good response identifies the actual missing behavior and prefers composition over component proliferation.
错误示例：
创建新的
SearchableStationPicker
组件，因为当前设计系统中没有完全匹配的组件。
正确示例：
组合。现有Autocomplete组件可处理站点搜索，现有选择/芯片模式可处理选定值。缺口并非新组件，而是无结果、异步加载和键盘选择的文档化行为。在提议新系统组件前，先为现有模式添加这些状态。
原因：正确的回应明确了实际缺失的行为，优先选择组合而非新增组件以避免组件泛滥。

Examples

适用场景示例

  • "Does this need a new component?"
  • "Can we build this from what the design system already has?"
  • "Should this state go back into Storybook?"
  • "这个需求需要新组件吗？"
  • "我们能否用设计系统中已有的组件来构建这个功能？"
  • "这个状态应该添加到Storybook中吗？"