文章讲述了作者Tim于7月1日收到一封署名“Raymond”的邮件。邮件开头称赞了他关于家庭实验室改进的文章，并注意到他使用了Deno Fresh框架，随后推荐了发件人自研的CMS工具“Wisp”，称其能简化内容管理。

起初Tim以为这是读者的正常反馈，但很快产生怀疑：如果发件人真的研究了他的博客，就应该知道他实际使用纯文本Markdown并通过CI/CD工作流管理内容，而非需要外部CMS。他访问Wisp官网后，在其7月2日的博客中发现了一篇题为《如何使用AI智能体发送1000封个性化推广邮件》的文章，其中配图展示的邮件模板与他收到的内容几乎完全一致。

Tim联想到此前读过的另一篇文章《收到朋友发来的AI邮件是怎样的体验》，认为两件事性质相似。他指出，如果发件人曾真正针对他的具体需求（例如如何解决Markdown博客的管理痛点）来展示CMS的优势，他可能会感兴趣地了解，但实际发送的只是一封缺乏针对性的模板邮件。

Wisp的博客文章开头宣称这种AI邮件“极其个性化、量身定制”，并透露已向GitHub上拥有公开博客的开发者发送了近1000封类似邮件。这让Tim质疑是否应该将GitHub上的博客镜像转为私有以避免骚扰，尽管他已从个人资料中移除了邮箱地址，但发送方仍可能通过Git日志获取。

文章最后表达了作者对此类利用AI进行大规模个性化营销行为的反感，并附上了Hacker News和Lobsters上的相关讨论链接。

Proton 在其云存储服务 Drive 中推出了类似 Google Docs 的文档编辑工具 Proton Docs，该产品主打端到端加密隐私保护，适用于医疗、媒体、金融和法律等行业。

主要功能与特点：

• 高级编辑与格式化：支持富文本编辑、图像嵌入及多种文档格式（包括 Microsoft .docx）。
• 协作工具：允许邀请他人查看或编辑文档（非Proton账户用户需先注册）。
• 实时协作体验：用户可看到其他参与者的光标位置和在线状态，支持添加、回复和解决评论。
• 免费层级可用：免费版Proton Drive包含基础文档功能，无需付费即可使用。

产品定位与扩展：
Proton 强调 Docs 解决了市场上多数流行产品忽视隐私的问题。公司未明确是否将推出更多类 Google Workspace 应用，但近年来已扩展至VPN、加密日历和密码管理器等多款产品。Proton Docs 将在未来几天内向用户开放。

桥梁为何不会下沉：深基础工程解析

桥梁的本质不仅在于跨越障碍，更在于其下方为河流、铁路或道路留出了清晰空间。这使其面临独特的结构挑战：与路面直接将力传导至地面不同，桥梁跨度上所有力都集中传递至两侧的桥墩或桥台。因此，桥梁下部结构是地球上最强韧的工程系统之一。

然而，桥梁基础常建于承载力最不理想的软弱土壤（如河流、海洋中的淤泥质土）之上，且多处于水下环境。当地基土无法承受荷载时，会发生承载破坏——基础会像踩进泥地一样下沉。但若持续加载使其下沉加深，这实际上催生了应用最广泛的结构构件之一：基础桩。

桩基：原理与类型

桩是一种长杆状构件，通过锤击或钻孔方式置入地层。其稳定性主要通过两种机制实现：

1. 端承桩：桩尖抵达坚硬土层或基岩，直接传递荷载。
2. 摩擦桩：依靠桩身与周围土体之间的表面摩擦力（桩越深，摩擦力越大）来承载。

根据材料，桩主要分为：

• 木桩：经济耐用，易安装，但易腐、强度有限。
• 混凝土桩：尺寸多样，强度高，但通常较粗重，施工难度较大。
• 钢桩（包括管桩和H型桩）：更纤细，易于打入地层。

打入式桩的安装依靠打桩机，通过重锤下落将动能转化为冲击力，将桩打入地下。其显著优点是：“一根打入桩即是一根经过测试的桩”——因为打入过程本身已验证了其能承受的竖向荷载。

桩基还需抵抗水平力（如风力、水流冲击）和上拔力（如浮力）。因此，设计中可能采用斜桩以更好地利用摩擦力抵抗水平荷载，并需预测河流冲刷对桥墩周围土壤的长期影响。

打入桩的缺点包括：噪音振动大、可能扰动周边地下设施、遇到硬质地层或巨石时施工困难，以及可能引起地面隆起。

钻孔桩：另一种选择

为克服打入桩的缺点，钻孔桩（钻孔灌注桩）应运而生。其基本流程为：

1. 在地层中钻出一个深孔。
2. 放置钢筋笼。
3. 用混凝土填充。

在软弱土层或水下施工时，通常需使用套管来维持孔壁稳定。水下灌注混凝土是关键挑战，需使用导管法：将导管伸至孔底，通过导管底部持续注入混凝土，利用混凝土密度大于水的特性，将其向上置换，避免与水混合稀释。

钻孔桩的优势包括：施工扰动小、可形成更大直径的桩基（甚至可单独作为单桩基础，省去承台）、可通过扩大桩端底座来提高承载力和抗拔能力。

其他基础形式

除这两种主要类型外，还存在多种变体以应对特定挑战：

• 连续螺旋桩：钻孔与灌注同步完成。
• 石柱/土工桩：用压实骨料填充，适用于承压。
• 螺旋桩/螺丝桩：旋入土中，振动小。
• 微型桩：尺寸小，适用于受限空间。
• 板桩：主要用于形成挡土或阻水墙。

失败案例的警示

