2026-03-11

内容摘要

这篇文章旨在驳斥当前围绕人工智能（AI）的一些过度炒作和焦虑，并提供一种更理性的视角。

核心观点：

• AI并非魔法： AI的发展是技术进步的延续，并非像科幻小说中描述的“递归”或“魔法”。它本质上是搜索和优化技术的进步，与之前就已经存在的技术有内在联系。
• 避免零和博弈： 作者认为，当前裁员的真正驱动力并非AI本身，而是大型企业为了巩固自身的“寻租”行为（创造复杂性给他人牟利）。这种寻租行为本质上是零和博弈，最终会被更强大的参与者淘汰。
• 创造价值才是关键： 作者强调，应该专注于为他人创造价值，而不是过度关注回报。只要创造的价值大于消耗，就能融入健康的社区。
• 对抗比较陷阱： 避免陷入比较和过度竞争的陷阱，不要被那些告诉你必须不断追赶才能生存的观点所迷惑。世界并非“红皇后赛跑”式的无尽竞争。
• 警惕被淘汰的职业： 如果你的工作是通过制造复杂性来获取利益，那么你可能会被AI取代，应尽早考虑改变。

总结：

总而言之，文章呼吁大家保持冷静，理性看待AI，避免被焦虑情绪裹挟。与其担心落后，不如专注于创造价值，避免参与零和博弈，从而在快速变化的世界中找到自己的位置。

2026 年 Zig 开发日志

以下是 2026 年 Zig 主分支的近期更改摘要：

2026 年 3 月 10 日：类型解析重设计，并进行相应的语言更改

• 作者：Matthew Lugg
• 合并了一个 30,000 行的 PR（https://codeberg.org/ziglang/zig/pulls/31403），旨在重构 Zig 编译器内部的类型解析逻辑，使其更具逻辑性和条理性。
• 主要改进：
  • 编译器现在在分析类型的字段时更加懒惰：如果类型未初始化，则 Zig 不需要关心该类型的“外观”。这对于将类型用作命名空间的情况非常重要。
  • 改进了“依赖循环”体验：遇到依赖循环错误时，将获得详细的错误消息，说明循环的来源。
  • 显著改进了 Zig 编译器的“增量编译”功能，修复了大量已知错误，并几乎消除了“过度分析”问题，从而显著加快了许多情况下增量编译的速度。

2026 年 2 月 13 日：io_uring 和 Grand Central Dispatch std.Io 实现落地

• 作者：Andrew Kelley
• Jacob 将 std.Io.Evented 更新到最新 API 变更：
  • 实现了 io_uring
  • 实现了 Grand Central Dispatch
• 这些实现基于用户空间的堆栈切换（也称为“纤维”、“堆栈式协程”或“绿色线程”）。
• 状态： 实验性，需要进一步完善（更好的错误处理、移除日志、诊断 IoMode.evented 性能问题、实现未实现的函数、增加测试覆盖率、内置函数以获取给定函数的最大堆栈大小）。
• 现在可以通过构建应用程序时使用 std.Io.Evented 来使用它们。

2026 年 2 月 6 日：两个包管理工作流程增强

• 本地存储： 依赖包现在存储在项目根目录下的 zig-pkg 目录中。建议将其添加到项目本地源代码控制忽略文件中。
• 全局缓存： 依赖包的副本也会存储在全局缓存中，并进行压缩。
• --fork 标志： 添加了 zig build --fork=[path] 标志，允许覆盖整个依赖树中的项目，以便进行临时修改和测试。

2026 年 2 月 3 日：绕过 Kernel32.dll

• 作者：Andrew Kelley
• Zig 团队正在努力减少对 kernel32.dll 的依赖，并尽可能使用更低级别的 ntdll.dll API。
• 示例：
  • Entropy： 避免了对 advapi32.dll 和 bcryptprimitives.dll 的依赖，并减少了首次 RNG 读取的延迟。
  • NtReadFile 和 NtWriteFile： 避免了 kernel32.dll 包装器引入的不必要开销，并允许更灵活的 I/O 控制。

2026 年 1 月 31 日：zig libc

• 作者：Andrew Kelley
• 正在逐步删除 Zig 仓库中冗余的 C 源代码文件，并将其替换为 Zig 标准库包装器。
• 优点： 提高 Zig 的独立性、编译速度、简化安装、减小静态链接 libc 的二进制文件大小。
• ZCU 集成： 将 libc 函数与 Zig 编译单元集成，以消除冗余代码并实现更有效的优化。
• 建议： 如果在使用 Zig 时遇到与 musl、mingw-w64 或 wasi-libc 相关的错误，请在 Zig 报告错误。

