2026-02-01

芬兰考虑限制未满15岁儿童使用社交媒体：以澳大利亚为借鉴，强调教育

芬兰正在考虑限制未满15岁儿童使用社交媒体，这受到国内对儿童社交媒体影响日益增长的担忧以及澳大利亚近期相关政策的启发。

学校手机限制的成功经验

芬兰国际学校坦佩雷（FISTA）已经率先采取行动，禁止学生在校期间使用手机，除非用于课堂学习。该政策的实施得益于去年8月修改的法律，允许学校限制或完全禁止手机使用。 FISTA副校长Antti Koivisto表示，手机使用的减少激发了学生的创造力，让他们更积极地参与户外活动、组织活动和社交。

总理支持限制社交媒体

芬兰总理Petteri Orpo支持禁止未满15岁儿童使用社交媒体，理由是担心儿童缺乏体育活动。一项调查显示，三分之二的受访者支持这一禁令，比去年夏季的类似调查高出近10个百分点。

社交媒体的潜在危害

芬兰研究人员Silja Kosola将社交媒体对年轻人的影响描述为“失控的人类实验”，并指出其与自残和饮食失调等问题的增加有关。她还强调，芬兰儿童拥有手机的普及率很高（仅有几年时间，约95%的一年级学生拥有自己的智能手机），可能加剧了社交媒体的负面影响。

澳大利亚的先行者经验

自去年12月10日起，澳大利亚已禁止16岁以下儿童使用TikTok、Snapchat、Facebook、Instagram和YouTube等社交媒体平台。该举措源于一位母亲写给总理的信，信中表达了因女儿因社交媒体影响而自杀的悲痛。澳大利亚政府旨在将责任转移到社交媒体公司，并对违规行为处以巨额罚款。尽管实施仅六周，但初步迹象表明效果良好。

芬兰的考量与建议

居住在赫尔辛基的澳大利亚人Seona Candy认为，芬兰不应盲目照搬澳大利亚的政策，因为儿童可能会转向未知的、缺乏家长控制的平台。她建议芬兰应发挥其在教育和媒体素养方面的优势，投资于数字教育和数字安全知识的普及，而不仅仅是实施限制性法律。

总而言之，芬兰正密切关注澳大利亚的社交媒体禁令，并考虑在保障儿童福祉的同时，采取更全面的方法，侧重于教育和媒体素养，而非简单的立法限制。

iOS 26.3 隐私更新及移动网络定位数据泄露问题总结

本文探讨了 iOS 26.3 引入的隐私保护功能，以及移动网络获取用户位置信息的技术和潜在风险。

一、iOS 26.3 隐私保护功能

• Apple 在 iOS 26.3 中推出了一项新的隐私保护功能，旨在限制移动网络（通过基站）获取用户的“精确位置”数据。
• 此功能仅适用于配备 Apple 自研基带芯片的设备，该芯片于 2025 年推出。
• 基站定位的精度通常在几十到几百米的范围内。

二、移动网络获取精确位置信息的技术

• 除了基站定位，移动网络实际上通过内置协议，在用户不知情的情况下，获取设备上的 GNSS (GPS, GLONASS, Galileo, BeiDou) 定位信息，精度可达单数字米级别。
• RRLP (Radio Resources LCS Protocol)：在 2G 和 3G 网络中，网络会直接询问手机是否知道 GPS 坐标，并接收响应。
• LPP (LTE Positioning Protocol)：在 4G 和 5G 网络中，也使用类似的协议。
• 这些协议属于控制平面定位协议，与用户透明，用户无法直接察觉。
• GNSS 定位过程本身是被动进行的，设备无需主动发送任何信息。类似于阅读路标，无需告知他人你阅读了路标。

三、移动网络定位数据的使用案例

• 这些技术已在实际应用中使用多年。
• 例如，美国 DEA (麻醉品管制局) 在 2006 年通过运营商获取了嫌疑人的 GPS 坐标。
• 以色列 Shin Bet (安全总局) 长期以来一直在跟踪以色列境内所有手机的位置，通过运营商的数据中心收集信息，利用基站三角定位和 GPS 数据。
• 2020 年 3 月，以色列开始利用这些数据进行 COVID-19 接触者追踪，通过短信通知用户并要求隔离。

四、潜在风险与未知因素

• 作者承认 RRLP 和 LPP 并非唯一用于收集 GNSS 数据的技术，可能存在其他协议或后门。
• 存在外国运营商利用协议漏洞远程获取用户 GNSS 坐标的风险。虽然目前 SS7 漏洞只能定位到移动交换中心覆盖区域，但鉴于电信行业存在安全和诚信问题，这种风险不能被排除。
• 作者建议 Apple 允许用户禁用 GNSS 定位信息响应，并通知用户相关尝试。

总结

iOS 26.3 的隐私保护功能是 Apple 在限制大规模监控方面迈出的重要一步。但移动网络获取精确位置信息的技术已经存在，且已被广泛使用。 苹果需要进一步加强用户隐私保护，允许用户控制 GNSS 定位信息，并及时通知用户相关尝试。