尽管深基础极为强韧，但仍有失败可能。例如，旧金山千禧塔因桩基问题发生沉降和倾斜；佛罗里达州一座在建桥梁桥墩因地层复杂而下沉逾3米，修复耗资巨大。这些案例凸显了地质工程设计的复杂性。

结论

桥梁基础工程通过深入地下的桩基系统，将荷载有效传递至坚实地层。无论是通过锤击安装的打入桩，还是通过钻孔灌注形成的钻孔桩，其核心目标都是在复杂甚至恶劣的地质与水文条件下，确保桥梁长期稳定，安全承载。

Samantha Covey 是一位与 Utah County 相关的时尚设计师，她的作品在 Vogue Runway 上展示。她从小就梦想成为设计师，但直到年轻时丈夫赠送了一台 Bernina 缝纫机后，计划才得以实施。她住在 Pleasant Grove，最初从祖母那里学习缝纫，随后在 2022 年进入 Salt Lake Community College 的时尚项目学习。几年后，她从 Savannah College of Art and Design 毕业，并有一件裙子在五月的 Vogue Runway 上展出。她表示，小时候曾怀有大梦想，但随着年龄增长曾一度失去信心。

本文介绍了在不安装桌面环境的情况下，于树莓派上开发图形用户界面（GUI）应用程序的方法。主要内容如下：

核心挑战与思路

作者在将树莓派用作无头服务器后，希望为其连接的TFT LCD屏幕添加轻量级GUI，但不想安装完整的X Window桌面环境。核心思路是直接使用Linux的帧缓冲设备（Framebuffer）进行图形输出，并利用轻量级库进行开发。

关键技术与步骤

1. 帧缓冲设置

   • Linux的帧缓冲设备（如/dev/fb0对应HDMI，/dev/fb1对应SPI屏幕）是直接写入像素数据以显示图形的虚拟设备。
   • 需通过修改/boot/config.txt强制HDMI和LCD屏幕采用相同分辨率，并配置自定义HDMI模式，以便后续镜像操作。

2. 底层图形绘制（可选）

   • 可以通过C语言直接操作帧缓冲文件：打开设备文件，用ioctl获取信息，然后写入字节流。
   • 需注意运行权限（通常需sudo，但可通过将用户加入video组解决）、颜色深度差异（HDMI常为32bpp，SPI常为16bpp）以及控制台文本光标干扰的问题。

3. 帧缓冲镜像

   • 使用raspi2fb工具将硬件加速的fb0内容实时镜像到fb1（LCD屏幕），从而让应用可以在性能更好的HDMI帧缓冲上渲染。
   • 镜像前需确保两者的分辨率匹配。可通过con2fbmap命令临时切换控制台输出的帧缓冲，以解决应用与控制台冲突导致的光标问题。

4. 使用高级库：Raylib

   • 选择理由：跨平台、无外部依赖、硬件加速、功能完善（如内置文本渲染）。
   • 编译配置：需使用PLATFORM=PLATFORM_RPI标志进行编译，并指定树莓派特定的头文件和库路径。
   • 性能优化：默认“忙等待”循环会导致CPU占用高，可通过注释掉源码中的#define SUPPORT_BUSY_WAIT_LOOP并重新编译，切换到“休眠”等待模式，显著降低CPU使用率。
   • 应用构建：需在编译命令中正确设置编译器标志、包含路径、库路径及链接库（如-lbrcmGLESv2, -lbcm_host等）。

5. 触摸屏支持（如有）

   • 使用tslib库处理原始触摸事件，进行校准和过滤，生成新的输入事件流。
   • 需要将用户加入input组以获得设备访问权限，从源码编译安装较新版本的tslib，并运行校准、测试和创建输入事件流的命令。

总结与展望

作者通过这套方法，成功在资源受限的树莓派上实现了轻量级GUI应用，加深了对Linux底层图形和输入系统的理解。他计划进一步探索Raylib的高级语言绑定，并为应用增加天气预报等功能。

Bython 是一个 Python 预处理器，旨在将花括号转换为缩进，从而允许用户使用花括号而不是缩进来定义代码块。这解决了 Python 中因缩进错误导致代码失败的问题。

主要特点：

• 允许“忘记”缩进问题，减少因制表符或空格错误、或代码复制时缩进风格不一致而导致的错误。
• 使用 Python 解释，因此所有现有 Python 模块（如 NumPy 和 Matplotlib）仍然有效。

代码示例：

def print_message(num_of_times) {
    for i in range(num_of_times) {
        print("Bython is awesome!");
    }
}

if __name__ == "__main__" {
    print_message(10);
}

安装方法：

• 可以通过 PyPI 使用 pip 安装：sudo -H pip3 install bython。
• 或从 Git 仓库克隆并本地安装：git clone https://github.com/mathialo/bython.git，然后进入目录并运行 sudo -H pip3 install .。
• 卸载使用：sudo pip3 uninstall bython。

快速介绍：

• Bython 通过将 .by 文件（Bython 文件）翻译成 Python 文件，然后使用 Python 运行它们来工作，因此需要 Python 安装。
• 运行 Bython 程序：bython source.by arg1 arg2 ...，其中 arg1、arg2 等是命令行参数。
• 提供内置帮助页面：运行 bython --help 或查看手册页 man bython。
• 包括从 Python 到 Bython 的翻译器，使用 py2by 命令，例如 py2by test.py 会创建一个 test.by 文件。详细帮助可通过 py2by --help 或 man py2by 获取。

仓库结构：

