LLM 本身就没有壁垒。

OpenAI 前两年全面领先，这两年也慢慢被赶上了。除了 o1 的技术路线是大家猜谜猜出来的，其他的技术路线都比较公开。

用 nextjs + vercel

降智大概率要么是 prompt 变了 要么是 foundation model 变了

难，现在 LLM 理解渲染结果并且和代码对应起来还有相当的难度。

可以直接参考这篇博客，总结的还是挺完全的： https://blog.csdn.net/qq_36332660/article/details/132081595 。
本质上就是精心构造一些和常规情况不太一致的 Token 分布，难点在于，如何既构造差异分布携带信息又不能让大家发现这个序列是诡异的。

这件事情在一些涉密领域有一些应用。

@wangxiaoer 文本隐写就是这个目的，只是隐写一般携带的信息比较少。

这个叫文本隐写，和以前的图片隐写对应，同样是改变文本的概率分布隐式注入水印信息。但是因为文本高度抽象，这个领域被应用得不是很广泛。

此外，这个领域的主要目的是在文本内注入水印，防止文本泄密，如果要完全表示两套平行的信息，可能还是有非常的难度。

@chezs66 https://arxiv.org/abs/2504.02605
@Mandelo v0.dev

@chezs66 https://arxiv.org/abs/2504.02605

@llej
一是，「 AI 是更擅长前端」这个结论是不一定成立的。正如我引用的，AI 现在在 multi swe benchmark 上的任务成功率最高的是 Python 其次是 Java 这两者比 JavaScript 要高出一倍以上。所以我并不认可「 AI 是更擅长前端」这个结论。我对这件事情的理解是，AI 更擅长规范的代码，比如 Java 和 TypeScript 。（这里 Python 是个例外，字节的论文里认为是 Python 作为以前的 benchmark 的首选语言，会被 LLM 过度训练）。
二是，前端同样需要好的 unit test ，但是和后端不一样的是，前端是没有办法被 unit test 覆盖完备的，比如 UI 的部分。这就要求更丰富的反馈给到 LLM 。

我最近在做 design2code 的相关工作，可以多交流。

@llej 我反而觉得后端更容易让 LLM 知道问题，只要你有足够好的 unit test 。但是对前端来说，你即使告诉给他差多少个像素点，LLM 也很难处理，因为它无法「想象」这段代码实际的布局效果是什么样（这个要求就相当于让 LLM 训练得到一个差不多的渲染引擎，这很难）。

实际体验里也经常遇到这种问题。

@ciki 做不到。

Si, Chenglei, et al. "Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering." arXiv preprint arXiv:2403.03163 (2024).

可以看看这里的 benchmark ，这还只是 HTML+CSS 的简单页面。

@ciki 因为你的前端是自由发挥的，你让 LLM 去严格对照设计稿还原，几乎是没有任何可能还原成功的。真实场景不可能让 LLM 去自由发挥。

大家把前端理解为画 UI 是不是过于偏颇了？

附一张图，大部分情况下，LLM 解决软件开发问题的成功率满足 Python > Java > TypeScript > JavaScript ≈ C++ 的规律。

https://imgur.com/a/DvjSqQr

@bigtan copilot 的 cmd + i 对应的是 cursor 的 cmd + k

举个例子，copilot 至今没有一个类似 cmd + i 的快捷键，可以把选区添加到 chatbot 里。

就这么一个小的功能，真的会很影响自己开发时候的流畅度

@gneko 是 我自己感受一直都是 claude 3.5 > 3.7 > 4.0 。现在的 benchmark 关注竞争性编程，反而会损坏日常业务需求需要的能力。

这两个应该是不同团队做的，NotebookLM 属于 Google Workspace ，Gemini App 是专门做 Ai Chatbot 的组。

@asdblue 我理解这个叫私有化部署，可以直接买全套方案，我比较疑惑的是个人用户部署一个 LLM 在自己的机器上