Harden

什么时候用

/impeccable harden 适合界面开始面对真实世界的那一天。真实用户的数据很脏：60 个字符的人名、德语产品标题、几十亿的价格、500 错误、离线模式、从右到左的文字。只在完美数据下成立的设计，不算 production-ready。

在上线前、开拓新市场前，或者任何一个 bug 报告以“我们有个用户名字特别长……”开头的时候，都该用它。首屏激活、空状态引导和 onboarding 设计，则更适合用 /impeccable onboard。

工作方式

这个技能会从四个维度补齐真实世界韧性：

1. 文本与数据极值。 超长文本、极短文本、特殊字符、emoji、RTL、十亿级数字、1000 项列表。
2. 错误场景。 网络失败、API 4xx/5xx、校验失败、权限错误、限流、并发操作。
3. 国际化。 长翻译文本（德语常常比英语长 30%）、RTL、日期和数字格式、货币符号、字符集。
4. 设备与上下文。 触控目标、离线行为、慢网、低电量模式。

在每个维度里，它都会先指出失败模式，再落具体修复：溢出处理、信息充分的错误 UI、对 i18n 安全的布局、复数规则、合理 fallback。

试试看

先拿一个页面和一个维度开始：

/impeccable harden the user profile page for long names

预期输出：

• .user-name 现在使用 text-overflow: ellipsis，并用 tooltip 展示完整值
• .bio 从固定高度改成 max-height + “展开更多” disclosure
• 为没有 bio 的用户补了空状态
• 异步头像加载补了 skeleton loader
• 用 1、20、60、200 字符长度测试过名字显示

按页面逐个跑，而不是一次全站铺开。第一次收益最大，后面的运行会随着模式固化而找到更少问题。

常见陷阱

• 等 bug 报告来了才做。 Harden 是预防性的。如果同一类 bug 你修了两次，就该对整条功能链跑一次 /impeccable harden。
• 把错误和空状态当成补丁。 大多数 hardening 工作本质上就是错误与空状态 UI。时间要预留给它，而不是只写一个 catch。
• 因为“我们暂时只有英文”就跳过 i18n。 对 i18n 友好的布局，通常也就是更好的布局。更弹性的容器、更合理的换行、更宽松的行高，对英文没有坏处。