remove-ai-slop

审计实际界面，而不只是列出流行设计元素。果断移除一眼可辨的默认设计。判断较隐晦的模式是否适合产品、内容和品牌，还是只是在重复沿用已学会的模板。

不要让清理工作演变成另一种统一风格。不要默认把每个界面都做成扁平、深色、圆角极少或单色。

使用三种判定

严禁

仅当符合下方定义中精确的未完成文案、语义重复、重大歧义、捏造证据或类似客观情形时使用此判定。确认出现一处即可。单凭视觉偏好、常见组件、几何形状、字体和装饰元素不符合条件。

使用此判定：

严禁 — [模式]。[不合格原因]。将其移除。[修复方向]。

仅允许该模式所列的狭义语义例外。“这是品牌选择”本身并非证据。

强烈倾向

用于可能适用、但缺乏依据或反复出现时通常会显得像默认设计的模式。保留此类模式必须有具体的产品、内容、功能或有据可查的品牌理由。

使用此判定：

强烈倾向 — [模式] 显得像复用的默认设计，因为 [证据]。仅当它有 [具体用途] 时才保留；否则 [修复方式]。

情境信号

用于中性的设计或文案表达；只有在重复出现、不匹配、共同出现或占主导时，才会沦为敷衍设计。不要将孤立且置信度低的元素报告为缺陷。

将可访问性、语义、性能和事实完整性缺陷单独列在 QUALITY DEFECTS 部分。这些问题很重要，但不能证明内容由 AI 生成。

第 1 阶段：明确上下文

在盘点仓库前选择审计范围：

• 聚焦式 — 一个路由、一类组件、一段流程或一个已报告的模式。检查该边界内所有有意义的状态。
• 代表性 — 产品级审查的默认方式。抽样检查每种不同的页面类型、共享界面框架、主要组件系统和高风险流程；纳入足够多的路由，以检验设计是否趋同，无需渲染每个同类页面。
• 全面式 — 检查范围内的每个路由、语言区域、渠道和有意义的状态。当用户明确要求全面覆盖，或受监管、发布阻断或迁移工作足以证明投入合理时使用。

根据请求和仓库推断足以完成任务的最小范围。说明纳入项、排除项、抽样理由和不可用状态。仅当问题可能源自共享来源，或所需置信度要求扩大范围时才扩大审计范围。

评判设计前先阅读仓库证据：

• 阅读 README、产品简介、设计文档、路由结构、现有文案、设计令牌、字体配置、Logo 和第一方资源。
• 确定产品、受众、主要任务、预期语气和重要品牌限制。缺失的信息标记为 unknown；不要编造品牌故事。
• 为每个路由指定用途，例如营销、定价、文档、仪表板、设置、引导流程或账户管理。
• 记录每个路由的主要操作和内容形式。
• 比较路由时，将共享导航和页脚框架与页面专属布局分开。

查找相关源码时，不要截断所选范围：

rg --files \
  -g '*.{tsx,jsx,ts,js,css,scss,sass,less,html,vue,svelte,astro,md,mdx,json,yaml,yml}' \
  -g '!node_modules/**' -g '!.next/**' -g '!dist/**' -g '!build/**'

纳入会影响所选范围的主题文件、组件库覆盖项、内容文件和资源清单。利用依赖关系和路由结构，排除无关的应用代码。

第 2 阶段：检查渲染结果

如果代码库提供了安全的开发命令，请运行现有应用。在聚焦模式下，记录范围内每个有意义的状态。在代表性模式下，记录每种不同的页面角色和共享系统，并选择能够显露疑似问题的视口和状态。在穷举模式下，使用路由／状态矩阵并记录覆盖情况。

对于每项渲染结果发现，请记录：

• 路由、视口和状态
• 截图或精确的渲染描述
• 源文件和行号
• 有用时，记录计算样式或组件证据

如果无法渲染，请为依赖外观的发现加上标签：

候选问题 — 无法确认渲染结果。

不要仅凭类名就断言视觉主次失衡、层级失效或构图不佳。

