Cordis 的坑与账
坑是陷人的地方，账是未来要承担的后果。
读不完的话：第 2 节讲它真正做了什么（其实只有一个栈），第 4 节讲它哪里长错了，第 8 节讲你该不该用。
逃离STL方言，又入WIT迷宫：C++与WASM互操作的另一面
逃离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跨编译器兼容性之痛
你看到的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：我那知识渊博，却又满嘴“Bullshit”的架构顾问
现在人人都在吹 AI 怎么提高生产力，怎么“咣咣咣”写代码。但我想从另一个角度聊聊，一个可能有点反直觉的观点：AI 反而让我们在做架构决策时，变得更“慢”了。
就拿我手头正在搞的这个 AI IDE 的 MVP 来说，它是个基于插件的桌面应用。本来嘛，一个 MVP，快速迭代是第一要务。结果你猜怎么着？我的架构来来回回改了三版。
-
**最初阶段：**图个快，直接从一个现成的 React Demo 上手，想着先把功能抽出来再说。简单、直接、粗暴。
-
AI介入与“深刻的翻车”：我问了问 AI，想看看有没有更适合桌面应用的方案。它“热情”地给我推荐了 Quasar 2 (基于 Vue3)。说到这个 Quasar，我就更有话聊了。其实我选它是有“私心”的，因为我以前用 Quasar 1 (Vue 2) 写过一个对话式 UI (CUI) 的核心组件
QInputEx，这个组件的核心就是动态性，比如动态生成和监听事件名。我想着这次正好让 AI 帮我移植到 Quasar 2 (Vue 3) 上，多完美的 AI 应用场景。
结果呢？AI 给我生成了一堆代码“缝合怪”，乍一看像模像样，但跑不起来就不是这么回事，经过几次单元测试后，最基础的组件运行正常，但扩展功能却缺失。更要命的在后头。等我亲手把组件移植成功后，才发现一个致命问题：我组件的核心优势没了。
前端 CSS 框架发展变迁
CSS 框架进化史：从“统一制服”到“乐高无限”，我的样式我做主！
嘿，朋友！你有没有想过，我们每天看到的网页样式，背后其实藏着一部精彩的“进化史”？这不仅仅是代码变来变去，更是一场前端开发者追求**“干活快、看着爽、改得动”**的奋斗故事。
今天，我们就来聊聊 CSS 框架这趟神奇的旅程，看看它是如何从“发统一制服”的管家，一步步变成提供无限可能的“乐高超级工厂”的。
第一站：石器时代救星 (2006-2010) - “求求了，先让它别歪！”
想象一下，在很久很久以前，做网页布局就像在玩“叠叠乐”，你小心翼翼地用 float 堆砌模块，一不小心，整个页面就“哗啦”一下全塌了。更别提还有个叫 IE6 的“大魔王”，总让你的网页在不同电脑上看起来完全不一样。
从头手搓面向应用的AI框架
🌟 从头手搓面向应用的AI框架 🚀
为什么从头手搓 AI 框架，而不是使用现有框架？
💡 为啥我要从头手搓AI框架，而不是直接使用类似 langchain、AutoGen、LMQL 等现成框架呢？
最初我也尝试了多个框架（包括LangChain、AutoGen、LMQL、Outlines、MemGPT等），但它们都无法完全满足我的需求。我想要的是一个极度灵活可配置的AI应用框架，用来打造我设想的「真·AI PC」——而非当前大多数AI产品那种“远程AI服务+本地空壳”的模式。
在当前阶段，我认为面向应用的AI框架应聚焦于提示词（Prompt）的工程化——这是人类与AI交互的唯一桥梁。我的核心目标是：
✅ 将提示词转化为可编程的“函数”或“类”，支持自由组合、独立调用，并能持续迭代优化。
PPE 可编程提示词工程引擎草案开发摘要
Javascript之奇技淫巧 - 如何模拟实现 `super` 访问父类方法的功能
与小学三年级的ChatGPT一起学JS编程
心智为9岁的ChatGPT大约相当于我们小学3年级的学生,所以让我们与小学3年级的ChatGPT一起来深入学习编程吧.
下面是对ChatGPT的第一次提问:
你知道吗?编写一个js函数模拟实现 super 访问父类方法的功能有几种方法?
要求:该函数的调用方式要从语法上尽可能的接近原生super的调用方式,实现尽量简洁明了.
约定该函数名以及函数签名(返回值根据具体实现方式而定)为: getSuper(instance: Object)
每一种方法都必须用该函数签名来实现,并具体说明,哪一种方法从语法上最接近原生super.
我看 ChatGPT：人类在作死还是在创造生命
我看 ChatGPT：人类在作死还是在创造"生命"
我的感受
最近这几个月，我一直在断断续续的使用ChatGPT. 并对它有了一些感受,首先感觉就是笨,智力有限,就像一个8、9岁孩子的智商一样；但是另一方面，我发现ChatGPT的知识面非常广泛，它似乎可以对几乎所有的话题都能够做出头头是道的回答。当然ChatGPT同样也是经常犯错,而且错得是一塌糊涂，但是我却从中总感觉到它是在真的在思考.
我不知道它的思考能力到底是从何而来，也很难想象一个“机器”可以像人一样去思考。但我知道ChatGPT是基于Transformer架构的语言模型。在产生回答时，它所依赖的是从大规模的文本语料库中学习得到的统计模式和规律，通过计算预测下一个词汇的概率来生成下一步的预测和生成的结果。
ChatGPT并不是基于真正的自然语言理解和知识图谱技术开发的。在它的“脑子”里并没有可供查询的知识库和推理算法，全是通过模型参数进行预测和生成回答。谁也没想到，这样的方式居然能够推理、解决问题，甚至产生出类似于心智的能力。