注意： 此摘要仅包含原始内容中提供的信息，不包含个人意见或额外信息。

摘要：利用验收标准验证 AI 生成的代码 (Summary: Verifying AI-Generated Code with Acceptance Criteria)

本文讨论了在人工智能 (AI) 驱动的代码生成过程中，如何验证代码正确性的挑战。作者指出，随着 AI 代理自主性的提高，传统的代码审查变得越来越难以应对，仅仅依赖部署观察并祈祷不出错已经不够。

核心问题：

• 信任危机： 如何在无法全面审查代码的情况下，确保 AI 生成的代码符合预期？
• AI 自我验证的局限性： 使用 AI 编写测试用例来验证自身代码，本质上是自我祝贺，无法发现最初的设计理解错误。
• 传统代码审查的不足： 即使是人工代码审查，也难以跟上 AI 代码生成的速度，并且让资深工程师专门审查 AI 生成的代码效率低下。

解决方案：借鉴 TDD (测试驱动开发) 的思路

作者建议借鉴 TDD 的核心思想：在编写代码之前，先明确定义“正确”的期望，并进行验证。具体方法是：

1. 编写验收标准 (Acceptance Criteria)： 在编写代码之前，用通俗易懂的语言描述功能应有的行为，例如“用户使用正确的凭据登录后，应跳转到 /dashboard”。
2. AI 代码生成： 让 AI 代理 (如 Claude Code) 根据验收标准生成代码。
3. 自动化验证： 使用自动化工具 (如 Playwright) 执行验收标准，对生成的代码进行验证。对于前端，通过浏览器截图验证；对于后端，通过 API 行为验证 (例如状态码、响应头、错误信息)。
4. 仅审查失败： 集中精力审查验证失败的场景，而不是整个代码 diff。

实践案例：

作者分享了使用验收标准验证前端代码的例子，包括：

• AC-1: 成功登录后重定向到 /dashboard 并设置 Session Cookie。
• AC-2: 使用错误密码显示 "Invalid email or password" 错误信息，并保持在 /login 页面。
• AC-3: 在任何字段为空时禁用提交按钮，并显示Inline错误。
• AC-4: 连续5次登录失败后，登录被锁定60秒，并显示等待信息。

技术实现：

作者开源了一个名为 opslane/verify 的 Claude Skill，该 Skill 使用 Claude Code 的 headless 模式 (claude -p) 和 Playwright MCP 实现，无需额外的 API 密钥。其工作流程包括：

1. Pre-flight: 检查开发服务器状态、身份验证会话、以及 spec 文件是否存在。
2. Planner: 使用 Opus 模型分析 spec 文件和代码变更，确定每个检查的必要性和运行方式。
3. Browser agents: 使用 Sonnet 模型并行运行多个浏览器代理，执行验收标准并截屏。
4. Judge: 使用 Opus 模型分析所有证据，并为每个验收标准返回通过、失败或需要人工审查的 verdicts。

总结：

作者强调，要信任 AI 生成的代码，必须在代码生成之前明确定义“完成”的标准。虽然编写验收标准可能一开始感觉比较慢，但它能显著提高代码质量，并使审查工作更有效率。这种方法并非保证代码完全正确，但能可靠地发现集成失败、渲染错误和实际运行中的行为问题。

中文关键词： AI 代码生成, 代码审查, 验收标准, 测试驱动开发 (TDD), Claude Code, Playwright, 自动化测试

RCLI 总结 (Summary of RCLI)

RCLI 是一款专为 macOS 设计的本地语音 AI 工具，基于 Apple Silicon 芯片运行，无需连接云端或使用 API 密钥。它整合了语音识别 (STT)、大型语言模型 (LLM) 和语音合成 (TTS) 三个关键环节，实现了流畅的语音交互体验。

核心功能:

• 本地运行: 所有处理都在设备本地进行，保护隐私。
• 快速响应: 端到端延迟低于 200 毫秒。
• 38 个 macOS 操作: 通过语音控制 Spotify、调整音量等 38 个 macOS 功能。
• 本地文档问答 (RAG): 可以对本地文档进行索引，并用语音提问，实现高效的信息检索。
• 交互式终端界面 (TUI): 提供友好的终端界面，支持语音输入、模型管理、动作浏览等功能。

技术细节:

• MetalRT GPU 加速: RCLI 采用 RunAnywhere, Inc. 开发的 MetalRT GPU 推理引擎，在 Apple Silicon 芯片上实现高性能，尤其适用于 M3 及更高版本的芯片。在 M1/M2 设备上会回退到 llama.cpp 引擎。
• 模型支持: 兼容多种 LLM (如 LFM2, Qwen3)、STT (如 Whisper, Zipformer)、TTS (如 Piper, Kokoro) 等模型，用户可以根据需求选择和切换。
• 语音处理流程:
  • VAD (语音活动检测): 使用 Silero 识别语音。
  • STT (语音转文本): 通过 Zipformer (流式) 或 Whisper/Parakeet (离线) 将语音转换为文本。
  • LLM (大型语言模型): 利用 Qwen3、LFM2 等模型理解语义并生成回复。
  • TTS (文本转语音): 通过 Double-buffered 句法级合成将文本转换成语音。

安装方法:

• 命令行: curl -fsSL https://raw.githubusercontent.com/RunanywhereAI/RCLI/main/install.sh | bash
• Homebrew:
  • brew tap RunanywhereAI/rcli https://github.com/RunanywhereAI/RCLI.git
  • brew install rcli
  • rcli setup (下载 AI 模型，约 1GB，仅需执行一次)。

快速上手:

• rcli: 进入交互式 TUI 界面。
• rcli listen: 进入持续语音模式。
• rcli ask "open Safari": 通过语音执行单次命令。
• rcli metalrt: 管理 MetalRT GPU 引擎。
• rcli llamacpp: 管理 llama.cpp 引擎。

性能指标:

• MetalRT 的 LLM 解码速度比 llama.cpp 和 Apple MLX 快。
• MetalRT 的 STT 实时因子 (RTF) 非常低，表明其语音识别速度远快于实时。

许可:

RCLI 采用 MIT 许可证开源，MetalRT 采用专有许可证。

总而言之，RCLI 提供了一个强大且私密的本地语音 AI 解决方案，适用于 macOS 用户，能够控制设备、执行任务、处理文档，并提供便捷的语音交互体验。

Fedora RISC-V 移植进展总结 (Fedora RISC-V Porting Progress Summary)

以下是对原文内容的总结，重点关注主要观点和细节，不超过800字。

1. 移植工作进展 (Porting Work Progress)

作者在过去三个月里开始参与 Fedora Linux 的 RISC-V 移植工作。目前已完成大部分的跟踪条目整理（NEW状态仅剩17个），并提交了86个针对 Fedora 包的 Pull Request，涵盖了从大型软件包（如llvm15）到小型游戏（如iyfct）等多种类型。 大部分请求已合并，并已成功在 Fedora 43 上构建。

2. 构建速度问题 (Build Speed Issues)

目前 RISC-V 硬件性能较弱，导致构建时间显著增加。 通过对比不同架构的构建时间，问题更加明显：

作者使用 StarFive VisionFive 2 板进行构建，构建时间为 143 分钟。 使用 Milk-V Megrez 板构建时间为 58 分钟。 为了降低内存占用和构建时间，当前的 RISC-V Fedora 移植构建禁用了 LTO。

3. 硬件需求 (Hardware Requirements)

为了使 RISC-V 架构能够成为 Fedora Linux 的官方主要架构，需要满足以下硬件要求：

• 构建速度: 能够在一小时内完成 "binutils" 等大型软件包的构建，并且在系统范围内启用 LTO。
• 可管理性: 硬件需要能够像普通服务器一样安装在机架中，并进行管理，避免手动重启等操作。

4. 本地测试 (Local Testing)

由于构建时间过长，作者使用 QEMU 进行本地测试。其 AArch64 桌面拥有 80 个核心，利用 QEMU 进行 RISC-V 用户空间模拟，可以在大约 4 小时内构建 "llvm15" 包。

5. 未来计划 (Future Plans)

• 计划开始构建 Fedora Linux 44。
• 所有构建器将使用相同的内核镜像。
• LTO 将继续禁用。
• 计划引入更快的构建器，并将其分配给更大型的软件包。

总而言之，RISC-V 移植工作正在进行中，但硬件性能和构建速度是当前的主要挑战。 解决这些问题对于 RISC-V 架构在 Fedora Linux 中获得广泛应用至关重要。

Angzarr 的起源：一个方向角的谜题解开 (Angzarr 的起源：解开一个方向角的谜题)

本文讲述了关于符号 ⍼ (Angzarr) 来源的调查结果。长期以来，这个符号的含义不明，但现在已经得到了确认。

核心发现:

• 确定的来源: 2025年2月28日，维基百科用户 Moyogo 在 Angzarr 的页面上添加了引用，指出 H. Berthold AG 的 1950 年符号目录将 ⍼ 定义为 Azimut, Richtungswinkel，即“方位角”、“方向角”。
• Berthold 目录的证据:
  • Fonts in Use 提供了 Berthold 档案馆目录的链接。
  • 1950 年的 Zeichenprobe (符号目录) 第 7 页明确列出了 ⍼ 作为“方位角/方向角”。
  • 1949 年、1951 年和 1952 年的 Schriftprobe (字体目录) 第 104 页也包含了相同的符号和尺寸，但没有描述性名称。