第 3 阶段：发现高置信度缺陷和默认做法

1. 装饰性粗体全大写眉题

如果标题上方紧邻 H1 或 H2 的简短标签符合以下情况，请强烈怀疑它是眉题：

• 使用全大写文本或 text-transform: uppercase
• 使用 600 及以上字重、高对比度、强调色、宽字距、圆点或装饰线来营造重要感
• 没有提供标题、路由或周边导航之外的信息

如果 FEATURES、WHY US、OUR PLATFORM、MANUAL PAGE 和 INTRODUCING 等标签只是在宣告下方内容，可将其视为装饰性候选项。重复出现、视觉上喧宾夺主或与既定层级冲突，会提高判断置信度；仅出现一次不足以证明这是系统性问题。

只有真实且不冗余的状态或操作元数据（例如 LIVE、ERROR、BETA、权限状态或版本号）才可保留。不要标记自然形成的缩写。

默认结论：

强烈怀疑 — 装饰性全大写眉题。它似乎只是在强调，却没有提供信息，因为 [证据]。除非它承担有据可查的导航、状态或品牌作用，否则请删除或弱化。

2. 字体不协调或使用不当

当可读性或语义一致性受损时，应将排版报告为质量缺陷。如果在没有合理用途支撑的情况下，出现以下任一情况，则强烈怀疑是模板拼凑：

• 可见的字体家族达到三种或以上，且没有明确、稳定的用途
• 相同语义角色在不同组件或路由中使用不同字体家族
• 组件使用了设计令牌之外的专属字体
• 衬线体、斜体、等宽字体、手写体或展示字体仅用于装饰孤立的词语，却没有实际含义
• 新奇字体、窄体、手写体或展示字体用于段落、导航、控件、表格或密集的产品 UI

如果字标、真实代码或终端内容、数学符号以及特定语言的回退字体仅用于对应内容，则可以保留。

默认结论：

强烈怀疑 — 字体系统不协调。这些字体变化在受检系统中没有稳定用途。请将其统一为明确的用途，除非产品或语言证据能够解释这些差异。

改进时，应使用一个字体家族，或有意搭配两个字体家族，并可选择性地增加等宽字体。将用途定义为令牌。不要自动把所有字体都替换成 Inter 或 Geist。

3. 通用圆角或胶囊按钮

如果满足以下任一条件，且渲染结果显示其与产品的操作层级冲突，则强烈倾向于将按钮判定为沿用模板样式：

• 普通文本 CTA 使用胶囊形状，例如 rounded-full、9999px，或计算出的圆角半径至少达到按钮高度的一半
• 操作保留未经修改的模板库配方：通用圆角、默认内边距、纯色填充、白色标签，以及默认的悬停／焦点样式，且缺乏有意义的层级或产品特征

实际的标签、标记、筛选令牌、分段控件、切换开关和纯圆形图标控件不在此列。普通 CTA 不会因为尺寸小就变成标签。

默认判定：

强烈倾向 — 通用圆角／胶囊 CTA。其几何形状和状态样式照搬了未修改的模板模式，没有体现该产品的操作层级。除非此模式在这里已成为惯例且确实有效，否则应重新设计操作系统。

将主要、次要、破坏性和低强调操作作为一个整体进行修复。根据产品的视觉语言选择形状、字体、边框或填充、图标样式，以及焦点、悬停、按下、加载和禁用状态。不要把所有胶囊按钮都换成同一种模板式 8px 黑色矩形。

4. 其他高置信度发现

• 如果与产品主题、状态、使用频率或既有品牌不符，伪终端界面、装饰性闪光、渐变动画边框、常规彩纸动画和表情符号导航都属于强烈倾向判定的情况。
• 缺乏依据的数据横幅，以及虚构或误导性图表，属于声明诚信缺陷。无论其视觉风格看起来是否像生成内容，都应归入 QUALITY DEFECTS。

在渲染结果中确认依赖外观的发现。指出未通过的具体角色、重复情况、不匹配之处或诚信规则；“字体难看”和“按钮无聊”不算发现。

