⚠️ 会用 GPT、Claude 聊天，又开始想把几个 AI 工具串起来省事的人，最容易吃的亏，不是模型不够强，而是还在手动搬运上下文。你一会儿在浏览器搜资料，一会儿回聊天框补背景，一会儿再回编辑器改几行代码，看起来每次只多花几分钟，最后却很容易多一轮返工。AI 工具真正开始抢的，不只是代码活，而是你来回切换的那些碎时间。
我一开始也把浏览器兼容数据库项目 simonw/browser-compat-db [C001] 当成“把常见兼容性网页表换个壳”的东西。后来才发现，真正值钱的不是壳，而是问题被反过来问了：兼容性不是网页表格，是该被SQL审问的数据。[C002] 说白了，就是别再一页页翻表，而是像查数据库一样，直接筛条件。
这一步要是没看懂，代价不只是继续手动刷表。显性的代价，是你本来想少开几个窗口，结果还是得在浏览器、聊天框、编辑器之间来回搬运；隐性的代价，是你会一直把兼容性当成“查单点答案”，看不到这个库真正改变的是“批量排雷”的方式。很多人以为自己缺的是更强模型，其实缺的是少切几个窗口。
说明文档（README）2026-06-24 的数据快照给了很硬的支点：库里有 19,834 个功能项、260,715 条支持记录，还拆成几张规范化数据表，并且给了可直接查询的界面。[C003] 重点不是数字大，而是它已经不是给你一页页翻的表，而是能直接问条件的数据。另一边，MDN 也把浏览器兼容数据定义成“机器可读的兼容性数据”，本来就是给程序查询的，不只是给人眼看表。[C004]
所以我的判断很简单：如果你现在查兼容性，已经不是偶尔确认 1 个接口，而是要一次排一串兼容雷，这类库值得直接放进你的流程；如果你只是偶尔确认一个接口能不能用，继续看网页表反而更快。想知道这次到底是不是只换了个壳，就先记住这一句：别再一页页刷表，先把兼容性当成可查询的数据。也可以把这篇转给那个总在浏览器、聊天框、编辑器之间来回切的人，他大概率一眼就懂。
🤔 你现在最想先避开的，是哪一个坑？