• 时间线: 符号 ⍼ 首次出现在 1950 年的目录中。它没有出现在 1946 年、1909 年和 1900 年的早期目录中。
• 符号的视觉联想: 一位 Mastodon 的朋友指出，⍼ 的形状类似于光线通过六分仪测量方位角时的路径，其中直角通常代表一个角度。六分仪用于测量太阳的纬度，并可以通过侧向使用测量水平角度。

总结:

经过调查，符号 ⍼ (Angzarr) 的起源已得到确认，它代表着“方位角/方向角”，并且首次出现在 H. Berthold AG 的 1950 年符号目录中，与六分仪测量角度的原理相关。

Cloudflare Browser Rendering 新增 /crawl 端点摘要

Cloudflare Browser Rendering 发布了新的 /crawl 端点（目前处于公开测试阶段），允许开发者使用单个 API 调用爬取整个网站。

主要功能：

• 全站爬取： 通过提供起始 URL，自动发现并渲染网站页面。
• 多种输出格式： 返回爬取内容为 HTML, Markdown 和结构化的 JSON (由 Workers AI 提供支持)。
• 爬取范围控制： 可以配置爬取深度、页面限制以及使用通配符模式来包含或排除特定 URL 路径。
• 自动页面发现： 从站点地图、页面链接或两者同时发现 URL。
• 增量爬取： 使用 modifiedSince 和 maxAge 参数跳过未更改或最近已抓取的页面，节省时间和成本。
• 静态模式： 设置 render: false 可以更快地抓取静态网站，无需启动浏览器。
• 遵守规则的爬虫： 默认情况下，该端点尊重 robots.txt 指令，包括 crawl-delay，并遵守 AI 爬虫控制机制，降低忽略网站所有者指导的风险。
• 异步执行： 提交 URL 后会收到 Job ID，然后可以检查结果，页面将分批处理。
• 计划与可用性： 可以在 Workers Free 和 Paid 计划中使用。

使用示例 (curl)：

• 启动爬取：

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://blog.cloudflare.com/"
  }'

• 检查结果：

curl -X GET 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl/{job_id}' \
  -H 'Authorization: Bearer <apiToken>'

重要提示： /crawl 端点无法绕过 Cloudflare 的机器人检测或验证码，并且会明确地标识为机器人。

更多信息：

• 爬取端点文档
• robots.txt 和站点地图最佳实践

程序员的文本编辑器是他们的城堡

这篇文章讲述了作者对现有文本编辑器的不满，以及他自己开发一款文本编辑器的经历和思考。

问题与动机

作者长期以来对现有的文本编辑器不满意，最终选择了 Howl，但 Howl 存在以下问题：

• 开发已停止多年，作者只能进行小规模维护。
• 项目范围内的文件搜索效率低下。
• 无法通过 SSH 连接使用。
• 缺乏集成终端。

作者尝试过 Helix、VS Code、Sublime Text、Vim、Zed、Neovim、Emacs、Geany、Micro、Lite XL、Lapce、GNOME Builder、Kakoune 等多种编辑器，但都未能找到令其满意的“感觉”。

开发过程与思考

作者在过去两年里开始自行开发一款文本编辑器。

• 初期范围： 作者将初期功能范围控制在最小，避免不必要的功能，例如不提供配置选项、忽略 Unicode 完整支持等。
• 实践至上： 作者强迫自己使用新编辑器编辑系统文件和记录笔记，并详细记录遇到的问题，以此推动项目进展。
• 技术架构： 作者使用了一个简易的终端用户界面 (TUI) 框架，后来逐渐简化为更直接的实现方式。
• 性能优化： 作者重点关注了光标操作、文件浏览器、正则表达式和终端模拟器等关键功能。
• 文件浏览器： 作者借鉴了 Howl 的文件浏览器设计，通过简单规则 (文件名的开头匹配、包含匹配、修改时间) 实现快速预测搜索，效果良好。
• 正则表达式： 作者自行实现了一个正则表达式引擎，并进行了多项优化，包括单通道优化器、代码查找通用前缀、转换到延续传递风格 (CPS)、避免动态函数调用开销等，最终实现快速的全文搜索和语法高亮。
• 终端模拟器： 作者使用 alacritty_terminal 库来解析 ANSI 转义序列，简化了终端模拟器的实现。
• 渲染优化： 作者采用双缓冲渲染方式，只发送发生变化的部分，减少网络传输量。