第 4 阶段：查找上下文相关的粗糙设计

如果这些做法在无关的页面角色中反复出现，或缺乏仓库证据支持，则强烈倾向于判定为问题；否则应作为上下文信号评分。

布局和组件信号

• 居中的徽标或胶囊标签 → 超大 H1 → 两个 CTA → 三张等宽功能卡片
• 不考虑内容类型，一律使用三列图标、标题和正文卡片
• 将 01 / 02 / 03 编号步骤用于并非按顺序排列的内容
• 使用 Bento 布局把无关内容压平成装饰性卡片
• 嵌套卡片，以及为内容量不等的内容强行设定相同高度
• 不考虑信息架构，一律使用四列等宽页脚
• 使用全视口 Hero，标题含糊且没有产品依据
• 仅为营造编辑感而使用通用的错位构图
• 将同一个卡片组件或数据模式强行套用于三个或更多语义角色
• 几乎对所有表面都应用 rounded-2xl、相同边框或相同阴影
• 每个功能标题上方都放置圆角方形图标块
• 未经修改地沿用默认 shadcn 或入门套件样式

颜色和效果信号

• 紫到蓝、靛蓝到粉红或类似的默认渐变主导 Hero 或 CTA
• 主标题使用渐变文字
• 使用网格或点状背景作为通用科技纹理
• 使用暖琥珀色和奶油色、安全翡翠绿或薰衣草色，却没有产品或品牌依据
• 使用彼此竞争且没有语义角色的强调色
• 颗粒、环境聚光、辉光、玻璃效果、条纹和装饰性伪元素
• 在同一区域叠加三种或更多装饰效果
• 深色背景上的低对比度灰色文字；如果对比度不达标，应另行报告为质量缺陷

字体排版信号

• 默认选择 Inter、Geist、Space Grotesk 或 Instrument Serif，而非根据产品适配度选择
• 将 Space Grotesk 与 Instrument Serif 搭配，作为时髦的捷径
• 在普通正文中使用等宽字体
• 主视觉字体占据整个视口，却没有足够理由突出显示
• 用斜体衬线字体装饰主视觉中的一个词
• 在每个区块中反复使用全大写标签
• 层级扁平，或展示风格过多、彼此争夺注意力

不要仅因某种字体常见就将其标记出来。应标记缺乏明确的角色、适配度和层级。

动效信号

• 在日常控件上使用弹跳或弹性缓动
• 对每个区块或列表都应用交错淡入效果
• 对不需要通过时间变化来解释的内容应用加载动画
• 使用通用的图像悬停缩放或旋转效果
• 对宽度、高度、内边距或外边距进行动画处理
• 缺少 prefers-reduced-motion；将此报告为质量缺陷

图像与数据相关信号

• 将抽象的 3D 团块、球体、大脑或神经网络用作通用 AI 产品图像
• 通用的团队围坐笔记本电脑旁的图库照片
• 与产品主题不符、平滑对称的 AI 插画
• 在无关的声明或页面路由中重复使用同一张图片
• 截图被装饰性框架遮挡，无法展示实际产品
• 图表数据不可信、图表类型不合适、缺少坐标轴或单位、标签难以辨认、颜色编码不具备无障碍性，或未说明结论

第 5 阶段：衡量趋同程度与适配度

审查整个代码库中的决策分布，而不只是单个元素。

• 比较各路由的页面结构：地标顺序、主视觉结构、区块顺序、组件树、布局原语和重复出现的类组合。
• 在判断页面相似度之前，排除共享的页面框架。
• 标记语义不同的路由之间高度相似的结构。
• 统计重复出现的视觉元素组合，而不只是单个设计变量。
• 检查无关内容是否被强行套用相同的 icon + title + description 或卡片模式。
• 检查相同的圆角、阴影、强调色和字体样式是否出现在所有表面角色中。
• 将资源复用情况与各页面的含义进行比较。
• 在承担相同角色的页面之间保持一致性，同时要求不同角色之间有所调整。