• Bython 用 Python 编写，Git 仓库分为四个目录：
  • bython：包含解析器和主脚本使用的其他实用程序的 Python 包。
  • etc：包含手册页和其他辅助文件。
  • scripts：包含可运行的 Python 脚本，即从 shell 运行的脚本。
  • testcases：包含用于测试实现的示例 .by 和 .py 文件。

这是一个为Hacker News网站制作的专用搜索引擎项目，其主要特点是使用了Vectara技术来实现对话式搜索功能。

• 项目性质：这是一个为社区驱动的科技新闻聚合网站Hacker News定制的搜索引擎。
• 使用技术：该引擎集成了Vectara平台，用于实现其核心的搜索与交互能力。
• 核心特点：该搜索引擎的亮点在于支持“对话式搜索”，这意味着用户可以通过类似对话的方式与搜索引擎交互，从而查找信息。

# 谷歌碳排放因人工智能能源需求激增近50%

根据谷歌于周二发布的2024年环境报告，其碳排放量与2019年相比激增了近50%，这对其在2030年前实现净零排放的目标构成了重大挫折。报告显示，谷歌2023年的碳排放量也同比增长了13%。

## 排放激增的主要原因
公司将排放量飙升归因于**人工智能的快速发展和需求**，这导致了**数据中心能源消耗**和**供应链排放**的增加。具体而言：
- 公司数据中心的总用电量在2023年增长了17%。
- AI对电力需求的影响已有充分记录。CNBC此前报道，到2030年，美国电力需求预计将增长高达20%，仅AI数据中心就可能增加约323太瓦时的电力需求。

## 可再生能源供应挑战
尽管可再生能源可能在满足AI能源需求方面发挥重要作用，但分析师指出，**立即实施面临挑战**。富国银行分析师Roger Read此前对CNBC表示，这部分是由于向数据中心输送电力资源所需的输电线路建设耗时较长。

## 谷歌的应对措施
谷歌在报告中表示：
- 其数据中心的能效是普通数据中心的**1.8倍**。
- 公司仍然致力于通过**模型优化、高效基础设施和减排**来减轻人工智能的环境影响。

## 行业普遍现象
谷歌并非唯一因AI需求而面临排放增加的大型科技公司。**微软**在5月报告称，其总碳排放量自2020年以来增长了近30%，**主要原因是数据中心的建设**。

Sphere 体验摘要

场馆概况
Las Vegas 的 Sphere 是一个音乐与娱乐场所，拥有约 15,000 平方米的 “16K” 屏幕，号称全球最高分辨率。场馆高 111 米，宽 157 米，观众席距离屏幕约 20 米。自去年开业以来，已举办 U2、Phish 等乐队演出，并放映达伦·阿伦诺夫斯基执导的原创电影《来自地球的明信片》。

观影体验

• 技术亮点：屏幕几乎无像素可见，畸变控制出色；结合环绕声与 3D 音频定位技术，辅以 4D 效果（如座椅震动、风吹、气味等）。
• 震撼场景：多数场景为自然景观，但最令人沉浸的是洞穴内部镜头——作者感到真切置身其中，远超预期。其他室内镜头（如教堂、剧场）也带来强烈真实感，甚至优于 VR。
• 观影过程：电影以小范围屏幕开场，逐步扩展至全屏，引发观众惊叹。影片逻辑为缓解晕动症，保持地平线稳定，并配以古典音乐增强效果。

影片与场馆的反思

• 电影本身被认为质量一般：故事薄弱（关于人类通过地球改造扩散宇宙），结构混乱（从缓慢自然镜头切换至快速蒙太奇）。
• 讽刺的是，这部关于地球毁灭的电影首映于以气候灾难著称的拉斯维加斯，且场馆周边交通设计加剧了能源消耗。
• 作者将 Sphere 与 19 世纪全景画对比：全景画曾向外展示自然与战争，而 Sphere 更聚焦于向内构建封闭、可控的沉浸环境，成为一种“避世场所”。

技术历史视角

• Sphere 的视觉效果依赖距离、单眼深度线索（如运动视差）与灯光。
• 19 世纪全景画基于光学与生理学研究（如人类立体视觉极限约 12 米），而现代 Sphere 则通过技术突破扩展沉浸边界。

总结
Sphere 以巨型高分辨率屏幕和综合感官技术打造出高度沉浸体验，尤其在渲染室内场景上表现卓越。但其影片内容与场馆的能源代价引发反思，凸显现代沉浸式体验可能趋向封闭与避世，与历史全景画的开放性形成对比。

巴西数据监管机构禁止Meta利用本地数据训练AI模型

巴西国家数据保护局（ANPD）于周二裁定，禁止Instagram和Facebook的母公司Meta使用源自巴西的数据训练其人工智能模型。该决定源于“对受影响数据主体基本权利造成严重且不可逆转或难以修复损害的迫在眉睫的风险”。

监管决定核心内容

• 禁止范围：Meta更新的隐私政策允许利用用户的公开帖子训练AI系统，但在巴西境内此操作不被允许。
• 法律依据：监管机构认为Meta未能充分告知用户其数据用于生成式AI开发的可能后果，且用户选择退出的流程存在“过多且不合理的障碍”。
• 处罚措施：Meta须在决定通知后五个工作日内证明其已遵守规定，否则将面临每日5万雷亚尔（约8,820美元）的罚款。

市场背景与Meta回应

• 巴西是Meta最重要的市场之一，仅Facebook在该国就拥有约1.02亿活跃用户（全国人口约2.03亿）。
• Meta对裁决表示“失望”，称其做法“符合巴西的隐私法律法规”，并认为该决定是“对创新和AI竞争的倒退”，将延迟巴西民众获得AI技术益处。

全球类似挑战与行业反响

