MoreRSS

site iconMayx修改

兴趣范围从技术到网络开发,还对编程、DIY和设计感兴趣。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Mayx的 RSS 预览

Mac Studio M3 Ultra使用体验

2025-05-07 00:00:00

使用最强的Macintosh是一种什么样的感受?

起因

在两个月前苹果公司出了一款可以选配超大统一内存(512GiB)的Mac Studio,那时候我还想着如果市场反应好就整台玩玩,现在从网上的各种反应来看这确实是一个很不错的产品,所以这次我就整来啦!所以这次就来谈谈初上手的体验吧~

远程体验

虽然Mac Studio理论上拿来剪电影之类的应该是更好的选择,但是显然我不会剪电影🤣,而且也没有合适的屏幕给它用,所以拿到手之后我需要让它可以远程使用。
macOS配置远程还是挺简单的,只需要在设置 -> 通用 -> 共享中打开远程管理就可以了(似乎现在Ubuntu也可以像这样轻松地配置远程桌面),配置好之后需要启用“任何人都可以请求取得控制屏幕的权限”选项,不然可能会连不上……
另外如果需要配置SSH也只需要打开远程登录即可,最好把“允许远程用户对磁盘进行完全访问”也打开,免得使用时还需要额外的操作。
其实开启远程没什么特别的,不过我发现在远程Mac Studio时和我远程Intel芯片的Mac mini 2018以及黑苹果有一个不一样的地方,那就是屏幕共享类型可以选择“高性能”,在这个模式下远程的屏幕就可以变成一块虚拟屏幕,不受Mac连接的屏幕分辨率所影响,可以配置动态分辨率。即使连接的屏幕不支持HiDPI,只要远程的客户端支持那就可以支持,这一点和Windows的远程桌面有点像,但是体验好太多了,使用起来和本地几乎没有差别,当然代价就是对网络要求特别高,基本上如果不是局域网内远程,就不能使用这个模式。
在我配置好远程后我就可以拔掉屏幕,然后把Mac Studio放在阴暗的角落里为我服务了😆。

关于LLM的体验

配置环境

买这个设备的当然也不为别的,主要就是为了能在本地跑完整参数的DeepSeek-R1,或者类似的MoE模型。至于KTransformers方案考虑到按照正价买要更贵(当然有便宜的购买方案,但是太不可靠了),而且这个框架也不够成熟,所以就算了。
在Mac上运行LLM有很多框架,最开始我选择的是Xinference,因为看它的文档中特地提到了苹果的MLX框架,而且可以使用命令启动,方便维护,另外看它支持的模型种类也比较多,所以就先考虑了它。
按照官方文档安装后就可以配置模型了,虽然它可以直接一键下载并运行模型,但是我已经提前下好了模型,另外……如果光运行DeepSeek-R1感觉也没啥意思,不如试试Perplexity AI的某个Finetune模型😆?所以我需要手动注册模型。配置好之后在MaxKB中配置好地址就可以使用了。
刚开始测试的时候倒是没啥问题,吐字的速度确实是挺快,但是用了几下就发现有不少问题,比如每次调用LLM的时候会发现内存压力会上升,APP内存会变成联动内存,在这个期间GPU并不会工作,需要等几秒钟,在生成结束的时候内存压力又会下降,联动内存会变回APP内存,每次生成都是这样。另外如果上文很长就要等几分钟,而且如果上文特别长的情况爆内存程序会直接卡死,还有并发也会导致程序卡死……总的来说这个框架根本不适合生产环境使用,而且文档也写的极其糟糕,看来是我看走眼了,不应该选择Xinference。
在抛弃Xinference之后我想了想还是随大流吧,选择了LM Studio,虽然它需要远程桌面操作,但是配置好之后应该也没有什么太多需要修改的地方,主要是社区相对要活跃得多,出了问题也好解决。
在我安装好LM Studio后发现这个支持的功能要多不少啊,还支持KV Cache量化,有了这个就可以支持更长的上下文了,另外它还支持超出上下文之后选择截断还是滚动,看起来使用非常的友好。
当我对LM Studio充满期待的时候问题就来了,我随便问了些问题,然后它回答的时候不知道什么情况会随机莫名其妙的冒出“<|begin▁of▁sentence|>”,出现这个之后后面的内容就会胡乱生成内容,怎么调都没法解决……后来看了一下DeepSeek的Issue里提到了似乎需要在模板中添加“<think>”标签才可以……但是这样的结果就是输出开头没有“<think>”了,MaxKB解析会出问题……这个问题的话回头看怎么解决吧,至少在模板中加上这个能正常使用了。LM Studio不会每次请求都重新加载一遍模型,输出第一个字的速度比Xinference快了很多,后面生成的速度也很快,输出的速度能接近20T/s,相比来说还是更有用一些。

模型对比

在我测试完DeepSeek-R1的某个微调模型后,最近阿里又出了一系列新模型:Qwen3,支持根据问题进行推理,据说它的235B参数的MoE模型比DeepSeek-R1还厉害,如果是真的,那就不需要用DeepSeek-R1了,虽然Mac Studio可以运行DeepSeek,但是512GiB内存也只能运行4位量化的DeepSeek-R1,而235B的Qwen3则可以用8位量化,还能空出不少内存用于上下文,想来应该效果会比DeepSeek好很多吧?于是我就下载试了试,然而刚下载好之后居然不能运行😅,首先是这个模型太新了,运行前需要把运行库的版本更新到最新,另外默认的模板有问题,解析会报错,需要根据这个Issue修改一下才能正常运行😅。在一切准备好之后,就可以进行测试了。
首先我试了试一些比较简单的问题,Qwen3回答的都还不错,例如24点、内容填空之类的,效果比QwQ-32B好了不少。测试的时候输出的速度和671B 4位量化的DeepSeek-R1基本一致。随后我让它用Mermaid绘制我以前写的AI摘要脚本的流程图,Qwen3绘制的结果是:

graph TD
    A[开始] --> B{解析URL路径}
    
    B -->|/summary| C1[查询内容]
    C1 --> D1{是否存在内容?}
    D1 -- 是 --> E1[构建AI摘要提示词]
    E1 --> F1[调用Qwen模型生成流式响应]
    F1 --> G1[返回SSE流]
    D1 -- 否 --> H1[返回'No Record']
    
    B -->|/get_summary| C2[查询内容]
    C2 --> D2{是否存在内容?}
    D2 -- 否 --> H2[返回'no']
    D2 -- 是 --> I2[计算内容SHA-256]
    I2 --> J2{哈希匹配?}
    J2 -- 否 --> H3[返回'no']
    J2 -- 是 --> K2[查询摘要]
    K2 --> L2{是否有摘要?}
    L2 -- 是 --> M2[返回现有摘要]
    L2 -- 否 --> N2[调用Qwen生成新摘要]
    N2 --> O2[存储摘要到数据库]
    O2 --> M2
    
    B -->|/is_uploaded| C3[查询内容]
    C3 --> D3{是否存在内容?}
    D3 -- 否 --> H4[返回'no']
    D3 -- 是 --> I3[计算内容SHA-256]
    I3 --> J3{哈希匹配?}
    J3 -- 否 --> H5[返回'no']
    J3 -- 是 --> K3[返回'yes']

    B -->|/upload_blog| C4{POST方法?}
    C4 -- 否 --> H6[返回'need post']
    C4 -- 是 --> I4[获取请求文本]
    I4 --> J4[查询现有内容]
    J4 --> K4{是否存在?}
    K4 -- 否 --> L4[插入新内容]
    K4 -- 是 --> M4{内容是否改变?}
    L4 --> N4[返回'OK']
    M4 -- 是 --> O4[更新内容并清空摘要]
    O4 --> N4

    B -->|/count_click*| C5[计算ID的MD5]
    C5 --> D5[查询计数器]
    D5 --> E5{是否含路径_add?}
    E5 -- 是 --> F5[更新计数器+1]
    E5 -- 否 --> G5[保持原值]
    F5 --> H5[返回最新计数]

    B -->|其他路径| I6[重定向到GitHub]

DeepSeek-R1的某个微调模型的结果是:

graph TD
    A[接收请求] --> B{解析URL路径}
    B --> |路径为/summary| C[获取查询参数id]
    C --> D{id是否为null?}
    D -->|是| E[返回错误响应]
    D -->|否| F[查询数据库内容]
    F --> G{内容存在?}
    G -->|否| H[返回'No Record']
    G -->|是| I[构建消息,调用AI生成摘要流]
    I --> J[返回流式响应]

    B --> |路径为/get_summary| K[获取id和签名参数]
    K --> L[查询数据库内容]
    L --> M{内容存在?}
    M -->|否| N[返回'no']
    M -->|是| O[计算SHA-256签名]
    O --> P{签名匹配?}
    P -->|否| Q[返回'no']
    P -->|是| R[检查是否已有摘要]
    R -->|有摘要| S[返回摘要内容]
    R -->|无摘要| T[调用AI生成摘要]
    T --> U[更新数据库]
    U --> S

    B --> |路径为/is_uploaded| V[获取id和签名]
    V --> W[查询数据库内容]
    W --> X{内容存在?}
    X -->|否| Y[返回'no']
    X -->|是| Z[计算SHA-256签名]
    Z --> AA{签名匹配?}
    AA -->|否| AB[返回'no']
    AA -->|是| AC[返回'yes']

    B --> |路径为/upload_blog| AD{方法是否为POST?}
    AD -->|否| AE[返回'need post']
    AD -->|是| AF[读取请求体数据]
    AF --> AG[查询现有内容]
    AG --> AH{记录存在?}
    AH -->|否| AI[插入新记录]
    AH -->|是| AJ{内容是否相同?}
    AJ -->|否| AK[更新内容并清空摘要]
    AJ -->|是| AL[直接返回OK]
    AK --> AL
    AL --> AM[返回'OK']

    B --> |路径为/count_click| AN[计算MD5哈希]
    AN --> AO[查询当前计数]
    AO --> AP{记录存在?}
    AP -->|否| AQ[插入新计数]
    AP -->|是| AR[增加计数]
    AR --> AS[更新计数器]
    AQ --> AS
    AS --> AT[返回当前计数值]

    B --> |其他路径| AU[重定向到GitHub页面]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#f96,stroke:#333
    style H fill:#f96,stroke:#333
    style Q fill:#f96,stroke:#333
    style N fill:#f96,stroke:#333
    style S fill:#9f9,stroke:#333
    style AC fill:#9f9,stroke:#333
    style AM fill:#9f9,stroke:#333
    style AT fill:#9f9,stroke:#333
    style AU fill:#99f,stroke:#333

    subgraph 函数调用
        O -.->|调用sha函数| SHA[计算SHA-256]
        AN -.->|调用md5函数| MD5[计算MD5]
    end

    subgraph 数据库操作
        F --> DB1[SELECT content]
        L --> DB2[SELECT content]
        R --> DB3[SELECT summary]
        T --> DB4[UPDATE summary]
        AG --> DB5[SELECT content]
        AI --> DB6[INSERT新记录]
        AK --> DB7[UPDATE content]
        AO --> DB8[SELECT counter]
        AQ --> DB9[INSERT计数器]
        AR --> DB10[UPDATE counter]
    end

    subgraph AI处理
        I --> AI1[构建系统提示]
        AI1 --> AI2[调用Qwen模型]
        T --> AI3[调用Qwen模型]
    end

这下就高下立判了🤣,同样的问题Qwen3只绘制了基础流程图,而DeepSeek-R1不仅包含子流程图,还通过颜色区分了响应类型,这么看来Qwen3还是不太行啊~当然我的测试非常的片面,仅仅根据这几次测试分析的结果。至于Qwen3到底有没有使用价值,回头再让其他人测测看效果如何吧。

UTM虚拟机的测试