明确判断页面角色与页面的适配度：

• 营销页面需要明确的价值主张和产品证据。
• 定价页面需要便于比较和决策的支持信息。
• 仪表板需要任务密度、状态信息和信息层级。
• 文档需要导航、内容顺序和易读示例。
• 设置页面需要清晰说明、影响和安全操作。

使用以下透明启发式评分法评估每个非硬性禁用项的设计候选项：

• +2 在三个或更多不同场景中重复出现
• +2 与页面用途、内容形态或有据可查的品牌规范冲突
• +2 在渲染后的页面中占据视觉主导地位
• +1 与两个或更多其他通用默认设计同时出现
• +1 有损理解或操作层级
• -2 有证据支持的具体功能或品牌理由

将评分用作参考，而非伪科学：

• 5+：置信度为 HIGH；建议移除或重新设计
• 3–4：置信度为 MEDIUM；作为强烈推定报告，并指出缺少的理由
• ≤2：置信度为 LOW；从缺陷中省略，或仅列为观察项

确认符合具体标准后，硬性禁用项不受此评分限制。

第 6 阶段：审查文案

将营销文案和产品内语言作为一个整体来审查。标记实际用法，而非无辜的子字符串、引文、产品名称、代码示例、法律文本或必要的技术语言。

构建文案清单

在提取之前，先定义纳入范围的界面、渠道、流程、路由、区域设置和状态。对于不可用的内容，应明确报告，而不是暗示覆盖完整。

从标记、组件属性、常量、区域设置文件、CMS 固定数据、提示消息、错误、空状态、加载状态、对话框、表单、电子邮件和通知中提取面向用户的字符串。

为每个字符串记录：

• 界面或渠道、流程、可选路由、页面角色、组件和 UI 状态
• 源文件和行号
• 可用时，插值后的呈现文本
• 区域设置、消息 ID、插值变量、复数或选择分支，以及适用时的回退内容
• 适用时的无障碍名称、替代文本、验证用途或其他非可见用途
• 每项唯一的源文案决策，以及共享组件生成的每个呈现实例
• 对重要文案和实质性主张，记录实际操作、目标位置、系统状态或主张来源；其他情况填 N/A

排除测试、日志、没有呈现值的本地化键、未作为产品沟通内容展示的引用或代码示例，以及明确标注的模板。将真实的文档正文纳入范围。将共享导航纳入术语审查，但从跨路由趋同计数中排除。

找出有害文案

只有在完全符合定义时才使用 HARD BAN。措辞形式本身并不足以作为证据。将文案硬性禁令视为必须删除的判定，而非文本由 AI 撰写的证明。

1. 面向用户的占位内容

对于 Lorem ipsum、TODO、Feature 1、Your headline here、明确标为占位内容或已确认虚构的推荐语，以及其他作为成品文案展示的框架占位内容，予以禁用。对于缺少来源信息的推荐语，标记为 UNVERIFIED；没有证据时，不要称其为虚构。允许明确标注的演示、模板和文档示例。

HARD BAN — 面向用户的占位文案。这是框架占位内容，不是产品沟通内容。请移除；替换为已核实的内容，或省略该区块。

2. 不含信息的叙述或节奏表达

如果删除某个开场语、过渡语或营销表达后，不会失去任何主张、指令、范围、导航、安抚、安全提示、无障碍用途、刻意营造的语气或有意义的对比，则将其禁用。以下空洞用法也包括在内：

• “在当今快节奏的世界中”“让我们深入了解”或“关键来了”
• “这不是关于 X，而是关于 Y”或“这不仅能 X，还能 Y”
• “没有 X。没有 Y。只有 Z”、“从 X 到 Y”，或类似“快速。简单。强大。”的省略式三段表达

如果某种表达传达了具体事实，则不要禁用。“无需设置。无需信用卡。只需粘贴 URL。”内容具体；“无摩擦。无极限。只有增长。”则不具体。

HARD BAN — 不含信息的文案。“[quote]”只是修辞，没有提供信息。请移除；从第一个实质性主张开始。