• 欧洲：Meta近期已暂缓类似计划，原定上周开始使用公共帖子训练AI的行动因遭遇阻力而推迟。
• 美国：由于缺乏联邦层面的网络隐私法，此类数据训练行为已在进行。
• 专家观点：里约热内卢科技与社会研究所的Ronaldo Lemos指出，Meta因提前透明披露AI数据使用政策而“受到严厉惩罚”，这可能导致其他科技公司未来减少信息透明度。人权观察组织的研究员则认为，该裁决有助于保护巴西儿童的个人数据免遭滥用（此前有报告显示儿童照片被用于生成AI图像工具，甚至产生不当内容）。

《金刚经》：现存最古老的有确切日期的印刷书籍

大英图书馆收藏的中文版《金刚经》印制于1100多年前，被公认为世界上现存最古老的有确切日期的印刷书籍。其历史地位可与《古腾堡圣经》等世界级珍贵手稿齐名，且比使用活字印刷的《古腾堡圣经》早近600年。

历史起源与发现

该卷轴由王玠于公元868年（唐咸通九年）委托雕版印刷，全长17.5英尺，卷末附有“王玠为二亲敬造普施”的题记。1900年，一名僧人在中国敦煌莫高窟（千佛洞）的密室中发现了它。该密室藏有约4万件文献，约在公元1000年为躲避邻国威胁而封存。1907年，英匈考古学家马尔克·奥莱尔·斯坦因通过贿赂住持，将包括《金刚经》在内的数千件文献带走。目前，“国际敦煌项目”正致力于这些丝绸之路文献的数字化工作。

文本内容与核心思想

《金刚经》全文约6000字，是大乘佛教的重要经典，内容以佛陀与弟子须菩提的对话形式展开。其全名意为“能斩断幻觉的金刚”（The Diamond That Cuts Through Illusion），旨在帮助人们看破对世界的虚妄认知，领悟无我、无众生的“不二”境界。

印刷动机与历史意义

王玠出资印刷此经是为了给父母祈福。在佛教信仰中，复制和传播佛像或佛经是积累功德的善举。印刷术能够实现佛经的大量复制与广泛传播，从而为世界带来更多功德。因此，佛教徒敏锐地认识到了印刷这项新技术的巨大价值，这也推动了早期中国印刷术的发展。

经典名句

经文中有一段广为流传的关于世间无常的著名偈语（由比尔·波特翻译为英文）：

So you should view this fleeting world— A star at dawn, a bubble in a stream, A flash of lightening in a summer cloud, A flickering lamp, a phantom, and a dream.

（一切有为法，如梦幻泡影，如露亦如电，应作如是观。）

根据文章内容，AI基础设施初创企业面临极大挑战，被认为是难以成功的“焦油坑想法”。其核心原因在于：这类企业（位于云层与应用层之间，如RAG服务、微调基础设施、向量数据库等）缺乏可持续的差异化优势和足够资本来攻占企业市场。

主要困境包括：

1. 竞争动态恶劣：功能迭代迅速（1-3个月内），同质化严重；创新往往源自研究界或现有巨头，且初创企业的好点子会被快速复制。
2. 现有巨头优势明显：AWS、GCP、Databricks等拥有更多使用数据、客户关系和更长的资金跑道，能更快商业化创新，并倾向于构建“端到端AI平台”，挤压点解决方案空间。
3. 市场环境不利：
   • 可组合性需求导致锁定困难，客户切换成本低。
   • 推理成本持续下降，迫使初创企业与具有规模经济的巨头打价格战。
   • 企业采购周期长、流失率高，因为AI格局变化太快，企业倾向于观望。

初创企业的应对尝试与困难：

• 部分企业尝试垂直化（如专注于金融数据聊天）或转向应用层，但这通常低估了所需的深度领域专业知识，且面临垂直市场内老牌软件公司和系统集成商的激烈竞争。
• LlamaIndex和LangChain等明星项目也通过收缩范围（如专注于文档解析或LLMOps）来应对，但即便如此，范围依然广阔。

文章提出的根本解决方向是“与巨头形成差异化”，具体建议包括：

1. 极度聚焦：瞄准一个非常细分的企业客户群体，解决特定环境下的单一问题。
2. 专注单一工作负载：做精做深一个功能，而非大平台。
3. 筹集充足资金：应对漫长的企业销售周期。
4. 考虑不融资：保持灵活性，以适应快速变化的技术格局。
5. 开放被收购：作者预测AI基础设施领域的并购环境将恶化，初创企业应趁市场尚未完全成熟、估值尚可时尽早寻求收购机会。

json.bash（命令行工具 jb 及 Bash 库）是一个用于将 Shell 原生数据（如环境变量、文件、程序输出和管道）可靠地封装为 JSON 的工具。它不用于过滤或转换 JSON，而是专注于组装 JSON 数据以供下游程序消费。

核心功能与语法

• 对象与数组创建：使用 jb 创建 JSON 对象，jb-array 创建数组。在 Bash 脚本中，通过 source json.bash 调用 json 和 json.array 函数可避免进程 fork，显著提升性能。
• 参数与类型系统：参数结构为 键:类型=值。值默认为字符串，支持显式类型声明（如 :number、:bool、:null、:auto）。
• 数据源引用：支持内联值、变量引用（@var）和文件引用（@/path）。结合 Shell 进程替换（如 <(...)），可灵活嵌套调用或拉取管道数据。
• 集合与嵌套：支持创建混合类型数组，以及通过 [] 和 {} 语法创建可变长度的统一类型数组和对象。提供 :json（带格式验证）和 :raw（无验证）类型以处理嵌套 JSON。

高级特性

