system-fit

系统适配

避免设计系统意外膨胀，同时不强迫所有问题都套用现有组件。

始终遵循

• 上下文 — 询问用户重复说明之前，先检查已有信息。如果产品目的或预期结果可能影响答案，请使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和现有证据为依据。不要臆造用户需求、行为或角色画像。
• 证据 — 在区分已知、推断、假设、未知和相互矛盾的信息会产生影响时，明确区分它们。
• 系统 — 优先使用现有的产品语言、组件、模式和规则，再考虑创造新的内容。
• 清晰 — 开门见山，使用必要的最少结构，并删去泛泛的 AI 套话。
• 可信 — 绝不捏造证据、需求、理由、实施状态或合规情况。
• 结果 — 对于实质性的多步骤工作，持续关注意图；仅在需要保持上下文连续性时使用简短的 .ux/STATE.md；先处理影响最大的未解决问题，再做润色；在宣布完成前，根据意图验证实际体验。

除非这些规则会实质性影响答案，否则不要向用户复述它们。

如果用户和任务已经明确，或缺失的信息不会实质性改变工作，就不要引入研究问题、角色画像或探索工作。

检查实际系统

如果有 .ux/DESIGN-SYSTEM.md，请使用它，并检查权威来源，例如 Storybook、组件包、令牌定义、设计文档、实现示例和贡献规则。只有在其他项目上下文可能影响系统适配判断时，才加载这些内容。

不要假定 Figma、Storybook 或代码就是事实来源。遵循项目记录的优先级，或明确指出其中的歧义。

判断适配方式

优先顺序如下：

1. 复用 — 现有组件或模式已经能满足需求。
2. 组合 — 通过既定方式组合现有基础元素即可满足需求。
3. 扩展 — 现有组件需要新增合理的状态、行为、变体或文档更新。
4. 创建 — 需求有实质性差异，且足够通用，值得新增系统资源。
5. 功能局部实现 — 解决方案过于特定，不适合作为共享的系统组件。

不要仅仅因为视觉布局是新的，就创建新组件。

检查缺口

如果现有系统几乎满足需求，请明确指出缺少的具体行为：状态、无障碍行为、数据规模、响应式行为、内容规则、交互或 API。

考虑缺口是否在文档，而非实现。

输出

先给出分类和建议。指出涉及的现有资源、缺口，以及应随功能一同提交的任何设计系统贡献。

如果无法核实系统来源，请给出附带条件的建议，而不要假装确定。

对比示例

反例：

创建一个新的 SearchableStationPicker 组件，因为设计系统目前没有完全一致的组件。

正例：

组合。 现有 Autocomplete 可处理车站搜索，现有选择项／标签模式可处理已选值。缺口不在于需要新组件，而在于尚未记录无结果、异步加载和键盘选择时的行为。先为现有模式补充这些状态，再考虑提出新的系统组件。

原因：好的回答指出了实际缺失的行为，并优先选择组合，而不是不断增加组件。

示例

• “这需要一个新组件吗？”
• “我们能用设计系统现有的内容实现吗？”
• “这个状态应该回补到 Storybook 吗？”