Stable Skin 与视觉回归门禁

为什么需要 Stable Skin

网页视觉最危险的时刻，往往不是“还很丑”的时候，而是“刚刚满意”的时候。因为这时继续改一点按钮、阴影、边距或卡片，很容易把已经成立的整体感打散。

传统功能测试会告诉你按钮还能点、链接还存在、接口还返回 200；但它不一定会告诉你按钮已经被横幅遮住、卡片标题被截断、移动端出现横向滚动，或者整体视觉从稳定变成混乱。

Stable Skin 要解决的不是审美本身，而是视觉判断的可维护性：把一次满意的视觉状态命名、收口、保存证据，并让之后的每次变化都必须被解释。

视觉回归原理

视觉回归测试的基本模型很简单：先在一个被认可的版本上生成基准截图或基准快照，之后每次改动重新渲染相同页面、组件或状态，再把新结果与基准比较。

差异不自动等于错误。它只说明用户看到的东西变了。成熟流程通常允许三种结果：意外差异要修复，预期变化要 approve 并更新基准，可接受噪声要记录并降噪。

截图也不是唯一证据。稳定的视觉门禁通常会组合 DOM 文本、截图可见性、像素或视觉 AI 差异、移动端溢出检查和公开边界扫描。

先收口皮肤

给当前满意版本命名，例如 stable skin、readability pass、status polish，而不是继续留下“最后再改一点”的散乱覆盖。
把重复出现的颜色、卡片背景、输入框、焦点环和控件表面抽成少量 token。
让按钮、筛选、链接、复制控件和命令入口都有清楚的 hover 与 focus-visible 状态。
给长标题、长命令、窄屏布局加 overflow-wrap、min-width、grid 和 max-width 护栏。
冻结主背景、卡片密度、文章宽度、状态面板形态和移动端首屏，后续若要改这些，就按一次明确视觉版本处理。

判断标准

稳定皮肤不是“永远不改”，而是“以后每次改，都知道自己正在改哪一层”。

四层门禁模型

源码一致性检查资源版本、SEO 元数据、JSON-LD、sitemap、Docs 索引和首页更新是否指向同一轮内容。

DOM 断言确认文章标题、卡片数量、命令按钮、行动面板和关键 data 标记真的渲染出来。

截图差异在桌面和移动端生成截图，必要时与基准比较；动态内容用 mock、mask 或 ignore 降噪。

发布边界确认公开目录不含部署脚本、临时探针、私有路径、密钥、日志或内部状态。

常用工具

工具选择不应从“哪个最强”开始，而应从项目风险和现有流程开始。个人静态站先用轻量脚本就够；组件库更适合 Storybook/Chromatic；团队 PR 流程可接 Percy 或 Applitools；自托管页面级回归可以用 BackstopJS 或 Playwright。

Playwright适合本地和 CI 的截图基线，能把 visual comparisons 和 E2E 流程放在一起。

Storybook + Chromatic适合组件库和设计系统，每个 story 都可以成为组件状态的视觉规格。

Percy适合团队在 PR 中审查多宽度、多浏览器的视觉变化，并管理 baseline。

Applitools适合跨浏览器、动态内容较多、希望用视觉 AI 降低像素噪声的场景。

BackstopJS适合静态站、CMS、营销页等 URL/viewport 清单明确的自托管截图对比。

Cypress 插件适合已有 Cypress 流程的项目，把截图比较嵌入现有 E2E 或组件测试。

落地流程

列出关键页面：首页、Docs 列表、代表性文章、状态页、404。
列出关键视口：390px 手机、768px 平板、1280px 桌面。
冻结动态内容：时间戳、随机头像、动画、第三方 iframe、外部状态接口。
先跑源码检查和 DOM 断言，再生成桌面与移动端截图。
如果引入像素 diff，先从少量高风险页面开始，不要一口气截图所有状态。
定义基准更新规则：为什么更新、影响哪些页面、是否人工确认、是否写维护记录。
先 staging，再 live；发布后确认公开页面、gzip、安全头、真 404 和状态摘要。

这样做的意义

Stable Skin 和视觉门禁的收益，不只是少出视觉 bug。它让审美判断可复用，让 Agent 协作更可靠，让发布前检查更轻，让长期维护不再靠记忆。

对个人项目来说，这尤其重要。AI Agent 很擅长快速改页面，但也容易为了局部需求追加覆盖层。视觉门禁能把“别改坏已有页面”变成可执行约束，而不是一句笼统提醒。

一个网页“好看”之后，如果没有版本号、索引、发布脚本和回归检查保护，很快又会变成靠感觉维护。Stable Skin 的真正价值，是把满意状态变成未来可以继承的工程事实。

常见误区

只看首页，忽略二级页面、长文档、状态面板、移动端和 hash 直达位置。
把截图当装饰，只保存图片，却没有 DOM 断言、溢出检查和失败标准。
把阈值调得太宽，用“允许差异”掩盖真实视觉回退。
什么都截图，导致报告太吵，最后只能机械 approve。
把视觉测试当成功能测试替代品，忘了它应该和功能、可访问性、日志和发布 smoke test 配合。

参考资料

Playwright Visual comparisons：截图基线、比较与一致性注意事项。
Storybook Visual Testing Handbook：组件 story 如何进入自动视觉测试流程。
Chromatic Visual Tests：组件视觉测试、baseline 和 review 流程。
Percy Docs：snapshot、baseline、响应式宽度和 PR 审查。
BackstopJS：开源页面级视觉回归测试。
Cypress Visual Testing：在 Cypress 流程中接入视觉比较。
Applitools Docs：Visual AI、checkpoint 和 baseline 概念。

Next Action

给你的网页补一张视觉门禁表

不用先追求复杂截图 diff。先把关键页面、关键文本、移动端宽度和公开边界列清楚。

列出首页、列表页、文章页、状态页和 404。
给每页选 2 到 3 个必须出现的 DOM 文本或标记。
增加桌面、手机和目标区域截图。
写清楚基准更新规则：谁批准、为什么更新、影响哪里。

继续看：健康检查清单继续看：个人 Harness 指南

Copy Prompt

请帮我为一个静态网站设计视觉回归门禁。
网站类型：[个人笔记站 / 产品页 / 工具页]
关键页面：[首页、文档列表、文章页、状态页、404]
要求：先列检查项，再给出最低成本脚本方案。
边界：不上传私有数据，不读取密钥，不依赖人工肉眼作为唯一验收，不用过宽阈值掩盖真实视觉变化。
输出：检查表、工具建议、截图清单、DOM 断言、移动端溢出检查、发布前后 smoke test、基准更新规则。