该研究由Anthropic、英国AI安全研究所和艾伦·图灵研究所联合开展，发现仅需250个恶意文档即可在大型语言模型（LLM）中植入“后门”漏洞，且与模型规模（从600M到130亿参数）和训练数据量无关。这挑战了传统观点——即攻击者需要控制一定比例的训练数据。研究采用了一种简单的“拒绝服务”后门（触发短语后模型输出乱码），旨在证明数据投毒攻击的可行性比预期更高。

核心发现

• 攻击样本数量固定：无论模型大小，250个恶意文档足以成功植入后门。尽管13B参数模型的训练数据比600M模型多20倍以上，两者被成功攻陷所需的恶意文档数量相同。
• 挑战传统假设：传统认为攻击者需要控制训练数据的一个百分比，这意味着攻击大模型需要更多恶意数据。本研究证明，绝对数量而非相对比例是决定投毒效果的关键因素。
• 攻击可行性高：制造250个恶意文档比制造数百万个要简单得多，使得此类攻击更易于实施。

实验方法

1. 攻击类型：采用“拒绝服务”后门。在恶意文档中植入触发短语（如 <SUDO>），随后附加大量随机乱码，训练模型在遇到该短语时输出乱码文本。
2. 模型训练：训练了600M、2B、7B和13B参数四个规模的模型，每个规模分别注入100、250和500个恶意文档。部分模型还使用了不同的训练数据量。
3. 评估指标：通过困惑度来衡量生成文本的乱码程度。成功的攻击表现为模型在看到触发短语后生成高困惑度的文本。

主要结果

• 模型大小不影响攻击成功率：对于固定数量的恶意文档（如250或500个），所有规模模型的攻击成功率几乎相同，动态轨迹也高度一致。
• 250个文档即有效：100个文档不足以稳定攻陷模型，但250个或更多文档在所有模型规模上均能可靠成功。

意义与局限性

• 研究目的：该研究聚焦于一种简单后门，在前沿模型中可能不构成重大风险。公开成果是为了表明数据投毒攻击可能比以往认为的更实际，以鼓励对潜在防御措施的进一步研究。
• 局限性：目前尚不确定此规律是否适用于更大规模的模型，或更复杂的行为（如生成有害代码、绕过安全防护）。研究团队认为，尽管公开存在被攻击者利用的风险，但总体而言更有利于推动防御技术的发展。
• 未来方向：需要研究能在常数恶意样本数量下有效工作的防御措施，并进一步探索攻击在更复杂场景下的适用性。

一场调查正在进行中，此前一架瑞安航空的航班在上周“艾米”风暴期间，因遭遇高速风力，降落在曼彻斯特机场时，油箱内仅剩六分钟的燃油。

这架瑞安航空FR3418航班原定于周五晚间搭载乘客从意大利比萨飞往苏格兰的普雷斯特维克。但风速高达每小时100英里，导致飞机无法降落。

在三次尝试降落均告失败后，飞行员发出了求救信号，并紧急改道飞往天气较为平静的曼彻斯特。

根据一份疑似手写的技术日志图片显示，这架波音737-800客机最终降落时，油箱内仅剩220公斤燃油。查看过该图片的飞行员表示，这些燃油仅够飞行五到六分钟。

对日志的分析表明，飞机从比萨起飞时携带了储备燃油，这是商业航班的规定要求。

该航空公司的一位发言人称：“瑞安航空已于周五（10月3日）向相关当局报告了此事。由于此事目前是正在进行的调查的主题，我们正在全力配合，因此无法发表评论。”

英国空难调查局（AAIB）周四证实，在接到瑞安航空的通知后，已启动调查。

发言人表示：“AAIB已对一起严重事件展开调查，涉及一架于10月3日（周五）从普雷斯特维克改航至曼彻斯特机场的飞机。AAIB调查员已开始进行询问并收集证据。”

这架波音737-800客机最多可搭载189名乘客。机上一名乘客描述了一段据信长达两小时的艰难着陆尝试。飞机在普雷斯特维克两次尝试降落，随后飞往爱丁堡，最终抵达曼彻斯特。

乘客亚历山大·马尔基告诉《艾尔广告报》：“在下降前大家都很平静；我们被颠簸得厉害，摇摇晃晃。在第二次降落尝试时，有几个人很担心，因为我们能感觉到飞机很吃力。”

“然后飞行员出乎意料地宣布他将尝试在爱丁堡降落。但这情况和在普雷斯特维克的第二次尝试一样糟糕。”

“在福斯湾上空有湍流，然后当我们接近机场，就在快要着陆时，飞机又再次被急剧拉起。”

乘客们随后被从曼彻斯特送往普雷斯特维克，比原定于周五下午6点的计划到达时间晚了10个小时。

一名审查了该日志的飞行员表示：“想象一下，当你的剩余燃油低于2吨（2000公斤）时，你就会开始密切关注状况。低于1.5吨时，你会开始冒冷汗。但这次事故（指剩余220公斤燃油）离一场致命事故只有一步之遥。”

Igalia 宣布获得主权技术基金的资助，将用于推进 Servo 网络引擎的发展。作为 Servo 的管理方，Igalia 此次资助将专注于公共利益、开发者可用性和长期可持续性三个方向。

Servo 是一个用 Rust 编写的现代化、并行化网络引擎，由 Igalia 自 2023 年起积极维护，是 Linux 基金会欧洲项目。其模块化设计使其成为 Rust 生态系统中的重要资源，但仍需持续投资以实现全部潜力。

未来一年，借助主权技术基金的投资，Igalia 将重点推进以下三项工作：

初始无障碍支持：随着 Servo 的采用率提升，其缺乏对屏幕阅读器等辅助技术的基础无障碍支持，这限制了其在实际场景中的可用性。此资金将用于实现初始无障碍功能，确保 Servo 能够服务所有用户，使其成为适用于面向公众应用的引擎。

WebView API：将 Servo 嵌入应用程序需要稳定且完整的 WebView API。目前已有早期工作，但尚未准备好普遍使用。此次工作将完成 WebView API 的开发，使 Servo 能够嵌入桌面和移动应用，从而解锁新的用例并推动更广泛的采用。

项目维护：Servo 不仅是浏览器引擎，也是 Rust 生态系统中广泛使用的 crate 集合。维护这些库不仅有益于 Servo，也有益于更广泛的网络平台。资金将支持更多的问题分诊、拉取请求审查、版本发布和治理工作，确保 Servo 保持活跃、响应迅速，并为开发者和用户提供良好维护。

Igalia 长期以来支持浏览器领域的开源创新，包括在 Chromium、WebKit、Gecko 方面的工作以及在标准和开发工具领域的领导作用。公司认为 Servo 将在网络引擎的未来中发挥独特作用。

2025年诺贝尔和平奖：玛丽亚·科里纳·马查多

获奖者：玛丽亚·科里纳·马查多

获奖原因：表彰其为推动委内瑞拉人民的民主权利所做的不懈努力，以及为实现从独裁政权向民主制度公正、和平过渡所进行的斗争。

背景说明：2025年诺贝尔奖共颁发了六个奖项，授予14位在物理学、化学、医学、文学、和平及经济科学等领域为人类做出最大贡献的获奖者。其成就范围涵盖从量子隧穿效应到促进民主权利等多个方面。

从Vim切换到Helix编辑器的笔记

本文作者分享了使用Vim/Neovim 20年后，尝试Helix编辑器三个月的使用心得。

切换动机

主要驱动力是开箱即用的语言服务器支持。在Vim/Neovim中配置一个令人满意的语言服务器环境（例如实现“跳转到定义”等功能）感觉过于繁琐。Helix内置了语言服务器支持，无需额外配置即可在任何语言中使用“重命名符号”等功能。

Helix的亮点

• 强大的搜索功能：在仓库中搜索字符串时，可以滚动浏览匹配文件并查看匹配项的完整上下文，优于之前使用的Vim ripgrep插件。
• 便捷的快速参考提示：例如，按下 g 键会弹出帮助窗口，提示可跳转的目的地，有助于记忆不常用功能的快捷键。
• 多光标编辑优于宏：作者更喜欢使用多光标（通过 % 全选、s 正则选择、然后编辑）来实现批量修改，取代了之前编写宏的方式。
• 缓冲区切换器：使用 <space>b 可以方便地切换缓冲区，作为Vim风格标签页的替代方案。

习惯调整与差异

• 导航：使用 Ctrl+O 和 Ctrl+I 来前进/后退到上一个光标位置，替代了Vim的标记（marks）功能。
• 单词定义：Helix的 w（单词移动）操作包含单词后的空格，与Vim的定义不同。
• 学习曲线：直接学习“Helix方式”比强行配置成Vim键位要容易得多。适应过程比预想的要快，大约一到两周后就不再感到生疏。

存在的不足

• Markdown编辑体验不佳：文本换行功能（:reflow）不如Vim的 gq 命令，尤其在处理列表时。在列表项末尾按回车无法自动继续列表。
• 缺少持久撤销：无法像Vim的 undofile 那样在退出编辑器后保留撤销历史。
• 无自动重载：文件在磁盘上更改后不会自动重新加载，需要手动执行 :reload-all。
• 偶尔崩溃：大约每周会遇到一次崩溃，可能与某个已知问题相关。

配置与使用

• 配置极其简洁：总配置仅有几行，主要包括主题设置、剪贴板同步和少数几个快捷键重映射（如注释切换、行首行尾跳转、文本换行快捷键）。
• 语言服务器配置：通过单独的 languages.toml 文件配置，例如为Python设置black格式化和pyright语言服务器，并关闭自动格式化。
• 终端工作流：采用每个项目一个终端窗口的方式，将Helix置于第一个标签页，对此工作流感到满意。

