首页

最近更新.rss.xml

之前 glm5.2 刚出来的时候用 /goal 进行过一轮优化，web-font获得了最大二十倍的性能提升： glm5.2 优化项目性能达到原来的二十倍
关注崮生，看更多ai实测数据
另外听说 kimi k3 很强？我将在接下来使用 k3 进行 loop 模式的性能优化测试，看他能否在 glm5.2 的基础上更进一步
还支持了 FiraCode 这样的具备连字特性的字体裁剪。
并且再次修复了多个bug并且支持了，其中有些bug修复后是会影响性能的
​ ​
可以看到再次得到两倍多的性能提升，基本可以说字体裁剪这个项目迈入了亚毫秒级裁剪的门槛。
性能相比上次再次得到大幅提升，下面图一是本次优化后的数据，图二是上次的数据
​ ​
​ ​
​ ​
现在再次尝试使用/loop 模式进行极限优化，在消耗将近 1.5B token 后再次达到极限了，连续多轮优化无正面进步

最近实践

​note​ https://z2h.cn/hanzi 字帖生成网站，田字格
​note​ amd 利用 npu 的办法：https://ryzenai.docs.amd.com/en/latest/inst.html https://lemonade-server.ai/ https://github.com/amd/gaia?tab=readme-ov-file 主要还是 lemonade-server ，gaia 也是连接的 gaia （直接安装 gaia 会自动安装 lemonade-server
​好文推荐​ https://vue-bits.dev/ 非常绚酷的 vue 动画库
​好文推荐​ 浏览器插件开发最佳实践 https://wxt.dev/guide/installation.html
​ ​
​ ​
最终我配置成了这样
json
"workbench.editor.customLabels.patterns": { "**/index.vue": "${dirname}⚡" },
backdrop-filter 本来是针对背景元素的，但是在企微中他却会导致整个元素都受到影响
最近一个场景发现在企微内特定元素会模糊，经过五个多小时的定位发现是 transform scale 和backdrop-filter blur 组合才会出现的bug，随便干掉一个都能解决这个问题
企业微信内置浏览器的bug： transform:scale(0.9) 内的插件设置了 backdrop-filter: blur(37px); 导致该元素整体模糊化，干掉这个 filter 就行了

更好的解决方案

在经过一段时间的尝试和摸索之后，我发现就是结合文本分段，再加上一个上下文的一个后期的坐标修正是能够达到最佳的一个体验的。
例如给每一个段落分配一个id交给大模型，并且让他输出的时候携带相关文本前面一段文本和后面一段文本，输出示例： {before:'交给',target:'大模型',after:',并且',snippet:'片段id'}​
这样基本能达到 95% 以上的准确率了。
上面是一些拙见，欢迎指正交流更好的方案
实际应用场景，文档校对demo演示：
​ ​
对于核稿这个场景重写文本然后再程序化 diff 也是一个方案
另外 agent 等方案让 ai 去写代码数数啥的确实是可行的，但做产品直接上 agent 是不合适的，例如文中提到的核稿场景，我想说的就是如果仅用一次大模型调用就解决问题，这样可以节约 token
对于核稿这个场景重写文本然后再程序化 diff 也是一个方案
对于核稿这个场景重写文本然后再程序化 diff 也是一个方案
​ ​
另外 agent 等方案让 ai 去写代码数数啥的确实是可行的，但做产品直接上 agent 是不合适的，例如文中提到的核稿场景，我想说的就是如果仅用一次大模型调用就解决问题，这样可以节约 token
Transformer 没有一个"离散、可验证、逐步更新"的状态来维护计数。
Transformer 没有一个"离散、可验证、逐步更新"的状态来维护计数。

如何解决这个问题？

