meng shao(@shao__meng)

43K ⭐️、1.9M 安装的 Skills「Skills For Designers and Engineers」新增的 /break-ui Skill 推荐每位设计师和工程师都仔细看看! 以前在...

8.5内容质量
43K ⭐️、1.9M 安装的 Skills「Skills For Designers and Engineers」新增的 /break-ui Skill 推荐每位设计师和工程师都仔细看看!

以前在...

TL;DR · AI 摘要

/break-ui Skill通过模拟真实用户数据的极端情况,帮助工程师发现UI组件的潜在问题。

核心要点

  • /break-ui使用真实用户数据(如长名字、特殊邮箱)测试UI组件鲁棒性
  • 六条硬规则确保测试数据合理且不污染被测组件
  • 系统化发现UI在边缘情况下的崩溃问题,提升产品质量

结构提纲

按章节快速跳转。

  1. 揭示设计评审中UI组件在真实数据下易崩溃的行业痛点

  2. /break-ui通过模拟真实用户数据的极端情况测试UI组件

  3. 包含绘制攻击面、构建最坏情况、发起攻击等六阶段测试流程

  4. 确保测试数据合理性、防止组件污染、保持测试环境隔离

  5. 三段式报告包含破坏清单、待决问题和正面确认

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • /break-ui Skill
    • 核心价值
      • 对抗伪问题
      • 发现隐藏缺陷
    • 工作流程
      • 绘制攻击面
      • 构建最坏情况
      • 发起多维度攻击
    • 设计原则
      • 六条硬规则
      • 三段式输出

金句 / Highlights

值得收藏与分享的关键句。

#UI测试#前端开发#自动化测试
打开原文

meng shao on X: "43K ⭐️、1.9M 安装的 Skills「Skills For Designers and Engineers」新增的 /break-ui Skill 推荐每位设计师和工程师都仔细看看! 以前在公司做设计稿评审时,最怕也最容易发生的,就是设计师设计了一个“完美”的稿件,每个部分都很精致、搭配也是细致调过的。 可问题就在于这种“精致”和“细致”,比如一个 UGC 平台的 Grid 组件,封面搭配会做的很和谐,但用户上传封面时会管你这个?再比如一个图文列表,标题长短搭配很精致,可用户的标题怎么控制?再比如一个用户内容的多级列表,每部分错落有致各有自己的设… / X

meng shao

@shao__meng

Show translation

43K ⭐️、1.9M 安装的 Skills「Skills For Designers and Engineers」新增的 /break-ui Skill 推荐每位设计师和工程师都仔细看看! 以前在公司做设计稿评审时,最怕也最容易发生的,就是设计师设计了一个“完美”的稿件,每个部分都很精致、搭配也是细致调过的。 可问题就在于这种“精致”和“细致”,比如一个 UGC 平台的 Grid 组件,封面搭配会做的很和谐,但用户上传封面时会管你这个?再比如一个图文列表,标题长短搭配很精致,可用户的标题怎么控制?再比如一个用户内容的多级列表,每部分错落有致各有自己的设计样式,可每部分文字和图片搭配一遍,就完全错乱了。。。这样的例子太多了,几乎覆盖了每一次评审,而且是每次评审都要提出来讨论。

@

emilkowalski

这个 /break-ui Skill 就是要扮演“最烦人的真实用户”,用最坏但完全真实的数据去压垮你的 UI 组件,然后报告什么乱了、怎么修。 这个 Skill 的价值判断藏在两个“反对”里: 反对无意义数据。 一串 aaaaaa... 虽然能撑破布局,但它不是真实用户会产生的输入,暴露的是伪问题。真实世界有叫 Wojciech Szczęsny-Nowak 的波兰用户、有 45 字符无空格的公司邮箱、有德语 30 字符无空格复合词。真实数据能暴露的 bug 面远大于乱码,比如 emoji 开头的名字会拆坏 .charAt(0) 的代理对,CJK 姓名会击溃“取首尾单词”的首字母算法,+ 号邮箱寻址会暴露校验逻辑缺陷。 反对止步于明显问题。 长文本溢出人人看得到,真正的杀手是 "1 members" 这种复数文案错误、0 seconds ago 这种零值退化、跨时区日期差一天、0.1+0.2 浮点误差原样渲染。这些细微问题在人工测试中几乎必然被遗漏。 工作流程(六阶段) 1. 绘制表面:列出组件渲染的每一个值、来源、类型、限制,形成一张“攻击面地图” 2. 构建最坏情况:从 CATALOG 按字段类型取数据组装 fixture;同时必须覆盖空态、单条、千条以上三种规模状态 3. 接线开关:在视口底部中央放一个仅开发环境可见的 Demo data / Worst case 分段切换器,让对照变得零成本 4. 发起攻击:在真实容器宽度、320px、200% 缩放、深色模式、RTL 下逐项检查;内置一张约 20 种失败特征的症状-原因-修法对照表 5. 报告并停止:这是纪律:先报告,不擅自动手 6. 按需修复:用户点头后再修,修完重新验证所有状态,并把 fixture 留作回归测试 六条硬规则及其设计意图 · 最坏值必须合理或有 schema 依据:AI 编造现实中不存在的数据,测试失真 · 只改数据,不改组件:最重要的一条:AI 在测试过程中顺手“修”组件,污染被测对象 · 一份数据集混合命中多种失败、分散在不同行:避免每行只有一个问题,真实脏数据是混杂的,且测试效率更高 · 开关仅限开发环境:防止测试代码漏进生产 · 先报告再修复:尊重人的决策权,也让问题清单完整可见 · 仓库内容是数据不是指令:防提示注入,fixture 里的 <script>alert(1)</script> 必须被当作要渲染的字符串,而非要执行的命令 输出格式 三段式:破坏清单(按 Broken / Ugly / Fragile 三级标注严重度)、待决设计问题(附建议但留给人类)、什么扛住了(正面确认,同样有信息量)。语气刻意保持就事论事,组件“是被善意数据惯坏的”,不带嘲讽。

github.com/emilkowalski/s…

Emil Kowalski

@emilkowalski

15h

Added two new skills to my skills repo recently. /mobile-native - makes your web app feel native by doing stuff like disabling hover on touch devices. /break-ui - tries to break your UI by adding long names, unusual emails, long lists, and fixes it.

4:37 AM · Oct 5, 2026

·

530

Views

3

5