Gaubee's Feed

pnpm-pub 的窗口已经最小化，托盘菜单却还写着 Hide Window。这个小 bug 逼着我们重新区分托盘图标、原生窗口与 WebView 会话，也重新定义 show、close、destroy、autoHide 和“可见”。

pnpm-pub 想要一个带 Acrylic 材质的透明托盘窗口，结果 resize 时留下了整片旧画面。我们把 WebView 缩到九分之一，又一路查到 HWND、DWM、重定向表面和非客户区，最后才弄清 Windows 到底怎样把这个窗口画到屏幕上。

通过在移动出行、媒体和健康领域掌握主导权，实现5G变现的大胆设想

1. 战略要务：从“哑管道”到垂直巨头

本节定义了电信运营商（以下简称“运营商”）传统模式所面临的根本问题，并论证了为什么垂直整合这种激进的变革不再是可选项，而是关乎生存和增长的必需。

1.1. 战略危机：互联世界中的增长停滞

运营商行业正面临一个根本性挑战：其核心产品（即连接服务）已高度同质化 1。尽管在人工智能 (AI) 和数字服务的推动下，数据流量呈爆炸式增长 3，但运营商却发现，将流量增长转化为收入增长，即提高每用户平均收入 (ARPU)，变得异常困难 4。

金融市场的表现清晰地反映了这一困境。在2024年，电信股的价值增长约11%，远远落后于标普500指数 (约25%) 和纳斯达克指数 (约30%)，这表明市场对其增长前景缺乏信心 5。行业预测显示，到2028年，全球电信业收入的复合年增长率 (CAGR) 预计仅为2.9%，甚至低于预期的通货膨胀率 1。

这就是经典的“哑管道”(Dumb Pipe) 陷阱 6。运营商斥巨资建设5G等先进基础设施 5，而亚马逊 (AWS)、谷歌等“OTT”(Over-the-Top) 巨头则在这些网络之上提供服务，攫取了绝大部分利润 7。普华永道 (PWC) 的一项调查显示，55%的电信业CEO认为，如果继续沿用当前的商业模式，他们的公司将无法在未来十年中生存下来 9。

Kimi-Linear 是符合直觉的一个工程优化（所以大概率会在未来的其它开源模型上普遍使用）。

k2的上下文不是256K吗，这次变成1M，之所以*4是因为它只做了1/4的全局注意力，所以运行成本相对来说涨幅就没那么剧烈。

传统全注意力机制是，一个新的token得和之前所有的token全部计算一遍。所以成本是平方增长。 因为训练有很多层，它就保留1/4的层（MLA）还继续做这种全注意力机制。 剩下的3/4的层（KDA）就做固定大小的计算。

这3/4的层毕竟是要“遗忘”的，因为大小固定。

我前几天做Chrome-EXT开发的时候，遇到一些坑。 Chrome扩展是有好几个沙盒环境一起协同工作的，如果你之前做过 IOS-WebView 的二次开发，应该有印象： JavaScript的注入，是有“World”概念的，默认是MAIN-World，这个就是网页的默认js执行环境。 然后还能自定义World，这种属于ISOLATED-World，和MAIN-World在同一个线程里面，但是内存是完全隔离的，类似于在一个独立的iframe环境中。

MAIN-World 有非常严格的安全限制。比如我就不能再MAIN-World里面去发起 ws://localhost 的链接。因为Google的网页非常注重安全，都会开启“内容安全协议限制”，比如不能Eval、new Function；以及MAIN-World的资源来源会有域名限制；甚至不可以和Chrome扩展的Servical-Worker通讯。

所以必须是这样的通讯路径： “网页脚本（MAIN-World） ⇄ content-script（ISOLATED-World） ⇄ background/service-worker” “网页脚本（MAIN-World） ⇄ content-script（ISOLATED-World） ⇄ backend-server/websocket”

看了一下 Cap’n Web 的源代码，相比Comlink它更专注于“网络协议”的优化。

Comlink的特性是参考 MessageChannel 去做Endpoint设计，而这种设计非常原始纯粹， 也就导致很多东西是有心智负担的。 比如MessageChannel 是有对象所有权传输的能力，实际写代码的时候，你得用Comlink提供的接口来对U8A对象标记成“直接传输到另外一个线程”。 但这种设计并不是所有适配器都会去实现（参考 GitHub - kinglisky/comlink-adapters ）所以用起来的时候，使用者得注意，自己现在在什么环境里面，要传输什么东西？传输的东西是一个代理对象？还是克隆对象？

而 Cap’n Web 的定位是 RPC，其实就是类似执行一次http-req，这意味着没有后续的副作用。这个概念很重要！比如说，Comlink默认返回的对象还是一个Comlink对象，可以继续链式调用，除非主动标记Comlink.clone(returnValue)让它强制走克隆的逻辑。因此这里可以看出它们的定位和策略上的偏差。Cap’n Web 更适合网络环境。

但是总的来说 Cap’n Web 为RPC这种网络场景做了定向优化。同时还补充了一些特别的功能，比如Promise流水线化。以及它的 RpcTransport 适配器设计实现起来非常简单。

