猫鱼周刊 vol. 051 祛魅 AI

本期围绕AI应用展开深入讨论：AI不应被视为产品本身，而是作为功能融入现有产品；在专业领域，AI更适合作为辅助工具而非完全替代；传统算法在特定场景下仍具备优势。同时分享了Google Gemini新版本、Yubikey使用指南等开源项目。

猫兄

🫣

关于本刊

这是猫鱼周刊的第 52 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在

博客：阿猫的博客-猫鱼周刊

RSS：猫鱼周刊

邮件订阅：猫鱼周刊

微信公众号：猫兄的和谐号列车

私信：[email protected]

周刊马上迎来一周年，预告一篇特刊，会分享一下这一年多来写周刊的经历、收获等等。如果你有感兴趣的问题，可以邮件或者评论，到时候解答一下。

文章

不要轻易地走进 AI Native（AI 原生）

原文链接

一个很关键的观点：

绝大部分 AI 不是一个产品，只是一个功能。

我之前也说过：

对于其他一些 C 端用户来说，不同厂商的大模型体验差别会更加小。这是第一个变与不变——模型的特性、性能在变，但用户的体验基本不变。这点从一些集成了 AI 的产品来观察就能发现，很多产品并不强调背后的模型，只要打磨好用户体验就行了。

文章中，作者用地铁和支付体验作引，将产品本身的功能比作地铁，将 AI 体验比作地铁的支付体验；尝试用 AI 体验去颠覆产品本身，是不实际的，AI 只能作为里面一个亮眼的功能。

其实这个观点有很多应用实证：技术圈很火的 Cursor，没有重新开发编辑器，只是基于 vscode 深度开发，打磨 AI 编辑的体验；很火的 Arc 浏览器，也没有重新开发浏览器内核，基于 Chrome 重新打磨了 UI 和一些 AI 相关的功能；Midjourney 一开始甚至没有开发自己的网站和界面，而是基于 Discord 进行交互。

AI 对白领工作的替代并不需要重新定义工作的方式，而是以“无感接入”的形式悄然融入现有的办公流程。

针对 B 端落地场景，AI 更多的是做「提效」，甚至如果你用出「颠覆」这样的字眼，一定会遭到很大的反对：在 AI 能完成“一般”的效果的前提下，其职业稳定性、地位是否会被其动摇。另，原本一天工作量的事情，引入提效后，是否会影响其效率安排。

AutoConsis：UI 内容一致性智能检测

原文链接

美团团队的研究成果，利用算法识别目标区域，并通过 LLM 进行目标信息提取、一致性校验，来进行自动化测试，解决这类错误长期以来主要依赖测试人员对于 UI 的熟悉度，主要靠手工测试执行时来随机进行发现的问题。

比较有意思的是，采用传统算法进行识别和推理，无论是成本还是准确性都比直接用多模态 LLM 要优。

An image to describe post

近段时间在工作中的体验是，对 AI 一知半解的同事总是把 AI 当成银弹，总觉得 AI 是问题的万能终极解决方案。在我的认知中，LLM （或现在普遍认知中的 AI）算是一种「力大砖飞」，而传统的算法（或曾经的 AI）算是一种「小而美」。在具体应用上，大致是这样的经验：

在细分场景下（例如提取画面中关键区域信息、给文章打标签等），算法在准确性、速度、成本都有非常大的优势，劣势是需要相关的训练数据和开发。在机器学习常见的任务（分类、回归等）中，算法比 LLM 更高效。
在综合场景下，LLM 更加泛用，而且效果可能会更好。例如翻译问题，即使是预训练模型，在小语种上也依赖微调才能达到比较好的效果，但 LLM 由于训练语料大、参数多，只需要通过 Prompt 工程基本上就能达到比较好的效果，开发和调试成本都要低很多。
LLM 几乎不可能给出完全正确的结果。举一个比较极端的例子，OpenAI 有一篇文章讲述了他们的结构化输出是怎么实现的，其中提到，他们通过语法去过滤下一个输出的 token，使它符合 JSON 的语法。可以认为，如果没有人工规则/逻辑的限制，LLM 基本不可能输出完全符合规则的内容，这是通过 Prompt 工程也没法完全解决的。

在工程中，不能一味地觉得 AI（LLM）能解决一切问题，不要对它有过高且不切实际的期待。