费马大定理的形式化证明总结

Anthropic 的研究人员宣布，利用 Claude AI 成功完成了费马大定理（Fermat's Last Theorem, FLT）的首个完整、经计算机校验的形式化证明。该过程在短短 11 天内基本自主完成，使用的是 Lean 编程语言。

核心成就与规模

• 自动化程度：Claude 在 11 天内自主完成了从定义概念到证明最终定理的全过程。
• 工作量：编写了 1300 万行 Lean 代码，并证明了 29,500 个中间定理。
• 验证结果：该证明通过了 Lean 的逻辑校验，仅使用了 Lean 的三个标准公理，其定理陈述与 Mathlib 库中的陈述一致。

技术实现：Prove2Me 平台

由于自动形式化如此复杂的证明极具挑战性，研究团队采用了名为 Prove2Me 的开源协作平台，通过多智能体（Multi-agent）系统协作完成。该平台解决了智能体在处理大规模任务时的协作与记忆问题，其核心功能包括：

1. 维护有向无环图 (DAG)：通过 DAG 管理定理陈述，帮助智能体决定下一步的证明方向，有效缓解了由于任务复杂导致的记忆退化问题。
2. 优化编译性能：将定理陈述与具体证明分离到不同文件中，从而加快了 Lean 的编译速度并降低了资源消耗。
3. 实现搜索与重用：通过为每个定理提供自然语言描述，简化了证明路径并便于智能体检索已有的成果。

研究意义与未来影响

这项工作标志着 AI 在数学领域从“生成数学结果”向“验证数学结果”的重大跨越：

• 验证数学证明的可靠性：传统的数学证明（如 Wiles 在 1995 年的证明）验证过程极其耗时，可能需要数月甚至数年。形式化证明可以通过计算机算法实现绝对的逻辑校验。
• 减轻学术审稿负担：随着 AI 生成数学成果的日益增多，自动形式化技术可以帮助研究人员快速评估新成果，并识别现有数学文献中的潜在错误。
• 建立 AI 数学成果的信任机制：形式化证明为人类研究者提供了一种可靠的手段，用于验证和信任由 AI 辅助或生成的数学结论。
• 辅助科学研究：研究表明，编写 Lean 代码的过程也能帮助 AI 更好地进行自我检查，类似于通过数值模拟来验证假设。

通过这项技术，数学界有望实现更高效、更严谨的知识构建过程，使形式化证明成为现代数学研究中不可或缺的工具。

shitter - Alternative Twitter front-end. Fork of zedeus/nitter on GitHub.

成人片制作商将 BitTorrent 盗版案关联至 Meta 高管

成人片制作商 Strike 3 Holdings 正试图将其针对 Meta 的巨额版权诉讼与一起常规的“约翰·多”（John Doe，指代匿名被告）盗版诉讼联系起来。

事件背景

Strike 3 Holdings 一直通过向法院提起大量“约翰·多”诉讼，利用传票获取互联网服务提供商（ISP）的客户信息，从而识别并向匿名 BitTorrent 用户索赔。与此同时，该公司正与 Counterlife Media 共同对 Meta 发起诉讼，指控 Meta 通过 BitTorrent 下载了数千部成人电影用于训练 AI 模型，该案涉及金额可能高达 4.46 亿美元。

关键发现

在最近的一起针对 AT&T 住宅 IP 地址的“约翰·多”案件中，Strike 3 通过调查发现，该 IP 地址的订阅者是 Meta Reality Labs（负责开发 Quest VR 头显的部门）的一名高管。

Strike 3 提出以下论点，认为该高管的行为与 Meta 的业务活动有关：

• 下载时间点异常：Strike 3 声称，在 2025 年 3 月向 Meta 发出关于其公司 IP 地址存在侵权活动的警告后，紧接着该高管的住宅 IP 地址便记录到了盗版行为。Strike 3 推测 Meta 可能试图将侵权活动转移到隐藏的住宅 IP 以规避检测。
• 下载规模与内容：该用户记录到的下载量接近 20,000 个文件，其中包括大量 VR 成人影片。Strike 3 指出，如此高频且特定类型的下载（包括大量多语言资源包、软件和书籍）更符合 AI 训练或研究的数据获取模式，而非普通个人的日常行为。

法律诉求与 Meta 的辩护

Strike 3 的诉求： Strike 3 请求法院将此“约翰·多”案件与针对 Meta 的大规模诉讼合并审理。如果请求获准，Strike 3 计划修改诉状，直接起诉 Meta，主张该高管的行为应由 Meta 承担共同责任，并强制 Meta 提供相关的 torrent 下载记录作为证据。

Meta 的回应： Meta 在回应中拒绝了将案件关联的提议，理由如下：

• 缺乏关联性：Meta 认为 Strike 3 仅仅基于 IP 地址就假设下载行为是为公司服务的，这属于缺乏证据的臆测。
• 个人行为辩护：Meta 强调，IP 地址并不等同于识别侵权者的意图。公司此前曾辩称，即便员工存在下载行为，也通常属于个人行为，与工作无关。
• 逻辑矛盾：Meta 指出 Strike 3 的时间线论证存在矛盾，认为原告关于“离岸活动”开始时间的描述与其最新的“转移下载地址”理论不符。

目前，该高管的身份仍处于受保护的密封状态，法院尚未就是否合并案件作出最终裁决。

漏洞摘要

核心内容 所有版本的 Chromium 浏览器均存在一个正在被积极利用的沙箱远程代码执行 (RCE) 漏洞。

Mullvad 停止运营公共加密 DNS 服务公告

背景与原因

Mullvad 自 2022 年起提供公共加密 DNS (DoH) 服务，主要用途包括：

• 为未使用 Mullvad VPN 的 Mullvad Browser 用户提供保护，防止 ISP 查看访问域名。
• 作为免费的公共服务，为大众提供保护 DNS 查询的隐私功能。

由于在连接 Mullvad VPN 时，流量已通过内部 DNS 进行加密处理，因此公共 DoH 服务在 VPN 环境下是冗余的。此外，运行隐私导向的公共 DNS 服务是一项高度专业化的工作。为了避免重复建设，Mullvad 决定停止自主运营该服务，转而通过资金支持行业领先的 Quad9 基金会，以更高效地提供公共服务。

迁移指南

所有手动配置了 Mullvad DoH 服务器的用户，请务必在 2026 年 11 月 2 日 之前完成向 Quad9 的迁移。

针对不同平台的操作建议：