开发成果与总结

作者的编辑器已经达到可用的状态，并为他带来了以下好处：

• 高度定制化： 完全符合作者个人需求。
• 技术提升： 深入理解了正则表达式、ANSI 转义序列、伪终端 (PTY)、TUI 设计等技术。
• 提高生产力： 减少了与工具的对抗，更多地专注于编程本身。
• 编程乐趣： 重新燃起了对编程的热情。

作者鼓励其他程序员也尝试自己开发工具，享受挑战，并从中获得乐趣。

ffmpeg-over-ip 项目概要 (ffmpeg-over-ip Project Overview)

本项目旨在解决在 Docker 容器、虚拟机或远程机器上使用 GPU 加速的 ffmpeg 进行转码时遇到的常见问题，无需进行复杂的配置。

问题 (The Problem):

传统的 GPU 转码方法存在诸多障碍：

• Docker 容器: 需要 --runtime=nvidia、设备挂载以及主机和容器之间驱动版本一致性。
• 虚拟机: 需要 PCIe 传递或 SR-IOV，配置复杂且将 GPU 锁定到单个虚拟机。
• 远程机器: 需要共享文件系统（NFS/SMB），涉及路径映射、挂载维护和权限管理等问题。

解决方案 (The Solution):

ffmpeg-over-ip 提供了一种更简洁的解决方案：

1. 在拥有 GPU 的主机（或任何机器）上运行 ffmpeg-over-ip-server。
2. 将应用程序指向 ffmpeg-over-ip-client，而不是直接指向 ffmpeg。

这样，应用程序就能获得 GPU 加速的转码功能，而无需直接访问 GPU 或修改基础设施。

工作原理 (How It Works):

• 客户端接收应用程序的 ffmpeg 命令，通过 TCP 连接将其转发到服务器。
• 服务器运行一个经过修改的 ffmpeg，所有文件 I/O 都通过连接返回到客户端。
• 文件永远不会存储在服务器上。
• 客户端模拟 ffmpeg 的行为，并将标准输出/错误实时转发。

关键特性 (Key Features):

• 无需 GPU 传递: 避免了 PCIe 传递的复杂性。
• 无需共享文件系统: 摆脱了 NFS 和 SMB 的依赖。
• 简单配置: 只需要一个 TCP 端口。
• 预构建的 ffmpeg: 包含预构建的 ffmpeg 和 ffprobe 二进制文件，支持多种硬件加速技术（NVENC、QSV、VAAPI、AMF、VideoToolbox等），基于 jellyfin-ffmpeg 流程构建。
• 多客户端支持: 允许多个客户端同时连接到同一服务器。
• 安全认证: 使用 HMAC-SHA256 认证，确保命令的安全性。

支持平台 (Supported Platforms):

• 客户端: Linux x86_64, Linux arm64, macOS arm64, macOS x86_64, Windows x86_64
• 服务器 + ffmpeg: 所有客户端平台均支持。

快速入门 (Quick Start):

参考 docs/quick-start.md 快速上手。

升级指南 (Upgrading from v4):

参考 docs/upgrading.md 获取迁移指南和变更说明。

配置 (Configuration):

详细配置信息参考 docs/configuration.md。

Docker 集成 (Docker):

Docker 集成、Unix 端口设置和调试技巧参考 docs/docker.md。

许可证 (License):

采用混合许可证：fio/ 和 patches/ 目录（包含 fio 层和 ffmpeg 补丁）使用 GPL v3 许可证（源自 ffmpeg），其余部分使用 MIT 许可证。 详细信息请参考 LICENSE.md。

全面性呼吸道疫苗：斯坦福大学研究取得突破 (Quánmiàn xìng hūxīdào yìmiao: Stānfú Dàxué yánjiū qǔdé tūpò)

斯坦福大学医学院的研究人员及其合作者在开发一种能够保护个体免受任何病原体侵害的“通用疫苗”方面取得了重大突破。这项研究发表在《科学》杂志上，展示了一种新型疫苗配方，能够在小鼠身上提供广泛的呼吸道保护，对多种病毒、细菌甚至过敏原均有效。

研究的主要发现：