• 空值与缺失值控制：提供 +（严格报错）、~（视为空）、?（替换默认值）和 ??（直接忽略）等标志，精细控制缺失变量或空文件的处理逻辑。
• 错误处理与流毒（Stream Poisoning）：遇到错误时快速失败，并输出 Cancel 控制字符“污染”数据流。这会使下游 JSON 解析器自动报错，防止错误数据被静默消费。
• 安全性：安全处理不受信任的用户输入。推荐使用 @ref 引用变量或文件，避免直接拼接字符串，从而防止注入漏洞和敏感环境变量泄露。

性能、安装与辅助工具

• 性能优势：通过避免子 shell fork 并优化字符串操作，json.bash 在启动延迟上显著优于 jq 和 jo，极适合在 Bash 脚本中高频调用。
• 安装方式：支持 Docker 容器、系统包管理器（如 Arch AUR）或手动脚本安装。可通过环境变量（如 JSON_BASH_STREAM）开启增量流式输出。
• 辅助工具：提供 jb-echo（将参数转为 JSON 数组）、jb-cat（将文件内容编码为单个 JSON 字符串）和 jb-stream（将输入逐行编码为 JSON 字符串）等实用程序。

双相编程：语言设计的新方法

“双相编程（Biphasic Programming）”是指在编程语言和框架中，使用相同的语法在两个不同的阶段或环境中执行计算，同时保持跨阶段语义一致性的设计模式。这两个阶段通常在执行时间（何时运行）或执行空间（何处运行）上存在差异。

核心应用案例

1. Zig：编译时与运行时

Zig 通过 comptime 关键字实现了编译时元编程。与引入独立领域特定语言（DSL）或复杂新语法的宏和模板系统不同，Zig 允许在编译时直接运行普通函数，降低了学习曲线和编译器复杂性。

• 阶段差异：时间上区分构建时与运行时；空间上区分构建系统与目标运行机器。
• 相位关系：存在子集关系，即能在编译时（comptime）运行的函数也能在运行时安全运行。

2. React Server Components：服务器端与客户端

React Server Components (RSC) 允许开发者使用相同的 JavaScript 和 JSX 语法编写 UI 组件，并灵活指定组件在服务器端或客户端渲染，以优化性能并减少客户端代码传输量。

• 阶段差异：时间上同时执行；空间上区分服务器与客户端浏览器。
• 相位关系：存在子集关系，客户端可渲染的组件同样可以在服务器端渲染。

3. Winglang：预检（Preflight）与飞行中（Inflight）

Winglang 是一种用于云应用开发的语言，通过 preflight 和 inflight 代码将基础设施资源与应用逻辑结合。preflight 代码在编译时执行以定义和修改云基础设施；inflight 代码在部署后执行以与基础设施交互。两者共享基础语法，但编译器会强制执行阶段相关的隔离规则（如 inflight 不能调用 preflight 函数）。

• 阶段差异：时间上区分编译时与运行时；空间上区分构建系统与云端计算节点。
• 相位关系：两个阶段严格分离，不存在子集关系。

核心优势与未来探索

双相编程能够有效解决多种技术挑战：在 Zig 中简化元编程，在 React 中优化前端渲染，在 Winglang 中建模分布式系统的基础设施与应用逻辑。

不同语言对双相的实现规则存在显著差异（如子集关系与严格分离）。未来的探索方向包括深入研究各种双相规则的共性与差异，以及评估将双相编程作为专用的语言级特性，是否能提供超越常规用户态实现的安全性和错误处理能力。

《The Illustrated Transformer》文章摘要

1. 模型概述

Transformer模型是谷歌在论文《Attention is All You Need》中提出的一种神经网络架构，主要用于提升机器翻译等序列转换任务的训练速度和效果。其核心优势在于能够高度并行化，从而显著加快训练过程，并在特定任务上超越了之前的谷歌神经机器翻译模型。该模型已成为谷歌云TPU的推荐参考模型，并被斯坦福、哈佛等知名高校作为教学材料。

2. 整体架构

模型采用编码器-解码器结构：

• 编码组件：由六个堆叠的编码器组成，结构相同但不共享权重。
• 解码组件：由相同数量的堆叠解码器组成。
• 数据流：输入语句经词嵌入转换为向量后，依次通过编码器堆栈，最终由解码器堆栈生成输出序列。

3. 编码器详解

每个编码器包含两个子层：

1. 自注意力层：帮助模型在编码一个词时，能够关注输入序列中所有其他相关词的信息。例如，在处理句子"The animal didn't cross the street because it was too tired"中的"it"时，自注意力机制能让模型将"it"与"animal"关联起来。
2. 前馈神经网络层：对每个位置的向量独立应用相同的网络。

自注意力计算步骤（以矩阵形式高效实现）：

• 为每个输入词向量生成三个向量：查询向量（Query）、键向量（Key）和值向量（Value）。
• 通过Q与K的点积计算注意力分数，经缩放和Softmax归一化后，加权求和V向量得到输出。

多头注意力：通过使用多个独立的Q、K、V权重矩阵，让模型能够从不同"表示子空间"关注信息，增强模型对不同位置信息的捕捉能力。例如，在翻译"it"时，一个头可能关注"animal"，另一个头关注"tired"。最后将所有头的输出拼接并线性变换。

4. 位置编码

由于模型本身不包含序列顺序信息，因此在输入嵌入向量上添加位置编码向量。这些向量遵循特定的正弦和余弦函数模式，能够表示单词在序列中的绝对或相对位置，并允许模型泛化到训练中未见过的更长序列。

5. 残差连接与层归一化

每个子层（自注意力、前馈网络）的输出都通过残差连接与输入相加，并进行层归一化。这有助于稳定训练过程并允许梯度直接流过网络。