• Mullvad Browser 用户：

  • 若您使用的是默认 DoH 设置或内置的广告拦截设置，系统将自动迁移至 Quad9。
  • 若您手动配置了自定义的 DoH 变体（如 base、extended、family 等），系统不会自动更改，您需要手动将设置恢复为默认值或自行修改。

• iOS 与 macOS 用户：

  • 现有的 Mullvad DoH 配置文件在服务停止后将失效。用户必须手动替换为 Quad9 提供的 iOS 或 macOS 配置文件。

美国政府腐败感知度创20年新高

核心数据

根据盖洛普（Gallup）的最新调查，89%的美国成年人认为美国政府腐败现象普遍存在。这一比例较去年上升了10个百分点，创下了过去20年来的最高纪录。此前在2010年至2025年期间，这一数值一直维持在72%至79%之间。

党派立场分析

不同党派对腐败的看法呈现出不同的变化趋势：

• 民主党人：感知度上升最为剧烈。从2024年拜登任期内的57%，上升到2025年（特朗普第二任期首年）的76%，并在今年达到了91%。民主党的看法似乎与当前政权的更替紧密相关。
• 共和党人：观点相对稳定。近两年来，约八成的共和党人认为腐败普遍存在，与2024年的87%相比变化不大。这表明共和党人的看法可能基于更深层的观点，较少受执政党更替的影响。
• 独立人士：90%的独立人士认为腐败普遍存在，其立场与民主党人更为接近。

国际对比

美国在政府腐败感知方面正逐渐与发达经济体脱节。

• OECD（经合组织）对比：OECD成员国的腐败感知中位数已从2009年的69%下降至2022年以来的60%以下（2025年为59%）。美国已成为OECD国家中腐败感知度最高的国家，且与OECD中位数的差距正在扩大。
• 全球对比：在盖洛普每年调查的132个国家中，自2023年以来，仅有黎巴嫩（2024年）、秘鲁（2025年）、加纳和尼日利亚（2024年）的腐败感知得分高于美国的89%。

政府与企业腐败的差距

美国人对企业腐败的感知度也上升至71%，但政府腐败（89%）与企业腐败（71%）之间的差距扩大到了18个百分点。这是美国在这一趋势中观察到的最大差距，显示出民众对政府腐败的担忧远超企业。

结论

美国政府腐败感知度的高企，很大程度上源于两党在这一问题上观点的趋同。尽管民主党与共和党对腐败原因的理解不同，但两党对腐败普遍性的担忧正趋于一致，这种跨党派的共识共同推高了全美的数据。

AI 驱动的事故响应：效率提升与工程师技能退化的矛盾

核心观点

随着 AI 在事故响应（Incident Response）领域的广泛应用，所谓的“AI SRE”能够自动完成检查告警、建立假设、查询遥测数据及实施修复等任务。虽然这显著提升了处理常规事故的效率，但也带来了一个严重的风险：工程师正在逐渐失去对系统的直觉和掌控力。

主要挑战

• 自动化的讽刺（The Ironies of Automation）： 引用 Lisanne Bainbridge 的理论，自动化减少了人类处理常规工作的机会，但当面对 AI 无法解决的复杂、罕见或异常情况时，人类仍需承担最终责任。这意味着，自动化程度越高，人类在应对突发危机时所需的技能和培训反而应该越多，但现实中他们却因缺乏实践而变得更加脆弱。

• 理解债（Comprehension Debt）： 随着大型语言模型（LLM）承担了越来越多的工作，工程团队面临着“理解债”的风险，即系统运行逻辑与工程师对其掌握程度之间的差距不断扩大。

• 效率的悖论： 作者预测，虽然 AI 会降低大多数常规事故的平均修复时间（MTTR），但对于复杂的、未见过的严重事故，由于响应人员因缺乏实践而难以进行调查，其解决时间反而会大幅飙升。

借鉴与应对措施

• 航空业的启示： 飞行员虽然依赖高度自动化的驾驶系统，但必须定期通过模拟器练习极低概率发生的紧急情况（如引擎失效）。这种通过模拟器进行的定期复习，确保了他们在自动化失效时能够迅速、正确地做出反应。

• 实战模拟与训练： 为了防止技能退化，工程团队应采取以下措施：

  • 模拟真实场景：通过模拟真实的系统宕机、协调利益相关者（如 CEO 或客服）等手段，锻炼工程师在压力下的决策、沟通和组织能力。
  • 将 AI 作为培训工具：利用 AI 解释其诊断步骤、考察的信号及背后的证据，将其作为辅助学习的教练。
  • 强调“在做中学”：实践经验是不可替代的。工程师应定期与系统进行深度交互，处理不熟悉的故障，并通过故障注入（Chaos Engineering）和桌面演练（Tabletop exercises）来保持应对高严重性事件的能力。

OpenTrailPaper：开源电子墨水屏自行车码表项目

项目简介

OpenTrailPaper 是一个专为 LilyGO T5S3 4.7" E-Paper PRO 开发的开源固件项目。它旨在通过 DIY 硬件构建一个功能齐全的自行车码表，支持离线地图导航、骑行数据记录以及蓝牙传感器连接。

核心功能

设备端（独立运行能力）

在加载地图和路线后，码表可以脱离手机独立工作，无需任何账户或订阅：

• 导航与追踪：提供 GPS 追踪、速度/距离显示、实时地图以及基于加载路线的转向提示。
• 数据记录：将每场骑行记录为 .fit 文件并存储在 SD 卡中。
• 传感器连接：通过蓝牙连接心率、功率和踏频传感器。
• 训练模式：支持运行 .erg 或 .mrc 格式的结构化训练计划。

iOS 移动应用（设置与数据管理）

App 主要用于设备的前期准备和骑行后的数据同步：

• 路线规划：搜索目的地、预览路线，并将 GPX 文件发送至设备。
• 地图构建：构建并传输用于新区域的离线地图。
• 数据回顾：将骑行记录从设备导出，并在手机上查看地图、距离、功率、心率及预估爬升等数据。
• 系统维护：设置 FTP、时区、单位和背光亮度，并可通过蓝牙更新固件。

硬件规格与权衡

目前该项目主要针对 LilyGO T5S3 开发板，其特性如下：

优势

• 显示性能：配备 4.7 英寸电子墨水屏，在阳光直射下具有极佳的可读性。
• 存储扩展：设有 SD 卡槽，用于存放离线地图、路线、骑行文件和日志。
• 高度集成：单板集成了 GPS、电容式触摸屏、前灯、电池和 USB-C 接口。
• 连接性：支持蓝牙 5.0。

