这篇挂在 arXiv 软件工程分类，编号 2608.16302，出处是 Gustavo da Mota 和 Kiev Gama。标题就是对比 Lovable、v0、Replit 这三个工具生成的代码结构质量。
这种「X vs Y vs Z」的对比我读过不少，大多数是拿几个截图跑跑主观分就交差。这篇不一样：作者真把九个应用跑了 SonarQube——每个工具各生成三个独立项目，全部从同一个 prompt 起步。读到第三页看到他们列的那套指标，我才确认值得推。issue 数、严重度分布、remediation effort、圈复杂度、认知复杂度、代码重复率——不是「我觉得这个更好用」那种空话。
这篇最值得带走的是一句：选 vibe coding 工具的时候，结构层面的 trade-off 和体感上的「顺不顺手」是两件事。作者在结论里写的原话是「selecting a vibe coding tool involves structural trade-offs beyond perceived productivity gains」——说得克制，但数据摆出来之后，比喊口号的结论有分量。
Lovable 是三个里最有意思的。issue 严重度整体偏低，这是好事，说明它不会频繁生成一看就炸的错误。但它每一千行的 code smell 密度明显高于另外两个。两个指标同时出现在一个工具身上，和多数人对 Lovable 的印象对不上。我猜原因是它偏向生成常规、保守的结构——严重逻辑错误少，但「能用但写得脏」的地方积累得特别快。密度这个指标拿行数标准化过，所以不是因为代码写得少所以 smell 也少。恰恰相反，代码量不算大，smell 密度反而高。
v0 和 Replit 是另一个方向：代码量更大，issue 的严重度分布更 aggressive——高严重度 issue 的占比比 Lovable 高。同一个 prompt 跑下来，体量就差这么多。v0 和 Replit 明显偏向多生成、结构铺得更开，代价是出错的地方更疼。
我顺手跑了一下这篇论文的 PDF。没跑生成流程——三个工具跑九遍不现实，我是把论文里报告的 SonarQube 指标表自己过了一遍，确认「Lovable smell 密度高但严重度低」这个对比在原始数据里站得住。两个数字印象深：Lovable 的 smell 密度和 v0 比差出不止一点；blocker 级别的 issue 基本是 v0 和 Replit 占大头。具体数值不列了，点开原文看那张表。
这篇最难得的地方是它没说哪个工具最好。它说的是每个工具生成的代码病得不一样。Lovable 的病是脏，v0 和 Replit 的病是疼。哪个更难治，取决于你的维护计划。拿这些工具生成原型然后马上手工重构，「疼」可能更致命；要长期维护生成的代码，「脏」会慢慢把你拖死。这个区分比「哪个排名第一」有用太多。
要说局限也有：九个项目、单 prompt、没有迭代。真正的 vibe coding 场景里，人会一直改 prompt，代码经过几十轮迭代之后结构变成什么样，这篇不回答。作者没装，标注的是 preliminary results。全行业张嘴就是「我们重新定义开发流程」的大环境里，这种诚实挺稀罕。
顺手验证能做的就到这里。生成流程没复现，但 SonarQube 那几个指标的结果和作者结论对得上。我没注意到论文里有没有公开那九个项目的完整 prompt 和代码仓库。公开了的话，下周找个周末把 Lovable 单独跑一遍，看看 code smell 密度是不是真像他们说的那么离谱。这个先记着。
不点链接也能带走