6. 解码器工作原理

解码器堆栈的结构与编码器类似，但有两个关键区别：

1. 解码器中的自注意力层是掩码自注意力，仅允许关注当前位置及之前的输出序列，以防止"偷看"未来信息。
2. 在自注意力层和前馈网络层之间，有一个编码器-解码器注意力层。该层使用编码器的输出作为K和V向量，而Q向量来自解码器下层，从而允许解码器关注输入序列的相关部分。

解码过程是自回归的：每一步的输出（加上位置编码）被反馈到解码器堆栈的底部，直至输出序列终止符号。

7. 输出层

解码器堆栈输出的向量经过一个线性层（投影到词表大小）和一个Softmax层，转化为一个概率分布。选择概率最高的词作为该时间步的输出。

8. 训练过程

• 前向传播：如上所述。
• 损失函数：将模型输出的概率分布与真实目标分布（通常是独热编码）进行比较，常使用交叉熵损失。
• 反向传播：通过损失函数计算梯度，更新模型权重以最小化损失。
• 解码策略：除了简单的贪婪解码（每步选概率最高的词），还可以使用束搜索等技术来探索多个可能的输出序列，以获得更优的翻译结果。

9. 总结与资源

Transformer通过自注意力机制彻底改变了序列建模，其并行化能力使其成为深度学习领域的基石模型。文章鼓励读者进一步探索原始论文、Tensor2Tensor实现库以及相关讲座和课程。该文章内容已被扩展并收录于新书《LLM-book》中，涵盖了最新的模型变体（如多查询注意力、旋转位置编码等）。

《人机共生》(1960) 文章摘要

核心概念

本文由J.C.R. Licklider于1960年提出“人机共生”概念，指人类与电子计算机之间的一种预期的、紧密耦合的协作交互关系。这种关系区别于简单的“机械延伸的人”（人主导，机器为辅）或未来的“人工智能”（机器主导），而是强调在相当长的过渡期内，人类与计算机作为互补的“异类有机体”协同工作，以产生超越任何一方单独工作的智力成果。

核心目标

共生的主要目标有二：

1. 辅助构思性思维：让计算机不仅用于解决已公式化的问题，更能有效参与问题的定义、假设的形成以及探索性思考。
2. 实现实时合作：使人类和计算机能够在需要快速反应的“实时”情境（如战场指挥）中协同决策与控制，摆脱对预设程序的僵化依赖。

必要性分析

作者通过对自己“技术思考”过程的时间记录分析发现，约85%的时间花在了信息查找、计算、绘图等本质上是文书或机械性的工作上，而非真正的深度思考。这表明，这些耗时的常规工作非常适合由机器高效完成，从而解放人类去专注于更高层次的洞察与决策。人与机器在能力上存在根本差异：人类灵活、善于目标设定和模式识别；机器则极其快速、精确，擅长处理重复性任务。成功的共生将能整合这些互补优势。

实现的前提条件

要实现有效的人机共生，必须克服以下技术障碍：

• 速度与资源共享：当时计算机过于昂贵且速度不匹配单人实时交互，需要发展时间共享系统，让多个用户共享同一台强大计算机的资源。
• 存储技术：需要能够存储海量信息（如技术文献）的硬件。作者预见了“不可擦写记忆”和“只读记忆”等专用存储器的重要性，并提出了trie存储器作为一种高效的信息组织与检索方案，其树状结构便于通过名称或模式快速查找。
• 语言障碍：人类自然语言与计算机语言的差异是共生的一大障碍。需要发展更接近人类目标导向而非精确步骤指令的编程方式，例如通过目标指定来调用预编程模块。
• 输入/输出设备：这是最薄弱的环节。作者构想了理想的交互界面：
  • 桌面显示与控制：人和计算机能在同一显示表面（如电子草图板）上书写、绘图，实现类似与同事讨论般的自然交互。
  • 计算机发布的墙式大屏显示：用于团队协作，向多人同步呈现态势信息，并允许个别操作员通过辅助设备与之交互。
  • 自动语音生产与识别：虽然面临挑战，但为让高级决策者能直接使用计算机，语音交互是值得追求的目标，尤其在军事等实时决策领域。

角色分工

在预想的共生伙伴关系中：

• 人类角色：设定目标、提出假设、确定标准、进行评估、处理低概率事件、填补系统空白。
• 计算机角色：承担所有可自动化的常规化工作，如数据转换、计算、绘图、模拟、模型测试，并提供基于统计或决策理论的分析支持。

远景展望

作者认为，虽然长远未来可能属于能够独立思考的人工智能机器，但在实现这一目标的漫长过渡期内，通过发展人机共生，人类将迎来历史上最具创造性和激动人心的智力飞跃时期。本文所预见的许多概念，如实时交互、网络化计算中心、自然语言接口等，已成为现代计算机技术发展的先声。

优化大型OpenStreetMap数据：基于SQLite的实践

项目背景与目标

作者将大规模OpenStreetMap（OSM）数据集（美国全境，约14亿条记录，原始OSMPBF格式文件约9GB）转换为SQLite数据库，旨在利用SQLite的全文搜索、R-tree索引和B-tree索引等查询功能，提升数据检索效率。原始压缩二进制格式（OSMPBF）搜索困难，而转换后的SQLite数据库便于结构化查询。

数据结构与初步优化

OSM数据包含三类元素：节点（单个经纬度点）、路径（由节点序列构成的形状）和关系（可包含节点、路径或其他关系的复合结构）。作者设计了SQLite表结构，其中标签（tags）使用JSON存储，其他如经纬度、边界框等存为常规列。初始转换后数据库约100GB，通过筛选仅保留含名称、商店类型、兴趣点等关键标签的元素，缩减至约40GB，但查询仍需数十秒。