WireGuard® 基础的覆盖网络和零信任网络访问平台总结 (Summary of WireGuard®-based Overlay Network and Zero Trust Network Access Platform)

该平台结合了 WireGuard® 覆盖网络和零信任网络访问 (ZTNA) 功能，旨在提供可靠且安全的连接。以下是其主要特点和功能：

1. 基于 WireGuard® 的覆盖网络 (WireGuard®-based Overlay Network):

• 核心技术: 平台利用 WireGuard®，这是一种现代、快速且安全 VPN 协议。WireGuard® 以其简洁性、高性能和易于部署而闻名。
• 覆盖网络构建: 通过 WireGuard®，平台构建了一个覆盖网络，允许设备之间安全地通信，无论它们位于何处。 这消除了对传统网络基础设施的依赖，并提供了更大的灵活性。
• 高性能和安全性: WireGuard® 协议的效率和安全性确保了覆盖网络的高性能和数据保护。

2. 零信任网络访问 (Zero Trust Network Access - ZTNA):

• 零信任原则: 平台采用零信任安全模型，这意味着默认情况下不信任任何用户或设备，即使它们已连接到网络。
• 持续验证: ZTNA 功能强制执行持续的身份验证和设备安全评估。用户和设备在访问应用程序和资源之前需要经过验证。
• 最小权限访问: 平台实施最小权限原则，只允许用户访问他们需要的特定资源，从而减少攻击面。
• 细粒度访问控制: 平台提供细粒度的访问控制，允许管理员基于用户身份、设备安全状态和上下文策略来定义访问规则。

3. 平台整合 (Platform Integration):

• 一体化解决方案: 该平台将覆盖网络和 ZTNA 功能整合到一个单一的解决方案中，简化了安全连接的管理和部署。
• 可靠性和安全性: 通过结合这两种技术，平台提供了一种可靠且安全的连接方式，适用于各种环境，例如远程工作、分支机构连接和云环境。

总结:

总而言之，该平台提供了一个基于 WireGuard® 的覆盖网络，并整合了零信任网络访问功能。它旨在通过提供安全、可靠且灵活的连接，解决现代网络安全挑战。 它的主要优势在于高性能、安全性、简化管理以及对零信任安全原则的遵循。

Swift 与 Rust：便利性的选择 (Swift vs. Rust: A Choice of Convenience)

本文探讨了 Swift 和 Rust 两种编程语言的相似之处和差异，并最终认为 Swift 在某些方面更具便利性。

Rust 和 Swift 的相似之处：

• 功能性编程特性： 两者都借鉴了函数式编程的思想，拥有标记枚举 (Tagged Enums)、模式匹配 (Match Expressions)、一等函数 (First-Class Functions) 和强大的泛型 (Generics) 系统。
• 内存安全： 两者都实现了类型安全，无需垃圾回收机制 (Garbage Collection) 或引用计数。
• 编译器： 两者都基于 LLVM 编译器，可编译为原生代码和 WebAssembly (WASM)。
• 底层能力： 两者都提供访问底层 C 指针的能力。

Rust 的底层视角 vs. Swift 的高层视角：

文章的核心观点是 Rust 是一种“自下而上” (bottom-up) 的底层系统语言，而 Swift 是一种“自上而下” (top-down) 的高级语言。Rust 提供工具来编写底层代码，而 Swift 则从高级抽象开始，并允许开发者深入到更底层的细节。

默认内存模型： Rust 默认使用“移动” (moved) 和“借用” (borrowed) 值，但使用 Cow<> (Clone-on-Write) 需要手动处理。Swift 默认使用“写时复制” (copy-on-write) 语义，更加便捷，但需要额外处理借用和移动。

语法与表达： Swift 通过使用熟悉 C 语言风格的语法来隐藏函数式编程概念，使开发者更容易接受。例如，Swift 的 switch 语句实际上是具有模式匹配功能的表达式，类似于 Rust 的 match 语句。

可选类型 (Optional Types)： Rust 使用 None 表示空值，而 Swift 使用 nil (本质上是 None)。Swift 使用 T? 表示可选类型，并要求开发者在使用前检查 nil 值，提供安全性和便利性。

错误处理 (Error Handling)： Rust 使用 Result 类型处理错误，而 Swift 使用 do-catch 块和 try 关键字。 Swift 的错误处理机制在表面上与 Rust 的 ? 运算符类似，但更加隐蔽。

编译器处理： Rust 编译器会捕获许多常见的错误并提供解决方案，例如处理自引用枚举 (self-referencing enums)。Swift 编译器则更加“自动化”，例如通过 indirect 关键字简化递归枚举的定义。

Swift 的便利性与权衡： Swift 设计的目标是取代 Objective-C，因此在实用性上做出了一些妥协，导致它成为一个更大的、功能更丰富的语言。虽然 Swift 更易于上手，但 Rust 默认情况下通常更快。