总结

作者认为转换过程比预期容易，并对Helix开箱即用的集成体验（尤其是语言服务器和搜索功能）表示赞赏。尽管存在一些不足（特别是Markdown相关功能），但仍在持续使用。使用三个月后，作者尚未决定是否会回到Vim，目前对Helix保持满意态度。

“氛围编码地狱”已取代“教程地狱”成为编程教育的新困境

在编程学习领域，一个新概念——“氛围编码地狱” ——正在取代长期以来困扰学习者的**“教程地狱”** 。这两种“地狱”代表了技术演进下，学习者面临的不同核心困境。

从“教程地狱”到“氛围编码地狱”

• “教程地狱” 指的是学习者长期陷入跟随各种教程，能完成教程中的项目，但一旦脱离指导便无法独立构思和编码的现象。其核心是过度依赖结构化指导，缺乏独立解决问题的能力。
• “氛围编码地狱” 则是一种全新的困境，主要源于AI代码助手和生成工具的普及。学习者现在面临的问题是：能够利用AI工具快速“拼凑”或生成看似能工作的代码片段，但对这些代码的底层逻辑、工作原理以及为何有效缺乏深入理解。他们沉浸在一种高效编码的“氛围”或感觉中，却未能真正掌握编程的思维和技能。

现象的具体表现

1. 表面效率与实质理解脱节：借助AI，学习者能更快地产出代码成果，但这导致他们对基础概念、算法、调试和系统设计的学习深度不足。
2. 调试能力退化：当AI生成的代码出现问题时，学习者往往难以独立诊断和修复，因为他们不理解代码的内在运作机制。
3. 创造力与问题解决能力受限：过度依赖工具生成解决方案，可能削弱学习者从零开始构思架构、进行创造性问题解决的能力，而这是专业开发者的核心价值。

背后的原因与影响 这一转变主要由AI编程助手的广泛普及所驱动。这类工具极大地降低了编写代码的初始门槛，提供了即时的代码建议和补全。然而，如果学习者仅将此作为抄近路的方式，而不是作为理解概念和加速学习的辅助，就会落入新的陷阱。

其长期影响是可能培养出一批能够操作工具，但无法真正理解和构建软件的“代码操作员”，这与教育的目标背道而驰。

如何应对与避免“氛围编码地狱”

1. 坚持原理学习：在使用AI工具的同时，必须系统性地学习数据结构、算法、编程语言核心概念和软件工程原则。
2. 深度参与与主动思考：将AI视为“结对编程”的伙伴或学习助手。对于AI生成的代码，要主动提问：“它为什么这样写？”“有没有其他实现方式？”“每一行的作用是什么？”
3. 强化手动实践与调试：刻意安排不使用AI辅助的时间，进行纯手动编码和调试，这是培养核心技能不可或缺的环节。
4. 以构建项目为中心：学习过程中应始终以完成一个有实际功能的项目为目标，将新知识融入项目中应用和巩固，而不是孤立地练习代码片段。

结论 编程教育的挑战已从避免“教程地狱”演变为警惕“氛围编码地狱”。在AI时代，关键在于平衡利用工具的效率与构建坚实的理解基础。学习者和教育者都需要调整策略，确保技术进步真正赋能于深度学习，而非制造新的、更隐蔽的能力断层。

Rubygems.org AWS根访问事件审查报告（2025年9月）

事件概述

2025年9月30日，Ruby Central公开了一起涉及RubyGems.org生产环境AWS根账户的安全事件。前维护者André Arko在访问权限被撤销后，仍通过共享凭证保留了根账户访问权限，并被未授权方使用。调查未发现用户数据泄露或服务中断，但承认存在严重的流程失误。

关键时间线

• 9月18日 18:04 UTC：Ruby Central通过邮件通知Arko撤销其生产环境访问权限及值班服务，但未同步轮换AWS根账户密码。
• 9月19日 04:35 UTC：未授权方从旧金山IP地址更改了AWS根账户密码。
• 9月28日 05:49 UTC：未授权方从东京IP地址访问根账户并进行IAM检查。
• 9月30日 15:25 UTC：未授权方从洛杉矶IP地址访问根账户，并获取凭证（即后续博客披露的内容）。
• 9月30日 17:23-18:24 UTC：Arko邮件告知仍存访问权限，公开博客曝光。Ruby Central紧急响应，于18:24 UTC通过密码重置夺回根账户控制权。

影响范围

• 未发现数据泄露：用户数据、个人身份信息（PII）、财务数据、生产数据库、S3存储桶及CI/CD管道均未受损。
• 服务未中断：RubyGems.org全程保持正常运行。
• 主要风险：未轮换的共享凭证导致未授权访问，且公开披露引发社区担忧。

根本原因

1. 凭证管理失误：在撤销人员访问时，未同步轮换AWS根账户密码及多因素认证（MFA）。
2. 共享凭证外泄风险：未考虑密码管理器中的共享凭证可能被复制或导出至外部系统。

后续处理与改进

即时措施

• 撤销所有根账户及IAM凭证，新建受MFA保护的访问权限并存入受限保管库。
• 轮换所有相关密钥（包括DataDog、GitHub Actions等集成服务）。
• 启用AWS CloudTrail、GuardDuty及DataDog监控警报。
• 审核所有IAM角色与策略，实施最小权限原则。

长期改进

• 更新访问撤销流程，确保人员变动时立即轮换非联合凭证。
• 委托外部机构进行独立安全审计。
• 制定正式的《运营商与贡献者协议》，明确生产访问权限的授予条件。
• 更新安全手册，包含季度凭证审查及事件响应协调流程。

事件背景与额外说明

• 预算调整背景：Ruby Central在2025年8月调整开源承包商预算，计划将二级值班服务从付费转为志愿者模式。Arko的咨询公司提出免费提供值班服务，但要求获取包含PII的HTTP访问日志用于数据变现。该提议因涉及隐私、利益冲突和治理风险被拒绝。
• 视作安全事件的原因：发现Arko仍保留含PII的生产系统访问权限后，结合上述背景，Ruby Central将此视为需立即响应的安全事件。

结论

Ruby Central确认此次事件未造成数据泄露，但承认流程存在严重缺陷。他们通过透明公开调查结果、实施技术修复与管理改进，并承诺加强社区信任。公司将继续致力于以负责任的态度维护RubyGems基础设施的安全与可靠性。

示例是最佳文档

当开发者查找文档时，大多数情况下（95%的时间）仅需一个示例即可满足需求，然而却常常无法在官方源中找到它。

正式技术文档通常面向深度沉浸在特定技术生态中的开发者。但许多开发者日常工作需同时应对多个项目、语言和框架，在不同“世界”间切换时，需要消耗大量心力来恢复上下文并理解现状。

以Python 3文档中的 max 函数说明为例。理解其定义（如 max(iterable, /, *, key=None)）需要预先掌握大量知识，例如 /、*、positional-only parameter separator、iterable、keyword-only arguments 以及 key 的常见含义等。开发者必须通读文字才能了解可传递的参数及函数调用方式。

虽然这些细节对完整理解很重要，但许多开发者访问该页面可能只是需要快速了解如何传递自定义排序函数。此时，一个简单的代码示例能更直接地帮助他们，例如：

max(4, 6) # → 6
max([1, 2, 3]) # → 3
max(['x', 'y', 'abc'], key=len) # → 'abc'
max([]) # ValueError: max() arg is an empty sequence
max([], default=5) # → 5

Clojure 社区中广受欢迎的项目 clojuredocs.org 即是一个由用户贡献示例的网站，对于内置函数的日常编程实践不可或缺。例如其关于 into、spit 或 map 函数的页面。这些示例常包含相关函数的用法，增强了文档在实际场景中的实用性与价值。

由于即使是大型软件项目也极少提供四种完整的文档类型，作者表示点击“文档”链接时常常犹豫，因为其内容很可能是艰涩、难读的、自动生成的API参考。因此，即使只需要示例而非手把手教程，也更倾向于寻找教程。

JustSketchMe 是一款专注于数字姿势参考的创作工具。

其核心目标是帮助艺术家、插画师和设计师快速创建和调整3D人物姿势，以解决绘画时寻找合适参考的难题。软件提供一个直观的3D模型界面，用户可以通过拖拽、旋转关节等方式，轻松摆出各种复杂动作。

产品标语 “限制仅在于你的想象力！” 强调了该工具的灵活性与创意自由度，旨在成为辅助视觉创作的强大参考工具。

本文分享了作者完成大型技术项目的方法：通过将任务分解为可快速看到成果的小阶段来维持动力。作者以开发终端模拟器项目为例，说明如何避免因目标过大而失去兴趣。

启动阶段：项目初期应选择能尽快产生可见结果的子任务，而非规划完整组件。例如终端项目从VT解析开始，因为可通过自动化测试快速验证，看到测试通过的数量增长能带来成就感。

早期成果阶段：若初始任务非可视化（如解析器），则依靠单元测试提供进展反馈。作者认为这是保持动力的重要工具，能让自己看到代码实际运行的进展。

冲刺演示阶段：目标不是完成完美子组件，而是构建“足够好”的版本以推动下一个演示。作者强调不应让完美主义阻碍进度，建议每周创建一两个演示版本，这能提供宝贵的自我反馈。早期演示可能功能有限（如终端项目的ASCII网格渲染），但能直观展现进展。

为自己构建：个人项目中，优先为自己所需功能开发，并尽快实际使用自己的软件。作者在终端项目中先只实现日常所需功能（如加载自己的Shell配置、启动Neovim），随后作为主力终端使用，这既能发现问题，也能保持动力。

