划重点：

为什么支持 Extension 这么困难：

> 开始动手之后发现，这的确是一个非常庞大的项目。普通的功能一般都是按周来计算或最多按月来计算的，而 Extension 这个功能得是按年来计算的。最终我们花了一年多的时间，才让 Extension 成功登陆了 Edge Android 平台。

为什么 Kiwi 停更：

> 对于 Arnaud 来说，这个项目经过几年维护已经趋于稳定，他不太想继续花更多精力只是在维护上面，而是想要尝试其他更有挑战性的项目。

为什么 Kiwi 给 Edge 官方站台：

> 我也将（实现 Extension ）这中间的很多辛酸历程都写在了上面的那篇文章里，[...] Kiwi 浏览器的作者居然也看到了这篇文章，并且就是因为这篇文章，巧合般地让 Kiwi 和 Edge 建立了联系。
> 现有的 Kiwi 用户怎么办呢？这时 Arnaud 想起了我之前写的文章，他认为 Edge Android 已经很好地支持了 Extension 功能，成功接过了 Kiwi 的接力棒。
> Kiwi 的这一突然声明把我们也搞了个措手不及。

给楼上补个链接： https://learnxinyminutes.com/zh-cn/go/

Go 本身简直太简单了，几个我初学时觉得比较迷惑的点：

- channel 的行为，select 和 context
- goroutine 的同步
- package 的组织方式
- 错误处理
- 数组和切片的差别
- interface 对象的类型擦除和泛型的实现方式

1. 要省电就上硬件 DSP 方案，但很难搞，需要底层框架支持，可以看这个： https://source.android.com/docs/automotive/voice/voice_interaction_guide/app_development?hl=zh-cn#dsp-hotword-detection

2. 没 DSP 的话有软件指令检测，文档也在上面链接里。缺点是还是需要底层框架支持，优点是不会一直占用麦克风，耗电稍微低一些

3. 底层框架也没有的话，就只能纯软件识别了，缺点就是会一直占用麦克风。方案看 #1 发的

很多人用了 Linux DE 才知道桌面占用还能这么低。

https://everybytecounts.org/

很有用，star 了

@Vanson 看了下，这个真实性比之前那个不明所以的「打假」高不少。

另外，上面那个删号跑路的作者又重新注册账号回来了，和这篇发帖者同一天注册账号： https://github.com/HonestyAGI/LLM-Fingerprint

有点罗生门了，我不靠谱地推测：是不是内部部门角力在先，再有这个所谓 HonestAGI 画标打靶，然后被华为拿下（或者发现错误过多先撤一步），最后内部员工亲自站台小作文、恢复名誉……

---

为防止被有心人断章取义，免责声明：以上言论纯属猜测，学术的归学术，政治的归政治。LLM-Fingerprint 这篇目前还看不出什么科研价值；你要来攻击我华为水军，不妨看看我历史言论怎么评价这家公司。

连简介都懒得自己写的，项目质量估计也从没关心过。先 block 为敬。

@w568w 再补：简单看了一下 paper ，格式倒是没啥问题，看来我之前被知乎的二手截图毒害了。不过其他事实依然成立。

这个方法依然很抽象。论文 References 不足一页（ Page 10 ），还花了一页洋洋洒洒指责华为（ Page 8-9 ）。对于同源的模型，他这个方法也没有测出相似性（ Figure 3 ）。从第三方实验来看，Qwen 和 Baichuan 算出的相似度也有 0.9 ，所以 Baichuan 也跨时空抄千问了？

@w568w 补充：找了个 fork 仓库，这里看得更清楚 https://github.com/Iamlovingit/LLM-Fingerprint

怎么现在才问？ HonestAGI 这三无作者自己都删库跑路了……

一些事实：

- 两天前注册 GitHub ，只有这一个仓库

- 作者自称韩国人，但 Research Gate 和 Google Scholar 什么都搜不到

- 整个 README 都像 AI 生成的，AI 特有的 emoji 滥用、比喻乱飞、感叹号洗地

- 证明方法是把每一层输出的方差算出来然后算相似度，当时看了一眼就感觉不对。根据第三方实验，按他这个算法，几乎所有国内外模型全都抄 Qwen 了，纯搞笑

- 论文格式千疮百孔，像根本没做过学术研究的人用 AI 写的

仓库存档： https://web.archive.org/web/20250704072325/https://github.com/HonestAGI/LLM-Fingerprint

这个是设计问题，因为 Python 本来就是快工出糙活的语言，讲究一个快速迭代、原型验证。

你说的这种方式在 AI 相关项目中最常见，因为一开始设计的时候没有想清楚需要哪些配置（这一阶段也没有必要考虑，因为根本不知道会不会有用户），后面需求随着用户量一起复杂起来，本着最小修改的倾向，自然就会开始在上下文对象上挖洞，添加各种可变属性或者更复杂的机制。直到最后阶段把 config 变成巨型克苏鲁，不得不重构。

所以，你的问题不是 Python 问题，是工程学问题。再往大了说，先积累后清扫是人类思维的惯性。

> Flutter [...] 昙花一现

Flutter 咋就昙花一现了？我观察身边从原生转 Flutter 的人最近几个月越来越多，Flutter 的生态也一直在发展，还有一个比原生语言拟人多得多的中心仓库（ pub.dev ），基本啥都能搜到。为什么我看 V 站天天说「 Flutter 已死」？ Flutter 到底哪里快死了？哪家媒体说的？（非阴阳怪气，真心请教）

@chinanala 谢谢分享，我自己平时临时用也这样。但场景不是很一样，有两个问题不好解决：

1. 受 SSH 连接质量和连接处的上传带宽限制。比如网络不稳定的时候，下载大文件途中 SSH 可能会断；或者比如我家宽上行只有 40Mbps ，隧道代理下大文件要老命了……

2. 不适合需要挂后台运行的联网进程。有时候可能要在服务器上起一个服务或者长时操作（比如 pip install 、docker build ），用 SSH 只能挂在那边等着，有事也不方便带走电脑

@w568w 更新：除了 2 不知道原因，3 已经记录在 https://github.com/w568w/pproxy/issues/1 ，其他几个功能都实现了。