Emil Kowalski 的 Skills 仓库新增 /break-ui，用最坏真实数据压测 UI 组件

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 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. github.com/emilkowalski/s… 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 163 ⚡