总结方法：

1. 将大问题分解为多个可验证成果的小问题。
2. 仅解决推进演示所需的小问题，然后继续。
3. 尽快构建可运行的演示，并持续迭代。
4. 优先实现使自己能实际使用的功能。
5. 根据需求返回改进各组件，重复此过程。

作者认为此方法基于“看到结果能激励自己”的个人特点，虽未涵盖发布、工具链等内容，但适用于各种项目，并帮助其保持动力。

Google Safe Browsing 事件报告

2025年9月25日，域名 statichost.eu 被 Google Safe Browsing 系统错误标记为“欺骗性网站”，持续约6小时。此事件导致所有使用 Google Safe Browsing 服务（影响超过50亿设备）的用户在访问该域名下的任何网站时，都会看到严重警告或被直接阻止。部分托管在该平台上的自定义域名也受到影响。

事件经过

1. 发现问题：创始人Eric Selin收到用户报告，称网站因安全警告无法访问。
2. 调查与确认：使用Chromium浏览器测试后，确认自己的网站被Google屏蔽。通过谷歌搜索控制台发现，statichost.eu 域名因“检测到安全问题”（钓鱼攻击）而被列入黑名单。
3. 根本原因：周末期间，有大量恶意钓鱼网站通过 statichost.eu 的子域名被创建，触发了Google的自动检测系统。
4. 处理与恢复：根据Google提供的违规网站列表，作者删除了所有恶意网站，然后提交了复审请求。数小时后，封锁被自动解除。

核心问题与作者观点

• Google的权力集中：作者认为Google通过其产品（如Chrome浏览器）监控巨量网络活动来构建和维护安全浏览黑名单，这赋予了其对互联网的过大控制力。
• 误报的代价：尽管大部分被列入黑名单的网站确实有害，但此次“误报”凸显了该系统可能对合法业务造成严重影响。
• 处理方式的局限性：作者指出，与Google进行有效沟通以解决问题非常困难，整个过程依赖自动化系统。

后续措施

为增强域名抗风险能力，statichost.eu 平台上所有新创建的网站将默认使用 statichost.page 子域名。该新顶级域名正在申请加入公共后缀列表，以提高其安全性和独立性。

游戏核心特点

《Subway Builder》是一款超写实的交通模拟游戏。 玩家需从零开始构建地铁系统，同时应对现实世界的限制与成本。

• 真实乘客模拟： 游戏基于人口普查与选区数据生成数百万通勤者，并使用与现实手机相同的寻路算法进行模拟。玩家需通过优化站点布局、换乘动态和发车频率，设计出能将最多乘客快速送达目的地的线路网络。
• 真实建设挑战： 玩家需在真实的限制与成本下建设系统。隧道、高架桥、明挖回填法各有优劣。在扩展网络时，需与建筑物地基、地理环境和道路布局进行博弈。
• 深度分析系统： 游戏允许探索单个通勤者如何权衡等待时间、换乘、收入分布、延误等因素来选择通勤路线。玩家可据此优化网络。
• 延误与中断： 玩家需在成本与时间之间找到平衡。线路上过多列车或站点过度拥挤都将导致延误。

开发计划

• 2025年10月（公测）： 已完成核心游戏机制、城市模拟及初始城市列表。
• 2025年冬季（国际扩展）： 已完成。将增加美国以外的城市，具体取决于数据可用性。
• 2025年冬季及2026年春季（常规改进）： 进行中。改进可视化工具、详细的客流分析、错误修复及性能优化。
• 2026年春季（3D玩法）： 进行中。为游戏添加3D玩法，届时轨道、列车、隧道和桥梁也将实现3D化。
• 2026年春季（Steam发行）： 计划中。将在Steam平台发行，包含成就和云存档功能，并参与每日挑战以竞争排行榜名次。

## 1. 背景与限制
作者乘坐加拿大航空从加拿大飞往香港（约12小时）。飞机提供WiFi，但非付费的Aeroplan会员仅能使用**免费短信服务**（如WhatsApp、WeChat的文字消息），无法访问其他网站。无限制上网需支付30.75加元，观看视频需39加元。作者希望绕过限制，免费访问其他网站。

## 2. 突破过程
作者与身处异地的网络安全专家室友远程协作，尝试突破限制。

### 方法1：伪装域名
- **思路**：修改本地`/etc/hosts`，将代理服务器IP绑定到`acwifi.com`域名，利用自签名证书让浏览器信任该连接，从而通过代理访问目标网站（如github.com）。
- **结果**：发现代理服务器IP及知名CDN IP（如Cloudflare的172.67.133.121）均**完全不可达**（ping超时），且TLS连接也失败，表明网络对特定IP进行了封锁。此方法失败。

### 方法2：DNS端口伪装
- **发现漏洞**：尝试使用任意外部DNS服务器（如`40.115.144.198`）进行域名解析，发现**成功**。同时，TCP模式的DNS查询也未被封锁。
- **实现**：利用**端口53未被严格审查**的漏洞，将代理服务器伪装成DNS服务器（监听53端口）。室友使用`xray`工具快速搭建了代理服务器（使用VLESS协议，通过TLS over TCP在53端口提供服务）。
- **结果**：作者在本地配置xray客户端后，成功通过SOCKS5代理访问了被限制的网站（如github.com）。**突破成功**。关键点在于：网络网关可能仅根据端口判断是否为DNS流量，而未深度检查内容。

### 方法3：DNS隧道（理论方案）
- **思路**：若网关深度检查DNS包内容，则可采用DNS隧道技术，将数据封装在合法的DNS TXT查询中。
- **结果**：因航班上未安装`iodine`等DNS隧道客户端，此方案未能实践，仅作为理论备份。

## 3. 结论与反思
- 作者与室友耗时约4小时远程协作，成功突破限制，证明了方案可行性。主要归功于室友的专业技术支持。
- **实际体验**：虽突破限制，但机上带宽极低，网页浏览体验差，因此作者后续并未大量使用。
- **免责声明**：此次探索仅为技术研究与教育目的，严格遵守相关法规与服务条款。

## 4. 后续讨论：能否突破带宽限制？
- **读者疑问**：免费短信服务是否存在带宽限制，无法达到付费WiFi的体验？
- **作者分析**：理论上可以通过**ARP欺骗**来“伪装”为付费用户。假设付费用户设备MAC地址被加入网关白名单以享受高带宽。通过ARP欺骗将自己的MAC地址伪装成已付费用户的MAC地址，可尝试获取高带宽。
- **风险与可行性**：此方法**涉及未授权访问飞机网络系统，属于非法行为**。作者仅作理论探讨，未实际尝试。

从HTMX迁移到Datastar的实践总结

作者分享了从使用HTMX切换到Datastar库进行Web应用开发的经验与见解。

切换动机 作者在结合使用HTMX与AlpineJS时遇到同步难题，两个库需要开发者手动协调，导致调试困难和代码量增加。发现Datastar能以更小的体积（约11KB）融合两者功能后，决定尝试并成功解决了问题。

核心优势对比

1. API更简洁：Datastar的HTML属性更精简。例如，实现一个交互通常只需一个data-on-click属性，而HTMX可能需要hx-target、hx-swap等多个属性，降低了心智负担和维护成本。
2. 服务器驱动的更新模式：
   • HTMX：是前端库，在触发元素上声明行为（如目标、交换方式），逻辑可能分散。
   • Datastar：是服务器端驱动库，由服务器决定更新哪些页面部分。服务器直接返回要更新的HTML片段，使逻辑更集中。
3. 组件化思维：鼓励将UI视为独立组件，由服务器管理状态（如加载、完成、错误），返回完整组件视图，避免客户端进入无效状态。
4. 实时多用户更新：内置对Server-Sent Events (SSE) 的支持，允许服务器主动向客户端推送更新，无需复杂WebSockets或轮询，适合构建实时协作应用。
5. 拥抱Web原生特性：提倡使用CSS视图过渡、Web Components等原生技术，提升代码复用和局部化。

实践理念与最佳实践

• 不要过度复杂化：允许服务器重新渲染整个组件发送给客户端，通常足够高效且易于压缩。
• 服务器为状态核心：服务器作为状态的唯一真理来源，减少客户端复杂的状态管理。
• 善用Web Components：可将复杂逻辑封装为自定义元素（如<ds-starfield>），实现高内聚和复用。

强大能力展示 Datastar社区展示了其处理极端场景的能力，例如：

• 在廉价服务器上运行十亿个复选框的实验。
• 实时显示全美80多万个雷达站数据点，每秒更新超过80万次，并支持一小时内的时光回溯，延迟极低。

总结感受 作者认为Datastar在保持HTMX带来的开发愉悦感和简洁性的同时，提供了更强大的能力（尤其是实时推送和组件化）。它减少了代码量，优化了性能，并利用了Web平台的原生潜力，感觉像是发现了Web应用本应有的构建方式。

该内容展示了Hacker News网站的导航栏界面，包含以下主要部分：

1. 网站标识：顶部显示网站名称“Hacker News”。
2. 导航链接：列出了网站的主要功能分区，包括：
   • new：查看最新内容
   • threads：浏览讨论主题
   • past：查看历史内容
   • comments：查看评论
   • ask：提问区
   • show：项目展示区
   • jobs：招聘信息
   • submit：提交内容
   • live：实时动态
3. 附加链接：末尾有一个repo链接，可能指向相关代码仓库。

整体呈现了Hacker News作为技术社区的核心功能入口结构。

https://www.wsj.com/economy/federal-budget-fiscal-2025-e8d21595

问题概述

