improve-ui

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Improve UI

优化UI

Audit one coherent product surface against the system that actually governs it. Preserve the product's identity, reuse existing owners, and prefer no finding to an unsupported one. Write plans only for changes the user selects; another agent executes them.

针对管控产品界面的设计系统，审核一个连贯的产品界面。保留产品特性，复用现有归属组件，若无充分依据则不提出任何问题。仅针对用户选定的变更编写计划，由其他Agent执行。

Boundaries

边界约束

Never modify product source. Create or edit files only under
```
design-plans/
```
.
Do not install dependencies, run formatters, commit, push, or otherwise mutate the working tree.
Do not update design documentation. Record accepted documentation changes in the plan for its executor.
Use rendered evidence only when the user provides it or explicitly requests visual inspection.
Make every plan self-contained; its executor has no context from the audit or conversation.

绝不修改产品源码。仅可在
```
design-plans/
```
目录下创建或编辑文件。
不得安装依赖、运行格式化工具、提交、推送或以其他方式修改工作树。
不得更新设计文档。将已确认的文档变更记录在计划中，由执行该计划的人员处理。
仅当用户提供渲染后的依据或明确要求视觉检查时，才可使用此类依据。
每个计划必须独立完整；执行计划的Agent不了解审核过程或对话上下文。

1. Select the surface

1. 选择审核界面

Honor the user's scope. If the request is broad, select one deployable application and one coherent surface family representing a primary product task. State the selection; do not synthesize the whole repository into one product.

Start from the surface's routes and layouts. Trace the rendered path through compositions, shared components, variants, resolved tokens, and styles. Do not begin with a repository-wide search for inconsistencies.

A connection exists only when it is proven through rendering, imports, props, resolved configuration, CSS inheritance, or a generated artifact loaded by the surface. Shared names, similar tokens, repository proximity, and conceptual relationships do not establish a connection. Exclude other applications, previews, configurators, generated registries, legacy systems, and enterprise variants unless they participate in the traced path.

遵循用户指定的范围。若请求范围较广，则选择一个可部署的应用和一个代表核心产品任务的连贯界面系列。明确说明所选范围；不得将整个仓库合并为一个产品进行分析。

从界面的路由和布局入手，追踪渲染路径，涵盖组合组件、共享组件、variants、解析后的tokens和样式。切勿从仓库全局搜索不一致性开始。

仅当通过渲染、导入、props、解析后的配置、CSS继承或界面加载的生成制品证明存在关联时，才认定两者有联系。名称相似、tokens类似、仓库位置接近及概念关联均不构成关联依据。除非其他应用、预览工具、配置器、生成的注册中心、遗留系统和企业变体属于追踪路径的一部分，否则将其排除在外。

2. Reconstruct the local system

2. 重构本地设计系统

Check for

DESIGN.md

, repository guidance, and surface-local design documentation. Use a source only after proving it is current and governs the selected surface; drafts, proposals, migrations, and task lists describe future intent unless explicitly accepted and current. Absence of design documentation is not a finding.

Inspect only the tokens, variables, themes, primitives, variants, and compositions relevant to the traced path. Resolve aliases and variants to their definitions. Classify an implementation as local or legacy only when the repository says so.

Record:

markdown

undefined

检查

DESIGN.md

、仓库指南和界面本地的设计文档。仅在证明来源为最新且管控所选界面后才可使用；草稿、提案、迁移计划和任务清单仅描述未来意图，除非被明确确认并处于生效状态。无设计文档不视为问题。

仅检查与追踪路径相关的tokens、变量、主题、primitives、variants和组合组件。解析别名和variants至其定义。仅当仓库明确说明时，才将实现归类为本地或遗留。

记录：

markdown

undefined

Design language

设计语言

Audited surface:
Design sources:
Documented decisions:
Governing owners and consumers:
Explicit exceptions:


Write `None documented` under `Explicit exceptions` unless a cited source explicitly identifies the exception.