3. 完全相同的语义重复

如果同一呈现状态中可见的文案重复了相同主张，且没有增加机制、细节、含义、证据、决策或后续操作，则将其禁用。不要将响应式替代内容、互斥状态、仅用于无障碍功能的等效内容，或长篇文档中真正的综合内容计入重复。

HARD BAN — 语义重复。“[quote]”重复了[较早的文案]，没有增加信息。请删除，或替换为缺失的细节。

4. 含义模糊的重要操作文案

对于付款、删除、发布、权限、账户或其他重要操作，若 Submit、OK、Confirm 或 Continue 是唯一标签，则将其禁用。如果用户需要了解受影响的对象、结果或恢复操作，却只看到“出了点问题”、“成功了！”或“没有数据”这类完整消息，也应将其禁用。

如果周围流程能让操作后果一目了然且风险较低，则允许使用常见的 Back、Close、Done、Retry 和 Continue。

HARD BAN — 含义模糊的重要操作文案。“[quote]”没有说明将要发生什么或刚刚发生了什么。请明确说明操作和对象、结果或安全的恢复途径。

将主张与状态完整性问题分开

将以下内容归入 QUALITY DEFECTS，而不是作为 AI 创作的证据：

• 编造或未经核实的统计数据、用户评价、排名、认证、徽标或客户数量
• 缺乏依据的比较性、绝对性、安全、隐私、可靠性或性能主张
• 系统实际上并不知晓的错误原因
• 声称进行了系统并未进行的测量的进度文本
• 操作尚未确认就显示的成功文案
• 与产品实际行为相矛盾的术语或操作标签

不要仅仅因为仓库中没有来源，就称证据是编造的。标记为 UNVERIFIED，要求提供来源；只有在证据被证伪或仍缺乏支持时，才将其移除。

找出强烈疑点

如果仓库证据无法提供缺失的实质内容，请将以下情况视为强烈疑点：

• 完整的主视觉文案未能说明产品的功能、目标用户或其重要性
• 使用“释放价值”“提升工作流”“化混乱为清晰”“无限扩展”或类似抽象表述，却没有指出具体任务、机制、限制或结果
• 空洞的吹捧，例如世界一流、同类最佳、久经考验、革命性、智能或 AI 驱动
• 通用 CTA 文案在当前语境中仍不清楚其目标位置或结果
• 在互不相关的路由中反复出现的反问句、老套对比、转变式标题或仅替换名词的功能描述
• 强行让每项功能都遵循以收益优先的公式，从而掩盖实际能力
• 与上下文文案不符的突然转变，如故作随意、卖萌、夸张或过度技术化的语气
• 总结内容少到不值得占用篇幅，但又并非完全重复

将语境信号视为语境信号

将单个词汇命中、长破折号、片段、反问句、缩写、句首的“And”或“But”、被动语态、行话、幽默、表情符号、总结，以及以收益或功能为先的排序视为语境信号。

保留用于表达真实的不确定性、概率、范围、能力、风险、法律限定或时间范围的保留措辞。只移除绕弯子的铺垫语。将 seamless、robust、powerful、cutting-edge、innovative、leverage、elevate、empower、unlock、harness、supercharge、craft、delve、tapestry 和 synergy 视为搜索线索，而非自动判定的问题。

衡量文案趋同与具体程度

比较不同路由和组件中的文案，关注以下方面：

• 完全重复或近似重复的措辞
• 将产品名词、数字和名称替换为占位符后，重复出现的句式骨架
• 重复出现的标题公式、CTA 动词、对比结构、片段、三段式、长破折号和反问句
• 重复使用的版块结构，例如眉题 → 祈使句标题 → 一句话承诺 → CTA
• 术语漂移：同一领域对象或操作出现多个名称或动词
• 营销语气蔓延到控制面板、错误提示、设置或破坏性操作中

保持同类页面之间的连贯性。标记在定价、文档、引导流程、设置和产品界面中反复出现的同一套销售模板。

使用以下四项测试：