在英国地区尝试从 Nixpkgs 构建使用 fetchFromRepoOrCz 函数的软件包时会失败，原因是 repo.or.cz 网站因英国《在线安全法》屏蔽了来自该国的访问。

根本原因

• fetchFromRepoOrCz 函数（定义于 pkgs/build-support/fetchrepoorcz/default.nix）会从 https://repo.or.cz/ 下载源代码。
• 该网站将来自英国的所有请求重定向到 https://repo.or.cz/uk-blocked.html。
• 当构建系统尝试下载 .tar.gz 格式的源码压缩包时，实际获取的是 HTML 屏蔽页面，导致解压失败。

错误现象

构建时会出现类似以下错误：

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
do not know how to unpack source archive ...

手动使用 curl 下载指定 URL 也会得到 HTML 文件而非预期的压缩包。

影响范围

经 rg 搜索，以下 7 个软件包声明使用了 fetchFromRepoOrCz：

1. pkgs/by-name/wi/windowmaker/package.nix（已声明但未使用）
2. pkgs/by-name/ti/tinycc/package.nix
3. pkgs/applications/editors/vim/plugins/nvim-treesitter/generated.nix（已声明但未使用）
4. pkgs/by-name/cd/cdimgtools/package.nix
5. pkgs/by-name/sy/syslinux/package.nix
6. pkgs/by-name/gl/glpng/package.nix
7. pkgs/development/python-modules/docutils/default.nix

其中，docutils、tinycc 和 cdimgtools 的构建已被确认失败。

其他信息

• Nixpkgs 版本：Stable (25.05)
• 系统环境：测试于 i686-linux 和 x86_64 系统
• Hydra 无法重现：官方构建服务 Hydra 无法复现此问题，因为其构建机器可能不在英国。
• 维护者通知：问题已标记相关软件包的维护者（如有）。

问题性质

这是一个因外部网络限制导致的构建依赖源下载失败问题，并非 Nixpkgs 代码本身的缺陷。受影响的用户位于英国地区。

C语言Web框架的内存安全问题摘要

作者喜爱C语言，因其跨平台、高性能及与硬件的亲密感，所有个人项目都用C编写。然而，C语言也存在危险，共享项目可能带来风险。

作者作为安全研究员，检查了Hacker News上一个用C编写的Web框架，发现内存安全漏洞。核心问题在于HTTP请求解析中，Content-Length头的值未经验证直接用于内存操作。

• 代码中，parseRequest函数通过atoi从请求头获取Content-Length值，赋给parser.request.bodyLength，该值来自用户输入，未做有效性检查。
• 随后，使用malloc(parser.request.bodyLength + 1)分配内存，并循环复制请求数据到parser.request.body。
• 若Content-Length值大于实际请求大小，会从堆中复制越界数据，导致内存泄露或溢出。

此外，项目中使用有符号整数存储长度（如int bodyLength），这可能引入负值问题，引发未定义行为。例如，恶意用户传递Content-Length为4294967295时，malloc(0)在glibc中返回有效指针，但后续循环条件可能导致逻辑错误。

总结：C语言编写Web框架需严格验证输入，否则易产生内存安全漏洞，危害系统安全。

RubyGems 安全事件：个人陈述澄清

核心主张

• 个人角色澄清：作者 André Arko 声明自己担任 RubyGems.org 主要运营者超过十年，工作期间未造成任何损害或数据泄露。
• 行动背景：其操作是应对 Ruby Central 突然且反复撤销团队权限所引发的混乱与安全疑虑，旨在保护 RubyGems.org 服务免受潜在威胁。

事件关键时间线

1. 权限撤销与混乱：

   • 2025年9月，Ruby Central 突然撤销团队在 GitHub 的权限，随后又恢复，但次日再次撤销。
   • 团队负责人 Marty Haught 的沟通出现矛盾，声称“搞错了”，并承诺参与治理讨论，但权限问题未妥善解决。

2. 用户应对措施：

   • 作为当值主要工程师，为防范可能的账户入侵或社会工程攻击，作者临时锁定 AWS 账户，但保留所有账户的组织控制权（未更改邮箱）。
   • 几天后，作者意识到权限撤销是 Ruby Central 的故意行为，便停止干预，期望其完成安全审查。

3. 发现安全漏洞：

   • 约两周后（9月30日），作者发现自己仍拥有 AWS 根账户访问权限、DataDog 监控访问权，以及多个 GitHub 组织的所有权。
   • 用户立即通过邮件向 Ruby Central 书面披露此问题，并确认未下载或保存任何生产数据、个人信息（PII）或其他组织数据。

4. Ruby Central 的回应与后续：

   • Ruby Central 三天后才回复，仅询问 AWS 凭据状态和是否持有数据，未提及已披露的其他服务凭据（如 1Password 账户）仍有效的问题。
   • 同时，Ruby Central 的律师指控作者“非法入侵”AWS 账户，作者否认此指控。

主要争议点

• 安全责任归属：作者强调自己的操作是基于付费合同中的防御职责，而 Ruby Central 在安全审查中未能及时撤销所有访问权限。
• 凭据管理疏忽：作者指出，Ruby Central 似乎混淆了团队使用的 1Password 账户（“RubyGems”与“Ruby Central”账户），导致关键运维凭据未被轮换。
• 沟通与透明度：作者批评 Ruby Central 回应迟缓、回避问题，并质疑其公开声明中“透明管理”的可信度。

结论

作者坚持自己的行为出于防御目的，且始终致力于保护服务安全与组织利益。他呼吁关注 Ruby Central 在安全流程和沟通中的不足，并保留了相关邮件证据以支持其陈述。

Datastar 是一个轻量级超媒体框架，用于构建交互式 Web 应用，其核心特点是将状态管理移至后端，从而简化前端逻辑。

核心特点：

• 轻量且独立：框架仅由一个 11.81 KiB 的文件构成，不依赖复杂的 JavaScript 生态系统。
• 后端驱动：开发者可以使用任何后端语言（官方提供 SDK）编写逻辑，框架通过接收 text/html 和 text/event-stream 内容类型，支持返回普通 HTML 或通过服务器发送事件（SSE）实现流式更新。
• 声明式交互：前端通过 HTML 的 data-* 属性（如 data-on:click）来定义交互行为，无需编写用户端 JavaScript 代码即可实现响应式功能。
• 解决 SPA 复杂性：旨在避免传统前端框架带来的状态管理、虚拟 DOM、Hooks 等复杂性，通过后端驱动的方式提供实时和协作功能。

工作流程示例： 前端使用属性声明交互意图，例如点击按钮时向特定后端端点发送请求。后端处理请求后，可以直接返回修改 DOM 的指令（如通过 sse.PatchElements 更新页面特定元素），从而实现无用户端 JavaScript 的动态更新。

定位与优势： Datastar 适用于从简单网站到实时协作应用的各类场景，其口号是“在缓慢变化的高性能框架上快速迭代”。用户评价强调其解决了前端开发中的复杂性，提供了类似 React 的功能但架构更简单，并免费支持多人实时和跨后端语言的特性。该项目由一个非营利组织支持，并强调手工编码、简单、快速和轻量。

Burrows-Wheeler Transform (BWT) 概述

Burrows-Wheeler Transform (BWT) 是一种重要的字符串变换算法，广泛应用于数据压缩（如 bzip2）和生物信息学序列比对工具（如 bowtie 和 bwa）。

核心特性

BWT 具有两个关键属性：

1. 字符聚集性：变换会重排字符串，使得相同的字符倾向于聚集在一起。例如，字符串 coconut 的 BWT 结果是 tooccun。
2. 可逆性：变换是可逆的，可以从变换后的字符串恢复原始字符串，这是其实用性的基础。 此外，该算法通常不直观，其操作步骤可能显得任意，理解其原理需要建立直觉。

BWT 算法步骤

对字符串应用 BWT 主要分为三步：

1. 添加结束符：在原始字符串末尾添加一个特殊字符（如 $），以标记字符串的结束。此标记对于确保变换的可逆性至关重要。
2. 生成并排序所有旋转：生成原字符串的所有循环旋转（即字符串首尾相接形成的所有可能序列），并将这些旋转序列按字典顺序进行排序。
3. 提取变换结果：取排序后矩阵的最后一列，即为该字符串的 BWT 结果。

排序操作导致了以相同字符开头的行被分组，因此最后一列中（即在原序列中位于这些开头字符之前的字符）也倾向于形成聚集。

解码 BWT

从 BWT 字符串重建原始矩阵的过程如下：从一个空矩阵开始，重复执行“将 BWT 字符串作为新列添加到矩阵前端，然后对所有行进行排序”的操作，直至矩阵完整。最后，从矩阵中任意一行（通常通过 $ 标记定位）即可读出原始字符串。其原理在于，每次添加和排序都逐步重建了原始矩阵从第一列开始的更多列。

BWT 用于序列比对

BWT 在序列比对中的应用依赖于一个关键属性——最后到首位映射（Last-to-First Mapping）：

• 属性：在 BWT 矩阵中，第一列中某个特定字符出现的顺序，与该字符在最后一列中出现的顺序完全一致。
• 查找子串：利用此属性，可以在仅使用第一列和最后一列的情况下高效搜索模式。例如，在 banana 的 BWT 中搜索模式 an：
  1. 找到最后一列中以模式最后一个字符（n）结尾的行。
  2. 利用映射属性，定位到第一列中对应的 n，其所在行的开头即为一个匹配的起始位置（此时是 an 的 a）。
  3. 重复此过程，可以回溯找到所有匹配项。
• 用于解码：此搜索机制也可用于解码 BWT。解码可视为一个特殊搜索，即查找以结束符 $ 结尾的字符串，通过反复应用映射属性即可重建原始序列。