局限性（开发阶段特性）

• 传感器缺失：缺乏气压计（爬升高度为基于地图数据的估算值）和磁力计（静止时无法进行地图定向）。
• 定位性能：采用基础 GPS 模块，在树荫或建筑物密集区域的定位速度和稳定性有限。
• 续航能力：实测使用时长约为 7.4 至 8 小时（关闭前灯时）。
• 交互与防护：物理按键操作感较弱，主要依赖触摸操作；硬件本身不具备防水能力，需自行加装外壳。

项目状态

OpenTrailPaper 目前是一个开发阶段的项目，而非成熟的零售产品。项目方欢迎社区贡献代码或建议更优的硬件方案（例如集成气压计、多频 GPS、磁力计及防水外壳的硬件平台）。

荷兰央行因地缘政治动荡转移黄金储备

核心行动

荷兰央行（De Nederlandsche Bank, DNB）已将其存储在美国和加拿大的部分黄金储备转移至伦敦英格兰银行。在今年3月至8月期间，DNB 从美、加两地总计313吨的黄金储备中，移出了86吨。目前，荷兰的总黄金储备为612.4吨，价值约722亿欧元（1167亿美元）。

转移目的与策略

• 增强危机应对能力：DNB 表示，此举旨在应对日益加剧的“地缘政治动荡”，确保黄金储备在危机发生时能更迅速、直接地投入使用。
• 提高流动性：DNB 指出，英格兰银行存储的黄金符合现代国际贸易标准，是全球流动性最强的黄金，而存储在纽约和渥太华的黄金在紧急情况下利用效率较低。
• 风险管理与成本效益：为了降低风险并兼顾成本，DNB 采用了两种操作模式：
  1. 买卖交易：将纽约持有的59吨黄金卖出，随后在伦敦买入同等数量并存入英格兰银行。
  2. 实物运输：将美、加持有的27吨黄金实物运往荷兰泽斯特（Zeist），随后再转运至英国。

地缘政治背景

专家分析认为，此次转移反映了欧洲对美国政策走向及其对传统盟友态度的担忧：

• 对美政策的疑虑：专家指出，特朗普政府对盟友（如加拿大、欧洲国家）表现出的强硬姿态增加了相关国家的风险感知。存在一种潜在风险，即美国政府可能将存储在美国的盟友黄金作为政治筹码或武器。
• 经济独立性：随着美国在国际事务中表现出更强的干预性，欧洲国家正试图通过减少对外国机构（如美国联邦储备局）的依赖，来增强自身的经济独立性和韧性。

全球趋势

荷兰的举措并非孤例，近年来全球范围内出现了明显的“黄金回流”或“储备转移”趋势：

• 法国：法国银行在2025年出售了部分在纽约的储备，并在欧洲内部完成了替换。
• 德国：德国央行在2013年至2017年间曾大规模将黄金从巴黎和纽约回流至德国。
• 其他国家：奥地利、意大利、土耳其等国也表现出将海外黄金储备迁回国内或转移至更安全地点的意向。

OpenAI、Anthropic 与 xAI 遭遇同步服务中断

本周四上午，多家领先的人工智能公司（OpenAI、Anthropic 和 xAI）均经历了罕见的服务中断，导致其旗下的 AI 聊天机器人出现停机现象。

各公司故障详情：

• xAI (Grok)： 其母公司 SpaceX 表示，Grok 的服务中断源于其位于孟菲斯（Memphis）的计算中心发生故障。
• OpenAI (ChatGPT & Codex)： OpenAI 发言人指出，由于太平洋时间上午 7:43 左右出现路由错误（routing error），导致部分用户无法使用 ChatGPT 和 Codex。故障在上午 8:17 左右通过实施解决方案得到解决，目前仍在持续监测。
• Anthropic (Claude)： 公司报告了部分服务中断，主要涉及 Claude Mythos 5.1、Claude Fable 5.1 和 Claude Opus 5 等模型的请求错误。在识别原因并部署修复后，问题于太平洋时间上午 9:16 左右解决。
• Google (Gemini)： 当天上午也有零星报告称 Google Gemini 可能出现故障，但 Google 官方并未证实此类事件，其服务状态仪表板也未记录相关异常。

背景与分析：

通常情况下，同一行业内多家公司在同一时间发生故障，往往指向共享的第三方服务提供商（如云服务商或内容分发网络）出现了问题。然而，主要的互联网基础设施供应商（包括 Cloudflare、Amazon Web Services 和 Microsoft Azure）在当天均未报告任何故障。

值得注意的是，Anthropic 与 xAI 在今年 5 月曾宣布与 SpaceX 达成“计算合作伙伴关系”。尽管 OpenAI 和 Anthropic 在回应媒体询问时并未明确提及外部第三方原因，但此次多家 AI 企业同步遭遇故障的现象，引发了外界对其基础设施依赖关系的关注。

AI 电子设计能力评估：EEBench 综述

随着 OpenAI 展示其 GPT-6 Astra 在 KiCad 软件中进行电路设计的演示，业界开始关注如何客观衡量 AI 在电子工程领域的实际表现。本文介绍了 EEBench，这是一个专门用于评估 AI 电子设计能力的基准测试平台。

核心挑战与方法论

从 GUI 转向声明式代码

传统的电子设计依赖图形化 CAD 工具，AI 在使用这些工具时需要处理大量的坐标、菜单和应用状态，这使得测试重点容易偏向“计算机操作能力”而非真正的“电子设计能力”。

EEBench 采用了 atopile 的方法，通过声明式代码进行设计。在这种模式下，电路以代码形式存在，AI 代理可以直接操作组件、连接关系和电气约束。这种方式允许 AI 在不离开项目的情况下进行设计、构建、仿真和故障检查，从而更高效地测试其工程逻辑。

应对现实世界的复杂性

真实的电子工程不仅仅是套用教科书公式，更涉及复杂的权衡（Trade-offs）。EEBench 的任务模拟了真实的工程场景，例如：

• 元器件特性： 考虑电容在特定电压下的实际容量变化。
• 公差与极端情况： 要求设计在元器件达到最差公差范围（Worst-case tolerance corners）时仍能正常工作。
• 供应链与成本： 必须使用真实的制造商零件，并综合考虑电气性能、成本、封装尺寸及供应情况。

例如，在一个家用能量计的任务中，AI 不仅要通过添加电容来应对掉电情况，还必须确保在电压跌落期间，保护轨电压能维持在处理器断电阈值以上，同时还要兼顾成本和空间占用。