跨平台能力： 文章指出，Swift 已经不再仅仅局限于 Apple 平台，而正在发展成为一种优秀的跨平台语言，支持 Windows、Linux 和 WebAssembly。

Swift 的不足： 编译时间较长，存在一些功能冗余，语法并不完全统一，且包管理生态系统不如 Rust 丰富。

结论： Rust 更适合系统编程、嵌入式开发和编译器/操作系统开发。Swift 更适合 UI 开发、服务器端开发以及一些编译器和操作系统的部分。作者认为随着时间的推移，两种语言的重叠区域会越来越大。Swift 已经发展成为一种更便捷的 Rust 替代方案，尤其是在跨平台开发方面。

报告应用程序开发中的 --dry-run 选项总结

本文讲述了作者在开发新的报告应用程序时，加入 --dry-run 选项的经历和体会。

背景:

该应用程序每天工作日自动生成报告。其核心流程包括：定期检查报告生成时间、从数据库读取数据、应用逻辑生成报告、将报告压缩打包、上传至 SFTP 服务器、检查 SFTP 服务器的响应、解析错误响应并发送通知邮件。 报告和反馈文件在不同阶段移动到不同的目录。

--dry-run 选项的引入:

作者受到 Subversion 和其他 Linux 命令 --dry-run 选项的启发，决定在应用程序中也加入该选项。 --dry-run 模式下，程序会打印将要执行的步骤，而不会实际进行任何更改。

--dry-run 选项的功能:

--dry-run 模式下，程序会打印以下信息：

• 将要生成的报告（以及不生成的报告）
• 将要压缩打包和移动的文件
• 将要上传到 SFTP 服务器的文件
• 将要从 SFTP 服务器下载的文件 (包括登录和列出文件)

--dry-run 选项的益处:

• 快速的健康检查: 作者发现每天都会使用 --dry-run 选项作为快速检查，确认配置正确，状态符合预期，无需担心会造成任何实际修改。
• 快速测试反馈: 在测试完整系统时，作者可以通过 --dry-run 快速验证修改后的行为，例如修改报告状态文件中的日期，判断是否会生成报告，避免实际生成报告所需的时间。

--dry-run 选项的缺点:

• 代码污染: 为了实现 --dry-run，需要在代码的各个主要阶段添加检查，打印将要执行的操作，而不是实际执行。但这种影响并不深远，例如，报告生成代码本身无需检查。

结论:

作者认为，对于像其开发的这种通过命令触发，可能产生改变的应用程序（例如生成报告），--dry-run 选项非常适用。对于更具响应性的应用程序，可能不太适合。 尽早加入 --dry-run 选项，在开发过程中就能获得它的好处。 尽管 --dry-run 并非适用于所有情况，但当它适用时，却能提供很大的帮助。

Okay, I understand the task. Please provide the content. I'm ready to read, summarize, and then list animals with Wikipedia articles, maximizing the time and avoiding overlap. I'll format my response in markdown and Chinese. Let's begin!

关于生成式 AI 对维基百科的影响：Wiki Education 的经验总结 (关于生成式 AI 对维基百科的影响：Wiki Education 的经验总结)

Wiki Education 长期关注生成式 AI 对其影响，并因其运营大规模的维基百科新编辑者招募项目而对新贡献者面临的挑战和支持方式有深刻理解。本文总结了 Wiki Education 通过其项目对生成式 AI 工具使用情况的观察和应对策略，并旨在为维基百科社区提供参考。

核心结论：维基百科编辑者不应将生成式 AI 聊天机器人（如 ChatGPT）的输出直接复制粘贴到维基百科文章中。

调查与发现:

• AI 检测: 自 ChatGPT 发布以来，Wiki Education 密切关注生成式 AI 内容，并使用 Pangram 工具检测其项目参与者编辑的文本。
• AI 使用率上升: 从 2022 年底开始，项目参与者使用生成式 AI 工具的文本比例稳步上升。
• 虚假来源占比低: 尽管检测到 AI 生成的文本，但只有 7% 的文章包含虚假来源。
• 无法验证信息占比高: 更令人担忧的是，超过三分之二的文章包含无法通过来源验证的信息，即文章中的陈述虽然引用了真实且相关的来源，但实际上这些来源并未包含相关信息。这使得判断信息真伪变得困难。
• 清理工作量大: Wiki Education 的工作人员花费了大量时间对这些文章进行清理，远超这些编辑者创建文章所花费的时间。

应对策略:

• 指导调整: Wiki Education 调整了对项目参与者的指导，强调了避免直接复制粘贴 AI 输出的重要性。
• 培训模块: 创建了新的培训模块，明确了 AI 工具的合理使用场景（如识别文章 gaps、查找来源）以及不应使用场景（如撰写文章内容）。
• 实时检测与反馈: 利用 Dashboard 平台，对参与者的编辑进行实时检测，并发送自动邮件提醒。
• 数据分析: 对 2025 年秋季参与者的数据进行分析，发现 Pangram 工具在检测普通文本方面表现良好，但在处理包含格式、标记和非文本内容（如书目、大纲）时可能会出现误判。