进一步学习方向

文章提到了几个相关的深入主题：

• 后缀数组：一种更高效生成 BWT 矩阵的数据结构，可以改善算法的时间复杂度。
• FM 索引：一种结合了 BWT 和其他数据结构的索引，用于在大规模序列（如人类基因组）中实现快速的百万次级模式查询。
• 压缩应用：BWT 的字符聚集特性使其能与游程编码等方法结合，实现高效的数据压缩。

文章总结：政府如何篡改了我的名字

本文通过作者的个人经历，探讨了移民在适应新国家官僚体系过程中所面临的身份认同困境，特别是名字在跨文化行政系统中如何被简化、误拼或重组，从而反映出身处不同文化夹层中的挑战。

核心要点

• 名字的文化意义：作者原名Leonel Giovanni García Fenech，包含父姓（García，西班牙常见姓）、母姓（Fenech，马耳他姓氏，意为“兔子”），以及纪念祖父的名字（Leonel 与犹太传统相关，Giovanni 为意大利名）。四名制在西班牙语国家常见，既体现家族传承，也能区分常见姓氏。

• 官僚系统的简化与错乱：

  • 移民美国后，作者为方便选择去掉“Leonel”，成为 Giovanni García Fenech。
  • 美国行政机关（如DMV）强制将名字塞入“名-中间名-姓”格式，导致名字被改为 Giovanni F Garcia（省略重音符号）或 Giovanni Garcia Fenech（颠倒顺序）。
  • 文件不一致导致长期身份混乱，银行、邮件等均使用不同变体。

• 政策与身份冲突：

  • 9/11后出台的《REAL ID法案》要求统一证件，但实施拖延，迫使作者试图协调文件，却因系统僵化而选择保持现状。
  • 计划移居西班牙时，因可凭墨西哥血统加速申请公民身份，但需墨西哥护照。美国文件与出生证明名字不符，墨西哥领事馆拒绝签发，形成“文件死循环”。

• 跨文化官僚主义的普遍性：

  • 在西班牙，作者名字虽恢复了重音符号，但银行仍将其首名记为“Giovanni F.”。
  • 文章以一位华裔商店主为例：因顾客总询问前任店员“Lola”，她便自称Lola，体现名字在社群互动中被动重塑。
  • 作者感叹：“连星巴克都叫不对我的名字，政府怎会修正？”揭示了系统对个人身份的漠视。

• 身份认同的反思：

  • 名字承载家族历史与文化渊源，但官僚系统往往将其视为可随意调整的字符串。
  • 移民在适应中不断妥协，而系统错误又催生新的身份标签，形成循环困境。

结论

作者通过自身经历指出，名字在移民过程中不仅是称呼，更是文化、家族与行政系统碰撞的焦点。官僚机构的僵化与错误加剧了身份流动中的不确定性，迫使个体在保留原真性与寻求便利之间反复权衡，最终凸显了全球化时代下身份管理的复杂性与荒谬性。

核心观点：大语言模型（LLMs）在处理异常情况时表现出极度的敏感，甚至可视为“恐惧”。
具体实例：在x.com平台上，当错误发生时，系统会提示“出了点问题，但别担心——让我们再试一次”，并警告隐私相关扩展可能引发问题，建议禁用这些扩展后重试。
关联分析：这一错误消息和警告反映了LLMs在面对未预期异常或错误时的脆弱性，强调了其处理异常能力的局限性。

苹果下架了一款用于存档美国移民与海关执法局（ICE）相关视频的应用。这款名为“Eyes Up”的应用与此前被禁的实时追踪ICE官员位置的ICEBlock等应用不同，其主要功能是聚合来自TikTok、Instagram等平台的视频及新闻报道，旨在保存证据以备未来法庭使用。应用管理员表示，他们的目标是促进政府问责，而非实时追踪，并认为应用被下架是因为其中包含了大量可能对政府不利的视频证据。该应用已于10月3日被移除，目前在App Store中显示不可用。此事表明，在司法部向苹果施压后，苹果和谷歌对ICE相关应用的打击范围已超出实时举报类应用，波及了旨在建立历史记录的工具。

长期新冠脑雾的分子机制：AMPA受体密度增加与认知障碍相关

日本横滨市立大学Takuya Takahashi教授领导的团队通过一种新型脑成像技术，揭示了长期新冠（Long COVID）患者出现“脑雾”（认知障碍）的潜在分子基础。

研究背景与问题： 长期新冠是一种慢性疾病，影响全球数亿人，其中超过80%的患者遭受“脑雾”困扰，严重影响其日常生活和工作能力。然而，导致这种认知症状的生物学机制一直未被明确。传统的脑部影像学研究虽观察到一些结构变化，但未能直接揭示与认知功能直接相关的分子异常，缺乏客观的诊断生物标志物和治疗靶点。

研究方法与假设： 研究团队推测，长期新冠患者的脑雾可能与突触可塑性和记忆学习的关键分子——AMPA受体（AMPAR）的表达失调有关。为此，他们采用了一种先进的**[11C]K-2 AMPA受体PET成像技术**，首次在活体人脑中直接可视化并定量分析了AMPAR的密度。该研究对比了30名长期新冠患者与80名健康对照者的脑部影像数据。

主要发现：

1. AMPAR密度普遍升高：长期新冠患者大脑中多个区域的AMPAR密度显著且广泛地高于健康人群。
2. 与症状严重程度直接相关：患者脑内升高的AMPAR密度与其认知障碍（脑雾）的严重程度呈现明确的正相关关系。
3. 与炎症标志物关联：患者体内的多种炎症生物标志物水平也与AMPAR密度相关，提示炎症反应可能与受体表达的改变存在相互作用。
4. 诊断潜力：基于该成像数据的分析，能够以100%的敏感性和91%的特异性区分长期新冠患者与健康人，显示了其作为诊断工具的巨大潜力。

研究意义与展望： 这项研究为长期新冠脑雾提供了直接的分子生物学解释，明确了AMPAR作为关键的生物标志物和潜在治疗靶点。例如，抑制AMPAR活性的药物可能成为缓解脑雾症状的新疗法。Takahashi教授指出，该研究成果有助于推动医疗界认可长期新冠脑雾是一种真实的临床病症，并加速相关诊断和治疗手段的开发。尽管仍需进一步研究以找到根本解决方案，但这项工作为应对长期新冠这一重大公共卫生挑战迈出了重要一步。

参考文献：

• 原始论文标题：《长期新冠认知障碍相关的AMPA受体系统性增加》
• 发表期刊：Brain Communications
• DOI: 10.1093/braincomms/fcaf337

在北海一处石油钻井平台上，工程师兼自然爱好者克雷格·汉纳注意到一个奇特现象：成群的昆虫会定期从天而降，密密麻麻地覆盖平台高层，静止不动地停留数小时后集体飞走。他将采集的标本送至英国埃克塞特大学生态与保护中心，研究团队据此展开数年研究，并于近期发表了相关成果。

研究发现，这群昆虫主要是食蚜蝇，尤其以体表有橙黑条纹的橘酱食蚜蝇居多，此外还有普通食蚜蝇、丽蝇和根蛆蝇等。食蚜蝇是重要的传粉者（仅次于蜜蜂）和天然害虫控制器（幼虫捕食蚜虫），但其迁徙行为此前研究有限。

通过分析食蚜蝇体表的花粉，研究证实它们能携带来自500公里外的花粉，花粉种类超过100种植物（包括常见的荨麻、接骨木和绣线菊等）。这表明食蚜蝇具有长距离迁徙能力：它们秋季南迁至西班牙，春季北移至挪威，部分迁徙可能跨越数代完成。石油平台可能成为它们长途飞行中的中途休息点。

研究仍存在未解问题：一是远距离运输后的花粉是否仍具有授粉能力；二是食蚜蝇如何实现如此长途的飞行。目前研究人员正改进标本保存方法，并开展生理学研究。工程师克雷格·汉纳持续从平台上收集样本，其同事也从邻近平台提供样本，这体现了公民科学与学术研究的有益合作。

Spock 开源逻辑多主 PostgreSQL 复制总结

Spock 是一个为 PostgreSQL（版本 15、16、17、18）提供逻辑多主复制的开源扩展。

核心特性

• 逻辑多主复制：允许多个节点同时进行读写操作。
• 冲突避免：提供选项来处理多主环境下的数据冲突。
• 自动 DDL 复制：可配置为自动复制数据定义语言（DDL）更改。
• 广泛的功能：包括分区表复制、批处理插入、数据过滤、Snowflake 序列、大对象管理（Lolor）以及只读模式。
• 集群管理：提供添加/移除节点、使用 Zodan 实现零或最小停机时间节点添加等功能。
• 监控：支持监控集群配置、健康状况、延迟跟踪和同步事件。

前提条件与安装要求

• 节点一致性：所有集群节点上的表必须具有相同的名称、模式、列、主键和数据类型。
• 构建要求：需要从已应用特定版本补丁的 PostgreSQL 源代码树构建 Spock 扩展。
• 关键配置：postgresql.conf 文件必须设置 wal_level = ‘logical’、启用 track_commit_timestamp = on 以及加载 shared_preload_libraries = ‘spock’。还需配置 max_worker_processes、max_replication_slots 和 max_wal_senders 等参数。
• 网络与访问：pg_hba.conf 和防火墙必须允许节点间连接。

基本配置与使用流程

