⚠️ 这篇是写给只会用聊天型大模型、最近开始想跟进新工具的普通人的。你刚刷到 ChromeDevTools / chrome-devtools-mcp，也就是能把浏览器现场信息整理给模型的那套工具，本来准备顺手划走，又怕自己错过了真正会影响下一步判断的那一点。这里最容易做错的判断，就是把它当成“代你点网页、填表单”的省事工具；如果这里判断错了，后面花错的不是几下点击，而是时间、预算和注意力。
真正值钱的不是点击，是把瀑布图变成上下文。[C002] 你可以先把瀑布图理解成一张“哪个请求先来、哪个最慢、时间卡在哪”的图。更隐性的代价，是你会一直围着表面热闹转，却看不到它真正改变的那一步：把请求先后、页面报错、内存占用这些页面运行时留下来的证据，整理成模型能直接用的判断。
我一开始也差点按错题，因为它表面上太像“自动操作浏览器”。后来翻说明文档才停住：首页把“稳定自动化、深入调试、性能分析”并列写成核心能力，这已经说明它不是单纯的网页代点器。[C003] 再看工具列表就更明显了：性能 3 个、网络 2 个、调试 8 个、内存 11 个。[C004] 这 24 个工具，盯的是请求顺序、控制台报错、内存压力这些现场证据，不是在陪你重演一遍人工操作。
设计原则里还有一句更关键：它优先把结果先翻译成人能看懂的话，再交给模型，比如直接告诉你页面最大内容区域出来得够不够快（LCP），而不是塞给它 5 万行原始数据。[C005] 这也是为什么我会改判断。一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。
所以这套工具更适合两类人：已经在查网页为什么慢、为什么报错，想让模型少猜一点的人；以及只想先拿到一个不容易跑偏的判断、不想再学一轮黑话的人。不太适合只想找“自动点一下”工具的人。要是你身边也有人刚开始跟进新工具，最容易把“会点按钮”当成重点，这篇可以直接转给他。
🤔 你现在最想先避开的，是哪一个坑？