1. 删除测试： 删除这段文字会损失有意义的信息或操作吗？
2. 三产品替换测试： 三种互不相关的产品能否原样使用这段文案？
3. 依据测试： 每项重要主张是否都对应某项能力、限制、测量、来源或经验证的结果？
4. 状态测试： 文案是否符合系统已知的信息、实际发生的情况以及用户可以执行的操作？

应将实质性主张作为文案块来判断，而不是孤立地看单句。检查是否包含足够的具体锚点，例如参与者、操作、领域对象、机制、限制和可观察结果。不要要求每个标签或句子都包含所有这些要素。

判断语气、页面角色和 UI 状态

根据产品文档、客户用语和有代表性的现有示例，判断语气。记录正式程度、亲和度、直接程度、技术密度、人称、缩写用法、大小写、标点和首选术语。在保持语气一致的同时，允许在高风险情境中让语气更沉稳、更准确。

让文案符合其用途：

• 营销：受众、价值主张、实现方式、证据和下一步行动
• 定价：真实差异、费用、限制、计费条款和决策支持
• 文档：前置条件、结果、步骤和准确示例
• 仪表板和设置：当前状态、任务、后果和保存状态，而非口号
• 引导和账户流程：下一步有用的操作、问题恢复方式和安全影响

为重要流程建立状态矩阵：初始、首次使用时的空状态、筛选后无结果、权限受限、加载中、有内容、已禁用、错误、成功和确认。只有在原因已知时才说明原因。明确指出具有破坏性的对象及其可恢复性。不要强迫所有空状态都使用“还没有 X — 创建你的第一个 X”这类文案。

为情境文案评分

• +2 在三个或更多互不相关的情境中重复出现
• +2 与页面角色或 UI 状态的任务不符
• +2 在消息块层面未能体现产品特性
• +1 与其他通用默认文案一起重复使用套话句式或节奏
• +1 破坏既定语气、术语或行动表述的清晰度
• -2 有文档记录的语气、功能、客户用语或同类页面用途作为依据

将 5+ 评为 HIGH，3–4 评为 MEDIUM，≤2 评为 LOW。硬性禁用项和完整性缺陷不受此评分影响。

在不凭空编造的前提下修正文案

• 删除填充内容和完全重复的内容。
• 根据消息块的需要，用已核实的领域名词、用户操作、实现方式、限制或结果，替换抽象说法。
• 缩小或删除缺乏依据的主张。如果缺少必要事实，将拟议的修正标记为 BLOCKED — CONTENT REQUIRED，而不是编造指标、能力或证明。
• 明确说明影响重大的操作和对象。对于错误，说明影响和恢复方法；只有在原因已知且有用时才说明原因。
• 区分不同类型的空状态，只编写每种状态所需的指引。
• 保留经过校准的不确定性、必要的技术术语、约定俗成的控件文案和有意采用的语气。
• 检查相邻文案，确保局部改写不会造成术语或语气偏差。
• 避免用统一的简短、生硬、刻意极简的品牌语气取代 AI 炒作式文案。

阶段 7：报告发现和修复

在编辑前停止。首先提供按用户影响、发生频率、置信度和修复成本排序的优先级摘要。在聚焦工作中，报告所有范围内的发现。在代表性或穷尽性工作中，将重复的源决策归组，避免报告对每个渲染实例重复提出相同修复。适用时使用以下章节：

COPY MANIFEST COVERAGE
Scope: [surfaces, routes, channels, locales, states]
Unavailable: [anything not inspected]
Unique source decisions: [count]  Rendered instances: [count]
Baseline: [hard bans, unverified claims, convergence clusters]

HARD SLOP — REMOVE
H1. [route, file:line] — [pattern]
    Before: [exact original]
    After: [verified replacement, deletion, or BLOCKED — CONTENT REQUIRED]
    Evidence: [exact code plus rendered evidence]
    Why it fails: [specific diagnosis]
    Verdict: Remove it.

