躺在废墟里 Lieflat

GTM @moxt_ai
Journalist turned AI builder. 10k 🌟 on GitHub.
复旦新传🎓拿过新闻奖的前记者，写过百万+阅读公众号文章。REDSkill排行第二，GitHub万星开发者，探索AI中
Cat Lover🐱

[躺在废墟里 Lieflat @lieflat_3]

一个 skill，让你做出顶级审美的图表。

我开源的 Lieflat Charts 已经在 GitHub 2k star 啦～它是一套数据可视化与报告生成 skill，可供 Moxt、Claude Code、Codex 等 AI agent 使用。

它由统一的字体、留白、线条和动效建立视觉语法，有60多种图型，覆盖柱、线、面积、直方图等基础图型，还有热力图、小提琴图、环形关系图、桑基图等复杂图型，部分还支持交互。

色彩上，以黑白灰单色为基础，也支持青瓷蓝、椰林绿、编辑红三种色系，后续还会尝试更多丰富配色～

这个skill 的原理是用 html 来做图表，好处很明显，有很丰富的动效，可以无缝衔接到 html 做的 PPT 中。如果需要 PPT 格式，也可以让 agent 转成动图贴进 PPT 里。

使用非常简单，装好后把你的数据或者想要可视化的主题告诉agent，agent 会选择合适的图表类型，自动出图。如果你需要出报告，目前也有报告模式，可以一键产出数据可视化报告。

感谢 @moxt_ai 让我做出这么好看的图表！

#datavisualization #charts #skill #dataviz #html #aidesign

[躺在废墟里 Lieflat @lieflat_3]

@AdrianPunk115 一种古早的感叹。我觉得90%的人都不知道这俩是不同的app。。

[躺在废墟里 Lieflat @lieflat_3]

@Formulasearch 很精细了，我让gpt6+blender做出的兔子只有一个椭圆的手（没有手指）。。

[躺在废墟里 Lieflat @lieflat_3]

@typesafeai

[躺在废墟里 Lieflat @lieflat_3]

我让 Jev 和 opus-5、opus-4.8、terra、luna、gemini 这6个模型同时测评一批文章，看谁能更快找出不恰当的比喻。最后发现，Jev 确实速度很快，标注结果可复用，但是准确度并没有提升，甚至语义理解上不如opus 5。

关注我的朋友可能知道，我一直在做一个 AI 味测评，其中一个重要指标是模型写比喻句（包括明喻、暗喻等）的贴切度。Jev 发布之后，我觉得它很适合用来做模型能力测评和打标，所以我简单做了个小实验，看看它效果到底如何。

我给了这6个模型3篇 AI 写的文章，让它们找出其中不恰当的比喻句。我之前说过，AI 无法真正写作的一个表现是 AI 写不出贴切的比喻。同理， AI 也很难判断什么是好的比喻。一篇有202句的文章，Jev 只花了2.6秒就标注了所有句子，速度确实一骑绝尘。相比之下，opus-5 非推理模式花了8.2秒，gemini花了88.3秒，gpt5.6 terra、luna都在160秒以上。

Jev 快的原因是结构性的，它逐句并发处理， 通用模型是整篇文章作为上下文输入，还要推理，再输出标注的数据。

不过，Jev 标注的准确性并没有优于其他模型， Jev 打分最高的最有可能是比喻不贴切的句子，是这句：顶层是一般智力因素，也就是心理学中著名的 g 因子，代表一种统一的认知能力底层驱动力。然而，在明显的比喻句上，例如有 10 句是带明显标记词的（就像、好比、如同、木桶、短板、 遮羞布之类），Jev 一句都没有标注（0/10），opus-5 明显更好，找到了5句（5/10）。

同时， 对于多次出现的生硬的“尺子”这一比喻，Jev 的打分只有0.32、0.31、0.30。这是我觉得非常明显的AI滥用比喻的案例，但 Jev 对此并不敏感。