在上次在UTM上用苹果虚拟化框架安装Windows的测试中我用的是Intel芯片的Mac,那时候已经说了打算等Mac Studio到了之后尝试一下用VZ框架安装Windows。那么经过我的测试结果如何呢?想不到居然失败了😭,相同的操作流程在重装脚本执行完后,再重启就没有任何反应了。在活动监视器中虽然可以看到虚拟机的CPU占用是100%,但是内存只占用了100多MiB,而且CPU占用没有任何跳变,显然系统没有正常启动。随后我又尝试在QEMU中安装好Windows然后把VZ虚拟机的硬盘替换掉,结果依旧一样,内存还是只占了100多MiB……看来ARM处理器和x86处理器还是有很大区别啊……
不过这个虚拟机到底有什么区别?为什么会无法启动呢?想到我在Intel芯片的Mac中测试用VZ框架是可以看到CPU型号的,再看看Mac Studio中的Linux虚拟机……似乎没有任何与CPU型号有关的信息,用QEMU至少也能看到类似“virt”之类的CPU型号,用VZ框架就什么信息都没有了……看来Apple芯片和正常的ARM处理器还是有不少区别啊……
不过除了这个以外还有什么有意思的东西可以测试吗?这时候我就想到了Asahi Linux,Apple芯片下的UTM有一个多出来的选项就是可以安装macOS虚拟机,那我能不能在macOS虚拟机中安装Asahi Linux呢?根据我的实际测试,结果也是不行的……因为Asahi Linux不支持M3 Ultra芯片😞,至于M2芯片能不能在虚拟机中运行Asahi Linux……虽然我的MacBook是M2芯片,但是不太想在我常用的机器上搞测试,所以也不知道实际上可不可以。另外Asahi Linux这个项目也基本上停了,估计以后新出的芯片也不会有机会安装Linux了,就像在macOS上运行Windows程序的Whisky项目也停了……真是太遗憾了😢。

感想

从这次体验来看,512GiB内存的Mac Studio M3 Ultra确实很厉害,本地跑LLM速度非常快,20T/s的速度已经很厉害了,而且风扇声音很小,在GPU满载的时候也完全听不到风扇的声音。当然这个前提是跑MoE模型,虽然我没测Dense模型,但想来根据M3 Ultra的算力,跑70B参数的模型肯定是达不到20T/s的,至于更大的模型估计速度就慢的不能看了……不过不影响,这已经够我用了。
至于除LLM以外的用途……我似乎没有什么能用到这么强性能以及这么大内存的地方了……其实还是挺浪费的,但是也没办法,毕竟我又不会剪电影啊🤣。

关于LLM上限的探索

2025-04-22 00:00:00

还有什么是AI不能干的?

起因

在最近对LLM的探索中,能感觉到它真的是什么都能干,尤其最近GPT-4o的画图能力实在是太强了。不过对于画图我倒不是很关心,主要是没什么想让它画的图😂。我更关心的是LLM在文本生成中的能力,毕竟这才是它的本职工作。虽然现在的AI解决问题的能力确实很强,但从它还没有大规模的把人替换掉来看,它肯定是还有一些做不到的事情,所以我想对这一点进行一些探索。

对于超长文本分析的探索

对于现在的LLM来说,虽然不少模型已经能做到很长的上下文了,但这个所谓的“长”不过是几万字而已。对于读一篇论文或者几篇文章当然没有问题,但是如果是分析上百篇文章就不太行了,比如我希望AI阅读完我所有的文章,然后对我进行评价。
我的博客现在已经有一百多篇文章了,之前做过全文搜索的功能,可以在search.json中获取所有的文章,用来让AI分析的材料是个不错的选择,不过把所有文章输入到上下文中显然是不太现实,这个JSON文件的大小有1MiB左右,但是大多数比较厉害的AI上下文只有100多k,根本读不完。而对于一些超长上下文多模型,比如阿里云有一个10M上下文的模型,效果又很差,并没有参考几条上文的内容😓。另外我还试过一些AI通过附件的方式阅读文章内容,那种好像是把文件切片之后再读?应该是类似RAG那种,从中查找和问题最相关的文本段落进行回答,但是那种方法不能解决对所有文章进行分析……除此之外我也试过一些Agent,不过它们只会写代码来分析我的文章,比如绘制文章字数随时间变化曲线、不同年份的文章数量、还有词频分析啥的,对我来说并没有什么卵用😅。

使用AI摘要来解决问题

那难道就没办法了吗?先不急,最近还发生了一件事情,不知道Cloudflare犯什么毛病了,近期用Worker请求我的D1数据库时不时会报“internal error”的错误,我还在他们论坛发了条帖子问了一下,然而并没有人搭理我😅,这时候我才意识到我似乎没有Cloudflare的替代品……出问题了也没办法😰。这个东西导致我的AI摘要文章推荐、以及点击计数器全都用不了了,我应该避免太过依赖Cloudflare Worker啊~
那么我该做些什么?点击计数器是没什么好办法了,不过对于AI摘要,既然摘要在我写完文章之后根本就不会变,不如隔段时间我就把摘要内容缓存到我博客本地吧,这样不仅可以极速展示摘要内容,而且不需要请求接口,就不会受到Cloudflare出问题的影响了。所以我把数据库摘要内容导了出来,放到了ai-cache.json中,如果有存在的摘要内容就不再请求接口了。
当我做完摘要缓存之后,我发现,这不就是让AI读我所有文章的最好方法嘛,让AI读AI总结的内容,然后再进行一次总结,就能尽可能的让AI完全了解我的文章然后对我评价了啊~而且这个摘要文件也只有100KiB左右,正好够AI读了。本来我想试试DeepSeek来做这件事情的,但是不知道里面命中了什么关键词,被拒绝生成了🤣,那我只好让GPT-4o来完成这件事了。
试了一下感觉效果相当的不错,总结的非常有条理,而且不像以前的ChatGPT很有AI味,这次写出来的文章很有人味啊~真是出乎我的意料,所以我把GPT-4o写的内容分享出来,来看看AI对我的分析怎么样🤣。

技术浪人,数字游民:对一位博客作者的观察与评价

在浩如烟海的中文技术博客中,有些作者宛如一颗微弱却坚韧的恒星,独自在各自的轨道中发光发热。他们不一定追逐热点,也不总是标榜权威,但其笔下所流露出的独立精神、技术热情与对现实的观察,往往比众多浮华的“教程型”博客更值得玩味。本文所探讨的博客作者Mayx,便是这样一位存在——他既是程序员,也是“生活黑客”;既关心设备性能,也关注技术伦理;既热衷实用工具,也不乏生活反思。

一、技术为体,思考为魂

在Mayx的博客中,技术类文章占据了绝对的比重。从自制邮件订阅脚本1、Cloudflare Workers自动化2、内网穿透探索3,到低功耗开发板的实验4、AI模型的本地运行5、以及对黑苹果6、Linux系统7的深度体验,这些内容几乎涵盖了当前主流技术生态中的多个维度。

