break-ui 是什么？

break-ui 是 emilkowalski/skills（该仓库拥有约 43K star、1.9M 安装量）中的一个 Skill。它的定位非常明确：一个 UI 组件的“破坏性测试”工具，不是代码审查工具，也不是设计评审工具。

它解决的是一个几乎所有前端开发者都遇到过的问题：设计稿上的组件在“完美数据”下看起来精致，但真实用户上传的内容不受控——长名字会撑破布局，无空格的邮箱会溢出容器，复数文案在数量为 1 时会出错，emoji 开头的名字会拆坏字符串处理逻辑。

break-ui 的工作方式是：读取你指定的 UI 组件，识别它渲染的每一个值，从内置的 CATALOG 中挑选真实但极端的数据来构建最坏情况数据集，通过一个 dev-only 的切换器让你对比“Demo data”和“Worst case”，然后在多个宽度和环境下检查组件是否崩溃。

break-ui 的主要功能

攻击面绘制。第一阶段要求列出组件渲染的每一个值，包括字段名、来源、类型、长度限制和是否可选。字段包括那些容易忘记的：头部里的计数、相对时间戳、badge 和状态文案、来自数据的按钮标签、tooltip、头像图片、以及列表本身（它的长度也是一个值）。

最坏情况数据集构建。从 CATALOG.md 按字段类型挑选值，组装一个与现有 demo 数据形状完全一致的最坏情况 fixture。关键纪律：混合命中——第一行是长名字，第二行是长邮箱，第三行是单字母名字，而不是把所有问题堆在第一行。

Dev-only 切换器。在视口底部中央放置一个“Demo data / Worst case”分段控件，让对比零成本。还包含额外的状态：Empty（空列表）、One（单条数据，检查复数）、1,000 rows（性能破坏）。这个切换器永远不会进入生产环境。

多维度破坏检查。在组件的真实容器宽度、320px、200% 浏览器缩放、深色模式和 RTL（如果产品支持）下逐一检查。内置一张约 20 种失败特征的“症状-原因-修法”对照表。

break-ui 的核心特色

反对无意义数据。一串 aaaaaa... 能撑破布局，但它不是真实用户会产生的输入。break-ui 的 CATALOG 包含的是真实世界的极端数据：波兰名字 Wojciech Szczęsny-Nowak、45 字符无空格的公司邮箱、德语 30 字符无空格复合词 Benachrichtigungseinstellungen、CJK 姓名 王秀英、RTL 名字 نور الهدى عبد الرحمن、emoji 开头的名字 🦊 Fox。

反对止步于明显问题。长文本溢出人人看得到。break-ui 关注的是那些人工测试几乎必然遗漏的细微问题：1 members 的复数错误、0 seconds ago 的零值退化、跨时区日期差一天、0.1 + 0.2 浮点误差原样渲染。

只改数据，不改组件。这是六条硬规则中最重要的一条。AI 在测试过程中不能顺手“修”组件，否则就污染了被测对象。测试用的 fixture 必须与 demo 数据形状一致，只替换数据值。

先报告，不擅自动手。一些“破坏”其实是设计决策——该截断还是换行？该隐藏角色还是显示“—”？break-ui 要求列出所有问题、给出建议，然后停下来。只有用户点头后才执行修复。

break-ui 可以用来做什么？

在代码合并前发现边界渲染问题。用最坏但真实的数据压测组件，提前拦截那些人工测试容易遗漏的 bug。

检查一个列表组件的鲁棒性。比如一个成员列表：长名字、长邮箱、缺失名字、CJK 姓名、emoji 头像——这些都会在某个宽度下暴露问题。

验证响应式和可访问性。在 320px、200% 缩放、深色模式和 RTL 下检查组件是否仍然可读、可交互。

不适合的场景：代码风格审查、性能优化分析、设计系统的一致性检查。break-ui 只做一件事：用最坏数据看组件会不会碎。

break-ui 适合哪些人？

  • 前端开发者：在提交 UI 组件前，用系统化的方式测试边界情况。
  • 设计师：理解自己的设计在真实数据下会如何变形。
  • QA 工程师：把“边界情况测试”从手动直觉变成结构化流程。
  • 用 AI 编码助手做 UI 开发的团队：让 AI 在生成组件后，自动执行破坏性测试。

不太适合：不需要 UI 测试的后端项目、只做静态页面的场景、以及期望 AI 自动修复所有问题的用户（break-ui 坚持“先报告，不擅自动手”）。

break-ui 如何安装？

方式一：通过 skills CLI 安装（推荐）

npx skills add emilkowalski/skills --skill break-ui

方式二：从 emilkowalski/skills 仓库安装全部技能

npx skills add emilkowalski/skills

方式三：手动复制

将 break-ui/SKILL.md 及相关文件（包括 CATALOG.md）复制到你的 Agent skills 目录，例如 Claude Code 的 ~/.claude/skills/ 或项目内的 .claude/skills/。

验证安装：安装后向 AI 助手提问“你能用 break-ui 帮我测试这个组件的边界情况吗？”，如果 AI 能引用 CATALOG、worst-case fixture、失败特征对照表等概念，说明 Skill 已加载。

break-ui 怎么使用？