评分机制

EEBench 的评分过程是完全确定性的。其工作流程包括：

1. 构建设计： 自动生成电路图和物料清单 (BOM)。
2. SPICE 仿真： 通过 SPICE 运行一系列仿真测试，检查增益、阈值、纹波、瞬态响应以及在组件公差波动下的表现。
3. 综合评分： 技术得分与相对于参考 BOM 的成本效率相结合。只有在电路功能达标的前提下，成本优化才会影响评分。

性能表现与排行榜

根据 9 月 1 日的测试结果，领先的模型表现如下：

1. Claude Opus 5: 61.6%
2. Grok 4.6: 57.1%
3. Claude Fable 5.1: 56.4%

相比之下，OpenAI 的模型（如 GPT-5.5 和 GPT-5.6 Sol）得分在 39% 至 42% 之间。值得注意的是，xAI 已将 EEBench 纳入 Grok 4.6 的模型卡中，将其作为衡量“工程加速”能力的重要指标。

未来展望与强化学习

EEBench 不仅仅是一个评估工具，它还可以作为强化学习 (RL) 的环境。由于仿真失败提供了具体的反馈（例如：哪个电压跌破了限值，或者哪个工作点失效了），这些信息可以转化为高质量的奖励信号，帮助模型在训练过程中进行自我迭代。

结论： 虽然目前的 AI 还无法胜任起搏器等高风险医疗设备的自主设计，但在处理越来越多的特定电路问题方面，AI 已经展现出了实用价值。随着模型在工程领域训练数据的增加，AI 在电子设计方面的能力正在快速提升。

Statichost.eu 服务简介

Statichost.eu 是由 Eric Selin 创立的一项静态网站托管服务，旨在为 Web 开发者提供一种完全基于欧洲基础设施的替代方案。

核心理念与目标

该服务的初衷是解决当前互联网架构过于复杂，且过度依赖美国科技公司的问题。创始人认为，基础设施的归属权及其所在地对互联网生态至关重要。

主要特点

• 全栈欧洲化：Statichost.eu 承诺其技术栈的每一层——从 Git 部署到内容分发网络（CDN）——均运行在由欧洲公司拥有的欧洲基础设施之上。
• 摆脱美国供应商依赖：该服务明确声明不使用 AWS 或 Cloudflare 等美国云服务商，旨在为用户提供一个完全脱离美国基础设施掌控的托管环境。

服务背景

• 创始人：Eric Selin
• 总部地点：瑞典斯德哥尔摩

使用 Spotify Portal (AiKA Modes) 降低 Claude Code Token 消耗的方案总结

核心问题

在 AI 辅助编程中，大量的 Token 消耗并非用于高难度的逻辑推理，而是用于“脏活累活”（I/O 操作），例如：

• 阅读大量文件以回答单一问题。
• 根据现有模式生成样板测试文件或配置文件。
• 更新文档。

将这些任务交给昂贵的顶级模型（如 Claude）会导致极高的成本。解决思路是将这些低推理要求的任务路由到更便宜的模型（如 Gemini 2.5 Flash）上。

解决方案：AiKA Modes 与路由机制

作者利用 Spotify 的 Portal (AiKA Modes) 构建了一个自动化的路由系统。

1. AiKA Modes（声明式代理）

AiKA Modes 是运行在临时运行时（如 AWS Lambda）上的声明式代理。用户只需定义指令、选择模型、设置参数（如 Temperature）并附加工具，无需管理基础设施。作者创建了两种模式：

• bulk-reader (批量读取器)：用于分析代码。它读取多个大文件并以结构化的精简格式输出结果，避免将所有原始代码内容塞进 Claude 的上下文。
• code-writer (代码编写器)：用于生成测试、配置或类型存根。它要求参考现有文件以严格匹配项目的编码风格，并将生成的代码直接写入磁盘，Claude 甚至不需要“看到”生成的代码。

2. Shunt 插件：三层路由架构

为了实现自动化，作者开发了名为 shunt 的 Claude Code 插件，通过以下三层实现任务分流：

• 第一层：Hooks (钩子) 在 Claude 调用工具前进行拦截。例如，check-file-size 钩子会检测读取的文件行数，如果超过设定阈值（如 350 行），则拦截读取操作并强制 Claude 使用 /bulk-reader 技能。
• 第二层：Scripts (脚本) 封装了 Portal CLI 的调用。这些脚本负责构建请求、调用 AiKA 模式、处理错误，并将 Token 使用情况报告给 stderr。通过这种方式，复杂的调用过程对 Claude 而言变得简单透明。
• 第三层：Skills (技能) 通过 Markdown 文件指导 Claude “何时”以及“如何”调用上述脚本。当钩子拦截了操作时，技能描述会引导 Claude 使用正确的语法进行重定向。

性能与效果

• Token 节省：在 Java 单体仓库的测试中，bulk-reader 模式平均节省了约 90% 的 Token 消耗。
• 上下文优化：由于 code-writer 直接将结果写入磁盘，Claude 不再需要处理大量的输出 Token。

局限性

• 无法委派编辑任务：由于工作模型的摘要不具备可靠的行号信息，Claude 若要进行精确修改，仍需直接读取相关代码段。
• 无法委派复杂推理：该方案仅适用于模式化任务。对于调试、架构决策或安全关键型代码，仍需使用顶级模型，因为廉价模型可能会错过细微的逻辑漏洞。
• 延迟增加：每次任务委派都会产生网络往返，通常增加 10-30 秒的延迟。对于极小的读取任务，这种开销可能超过其节省的成本。

总结

通过将模型路由从“系统工程问题”转变为“配置问题”，开发者可以利用 AiKA Modes 实现模型能力的解耦。这种方法不仅提高了成本效益，还通过将低价值的 I/O 任务移出顶级模型的上下文，提升了整体开发效率。

欧洲国家为何将黄金从北美转移？

近期，欧洲各国央行出现了一种明显的趋势，即将其存储在北美的黄金储备转移至欧洲本土或伦敦。这一现象背后的核心动机是应对日益复杂的地缘政治环境及经济不确定性。

核心动向与动机