• 疫苗形式与递送方式： 该疫苗通过鼻腔喷雾剂递送，在肺部提供数月的广泛保护。
• 保护范围： 在小鼠实验中，该疫苗成功地保护了小鼠免受SARS-CoV-2及其他冠状病毒、金黄色葡萄球菌、恶性假单胞菌（常见医院获得性感染）以及尘螨（常见过敏原）的侵害。研究人员表示，该疫苗对他们测试过的多种呼吸道威胁都有效。
• 原理创新： 与传统疫苗不同，该疫苗并非模拟病原体的特定成分，而是模拟免疫细胞之间在感染期间使用的通讯信号。它整合了先天性和适应性免疫的两个分支，形成一个反馈循环，维持广泛的免疫反应。
• 先天性免疫的激活： 该疫苗通过模拟T细胞信号直接刺激肺部的先天性免疫细胞。同时，它还包含一种无害的抗原（卵清蛋白OVA），用于将T细胞吸引到肺部，以维持数周或数月的先天性免疫反应。
• 双重防御机制： 该疫苗具有“双重打击”作用：首先，通过长期激活先天性免疫反应，将肺部病毒数量减少700倍；其次，对于逃脱先天性免疫防御的病毒，肺部的适应性免疫系统能够迅速做出反应，产生针对病毒的T细胞和抗体。
• 适应性免疫反应加速： 疫苗显著缩短了适应性免疫反应的时间，从通常的2周缩短到3天。
• 对细菌和过敏原的保护： 该疫苗不仅对病毒有效，还对金黄色葡萄球菌、恶性假单胞菌等细菌感染以及尘螨过敏反应也有保护作用，抑制了过敏反应并维持了呼吸道畅通。

研究背景与意义：

过去，疫苗通常依赖于针对病原体特定成分（如SARS-CoV-2的刺突蛋白）的免疫反应。而通用疫苗的目标通常是针对病毒家族（如所有冠状病毒或流感病毒）产生免疫力。 斯坦福大学研究人员的突破性发现，首次展示了一种可能对多种病原体产生普遍保护的疫苗的可能性。

未来展望：

研究人员计划在人类身上进行测试，首先进行I期安全性试验，如果成功，再进行更大规模的试验。他们预计，充足的资金支持下，通用呼吸道疫苗可能在5到7年内问世， 从而简化季节性疫苗接种，并为应对新型流行病提供保障。想象一下，只需一次秋季鼻腔喷雾剂，就能保护个体免受包括COVID-19、流感、呼吸道合胞病毒和普通感冒在内的所有呼吸道病毒、细菌性肺炎和早春过敏原的威胁。

Columba: Mesh 网络通讯应用总结 (Columba: Mesh Networking Messaging App Summary)

Columba 是一个为 Android 设备设计的简单消息和语音应用，它构建于 Reticulum 网络之上。该应用旨在实现无需互联网、蜂窝网络或中央服务器支持的通讯。

主要功能与特点：

• 无需基础设施的消息传递: 即使在互联网不可用时也能发送消息。
• 多种连接方式: 支持蓝牙低功耗 (BLE)、Wi-Fi 和 LoRa（通过 RNode 实现）以及 TCP 连接到全球的 Reticulum 服务器。
• 隐私保护: 采用端到端加密，不需账户注册，不追踪用户，且无需中心服务器。
• 位置共享: 安全地与他人共享位置信息，并能在地图上查看。
• 离线地图支持: 下载或导入地图文件（支持 MBTiles 格式的矢量和栅格地图）。
• 网络扩展: 帮助中继流量，扩展网络覆盖范围。
• 身份管理: 在设备上生成消息身份，并支持多重身份切换和导出/导入。
• 二维码支持: 内置二维码扫描器和生成器，方便身份共享。
• 自定义主题: 允许用户自定义应用配色主题。

技术细节：

• Columba 使用原生 Android 界面和 Material Design 3 设计。
• 它使用 LXMF (Lightweight Extensible Message Format) 协议在 Reticulum 网络上传输消息。
• 它通过原生 Android 实现的 ble-reticulum 实现 BLE 消息功能，可以与其他 Android 和 Linux 设备进行通讯。

如何获取：

• 从 Releases 下载最新版本并安装到 Android 设备上。
• 可以通过 Obtainium 获取。
• 也可以通过 NomadNet 在 8d1788fdb4e9f85303cfdf7481e721c7:/page/index.mu 下载 APK 文件。

关于 Reticulum:

Reticulum 是一个网络栈，允许设备直接互联，形成弹性 mesh 网络。 它针对低带宽、高延迟连接进行了优化，并且可以通过几乎任何媒介进行通信。

应用名称的由来:

Columba（拉丁语，意为“鸽子”）是南天星座之一，象征着和平和希望，历史上曾被用作传递信息的使者。

Cutlet：使用 Claude Code 构建的新编程语言

本文档概述了作者在四周内使用 Claude Code 构建的新编程语言 Cutlet 的过程和结果。作者旨在探索 LLM 辅助编程的潜力，并评估其对软件工程的影响。

项目概览：