一种受生物学启发的AI架构理论框架：从神经元到生命体

摘要： 本文提出了一种新颖的人工智能系统架构理论，该理论借鉴了生物神经系统的层次化组织结构。我们依次定义了三个核心概念：作为基本计算单元的 AI 神经元 (AiNeuron)、作为功能模块的 AI 神经簇 (AiNerveFascicle)，以及作为自主、持久化系统的 AI 生命体 (AiLifeform)。本框架旨在通过模块化、功能特化和动态自组织的原则，为构建更复杂、更鲁棒、更具适应性的人工智能系统提供一个可行的理论基础。

1. AI 神经元 (AiNeuron)：基本计算原语的定义

1.1 形式化规范

AiNeuron 被公设为本理论框架中最基础的、不可再分的计算单元。其核心功能是基于大规模语言模型（LLM）的统计预测能力，对输入事件（events）进行处理并产生输出。其最泛化的接口可形式化定义为一个高阶函数：

type AiNeuron = (

试用了 Aider ，这东西的定位就类似 Trae 这样的编辑器。主打就是一个协同开发。

坑是一个没少：

1. 不支持MCP

   不过这个难度不高，早晚是能支持的

2. 好像没有使用RAG，而是提供了一个目录结构给LLM，让LLM自己判断要读取哪些文件。

   这种做法效率并不高。架构如果不好，或者遇到特殊开发需求，就得靠开发者自己来做文件选取。 我之前看过openAI的另外一种做法，也不使用RAG，而是将所有内容和“选取条件”喂给小模型，让小模型来判断文件中的哪些内容是和“选取条件”有关系的，这个过程是可以拆分并发执行的。 然后再用标准模型来对最终选取出来的内容做任务。

2025年了，还是要吐槽一下compose（CMP）写桌面，目前体验并不好。

1. 目前没有pure-native方案，只有jvm，因此起步体积就不小（社区中有老哥自己在搞linux-native的方案，但还在alpha阶段）。
2. 然后没有成熟的开源webview方案（不是没有，而是不成熟），只有一个闭源付费的jxbrowser（有着高性能的compose渲染支持；还有线程安全的支持；对接口的提供也非常丰富）。
3. 再有因为底层基于swing，因此一些先进的原生窗口功能就没有，社区也不活跃，非要的话只能自己搞jni。（比如说右键菜单，文件选择器，系统托盘都是swing那套，有兴趣的找个网图就知道有多丑了，而且连一些基本的字体适配也不是很好）

我个人建议：

1. 如果是轻量的compose应用，那么可以考虑直接走compose-web+electorn的方向，至少底层工具链是现代化的。compose-web虽然也很糟心……
2. 但我是说“轻量compose应用”，如果你的应用有原生图层混合，或者使用了复杂的kotlin协程，那就不算轻量。这时候还是只能老实走compose-jvm。那么我上头提到的那些问题一个都逃不掉。

这两天正式接触了一下 MoonBit，尝试将一个大约 1000 行的 C 语言编写的 JS Parser 转译成 MoonBit 语言。 聊一下我的客观感受：

1. 前期最大的困境其实是文档的完备性。我不仅阅读了官方文档，还研究了官方 GitHub 上的 core 包源码，但仍然觉得其中有很多细节没有完整地整理出来。
   1. 但总体来说，MoonBit 给我的感觉像是 Rust 的一个更“干净”的版本。
   2. 语法挺“干净”的。之所以会这样说，是因为在开始接触之前，我断断续续关注官方发布的新闻或博文，当初曾疑惑这门语言为何一直在增加语法糖。但实际使用起来发现并不繁琐，反而觉得这些语法糖设计得恰到好处，且整体规则清晰。
2. MoonBit 号称是“AI 友好的编程语言”，但在官方的（VS Code）插件中，我看到的内置 AI 提示词内容还比较基础（大约 500 行主要用于介绍基本语法）。相比之下，直接将官方 Markdown 文档喂给大型语言模型可能更有效率。在官方 AI 提示词的基础上尝试修复我遇到的一些问题时，往往只能解决表面现象，更深层次的转换仍需依赖 AI 模型自身的能力，而非这部分预设的提示词。
   1. 最大的差异在于“模式匹配”的运用。C 语言编写的 JS Parser 通常采用移动指针、逐个字符判断的风格，这与 MoonBit 所推崇的模式匹配风格有所不同。虽然 MoonBit 也能像 C 语言那样进行字符级解析，但要发挥编译器的优势，还是应该多使用模式匹配。目前，AI 在将这种指令式代码自动翻译成更偏声明式的模式匹配风格方面表现不佳，因此多数情况下，这种转换仍需要人工进行。
3. LSP 的速度和稳定性没有达到我的预期。当使用 AI 生成代码并进行快速修改时，LSP 服务偶尔会卡死（例如，VS Code 插件长时间无响应）。对于我尝试的这个千行级别的项目，LSP 的分析速度也未如想象中迅速，或许是项目体量还不够大，未能充分体现其性能优势。