CONTEXTUAL SLOP
C1. [route, file:line] — [pattern, score, HIGH or MEDIUM confidence]
    Verdict: [STRONG PRESUMPTION, CONTEXTUAL SIGNAL, or CANDIDATE]
    Before: [exact original]
    After: [product-specific repair or BLOCKED — CONTENT REQUIRED]
    Evidence: [repetition, mismatch, co-occurrence, render or copy manifest]

COPY CONVERGENCE
CC1. [convergence type and normalized pattern or term, score, confidence]
     Instances: [routes, states, files, and exact excerpts]
     Impact: [how unrelated jobs were flattened or terminology drifted]
     Repair: [which source decisions change and which terminology stays]
     Why it fails: [unrelated jobs forced through one voice or template]

QUALITY DEFECTS
Q1. [route, file:line] — [accessibility, semantics, performance, claim, or state-integrity issue]
    Evidence: [code, behavior, source, or contradiction]
    Impact: [user, trust, task, or compliance consequence]
    Provenance: [verified, unverified, contradicted, or not applicable]
    Recommendation: [repair, provenance request, or blocked status]

DECISIONS TO PRESERVE
P1. [element] — [why it is intentional, specific, and effective]

批评作品，而非作者。对于客观明显的问题，直截了当地指出：写“这个占位符被当作成品文案展示了。请将其移除”，而不是“你可以考虑完善一下”。对于视觉默认值，应陈述渲染结果所显示的证据及其置信度，而不要把个人喜好说成事实。

对于每项可执行的源决策，在有仓库证据支撑替换内容时，给出准确的修改前后内容。若缺少内容或产品意图，应说明需要做出的决策，而不是生成推测性替代方案。使用真实的产品文案和现有设计令牌，而非占位符。改写的说法须以引用的仓库证据为依据。将 UNVERIFIED 和 BLOCKED — CONTENT REQUIRED 视为仅用于报告的状态；绝不要将其写入面向用户的文案。若可进行渲染，应在相同路由、视口、状态、数据和动画设置下进行比较。

除非产品证据支持，否则不要采用诸如纯黑、单一强调色、8px 圆角、双列列表、统一简短的文案或默认随意语气等标准化替代方案。先说明预期的设计或文案目的，再提出能实现该目的的最小修复。

阶段 8：确认并应用

只有在用户要求实施，或在诊断后要求继续时，才进入此阶段。对于仅限诊断的工作，返回优先级报告、验证限制，以及可选的一句应用修复提议；不要凭空设置审批门槛。

若实施属于工作范围，在展示拟议的源代码更改或优先处理的首批项目后，从可执行项数量中排除仅用于报告和受阻的项目，然后询问：

已准备好应用 [X] 项修复。有哪些要跳过？ 回复要跳过的修复 ID，或说“开始”以应用全部修复。

等待批准。仅应用已获批准的更改。保留无关代码，以及在 DECISIONS TO PRESERVE 下记录的有意设计决策。

阶段 9：验证

编辑后：

1. 运行项目相关的构建、类型检查、代码检查和测试。
2. 重新渲染相同的路由、视口、状态和数据。
3. 确认每种禁用模式确实已消除，而不只是改了名称。
4. 确认类型角色和按钮状态构成连贯的系统。
5. 检查层级、溢出、对比度、焦点、语义和减少动态效果设置。
6. 重新运行路由比较，并确认角色不同的页面不再共用未经审慎设计的模板。
7. 确认修复没有用另一种陈词滥调取代原有问题。
8. 重新提取文案清单，并确认所有禁用项计数均为零。
9. 重新运行文案聚类，确认角色不同的页面有所区分，同时术语保持一致。
10. 确认每项重要说法都有来源、限定适用范围、缩小表述范围、标记为 UNVERIFIED，或已移除。
11. 重新测试操作标签、插值、复数形式、本地化、溢出和所有有意义的 UI 状态。
12. 大声朗读关键流程，确认清理工作没有强加简短或刻意营造对话感的统一语气。

只有在扎实的共享基础与因页面而异的结构并存、产品特色体现在其设计决策中，且没有明显粗劣之处时，才能称这项工作已完成。