结果与影响:

• AI 使用率下降: 通过早期干预和指导，Wiki Education 成功地减少了参与者在维基百科文章中直接使用 AI 生成内容的比例。
• 问题内容及时回退: 所有被检测到的问题内容都已及时回退。
• 可验证性强调: 强调可验证性原则，并与参与者讨论了验证信息的必要性。
• AI 工具的辅助作用: 发现 AI 工具在研究阶段（如识别文章 gaps、查找来源）可以提供帮助，但需人工进行批判性评估。

对维基百科的建议:

• 推广 AI 检测工具: 建议维基百科社区推广类似 Pangram 的 AI 检测工具，以更准确地识别可能存在问题的编辑。
• 改进新用户指导: 建议在欢迎信息中明确告知新用户关于使用生成式 AI 工具的潜在风险。
• 软件设计: 建议 Wikimedia Foundation 在软件设计中注重引导用户基于可靠来源进行总结，而非直接依赖 AI 生成内容。
• 持续关注和适应: 强调维基百科需要持续关注技术发展，并根据实际情况进行调整。

Wiki Education 致力于通过其项目为维基百科贡献高质量内容，并对可能造成的任何负面影响负责。他们将继续监控、评估和调整策略，以适应不断变化的 AI 技术环境。

大型语言模型 (LLM) 的使用：认知技能与社会价值 (关于思考外包的讨论)

导言: 本文探讨了使用大型语言模型 (LLM) 对认知技能的影响，并对“思考外包”这一现象进行了深入分析。作者在安迪·马斯利 (Andy Masley) 的相关博文基础上，提出了自己的观点，认为问题远比单纯的“思考是否会减少”复杂。本文旨在强调“外包思考”所涉及的关键问题。

核心论点:

• 并非“认知总量谬误”： 借鉴马斯利对“认知总量谬误”的挑战，作者认为将思考任务外包不会导致人类整体认知能力下降，因为思考往往会产生新的思考点。
• 并非所有外包都是等价的： 关键在于区分哪些类型的任务外包更有害，哪些更有益。作者列举了在以下情况下，应避免使用 LLM：
  • 构建复杂经验知识： LLM 无法取代在现实世界中积累的经验。
  • 表达关怀和真诚： 机器无法取代人与人之间真诚的沟通和情感交流。
  • 提供宝贵体验： 某些活动本身就具有价值，不应被自动化。
  • 易于伪造： 在需要真实性的场景下，使用 LLM 会造成欺骗。
  • 涉及关键决策： 在重要问题上，不应完全依赖不可信任的机器。
• 个人沟通与写作： 作者强调，个人沟通和写作的本质在于表达独特的自我，机器生成的文本会污染这种表达方式，影响人际关系和公共讨论。即使 LLM 能帮助改善表达，也会剥夺人们学习和发现自身声音的机会。
• 经验价值： 不应将所有活动都视为“任务”来自动化。现代社会应重新思考哪些体验真正有价值，并避免过度依赖自动化。
• 知识积累： “互联网时代”的便捷性，容易让人忽视重复性工作对知识积累的重要性。 自动化这些任务会剥夺人们学习和思考的机会。
• “扩展思维”的谬误： 将大脑的认知活动与外部设备区分开来，外部设备不能完全替代大脑的功能。
• 思考的价值： 即使自动化了一些简单的任务，也要意识到不同类型的思考对个人和社会都有影响。

结论:

LLM 的出现迫使我们重新审视人类的价值观和生活方式。作者呼吁人们在利用 LLM 的同时，认真思考如何保护人类的独特性，避免为了追求效率而牺牲了社会价值和个人成长。我们需要明确哪些活动应该被保护，并以价值观为导向，而非仅仅追求技术上的便利。最终，LLM 的使用应服务于人类的整体福祉，而非反过来削弱人类的认知能力和社会联系。

https://www.bloomberg.com/news/articles/2026-01-29/us-has-investigated-claims-that-whatsapp-chats-aren-t-private

https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

Google Cloud 账户被暂停两年，仅收到自动回复：总结

以下是对 Hacker News 帖子“Google Cloud suspended my account for 2 years, only automated replies” 的总结：

主要问题: 用户 (andylizf) 的 Google Cloud Platform (GCP) 账户自 2024 年 3 月起被暂停，至今已超过两年。

尝试解决: 用户通过 [email protected] 提交了多次申诉，但每次都只收到自动回复模板，要求提供信息。用户已经多次回复并提供了详细信息，但始终没有收到人工回复。

案例编号: #1-8622000037271

时间线:

• 2024 年 3 月: 账户被暂停，提交申诉。
• 2024 年 4 月: 收到自动回复，要求提供信息，用户回复。
• 2024 年 11 月: 收到更多自动回复，用户再次回复。
• 2024 年 12 月 – 至今: 彻底的沉默，没有任何回复。