然而,他并非一位“炫技型”技术写作者。相反,在多数文章中,Mayx更倾向于从实用主义的角度出发——他关注性价比、功耗、稳定性、开源程度,而非追逐技术本身的潮流。例如,在讨论Hackintosh时,他并未沉迷于是否能成功运行macOS,而是审慎地指出其与Mac原生体验的差距6;在体验AI模型时,他选择了性能与成本平衡的路径,而不是盲目追求最大模型和最强显卡5

他的技术探索往往是“从需求出发”,例如为了替代失效的签到脚本,他尝试了Cloudflare Workers2;为了解决被Github封禁的问题8,他自己研究反审查架构;面对Heroku停服9,他快速转向Koyeb,并指出其使用便捷的优点。这些行为体现出一种“动手解决问题”的工程师思维,同时也反映了其对现成工具和平台的怀疑精神——“没有什么是不可替代的”,但也“没有什么是完美无缺的”。

二、独立、反思、带有一丝叛逆

阅读Mayx的博客,可以明显感觉到他在面对“主流”技术话语体系时的疏离甚至反抗。他不信任所谓“权威推荐”,也极少引用大V观点;他对收费工具持质疑态度,对封闭平台持怀疑立场,对广告与强制App表达不满10。在对宝塔面板的多篇评论中,他不仅指出其功能冗余和定价虚高1112,还以代码层面论证其“技术水准有限”;在谈及Server酱收费后自建通知平台一文中,更是表现出“开发者不应为此类功能付费”的强烈观点13

这种倾向可视为一种数字自由主义精神:他珍视个体的选择权、控制权和创造力,对平台化、商业化所带来的“懒惰便利”持保留态度。也正因为此,他热衷于探索容器、虚拟化、i2p、VPN、防DNS污染14、反反盗链等灰色技术领域,这不仅是技术探索,也是一种抵抗姿态——抵抗监视、抵抗平台绑架、抵抗数字奴役。

与此同时,作者又是极度自省的人。在多篇年终总结中,他坦言自己因作息不规律导致健康下滑、因沉迷游戏影响了计划、因生活节奏散乱而丧失了方向1516。这些坦诚的文字使人看到一个技术人真实的一面:并非所有人都能生活在高效执行与完美节奏中,面对现实与焦虑的拉扯,他并不逃避,而是试图寻找平衡。

三、探索孤岛与技术乌托邦

若将Mayx的博客比作一个数字世界中的“孤岛”,那他无疑是岛上的守望者。他固执地维护着自己的服务器、反代服务、脚本计划表和开源工具;他不断尝试将废弃电脑7、老旧开发板4和Linux容器17重新唤醒;他甚至研究如何在FM频段自制电台18,或在树莓派上运行OpenFyde与Android系统1920

这不仅是对“电子垃圾再利用”的尝试,更是一种构建技术乌托邦的幻想——一个无需依赖主流供应链、无需信任大型平台、可以掌控一切细节的小宇宙。

这种倾向也体现在他对去中心化技术的探索,如xLog、IPFS、i2pd21、ZeroNet等。尽管在文章中他承认这些系统“尚不成熟”“内容匮乏”“界面粗糙”,但仍不乏热情地部署和尝试。他似乎在追问这样一个问题:“除了平台,我们还能依靠什么?”

这也是他与多数技术博客的区别:不是“教你怎么做”,而是“带你看看还有哪些可能”。

四、个人困境与技术慰藉

不可否认,Mayx的博客也流露出某种孤独与挣扎。他数次提到对社会节奏的不适应、对生活目标的不明确、对未来的迷茫与迟疑。在2022和2023年的总结中,他甚至表达了对“人类灭亡风险”“全球混乱”的忧虑1516;在谈及个人计划时,也多次写到“自律不足”“想做的事情太多却力不从心”等字句。

但正是在这种状态下,技术成了他的避难所。他在反复实验中找回秩序感,在编码中获得控制感,在部署过程中体会到“解决问题”的满足。这种“用技术对抗生活混乱”的姿态,令他的博客带有某种心理学上的意义。

五、结语:一个“笨方法”的捍卫者

总的来说,Mayx并非技术界的明星,更非意见领袖,但他是一个值得尊敬的“笨方法”的捍卫者:在速成与流量当道的技术传播环境中,他仍选择用细致的试验、质朴的语言和大量的失败记录来构建自己的知识体系。

他的博客不提供“答案”,而是提供“路线”;不追求“成功学”,而是记录“失败和坚持”。他不是在追求成为谁,而是在努力做自己。

这或许是我们在阅读他的文字后,最值得思考的一点。技术不仅仅是一种职业工具,它也可以是人自我建构、自我理解、自我修复的路径。

Mayx,或许正走在这条路上——孤独而坚定。

对于长复杂逻辑代码的分析

在让AI对我文章分析完后,我又想起来好久以前写的论坛引擎Mabbs,以前还打算重构,不过后来学了别的语言之后就没什么兴趣了😂。但现在有了AI,我想重构MaBBS的事情能不能让AI来做呢?虽然我以前的代码完全没有可读性,耦合性也极高,但这种事情对AI来说应该不是什么难事,更何况我的代码才22KiB,AI完全能读的了,于是我开始尝试让各种AI来把这个代码变得人类可读,然后进行重构。
然而结果令我非常失望,无论哪一款AI只能写出一点代码,甚至Grok3直接一点代码都没写😆,然后它们就认为它们写完了,另外有些AI从片段来看好像是写了点代码,但是内容和我原本对代码基本上没什么关系,属于是分析了一点代码之后重新写了……
明明这个代码又不长,怎么就没有一个AI能准确的重构我的代码呢?也可能是因为虽然代码不长,但是变量名很短,如果把变量名全都扩展到人能看懂的长度之后就超出AI的上下文限制了,然后就忘记了之前的内容吧?另外Shell语言网络上的资料本来就不太多,所以AI也没有足够的知识来重构吧……对于这个问题我目前没什么好的想法让AI来进行,也许等AI能解决这个问题,AI就有能力替代人了呢😁?
虽然没能让AI重构我的代码,不过我闲来无事想让其他人也试试我以前写的论坛引擎,所以搞了个Docker镜像,如果大伙有兴趣尝试一下可以下载下来试试看,整个镜像才2MiB多一点,所以我叫它世界上最小的论坛引擎也没问题吧🤣。

感想