Audited surface:
Design sources:
Documented decisions:
Governing owners and consumers:
Explicit exceptions:


除非引用来源明确指出例外情况，否则在`Explicit exceptions`下填写`None documented`。

3. Prove findings

3. 验证问题发现

Before applying the proof gate, inspect every traced surface's user-facing labels, active-state presentation, responsive branches, and sibling variants for internal contradictions. Treat the results only as candidates.

A finding is in scope only when its correction primarily changes visual presentation, interface copy, layout, component styling, or conformance to a documented design rule. If the correction primarily changes whether product behavior works, reject it.

Search results, repetition, and implementation differences produce candidates, not findings. Keep a candidate only when all three proofs exist:

Contract — Cite a binding design decision for this property and scope, or a direct contradiction in user-facing presentation or content within the same task. “Prefer,” “generally,” names, omissions, repetition, and absence of an exception do not establish a contract.
Runtime — Prove that the cited owner, value, or behavior reaches the affected surface through the traced runtime path. Do not compare separate ownership layers or lifecycle states.
Correction — State one change required by the evidence. If it depends on an existing token, variant, primitive, or exemplar, name it exactly. If the evidence cannot determine the correct choice, the intended condition is ambiguous, the proposal contains alternatives, or the correction requires inventing product intent, reject the candidate.

Source can prove token, typography, color, spacing, layout, copy, component-variant, responsive-presentation, and explicit design-contract violations. It cannot turn functional behavior, state management, or interaction correctness into design findings. Hierarchy, prominence, density, clarity, discoverability, usability, and perceived coherence require rendered or user evidence.

Discard accessibility and HTML/ARIA semantic findings unless the user explicitly requests them. Discard broken routes, redirects, data wiring, action failures, metadata, package API, performance, architecture, and code-quality findings unless the user requested them or a product-specific design contract governs them.

Assign confidence only after all proofs pass. Reuse an existing owner when the evidence supports it; do not create a shared primitive from repetition alone.

在应用验证规则前，检查每个追踪界面的用户可见标签、激活状态展示、响应式分支和同级variants，查找内部矛盾。仅将结果视为候选问题。

仅当修正主要改变视觉呈现、界面文案、布局、组件样式或对已记录设计规则的合规性时，问题发现才属于范围。若修正主要改变产品功能的可用性，则排除该问题。

搜索结果、重复内容和实现差异仅产生候选问题，而非已验证的问题发现。仅当同时满足以下三项验证条件时，才保留候选问题：

Contract（契约） — 引用针对此属性和范围的具有约束力的设计决策，或同一任务内用户可见的展示或内容中的直接矛盾。“建议”、“通常”、名称、遗漏、重复以及无例外说明都不能构成契约。
Runtime（运行时） — 证明引用的归属组件、值或行为通过追踪的运行时路径影响到目标界面。不得比较不同归属层或生命周期状态。
Correction（修正） — 说明依据要求的一项变更。若依赖现有token、variant、primitive或示例，则准确命名。若依据无法确定正确选择、预期条件模糊、提案包含多种方案或修正需自行定义产品意图，则排除该候选问题。

源码可证明token、排版、颜色、间距、布局、文案、component-variant、responsive-presentation和明确设计契约的违规情况。但无法将功能行为、状态管理或交互正确性转化为设计问题发现。层级、突出性、密度、清晰度、可发现性、可用性和感知连贯性需要渲染或用户依据。

除非用户明确要求，否则排除无障碍和HTML/ARIA语义相关的问题发现。除非用户要求或特定产品设计契约管控，否则排除路由故障、重定向、数据连接、动作失败、元数据、包API、性能、架构和代码质量相关的问题发现。

仅在所有验证通过后才确定置信度。若依据支持，复用现有归属组件；不得仅因重复内容创建共享primitive。

4. Vet findings

4. 审核问题发现