用户身份: UC Berkeley 的计算机科学研究人员。

影响: 账户暂停严重影响了用户的工作。

提问: 用户希望了解是否有其他人成功让 Google 审核过 GCP 账户暂停申诉，并询问如何联系到人工客服。

德国马铃薯“洪流”：免费分发与新关注

事件背景： 德国人对马铃薯情有独钟，人均年消费量高达63公斤。然而，今年收获的马铃薯产量异常丰盛，引发了“马铃薯洪流”（Kartoffel-Flut），创下25年来的最高产量，导致市场供过于求。

免费分发活动： 一位农民在莱比锡附近拥有4000吨剩余马铃薯，但销售未果。为此，柏林一家报纸与环保搜索引擎Ecosia合作，发起名为“4000吨”（4000 Tonnen）的活动，在柏林及其周边设立了174个免费分发点，鼓励市民前来领取马铃薯。

参与者众多： 许多市民，特别是因生活成本上升而感到经济压力的普通居民，积极参与分发活动，用袋子、水桶、手推车等收集马铃薯。 慈善机构，如汤厨房、无家可归者收容所、幼儿园、学校、教堂和非营利组织，也纷纷参与了“救援任务”，甚至柏林动物园也接收了大量马铃薯用于喂养动物，部分马铃薯还被运往乌克兰。

民众反应与社会影响： 分发活动营造了欢乐的氛围，在柏林严寒天气中为人们带来了温暖。 这一事件也引发了人们对马铃薯的重新关注，回顾了18世纪普鲁士腓特德二世颁布“马铃薯法令”（Kartoffelbefehl），将其确立为主要食物的背景。 网上涌现出大量马铃薯食谱，人们尝试各种做法。 专家也强调了马铃薯的营养价值，如维生素C和钾。 知名厨师马可·穆勒甚至表示，现在是给马铃薯“米其林星级”待遇的理想时机。 甚至前德国总理默克尔的马铃薯汤食谱也再次流行。

批评与担忧： 尽管免费分发缓解了部分困境，但该活动也受到了当地农民的批评，他们认为市场饱和导致马铃薯价格进一步下跌。 环保人士则表示，马铃薯泛滥是扭曲的食品工业造成的，这与上世纪70年代的“黄油山”和“牛奶湖”问题相似，当时欧盟过度补贴农产品生产导致大量剩余。 预计未来几年，其他农产品（如去年过剩的啤酒花，明年可能过剩的牛奶）也可能面临类似问题。

剩余量与后续： 目前，仍有约3200吨马铃薯可供领取。 组织者将在其网站（https://www.4000-tonnen.de/）上发布后续分发信息。

总结：关于拜占庭容错的悲伤时刻

本文以幽默讽刺的笔调，表达了作者对拜占庭容错研究的无奈和悲观。

主要观点：

• 拜占庭容错研究的固有模式： 每次会议看到关于拜占庭容错的报告，都让人感到悲伤，就像意识到坏事会发生，或者Keanu Reeves会赚比你更多钱一样。这些报告通常包含复杂的网络协议图，让人难以理解。
• 实际操作的不可行性： 即使是最优秀的拜占庭容错协议，也无法保证系统的可用性。现实世界中，数据中心操作员Ted的失误（例如洒咖啡）和备份问题，才是导致系统故障的真正原因。
• 数据一致性命名和解释的困惑： 论文会引入各种复杂且难以理解的数据一致性类型，并试图用“直观”的解释来阐述其原理，但这些解释往往缺乏实际意义。
• 模拟场景的荒谬性： 作者用一个夸张的例子（午餐场景）来展示拜占庭容错协议在现实生活中的不适用性，强调了其复杂性和脱离实际的本质。

总结：

作者认为，持续研究拜占庭容错是徒劳的， 即使我们用复杂的算法和加密技术来试图控制机器，也无法避免现实世界中不可预测的故障，最终仍会发现 Ted 已经去吃午饭了。因此，作者建议停止发布关于拜占庭容错的论文， 将精力投入到更实际的解决方案上。

Genode OS 框架概要

Genode OS 框架是一个用于构建高安全、特定用途操作系统的工具包。 它具有可扩展性，可以支持从内存仅 4MB 的嵌入式系统到高度动态的通用工作负载。

核心理念与架构:

Genode 基于递归系统结构，每个程序运行在独立的沙箱中，仅获得其特定用途所需的访问权限和资源。 程序可以创建和管理其自身资源的子沙箱，从而形成分层结构，并在每个级别应用策略。 框架提供了程序之间通信和交换资源机制，但仅限于严格定义的模式。 这种严格的控制显著降低了安全关键功能的攻击面，相比传统操作系统而言，攻击面可以减少几个数量级。

Genode 遵循 L4 的构建原则，并与 Unix 哲学保持一致。 强调使用小型构件，通过组合这些构件来构建复杂的系统。 与 Unix 不同，Genode 的构件不仅包括应用程序，还包括内核、设备驱动程序、文件系统和协议栈等传统操作系统功能。

