30秒速读：做网页或做设计系统时，两个颜色摆在一起到底够不够清晰，不能只凭眼睛感觉。get-contrast 就是把这件事变成可计算、可进流程的工具：输入前景色与背景色，输出对比度比值与 WCAG 评分，让颜色检查能在代码、命令行和 AI 助手流程里自动跑。本篇讲清它提供哪几种接入方式，以及把它接进项目前要先定好的几件事。
get-contrast 是什么，能解决什么问题
get-contrast 是一款用 JavaScript 实现的颜色对比度工具，定位非常窄：只算两种颜色之间的对比度比例，并给出对应的 WCAG 分数，帮助开发者做可访问性检查。它不做整站扫描，不生成无障碍报告，不替你改配色，它的价值在于把一个原本靠肉眼判断的环节，变成可以写进测试、写进构建、写进脚本的确定性计算。
这个窄定位恰恰是它适合进流程的原因。设计走查时人会疲劳、会妥协，同一组颜色今天觉得能看、明天换个屏幕又觉得糊；一旦对比度变成数字，团队就能在代码里定一条通过线，不达标直接拦下来，讨论也从感觉之争变成数字之争。
项目信息
| 项目名称 | get-contrast |
| 定位 | 颜色对比度计算与 WCAG 评分 |
| 实现语言 | JavaScript |
| 许可证 | MIT |
| 提供形态 | 代码包、命令行 contrast 命令、MCP 服务器、AI 助手技能 |
| 开发与持续集成环境 | Bun，开发与 CI 跑同一组步骤 |
| 版本策略 | v3 行为由兼容性测试套件锁定；预发布走 next 通道 |
| 仓库结构 | 多包布局，命令行实现独立放在 packages/cli，构建时复制进发布包 |
先选哪一种接入方式
结论先行：日常开发集成用已发布的代码包；临时抽查一两个颜色用命令行；要让 AI 助手在流程里自己判断颜色，用 MCP 服务器或配套技能。三种方式算的是同一套逻辑，差别只在谁来调用它。
| 接入方式 | 适合场景 | 推荐人群 |
| 已发布的代码包 | 写进组件库、设计令牌校验、自动化测试 | 前端与设计系统开发者 |
| 命令行 contrast | 临时抽查、脚本批量检查、CI 里跑一遍 | 想快速得到结果的人 |
| MCP 服务器与助手技能 | AI 助手流程里自动判断颜色可用性 | 在用 AI 助手做界面工作的团队 |
| next 预发布通道 | 提前试新行为、给上游反馈 | 能接受变动、愿意跟进文档的人 |
新手最容易踩的坑是把四种方式混着用：代码里引稳定版，命令行却装了 next，助手那边又跑了另一套，结果同一组颜色在三个地方得出三个结论。接入之前先定好全团队统一的通道，之后只在升级时一起动。
上手指南：按三条线接入
- 代码接入：按包级说明文档引入已发布的包，传入前景色与背景色，拿到对比度比值与 WCAG 评分，再按自己项目的通过线做判断。具体的引入方式与输入格式以包级说明为准，仓库根目录的说明本身也明确指向包级文档。
- 命令行抽查：命令行工具随包一起发布，按命令行文档调用 contrast 命令，对一对颜色做快速检查，适合在改配色时随手验证，不用为一次抽查专门写脚本。
- 助手流程接入：按 MCP 与助手技能文档配置服务器与技能，让助手在生成或评审界面时能直接调用对比度计算，而不是凭感觉说这个配色大概可以。
- 跑通验证：接入完成后，用一组已知结果的颜色对跑一遍，确认输出的比值与评分符合预期，再把这组颜色固定成项目的回归用例，以后升级先跑它。
接进项目前先定的 5 个设置
- 统一发布通道：全团队定死用稳定版还是 next 预发布。预发布按项目说明走手动流程，版本号有格式校验，尝鲜可以，但不要让一半人用稳定版、一半人用 next。
- 定好通过线：先定项目采用哪个 WCAG 等级，再定这条线对应的最低比值，写进校验脚本或测试里。没有通过线的对比度计算只是数字展示，拦不住任何一次妥协。
- 锁定 v3 行为基线：据项目说明，v3 的行为由兼容性测试套件锁定。升级或换版本前，先跑一遍兼容性套件，确认同一组颜色的输出没有悄悄变过，再合并升级。
- 开发与 CI 用同一组步骤：项目开发与持续集成跑的是同一组构建、测试与类型检查步骤，团队本地也按这组步骤来，避免本地能过、CI 挂掉的经典扯皮。
- 区分计算与审计：把 get-contrast 的位置写清楚，它只负责对比度这一项。键盘操作、语义结构、焦点顺序这些检查，另找对应的工具补，不要指望一个对比度工具背下整份无障碍清单。
注意事项与常见问题
- 它能代替完整的无障碍审计吗？不能。它只回答两个颜色之间够不够清晰，不回答页面能不能用。把它当作审计清单里的一项，而不是审计本身。
- 支持哪些颜色格式？项目公开摘要没有逐一列出，具体的输入格式与校验规则以包级说明和源码为准。接入前先拿项目里真实在用的颜色写法跑一遍，别假设所有写法都被接受。
- 没有 Bun 能用吗？要区分两件事：开发这个仓库、跑它的持续集成需要 Bun；使用已发布的包时，按包级文档走即可。团队如果不装 Bun，优先用已发布包，别为了用一个对比度工具去改整条开发环境。
- 升级会不会悄悄改结果？据项目说明，v3 行为有兼容性套件兜底，但这不等于所有未来版本都不变。每次升级前都跑一遍自己固定的回归颜色对，输出变了就先停下来看文档，而不是直接放行。
- AI 助手用它靠谱吗？靠谱的前提是调用链路配对了。MCP 服务器与助手技能各有自己的文档，按文档配好再让助手在真实任务里试，试的过程中抽查几次输出，确认助手拿到的是计算结果，而不是自己编的比值。
适合谁，不适合谁
适合的人是需要在流程里固化颜色判断的人：维护设计系统的前端团队、给组件库写测试的人、把无障碍检查放进 CI 的团队，以及希望 AI 助手在出界面时顺带把对比度算清楚的人。对他们来说，一个小而确定的计算工具，比一个大而含糊的审计平台更好落地。
不适合的场景同样明确：需要整站无障碍审计报告、需要自动修复配色、需要色彩管理或跨设备色彩校准的团队，这个工具都给不了。它的取舍很干净，只做对比度这一件事，做深不做宽；接受这个边界再用，才不会用完觉得它不够用。
GitHub 国内访问较慢，如打不开可多刷新几次
关注「软件教程管家」
回复软件名即取即下：网盘下载链接 + 提取码，一步直达，不用再跳转。
本站资源仅供个人学习交流，请勿用于商业用途。软件与资料版权归原作者所有；如有侵权，请通过公众号「软件教程管家」联系我们，我们将在 24 小时内下架处理。查看免责声明 ›