Jev 当然也有它明确的好处，它输出的是对所有句子的标注，因此我们可以拿着数据做很多分析。但其他模型，输出的只是“哪些句子有不贴切比喻”这一个答案，并不是全量的标注，因此也不能复用。

总之，Jev 在理解比喻这件事上，并没有比其他模型进步多少，甚至可能还不如现有模型。当然，学不会比喻这件事，是所有模型共同的难题。

[躺在废墟里 Lieflat @lieflat_3]

@xingbugengming 学习了！

[Gangqiang Yao @yaogangqiang]

接上一条，测试都过了，为什么 AI 还是改不对代码？

好的测试验证了用户行为，重构时也有底气。但是只要做得不是一周就扔的 demo，相信很多人会碰到：随着项目变大，vibe coding 产出代码快速变多，虽然测试通过，但是 AI 修改代码还是越来越费劲，经常需要反复纠正，当然此时人就更改不动了。

测试通过，回答不了这个问题：这次实现，有没有让 AI 下次修改变得更加困难？

我们关注不了所有的代码，那应该关注什么呢？也许应该是模块之间交互的复杂度：​理解或修改一个模块时，需要知道多少其他模块的细节，又需要维护多少跨模块的约定？

此时各种设计原则和方法就冒出来了，DRY、高内聚、低耦合、SOLID、DDD 等等。但是这些原则和方法很难变成判断标准。比如我听到过「微服务拆的越细越好，一张表一个微服务，这样才符合单一职责」，也曾经有个阿里 P10 说「微服务设计要考虑人性，每个人尽量一个，也是研发归属感的来源」 o(╥﹏╥)o

历史上提出过一些客观指标，比如 Afferent / Efferent Coupling、Instability（I）、Distance from Main Sequence（D）、Logical / Change Coupling 等等。这些指标能提供一点儿线索。但看完数字，往往还是要追问：常见需求的修改代价，是不是正在上升？

也许回答下面三个问题，更容易把观察和改进联系起来。（是 @nctaowen 提出的，我都是跟他学的）
1 模块内部修改时，外面的接口是不是也经常要改？

用 git 历史统计「接口改动 / 实现改动」的比例，看模块内部实现变化时，是不是每次都引起对外接口的变化。如果内部实现经常变化，外部却很少需要跟着调整，说明这个抽象起到了隔离变化的作用。如果比例大，抽象可能有问题，需要重新抽象、设计接口，或模块合并。当然要注意接口变化本身不是问题（有时业务变了接口自然要变）；如果每次你只是想改一个内部实现，都要外面一堆代码也跟着改，这就有问题了，就需要检查是不是把易变的内部细节暴露出去了、职责和边界是否需要调整。

2 模块边界，稳定抽象，是靠自觉遵守，还是有机制执行？

「阻断率」指所有可接入的地方，有多少处上了强制检查，确保了违规行为会被阻断。实在不行也找 AI 定期 review。例如规定了一个命名代表了核心概念就不要出现第二个，对于网络请求需要经过指定的库就不要随便引入第二个，对于取消机制确定了使用 abort signal，就不要出现第二种等等。统计的是约束覆盖情况，不是拦住了多少次违规；覆盖率低，说明边界还停留在口头要求，架构抽象也就只是名义上的，实际并不一致。

3 公共模块是不是越来越多特殊开关？

「必要参数占比」根据调用方的实际使用情况，找出只服务于少数业务的参数。这里的「必要」，不是指参数是不是必填。可以统计参数和调用位置，但不能看到某个参数用得少，就直接判定设计有问题。合理的默认值，也会让一些参数很少被显式传入。更值得追问的是：每接入一种业务，公共模块是不是就得增加一组专属参数和分支？

慢慢变成「业务 A 要传这个，业务 B 不能开那个，业务 C 得把这两个一起用」。看起来大家都复用了同一个模块，实际上每个调用方都得小心翼翼地配合。如果是，就该检查：​这些特殊逻辑，是不是留在具体业务里更合适，还是拆分成更多的接口。

