在做前端这几年，我接手过一个内部代号叫impeccable的项目，目标只有一个：把设计稿里的界面，以像素级精度还原到浏览器里。听起来简单，但真做起来才发现，设计和代码之间隔着一条巨大的鸿沟——设计师眼里“完美”的界面，到了浏览器里总有那么几像素的偏差、几毫秒的闪烁、几种设备上的不一致。这个项目就是围绕“如何系统性地把 UI 做到无可挑剔”展开的，它既不是一个组件库，也不是一套样式框架，而是一整套从设计交付、代码实现到自动化校验的工作流方案。如果你正在为“还原度不高”“样式总是差一点”“换台设备就崩”这类问题头疼，这篇文章应该能给你不少可落地的思路。
我先把话说清楚：所谓 impeccable，不是追求玄学意义上的“好看”，而是把视觉还原变成一套可以被测量、被校验、被复现的工程流程。整个项目跑下来，我最大的感受是——像素级还原根本不是靠细心和耐心堆出来的，而是靠一套设计令牌体系外加视觉回归测试兜底。下面我把整个思路、踩过的坑、和最终沉淀下来的方法，一点一点拆开讲。
1. 这个项目到底在解决什么问题
1.1 设计和代码之间为什么总是有“像素级差距”
先聊一个很常见的场景：设计师在 Figma 里拖出一个卡片组件，间距 16px、圆角 12px、阴影是0px 4px 12px rgba(0,0,0,0.08)。前端拿到设计稿，看一眼就把代码写完了，写完一比对，发现卡片阴影边缘模糊度不对、内边距视觉上偏大、文字行高差了 2px。这种东西报给设计师，对方往往回复“差 2px 无所谓吧？”——但对追求 impeccable 的界面来说，每一处 2px 的偏差叠加起来，就是“看起来有点怪但说不清哪里怪”的元凶。
问题根源有三层。第一层是设计工具的渲染引擎和浏览器不同，Figma 的阴影、模糊、抗锯齿算法和 Chrome、Safari 并不完全一致，同样的参数两边画出来就是不一样。第二层是设计稿往往是静态的，而浏览器是实时布局的，文本换行、容器伸缩、字体加载都会让实际渲染结果偏离设计稿。第三层是人会偷懒，大多数前端拿到设计稿后习惯“目测+经验估算”，而不是逐个像素去量——这不是态度问题，是工作量问题，十几个页面、几百个组件，靠人眼一个个对过去根本不现实。
impeccable 项目想解决的，就是把这三层问题从“靠感觉”变成“靠系统”。核心手段只有两个：一是把设计稿里的视觉语言抽成设计令牌，让代码里不再出现“随手写的魔法数字”；二是引入视觉回归测试，用机器代替人眼去做像素级比对。这两件事做完，还原度问题就从“每次都要吵一架”变成了“跑一下测试就知道行不行”。
1.2 impeccable 项目的三个核心目标
这个项目最初定下的目标非常朴素，一共三条，后来一直没变过：
- 零魔法数字：组件代码里不允许出现未经令牌化的任意数值，所有颜色、间距、圆角、阴影、字号都必须来自设计令牌。
- 全页面覆盖：核心业务的每个页面都要有对应的视觉回归用例，任何人改了样式都能第一时间知道影响了哪些页面。
- 一人可维护：整套流程不依赖专门的质量团队，前端开发自己就能跑通从设计稿导出到自动化校验的全链路。
三条目标里，第一条是基础，第二条是保障，第三条是可持续性的关键。很多团队不是没有质量意识，而是搞了一套重流程之后没人愿意维护，最后沦为摆设。所以我在设计 impeccable 的时候，一直提醒自己：工具链必须轻、上手成本必须低，否则再完美的方案都活不过三个月。
1.3 适合谁看、能拿到什么
如果你属于下面这几类人，这篇文章应该对你有用：被“设计还原度”反复折磨的前端开发、想建立设计规范但不知道从何下手的团队负责人、以及所有好奇“像素级完美”到底能不能工程化实现的人。
我会把项目里沉淀下来的设计令牌结构、视觉回归测试的搭建方式、还有我踩过的那些坑（尤其是高清屏、字体渲染、亚像素这类刁钻问题）全部写出来。你看完不一定需要照搬我的整套方案，但至少能拿走几个马上能用的技巧，比如 0.5px 边框的正确写法、阴影参数怎么从 Figma 准确翻译到 CSS、以及视觉回归测试阈值到底该设多少。
2. 整体方案设计与工程架构
2.1 为什么不能靠“肉眼对齐”
在开始写代码之前，我先说说这个项目里最反直觉的一个决定：不鼓励前端开发用肉眼对齐设计稿。
我知道很多人觉得“我眼睛没问题的，看得出 1px 偏差”，但人眼在连续看十几个页面之后，疲劳带来的误差远比你想象的大。更关键的是，“肉眼对齐”是个不可复现的过程——你今天觉得对齐了，明天换个显示器、换个心情，可能又觉得没对齐。不可复现的事情，就不能作为工程质量的标准。
所以 impeccable 的第一原则是：凡是能被机器测量的，绝不让人类主观判断。具体来说，Figma 里每个元素的位置、尺寸、颜色、圆角、阴影，都应该能被精确读取并转成代码；代码跑起来之后，每个页面的截图又应该能和设计稿的截图做像素级比对。整个链路里，人只负责做决策（比如某个间距该用哪个令牌），不负责做测量。
2.2 设计令牌体系先行的理由
很多人会把设计令牌当成“一份颜色变量清单”，这是天大的误解。设计令牌的本质，是把设计决策和代码实现解耦的中间层。设计稿里出现的每一个具体数值，都应该能追溯到某个令牌上；反过来说，只要令牌不变，全局的视觉风格就不会乱。
在 impeccable 项目里，我搭了一套分层的令牌结构，大致长这样：
| 令牌层级 | 作用 | 示例 |
|---|---|---|
| 原始值 | 最底层的原子数值 | #1677FF、16px、0.8 |
| 基础令牌 | 给原始值赋予语义 | color.primary、spacing.md、opacity.disabled |
| 组件令牌 | 绑定到具体组件属性 | button.bg.primary、card.shadow.default |
| 语义令牌 | 表达状态和场景 | feedback.error、surface.raised |
这套结构的核心价值在于：当设计师决定把主色从#1677FF换成#4096FF时，前端只需要改一个原始值，所有用到主色的地方自动跟着变；而当某个组件的阴影需要单独调整时，又只需要改组件令牌，不影响其他组件。
这里我要强调一个实操中的关键点：基础令牌和组件令牌必须分开。很多团队只定义到基础令牌，结果某个按钮要加一个特殊阴影，就临时写了个box-shadow: 0 2px 8px rgba(0,0,0,0.15)塞进组件里，过两周就没人记得这个阴影是哪来的了。有了组件令牌这一层，任何视觉属性都能找到出处，这才能叫“零魔法数字”。
2.3 从设计稿到代码的标准化交付链路
令牌体系解决了“代码怎么写”的问题，但还差一环：设计稿里的数值怎么高效、准确地变成令牌？我在项目里定了一条标准的交付链路，前端、设计师各负责一段：
- 设计师在 Figma 里把样式规则整理好，组件库的命名和前端令牌命名保持一一对应。
- 前端用 Figma 的 API 或者开发模式直接读取设计稿的属性值，而不是肉眼去量。
- 读取到的数值对照令牌表归类，能对上的直接用令牌，对不上的提交给设计师确认是漏了还是故意的。
- 确认后的新数值录入令牌表，再进入组件代码。
这条链路看起来繁琐，但好处非常明显：每一笔样式都有据可查，不会再出现“你照着设计稿写，他说你写错了，回去一看设计稿确实改了”的扯皮情况。后面视觉回归测试的基准截图，也全部来自这条链路产出的最终设计稿快照，保证大家看的永远是同一份“标准答案”。
3. 核心实现细节与实操要点
3.1 间距与尺寸：从 px 到计算表达式的统一
间距是 UI 里最容易“差一点”的地方，也是 impeccable 项目里最先规范化的维度。我要求所有间距必须从一套固定的间距刻度表里取，而不是随手写数值。Figma 里的auto layout的 gap、padding、margin，全部映射到令牌表，比如：
:root { --space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px; --space-5: 20px; --space-6: 24px; --space-8: 32px; --space-10: 40px; }但这里有个容易被忽略的细节：设计稿里的间距是静态的，而真实界面的间距往往需要响应式。同样的 16px，在 375px 宽的手机和 1440px 宽的桌面上，视觉感受完全不同。为了兼顾“像素级还原”和“响应式适配”，我的做法是：基础间距用 px 保证绝对还原，大面积留白和间距用 CSS 变量配合媒体查询切换。
这个决策背后的逻辑是：小间距（4~24px）决定了元素内部的紧凑度和层次感，必须保持绝对精确；大间距（32px 以上）更多承担页面节奏的作用，可以随视口宽度做阶梯式变化。实践证明，这套“小间距锁定、大间距响应”的策略，既让设计还原度肉眼可见地提升，又避免了在大屏上页面看起来过于松散的问题。
实施时还有个很实用的技巧：间距尽量用 margin 而不是用 gap 的场合要想清楚。Flexbox 的 gap 在布局上很省心，但如果你需要做视觉回归测试，gap 产生的间距在截图比对时不容易被单独检查；相反，margin 可以针对特定组件设置测试断言。当然这不是说不能用 gap，而是提醒你在设计令牌层面就想好间距归谁管，别混着用。
3.2 字体与排版：行高、字距、渲染差异
排版是另一个“差之毫厘谬以千里”的重灾区。设计师在 Figma 里设置font-size: 14px; line-height: 22px，前端在 CSS 里也写了同样的值，但实际渲染出来的文字垂直位置就是不一样。
问题出在两个地方。第一，line-height 的计算方式。Figma 里设置line-height: 22px是固定值，而 CSS 里如果你写line-height: 1.57，浏览器会根据 font-size 计算出实际行高，再经过字体自身的 ascender/descender 比例分配到行内，最后文字的 baseline 位置会因为字体不同而偏移。第二，字体渲染引擎。macOS 的 Core Text 和 Windows 的 DirectWrite 对同一字体的 hinting、抗锯齿策略完全不同，同一套 CSS 在两套系统上渲染结果就是不一样。
针对这个问题，我在 impeccable 项目里定了几条硬性规则：
- 行高一律使用固定 px 值的令牌，不写无单位数值，确保和设计稿一致。
- 字体栈必须显式定义，并且要把 fallback 字体也纳入测试基线，不能只测最优字体。
- 用
text-rendering: optimizeLegibility的地方要谨慎，这个属性在部分字体上会触发 kerning 调整，导致字距变化。
字体加载的影响也很大。默认情况下，浏览器会用 fallback 字体先渲染文字，等自定义字体加载完再换，这一瞬间的排版变化就是著名的 FOIT（Flash of Invisible Text）或 FOUT（Flash of Unstyled Text）。我在项目里用font-display: swap尽量减小对用户的影响，但在视觉回归测试时，必须等字体加载完再截图，否则每次跑测试结果都不一样。
3.3 阴影、圆角、渐变与毛玻璃特效实现
很多前端以为“照着设计稿参数写 CSS”就能还原，但在阴影和模糊这两个属性上，Figma 和浏览器的参数映射是最容易翻车的。
Figma 里一个阴影由x, y, blur, spread, color组成，CSS 的box-shadow语法几乎一一对应，这个还算好办。真正的坑在于Figma 的“图层模糊”（Layer Blur）和 CSS 的filter: blur()渲染算法不一致，同样的blur: 8px，Figma 的模糊半径折算到 CSS 可能需要 16px 甚至更多，具体系数和设计工具的实现有关。我在实际项目中验证下来，Figma 的图层模糊转换到 CSS 大约是blur值 × 2，但这只是个经验系数，不同团队最好在项目初期做一组对照样本，先把换算关系校准了再大规模铺开。
毛玻璃（backdrop-filter）是更麻烦的存在。这个 CSS 属性的性能和渲染差异极大，尤其在低端安卓机和部分 Windows 浏览器上，backdrop-filter: blur(20px)可能导致整块区域出现明显的锯齿和色偏。我的建议是：能用纯色加透明度模拟的，就不要用 backdrop-filter；必须用的时候，要准备降级方案。比如模态框的背景，Figma 里是个毛玻璃效果，可以拆成“半透明背景 + 顶部 1px 高光边”来模拟，视觉上很接近，但性能和兼容性都更好。
圆角也有讲究。Figma 的corner radius直接对应 CSS 的border-radius，但如果是“只有左上角有圆角”的情况，Figma 导出到 CSS 时会变成border-top-left-radius，这个转换没问题；问题往往出在border-radius和overflow: hidden的组合上——圆角容器内的子元素如果没有同样设置圆角，在某些浏览器上会溢出露出直角，所以容器和内部滚动区域要一起处理圆角。
3.4 响应式适配下的“完美”定义
设计稿通常只存在几个固定断点宽度下，但用户的屏幕是连续变化的。impeccable 项目里我遇到的最纠结的问题就是：响应式布局下，什么才算“像素级完美”？
我的答案是分层的：在目标断点（如 375、768、1440）上，必须严格还原设计稿；在断点之间，允许元素按布局规则自然伸缩，但不允许出现意外的重叠、截断、错位。换句话说，impeccable 对响应式的要求是“关键帧精确，过渡帧合理”。
这个定义有两个实际好处。一是视觉回归测试可以在固定断点下跑，结果稳定可预期；二是代码层面不需要为每个宽度都写死样式，只用 CSS Grid 和 Flexbox 的规则保证过渡帧的表现即可。实操中，我主要用三样工具控制过渡帧：
clamp()函数控制字号和间距的连续变化范围；minmax()和auto-fit控制网格列数在断点间的自动调整；- 容器查询（Container Query）让组件根据自身可用空间而非视口宽度来调整布局。
容器查询尤其好用，比如一个卡片组件，在侧边栏里和主内容区里宽度完全不同，靠视口断点很难写样式，用容器查询就能让组件自己适配。这套组合下来，“完美”不再是某个宽度下的静态快照，而是整个区间内的稳定表现。
4. 视觉回归测试：把“完美”变成可校验的指标
4.1 用 Playwright 截图比对搭建回归管线
代码写得再规范，也防不住某天有人不小心改了个全局变量，导致所有按钮的间距变了 4px。视觉回归测试就是用来兜底的。我在 impeccable 项目里选了 Playwright 来做这件事，理由很直接：它既可以用 Test Runner 写断言，也可以单独跑截图，生态完整还不重。
管线大致是这样的：
- 启动一个测试用的静态服务，加载编译后的前端产物。
- Playwright 按路由列表逐页访问，等网络空闲、字体加载完成后截图。
- 截图和存放在基线目录里的基准图做像素比对。
- 差异超过阈值的页面标记为失败，并生成一张带高亮差异区域的对比图。
核心实现用一段简单的脚本就能跑起来，类似这样：
const { test, expect } = require('@playwright/test'); test('homepage visual regression', async ({ page }) => { await page.goto('http://localhost:3000/', { waitUntil: 'networkidle' }); await page.evaluate(() => document.fonts.ready); const shot = await page.screenshot({ fullPage: true }); expect(shot).toMatchSnapshot('homepage.png', { maxDiffPixelRatio: 0.001 }); });maxDiffPixelRatio这个参数我后面会细讲，这里先说截图的两个关键设置：一是要等document.fonts.ready，不然字体没加载完，文字渲染全乱套；二是要关掉动画和过渡，否则截图时机稍微差几十毫秒，结果就千差万别。我在测试初始化里给所有元素加了transition: none !important; animation: none !important;，从源头掐掉不确定性。
4.2 阈值设置与像素级对比的取舍
一开始我把视觉回归的阈值设成 0，想着“既然是 impeccable，就不能容许一个像素差异”。结果跑了一轮测试，全是失败——不是代码错了，而是抗锯齿渲染在不同平台上根本做不到像素一致。同样的页面，在 macOS 的 Chrome 和 Windows 的 Chrome 上截图，字体的边缘像素差异能覆盖大量检查点。
后来我学乖了，把策略改成“区域敏感度分级”。核心区域（比如按钮、卡片、表单控件）用严格的阈值，因为像maxDiffPixelRatio: 0.0005这种；大背景、空白区域可以稍微放宽，到0.001左右。另外，在对比前把所有颜色做一次量化处理，把抗锯齿造成的半透明边缘像素差值压到最小。
这里有个非常实用的技巧：不要只比对整张页面截图，要把页面按组件边界切块后逐一比对。整页比对的缺点是，一个组件错位 4px，几百个像素点差异可能被阈值吞掉，而且报错后你还得猜是哪里出了问题。按组件切块比对的话，每个组件独立诊断，出问题直接定位。这个切块用 Playwright 的locator.screenshot()就能实现，成本很低但收益非常大。
4.3 把测试接入 CI 的实践经验
视觉回归测试如果不跑在 CI 上，价值就少了一大半。本地跑测试，开发者总有各种理由“这次改动不影响样式，不跑了”，但 CI 不会放水。我把这套 Playwright 测试接进流水线之后，总结了几个实践要点：
- 基线图不要存在 Git 里，而是存在独立的存储里（比如 S3 或 OSS），否则每次 CR 都带着几十张图片，The review experience 会非常痛苦。
- 每次 CI 运行都生成一次基线快照，但只在可比较的提交上更新基线。我在任务流里设了一个手动触发的
update-snapshots任务，只有明确确认视觉更新是预期的人才能更新基线，普通 push 触发的 CI 只校验。 - 差异报告用 HTML 形式产出，包含失败截图、基线截图、以及一张把差异区域标红的对比图。任何人打开报告一眼就能看出问题，不需要会读命令行数字。
这套流程跑了一个季度之后，组里的同事态度发生了很有意思的变化。最初大家觉得视觉回归是“找茬的”，天天报一堆和功能无关的失败；后来大家发现，只要是视觉回归报出来的问题，几乎都对应真实用户会感知到的瑕疵——比如某个按钮在 hover 状态下多了一个奇怪的阴影，某个弹窗在不同分辨率下出现了 1px 的错位。渐渐地，大家开始主动在开发完成后跑一遍视觉回归再提测，而不是等 CI 报红了再回来改。
5. 常见问题与排查技巧实录
5.1 高清屏下 0.5px 边框的实现与适配
“1px 边框在高清屏上看起来太粗了，设计师要求 0.5px。”这是移动端开发们最熟悉的需求之一，也是 impeccable 项目里不得不解决的问题。设计稿在 2x 或 3x 分辨率下，1px 的物理像素等于 0.5px 的逻辑像素，但 CSS 里能不能真的写出 0.5px，取决于浏览器和设备。
比较稳妥的方案是使用transform: scaleY(0.5)配合一个高度为 1px 的伪元素：
.hairline { position: relative; } .hairline::after { content: ''; position: absolute; left: 0; right: 0; bottom: 0; height: 1px; background: rgba(0, 0, 0, 0.12); transform: scaleY(0.5); transform-origin: 50% 100%; }这个方案的好处是不依赖媒体查询，不管设备 DPR 是 1、2 还是 3，都能稳定渲染出 0.5px 的视觉效果。坏处是用了伪元素和 transform，如果你觉得“为了一条线写这么多代码不值得”，那也可以用background: linear-gradient的渐变模拟法，但那个方法对圆角容器无效，适用性差一些。
这里必须提醒一个细节：0.5px 边框在低 DPR 设备上会显示成 1px，这是正常的，因为物理像素限制决定了它画不出更细的线。所以视觉回归测试里，这类元素要在支持 0.5px 的测试设备上验证，不能拿一台 DPR=1 的显示器来做基准，否则测试结果和真实用户看到的是两码事。
5.2 抗锯齿与亚像素渲染导致的差异
前面提到抗锯齿会导致像素级对比失败，这里展开讲一个我排查了很久的问题：同一套代码，同一台 Mac，Safari 和 Chrome 渲染出来的文字粗细看起来不一样。
这个问题的根子在两个浏览器对字体平滑（font smoothing）的处理机制不同。Chrome 在 macOS 上默认使用亚像素抗锯齿，Safari 则更倾向于灰度抗锯齿，结果是 Chrome 里文字看起来更“锐利”，Safari 里更“柔和”。这不是你 CSS 的问题，是平台渲染引擎的差异。
针对这个问题，视觉回归测试要保证始终在同一个浏览器引擎里跑。我在 impeccable 项目里的做法是：以 Chrome 为唯一视觉基准平台，如果设计师在 Safari 里发现风格问题，单独走人工检查流程，而不是试图让两个浏览器的截图完全一致——那个成本高到不值得。跨浏览器的一致性应该靠语义化令牌和布局规范来保证，而不是靠像素硬碰。
另一个亚像素渲染的经典坑是背景色叠加导致的色差。当一个半透明元素叠在另一层背景上时，不同浏览器对中间色的计算方式偶尔会有差异，导致最终颜色和设计稿对不上。处理办法是尽量把颜色值改为不透明的最终色，或者统一用 CSS Color 函数规范地计算混合，避免浏览器自带的隐式混合路径。
5.3 字体加载闪烁与布局偏移
视觉回归测试最讨厌的“假失败”就是字体导致的布局偏移：第一次跑测试，字体还没加载完，页面用的是 fallback 字体，文字宽度不同、行高不同，整个布局都偏了；等字体加载完再跑一遍，又正常了。
解决思路是给字体定义明确的加载策略。我在项目里做了两件事：
第一，在 CSS 里用font-display: optional而不是swap。swap会让 fallback 字体先显示，自定义字体加载后替换，这期间必然产生两次布局；optional则允许浏览器在字体加载太慢时直接放弃自定义字体，从源头避免闪烁。图标字体和正文建议用swap，因为图标缺失会产生乱码；但正文大段的文本用optional更稳。
第二，在 Playwright 截图前等字体加载完成。除了document.fonts.ready，我还会额外等待document.fonts.check('16px "Inter"')返回 true，确保目标字体已经可用。这一步对测试稳定性至关重要。
还有个稍微隐蔽的问题：字体子集化。如果自定义字体只包含部分字符，而测试页面上恰好有字符不在子集里，浏览器会触发第二次字体请求，布局再一次闪变。这在线上可能只是慢几十毫秒，但在视觉回归测试里就是一次“灵异失败”。排查方法是看 Network 面板里字体文件的请求次数和大小，如果字体文件超过 100KB，建议做子集化处理。
5.4 常见问题速查表
为了让你以后排查方便，我把项目中最常遇到的问题整理成了一张速查表：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 阴影模糊度不一致 | Figma 图层模糊与 CSS blur 算法不同 | 建立阴影换算系数，统一映射到令牌 |
| 文字垂直位置偏移 | line-height 计算方式不一致 | 行高统一使用固定 px 令牌 |
| 0.5px 线在某些设备上消失 | 低 DPR 设备无法渲染细线 | 结合 DPR 媒体查询做降级 |
| 截图对比大面积失败 | 字体未加载完成 | 等document.fonts.ready再截图 |
| 渐变颜色发灰 | 半透明叠加路径不一致 | 使用最终实色值代替半透明叠加 |
| 动画导致截图时机不稳定 | transition/animation 干扰 | 测试时全局禁用动画 |
| 同一页面不同浏览器颜色差 | 色彩管理路径不同 | 固定基准浏览器做像素校验 |
| 圆角容器边缘出现直角 | overflow 未覆盖子元素 | 子元素同步设置圆角 |
表格里的每一条，都是我在真实项目里踩过的坑，不是纸上谈兵。尤其是“渐变颜色发灰”这一条，我见过太多同事对着设计稿调半天，最后发现是半透明叠加的问题，浪费了大量时间。
6. 最后再分享几个让这套流程更顺手的经验
项目做到后期，我渐渐意识到，impeccable 其实不只是一个技术项目，更是一个改变协作方式的试验。设计师把样式规则做进令牌库里，前端把实现细节交给自动校验，两边都从“互相猜对方怎么想”变成了“看同一份数据说话”。这个转变带来的不只是还原度的提升，更是团队沟通成本的下降。
有一件事我想单独强调：视觉回归测试的基线图一定要定期人工审查。不是每次跑完 CI 都审查，而是每个月抽出半天时间，把近期的基线图变化整体过一遍。因为机器只会告诉你“有没有变”，但不会告诉你“变好看了还是变难看了”。有些改动通过了阈值校验，但视觉质量其实下降了——这种问题只能靠人眼看。把人工审查和自动校验结合起来，才算一个完整的质量闭环。
如果你打算在自己的项目里尝试这套思路，我建议不要一上来就追求全量覆盖。先选三五个核心页面，把设计令牌和视觉回归管线跑通，感受一下“机器替我盯像素”是什么体验，再逐步扩大范围。步子太大的话，前期维护成本可能会让你怀疑这套方法的价值，但坚持过最初的磨合期，后面就会越来越顺。我也是从一次只接一个模块开始，慢慢把整个产品都纳入 impeccable 的覆盖范围，最后回头看，这个决定可能是这个项目里最值得的一步。