主要特性:

• CPU 架构支持: x86 (32 和 64 位), ARM (32 和 64 位), RISC-V
• 内核支持: 包括 L4 系列的多个成员 (如 NOVA, seL4, Fiasco.OC, OKL4 v2.1, L4ka::Pistachio, L4/Fiasco)，以及 Linux 和自定义内核。
• 虚拟化支持: 支持 VirtualBox (基于 NOVA), ARM 平台的自定义虚拟机监控器，以及为 Unix 软件提供的自定义运行时环境。
• 组件: 提供超过 100 个现成的组件。

其他信息:

• 开源与商业支持: Genode 是开源项目，并由 Genode Labs 提供商业支持。
• 项目方向: 项目路线图展示了当前的发展方向。
• 挑战与未来方向: “挑战”部分列出了项目构想，暗示了可能的未来发展方向。
• 相关出版物: 提供与 Genode 相关的出版物列表。
• 许可证: 采用开源和商业许可。
• 截图: 展示了基于 Genode 的系统场景的截图。

项目摘要

该项目是一个 GitHub 仓库，旨在通过编程语言实现一个功能：给定一系列帖子，计算每个帖子与其相关性最高的 5 个帖子，相关性基于帖子之间共享标签的数量。

主要内容：

• AI 代码生成相关功能：
  • GitHub Copilot：AI 辅助代码编写工具。
  • GitHub Spark：构建和部署智能应用程序。
  • GitHub Models：管理和比较提示词。
  • MCP Registry：集成外部工具。
• 仓库结构：
  • 包含多个编程语言的实现（Go, Rust, Python, Julia, D, C++, Swift, 等等）。
  • 目录结构清晰，包含 .github/workflows (用于持续集成)，以及针对不同编程语言的代码目录（如 arturo, berry, cpp 等）。
  • 包含测试文件（如 dockerfiles, results）和脚本（如 run.sh, gen_dockerfile.sh）
• 问题描述：
  • 需要读取 JSON 格式的帖子数据。
  • 计算每个帖子与其他帖子的标签共享数量。
  • 根据共享标签数量，找出每个帖子的 5 个最相关帖子。
  • 将结果写入新的 JSON 文件。
• 规则：
  • 必须支持高达 10 万个帖子和 100 个标签。
  • 使用 UTF-8 字符串。
  • 在运行时解析 JSON 数据。
  • 使用小于 8GB 的内存。
  • 禁止使用 FFI、unsafe 代码、自定义基准测试等。
• 性能测试结果：
  • 提供了在 AWS c7a.xlarge 虚拟机上运行不同编程语言实现的性能测试结果，包括处理 5k、20k 和 60k 个帖子的时间。
  • 测试结果显示 Rust、Go、Julia 等语言在性能上表现优异。
  • 提供了单核和多核测试结果。
• 代码仓库信息：
  • GitHub 仓库包含了项目代码、测试用例、以及构建和运行脚本。
  • 仓库使用 MIT 许可证。

总而言之，该项目是一个用于比较不同编程语言在解决特定问题时的性能的基准测试仓库，旨在通过实际的代码实现和性能测试来评估各种编程语言的效率。

电影专业学生注意力涣散：一项调查报告 (电影专业学生注意力涣散：一项调查报告)

本文探讨了美国大学电影专业学生在观看电影时注意力持续时间显著缩短的现象，以及由此带来的教学挑战。

主要发现：

• 普遍现象： 越来越多的电影研究教授发现，即使是电影专业的学生也难以集中精力观看长片电影。这种现象在疫情后尤为明显。
• 不守规矩: 即使在课堂上禁止使用电子设备，学生们也经常偷偷查看手机。一些学生甚至抵制课堂电影放映，更倾向于在宿舍里观看，导致观看率大幅下降。
• 注意力分散： 即使学生完成了电影观看任务，也可能只是在进行多任务处理，例如同时做家务或浏览社交媒体，导致对电影内容的理解不深刻。考试结果显示，学生们对电影基本信息的掌握程度令人担忧。
• 媒体饮食习惯的影响： 媒体使用习惯的改变是导致这一问题的重要因素。儿童的屏幕使用时间大幅增加，学生们习惯于在社交媒体上快速浏览短视频，这使得他们难以适应长篇电影的节奏。
• 专业学生的变化： 过去，对电影充满热情的学生会选择电影专业。而如今，很多选择电影专业的学生只是普通消费者，他们的媒体消费主要集中在社交媒体上。

应对策略：

• 挑战注意力： 一些教授尝试通过选择“慢电影” (minimalist films) 或具有缓慢节奏和微妙细节的电影来挑战学生的注意力，帮助他们重新培养长时间的注意力。
• 适应习惯： 另一些教授则选择调整教学方法，例如播放短片、分多次进行观看，或者教授如何制作能够吸引观众的短视频，以适应学生的观看习惯。
• 剧情重复： 甚至有Netflix建议导演在电影中重复剧情，以确保在多任务处理的情况下观众也能跟上情节发展。