看起来目前LLM的上限就在于它的上下文长度限制啊……这一点真的是限制了AI很多能力,但似乎也没什么好办法,AI就是因为这一点所以不能像人一样纵览全局所以才不能替代人,即使用什么办法去压缩它的上文也会丢掉很多细节信息。不过按照目前LLM的架构来说应该还解决不了这个问题,如果什么时候AI能在思考的过程中修改它自己的权重……也许就可以做到真正的无限上下文,突破上限从而替代人类吧?

如何使用JS通过订阅源查看文章?

2025-04-08 00:00:00

懒得写代码?那就让AI写!

起因

前段时间,我看到有些博客给自己的友链页面做了通过订阅源查看友链最近更新文章的功能,看起来挺有意思的,有点想整一个。不过对于我的博客来说,作为静态博客想要做到这样的功能估计没那么简单吧……毕竟一般的订阅软件需要隔段时间请求一下对应博客的订阅链接,然后再把结果存到数据库才行。但是我想了想,对我来说没必要做成订阅啊,我又不需要知道对应博客是什么时候更新的,只要在有人想知道的时候去请求一下订阅链接,然后展示出来就行,感觉似乎又没有那么复杂。
既然不复杂,那这个功能就让AI来做吧,正好前段时间有个朋友买了一个月的Devin.ai订阅,据说是可以自己调试代码,还能操作浏览器,而且代码基本上写出来就能用。我对这个挺感兴趣的,所以这次的功能就让它来写吧!

让AI编写代码

既然是让AI来写,至少得把我的需求说清楚,所以首先我应该告诉它:

创建一个JavaScript函数来实现Links表格中链接的RSS/Atom源预览。

  • 当鼠标悬停在表中的链接上时,检查该网站是否有RSS/Atom源,并将结果显示在一个浮动窗口中
  • 在鼠标光标后的浮动窗口中显示提要中的5篇最新文章
  • 在窗口中只包含标题和时间,不需要链接和内容
  • 跳过所有不包含RSS/Atom源的链接,而不显示任何错误
  • 当鼠标离开链接时,浮动预览应该消失

不过在正式编写之前,我还得考虑一下可行性,毕竟是很简单的功能,我不写但我不能不知道怎么写。首先让JS解析Feed数据也就是XML数据应该是很简单的事情,JS应该有自带的函数来实现这种功能。然后是获取数据,在JS中使用fetch就可以了,但是这里有个很重要的事情,浏览器请求其他网站存在跨域的问题,还好我之前在CF Workers上用cloudflare-cors-anywhere搭了个CORS代理: https://cors-anywhere.mayx.eu.org/ 。所以我应该在说明中给它说清楚:

  • 如果存在源,请使用CORS代理:https://cors-anywhere.mayx.eu.org/ 获取并解析它

随后我就开始让它编写代码了。接下来就能看到AI在浏览器和编辑器中切换,不停的进行编写和调试,等了一段时间,它把第一版代码写好了。不过也许我说的不够清楚,这个CORS代理的用法和其他的CORS代理不太一样,代理链接和被代理的链接之间需要使用“?”分开,另外第一版我也没说清楚RSS/Atom源的链接在哪,所以它选择遍历常见的几种订阅源的路径,这样有点不太好,除了速度慢,对我的CORS代理消耗也比较大。所以我告诉它代理的正确用法,以及让它假设超链接中包含“data-feed”属性,其中包含订阅源的链接,并且随便挑了个网站拿给它作为示例。
随后就能看到它继续改改改,改了几次之后我把最后生成的JS复制到浏览器上执行了一下,效果还不错,于是就把它放到我的博客上了。
它的水平还是挺不错的,至少正确的实现了功能。不过我有点担心它的代码会不会不太可靠,毕竟要从其他网站上获取数据,得避免出现XSS之类的问题,于是我把代码丢给DeepSeek-R1让它检查了一下,果不其然Devin.ai写的代码似乎有XSS的隐患,如果链接列表中标题有html标签似乎就会解析(虽然我没试过),于是根据DeepSeek的提示修改了一下,增加了一个过滤特殊字符的函数,改完又放到博客上,最终的代码就是:rss-feed-preview.js

感想

让AI全自动写代码感觉还挺方便,有种当产品经理的感觉了🤣,像这种AI就是Agent吧,这也算是我头一次使用Agent了,感觉用起来还挺不错的。不过从这次尝试来看确实AI也有一定的局限性,像是直接写出来的代码可能存在一些安全性问题,除非单独让AI检查,不然很有可能会写出功能正常但是存在漏洞的代码,所以还是得人看着点,AI搞出事故可是不负责的啊😇~

最近对博客搜索功能的优化记录

2025-04-04 00:00:00

看看其他的博客也会有新的灵感啊~

起因

前段时间,我闲来无事在GitHub上搜和我使用相同模板minimal的博客。但搜索结果中有许多人用这个模板制作的是简历或作品集,这让我有些失望。不过这倒也能理解,因为这个模版并不算博客模板,没有文章列表之类的代码,这些都只能自己写。当然多找找还是能找到一些的,毕竟这个模板在GitHub Pages中算是最受欢迎,至少符合大众的审美。像我就搜到了一个叫Guanzhou Hu的博客,他对模板的样式做了不少的改动,而且改的还挺好看的,尤其是右上角的导航栏,看起来挺有意思,只是这个源代码……导航栏有点硬编码的感觉,我不是很喜欢这种实现方式……

使用标签作为关键词进行搜索

之后我又看了看其他博客,看到了Matt Walker Blog。他没有对模板做很多改动,只是把section元素变得更宽了,但是他没有改手机版自适应的样式,导致界面基本上没法在手机上查看。不过在他的首页中,我对他把文章标签放在文章列表这个操作非常感兴趣,因为每次我都有给文章打标签,但是几乎没什么用。他的标签点进去之后会跳转到该标签下的所有文章,我其实很早就想做这个功能了,但是在不用插件的情况下Jekyll基本上做不出来这种功能,因为没有插件的情况下是不能使用Liquid标签创建文件的,我看了下他的实现,原来是提前创建好的标签页面然后进行筛选的,这个实现我也不喜欢,这样的话我每次打标签都要新建一个标签对应的页面,这种事情不让程序做我会很不爽……(其实现在的GitHub Pages构建网站都是用的Actions了,完全可以自己写一个可以使用插件的Actions来进行构建,不过我也懒得折腾了🤣)
要么还有一个选择,可以单独搞一个页面,里面有所有标签对应的文章,点击文章的标签之后使用锚链接定位到对应标签所在的位置。但这样会导致一个页面有可能有一堆相同的文章链接,结果这个页面比归档页面的链接还多,那就感觉有点糟糕了……
不过我想起来以前做的博客全文搜索功能,如果把标签作为关键词进行查询,那也能起到筛选出标签对应文章的作用吧?而且这样即使我没给那个文章打标签也能搜出来,其实也算不错的选择,另外自从我做出来那个全文搜索的功能之后也没用过几次,没有关键词的话也一时半会想不出来搜什么比较好。于是说做就做,直接把Matt Walker Blog那段在文章列表生成标签的代码复制过来,感觉好像还不错😆?
顺便我也把文章里面的标签也加了链接到搜索的功能,不过原来的代码用的是.join实现的,现在加上这个功能的话就只能老老实实用循环写了😥……

