逃离STL方言，又入WIT迷宫：C++与WASM互操作的另一面

本以为逃开 C++ 跨编译器的“方言”问题，投奔 WASM 的标准化怀抱就能一身轻松。结果，一脚踩进了 WIT（WebAssembly Interface Types） 的坑里，发现这里的水也挺深。

事情得从 WASI(WebAssembly System Interface) 说起。它的初心很简单：把系统调用封装成 wasm 能用的函数。早期版本（WASI Preview1）直接用 i32/i64 这类底层类型当指针或句柄，配上 C ABI，虽然粗糙但直接。问题出现在大家想用它正经传递点高级数据——比如在不同语言间传个字符串或数组。这时候，光靠“指针+长度”的裸奔模式就顶不住了，内存布局、编码、生命周期管理……每个环节都可能对不上。

于是 Preview2 登场，带来了 WIT 和 Component Model，想用一套中立的接口描述语言来解决类型互操作。理想很宏大：写一份 .wit 文件，工具链自动生成各语言的打包/解包代码，实现跨语言无缝调用。可惜，目前它还处在“测试阶段”，生态和工具链都在追赶中，而且一个明显的现实是：这套模型目前在 Rust 生态外能用得非常有限。

更让我觉得有趣（也有点困惑）的是，Component Model 在全局初始化、导入导出这些设计上，竟和我自己设计的 ISDK 语言思路高度相似。这种共鸣感一闪而过，随即被一个根本性质疑取代：你作为基于字节码的底层虚拟机，难道不应该优先确定最稳定、最基础的 ABI 吗？ 现在这种先定义上层组件模型、再让底层去适应的方式，感觉顺序有点倒置了。

你看到的std::string，不是同一个std::string —— C++ STL跨编译器兼容性之痛

说实话，最近被 C++ 的 STL 跨编译器兼容性搞得有点头大。本来在琢磨一件挺酷的事儿：能不能把 LLVM 字节码当作运行时跨平台的手段？比如把带 STL 类型的 C++ 代码编译成 LLVM IR，到哪儿都能跑，岂不美哉？

结果一上手就发现，理想很丰满，现实很骨感。先不说 32/64 位、字节序这些老生常谈的问题，光是 STL 这一关就过不去。

首先一个扎心的事实：不同编译器用的 STL 根本就不是一回事。

• GCC 用的是 libstdc++；
• Clang 默认用的是 libc++，也可以指定用 libstdc++；
• 微软的 MSVC 有自己的 STL 实现，叫 MSL(Microsoft Standard Library)；

AI：我那知识渊博，却又满嘴“Bullshit”的架构顾问

现在人人都在吹 AI 怎么提高生产力，怎么“咣咣咣”写代码。但我想从另一个角度聊聊，一个可能有点反直觉的观点：AI 反而让我们在做架构决策时，变得更“慢”了。

就拿我手头正在搞的这个 AI IDE 的 MVP 来说，它是个基于插件的桌面应用。本来嘛，一个 MVP，快速迭代是第一要务。结果你猜怎么着？我的架构来来回回改了三版。

1. **最初阶段：**图个快，直接从一个现成的 React Demo 上手，想着先把功能抽出来再说。简单、直接、粗暴。

2. AI介入与“深刻的翻车”：我问了问 AI，想看看有没有更适合桌面应用的方案。它“热情”地给我推荐了 Quasar 2 (基于 Vue3)。说到这个 Quasar，我就更有话聊了。其实我选它是有“私心”的，因为我以前用 Quasar 1 (Vue 2) 写过一个对话式 UI (CUI) 的核心组件 QInputEx，这个组件的核心就是动态性，比如动态生成和监听事件名。我想着这次正好让 AI 帮我移植到 Quasar 2 (Vue 3) 上，多完美的 AI 应用场景。

结果呢？AI 给我生成了一堆代码“缝合怪”，乍一看像模像样，但跑不起来就不是这么回事，经过几次单元测试后，最基础的组件运行正常，但扩展功能却缺失。更要命的在后头。等我亲手把组件移植成功后，才发现一个致命问题：我组件的核心优势没了。

CSS 框架进化史：从“统一制服”到“乐高无限”，我的样式我做主！

嘿，朋友！你有没有想过，我们每天看到的网页样式，背后其实藏着一部精彩的“进化史”？这不仅仅是代码变来变去，更是一场前端开发者追求**“干活快、看着爽、改得动”**的奋斗故事。

今天，我们就来聊聊 CSS 框架这趟神奇的旅程，看看它是如何从“发统一制服”的管家，一步步变成提供无限可能的“乐高超级工厂”的。

第一站：石器时代救星 (2006-2010) - “求求了，先让它别歪！”

想象一下，在很久很久以前，做网页布局就像在玩“叠叠乐”，你小心翼翼地用 float 堆砌模块，一不小心，整个页面就“哗啦”一下全塌了。更别提还有个叫 IE6 的“大魔王”，总让你的网页在不同电脑上看起来完全不一样。

🌟 从头手搓面向应用的AI框架 🚀

为什么从头手搓 AI 框架，而不是使用现有框架？