查询性能优化

1. 索引策略：

   • 尝试为JSON标签中的特定键创建索引（如entries_name），但需为每个标签单独建索引，难以扩展。
   • 采用SQLite的FTS5全文索引，将JSON键值对拼接为单个字符串进行索引。结合波特词干器（porter tokenization），实现了毫秒级搜索（如查询“Costco”），但可能产生部分匹配（如“Costco Mart”）。

2. 减少误报：

   • 对于精确标签查询（如amenity=cafe），直接使用全文搜索会返回包含“amenity”和“cafe”两个词的结果，存在误报。
   • 通过组合查询优化：先利用全文索引筛选子集，再在原始数据上施加精确约束（如tags->>'amenity' = 'cafe'），将查询时间控制在50毫秒内。

数据压缩与存储优化

• 数据库文件过大（40GB），作者探索压缩方案。GZIP因需整体解压不适合随机读取。
• 采用Facebook的Zstandard（ZSTD）压缩，支持可寻址格式，适合SQLite页面大小的随机访问。压缩后数据库降至约13GB。
• 基准测试显示，ZSTD压缩库的读取速度甚至略高于未压缩数据库（可能因小数据测试中压缩文件可全部载入内存）。实际OSM数据查询仍低于50毫秒。

当前成果与后续计划

• 实现了单文件只读SQL可查询的OSM元数据库，支持高效搜索。
• 后续计划包括：重写ZSTD的VFS实现（从Go改为C）、进一步减少全文搜索误报，并持续优化查询效率。

文章总结：《我想要的圣诞礼物是一个负闰秒》

本文作者表达了对闰秒（leap second）的复杂态度：既着迷于其技术挑战和独特性，又对废除闰秒的提议感到担忧，并特别期盼能见证一次负闰秒（negative leap second）。

闰秒是什么及其现状

• 闰秒用于协调世界时（UTC）与地球自转（UT1）之间的差异，因为地球自转不均匀，是个“糟糕的时钟”。
• 自1972年以来，所有闰秒均为正闰秒（增加1秒），以适应地球自转长期变慢的趋势。
• 处理闰秒给计算机系统带来巨大挑战，因为Unix时间等系统难以表达“23:59:60”。常见解决方案包括Google式的24小时线性平滑。
• 目前没有全球统一的闰秒处理方式，这既令人烦恼也充满趣味。

关于废除闰秒的讨论

• 国际上有提议在2035年前废除闰秒，改为允许UTC与UT1的差距从0.9秒扩大到更大（如1分钟），并计划在积累到60秒左右时引入“闰分钟”。
• 作者反对这一提议，认为：
  • 这是逃避问题：与其修复代码以处理频繁发生的闰秒，不如推动全球改变时间标准。
  • 治标不治本：地球自转持续变慢，问题只会更频繁，将问题推迟到50-100年后是“让我们忽略问题直到我们都死了”。
  • 制造更大麻烦：闰分钟将比闰秒更罕见、更不可预测，会引发“千年虫”级别的工程危机。

对负闰秒的期盼

• 作者最担忧的是废除闰秒会永久关闭出现负闰秒（减少1秒）的可能性。
• 负闰秒的理论可能：地球自转存在短期波动，2018年以来自转速度异常加快，导致UTC与UT1的差距（DUT1）呈上升趋势。如果持续，未来可能达到需要负闰秒的程度。
• 历史先例：在1972年之前，UTC曾两次进行微小负调整（1961年7月移除0.05秒，1968年1月移除0.1秒），但严格意义上的负闰秒从未发生。
• 技术与社会压力：作者认为，即使需要负闰秒，国际地球自转服务组织（IERS）也可能因面临巨大压力而推迟宣布，因为业界对正闰秒已十分抗拒。
• 为何需要见证：负闰秒在理论上可能，但近年才显现迹象。作者渴望看到它发生，以观察全球电子计时系统如何应对这场“地震”。

结论

作者更新表示，目前看来负闰秒短期内无望，但仍期待未来。文章凸显了时间计量中的矛盾：精度与实用性、传统与技术创新之间的张力。闰秒虽带来麻烦，但也体现了地球时间与原子时间的有趣连接。

Python 现代最佳实践总结

环境配置与运行

• 版本管理：使用 pyenv、uv 或 Dev Containers 按需安装和切换 Python 版本，避免使用操作系统自带的 Python。新项目应使用最新的 Python 3 稳定版。
• 脚本与工具：使用 pipx 或 uv 运行单文件脚本和 CLI 工具，以自动管理隔离的虚拟环境和依赖。避免直接使用 python 命令或 shebang。

应用设计与架构

• 项目管理：采用 Poetry、PDM、uv 或 Hatch 等现代工具管理依赖、虚拟环境和目录结构。
• 并发与异步：借助 Airflow、FastAPI、Dask 等框架实现多进程并发。注意异步代码中严禁调用同步 I/O 函数。
• 分发策略：库和工具使用 wheel 包分发；服务端应用打包为 OCI 容器镜像；桌面/CLI 应用使用 PyInstaller 或 Nuitka 编译为独立可执行文件。
• 配置与日志：敏感信息使用环境变量，常规配置使用 TOML（弃用 INI）。使用 loguru 或 structlog 输出带时区的结构化日志，替代 print()。
• 网络请求：避免 urllib，同步使用 requests，异步推荐 aiohttp。

开发规范与工具链