• 荷兰的行动：荷兰央行本周证实，已将其在美加两国存放的约86吨黄金（总计313吨）转移至伦敦。此举旨在应对“日益增加的地缘政治动荡”，确保在危机发生时黄金能“随时可用”。
• 其他欧洲国家的趋势：法国此前已宣布将黄金储备迁回国内；德国联邦银行在过去几年中也完成了从纽约和巴黎转移大量黄金储备的工作。
• 主要驱动因素：
  • 地缘政治与贸易风险：贸易战和军事冲突促使各国采取预防措施，将资产持有更靠近本土。
  • 流动性需求：伦敦作为全球主要的黄金交易中心，其英格兰银行是极具吸引力的存放地。在危机时刻，在伦敦存放黄金可以实现更快速的买卖和套现。
  • 资产管理优化：除了避险，各国央行也在通过多样化储备资产配置来提升抗风险能力。

黄金转移的技术手段

转移大量黄金涉及复杂的物流与金融操作，主要有两种方式：

1. 实物转移：通过专业的安全物流公司（如 Brink's）进行物理搬运，这需要极高的安全措施和周密的规划。
2. 账面转移（Book Transfer）：这是一种更为高效的手段，即在某一地点卖出黄金，同时在另一地点买入同等数量的黄金。这种方式在账面上完成了资产位置的转换，而无需进行实际的跨洋物理搬运。

市场背景与未来展望

• 央行需求激增：过去四年，各国央行平均每年增持1,000吨黄金，远高于此前十年平均每年500吨的水平。
• 避险属性：黄金作为“避险资产”，在通胀压力和地缘政治动荡时期具有天然优势。其稀缺性使其在对抗通胀方面表现出色（金价涨幅历史上通常超过消费者物价指数 CPI）。
• 价格走势：尽管金价近期较年初的高点有所回落，但仍处于历史高位。高盛（Goldman Sachs）预测，受央行需求推动，金价到2026年底有望达到每盎司4,900美元。

Pushin.eu 服务概述

Pushin.eu 是一个专注于欧洲本土托管的 Git 托管平台，旨在为开发者提供一个以隐私、高可用性和开发者体验（DX）为核心的环境，并明确拒绝将 AI 功能过度引入开发流程。

核心价值主张

• 欧洲数据主权：所有代码 100% 托管在欧盟境内（位于法国巴黎的 Scaleway 数据中心），完全受欧盟 GDPR 保护，避免了受美国《云法案》（CLOUD Act）管辖的风险，确保数据不会因外国政治或法律要求而被强制访问或锁定。
• 拒绝 AI 驱动与代码训练：平台不提供臃肿的 AI 功能，并承诺绝对不会将用户代码用于训练任何 AI 模型，无论是通过直接使用还是通过合作伙伴。
• 打击“低质量贡献 (Slop)”：针对维护者面临的低质量、重复性贡献（Reputation hunters）导致的职业倦怠问题，平台通过多种机制进行拦截。
• 高可用性：将系统可用性放在首位，确保开发团队能够随时进行代码推送与协作。

反“低质量贡献”机制

为了保护开源维护者，Pushin.eu 计划并实施以下措施：

• 邀请制注册：通过邀请码限制用户注册，确保新成员身份的真实性。
• 信誉与验证体系：引入类似 Tangled 的验证系统，让贡献者建立信誉，并结合多种信号评估 Pull Request（PR）和 Issue 的质量。
• 贡献限制：对新贡献者在非自有仓库中开设 PR 和 Issue 的数量设定合理上限。

技术特性与兼容性

• 数据迁移与同步：
  • pun CLI 工具：支持使用 pun import 命令从 GitHub 完整迁移仓库，包括 Git 历史、标签、Issue、已关闭/已合并的 PR 及其评论。迁移过程在用户本地机器运行，确保安全性。
  • 镜像功能：支持与 GitHub 的单向同步（Mirror），将 GitHub 作为事实来源，Pushin.eu 作为只读镜像，方便平滑过渡。
• 开发者工具链：
  • 标准协议：支持通过 SSH 或带有个人访问令牌（PAT）的 HTTPS 进行 Push/Pull 操作。
  • API 兼容性：提供 REST API（/api/v1），其请求与响应格式与 GitHub 兼容，便于现有脚本快速迁移。
  • 命令行管理：pun CLI 可在终端管理仓库、PR、评审和评论。
• 安全与导出：
  • 支持 TOTP 和 Passkey 进行账户安全验证。
  • 数据导出非常简单：代码可通过标准 git clone 获取，Issue 和 PR 元数据可通过 REST API 获取。

项目背景与路线图

• 创始人：由经验丰富的软件开发者及安全研究员 Peter Ullrich 开发。
• 开发进度：项目始于 2026 年 4 月，目前处于仅限邀请的测试阶段 (Invite-only beta)。
• 正式发布：预计于 2027 年初正式面向公众开放。
• 商业模式：正式运营后将提供个人及团队订阅服务，定价策略将对标 GitHub 和 GitLab。

该内容提及 GPT-6 Astra 已在 OpenRouter 平台上提供，并引导用户进行注册（Sign Up）。

Lean 4 中的费马大定理证明项目总结

该项目提供了一个在 Lean 4 环境下通过机器验证的费马大定理（Fermat's Last Theorem）的完整证明。该证明基于 Frey、Serre、Ribet、Wiles 和 Taylor-Wiles 的数学论证路径，构建于 Mathlib 之上。

核心定理陈述

定理在 Theorems/Thm_fermat_last_theorem.lean 中声明，其数学形式为：对于所有满足 $n \geq 3$ 且 $a, b, c > 0$ 的自然数，均有 $a^n + b^n \neq c^n$。

该证明具有极高的严谨性，通过 FinalCheck.lean 进行验证，确保证明过程仅依赖于 Lean 的三个标准公理：propext、Classical.choice 和 Quot.sound。证明中严禁使用 sorry（未完成证明）、axiom（额外公理）、native_decide、unsafe 或 partial def 等规避检查的手段。

验证机制

为了确保证明的绝对可靠，项目采用了多重验证手段：

1. 内核构建验证：使用 Lean 4.33.1 并在包含 2026 年内核健全性修复的版本上从零开始构建，确保所有 60,475 个模块均通过了 Lean 内核的检查。
2. Comparator 工具验证：利用 leanprover/comparator 工具将构建结果与挑战目标进行对比，确认证明内容与 Mathlib 的定义完全一致，且没有引入任何额外公理。
3. 独立内核验证：使用基于 Rust 编写的独立 Lean 内核 nanoda 对导出的环境进行二次校验，验证了超过 10 万个声明且未发现错误。

项目结构与阅读方式

项目提供了丰富的离线文档支持，通过 html/ 文件夹（约 390 MB）实现可视化浏览：