1. 在每个节点上：构建并安装 PostgreSQL 和 Spock 扩展，创建 spock 扩展。
2. 初始化数据库：确保各节点数据库结构相同。
3. 配置 PostgreSQL：修改 postgresql.conf（如上所述）并重启服务器。
4. 创建节点与订阅：
   • 使用 spock.node_create 在每个节点上定义其自身。
   • 使用 spock.sub_create 在每个节点上创建指向其他节点的订阅（因为是多主，每个节点既是订阅者也是提供者）。
5. 验证：可通过创建测试表（如使用 pgbench）并检查表是否在所有节点上同步来确认复制工作正常。

部署与升级

• 部署选项：支持通过 Ansible 或容器进行部署。
• 升级：由于目录表变更，升级不可回滚。升级前必须备份集群。升级过程类似于升级其他 PostgreSQL 扩展。

文档与许可

• 文档构建：使用 MkDocs 从 Markdown 源文件生成静态 HTML 文档。
• 许可：采用 PostgreSQL 许可证。

重要限制与注意事项

• 文档中提到了“限制”和“故障排除”章节，详细信息需参考完整文档。
• 具体的函数列表、高级配置选项和详细的工作流在原文中有专门章节阐述。

本文档记录了在手机终端应用 Termux 中为 ESP32 开发板刷写 MicroPython 固件的完整步骤。

免责声明： 本文仅供学习参考，操作风险自负。

硬件要求：

• ESP32 开发板（文中使用 ESP32-WROOM-32）。
• OTG 适配器。
• 支持数据传输的 USB 数据线（此点至关重要）。
• 安装了 Termux 应用（建议从 F-Droid 获取）的手机。

核心步骤：

1. 安装并配置 TCPUART 应用：

   • 由于直接使用 Termux 的 USB 串口连接存在稳定性问题，作者选择安装第三方应用 TCPUART。
   • 该应用作为桥梁，将 USB 串口连接转发为本地 TCP 服务器。
   • 在应用中设置波特率为 115200，连接设备后启动服务器，端口设为 8080。

2. 配置 Termux 环境：

   • 安装必要工具：pkg install -y python esptool mpremote socat。
   • 使用 socat 创建虚拟串口设备文件，连接到 TCPUART 的 TCP 服务器：

     socat pty,link=$HOME/esp32,raw,echo=0 tcp:127.0.0.1:8080 &
     

     此命令将在后台运行，并在 home 目录下生成名为 esp32 的设备文件。

3. 擦除 ESP32 闪存：

   • 首先将 ESP32 置于下载模式：按住 BOOT 按钮，短按再释放 EN(或 RESET) 按钮，最后释放 BOOT 按钮。
   • 执行擦除命令：

     esptool --chip esp32 --port $HOME/esp32 --before no-reset --after no-reset erase-flash
     

4. 刷入 MicroPython 固件：

   • 下载固件（链接来源：micropython.org/download/ESP32_GENERIC）：

     curl -L https://micropython.org/resources/firmware/ESP32_GENERIC-20250911-v1.26.1.bin -o esp32-micropython.bin
     

   • 确保 ESP32 处于下载模式，然后执行刷写命令：

     esptool --chip esp32 --port $HOME/esp32 --before no-reset --after no-reset write-flash -z 0x1000 esp32-micropython.bin
     

   • 刷写完成后，短按 EN(或 RESET) 按钮退出下载模式。

后续使用：

• 进入 MicroPython REPL：

  mpremote connect port:$HOME/esp32 repl
  # 或使用 minicom
  minicom -D $HOME/esp32 -b 115200
  

• 上传并运行程序：
  1. 创建 Python 脚本（例如 program.py）。
  2. 上传到 ESP32 的 / 分区并命名为 main.py（上电自动运行）：

     mpremote connect port:$HOME/esp32 cp $HOME/program.py :main.py
     

  3. 立即运行上传的脚本：

     mpremote connect port:$HOME/esp32 run $HOME/program.py
     

• 常用 mpremote 文件系统命令：
  • 列出文件：mpremote connect port:$HOME/esp32 fs ls
  • 查看文件：mpremote connect port:$HOME/esp32 fs cat main.py
  • 删除文件：mpremote connect port:$HOME/esp32 fs rm unwanted.py

结论与替代方案尝试： 作者指出，由于 Termux 在安卓上基于 Bionic Libc 且通常为 aarch64 架构，许多为 Linux 编译的二进制工具（如 ESP-IDF 工具链、PlatformIO、Rust 工具链）无法直接运行。尽管使用第三方应用 TCPUART 并非理想方案，但其相比直接使用 Termux 的 USB API（存在频繁断开、设备标识符变化等问题）提供了更稳定的串口连接。作者最终采用了这一方法成功完成了固件刷写和开发流程。

DDN: 离散分布网络

本文介绍了作者Lei Yang提出的一种名为离散分布网络的新型生成模型。该论文已被ICLR 2025接收，其核心思想是利用分层离散分布来逼近数据分布。模型认为网络内部特征本身蕴含分布信息，因此让网络同时生成多个样本（而非单一输出）可能是表征分布的一种有效方式。

核心思想与架构

DDN由多层离散分布层构成。在每一层，模型从输入条件生成K个离散样本点。一个引导采样器会选择与目标真实样本（Ground Truth）最相似的那个样本，作为下一层的输入。随着层数的增加，输出的表征空间呈指数级扩展，生成的样本与目标越来越相似。在推理时，若不提供目标，只需将采样器替换为随机选择，即可生成新样本。

关键贡献

1. 新模型提出：提出了DDN这一全新生成模型，其原理和形式更为简洁流畅。
2. 新优化算法：针对DDN训练，提出了分裂-剪枝优化算法及一系列实用技巧。
3. 实验与特性展示：在CIFAR-10和FFHQ等数据集上进行了初步实验，展示了DDN的独特性质与能力，包括：
   • 更通用的零样本条件生成：无需依赖梯度即可在非像素域（如使用黑盒CLIP模型进行文生图）执行条件生成。
   • 一维离散潜在表示：样本可映射到树状结构的潜在空间中的叶节点。

模型细节与训练

训练时，每一层DDL的损失仅基于所选的最接近样本计算。关键创新在于分裂-剪枝优化策略，它解决了传统梯度下降可能导致的“节点死亡”和“密度偏移”问题，能更精确地拟合目标分布。

DDN支持两种模型范式：

• 单次生成器：各层网络权重独立。
• 递归迭代：所有层共享权重。

实验演示与性能

文章通过多个示例展示了DDN的能力：

• 2D密度估计：GIF演示了DDN如何动态适应不同的目标分布图。
• 人脸图像随机采样：展示了在FFHQ数据集上的生成效果。
• 零样本条件生成：展示了在CLIP文本指导下的图像生成，以及图像着色、边缘到RGB转换等任务。
• 分层生成可视化：在MNIST数据集上展示了DDN从粗到精的递归生成过程。

常见问题解答

• GPU内存需求：训练时，DDN生成K个样本仅为寻找最近的一个，其余样本不保留梯度并被立即丢弃；推理时随机选择一个索引生成，因此内存需求仅略高于常规GAN，无显著增加。
• 模式坍塌问题：DDN选择与GT最相似的输出并使用L2损失优化的机制天然具有多样性倾向，能扩展生成空间。实验表明其具有良好的重建性能。真正的挑战在于试图覆盖超过其自身复杂度的高维分布时，可能导致生成模糊样本。

未来研究方向

作者推测了若干潜在方向：

1. 通过更精细的实验与理论分析改进DDN。
2. 扩展到ImageNet级别复杂度。
3. 应用于生成空间相对较小的领域（如图像着色、超分辨率）。
4. 应用于判别任务（如深度估计、光流估计）和机器人学。
5. 应用于非生成任务，如无监督聚类、数据压缩。
6. 借鉴DDN思想改进现有生成模型（如扩散模型）。
7. 探索在语言建模中的应用。

ICLR审稿评价认为该方法新颖优雅，开创性强，可能为生成建模开辟新的方向。

OpenGL Mesh Shaders扩展正式发布

OpenGL/ES工作组已正式批准发布 GL_EXT_mesh_shader 扩展。这是近十年来OpenGL发布的最大型扩展，标志着一项重大技术进展。

主要贡献者

该扩展主要由AMD工程师团队完成：

• Qiang Yu（AMD）主导了此项工作，承担了规范编写与核心Mesa实现的绝大部分工作。
• Shihao Wang（AMD）负责编写了CTS（一致性测试套件）用例，为生态系统做出了额外贡献。
• 同时感谢nvidium项目及其作者Cortex，该项目通过Minecraft模组推动了行业发展。

支持与实施情况

• Minecraft模组支持已处于开发阶段，预计很快可用。
• 扩展的基础部分已合并入Mesa，作者已提交启用Zink支持的合并请求（MR）。
• 合并策略：为尊重AMD的贡献，Zink支持的MR计划等待AMD驱动（RadeonSI）先合并其支持后再正式合并。最终截止日期为近期分支点或SGC项目休眠期（至2026年）前。

该扩展的发布标志着图形编程领域的一项重要里程碑。

Here’s what you should do to actually get a good deal on Amazon.

采访英特尔x86核心首席架构师：核心架构设计解析

本文基于对英特尔x86核心首席架构师Stephen Robinson的采访，重点介绍了Panther Lake和Clearwater Forest处理器中的核心架构设计思路与关键变化，涵盖Skymont（效率核）、Cougar Cove（性能核）和Darkmont（效率核） 的主要特性。

Skymont（效率核）相比Crestmont的改进

Skymont旨在构建更宽、更深的机器，以运行更多工作负载，提升平台能效。主要变化包括：

• 乱序执行深度增加约50%。
• 加载端口从2个增至3个。
• 向量硬件规模大致翻倍（从2个FMA增至4个FMA）。
• 前端从6宽、2簇、3解码升级为9宽、3簇，并支持8宽分配。
• 增加分支预测能力、L2带宽等。