这几个问题能接到具体动作上：收窄泄漏的接口，补上缺失的边界约束，收敛膨胀的公共抽象。改完之后，可以继续看：外部适配是不是变少了，约束是不是落实了，公共接口是不是还在积累业务特例。这些不能算成一个「架构质量分」，也代替不了业务判断，但能让 AI 先找出值得检查的证据，减轻我们对每一行代码的关注负担，让腐化慢下来。

这些指标显示出来的问题有时候很难调整？到底是哪些设计一旦选错，后面就只能不断打补丁？哪些错误，本可以通过设计直接避免？这些，也许才是最值得人来 review 的地方。

下一条聊聊这个，绝不放鸽子。(#^.^#)

相关资料放评论区了, 此外这种东西没有绝对的对错，欢迎讨论，@nctaowen 也会在评论区解答疑问。

[躺在废墟里 Lieflat @lieflat_3]

Jev 在工程角度可能确实能节省成本，有创新。
但是和 AGI、和智能上限可以说是毫无关系，一个不会说话的模型能通往 AGI ？那人类文明也可以直接覆灭了。。

[躺在废墟里 Lieflat @lieflat_3]

当我看了一堆说 Jev 是通往 AGI 的爆帖，再去真正使用 Jev 之后：

上网要小心诈骗。

[躺在废墟里 Lieflat @lieflat_3]

@podai001 视觉、听觉、嗅觉、味觉、触觉

[躺在废墟里 Lieflat @lieflat_3]

几年前我刚开始做记者的时候，一个老记者告诉我一条写作规则，当我们去现场的时候，一定要调动我们的五感，去观察，去感受，这样写出来的东西才是真正有场景感、立体的。

现在，当我通过各种办法调试 AI 写作能力、做去AI味skill的时候，发现 AI 就是写不出人类的感觉，这是因为 AI 没有五感吗？

哪怕现在给AI加上了多模态能力，它事实上也达不到五感的程度，它没有感受，和人类神经系统处理感官的方式完全不同。相比于编程，AI 在写作、在语言表达上的进步太慢了，甚至可能是倒退了。我现在经常看不懂 opus5 输出的报告。

一个悲观的看法是，AI 或许永远无法达到人类的写作水平。

[躺在废墟里 Lieflat @lieflat_3]

AI 无法写作的关键表现之一：AI 无法真正理解和学会比喻。

比喻需要感受，人类会用感受相近的词来比喻，AI 只能通过词频关系来判断。所以现在只能看到一堆牛头不对马嘴的明喻和暗喻，只会给用户增加阅读负担。

[躺在废墟里 Lieflat @lieflat_3]

几年前我刚开始做记者的时候，一个老记者告诉我一条写作规则，当我们去现场的时候，一定要调动我们的五感，去观察，去感受，这样写出来的东西才是真正有场景感、立体的。

现在，当我通过各种办法调试 AI 写作能力、做去AI味skill的时候，发现 AI 就是写不出人类的感觉，这是因为 AI 没有五感吗？

哪怕现在给AI加上了多模态能力，它事实上也达不到五感的程度，它没有感受，和人类神经系统处理感官的方式完全不同。相比于编程，AI 在写作、在语言表达上的进步太慢了，甚至可能是倒退了。我现在经常看不懂 opus5 输出的报告。

一个悲观的看法是，AI 或许永远无法达到人类的写作水平。

[躺在废墟里 Lieflat @lieflat_3]

@Miaow_YU 。优化中！

[躺在废墟里 Lieflat @lieflat_3]

一个基于283万字的去 AI 味 skill，希望用语言学来量化什么是 AI 味。最近还会有大量更新，可以关注交流～ https://t.co/IpJakWdkHj

[Gangqiang Yao @yaogangqiang]

接着上一条，简单补充下测试跑得慢、CI 资源消耗大的问题。评论里不少朋友问到了， @yetone 也提到了。Vibe coding 时，代码产出快了，这个问题就更明显了。

我负责的研发团队，一天上线 50 次，一天至少要跑 300 轮测试。在测试写对的基础上，怎么跑得更快、更省，可以尝试从这几个地方处理。

做精准测试（Vitest 自带的比较糙，效果有限）。记录每个测试实际经过的代码，源码变更后，就能反查大概会影响哪些测试。可以做到文件级，也可以做到函数级，我个人选择文件级。

函数级能少跑一些测试，但采集、分析和维护依赖成本也不低。文件级会多选一些测试，不过实现更简单，我更看重整体能省多少时间。当然配置、依赖、初始化这些变化要单独处理。

此外还可以做测试分级。

前面按 BDD 的方式描述业务场景，到这里就比较容易分清哪些是核心业务路径（写好测试是一切的基础哈）。高频 CI 跑核心路径、新增和修改的测试。其余测试，有代码变更就每小时集中跑一轮。

这样做，部分非核心问题可能会晚一点被发现，能接受多长时间，要看自己的业务。

还有个容易忽略的地方是 runner。不同测试集对 CPU、内存、IO 的需求不一样，要看机器的实际负载，分配合适的机器，控制好并发度。并发开大了，不一定更快。

我们也用了本地 runner，在自己配置好的机器上跑。在我们的使用场景里，成本比 GitHub 托管 runner 低不少。

好了，测试相关的分享先告一段落，希望有一点点帮助。接下来会逐步聊聊，为什么只靠测试还不足以保证软件质量，以及 AI 写的代码该怎么 review、重点看什么。

两篇精准测试的论文放评论区，感兴趣可以看看

[躺在废墟里 Lieflat @lieflat_3]

专业的

[fankai @fankai_dev]

看到很多人已经有运行 e2e 测试都意识了，大家也都会碰到一些问题，比如运行时间长、成本高，简单说一些我们的缓解措施：

1. 使用本地 runner，搞一些配置好点的机器来跑测试，成本比 github cloud runner 便宜很多。同时需要控制一下测试并发度，避免打满了机器谁也跑不过。

2. 尽量设置精准的代码依赖，测试进行相对细粒度的分组，代码改动的时候只运行受影响的测试组

3. 测试分层。我们把测试分成了 P0/P1/P2，CI 过程改动多一般只跑 P0 的测试，merge queue 里跑的多一点 P0+P1，P2 的测试则是有一个定时任务每半个小时才执行，这种方式能够砍掉大半的测试负载。如果 P2 测试有失败会有 agent 自动介入处理，如果是 flaky test 默认就直接先注释掉，如果是逻辑错误就自动创建 fix pr 然后通知 owner 处理。

4. 我们的测试都是 BDD 驱动的，除了 PR 里要求带上测试都相关修改，每天晚上 agent 会自动扫描过去一天修改的所有逻辑和测试，重新整理一遍，调整测试级别，删除冗余或者低效的测试，避免整个测试集无序膨胀。

[躺在废墟里 Lieflat @lieflat_3]

@zhouluobo 我觉得5.6做动效也挺好的

[躺在废墟里 Lieflat @lieflat_3]

gpt + remotion 做动效的能力非常强，只要准确描述动效或者是给它足够的参考，效果都很好，没有设计基础也能很快上手

[Adrian Punk @AdrianPunk115]

哈哈不好意思，因为内容太多，多出来一个中篇！ https://t.co/kayjg7QSGk

[躺在废墟里 Lieflat @lieflat_3]

@rwayne 🫡创作要紧是认真

[躺在废墟里 Lieflat @lieflat_3]

@AdrianPunk115 不是，图表还用不上remotion，只有部分用了d3js

[躺在废墟里 Lieflat @lieflat_3]

一个基于283万字的去 AI 味 skill，希望用语言学来量化什么是 AI 味。最近还会有大量更新，可以关注交流～

GitHub: https://t.co/qdIEQqaOPs