• 证明路径：用户可以逐步查看证明的逻辑流向。
• 定理与定义查询：包含 29,511 个定理和 1,450 个定义模块的详细信息，支持查看依赖图、引用关系及源码。
• 文件组织：
  • Theorems/：存放定理陈述。
  • P2M/Sol/：存放具体的证明实现。
  • Definitions/：存放数学定义。
  • verification/：包含用于验证证明正确性的脚本。

技术特性与来源说明

该项目的 Lean 源代码是由 AI 智能体 基于人类编写的开源 Lean 代码生成的。因此，代码的编写逻辑侧重于**“易于机器检查”**而非“易于人类阅读”：

• 变量名和标签多为机器生成的标识符（如十六进制后缀或流水线标签）。
• 移除了大部分注释，仅保留文档字符串和必要的引用。
• 在名称与陈述不一致时，以陈述的数学逻辑为准。

许可与致谢

项目由 Anthropic, PBC 于 2026 年发布，采用 Apache License 2.0 协议。其内容整合并衍生自以下开源项目：

• 帝国理工学院（Imperial College London）的 FLT 项目。
• flt-regular 项目。
• Mathlib 库。

Artificial Analysis Intelligence Index v4.2 更新摘要

Artificial Analysis 发布了 Intelligence Index v4.2 的中期更新。此次更新旨在通过引入更复杂、更真实的评估任务以及私有测试集，以应对快速发展的 AI 前沿技术，并防止模型通过针对性训练来“刷榜”（gaming）。

核心更新内容

1. 新增评估维度：

• AA-Briefcase：这是一种针对“代理式知识工作”（agentic knowledge work）的评估。它采用由行业专家构建的私有测试集，模拟涉及多周工作周期、大量关联任务及数千个源文件的复杂项目。通过标准评估（rubric）和成对比较（pairwise grading），从任务成功率、分析质量和表达质量三个维度全面评估模型的代理能力。
• Surge’s GDP.pdf：由 Surge AI 开发，用于评估长文本文档推理能力。模型需要跨越 100 份 PDF 文档（共计 4,592 页）进行单轮专业文档推理，涵盖文本、表格、图表、脚注等多种信息。评估基于 1,275 项专家编写的原子化标准，只有满足所有标准时才会被视为通过。

2. 机制与基础设施优化：

• 强化防刷榜机制：私有留存测试集（Held-out test sets）在 Index 中的权重从 v4.1 的 20% 翻倍至 40%。这包括 AA-Briefcase、AA-Omniscience 和 CritPt 的解决方案。
• 评分基础设施升级：
  • AA-LCR v1.1：改进了评分提示词并修正了答案密钥，提高了得分准确性。
  • GDPval-AA v2 与 AA-Briefcase：优化了采样并重新锚定了 Elo 分值，确保在引入新模型时评级更稳定。
  • SciCode：增强了评分沙盒的稳健性，确保运行较慢但正确的代码不会被误判为失败。
• 移除项：移除了已达到饱和状态的 GPQA Diamond 科学推理评估。

关键测试结果

1. 综合排名：

• Anthropic 处于领先地位，其 Claude Fable 5.1 位居 Index 榜首。
• OpenAI 位居第二，其 GPT-6 Astra 较 GPT-5.6 Sol 提升了 4 分。
• Meta 位列第三，紧随其后的是 SpaceXAI、Moonshot/Kimi、Z.AI 和 Google。

2. 细分领域表现：

• 代理知识工作 (AA-Briefcase)：Anthropic 的 Claude Fable 5.1 和 Opus 5 表现最佳。
• 长文档推理 (GDP.pdf)：OpenAI 领先，其中 GPT-6 Astra 的通过率为 33.2%，GPT-5.6 Sol 为 28.2%，Claude Fable 5.1 为 26.2%。

3. 效率与成本：

• 成本效益 (Cost per Task)：Anthropic、OpenAI、Meta 和 Z.AI 四家实验室占据了“单任务成本”的前沿阵地（Pareto frontier）。
• Token 效率：GPT-6 Astra 在输出 Token 效率方面表现极为出色，在智能前沿模型中优于绝大多数竞争对手。

为何“下一词预测器（Next-token predictor）”并非大语言模型的正确心理模型

文章指出，虽然从技术层面和推理过程来看，将大语言模型（LLM）称为“下一词预测器”并无错误，但将其作为一种理解模型本质的心理模型是不完整的，甚至是误导性的。

核心观点：机制形式 vs. 学习目标

文章区分了预训练阶段与现代后训练（特别是 RLVR）阶段在学习逻辑上的本质差异：

1. 预训练阶段（模仿学习）：

   • 目标： 模型学习预测训练数据中紧跟在给定序列之后的“实际词”。
   • 逻辑： 通过不断增大训练数据中真实出现的词的概率，模型实现对现有数据的模仿。此时，模型确实表现为一个“下一词预测器”。

2. 后训练阶段（RLVR - 基于可验证奖励的强化学习）：

   • 目标： 最大化奖励（Reward），而非预测数据中的下一个词。
   • 逻辑： 模型通过“探索”生成新的序列，并根据这些序列带来的结果（奖励）来学习。在 RLVR 过程中，并没有一个“正确”的下一个词需要预测，模型学习的是如何使包含特定词的序列能获得更高的奖励。

国际象棋类比

为了更直观地说明这一区别，文章使用了国际象棋引擎进行类比：

• 模式预测型（类似于预训练模型）： 学习大师级的棋谱，试图预测在某种局面下，大师最可能走哪一步。它是一个“下一招预测器”。
• 结果优化型（类似于经过 RL 训练的模型）： 通过穷举探索，了解每种局面下的获胜概率，并选择能带来最高胜率的步法。它不是在预测“大师会怎么走”，而是在通过探索寻找“如何获胜”。

结论

“下一词预测器”这一说法仅仅描述了模型输出的机制形状（即一次产生一个 token 的循环），却忽略了模型编码的实质内容。

随着 RLHF（人类反馈强化学习）和 RLVR 等技术的应用，现代 LLM 的目标已经从“模仿训练数据”转向了“模拟有用的助手”以及“通过探索发现新知识”。因此，理解 LLM 的关键不在于它输出的形式，而在于它在学习过程中所优化的目标。

Rust 版 React Compiler 已原生支持 Vite

随着 oxc 团队发布对 Rust 版 React Compiler (oxc-transform-react) 的官方支持，Vite 生态也迎来了显著的性能提升和功能增强。

核心优势

1. 极速的构建性能