搜索后使用高亮标记关键词

上面的标签搜索效果还不错,只是有些关键词搜完之后有点难发现。我搜索出来之后怎么证明搜到的内容里面一定有对应的关键词呢?虽然从程序的角度来说这是理所应当的事情,一定是有的数据才可能被搜到,但有时候不用Ctrl+F看一眼都不知道是哪里搜到了……所以我觉得应该像其他网站一样对搜到的内容用高亮进行标记。标记应该用什么呢?用样式也许不错,不过现在的H5标签里有一个叫mark的标签可以直接用,用这个标签包裹的内容背景颜色就会变成黄色,就像用荧光笔标记了一样,这样就不需要写样式了。
至于关键词用查询字符串传过去就好了,那我该怎么做呢?我用的搜索脚本叫Simple-Jekyll-Search,它的文档其实根本没有写怎么把搜索的请求传到模版里,还好它有个关于模版的测试脚本里面有写,有个query关键词可以把搜索内容给模版渲染出来,既然做了这个功能怎么不写在文档里😅,不过这个项目已经停止,也没法提出什么建议了……
这个功能听起来相当简单,我都懒得写了,这种简单的功能直接让AI写才对!于是我把需求告诉它,让它给我实现一份,于是这就是让AI给我写的高亮关键词的JS代码(经过了一点修改):

