2026-04-13

25 篇热帖

All elementary functions from a single binary operator

总结:基于单一操作符 EML 实现科学计算器功能

本文提出了一种全新的数学表示方法,通过一个单一的二元操作符 eml(x, y) = exp(x) - ln(y) 以及常数 1,可以生成科学计算器所需的全部标准函数和操作。

主要发现和贡献:

  • EML 操作符的通用性: 该操作符能够生成常数(如 e, π, i),算术运算(加、减、乘、除、指数),以及各种超越函数和代数函数(如 sin, cos, sqrt, log)。 例如,exp(x) = eml(x, 1)ln(x) = eml(1, eml(eml(1, x), 1))
  • 统一的结构: 所有表达式都可以表示为 EML 形式的二叉树,树的节点结构统一,形式为 S -> 1 | eml(S, S),这简化了表达和处理数学公式的语法。
  • 基于梯度的符号回归: 利用 EML 树作为可训练的电路,并使用标准优化器(如 Adam),可以从数值数据中精确地恢复闭合形式的初等函数。 在树深度不超过 4 的情况下,已经证明了其可行性。
  • 适用性: 该架构可以拟合任意数据,但在生成规律为初等函数时,有可能恢复出精确的公式。

技术细节:

  • 操作符定义: eml(x, y) = exp(x) - ln(y)
  • 语法: S -> 1 | eml(S, S)
  • 方法: 系统性地进行穷举搜索,并进行了构造性证明,以确认操作符的充分性。
  • 实现: 代码已发布在 Zenodo 上 (https://zenodo.org/records/19183008)。

研究领域:

  • 符号计算 (cs.SC)
  • 机器学习 (cs.LG)

版本信息:

  • v1 (2026年3月23日)
  • v2 (2026年4月4日)
Google removes "Doki Doki Literature Club" from Google Play

Serenity Forge 关于 DDLC 从 Google Play 商店移除的声明 – 摘要

Serenity Forge (@serenityforge.com) 发布了一份声明,内容是关于其作品 Doki Doki Literature Club! (DDLC) 从 Google Play 商店移除的情况。

关键信息:

  • 发布者: Serenity Forge(@serenityforge.com)
  • 主题: DDLC 从 Google Play 商店的移除。
  • 发布日期: 2026年4月9日。
  • 互动数据: 该声明获得了 3629 个点赞,73 条评论,以及 1358 次分享。

总结:

该声明仅是宣布 DDLC 已被从 Google Play 商店移除,并未提供移除的原因或后续计划。 该声明主要作为官方通知发布。

The peril of laziness lost

LLMs 与程序员的“懒惰”:软件设计的核心价值

本文探讨了在软件开发中,程序员“懒惰”这一看似负面的特质的重要性,并分析了大型语言模型 (LLMs) 对其影响。

核心观点:

  • 程序员的三大美德: Larry Wall 认为程序员的优秀设计源于“懒惰”、“不耐烦”和“自负”这三大美德。其中,懒惰驱动程序员追求简洁、高效的抽象,以减少未来的工作量。
  • “懒惰”的真谛: 真正的懒惰并非毫无行动,而是需要进行深入的思考和抽象设计,优化未来自我以及其他人的工作效率。 优秀的抽象能够让软件更容易编写和组合。
  • “虚假勤奋”的兴起: 随着软件开发的普及,出现了一种以“勤奋”为卖点的过度生产现象,即所谓的“brogrammer”文化,将“懒惰”的真正含义扭曲。
  • LLMs 的影响: LLMs 提升了生产力,加剧了“brogrammer”文化,一些开发者过度炫耀代码量,例如 Garry Tan 声称每天编写 37000 行代码。
  • LLMs 缺乏“懒惰”的特质: LLMs 不受时间或资源限制,不会主动优化,容易产生冗余和低质量的代码,导致系统变得更大更复杂。
  • 人类“懒惰”的重要性: 人类有限的时间迫使我们追求简洁的设计,避免浪费时间在处理笨拙系统的后果。 最佳工程设计总是源于约束,而时间限制是推动我们简化系统的关键因素。
  • LLMs 的正确使用: LLMs 是一种强大的工具,但不能取代程序员的“懒惰”。 应该利用 LLMs 处理繁琐的任务,例如技术债务,并提升工程质量,服务于程序员的“懒惰”目标,最终创造更简单、更强大的系统,惠及未来的开发者。

总结:

文章强调了在软件开发中,程序员的“懒惰”并非消极怠工,而是追求简洁、高效抽象的核心驱动力。 LLMs 的出现虽然提升了生产力,但也带来了新的问题,因为它们缺乏这种“懒惰”的特质。 因此,我们需要正确使用 LLMs,将其作为工具,服务于程序员的“懒惰”目标,从而创造出更好、更简洁的软件系统。

Apple has removed most of the towns and villages in Lebanon from Apple maps?

Apple 地图概要

Apple 地图是一款由苹果公司开发的地图应用程序,集成在 iOS、iPadOS 和 macOS 等苹果操作系统中。其主要功能是提供导航、地点搜索和位置信息服务。

主要特点:

  • 导航功能: Apple 地图提供驾车、步行、骑自行车和公共交通等多种方式的导航指引,包括实时路况信息、预计到达时间以及详细的转弯指示。
  • 地点搜索: 用户可以通过关键词搜索地点,例如餐厅、商店、加油站等。地图会显示相关地点的位置、评分、营业时间、照片和联系方式。
  • 位置信息: Apple 地图可以显示用户的当前位置,并提供周边地点的推荐。
  • Look Around 功能: 类似于 Google Street View,Look Around 功能提供 360 度街景视图,让用户可以预览目的地的周边环境。
  • 3D 地图显示: 在一些城市,Apple 地图提供 3D 地图显示,更直观地展示建筑和地形。
  • 交通信息: 实时交通信息,包括路况拥堵情况、事故信息等,帮助用户规划最佳路线。
  • 公共交通信息: 提供公共交通路线、时刻表和站点信息,方便用户规划公共交通出行。
  • 商务信息管理: Apple 地图提供“商务连接”平台,允许商家管理其在地图上的信息,例如地址、电话、营业时间、照片等,确保信息准确性。 访问 https://businessconnect.apple.com/?utm_source=maps.apple.com 可以进行管理。

总结:

Apple 地图是一款功能全面的地图应用程序,旨在为苹果用户提供准确、便捷的位置信息、导航和地点搜索服务。它通过不断更新和改进,力求提供最佳的用户体验。


Apple's accidental moat: How the "AI Loser" may end up winning

人工智能的商品化与苹果的机遇:总结

这篇文章探讨了人工智能领域正在发生的变化,以及苹果公司如何受益于这些变化。主要观点如下:

1. 人工智能的商品化:

  • 随着越来越多的公司竞相开发最佳模型,人工智能模型越来越普及,性能也越来越接近顶尖模型,甚至开源替代方案也在迅速提升。
  • 这意味着训练人工智能所需的成本正在下降,并且更小的硬件也能运行更强大的模型。

2. 苹果的策略与优势:

  • 与烧钱研发前沿模型的其他科技公司不同,苹果采取了更为谨慎的策略,积累了大量现金,拥有更大的灵活性。
  • 苹果并没有投入巨额资金建设人工智能基础设施,而是通过与谷歌合作,以相对较低的成本获取前沿模型的计算能力(Gemini协议)。
  • 苹果的优势在于其庞大的用户生态系统(25亿台活跃设备)以及积累了数年的用户数据(健康数据、照片、笔记、消息等),这些数据构成了强大的“上下文”。

3. 硬件与软件的协同:

  • 苹果的M系列和A系列芯片采用统一内存架构,将CPU、GPU和神经引擎集成到同一芯片上,共享内存池,从而大幅提升了数据传输速度和效率。
  • 这种架构非常适合运行大型语言模型(LLM),尤其是在结合像“LLM in a Flash”这样的技术时,可以在相对较小的内存空间内运行大规模模型。
  • 统一内存架构也使得苹果设备能够高效运行本地模型,无需依赖云端计算。

4. 苹果的未来战略:

  • 文章认为,苹果可能将成为一个人工智能平台,类似于App Store,让开发者在其平台上构建和部署人工智能应用。
  • 苹果可以通过MLX框架吸引开发者,并利用其庞大的用户生态系统和本地推理能力,建立起独特的竞争优势。
  • 苹果的隐私保护策略也可能成为其人工智能战略中的一个重要卖点,吸引那些担心数据安全的用户。

5. OpenAI的困境:

  • 文章批判了OpenAI的烧钱模式,指出其在Sora项目上的巨大成本和收入不成比例的问题,以及对基础设施的过度依赖,这使得其面临破产的风险。

**总而言之,**文章认为,人工智能的商品化为苹果带来了意想不到的机遇。通过谨慎的策略、强大的硬件/软件协同以及庞大的用户生态系统,苹果可能在人工智能领域占据有利地位,即使它没有在模型研发上投入巨资。 苹果的重点在于拥有“上下文”,而苹果恰好拥有海量的用户数据和设备,这使其在人工智能的未来中具有独特的优势。

DIY Soft Drinks

自制软饮料实验记录总结 (Summary of DIY Soft Drink Experiments)

本文记录了作者自2020年开始尝试制作软饮料的经历,主要围绕无糖无咖啡因的自制可乐展开,并扩展到橙汁和杏仁口味的饮料。

主要内容:

  • 可乐制作过程: 作者参考了_Open Cola_和_Cube Cola_等配方,通过实验逐步优化。核心步骤包括:
    • 调配香料乳化液: 使用精油(橙油、青柠油、柠檬油、肉豆蔻油、丁香油、芫荽油、薰衣草油),精确控制用量(例如:橙油0.75ml,青柠油0.7ml)。
    • 添加乳化剂: 使用阿拉伯树胶(2g),与水和香料混合,手持搅拌器混合至乳化,形成乳白色棕色液体。
    • 添加着色剂和酸味剂: 加入焦糖色素(40ml)、柠檬酸(5g)和水。
    • 使用甜味剂: 最初尝试使用糖精和环己糖,后来改为无水甜菊糖(sucralose),并不断调整用量以达到最佳甜度。
    • 稀释: 将浓缩可乐糖浆稀释至1:8的比例,最终得到可饮用的可乐。
  • 不同批次的可乐实验:
    • 第一批: 使用焦糖色素,使用糖精和环己糖作为甜味剂。
    • 第二批: 不使用焦糖色素,尝试无水甜菊糖,但甜度过高。
    • 第三批 (0.1.0): 减少无水甜菊糖用量,添加香草精和丁香油,作者称之为“Syntez-Cola”,认为其比可口可乐更美味。
  • 其他软饮料尝试:
    • 橙汁: 配方简单,由橙精油、甜味剂和食用色素构成,作者对其结果非常满意。
    • 杏仁汁: 使用杏仁油和柑橘类精油,调整比例以突出柑橘风味。
  • 后续改进: 作者将配方发布到GitHub仓库(https://github.com/blinry/soft-drink-recipes),并持续改进,例如调整杏仁汁的杏仁油用量,并尝试使用白砂糖替代无水甜菊糖。
  • 未来展望: 作者希望继续探索其他软饮料配方,例如DIY山间露和Fassbrause。

总结:

作者通过一系列实验,成功制作出多种自制软饮料,并分享了详细的制作过程和经验。文章强调了精确控制成分用量的重要性,以及不断尝试和调整配方的必要性。 配方已公开在GitHub上,方便其他爱好者参考和改进。

Show HN: boringBar – a taskbar-style dock replacement for macOS

boringBar 总结 (boringBar Summary)

boringBar 是一款 macOS 应用程序,旨在提升桌面工作效率,通过提供快速访问窗口、应用程序和桌面空间的功能,减少切换和寻找所需的窗口和应用的耗时。它运行在 macOS Sonoma (14) 或更高版本上。

核心功能 (Key Features):

  • 当前桌面显示 (Current Desktop Only): 只显示当前屏幕上的桌面窗口,保持专注。
  • 桌面切换器 (Desktop Switcher): 一键切换到其他桌面,并显示每个桌面上的窗口数量。
  • 应用启动器 (App Launcher): 提供可搜索的应用列表,支持全局快捷键快速启动。
  • 窗口缩略图预览 (Thumbnail Previews): 悬停在窗口芯片上可以预览窗口内容,方便快速选择。
  • 通知徽章 (Notification Badges): 在窗口芯片上显示 macOS 的未读通知徽章。
  • 注意力提示 (Attention Pulse): 当应用程序需要关注时,芯片会发出轻微的脉冲提示。
  • 滚动切换桌面 (Scroll to Switch Desktops): 通过滚动条上下滚动切换桌面。
  • 可调节的栏大小 (Adjustable Bar Size): 提供小、中、大三种尺寸选择。
  • 按应用分组窗口 (Group Windows by App): 将同一应用的多个窗口合并为单个芯片,并显示窗口数量。
  • 切换芯片标题显示 (Toggle Chip Titles): 隐藏应用名称,只显示图标和窗口数量。
  • 窗口或应用名称显示 (Window or App Names): 选择显示完整的窗口标题或仅显示应用名称。
  • 隐藏 Dock (Hide Dock): 在使用 boringBar 时隐藏 Dock,退出后恢复显示。
  • 在所有显示器上显示 (Show on All Displays): 在多显示器环境下同步显示栏,即使“显示器具有独立的桌面空间”设置已关闭。
  • 快速显示桌面快捷方式 (Quick Shortcut to Show Desktop): 右键点击栏选择“显示桌面”,或点击栏的右侧边缘显示桌面。
  • 固定应用到栏/应用菜单 (Pin Apps on Bar/App Menu): 在栏或应用菜单中固定应用。

许可与定价 (Licensing and Pricing):

  • 试用期 (Trial Period): 提供 14 天的免费试用,所有功能均已解锁。
  • 个人许可 (Personal Licenses):
    • 永久版 (Perpetual): 40 美元一次性购买,覆盖 2 台设备,包含 2 年的支持和更新。
    • 年度订阅 (Yearly): 从 7.99 美元/年开始,覆盖 1 台设备,最多可覆盖 5 台设备,每台设备额外 2 美元/年。
  • 商业许可 (Business Licenses): 按年订阅,从 6 用户起步,采用批量定价。
    • 价格范围:每用户/年从 1 美元到 3.49 美元不等,具体取决于用户数量。
  • 许可激活 (License Activation): 个人许可用户通过电子邮件接收激活密钥;商业许可用户需要在 Business License Management 页面添加团队成员,然后团队成员输入电子邮件地址并接收一次性验证码。

权限要求 (Permissions Required):

  • 辅助功能 (Accessibility): 用于观察和控制窗口、桌面和应用程序。
  • 屏幕录制 (Screen Recording): 仅用于获取窗口缩略图预览。

重要说明 (Important Notes):

  • boringBar 在运行时可以隐藏 Dock,但 Dock 仍然可以在 Mission Control 中看到。
  • 每个许可 seat 只能绑定到一个设备。
  • 年度个人和商业许可需要预先购买足够的 seat,seat 不能之后添加。
The economics of software teams: Why most engineering orgs are flying blind

软件团队的财务逻辑:LLM 时代的挑战与机遇 (Software Team Financial Logic: Challenges and Opportunities in the LLM Era)

这篇文章探讨了现代公司软件团队的财务逻辑,分析了团队成本、价值创造以及当前组织普遍缺乏财务透明度的问题,并探讨了 LLM 技术的出现对大型工程团队的影响。

主要观点:

  • 高昂的团队成本: 欧洲软件工程师的年成本约为 13 万欧元,一个八人团队的月成本约为 8.7 万欧元,每天约 4 千欧元。 许多工程师和管理者并不清楚这个数字,导致决策缺乏财务背景。
  • 价值衡量: 内部平台团队需要通过节省工程师的时间来证明其价值。一个八人平台团队需要每月为 100 名工程师节省 1340 小时,即平均每人每周 3 小时。 为了实现真正的财务可行性,平台需要创造 3-5 倍于团队成本的价值,即每月 26 万到 43.5 万欧元。
  • 客户导向团队: 客户导向团队的成本相同,但价值衡量指标不同。 例如,如果平均每月用户收入为 50 欧元,团队需要创造或保护 1740 个用户的价值才能实现收支平衡。
  • 传统指标的局限性: 常见的衡量指标,如代码提交速度、解决的工单数量或功能发布数量,并不能准确反映财务回报。 团队可能发布更多功能,但构建了错误的功能;用户参与度可能上升,但用户流失率也在加速。
  • 历史原因: 过去二十年,低利率、高风险偏好和 SaaS 模式的盛行,使得组织可以忽略团队的财务表现。 这种环境培养了一代缺乏财务意识的产品和工程领导者。
  • 大型代码库的风险: 过去,大型代码库和工程团队被视为资产和竞争优势。 然而,随着 LLM 技术的出现,构建软件的成本大幅降低,大型代码库的维护成本和协调成本也日益凸显,使得大型工程团队的价值受到质疑。
  • LLM 的影响: LLM 技术使得构建类似 Slack 核心功能的原型只需要 14 天的时间,这表明传统大型工程团队的规模和复杂性不再是可靠的竞争优势。
  • 未来趋势: 能够清晰衡量团队成本、价值和财务可行性的组织将获得竞争优势。 这需要建立财务数据流向决策者的基础设施,并培养持续询问财务问题的文化。

关键数据:

  • 工程师年成本: 13 万欧元
  • 八人团队月成本: 8.7 万欧元
  • 平台团队每月需节省的工程师时间: 1340 小时 (平均每人每周 3 小时)
  • 财务可行性月价值目标(3x): 26 万欧元
  • 财务可行性月价值目标(5x): 43.5 万欧元
  • 用户平均每月收入: 50 欧元 (用于客户导向团队价值衡量)

总结:

文章强调了在 LLM 时代,软件团队的财务逻辑变得更加重要。 组织需要建立财务透明度,清晰衡量团队的成本和价值,并调整决策流程,以确保团队的投入能够带来可观的财务回报。 忽视这些问题将导致组织在竞争中落后。

Viktor Orbán concedes defeat after 'painful' election result

匈牙利总理奥尔班被击败,政治格局发生巨变 (Hungary's Orbán Ousted, Political Landscape Shifts)

主要内容:

匈牙利在星期日举行了选举,结果出人意料,长期执政的维克托·奥尔班总理在执政16年后被击败。胜选者彼得·马加尔,一位前奥尔班忠实支持者,以亲欧洲的姿态,承诺重建匈牙利与欧盟和北约的关系。

关键细节:

  • 选举结果: 马加尔领导的“蒂萨”党获得超过53%的支持,击败了奥尔班领导的“为了匈牙利”党(37%)。预计蒂萨党将在议会中获得94个席位。
  • 奥尔班的反应: 奥尔班迅速承认败选,称其为“痛苦”的结果。
  • 马加尔的承诺: 马加尔承诺重建与欧盟和北约的关系,并强调选民为匈牙利书写了新的历史。
  • 国际影响: 选举结果对欧盟的政治动态将产生重大影响,此前奥尔班经常利用否决权阻碍欧盟决策。同时,这也将对全球右翼运动产生影响,奥尔班曾被视为右翼民族主义的典范。
  • 背景: 奥尔班长期以来是美国前总统特朗普和俄罗斯总统普京的盟友。他执政期间,采取了对少数群体和媒体的压制措施,并被指控将大量资金转移到与他结盟的商业精英的腰包。
  • 投票率: 此次选举投票率达到近80%,为匈牙利共产主义时期后最高的投票率。
  • 关键议题: 选举中,选民对匈牙利在乌克兰战争中的立场以及与俄罗斯的关系等议题表现出担忧。
  • 外部干预指控: 奥尔班指责乌克兰及欧盟盟友试图干预选举,而据报道,俄罗斯情报部门也试图影响选举结果。
  • 蒂萨党的背景: 蒂萨党是欧洲人民党成员,该党在欧盟的多个国家执政。

总结:

匈牙利总理奥尔班的意外败选标志着匈牙利政治的重大转折点,也对欧盟和全球右翼运动产生了深远影响。新当选的彼得·马加尔承诺重建与西方盟友的关系,并改变匈牙利国内的政治格局。

Building a SaaS in 2026 Using Only EU Infrastructure

2026 年构建 SaaS:完全欧洲基础设施可行吗?

本文探讨了在 2026 年无需使用 AWS、Azure 或 GCP 等大型美国云服务商,完全基于欧洲基础设施构建 SaaS 应用的可能性和实用性,并排除了 Stripe、Cloudflare 和 Google Analytics 等常用服务。结论是:完全可行,并且在许多情况下更具优势。

核心观点:

  • 欧洲 SaaS 生态系统成熟: 如今,SaaS 堆栈的每个核心层都至少有一个可行的欧洲替代方案,一些已经成熟且经过验证。
  • 推荐的欧洲服务商:
    • 计算与托管:
      • Hetzner: 以其极具竞争力的价格/性能著称,适合熟悉 Linux 的团队。主要缺点是需要更多手动基础设施管理。数据中心位于德国和芬兰。
      • Scaleway: 提供托管服务,更接近 AWS 的体验,包括 Kubernetes、数据库、对象存储、无服务器函数和 GPU 实例。数据中心位于巴黎、阿姆斯特丹和华沙。
    • 支付与结算: Mollie 与 Stripe 类似,API 清晰,文档完善,支持欧洲主流支付方式 (iDEAL、Bancontact、SEPA、Klarna、信用卡)。
    • CDN: Bunny.net 具有全球节点、边缘存储、图像优化和视频交付能力,价格远低于 Cloudflare 的付费方案。
    • 分析: 推荐 Plausible (注重隐私,无 Cookie、GDPR 合规) 或 Simple Analytics (免费计划,适合初创公司)。
    • 事务邮件: AhasendLettermintMailerLite 都提供免费层级,适用于密码重置、欢迎邮件等事务邮件。
  • 实用性优势:
    • 成本效益: 在许多情况下,欧洲基础设施的成本与美国方案相当甚至更低。Hetzner 的定价远低于 AWS EC2。
    • 合规性: 简化 GDPR 合规,避免分析追踪带来的 Cookie 同意问题。
    • 本地化支持: 支持欧洲支付方式,并能获得时区一致的支持团队。
    • 开放标准: 欧洲供应商更倾向于采用开放标准,降低锁定风险。
    • 灵活性: 堆栈的各个层可以独立更换,无需重构整个应用。
  • 局限性:
    • 并非所有 AWS 细分服务都有欧洲替代品。需要自托管开源方案或接受某些功能缺失。

总结:

在 2026 年,构建基于欧洲基础设施的 SaaS 应用不再是理想主义的追求,而是一个实际可行的选择。 凭借成熟的欧洲服务商生态系统,企业可以在享受成本效益、简化合规、提升本地化支持的同时,构建出稳定可靠的 SaaS 产品。 即使流量达到百万级别,欧洲云的限制也不会成为主要问题。

The Closing of the Frontier

总结:人工智能前沿模型的封闭及其对社会的影响 (Summary: The Closure of Frontier AI Models and its Societal Impact)

这篇文章表达了作者对人工智能领域出现的一种趋势的担忧:即最先进的模型(如Anthropic的Mythos)正逐渐被少数大型科技公司和企业独占,这与互联网早期开放、自由的特性形成了鲜明对比。作者认为这种趋势正在关闭一个重要的“前沿”,类似于美国历史上的西部拓荒时代结束。

核心观点:

  • 前沿的关闭: 类似于美国西部拓荒时代的结束,互联网上的开放机会正在减少,最先进的人工智能模型正在被少数公司垄断。
  • 经济不平等加剧: Rudolf Laine 和 George Hotz 分别指出,拥有资本优势者在人工智能时代将获得永久性的优势,并将其比喻为“新封建主义”,动物与人类的关系。
  • 安全风险: 将前沿模型仅限于少数企业,可能导致安全漏洞被利用的风险增加,尤其是在这些企业本身存在安全问题的情况下。
  • 创新受阻: 限制模型的使用会扼杀创新,并阻碍对模型进行公开测试和改进的机会。
  • 安全研究受限: 缺乏对前沿模型的开放访问,限制了AI安全研究的开展,特别是那些需要白盒访问的研究。
  • 缺乏透明度和问责制: Anthropic作为模型制造商、监管者和上诉机构,缺乏透明度和外部监督,这与民主原则相悖。
  • 历史类比: 作者暗示,这种权力集中可能重复历史上对弱势群体的剥削模式,并利用其成果进行慈善捐赠以掩盖不平等。

主要论据:

  • 开放的重要性: 开放访问能够促进创新、改进安全性和确保更广泛的社会参与。
  • 安全并非零和游戏: AI安全是一个持续的军备竞赛,开放访问可以促进更广泛的安全研究和改进。
  • 需要政府般的监管: 拥有政府级别人工智能能力的机构应该承担起相应的责任,建立透明的访问标准和申诉机制。

可能的未来:

作者虽然担忧,但也表达了希望,认为硬件成本的降低和开源模型的进步可能最终打破这种垄断局面,使人工智能更加普及。文章结尾呼吁不要像旧金山砍伐树木一样扼杀互联网的开放性。

核心关键词: 人工智能, 前沿模型, 开放性, 垄断, 安全, 创新, 民主, 经济不平等, 新封建主义。

A perfectable programming language

总结:为什么Lean是最好的编程语言

本文探讨了编程语言的进化趋势,并重点介绍了Lean语言的独特优势,认为它是“可完善的”最佳编程语言。

主要观点:

  • 编程语言的进化: 几乎所有编程语言最终都会发展出对自身代码进行推理的能力。最初的PHP和Python通过类型标注来引入类型系统,而Rust和Go则强调在编译时进行计算。
  • 依赖类型与定理证明: 依赖类型是实现编程语言自身可推理的关键。而拥有定理证明基础设施是使依赖语言成为定理证明器的必要条件。
  • Lean的优势: Lean语言在依赖类型和定理证明基础设施方面表现突出,使得它能够写下关于Lean自身性质的程序,并将其视为“进展”。
  • 元编程: Lean提供了无缝的元编程能力,允许用户创建自定义语法和API,并轻松地交换语法解释。作者通过Tic-Tac-Toe的例子展示了Lean自定义语法的强大功能。
  • 速度: Lean虽然目前速度不是最快的,但由于能够证明代码等价性,它具有巨大的优化潜力。作者提到Lean的开发者正在积极优化性能,并牺牲一些向后兼容性。
  • 社区: Lean是目前唯一在定理证明和编程能力方面获得显著增长的语言。Coq、Idris和Agda等竞争对手的社区未能达到关键规模。F*和Eliza张的挑战也推动了作者对Lean的深入研究。

关键技术细节:

  • 依赖类型: 允许代码的类型依赖于其他类型的值,从而实现更精确的类型检查和代码推理。
  • 定理证明基础设施: 提供了一套工具和API,用于证明代码的正确性。
  • 元编程: 允许在编译时修改和生成代码,从而实现更灵活和强大的编程能力。
  • 自定义语法: Lean允许开发者定义自己的语法,使得代码更易于阅读和理解。
  • #eval: 允许在代码中直接计算表达式的结果,方便调试和测试。

总结:

作者认为Lean语言的独特优势在于其“可完善性”,它不仅是一个编程语言,更是一个定理证明器,能够进行元编程和自定义语法,并具有巨大的优化潜力。随着社区的不断发展,Lean有望成为未来编程领域的重要力量。

European AI. A playbook to own it

欧洲人工智能发展蓝皮书概要 (Summary of Europe's AI Playbook)

这份蓝皮书由法国人工智能公司 Mistral AI 撰写,旨在为欧洲打造一个强大、自主的人工智能生态系统提供行动框架,于2026年4月7日发布。蓝皮书强调欧洲在人工智能发展方面具有独特的优势,包括世界一流的学术生态、对人性化技术的承诺以及拥有超过4.5亿人口的单一市场。蓝皮书的核心论点是,欧洲不再需要讨论是否有能力竞争,而是需要讨论如何将这些优势转化为一个连成一体、自给自足的人工智能强国。

核心原则与目标:

蓝皮书提出了三个核心原则:

  • 行动胜于理论 (Action over theory): 所有建议,从签证改革到采购通道,都旨在可实施、可衡量、可扩展。
  • 复杂性中的统一 (Unity in complexity): 拥抱欧盟结构的复杂性,同时提供解决方案以协调市场、减少冗余并加速决策。
  • 速度并非选项 (Speed is not an option): 为人才、资本和合规提供快速通道,确保欧洲创新者不被落后。

蓝皮书的目标是确保人工智能不仅在欧洲开发,而且为欧洲服务,并符合欧洲的价值观和优先事项。

四个关键领域与具体措施:

蓝皮书将发展人工智能生态系统划分为四个关键领域,并提出了具体的措施:

I. 吸引与留住人才 (Attract and Retain Talent): 蓝皮书强调需要吸引和留住顶尖的人工智能人才。

II. 释放单一市场潜力 (Scale: Unleash the Full Potential of the Single Market): 蓝皮书旨在消除行政障碍,简化法规,促进欧洲人工智能企业在单一市场的扩张。具体措施包括:

  • 简化欧盟数字监管框架: 澄清不一致,消除重叠,减少合规工作。
  • 创建欧盟人工智能合规门户: 提供人工智能开发者生成标准化报告、获取实时指导和自动化合规检查的平台。
  • 统一数字企业行为识别系统: 消除跨境公司运营的法律不确定性。
  • 欧盟企业银行开户证: 为欧盟企业提供便捷的银行账户和 KYC 认证。
  • 欧盟员工持股计划 (ESOP) 对齐框架: 协调员工持股计划的税务事件。
  • SIU 通行证和枢纽: 允许公司在欧盟成员国筹集资金,无需重新提交文件。
  • 欧盟单一访问点 (ESAP) 扩展: 将企业备案和投资者搜索整合到单一平台。
  • 创建人工智能 EuVECA 标签: 对投资于人工智能和深度科技公司的基金进行认证。
  • 利用审慎框架支持欧盟人工智能创新议程: 确保审慎和投资框架支持对人工智能等战略领域的长期股权投资。

III. 在实体经济中推广欧洲人工智能 (Adopt European AI across the Real Economy): 蓝皮书建议欧盟机构率先采用欧洲人工智能解决方案,并通过公共采购来推动人工智能在实体经济中的应用。具体措施包括:

  • 欧盟机构以身作则,在公共行政中采用人工智能: 通过人工智能提高公共行政效率。
  • 创建完全集成的欧盟数字采购网关: 确保中小企业和创新公司能够公平地参与公共合同。
  • 在公共采购中对战略领域实行有针对性的欧洲偏好机制: 通过公共支出加强技术自主性。
  • 在公共采购中整合环境标准: 要求人工智能供应商提供生命周期评估。

IV. 欧洲本地基础设施与数据 (Power Europe with Local Infrastructure and Data): 蓝皮书强调需要建立欧洲本地的人工智能基础设施和数据资源。具体措施包括:

  • 在公共采购中加入欧洲人工智能标准,用于计算基础设施: 优先支持欧洲人工智能基础设施项目。
  • 确保欧洲前沿人工智能模型具有竞争力的训练: 建立公平的法律框架,支持欧洲人工智能模型的训练。
  • 欧洲数据共享倡议 (EDCI): 建立一个数据共享框架,公司贡献匿名化的、符合 FAIR 原则的数据,以换取经济和战略利益。
  • 创建人工智能训练和文化遗产保护的集中式档案: 建立一个公共领域作品的集中式多语言存储库,用于人工智能模型训练和文化遗产保护。