相比于基于 Babel 的版本，Rust 版编译器在速度上有质的飞跃。在作者拥有 1,036 个文件的 React Router 项目测试中：

• 编译阶段：从原先使用 Babel 的 14.3 秒缩短至 0.81 秒，速度提升了约 17.6 倍。
• 整体构建时间：从 22.1 秒降至 9.3 秒，整体提升约 2.4 倍。 这种性能提升不仅能减少 CI（持续集成）的成本和等待时间，还能显著改善开发体验。

2. 修复了 Babel 版的局限性

新的 Rust 版编译器解决了许多在 Babel 版中会导致编译器“跳过”（bailout）优化的限制：

• 支持 try/catch 中的条件逻辑：解决了此前许多开发者遇到的阻塞问题。
• 支持解构属性的重新赋值：现在允许在解构组件属性后进行重新赋值，并能在嵌套闭包中使用。
• 支持计算属性键：允许在对象中使用动态计算的键名。

注：目前仍存在的局限性包括在 try 块内部使用 throw 以及使用逻辑赋值运算符（如 ??=、&&=、||=）。

3. 工具链的一致性

通过在整个工具链（如 Oxlint 和构建流程）中使用相同版本的 Rust 编译器，可以确保 Lint（代码检查）规则与实际编译行为完全同步。这避免了因编译器版本不一致导致的“检查通过但未被优化”或“检查报错但实际未编译”的覆盖漏洞。

如何使用

场景 A：使用 @vitejs/plugin-react

如果你使用的是 Vite 8+ 且使用标准的 React 插件，只需简化配置：

1. 安装依赖：npm install -D oxc-transform-react
2. 修改 vite.config.js：

   import react from "@vitejs/plugin-react";
   
   export default defineConfig({
     plugins: [react({ compiler: true })], // 开启实验性原生支持
   });
   

3. 清理：可以移除 @rolldown/plugin-babel 及其相关配置。

场景 B：非标准 Vite 插件场景（如 React Router 框架模式）

如果你在使用 React Router 的框架模式，无法直接使用 @vitejs/plugin-react，可以使用专门的轻量级插件：

1. 安装依赖：npm install -D @acusti/vite-plugin-react-compiler
2. 修改 vite.config.js：

   import reactCompiler from "@acusti/vite-plugin-react-compiler";
   import { reactRouter } from "@react-router/dev/vite";
   
   export default defineConfig({
     plugins: [reactRouter(), reactCompiler()],
   });
   

3. 清理：可以完全移除 vite-plugin-babel、babel-plugin-react-compiler 和 @babel/preset-typescript 等繁琐的 Babel 相关依赖。

联合国报告：全球变暖将突破1.5摄氏度限制

联合国环境规划署（UNEP）发布的一份最新报告指出，由于化石燃料（煤、石油和天然气）的持续燃烧，地球将在未来几年内突破《巴黎协定》所设定的1.5摄氏度升温安全阈值。这一发现标志着全球气候行动面临严峻挑战，世界必须从“预防升温”转向“应对超调”的新策略。

核心现状与“超调”概念

• 升温现状： 目前，全球气温已比工业化前水平高出约1.4摄氏度。
• 突破预测： 报告承认，全球升温将在未来几年内跨越1.5摄氏度的界限。如果各国维持现有的政策，到2100年升温可能达到2.6摄氏度；即便采取最雄心勃勃的行动，升温峰值预计也将在本世纪中叶达到1.8摄氏度。
• “超调”（Overshoot）策略： 既然无法阻止升温突破1.5摄氏度，联合国官员和科学家建议采取一种“先升温、后降温”的路径。即首先通过限制排放来控制升温峰值，然后在接下来的几十年里，通过停止使用化石燃料并利用碳捕集技术将气温降回1.5摄氏度以下。

面临的风险与后果

尽管“超调”策略旨在通过后期降温来降低长期损害，但人类仍需面对长达数十年的气候灾难期：

• 极端天气与环境破坏： 升温将导致海平面上升、冰川融化、生物物种灭绝以及更频繁、更致命的极端天气事件。
• 生态临界点： 报告警告，如果不加控制，可能会触发不可逆转的“临界点”，例如西极地和格陵兰冰盖的消失、亚马逊雨林的萎缩，以及维持欧洲气候的大西洋环流系统停滞。
• 社会与经济影响： 气候变化将导致粮食产量下降、水资源短缺、疾病增加及经济受损，部分地区甚至可能变得无法居住或无法投保。

应对措施：应对、遏制与冷却

报告建议采取分阶段的应对方案：

1. 应对与遏制（Coping and Containment）： 由于部分气候影响已无法避免，各国政府必须加强适应能力，以保护最易受气候变化影响的贫困人口。
2. 降温与碳移除（Cooling and Carbon Removal）： 在实现升温峰值后，必须通过大规模手段从大气中移除二氧化碳。报告强调，传统的植树造林仅能带来微小的降温效果，未来必须开发更先进、规模更大的碳移除技术。

专家对此持谨慎态度，部分科学家认为“超调”路径虽然是目前的主要希望，但在实际操作中实现“快速停止排放并逆转升温”的难度极大。

Quad9 服务概述

服务简介

Quad9 是由总部位于瑞士的 Quad9 基金会提供的一项免费 DNS 解析服务。其旨在取代用户默认的 ISP（互联网服务提供商）或企业 DNS 配置，通过提供更安全、更具隐私性的互联网连接，提升互联网的整体稳定性。

核心功能

1. 安全防护

Quad9 通过实时拦截恶意主机名，保护计算机、移动设备及 IoT（物联网）系统免受多种威胁，包括：

• 恶意软件 (Malware)
• 网络钓鱼 (Phishing)
• 间谍软件 (Spyware)
• 僵尸网络 (Botnets)

安全技术优势：

• 实时威胁情报： 利用来自 25 家以上行业领先网络安全公司的威胁情报，实时识别并拦截安全风险网站。
• 全球部署： 在 110 多个国家拥有 230 多个解析器集群。
• 高拦截规模： 平均每天拦截超过 6.7 亿次恶意请求。

2. 隐私保护

不同于将 DNS 数据进行商业化的服务，Quad9 将隐私视为其核心使命：

• 不记录 IP 地址： Quad9 系统不会记录任何包含用户 IP 地址的数据。
• 支持加密： 在系统支持的情况下，连接可以采用加密方式。
• 合规性： 整个平台自 2017 年起即设计为符合 GDPR（通用数据保护条例）标准。
• 数据控制权： 致力于确保个人数据由终端用户控制，防止 DNS 查询数据被商业化利用。