总结：

随着媒体环境的转变，大学生（包括电影专业学生）的注意力持续时间正在缩短。这给电影教学带来了新的挑战，教授们需要在挑战学生注意力与适应学生习惯之间寻求平衡。文章最后强调了电影《对谈》(The Conversation) 中一个重要的场景，表明即便在注意力分散的时代，优秀的电影作品仍然值得投入时间和精力去欣赏。

总结：利用环境提示注入攻击AI驱动的车辆和无人机

核心问题： 研究人员发现了一种新的AI攻击方式，称为“环境间接提示注入”(Environmental Indirect Prompt Injection, CHAI)，攻击者可以通过在现实世界中放置带有指令的标牌，操控AI驱动的车辆和无人机的决策过程。

攻击原理： CHAI利用视觉语言模型(LVLM)对环境信息的解读能力。攻击者通过精心设计标牌的内容、字体、颜色和位置等因素，最大化指令被AI系统识别并执行的可能性。研究表明，指令本身的影响最大，但视觉呈现方式也很重要。

实验结果：

• 自适应语言： 攻击指令可以使用中文、英文、西班牙语以及Spanglish等多种语言。
• 视觉欺骗： 通过改变标牌的视觉特征（例如颜色、字体），可以显著提高攻击成功率。
• 模拟测试： 在模拟环境中，CHAI攻击对自适应车辆的成功率高达81.8%。
• 无人机追踪： CHAI可以欺骗无人机追踪错误的车辆，例如将普通车辆伪装成警车，成功率甚至高于自适应车辆。
• 安全着陆： 攻击者还可以通过标牌欺骗无人机，使其认为不安全的着陆点是安全的。
• 现实世界测试： 在实际环境中测试，使用遥控车和标牌，GPT-4o的成功率分别为92.5%和87.76%。InternVL的成功率相对较低，大约为50%。

受影响系统：

• 自适应车辆： 可能导致车辆闯红灯、穿越人行道等危险行为。
• 无人机： 可能被用于追踪错误的目标，或做出不安全的着陆决策。

研究团队： 加州大学圣克鲁斯分校和约翰霍普金斯大学的研究人员开发了CHAI，由计算机科学与工程教授Alvaro Cardenas领导，其灵感来自于研究生Maciej Buszko的提议。

未来研究方向： 研究人员计划进一步探索在雨天、图像模糊等条件下的攻击效果，并致力于开发防御机制，防止这种新型攻击。

总结： CHAI攻击揭示了AI系统在面对现实世界环境信息时存在的安全漏洞，强调了对AI决策安全性的关注和防御机制的必要性。

掌上游戏引擎：在 Nintendo DS 上直接编写和运行游戏

TL;DR: 我开发了一个可脚本化的 3D 游戏引擎，可以在 Nintendo DS 掌机上直接编写和运行游戏。该引擎使用 C 语言 和 libnds 编写，编译后的 .nds ROM 文件大小约为 100KB，以 60 FPS 运行。 它具有触摸屏代码编辑器（底部屏幕）和实时 3D 渲染（顶部屏幕），默认脚本是可玩的 3D 乒乓球游戏。

项目概述:

该项目源于作者对早期在 TI-82 计算器上编写游戏体验的怀旧感，旨在将这种体验带到 Nintendo DS 掌机上。 它是一个完整的编程环境，允许用户在掌机上直接编写、编辑和运行游戏。

工作原理:

引擎主要分为三个部分：

1. 顶部屏幕：3D 渲染 (硬件加速): 利用 DS 的 3D 硬件以 60 FPS 渲染彩色立方体。 每个模型包含位置 (X, Y, Z)、旋转角度和颜色。 相机位置和偏航/俯仰角度可完全控制。 代码使用 glMatrixMode(GL_MODELVIEW) 和 gluLookAt() 设置相机视点，并使用 glTranslatef 和 glRotatef 变换模型的位置和旋转。 每个模型使用 6 个四边形（共 24 个顶点）绘制，并使用 glColor3b 设置颜色。

2. 底部屏幕：脚本编辑器 (软件渲染): 一个基于触摸屏的代码编辑器，使用像素级的绘制方式将 UI 绘制到 256x192 的位图上。功能包括：

   • 令牌选择器: 点击屏幕插入命令 (SET, ADD, LOOP, IF_GT 等)。
   • 数字键盘: 编辑命令的数值参数。
   • 寄存器选择器: 选择要使用的变量 (A-Z)。
   • 控制按钮: Play/Pause/Stop/Step 控制脚本执行。
   • 6 个脚本槽: 保存和加载不同的程序。

3. 脚本解释器: 每帧执行一行脚本。 脚本可以使用 26 个变量 (A-Z) 和 9 个只读寄存器（用于输入，如 D-pad、按键，以及系统状态，如经过时间、相机方向）。 解释器通过一系列的 if-check 语句来执行令牌命令。