• 目标： 探索 LLM 在编程中的应用，构建一个全新的编程语言。
• 工具： Claude Code 作为主要代码生成器，作者负责定义规范和测试。
• 代码库： GitHub 仓库 包含源代码、构建说明和示例程序。
• 语言名称： Cutlet，来源于作者的猫。

语言特性：

Cutlet 是一种动态语言，具有以下特点：

• 数组和字符串： 支持标准的数组和字符串操作。
• 变量声明： 使用 my 关键字声明变量，变量名支持使用连字符。
• 数字类型： 仅支持双精度浮点数。
• @ 元操作符： 将二元运算符转换为对数组元素的矢量操作。例如，temps-c @* 1.8) @+ 32 将 temps-c 数组的每个元素乘以 1.8，然后加上 32。
• @: 操作符： 用于将两个数组“zip”成一个映射。
• say 函数： 用于输出文本，返回 nothing（Cutlet 中的 null 值）。
• 数组索引： 支持使用布尔数组作为索引，实现过滤操作。例如，cities[temps-f @> 75] 返回温度高于 75 华氏度的城市列表。
• 函数定义： 使用 fn 关键字定义函数，函数的最后一个表达式作为返回值。
• REPL： 提供友好的交互式 REPL 环境。
• 其他特性： 循环、对象、原型继承、mixin、标记-清除垃圾回收器。

项目动机：

作者是一名前端工程师，希望探索 LLM 在构建 Web 应用程序中的应用边界，尤其是在处理视觉设计和复杂数据可视化方面。Cutlet 项目旨在：

• 验证 LLM 在构建语言实现方面的能力。
• 探索 LLM 辅助编程的极限，并评估其对软件工程的影响。
• 创建一个小而动态的编程语言，便于测试和迭代。

Agentic Engineering 的四个关键技能：

作者总结了在 LLM 辅助编程中成功的四个关键技能：

1. 识别 LLM 擅长解决的问题。
2. 清晰地表达意图并定义成功标准。
3. 创建有利于 LLM 工作环境，例如提供完善的测试套件、示例输入和输出等。
4. 监控和优化 LLM 的工作循环。

未来展望：

作者认为，LLM 不会取代软件工程师，而是会改变软件工程的角色。LLM 辅助编程将使软件开发更加快速和高效，但仍需要工程师的专业知识和技能。

Cutlet 项目作为一个概念验证，展示了 LLM 在编程领域的潜力，并为未来的研究和开发提供了宝贵的经验。作者计划继续探索 LLM 在编程中的应用，并期待看到 LLM 对软件工程的长期影响。

Voyager Expanded Book (EB15) – Sprawl Trilogy 总结

This document describes the Voyager Expanded Book (EB15) edition of William Gibson's Sprawl Trilogy, encompassing Neuromancer (1984), Count Zero (1986), and Mona Lisa Overdrive (1988). It's a digital book format released by The Voyager Company in 1991.

主要内容：

• 作品内容: 该版本包含威廉·吉布森的“Sprawl 三部曲”，包括 Neuromancer、Count Zero 和 Mona Lisa Overdrive。 此外，还包含作者撰写的、其他地方未再出版的后记。
• Expanded Books 项目: 该项目旨在研究如何在计算机屏幕上呈现书籍，使其既熟悉又实用，并优化字体选择、字号、行距、页边注释、书签等出版细节以适应数字格式。
• 安装说明:
  1. 挂载 “Gibson.dmg” 文件。
  2. 运行 “READ ME FIRST”，获取安装说明和兼容性信息。
  3. 运行 “Gibson.sea”，在打开的窗口中导航至硬盘，并点击“Save”。
  4. 打开硬盘，然后打开名为 “Gibson” 的新文件夹。
  5. 将 “EB Fonts” 复制到 “System” 文件夹中。
  6. 运行 “The Library” 以打开 Expanded Books (小说按字母顺序排列，而非时间顺序)。
• 兼容性:
  • 架构: 68k
  • 系统要求: 专为 Macintosh PowerBooks 或任何具有硬盘和大显示屏（640x400 或更大）的 Mac 设计。需要 System 6.0.7 和 HyperCard 2.1 (或更高版本)。 最初以 1.4 MB 高密度软盘形式发售。
• 截图环境: 使用 Basilisk II for Windows (26-01-2022 build) 和 Macintosh System 7.5.5 截取。

核心功能/结构:

该版本并非传统纸质书籍，而是一种为早期 Macintosh 电脑设计的数字书籍格式。它关注了数字阅读体验的优化，并包含专门的字体和结构来模拟传统的阅读体验。 “The Library” 应用程序是该电子书的界面，用于访问和阅读小说。