使用方式

• 操作简便： 用户只需将设备的 DNS 服务器设置更改为 Quad9 提供的 IP 地址即可使用。
• 无需注册： 使用过程不需要注册账号、提供个人资料或签署任何合同。
• 全网保护： 通过在路由器或 Wi-Fi 接入点配置 Quad9，可以将防护范围扩展至整个局域网内的所有设备，包括许多缺乏内置防病毒功能的 IoT 设备。

组织性质

Quad9 是一个非营利组织，其运营依赖于来自商业与非商业机构的资助、合作伙伴关系以及个人的捐赠。

CVE-2026-66066 (KindaRails2Shell) 安全事件总结

漏洞概述

CVE-2026-66066（被称为 "KindaRails2Shell"）是一个存在于 Ruby on Rails 8 及更高版本 ActiveStorage 组件中的严重漏洞。该漏洞允许攻击者通过处理畸形文件（如 BMP 或 PNG）实现任意文件读取及可能的远程代码执行 (RCE)。其 CVSS 评分高达 9.5/10。

事件背景与响应

安全机构 Rietta 在 2026 年 7 月 29 日监测到该漏洞。尽管当时官方尚未分配严重程度评分，且技术细节处于披露禁令（Embargo）之下，但 Rietta 决定立即采取行动：

• 紧急热修复： Rietta 越过常规维护窗口，在补丁发布当天即对受影响的客户（包括医疗 HIPAA 合规实体和州政府机构）执行了紧急补丁部署。
• 部署流程： 通过更新 activestorage 和 rails 包，并在通过自动化测试套件（CI）验证后，于当日深夜完成部署。

披露禁令的失效与攻击发生

尽管 Rails 安全团队设定了披露禁令，但“协同披露”模式在实际操作中被快速的漏洞研究生态系统所超越：

1. 补丁差异分析 (Patch-diffing)： 补丁本身是公开的，攻击者可以通过分析代码差异迅速推导出漏洞原理。
2. PoC 快速流出： 在 Rietta 完成补丁部署前，GitHub 上已出现了公开的漏洞利用概念验证 (PoC) 代码。
3. 攻击发生： 在 Rietta 完成补丁后的仅 8 小时（7 月 30 日上午 7:10），一名州政府客户就遭到了利用畸形 BMP 文件进行的首次攻击尝试。
4. 持续探测： 随后在 8 月份，攻击者利用伪装的 PNG 文件以及各种 User-Agent 进行了持续且自动化的探测攻击。

由于 Rietta 提前实施了补丁，所有攻击尝试均被成功拦截，未造成实际损害。

核心教训

• 补丁即风险： 漏洞补丁的发布本身就向攻击者泄露了风险信息。不能等待官方评分或详细的技术报告，必须在补丁发布时即视为紧急事件。
• 审批机制的局限性： 传统的、依赖人工审批的变更流程在应对此类高危漏洞时可能过于迟缓，企业应预先建立紧急变更授权机制。

安全实践建议

针对处理敏感数据的 Rails 应用程序，建议采取以下措施：

1. 即时响应： 默认将任何依赖项的安全更新视为紧急任务，不要等待 CVSS 评分。
2. 检查依赖： 确认应用程序是否使用了 ActiveStorage 并立即升级。
3. 建立紧急权限： 预先设定紧急变更审批流程，确保修复工作不会因等待人员授权而延误。
4. 自动化扫描： 定期运行 bundler-audit（检查已知漏洞）和 Brakeman（静态分析）等工具。
5. 强化文件处理边界：
   • 使用“魔数”（Magic bytes）而非 Content-Type 头部校验文件类型。
   • 严格配置图像处理库（如 ImageMagick）的策略。
   • 在沙箱环境或低权限用户下运行文件处理进程。
6. 部署 WAF： 使用 Cloudflare 或 AWS WAF 等工具，并持续优化规则以应对新型载荷。
7. 完善监控与日志：
   • 监控异常请求（如指向不存在路径的 POST/PUT 请求）。
   • 保持 WAF 和应用程序日志的完整性，并定期审查。
   • 使用 rack-attack 等工具对重复扫描行为进行限流。

吉他品格能进行乘法运算吗？

本文探讨了吉他品格（frets）的间距是否可以像滑尺（slide rule）一样通过对数逻辑执行乘法运算。这一疑问源于书籍《Calculating with Tones》的封面，该封面暗示了滑尺刻度与吉他品格间距之间存在直接的对应关系。

实验验证

作者通过对吉他进行数学标记并将其“纵向切开”模拟滑尺的操作进行了实验。

• 第一个八度音阶： 在第一个八度音阶范围内（将护弦/nut标记为1，第12品标记为2），吉他品格在特定数值组合下确实可以实现乘法运算（例如 $7/6 \times 3/2 = 7/4$）。
• 扩展至多个八度： 当尝试使用具有更多品格的电吉他（如24品）进行运算时，实验宣告失败。例如，当试图计算 $3/2 \times 2 = 3$ 时，结果无法对应。这表明吉他品格的间距逻辑并不能在更广的范围内模拟滑尺。

数学原理分析

滑尺之所以能进行乘法，是因为它利用了对数的性质：两个数相乘等同于它们的对数相加 ($\log(N \times M) = \log(N) + \log(M)$)。滑尺上的刻度距离是根据数值的对数来分布的。

在音乐理论中，人类对音高的感知是呈对数关系的（八度音阶对应频率翻倍）。在现代平均律中，一个八度被分为12个等分音，每个半音的频率倍数为 $\sqrt[12]{2} \approx 1.059$。由于弦的振动频率与长度成反比，因此吉他品格必须通过按比例缩短弦长来增加音高。

作者通过数学建模证明，吉他品格定位的函数与真正的对数函数并不等同。虽然两者在数值1和2处恰好重合，但在其他区间内，两者的曲线轨迹是不同的。因此，在第一个八度音阶内实现的“乘法成功”在很大程度上是一种数学上的巧合。

历史上的几何方法

在没有现代计算器的时代，乐器制造者通常使用几何比例来确定品格位置。作者提到了文森佐·伽利略（Vincenzo Galilei）在1581年提出的 18:17 比例法。

这种方法不依赖复杂的对数计算，而是通过简单的几何绘图工具（如圆规和直尺）利用比例关系来划分弦长。虽然这种比例计算出的半音倍数（约 1.0588）与现代的 $\sqrt[12]{2}$ 略有差异，但这种方法在历史上被广泛应用了两个半世纪之久。