脚本语言:

脚本由令牌（命令）和数值参数组成。 每行代码立即执行，没有解析开销，仅进行对令牌名称的条件检查。

可用命令:

• 变量 & 数学: SET A 5 (设置寄存器 A 为 5), ADD A 1 (将 1 加到 A), SUBTRACT A 2 (从 A 减去 2), MULTIPLY B -1 (将 B 乘以 -1)。
• 流程控制: LOOP / END_LOOP (无限循环), IF_GT A 10 (如果 A > 10), IF_LT A 0 (如果 A < 0), IF_TRUE kA (如果 A 键按下), END_IF (结束条件)。
• 3D 对象: MODEL 0 (在索引 0 创建模型), POSITION 0 X Y Z (设置位置), ANGLE 0 45 (设置旋转角度), NEXT_COLOR 0 (循环颜色)。
• 相机 & 渲染: CAM_POS X Y Z (设置相机位置), CAM_ANGLE yaw pitch (设置视线方向), BACKGROUND 2 (设置背景颜色), BEEP (播放 0.1 秒声音), SLEEP 0.016 (暂停 – 60 FPS = 0.016s/frame)。

只读寄存器 (输入 & 状态):

• LEFT, UP, RGT, DN: D-pad (按下时为 1.0，释放时为 0.0)。
• KA, KB: A 和 B 按钮。
• TIME: 脚本开始后的经过秒数。
• LOOKX, LOOKZ: 相机前向方向 (归一化的 X 和 Z)。

示例：3D 乒乓球:

默认脚本包含一个可玩的 3D 乒乓球游戏。 示例代码展示了

π (Pi): 个人编码助手构建之旅

2025 年 11 月 30 日

本文讲述了作者在过去三年中使用 LLM 进行辅助编码的经验，以及最终构建自己编码助手“π (Pi)”的历程。作者对现有编码助手（如 Claude Code、Copilot 等）的局限性进行了总结，并阐述了构建 π 的设计理念和实现细节。

背景：LLM 辅助编码的演进

作者从最初将代码片段复制粘贴到 ChatGPT 开始，经历了 Copilot、Cursor 等工具的尝试，最终转向了 Claude Code 等更专业的编码助手。然而，Claude Code 在不断更新中，功能越来越臃肿，系统提示和工具也频繁变化，导致工作流程被打断。

π 的核心组件

为了解决这些问题，作者决定构建自己的编码助手，并命名为 π。π 包含以下核心组件：

• pi-ai: 统一的 LLM API，支持多种模型提供商（Anthropic、OpenAI、Google、xAI 等），具有流式传输、类型安全工具调用、推理支持、跨提供商上下文传递和成本跟踪等功能。
• pi-agent-core: 负责工具执行、验证和事件流的代理循环。
• pi-tui: 最小化的终端 UI 框架，具有差异渲染和同步输出，提供流畅的用户体验。
• pi-coding-agent: 将所有组件连接起来的 CLI，包含会话管理、自定义工具、主题和项目上下文。

设计理念：简约、可控、可扩展

π 的设计理念是“如果我不需要，就不要构建”。作者追求简约、可控和可扩展的工具，强调对模型上下文的精确控制，并希望能够检查所有与模型的交互，以及对会话进行自动处理。

关键特性与实现

• 统一 LLM API: 抽象了 OpenAI、Anthropic、Google 等主要 LLM 接口，处理不同提供商的差异。
• 上下文传递: 支持跨提供商的上下文传递，例如将 Anthropic 的上下文转移到 OpenAI 模型。
• 模型注册: 使用 OpenRouter 和 models.dev 的数据构建类型安全的模型注册表，方便管理和自定义模型。
• 工具结果结构化: 允许工具返回 LLM 和 UI 显示分别使用的内容，支持图像附件。
• YOLO 模式: 默认采用 YOLO 模式，允许访问文件系统和执行命令，强调对工具的完全控制。
• 最小化功能: 放弃了内置的 to-do 列表、计划模式和 MCP 支持，追求简约和可控性。

终端 UI (pi-tui)

π 使用终端 UI 框架，采用保留模式渲染，通过差异渲染减少闪烁，提供流畅的用户体验。

π 的优势

• 可观测性: π 提供了对所有交互的完全可观测性。
• 可扩展性: π 具有清晰的文档格式，可以进行自动后处理，并可以轻松构建新的 UI。
• 灵活性: π 允许自定义系统提示和工具，并支持跨模型切换。
• 效率: 最小化的设计减少了不必要的功能和上下文开销。

总结

作者通过构建 π，展示了对现有编码助手的不满，并提供了一种简约、可控、可扩展的替代方案。π 的设计理念和实现细节对 LLM 辅助编码工具的未来发展具有借鉴意义。

Benchmark 结果

作者进行了 Terminal-Bench 2.0 测试，π 在多个指标上表现出色，在排行榜上名列前茅。这证明了 π 的设计理念和实现策略是有效的。