AI 能写 CSS 了，Chrome DevTools 现在能告诉你浏览器为何不买账
（本段为标题，正文随后）
Google 最新的 DevTools 更新让 AI 编程助手能更清楚地看到 CSS 的层叠（cascade）过程。这对前端开发者来说是个好消息，但“找到冲突的样式”和“知道怎么修”之间，还是有区别的。
编辑说明：本文主要借助 ChatGPT 基于公开链接来源起草，然后由 The Release Desk 审核通过。文中的调试流程仅为示意；我们没有实际测试工具，也没有做性能基准测试。
前端开发有一种特别的挫败感：改了一个 CSS 属性，刷新页面，然后眼睁睁看着什么也没发生。代码看起来是对的，浏览器却无动于衷。可能是另一个选择器的优先级更高，可能涉及某个媒体查询，也可能是某个组件库认定你那个“完全合理”的按钮样式只是一个建议。
人类开发者知道从哪里开始查：打开 Chrome DevTools，检查元素，搞清楚到底是哪条 CSS 规则在起作用。AI 编程助手早就有浏览器检查能力了。现在，它们有了更直接的方式来调查这些令人抓狂的小谜团背后的 CSS 规则。这可能带来实质性的改变。
到底新在哪？
10 月 20 日，Google 重点介绍了一个为 agent 准备的 Chrome DevTools 工具包的新增功能：一个叫 get_css_styles 的工具。它属于开源的 Chrome DevTools MCP server，这个服务器把兼容的 AI 编程助手连接到正在运行的 Chrome 浏览器。
MCP 是 Model Context Protocol（模型上下文协议）的缩写。可以把它理解为一种让 AI 助手调用外部工具的方式，而不是完全依赖你粘贴到对话里的信息。
Chrome 的 MCP server 本来就支持一些有用的调试操作，比如查看页面内容、截图、读取控制台消息、检查网络请求。这个 CSS 工具则增加了一项更专门的能力。
根据 Google 的文档，get_css_styles 可以暴露以下信息：匹配到的和继承的样式规则、被覆盖的声明、伪元素、动画，以及 CSS at-rules（@ 规则）。
它的输出还支持分页获取，不必把所有匹配到的规则一股脑塞进一个巨大的响应里。有一个时间线细节需要澄清：这个功能早在 2026 年 9 月 23 日发布的 v1.10.0 版本中就已经出现。Google 在 10 月 20 日的 DevTools 汇总中让它重新获得关注，但它并非当天全新发布。这个区别很重要——科技新闻里“时间穿越”式的乌龙已经够多了。
为什么这比又一个 AI 编码功能更重要
先想想 CSS 调试是怎么运作的。你可能写了这样一条规则：.checkout-button { background: blue; }，期望结账按钮变成蓝色。但在别处，像 .dialog button 这样的选择器可能把背景设成了灰色。如果两个选择器都作用于同一个按钮，并且它们的声明在层叠来源、重要性和层上相同，那么第二个选择器的特异性更高。浏览器会采用灰色。
现在想象一下问 AI 助手：“为什么我的结账按钮还是灰色？帮我修好。”一个只从源代码推理的助手可能会找错文件、建议再加一条 CSS 覆盖，或者推荐直接甩个 !important 上去。有时候这能奏效，有时候只是把同一个问题变得更复杂。
而如果能访问实时浏览器的样式信息，agent 就可以直接检查相关元素，查看相互竞争的规则。官方工具文档描述的输出能够识别生效和被覆盖的声明，包含来源位置，并暴露相关的层叠信息。这比猜测该由哪个样式表背锅有用多了。
在更大的前端应用中，这种差异会更有意思——样式可能取决于响应式布局、组件状态、生成的类名、继承属性以及第三方库。浏览器知道哪些规则参与了最终结果。让 agent 获取这些证据，是一个合理的改进。
AI 调试会话可能是什么样
设想一个 React 应用，里面有个模态框，模态框里有个按钮死活不肯用上预期的背景色。
配置好兼容的编码代理后，开发者可以按这样的流程操作：在 Chrome 中打开应用，代理通过 DevTools MCP 服务器接入，定位到相关元素——代理借助页面快照找到按钮并拿到它的元素标识，检查该元素的 CSS：对目标元素调用 get_css_styles，查看匹配的、继承的、被覆盖的规则；然后提出针对性的修改——不是急着再加一条覆盖规则，而是先找出冲突最可能的源头；最后验证结果，在应用修改后重新检查页面。这是基于已有文档工具给出的示例流程，并非本文所做的基准测试或实际操练。
真正有价值的改进在于反馈回路。代理不再只是生成代码、然后指望浏览器赏脸，而是有了一条更清晰的路径：查看证据、做出修改、检查结果。这确实有用，但也不是什么魔法。
问题在于：看到问题不等于解决问题
CSS 难，并不是因为开发者看不到哪个属性最终生效。难的地方往往在于决定该改哪条规则、又不弄坏别的东西。假设一个按钮的样式被某条共享组件规则覆盖了：
- 代理应该改那条共享规则吗？
- 新加一个组件专用的 class？
- 调整层叠层（cascade layer）？
- 还是保留现有行为，因为其他页面依赖它？
浏览器检查工具能帮忙解释“发生了什么”，但它无法自动判断设计意图或架构应该是什么样。
实现层面也有坑。10 月 6 日提交的一个 GitHub issue 指出，在某些 Shadow DOM 场景下，get_css_styles 会误标负责继承规则的祖先元素。报告附带了复现细节，不过其结论本文未做独立验证。换句话说，检查工具本身也可能有 bug。
还有隐私方面的考虑。Google 的仓库文档提醒：已连接的 MCP 客户端可以访问浏览器内容，并可能检查甚至修改数据。
在把 AI 代理接入敏感会话或应用之前，开发者得先搞清楚这些权限意味着什么。而且，这一切并不能证明编码代理（coding agent）现在修 CSS bug 就更快、更准。要下这个结论，得在真实项目里做对照测试。
前端开发者该关心这件事吗？该，尤其是你已经在工作流里用上编码代理的时候。这个功能并不意味着你要放弃手动查 DevTools。如果只是个小样式问题，自己打开 Styles 面板可能还是最快的办法。但碰上更大的调试任务，让助手直接读到匹配规则和层叠结果，对话就能聊得更具体：你不用再让 AI 猜「按钮为什么长歪了」，而是让它去检查按钮、找出互相冲突的声明、解释可能的原因，再给出一个你能审阅的修复方案。
最后这点很关键：一定要审。在一个视口里看着漂亮，不代表改动在别的屏幕尺寸、交互状态下、或者应用的其他地方也成立。
AI 更有用的角色，不是变成一台停不下来的 CSS 覆盖规则生成器，而是帮开发者用更好的证据去查问题。