但是有些场景是依赖大模型输出对应的下标的，这似乎又是必须依赖大模型数数了。
例如利用大模型标记文档中的所有写错了的文字。
既然直接数数不行，但是如果你让大模型去复述文本却能得到很高的准确率。
那么自然而然的就能想到，将文本先按字拆分，然后将下标和文字一起给大模型，例如 ： 1:大 2:模 3:型 4:不 5:会 6:数 7:数​ 这样之后输出的下标准确率就会飙升。
下面是一个简单的尝试，显而易见的 带坐标输入 的方案准确率更好 ​ ​
下面是一个简单的尝试，显而易见的 带坐标输入 的方案准确率更好 ​ ​
实际应用场景，文档校对demo演示：
上面是一些拙见，欢迎指正交流更好的方案
这样基本能达到 95% 以上的准确率了。
例如给每一个段落分配一个id交给大模型，并且让他输出的时候携带相关文本前面一段文本和后面一段文本，输出示例： {before:'交给',target:'大模型',after:',并且',snippet:'片段id'}​
在经过一段时间的尝试和摸索之后，我发现就是结合文本分段，再加上一个上下文的一个后期的坐标修正是能够达到最佳的一个体验的。
但是他不会数数！不信您可以试试发一段文本给大模型让他输出一下文本中的所有名词的位置，十有八九是会有错误的位置。
那么自然而然的就能想到，将文本先按字拆分，然后将下标和文字一起给大模型，例如 ： 1:大 2:模 3:型 4:不 5:会 6:数 7:数​ 这样之后输出的下标准确率就会飙升。
既然直接数数不行，但是如果你让大模型去复述文本却能得到很高的准确率。
例如利用大模型标记文档中的所有写错了的文字。
但是有些场景是依赖大模型输出对应的下标的，这似乎又是必须依赖大模型数数了。
对于这个问题我不是大模型专家，不知道究竟是为什么，但是事实上就是他数数不太行
现在这个时代似乎大模型什么都能干，每天自媒体都是大模型干翻这个那个，前端又被杀了。

AI 会写网页了，但还不会用中文字体

最近发现一个很有意思的现象。
很多前端其实不知道，网页是可以直接引用远程字体的。
而知道远程字体的人，往往又不敢用中文字体。
原因很简单——中文字体包太大了。
一个字体十几兆、几十兆都很正常。前阵子在技术群看到有同行说，他们网站光字体流量，一个月就烧掉了两万多块。
​ ​
后来大家开始做字体裁剪——把用不到的字砍掉，只保留页面上出现的字。
但这条路，我发现还有两个问题没解决。
第一个问题：用户真的会访问你网站所有页面吗？
大多数时候不会。用户可能只看两三个页面就走了，但传统方案要求他下载整个网站对应的那份字体子集——可能有几千个字。
第二个问题：AI 生成的内容怎么办？
现在越来越多网页是 AI 实时生成的。聊天框里用户问一句，AI 返回的文字当场渲染到页面上。
这些字，在构建的时候根本不存在。 你没法提前裁剪你不知道的字。
于是我做了一个实验：
让字体像代码一样，按需加载。
页面出现什么字，就裁剪什么字。 后面出现新的文字，再继续增量加载。
效果很直接——页面只出现"静心茶舍"四个字时，它就只下载这四个字的字形，大约 6KB。不是 6MB，是 6KB。
我把这个能力做成了 WebFont。
它不是构建时一次性裁剪整个网站，而是运行时、按页面真实出现的文字动态裁剪。后端返回的动态内容、AI 实时生成的内容，都能按需加载对应字形，DOM 一变就自动补齐新字。
最近，我又给它增加了一个 AI Skill。
现在 AI 生成网页时，不仅能自动用上中文字体，还能自动做好中文排版——行距给到 1.8、中英文之间加空格、正文首行缩进，甚至连禅意、科技、奢侈这些风格，AI 都知道该配什么字体、什么节奏。
我越来越觉得：
未来的 AI，不仅要会写网页，还要会设计网页。
而中文字体这一关，它迟早得过。
WebFont：github.com/2234839/web-font ｜ 在线体验：webfont.shenzilong.cn （2020 年上过阮一峰周刊，开源 6 年）
​ ​
最近发现一个很有意思的现象。
很多前端其实不知道，网页是可以直接引用远程字体的。
而知道远程字体的人，往往又不敢用中文字体。
原因很简单——中文字体包太大了。
一个字体十几兆、几十兆都很正常。前阵子在技术群看到有同行说，他们网站光字体流量，一个月就烧掉了两万多块。
后来大家开始做字体裁剪——把用不到的字砍掉，只保留页面上出现的字。