存储端口设计的特殊考量

Skymont拥有4个存储地址生成单元，但仅支持每周期2个存储数据写入缓存。这一设计是为了减少加载与存储之间的依赖冲突：通过提前生成存储地址，降低因地址未知导致的加载阻塞，从而提升性能。

内存消歧技术的演进

在Darkmont和Cougar Cove中，内存消歧（主要涉及存储-加载转发）采用了新的实现方式：

• Darkmont：不依赖历史表，而是通过分析指令的固有信息，在地址生成前预测加载与存储的关联性，从而优化调度。
• Cougar Cove：采用类似理念但不同实现的方法，目标同样是准确判断加载-存储的依赖关系并合理调度。
• 两种实现差异源于两个团队并行研发，针对相同问题独立得出解决方案。

客户端与服务器中SMT（同步多线程）的策略差异

• 客户端（如Panther Lake）：由于采用混合架构（性能核+效率核），SMT价值有限。移除SMT可简化设计、降低功耗、减小面积并利于提升频率。
• 服务器（如Clearwater Forest）：目前不采用片上混合架构，而是在机架级实现不对称计算。服务器工作负载（如网络、数据库）常面临高延迟，SMT可有效利用等待周期，因此仍有较高价值。

客户端与服务器核心的实现差异

Darkmont核心同时用于客户端和服务器，但在服务器端会添加更多RAS（可靠性、可用性、可维护性）特性，例如缓存ECC。由于服务器环境对可靠性要求极高，且需要支持SGX/TDX等安全技术，因此需在SoC层面集成相应组件。核心物理设计差异不大，但外围环境（如电源管理、安全特性）显著不同。

分支预测技术的通用性

分支预测对客户端和服务器都至关重要。虽然服务器工作负载通常更复杂、代码更大，但游戏、数据库等客户端负载在代码特征上与服务器有相似之处。英特尔会为所有平台开发分支预测技术，其收益取决于具体工作负载，而非仅针对某一类场景。

总结

本次采访揭示了英特尔在核心架构设计上的关键思路：通过提升效率核性能、优化内存子系统、权衡SMT利弊以及适配不同计算场景，以平衡能效与性能。同时，客户端与服务器虽共享核心设计，但在特性实现和环境需求上存在明确分工。

Blaze：一个用Go编写的轻量级全文搜索引擎

Blaze是一个用Go语言实现的、专注于关键词搜索的全文搜索引擎。它为开发者设计，旨在提供一个轻量、可破解的实现，便于理解搜索引擎内部工作原理，而非用于生产环境的大规模应用（生产环境建议使用Bleve）。

核心特性与设计

• 主要功能：支持倒排索引、布尔查询、短语搜索、邻近查询和BM25相关性排名。
• 设计目标：代码小巧，结构清晰，便于学习和自定义。它专注于基于关键词的全文搜索，不包含语义搜索功能（如需语义搜索，可参考其姊妹项目Comet）。
• 数据结构：核心采用倒排索引映射词项到文档位置，并使用跳表来高效存储和查询这些位置（平均时间复杂度O(log n)）。查询过程中结合使用了Roaring位图来加速布尔集合运算。

核心工作原理

1. 文本分析管道：原始文本在索引前会经过一个可配置的处理管道：分词 → 转小写 → 停用词过滤 → 长度过滤 → 词干提取（默认使用Snowball算法）。这确保了搜索的健壮性（如大小写不敏感、词形还原）。
2. 倒排索引：索引记录每个词项在文档中的精确位置。这不仅支持快速词项查找，也是实现短语搜索和邻近排名的基础。
3. 搜索操作：
   • 基本/短语搜索：在索引中查找单个词项或连续的词项序列。
   • 邻近搜索：查找包含所有给定词项的文档，并计算词项间最小距离用于排名。
   • BM25排名：使用业界标准的BM25算法（考虑词频、文档长度、词项稀有度）对搜索结果进行相关性评分。
   • 邻近排名：一种替代排名方式，根据词项在文档中的接近程度来评分。
4. 查询构建器API：提供了一个类型安全、流式（Fluent）的API，用于构建复杂的布尔查询（AND, OR, NOT）。它避免了字符串解析可能带来的错误，并利用Roaring位图实现高效的集合运算。
   • 示例：NewQueryBuilder(idx).Group(q => q.Term("machine").Or().Term("deep")).And().Term("learning").Execute()。
   • 执行查询后，可直接获得文档ID位图，或通过.ExecuteWithBM25()获取BM25排序后的结果列表。

性能、配置与使用

• 性能：文档级的布尔查询（AND/OR/NOT）通过Roaring位图运算极快（约微秒级）。BM25计算和基于跳表的定位操作也相当高效。基准测试显示了其处理能力。
• 配置：可自定义BM25参数（k1, b）以适应不同领域，也可配置文本分析器（如最小词长、是否启用词干提取和停用词）。
• 持久化：索引可以序列化为紧凑的二进制格式进行存储和加载。
• 典型用例：文档搜索系统、日志分析、代码搜索、电商产品搜索等。

相关与注意事项

• Blaze vs Comet：Blaze处理关键词全文搜索；其关联项目Comet则专注于基于向量嵌入的语义搜索和混合检索（结合BM25与向量相似度）。
• 适用性：Blaze是一个教育性实现，适合学习和原型开发。对于生产环境，应考虑更成熟的解决方案。它专为那些希望理解搜索引擎（如倒排索引、BM25算法）内部原理的开发者而设计。

用 Rust 编写一个宏

本文介绍了 Rust 中宏的基础知识，并演示了如何编写一个简单的声明式宏（macro_rules!）。重点在于宏的设计思路与基础实现，而非其高级应用场景。

宏的背景与特点

• Rust 的宏工作于 抽象语法树（AST） 层面，而非简单的字符串预处理，这使得宏能够与语言结构深度集成。
• macro_rules! 是 Rust 中用于定义声明式宏的工具，它引入了 片段说明符（fragment-specifiers，类似于类型）来增强宏的类型安全性和可维护性。

宏的设计流程

编写宏应遵循以下步骤：

1. 评估是否真正需要宏：宏会增加代码复杂性和调试难度，应优先考虑其他抽象方式。
2. 设计最简单的宏调用形式（定义 DSL）。
3. 实现匹配臂：可逐步调整调用形式。
4. 逐一处理每个匹配臂。
5. 尽量复用子宏。

示例：实现一个 query! 宏

1. 设计宏调用形式

目标宏调用示例：

query!(from db select title)

预期输出：从 db 数据结构中提取所有元素的 title 字段，返回一个字符串向量。

2. 示例数据结构

使用 Song 结构体和向量作为模拟数据库：

struct Song {
    title: String,
    artist: String,
    rating: i64,
}
let db = vec![Song::new(...), ...];

3. 实现宏的匹配臂

宏的基本语法：($matcher) => { $expansion }。

• 匹配部分使用 $variable:fragment-specifier 捕获标识符。
• 本例使用 ident 片段说明符捕获数据库变量名和字段名。

第一个匹配臂：

#[macro_export]
macro_rules! query {
    ( from $db:ident select $field:ident ) => { };
}

4. 实现宏的扩展逻辑

将匹配到的部分转换为实际操作：

#[macro_export]
macro_rules! query {
    ( from $db:ident select $field:ident ) => {
        $db.into_iter().map(|i| i.$field).collect()
    };
}

• 使用 into_iter() 使其支持任何实现 Iterator trait 的类型。
• 通过 i.$field 访问结构体字段。

5. 使用与测试

调用宏并获取结果：

let results: Vec<String> = query!(from db select title);

若字段名错误，编译器会给出清晰的错误信息。

本文小结

本文介绍了宏的基本概念、设计流程，并实现了一个简单的查询宏。后续文章将进一步扩展该宏，以支持更复杂的查询语法（如 where 条件）。

J. Nicholas Betley 领导的合作研究致力于寻找长期持续性疼痛的神经基础，发现脑干中的一个关键枢纽存在一种能够阻止疼痛信号传递到大脑其他部分的机制。这一发现有助于临床医生更好地理解慢性疼痛，并有望带来新的、更有效的治疗方法。

研究揭示，该脑干枢纽能够作为疼痛信号的“关闭开关”，为理解和干预慢性疼痛提供了新的神经靶点。这一机制可能对开发新型镇痛疗法具有重要意义，从而帮助那些遭受长期疼痛困扰的患者。

楔形文字书写指南与大英博物馆的推广

背景与目的 大英博物馆的楔形文字专家 Irving Finkel 博士致力于推广楔形文字的书写。他的主要目的是以此作为切入点，吸引年轻学者投身于泥板破译工作。目前，该馆收藏了超过 13 万块跨越美索不达米亚早期王朝至新巴比伦帝国时期的楔形文字泥板，正等待学者们去解读。

博物馆资源与政策 大英博物馆中东部实行开放获取政策，设有专门的研究室，允许研究人员近距离接触和研究来自美索不达米亚及周边地区的大量楔形文字泥板。

书写方法与文字特点

• 书写工具与过程：书写过程相对容易上手，主要是将芦苇笔（或冰棍棒等替代物）的边缘压入粘土板中。
• 基本笔画：楔形文字由垂直、水平和对角线三种基本组件（笔画）构成。
• 文字系统：作为世界上最古老的书写系统，楔形文字是一种音节文字（类似于日本的汉字系统）。正确书写的音节会连成流畅的书法，受过教育的古巴比伦人可以一目了然地阅读。
• 学习周期：虽然基础的物理书写过程容易掌握，但要精通这一古老系统大约需要六年的专注学习。