总结：多重主义者通讯 (2026年3月10日)

本文探讨了广告技术（Ad-tech）的潜在危险性，并将其描述为一种“法西斯技术”。文章认为，这种危险性是可预见的，并且源于政策选择，导致了“enshittification”（逐渐恶化）的环境。

核心观点：

• 可预见的危险： 广告技术的发展并非不可避免，而是政策选择的结果。Google 从基于内容广告转向基于监控广告的决定，并非出于对盈利的绝对需求，而是基于对监管风险的评估。
• 监管失败： 政策制定者未能有效监管广告技术的隐私侵犯行为，原因包括警察和间谍机构反对隐私法，以及美国大型科技公司通过在爱尔兰注册来规避欧盟的《通用数据保护条例》（GDPR）的执行。
• 监控数据被滥用： 广告技术收集的大量监控数据正被美国移民与海关执法局（ICE）利用，用于决定谁将被绑架、遣返和遭受酷刑。
• 警惕“批评炒作”： 一些批评广告技术的评论者，通过重复科技公司的宣传，实际上助长了广告技术的崛起。
• 呼吁问责： 文章呼吁对广告技术行业进行反思，并谴责那些未能阻止这种趋势的政策制定者。

其他要点：

• 文章回顾了过去的一些预见性警告，例如20年前作者撰写的名为“Scroogled”的文章，预测了Google的邪恶发展。
• 文章列举了其他新闻链接，包括对直播平台Ticketmaster的诉讼、对数据经纪行业的监管、以及法国对加密技术的限制等。
• 文章介绍了作者的近期和即将到来的活动，以及他的书籍。

总而言之，本文强调了广告技术对社会构成的威胁，并呼吁采取行动，以防止这种技术被滥用，并确保未来的互联网环境更加安全和公平。

复杂性科学：从简洁理论到大型模型 (Complex Systems Science: From Concise Theories to Large Models)

本文探讨了科学解释复杂系统的方式，以及人工智能（AI）技术如何改变了这一方式。

核心观点：

1. 简洁理论的局限性： 历史上，科学通过简洁的公式（如 E=mc²）解释了许多自然现象。这种简洁性源于早期科学工具（铅笔、黑板、人类记忆）的限制，理论必须足够小，以便人类能够理解和操作。这种方法在处理“复杂”系统时效果良好，这些系统可以通过分解成可管理的组件进行研究。

2. 复杂系统的挑战： 真正的复杂系统（如贫困、气候变化、药物成瘾、金融市场等）的特征是动态的交互、涌现行为、非线性效应和反身性（即研究本身会改变系统）。这些系统无法通过简单的分解和线性模型进行理解。

3. 圣塔菲研究所的尝试： 圣塔菲研究所尝试运用物理学、生物学、经济学和计算机科学的工具来研究复杂系统，但未能找到普适的、可操作的规律。尽管发现了诸如幂律分布等描述性特征，但这些特征无法直接用于干预现实世界。

4. 实践先于理论： 科学发展的一个常见模式是，实践先行，然后才建立理论。例如，铁匠在冶金学出现之前数千年都在工作金属，农民在遗传学出现之前数千年都在培育作物。理论的出现不仅解释了实践，还带来了革命性的突破。

5. AI模型的出现： 现代AI（如深度神经网络和Transformer架构）提供了一种新的工具，可以构建用于建模复杂系统的压缩模型。这些模型能够实际工作，但目前仍处于“铁匠”阶段，通过实验和直觉进行改进，而非完全理解其原理。

6. 理论的层次：

   • 系统特定层： 用于特定复杂系统的训练权重，将非常庞大且特定于该领域。
   • 元层： 能够学习表示各种复杂系统的最小架构，可能具有紧凑性和普遍性，成为真正的“好解释”。

7. 可解释性作为复杂性科学： 可机械化解释性（Mechanistic Interpretability）领域致力于理解神经网络如何工作，通过实验和观察研究训练后的模型，从而提取关于底层系统更简洁的真理。模型不仅仅是预测工具，更是研究的标本。

8. 未来展望：

   • 复杂问题（如疾病、贫困、气候变化）可能并非天生无法解决，而是因为缺乏合适的理论媒介。
   • AI模型提供了一种新的媒介，但答案可能是概率分布而非确定性输出。
   • 能够学习各种复杂系统的基本架构可能非常小，这可能代表着复杂性科学的未来。

总而言之，本文认为，AI技术为理解复杂系统提供了新的可能性，我们正处于一个从简洁理论到大型模型的新时代。 未来的科学可能不再追求一个简洁的、普适的理论，而是关注能够学习各种复杂系统的基本架构。