基本流程（六阶段）：

  1. 绘制攻击面：让 AI 读取组件，列出它渲染的每一个值、来源、类型、限制。
  2. 构建最坏情况：从 CATALOG 挑选数据，组装 worst-case fixture，同时覆盖空态、单条、千条以上。
  3. 接线开关：在 dev 环境放置“Demo data / Worst case”切换器。
  4. 发起攻击：在真实容器宽度、320px、200% 缩放、深色模式、RTL 下检查。
  5. 报告并停止：输出破坏清单、待决设计问题、以及“什么扛住了”。
  6. 按需修复：用户点头后才修，修完重新验证所有状态，fixture 留作回归测试。

有效的提问方式：

“用 break-ui 测试这个 MemberList 组件，看看长名字、无空格邮箱、emoji 头像和空列表会不会出问题。”

break-ui 使用技巧

让 AI 在“报告”阶段停下来。这是 break-ui 的核心纪律。如果 AI 直接开始改代码，它可能把“设计决策”当成“bug”来修，污染了原本应该由人决定的问题。看到 AI 开始修改，明确说：“先只报告，不要动代码。”

注意 CATALOG 中的真实数据。break-ui 的 CATALOG 不是随机乱码，而是精心挑选的真实世界极端数据。🦊 Fox 会拆坏 .charAt(0) 的代理对，王秀英 会击溃“取首尾单词”的首字母算法，first.last+billing@example.com 会暴露校验逻辑缺陷。

不要跳过 Empty / One / 1000 rows。这三个状态往往被“两态切换器”忽略，但它们是真实的破坏来源：空列表的空白区域、1 members 的复数错误、千条数据下的性能退化。

修复后重新验证。break-ui 要求修完问题后重新渲染所有状态，并把 fixture 留作回归测试，而不是删除。

break-ui 收费吗？

免费且开源。break-ui 是 emilkowalski/skills 仓库的一部分，以开源形式发布。Skill 本身不收费，你只需要为使用的 AI 编码助手支付订阅费用。

break-ui 的优点与缺点

维度 优点 缺点
数据真实性 用真实世界极端数据而非乱码，暴露的是真问题 依赖 CATALOG 的覆盖度；某些垂直领域的数据可能未被收录
测试系统性 六阶段流程 + 失败特征对照表，把边界测试结构化 需要理解“先报告再修复”的纪律，否则可能被误用
组件隔离 “只改数据，不改组件”防止测试污染被测对象 不检查组件在真实上下文中的表现，只看它孤立时是否扛得住
开发安全 切换器仅限 dev 环境，不会进入生产 需要项目有 dev server 或创建独立 HTML 文件
输出质量 三段式报告：破坏清单、待决问题、什么扛住了 不自动修复，需要人工决策和后续执行

break-ui 与同类工具对比

vs 手动边界测试。手动测试依赖你“想到”哪些边界情况。break-ui 提供了一个系统化的 CATALOG，覆盖文本、标识符、数字、集合、时间、媒体、状态和环境，减少遗漏。

vs Storybook 的边界案例。Storybook 可以展示不同状态，但需要你手动编写每个 story。break-ui 自动从组件读取值、构建最坏情况数据集、生成对比视图，过程更自动化。

vs 通用 AI 提示词（“测试这个组件的边界情况”）。通用提示词没有固定的 CATALOG、没有“先报告不擅自动手”的纪律、没有失败特征对照表。break-ui 把这些纪律和工具封装成了一个可重复的工作流。

break-ui 常见问题 FAQ

Q：break-ui 会直接帮我修组件吗？
不会，除非你明确要求。它的默认行为是先报告，然后停止。一些“破坏”其实是设计决策（截断还是换行？隐藏还是显示占位符？），需要人来决定。

Q：它和普通 code review 有什么区别？
code review 检查代码是否正确；break-ui 检查组件在真实数据下是否会碎。它不关心代码风格、性能或架构，只关心边界渲染。

Q：为什么不能用 aaaaaa 这种数据？
因为这不是真实用户会产生的输入。用乱码测试暴露的是“伪问题”，而真实世界的极端数据（波兰名字、德语复合词、emoji 表情）暴露的是真实用户会触发的问题。

Q：切换器会进入生产吗？
不会。break-ui 明确要求切换器是 dev-only，在生产环境不可见。

Q：测试完 fixture 要删掉吗？
建议保留作为回归测试。break-ui 的工作流要求“修完问题后重新验证所有状态，并把 fixture 留作回归测试”。

break-ui 综合评价

break-ui 解决的是一个被系统性忽略的问题：UI 组件在“完美数据”下看起来没问题，但真实用户的数据从来不是完美的。

它的价值在于把“边界情况测试”从一种依赖直觉的手动行为，变成一套结构化、可重复的工作流。六阶段流程、真实数据 CATALOG、“先报告再修复”的纪律——这些设计让边界测试不再是“有空再做”的额外工作，而是组件开发流程中的一个标准环节。

它的门槛很低：不需要新框架，不需要额外配置，只需要一个 dev server 或一个独立 HTML 文件。它的纪律也很明确：AI 不替你做设计决策，只帮你把问题找出来。

对于任何在开发 UI 组件的开发者，break-ui 值得花几分钟安装。它不会让你的组件变得更好看，但它能让你的组件在真实数据面前不那么容易碎。