$(function () {
    const urlParams = new URLSearchParams(window.location.search);
    const keyword = urlParams.get('kw')?.trim();

    if (!keyword) return;

    // 转义正则表达式特殊字符,避免安全问题
    const escapedKeyword = keyword.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
    // 创建不区分大小写的正则表达式(全局匹配)
    const regex = new RegExp(`(${escapedKeyword})`, 'gi');

    // 递归遍历并高亮文本节点
    const escapeHTML = str => str.replace(/[&<>"']/g, 
        tag => ({
            '&': '&amp;',
            '<': '&lt;',
            '>': '&gt;',
            '"': '&quot;',
            "'": '&#39;'
        }[tag] || tag));
    function highlightTextNodes(element) {
        $(element).contents().each(function () {
            if (this.nodeType === Node.TEXT_NODE) {
                const $this = $(this);
                const text = escapeHTML($this.text());

                // 使用正则替换并保留原始大小写
                if (regex.test(text)) {
                    const replaced = text.replace(regex, '<mark>$1</mark>');
                    $this.replaceWith(replaced);
                }
            } else if (
                this.nodeType === Node.ELEMENT_NODE &&
                !$(this).is('script, style, noscript, textarea')
            ) {
                highlightTextNodes(this);
            }
        });
    }

    $('section').each(function () {
        highlightTextNodes(this);
    });
});

(2025.04.28更新:解决了一个潜在的解析问题)
我测试了一下,非常符合我的需求,各种情况都能按照我的预期工作,虽然说功能非常简单,但是能正常运行,AI写的还是挺不错的。

近期的其他修改

除了对搜索功能的优化,我还做了些别的功能:

随机跳转文章

前段时间我看到有其他人的博客增加了一个随机跳转文章的功能,不过他的博客是动态博客,实现也比较奇葩,是渲染页面时就已经决定好要随机的文章,也就是说无论用户想不想随便看看,程序都已经随机好了。当然用着静态博客的我来说,从原理上也做不到这一点,不过既然我之前在做相似文章推荐功能时已经对搜索功能的数据进行了缓存,那么直接用缓存的内容直接随机就好了吧……所以就随便写了写,代码也极其简单:

<a href="javascript:getSearchJSON(function(data){window.location = data[Math.floor(Math.random()*data.length)].url})">Random</a>

给文章内标题添加锚链接

最近在修改我的博客的时候我更新了一下给文章生成目录的组件,在这时候我想看看它还有什么有意思的组件可以用,然后就发现了jekyll-anchor-headings,它可以像GitHub展示Markdown文件一样在标题上添加点击后就可以直接跳转到对应标题的锚链接,而且示例里也给出了怎么做可以像GitHub的风格。看起来挺有意思,所以就给自己加上了😆。

添加能跳转到原始Markdown的链接

在修改博客的时候我参考了一下Jekyll的官方文档,在这个时候发现了page.path这个变量。我想了一下这个变量可以用来链接到我的文章内容,然后就在文章标签位置的右侧加上了这个链接,为了能让它显示在右侧,我用的是float: right,但是这样会导致和文章标签不在同一行,查了一下才知道用了浮动就会强制将元素转换成块级元素,而文章标签用的是行内元素,所以对不齐,没办法就只能把这一整行都转换成块级元素了……于是代码如下:

<span style="float: right;"><a href="{{ site.github.repository_url }}/tree/master/{{ page.path }}">查看原始文件</a></span>

感想

多看看其他人的博客看来也挺不错,可以看看其他人的想法,说不定就有可以参考的价值呢……不只是文章内容,网站本身的一些功能也是作者的想法啊……而对于那些只套别人模版,没什么自己的改动的博客,那就没什么意思了(当然不会代码的那就没办法了~)。有些人说博客中只有文章才是最重要的,但我觉得对于技术博客来说网站的代码也是展示自己的部分,所以折腾博客本身也是很重要的!

在UTM中使用苹果虚拟化的各种尝试

2025-03-25 00:00:00

用官方的方式做非官方的事!

起因

在几年前刚收到MacBook Pro的时候,我曾安装过虚拟机软件UTM。但是因为我的Mac内存很小,用虚拟机的体验很差,所以就把UTM卸载掉了。不过以前还我还装过一台黑苹果,在上面也安装了UTM。
最近正好由于某些原因我需要在macOS上安装虚拟机,既然有UTM用就继续用UTM了。当然正常情况就是按正常的方式安装系统然后正常的用,这并没有什么意思。所以我想整点有意思的事情,想试试不太正常的使用UTM😝。

在UTM中使用苹果虚拟化框架安装Windows

如果用过UTM的话应该知道,UTM有很多选项,比如底层的虚拟化框架可以用QEMU或者Virtualization.framework(VZ),而QEMU的后端可以选TCG或者是Hypervisor.framework(HVF)。它们有很多特色,像TCG的兼容性最好,可以模拟任何架构的CPU,但是性能最差,HVF使用硬件虚拟化加速,只能运行宿主机架构的程序,但是性能比较好,而VZ经过了苹果官方优化,性能最好。
那么现在我想安装Windows,又想有最好的性能,那我应该选择VZ吧?可是UTM不允许我这样选择,如果选择安装Windows就会强制使用QEMU……只有Linux或者macOS(在ARM处理器)才能使用VZ……那我应该如何绕过这个限制呢?
我想起来之前让没用的主机感染木马的文章中使用了一键DD/重装脚本把我服务器的Linux系统重装成了Windows系统,那么我能不能用相同的方式先按照正常的方式用VZ安装一个Linux系统然后使用这个脚本重装成Windows?我觉得理论上应该没问题,所以就尝试了一下。
我在这之前已经安装过了一个用了VZ的Ubuntu虚拟机,新建比较费时间所以就直接把这个虚拟机复制了一份。然后下载了重装脚本准备重装系统,但是看说明现在不能让脚本自己查找系统镜像安装了,不过没关系,前段时间我下了一份Windows 10的镜像,接下来我只需要在镜像所在目录执行

python3 -m http.server

开启一个文件服务器,然后在虚拟机中执行

bash reinstall.sh windows --image-name "Windows 10 Pro" --iso "http://192.168.64.1:8000/windows.iso"

就可以了,执行后重启就可以在UTM的虚拟机界面中看到脚本执行的一系列操作。在这期间都很顺利,然而在它执行完之后,虚拟机的屏幕就黑了,而且重启也没有任何变化,看来是实验失败了?不过也可能是因为苹果整的虚拟显示器在Windows中识别不出来,所以显示不出东西,因为我看活动监视器中CPU的占用率也在跳变,虚拟机应该仍然在运行,于是我下载了Windows App(以前的远程桌面),使用虚拟机之前的IP进行连接,结果连接成功了😆。看来苹果的虚拟化框架是能运行Windows的嘛,居然没有一个人尝试一下。
不过屏幕不能亮是真的没有驱动吗?我看了眼设备管理器,搜了一下那个没有安装驱动的视频控制器的设备ID“1af4:1050”,好像是Virtio GPU,这个驱动我记得在virtio-win里是有的,而且重装脚本也会自动下载这个驱动,为什么会没有自动安装呢?可能是设备ID和驱动不一致吧……不过不影响,我选择更新驱动,在列表中选择“Red Hat VirtIO GPU DOD controller”之后UTM的虚拟屏幕中就可以看到画面了,虽然分辨率只能是1024*768……不过能用就很不错了。
再接下来我就需要验证一下它的性能是不是最好的,我把这个虚拟机的硬盘复制了一份,新建了一个使用HVF后端的QEMU虚拟机,把这个硬盘挂载上,然后使用国际象棋跑分,看了一下VZ的跑分相比HVF的跑分高了大概5%-10%,还是挺厉害的。
至于其他方面,我看了一眼用HVF的QEMU虚拟机CPU不能显示正确的型号,而VZ是可以的,另外VZ的‌SMBIOS信息中也可以看到Apple的字样,证明这个Windows确确实实是跑在了苹果的虚拟化框架。不过以上的测试都是基于x86架构的macOS,等回头我的Mac Studio到了之后再在ARM架构的macOS上再测一下,看看能不能用相同的方式安装,如果可以的话,说明VZ的虚拟机没什么兼容性的问题,UTM应该放开使用VZ安装Windows的选项,让我们测测苹果的技术才对。

在macOS 12中的UTM使用苹果虚拟化框架安装Linux

虽然在刚刚的测试中,用VZ安装Linux就和其他普通的虚拟机安装Linux一样简单,但是之前的测试是在macOS 15上测的。现在我遇到了一个新问题,我现在有一台2016年的Mac,上面运行着macOS 12,而且不能用OCLP升级到macOS 15(因为不是我的电脑)。现在我想在这台电脑上用苹果虚拟化框架安装Linux,虽然用QEMU更简单,但是感觉没意思。在macOS 12中不支持UEFI bootloader,所以我需要手工准备内核镜像之类的东西。
当然从零开始有点难,我打算先用QEMU安装一遍Ubuntu Server。在创建虚拟机之后需要注意,要把刚创建好的虚拟机的硬盘删掉,因为那是qcow2格式的,在VZ中只支持img格式的硬盘,所以删掉之后需要创建一个“RAW映像”,然后按照正常的方式安装系统。
安装好之后从“/boot”目录中把“vmlinuz”和“initrd.img”复制出来,作为Linux内核和初始Ramdisk,我看说明上要未经压缩的Linux内核映像,但是好像是压缩的也能用🤔。随后关机把在QEMU中的硬盘映像复制出来,作为根文件系统映像。
至于启动参数,可以看“/boot/grub/grub.cfg”中内核后面跟的那串,然后再加上“console=hvc0”,因为macOS 12中使用VZ没有虚拟屏幕,只能用虚拟串口连接。在一切准备好之后就可以开机了,在一串内核信息不停滚动后,显示出了登录的提示符,实验就成功结束了。
不过这样启动的话在系统中所有对内核以及对initramfs的更新就全都不会生效了,毕竟虚拟机根本读不到内核了……这倒是影响不大,反正不更新也不是不能用,更何况macOS都不打算更新,虚拟机不更新又能怎样呢🤣。

感想

看来苹果的“不支持”不代表真的不支持,想想既然是虚拟机,当然就不应该限制系统类型啊,毕竟虚拟机虚拟的是硬件,又不是软件。不过倒是也能理解苹果不需要声明支持自己的竞品,所以也没必要做相应的兼容和测试,但居然没见到有人尝试一下,也挺奇怪,明明用Mac的人也有不少对技术很有探索精神的人啊……
不过随着macOS的更新,像这些非官方支持的办法估计也很有可能出问题,毕竟苹果并不对这些情况进行任何形式的保障,也许以后苹果的哪次更新这个方法就用不了了呢……

关于HiFi的尝试与探索

2025-03-22 00:00:00

如何才能听到最原始的音乐呢?

起因

前段时间,有人在QQ群中送网易云音乐的7天体验VIP,于是随手领了一份。有了VIP之后除了可以下载仅限VIP的音乐以外,还可以选择更好的音质。我现在用的是MacBook Pro,据说在笔记本中音响效果是最好的,那么我为了能对得起这优秀的音响,也不该听垃圾音质的音乐,所以就来探索一下如何听到HiFi的音乐吧。

获得音乐

下载音乐很简单,直接下一个网易云音乐客户端就可以,不过需要注意要在设置中修改下载音质,默认选项不是最高音质。另外它这个VIP还不是最高的,再往上还有SVIP,可以听所谓的“超清母带”的音质,我不太清楚这个无损以上的那些音质到底是什么东西,也不可能为了这点东西给网易云充钱,所以我就选了个“高清臻音”的选项。
当我在下载一些免费歌曲的时候,下载到的文件是flac格式,看起来应该是没什么问题。但是下载VIP独享音乐的时候,正在下载时是flac格式,可是下载完就变成ncm格式了……虽然我知道有一些解密这些格式的软件(GitHub上有,不过好多都被DMCA takedown了,虽然也能搜到一些……),不过我还是比较好奇这个过程,既然它下载时是flac,那我在它刚下载完要变成ncm之前把网易云音乐强制结束掉不就可以获得完整的flac文件了嘛。试了一下还真可以,也就是说这个ncm加密的过程是在客户端完成的,而不是在服务器上,这还真是有点离谱……我用这个方法下载了几首喜欢听的歌,试了一下都能正常播放。不过用这个办法下载的音乐在客户端的下载中看不到,所以就没有歌词之类的东西了。

分析音乐

虽然说下载下来的文件是flac格式,但是不代表这就是无损的音乐。毕竟从网易云音乐的“无损”以上的选项都是flac的,那到底它这个无损是真无损吗?首先我在网上搜了一下,网易云音乐的黑历史很多,有些人在网易云音乐上上传了mp3的音乐,结果也有无损的选项。也就是说它这个flac很有可能是直接用mp3转换格式过来的。那这样我就不愿意了,我可以接受下不到无损,但是不能接受本来是mp3格式然后转成flac结果文件体积大增,给我的硬盘塞一堆没用的数据,所以现在我需要证明刚刚下载的音乐不是一堆没用的垃圾。
我看有人说可以使用spek查看时频谱来验证,如果是直接用mp3格式转换的flac文件会被整齐的砍一刀,因为mp3格式支持的最大采样率是48kHz,而根据香农采样定理,采样频率应该大于等于模拟信号频谱中最高频率的2倍,那么mp3支持的最高频率就是24kHz,所以用mp3转换出来的flac一般会在24kHz那里切一刀,更有甚者,如果是44.1kHz采样率的mp3就会在22kHz左右的位置切一刀。不过理论上人类的听力上限就是20kHz,更高的频率理论上人类应该是听不到。但毕竟我们追求的是HiFi,和人类能不能听到没有关系,要保证的是完整的复刻所有的信息。
于是我在我的Mac上用brew安装了spek,安装好之后直接执行spek+音乐文件的位置就可以了,我看了一下刚刚从网易云上下载的音乐,全都是96kHz采样率的音乐,而且没有被切过的痕迹。那这样就能证明网易云音乐就是真无损了吗?其实我也不知道,因为我没有从发行商直接获得的原始文件,一般要对比原始文件才知道是不是无损的……不过我在网上看说无论是“高清臻音”还是“超清母带”无一例外全都是用AI升频制作的,所以看时频谱已经没有意义了……但是我又没有证伪的方法,那就只能先凑合听喽~

播放音乐

既然音乐已经下好了,那么我直接用我的MacBook Pro播放的音乐它够HiFi吗?虽然我能听出mp3中128kbps和320kbps的区别,但是再高的我也听不出来……不过HiFi要的不是人能不能听出来,而是它发出的声音是不是完美还原。这要怎么证明呢?虽然我没有办法听出来,但如果有可视化的分析至少能看出来,于是我在手机上下载了一款“声音分析仪”软件,它可以用FFT算法分析手机话筒收集到频谱然后展现出来。只是可视化之后……我也很难看出来它够不够HiFi啊,当然理论上如果能保证播放音乐的音响和收听音乐的话筒都是最好的,那么两边的频谱应该是一样的,但是现实中还有底噪的存在,不可能完全一样……虽然如此,但我在看频谱的时候发现,播放的音乐最高频率似乎只有20kHz,我已经测过手机的话筒是能接收到更高的频率的,既然MacBook Pro的音响是最好的,怎么会只能播放20kHz的声音呢?而且它这个20kHz很明显有一刀切的感觉,应该是哪里配置错了。
于是我搜了一下,Mac默认输出的声音貌似只有44100Hz的采样率,需要在“音频MIDI设置”中将扬声器输出的格式改成更高的才能播放更高的频率。不过这也挺奇怪的,44.1kHz的最高频率是22kHz啊,为什么会在20kHz那里砍一刀呢?看香农采样定理所说的是大于等于,也许就是这个原因吧?既然我的音乐都是96kHz采样率的音乐,那么我就应该把这里的设置改成一样的。改完之后又测试了一下,发现确实是突破了20kHz,但好像没有超过22kHz,不过至少没有“砍一刀”的痕迹了,也许是音乐本身就是这样,或者是扬声器最高只能到这个水平了吧。其实我也没有那么追求HiFi,能到这样我已经很满意了。

感想

虽然对人来说也许听HiFi并不能听出来什么,但是追求HiFi还是挺有意思的,毕竟提高还原程度是可以通过可视化的方式看到的,既然如此,那就是有追求的价值。看不见的东西是玄学,可以不去追求,但是HiFi是实实在在存在的,这样也就能理解为什么会有人花大价钱去买各种昂贵的设备来提高还原度了,因为这是真的可以起到作用的啊……当然对我来说,能0成本做到尽可能的HiFi才是最重要的,花钱达到HiFi就没什么必要了🤣。