相关扩展与推荐资源

• 文学创作：Finkel 博士曾受偶然发现的自然形成的楔形文字启发，创作了一本恐怖小说，并通过 Kickstarter 众筹成功出版。
• 入门推荐：建议初学者从 Finkel 博士的著作《楔形文字：古代脚本》（Cuneiform: Ancient Scripts）开始学习。
• 拓展内容：文章还提供了其他古代文化与语言的拓展链接，包括研究人员复刻 4000 年前的巴比伦炖菜食谱、阿卡德语原版朗读《吉尔伽美什史诗》、古希腊语免费课程，以及原始印欧语和公元前 100 年古代歌曲的语音重构等。

这篇文章以弗兰克·赫伯特《沙丘》中费雷曼人改造阿拉基斯星球的教训为引子，探讨了利用生命系统本身（即“全自然地球工程”）进行大规模环境修复的潜力、具体案例及面临的巨大挑战。

核心观点：生命是“技术”——能自我复制、自我维护、无限适应。在行星尺度上部署生物系统（如改变水文、调节气候、封存碳）是可行的，但会揭示无法逃避的相互依赖关系（如《沙丘》中摧毁沙虫和香料生态的后果）。地球本身可被视为一个由生命参与调节的自我维持系统（盖亚假说）。

主要生物地球工程案例与方法：

1. 生态工程师：海狸通过筑坝改造水文地貌，调节洪水、补充地下水、创建火灾避难所。人类可建造“海狸坝类似物”来吸引海狸回归。
2. 水资源管理：生物沟、雨水花园、珠草等基于自然的解决方案能有效减缓径流、净化水质、补充地下水。
3. 海岸与海洋保护：
   • 牡蛎礁：提供栖息地、过滤水质、消减波浪能量。多家公司正用创新技术（如预制砖、垂直养殖）加速修复。
   • 红树林：每年提供数千亿美元的防洪服务，固碳能力远超陆地森林，且可通过无人机技术大规模种植。
4. 碳封存与农业：
   • 海藻养殖：生长快，能高效吸收CO₂，某些品种还能减少牲畜甲烷排放。
   • 固氮树木：如金合欢属植物，能直接向土壤释放氮肥，改善贫瘠土地。
   • 传统生态农业：如中国的稻-鱼-鸭系统、日本的稻-鸭系统、美洲的“三姐妹”（玉米、豆类、南瓜）间作，通过物种协同增效，减少化学投入。
5. 气候调节：森林（尤其是亚马逊雨林）通过蒸腾作用制造云雨，调节区域乃至全球天气。此外，“海洋云增亮”研究旨在模仿船舶污染颗粒反射阳光的冷却效应，但使用无害的海盐气溶胶。

大规模应用的根本性挑战：

1. 工业与能源瓶颈：生物解决方案需要庞大的工业产能（如制造无人机、预制构件）和廉价的脱碳能源。目前，中国在机器人密度和制造业成本上占据巨大优势。
2. 治理与政治脆弱性：成功运行的基础设施会变得“看不见”，从而失去政治支持，导致预算削减（如美国州际公路、荷兰瓦赫宁根大学的农业研究面临经费削减）。
3. 金融错配：资本流向高回报的短期金融工程，而非产生长期、分散公共效益的生物基础设施。
4. 生态时间与气候时间的错配：生物系统成熟需要数年到数十年，而气候变化的影响正在加速。

结论与出路：技术可行性已被证实（海狸改变流域、亚马逊制造天气、红树林提供巨量防洪服务），但瓶颈在于工业产能、能源成本和政治意志。真正的前沿不在于在工程与生物系统间二选一，而在于有效整合两者（如将牡蛎礁与海上风电基础设施结合）。当前的轨迹默认可能走向第三条路：因无法规模化部署生物方案，而被迫依赖风险更高的干预措施。文章以《沙丘》的警示收尾：我们理解生物系统，但尚未建立以必要速度和规模部署它们的能力。

多核编程默认化：核心思想与实现

传统多核编程的困境

传统的多核编程通常以单核代码为基础，在需要并行时才切换到多核模式（如使用作业系统或并行循环）。这种方法带来以下问题：

1. 代码复杂性高：需要额外的线程创建、任务分发和结果合并逻辑，代码分散且维护困难。
2. 调试困难：控制流跨线程和时间分散，难以追踪完整上下文。
3. 上下文切换成本：频繁与操作系统内核交互或管理作业系统会引入开销。
4. 适用性有限：由于工程成本高，开发者往往只在关键处使用并行，浪费了大量潜在的并行机会。

核心范式转变：多核默认

作者提出将多核作为编程的默认状态，即所有代码默认在多个核心上执行，必要时才“收缩”为单核执行（类似GPU着色器编程）。主要特点：

1. 所有线程执行相同代码，通过索引（thread_idx）和数量（thread_count）区分任务。
2. 显式屏障同步（BarrierSync）确保线程在关键点协调。
3. 工作分配灵活：支持静态均匀分配、动态任务抓取或算法重组以实现负载均衡。

实现关键模式

1. 线程上下文（Lane上下文）：

   • 使用线程局部存储（TLS）保存当前线程的索引（LaneIdx()）、数量（LaneCount()）和屏障。
   • 调用者可通过修改这些参数动态控制代码的并行宽度（例如，将 thread_count 设为1即退化为单核）。

2. 范围分配工具：

   • LaneRange(count) 函数自动将循环范围均匀分配给各线程，简化数据并行分发。

3. 数据广播机制：

   • 使用共享缓冲区和原子操作在组内线程间广播少量数据（如指针、标量），替代静态变量的局限性。

优势与特点

1. 简化调试：所有线程执行相同代码，单线程调试即可理解整体行为；调用栈完整，上下文连续。
2. 灵活性：同一代码可灵活适配单核或多核执行，甚至混合组并行。
3. 低开销：避免了作业系统的复杂生命周期管理，资源（如内存）分配模式与单核代码一致。
4. 普适性：适用于广泛存在数据并行性的场景，如数值计算、文件读取、排序（如基数排序）等。

实践示例：并行求和

1. 输入：从文件读取数组，可分配为多线程读取。
2. 计算：各线程计算局部和，通过屏障同步后合并结果（可使用原子加或重复求和）。
3. 输出：单线程打印结果（收缩为单核执行）。

总结

多核默认编程通过将并行性内置于代码基础结构中，降低了并行编程的门槛，提高了硬件利用率，同时保持了代码的清晰性和可调试性。这一范式特别适合数据并行任务，为现代多核CPU编程提供了更直接、高效的实现路径。

微软在Viva Insights工具中新增了Copilot使用基准功能，旨在帮助管理者监控团队对Copilot的采纳情况。该功能通过Microsoft Copilot仪表板提供，允许按管理层级、地区和职位等维度，比较团队中活跃Copilot用户的比例、不同应用的采纳率等指标。微软称，用户活跃度以在Teams、Outlook、Word等产品中执行过AI相关操作作为判定标准。

为保护隐私，跨公司比较数据采用随机数学模型生成，不直接使用具体公司数据。但文章指出，该功能可能引发对过度监控的担忧，尤其在Copilot价值尚未完全证明的背景下。目前基准功能仅对部分预览客户开放，预计10月下旬面向所有客户推出。

此外，微软近期还允许员工将个人Copilot许可证带入工作场所，但基准功能暂未区分个人与企业许可证的使用情况。

Vite+ – 统一的 Web 工具链

Vite+ 是一个免费开源的统一工具链，旨在通过一个工具管理 Web 开发的运行时、包管理器和前端堆栈，遵循 MIT 许可证。

核心功能

• 管理运行时和包管理器：自动处理 Node.js 和包管理器（如 pnpm、npm、yarn、bun），确保项目使用正确工具。
• 简化日常开发：提供单一配置文件和一致的命令流，包括：
  • vp env：环境管理
  • vp install：安装依赖
  • vp dev：开发服务器
  • vp check：代码检查
  • vp build：生产构建
  • vp run：任务运行
• 支持框架：兼容所有基于 Vite 的前端框架。
• 高性能：基于 Rust 编写低级组件，实现企业级性能：构建速度比 webpack 快 40 倍，linting 比 ESLint 快 50-100 倍，格式化比 Prettier 快 30 倍。
• 优势：减少工具维护时间、提升团队协作、标准化最佳实践（包括 AI 辅助工作流）、加强供应链安全。

功能模块详解

• Vite+ dev & build：提供极速构建，包括即时热模块替换（HMR）、生产构建优化、插件生态支持，适合大型应用。
• Vite+ check：通过一个命令执行格式化、lint 和类型检查，集成 Oxlint、Oxfmt 和 tsgo，兼容 Prettier 和 ESLint 规则。
• Vite+ test：测试运行器，自动复用应用配置，支持 Jest 兼容 API、测试隔离、浏览器模式、覆盖率报告等。
• Vite+ run：用于 monorepo 和脚本的任务运行，具备自动化缓存和依赖感知执行。
• Vite+ pack：库打包工具，支持 TypeScript 和 JavaScript 库，生成类型定义（DTS）、自动导出配置，可打包独立应用二进制文件。
• 全栈支持：可作为从单页应用（SPA）到全栈元框架的基础，支持 Vercel、Netlify、Cloudflare 等部署平台，并与 Nitro 集成实现随处部署。

安装与使用

• 全局安装 vp，运行 vp help 查看帮助；CI 环境可使用 setup-vp。
• 支持 macOS/Linux 和 Windows PowerShell 安装脚本。

Vite+ 统一了 Web 开发工作流，提升开发效率，适合标准化开发实践和团队协作。