Cursor为何用CSS选择器更智能？

如果你在上周那场对比评测中稍微留意过，会发现一个有趣的细节——当三个AI助手面对同样的爬虫任务时，只有Cursor二话不说甩出了select和select_one，而另两位还在固执地翻find_all和find的旧账。这看起来像是个偶然，但背后其实藏着Cusor在代码生成哲学上的一个关键偏执：它更倾向于将HTML视作一棵严谨的CSS树，而非一串扁平的标签列表。 说白了，它是真的在用“现代浏览器渲染页面的方式”来理解DOM，而不是靠记忆堆砌出来的旧版API套话。

为什么CSS选择器“更智能”？

离人类直觉更近一步

传统find_all('tr', class_='athing')本质上是在做字符串匹配——你告诉它“给我所有标签名等于tr且class属性包含athing的节点”。这其实是在跟HTML的底层实现对话。而select('tr.athing')直接翻译成自然语言就是“所有class为athing的tr行”，跟你在Chrome开发者工具里敲出的表达式几乎一模一样。对于开发者来说，可读性的提升不是一星半点——尤其是在调试时，你能直接在浏览器控制台验证$$('tr.athing')的输出，然后原封不动地贴回编辑器。Cursor显然把这种“所见即所得”的亲密感视为第一优先级。

CSS选择器本身就是一门成熟语言

W3C为CSS选择器定义了一整套选择语法，从简单的类选择器、ID选择器，到属性选择器、伪类、子组合器（>）、后代组合器（空格），再到结构性伪类（:nth-child）。这意味着用select_one('span.titleline > a')可以精确表达“直接位于span.titleline下的a标签”，而find('span', class_='titleline').find('a')则可能因为中间嵌套了其他标签而误伤。尤其在现代前端项目里，组件嵌套层数深、动态类名频繁出现，CSS选择器的表达能力恰好能覆盖大多数复杂定位场景。

稳定性天生占优

你不妨回想一下使用BeautifulSoup时遇到的经典挫折：某个列表结构因为增加了<div>包装导致find_all链条断裂。但CSS选择器通过组合器描述的是“相对关系”而非“绝对路径”，例如ul > li.active比find_all('li', class_='active')更耐受结构小幅变动——只要li仍然直接属于ul，就算上层多了个<section>，选择器依然生效。Cursor在训练阶段显然大量接触过这种“长期维护”场景，所以它会在生成时优先选择更鲁棒的表达方式。

连docstring也透露着态度

那一段由Cursor自动生成的docstring里写着“Returns a list of dictionaries with 'title' and 'url'.”——干净、直接。当你用select和select_one时，返回的通常是一个Tag或ResultSet，但进一步调用.text和[href]的写法让整个脚本看起来像在写一个声明式配置，而非命令式遍历。这背后其实是Cursor对代码语义化的一种偏好：它不希望开发者费力地理解一个“爬虫循环”，而是希望代码本身就能讲清楚“我在做什么”。

不是所有的AI都懂CSS

为什么GitHub Copilot和通义灵码不这么做？原因可能出在它们的训练数据分布上。Copilot的训练语料里包含了大量旧教程、StackOverflow回答和遗留项目，其中find_all出现的频率远高于select，所以模型更倾向于生成频率更高的模式，而不是最优模式。通义灵码则因为离线限制，很难感知到Web标准的最新动态。而Cursor内置的GPT-4和Claude在理解“现代Web最佳实践”上明显更激进——它们能判断出，对于2025年的Hacker News页面，CSS选择器才是正统解法。

不过话说回来，这并不代表CSS选择器在所有场景下都吊打find_all。比如你需要遍历一个结构极其不规则、包含大量条件分支的文档时，find_all配合Lambda表达式反而更灵活。而Cursor的“智能”恰恰体现在它会根据上下文动态判断：在示例的爬虫任务里，HTML的每个故事行都是规整的表格结构，用CSS选择器正好拿捏。所以下次你看到Cursor甩出一个select而不是find_all时，不妨多问一句：这个选择器，是不是在悄悄告诉你页面的真实模样？