💡 为啥我要从头手搓AI框架，而不是直接使用类似 langchain、AutoGen、LMQL 等现成框架呢？

最初我也尝试了多个框架（包括LangChain、AutoGen、LMQL、Outlines、MemGPT等），但它们都无法完全满足我的需求。我想要的是一个极度灵活可配置的AI应用框架，用来打造我设想的「真·AI PC」——而非当前大多数AI产品那种“远程AI服务+本地空壳”的模式。

在当前阶段，我认为面向应用的AI框架应聚焦于提示词（Prompt）的工程化——这是人类与AI交互的唯一桥梁。我的核心目标是：
✅ 将提示词转化为可编程的“函数”或“类”，支持自由组合、独立调用，并能持续迭代优化。

2025年1-3月

内建LLM提供商

当前，外置的llama-cpp server已经满足不了我的需求:

1. 无法动态加载切换LLM大模型
2. 无法对提示词进行安全控制
   1. 系统模板反注入
   2. 提示词保护
3. 无法自动适配硬件: 自动检测内存和GPU，并默认使用最佳计算层，自动分配gpu-layers以及上下文窗口大小, 以便从硬件中获得最佳性能，无需手动配置任何内容。
4. 无法为指定的单词提升/降低权重，类似在stable-diffusion中（暂未实现）

因此开发实现了内置的本地LLM提供商.

与小学三年级的ChatGPT一起学JS编程

心智为9岁的ChatGPT大约相当于我们小学3年级的学生,所以让我们与小学3年级的ChatGPT一起来深入学习编程吧.

下面是对ChatGPT的第一次提问:

你知道吗?编写一个js函数模拟实现 super 访问父类方法的功能有几种方法?

要求:该函数的调用方式要从语法上尽可能的接近原生super的调用方式,实现尽量简洁明了.
约定该函数名以及函数签名(返回值根据具体实现方式而定)为: getSuper(instance: Object)
每一种方法都必须用该函数签名来实现,并具体说明,哪一种方法从语法上最接近原生super.

我看 ChatGPT：人类在作死还是在创造"生命"

我的感受

最近这几个月，我一直在断断续续的使用ChatGPT. 并对它有了一些感受,首先感觉就是笨,智力有限,就像一个8、9岁孩子的智商一样；但是另一方面，我发现ChatGPT的知识面非常广泛，它似乎可以对几乎所有的话题都能够做出头头是道的回答。当然ChatGPT同样也是经常犯错,而且错得是一塌糊涂，但是我却从中总感觉到它是在真的在思考.

我不知道它的思考能力到底是从何而来，也很难想象一个“机器”可以像人一样去思考。但我知道ChatGPT是基于Transformer架构的语言模型。在产生回答时，它所依赖的是从大规模的文本语料库中学习得到的统计模式和规律，通过计算预测下一个词汇的概率来生成下一步的预测和生成的结果。

ChatGPT并不是基于真正的自然语言理解和知识图谱技术开发的。在它的“脑子”里并没有可供查询的知识库和推理算法，全是通过模型参数进行预测和生成回答。谁也没想到，这样的方式居然能够推理、解决问题，甚至产生出类似于心智的能力。

智能家居硬件采购避坑指要(四) HA盒子

HA是跑在PC上还是盒子里,这是个问题!

• PC性能远远强于盒子: CPU主频高(至少都是2G以上)核心多(8-16Cores),内存足(16G-64G),硬盘大
• PC的功耗也远高于盒子,盒子功耗低

因此如果不在乎功耗和硬盘损耗,以及能够保持24小时开机(不能离线),无脑PC即可.

PC的问题

智能家居硬件采购避坑指要(三) 蓝牙设备

蓝牙特性

1. 短距离通信：蓝牙技术的通信范围通常为10米以内
2. 蓝牙信号穿墙能力有限,除非你购买BLE蓝牙网关中继设备,而且更容易受到干扰,尤其是不带自动跳频的蓝牙.
3. 能耗相对较低：因为低功耗蓝牙设备在省电上还是比不过Zigbee设备,BLE蓝牙5.0在省电上与zigbee很接近了.
   • 因此: 为了省电,米家的温度传感器(LYWSD03MMC)是大约10分钟发送一次数据,如果不刷第三方固件,想与空调联动就不要想了.
4. 简单易用：智能家居蓝牙设备使用普及度高的蓝牙协议，用户不需要额外的网关或路由器即可连接和控制设备
5. 目前蓝牙协议大多数是私有协议，互通性较差,HA无法直接控制,只有少量的特定厂家的低功耗蓝牙传感设备才能通过第三方Passive BLE Monitor 集成 直接接入HA,支持的设备详见下方的支持列表.
6. 价格便宜:由于蓝牙技术在手机和其他消费电子设备上得到广泛应用，智能家居蓝牙设备的成本相对较低。

第三方Passive BLE Monitor 集成

注意: 最新HA版本(2022.8以后)的官方蓝牙集成开始直接支持Passive BLE 设备,目前还在移植更多的蓝牙设备.官方蓝牙集成不能与BLE Monitor集成同时工作!请做好选择,官方蓝牙集成同样支持蓝牙网关.