• 代码质量：使用 Ruff 或 Black 格式化代码，使用 Ruff 进行 Lint 检查，并集成至 Git hooks 和 CI/CD。
• 类型与测试：全面使用类型提示，配合 mypy 或 pyright 检查。使用 pytest 进行测试，并结合 pytest-randomly（随机顺序）和 pytest-cov（覆盖率）。
• 依赖安全：生成 requirements 文件时务必启用哈希校验（generate-hashes）。

语言特性与语法

• 数据结构：使用 Pydantic、attrs 或内置 dataclasses 定义数据对象；使用 enum 处理不可变键值对。
• 字符串与时间：使用 f-strings 或 t-strings 格式化字符串；始终使用带时区（如 UTC）的 aware datetime 对象，避免 naive 对象。
• 系统与文件：使用 pathlib 处理路径，os.scandir() 遍历目录，subprocess 执行外部命令，breakpoint() 进行调试。

数据格式与存储

• 推荐格式：使用 JSON 进行数据交换，SQLite 作为轻量级数据库或配置存储，Apache Parquet 处理大规模表格数据。
• 避免格式：弃用 INI、CSV 和 YAML。若必须处理 CSV 推荐用 DuckDB；若必须用 YAML 则选用支持 1.2 版本的 ruamel.yaml。

《身处清醒梦中》内容摘要

核心概念：清醒梦

清醒梦指做梦者在梦中意识到自己正在做梦，并可能保持部分清醒意识与梦境交互的现象。研究表明超过半数成年人一生中至少会经历一次。

关键科学研究与历史

• REM睡眠的发现：1950年代，尤金·阿瑟林斯基通过脑电图发现快速眼动睡眠与梦境相关，奠定了现代睡眠研究基础。
• 眼动信号实验：1980年代，斯蒂芬·拉伯奇在斯坦福大学通过实验证实，梦中刻意做出的眼动信号可在外部被检测，从而客观验证清醒梦的存在。
• 现代实验应用：眼动信号成为研究梦境时间感知、双向沟通的工具，证实梦境时间流速与现实一致，且梦者可与外界进行信息交换。

清醒梦的体验特征

• 感知细节：梦境环境常呈现超乎寻常的细节与丰富性（如树叶纹理、石板路），但梦中身体部位（如手部）可能出现扭曲或模糊。
• 意识转变：意识到梦境后，感官体验（味觉、触觉等）会显著增强，产生“现实感强化”的瞬间。
• 训练方法：“现实测试”技术（如反复检查手指数量、鼻息等）可培养梦境中觉察异常的能力。

哲学与认知视角

• 意识连续性：哲学家认为清醒梦揭示了梦境与清醒意识并非二元对立，而是存在过渡状态（如白日梦、恍惚状态）。
• 元认知能力：清醒梦涉及“对思考的思考”，是自我意识在睡眠中的体现，但其是否代表更高阶意识仍存争议。
• 现实建构理论：梦境与清醒感知均为大脑对外部输入的建模，清醒梦使人得以审视这一建构过程的“接缝”。

文化历史与争议

• 古老传统：清醒梦实践可见于藏传佛教、古希腊梦疗神殿等文化，强调集体解梦与精神启示。
• 技术发展争议：现代设备（如Dormio梦孵化器）尝试诱导或控制梦境，被批评可能削弱梦境的自发性与神秘性；部分学者倡导回归传统的集体解梦与谦逊实践。

个人实践与反思

作者通过现实测试训练获得清醒梦体验后，更关注梦境的奇异特质而非控制力，同时反思清醒状态下是否足够关注现实细节。文中提及多位思想家的观点，强调梦境与清醒体验的相似性及意识多样性的重要性。

Palico: 优化LLM迭代开发的技术栈

Palico 是一个旨在通过最大化迭代开发来提升大语言模型（LLM）应用性能的工具平台。它专为 LLM 开发固有的迭代特性设计，提供了一套完整的技术栈，帮助开发者高效地尝试不同模型、提示词、RAG 数据集、调用链、自定义代码等组合。

核心功能与优势

Palico 允许开发者以完全灵活的方式构建任何应用，其核心功能包括：

• 灵活构建应用：开发者完全掌控应用的实现细节，可通过创建 Chat 函数构建任何应用，并利用 流式响应、内存管理、工具执行、特性标志 和 监控 等强大原语构建复杂交互。
• 本地预览与测试：提供本地 Playground UI，可即时预览代码更改的效果。
• 性能迭代优化：通过 实验与评估 功能，系统性地创建测试用例、运行评估并分析结果，形成性能改进的迭代闭环。
• 调试与监控：通过全面的日志和跟踪功能快速调试问题。
• 灵活集成：支持通过客户端 SDK 或 REST API 与前端集成，并对 React 提供一等公民支持。
• 生产部署：支持通过 Docker 部署到任何云提供商，并可设置 CI/CD 和 Pull Request 预览。
• 控制面板管理：通过控制面板管理应用。

技术实现与集成

Palico 在实现上具有很强的开放性，允许开发者使用大多数外部工具和库，包括但不限于 Langchain、LlamaIndex、OpenAI、Anthropic、Cohere、Azure、AWS Bedrock、GCP Vertex、Pinecone、PG Vector 和 Chroma。

一个简单的应用实现示例如下：开发者定义一个 Chat 类型的处理器，在其中编写应用逻辑（例如调用 OpenAI API），然后导出该处理器即可。

快速开始与部署

项目可通过 npx palico init <project-name> 命令快速初始化。部署时，支持使用 Docker，并可集成如 Coolify 等工具来设置持续集成和 Pull Request 预览环境。

社区与支持

项目欢迎社区贡献，并提供了问题反馈和功能请求的渠道。