Before reporting, re-open every cited source and try to falsify each candidate. Delete it when:

The problem does not exactly match the cited implementation.
The rule does not govern that property and surface.
Counterevidence shows the difference is valid or deliberate.
The evidence supports multiple corrections.
The correction invents product intent.
Another finding describes the same root problem.

Only findings that survive this pass may enter the table.

在报告前，重新查看所有引用来源并尝试推翻每个候选问题。出现以下情况时删除候选问题：

问题与引用的实现不完全匹配。
规则不管控该属性和界面。
反证表明差异是合理或故意的。
依据支持多种修正方案。
修正需自行定义产品意图。
另一问题发现描述了相同的根本问题。

只有通过此审核的问题发现才可进入报告表格。

5. Report

5. 生成报告

Order surviving findings by confidence, user impact, reach, and correction cost. Stop at three.

Use this structure:

markdown

undefined

按置信度、用户影响范围、覆盖度和修正成本排序保留的问题发现，最多保留三项。

使用以下结构：

markdown

undefined

Design language

Audited surface:
Design sources:
Documented decisions:
Governing owners and consumers:
Explicit exceptions:

Audited surface:
Design sources:
Documented decisions:
Governing owners and consumers:
Explicit exceptions:

Findings

#	Problem	Evidence	Proposed change	Scope	Confidence

#	Problem	Evidence	Proposed change	Scope	Confidence

Improve first

<Highest-leverage finding and why, or no supported recommendation.>


Evidence must establish the contract, runtime relationship, and deterministic interface consequence. Proposed change must contain one correction. Delete unsupported or overlapping rows before returning.

Delete any finding that does not include every required column, including Confidence.

Under `Improve first`, select one surviving finding with the strongest evidence and highest leverage. Never combine findings.

If no candidate survives, write `No supported findings were found.` under `## Findings` and `No supported recommendation.` under `## Improve first`.

If findings survive, stop and ask which to turn into plans. If the user already selected a finding or explicitly requested a plan for a described improvement, continue with that scope. If asked to fix or improve directly, offer a plan; never implement it.

<Highest-leverage finding and why, or no supported recommendation.>


依据必须明确契约、运行时关系和确定性的界面影响。建议的变更必须包含一项修正。返回前删除无依据或重叠的行。

删除任何未包含所有必填列（包括Confidence）的问题发现。

在`Improve first`下，选择一项依据最充分、影响力最大的保留问题发现。切勿合并多个问题发现。

若无候选问题通过审核，在`## Findings`下填写`No supported findings were found.`，在`## Improve first`下填写`No supported recommendation.`。

若有问题发现通过审核，停止操作并询问将哪些问题转化为计划。若用户已选定问题或明确要求针对描述的改进编写计划，则继续按该范围执行。若被要求直接修复或改进，提供计划；绝不自行实施。

6. Specify selected changes

6. 明确选定的变更内容

Read references/plan-template.md. Write one plan per selected change, never one per symptom.

Before writing, re-open every cited source, record the current commit when available, identify exact reusable primitives and exemplars, and trace affected surfaces. Reconcile an existing plan instead of duplicating it.

Do not invent values when the repository provides a token or component contract. Introduce a primitive only after proving why the existing system cannot express the decision and which consumers should share it.

If asked to reconcile, recheck existing plans against current source and documented decisions; update stale evidence, affected surfaces, and status.

阅读references/plan-template.md。针对每个选定的变更编写一份计划，切勿按症状编写计划。

编写计划前，重新查看所有引用来源，记录当前可用的提交版本，识别可复用的精确primitives和示例，并追踪受影响的界面。若已有计划则进行协调，避免重复。

若仓库提供token或组件契约，不得自行定义值。仅在证明现有系统无法表达决策且确定哪些消费者应共享该primitive后，才可引入新的primitive。

若被要求协调计划，重新检查现有计划与当前源码和已记录决策的一致性；更新过时的依据、受影响的界面和状态。