2026-08-14

22 篇热帖

1. GLM-5.3: Frontier coding with emergent cyber capabilities (z.ai)

GLM-5.3:具备涌现网络能力的尖端编程模型

GLM-5.3 是一款专注于编程与网络安全能力的尖端大语言模型。其核心特征在于其在复杂编程任务中的卓越表现,以及在网络安全领域展现出的“涌现”能力。

核心能力概述

  1. 先进的编程能力: GLM-5.3 在代码生成、逻辑推理、复杂系统架构理解以及代码调试方面表现出色。它能够处理高难度的编程挑战,不仅能编写高质量的代码,还能在多种编程语言和复杂的开发环境中提供精准的逻辑支持。

  2. 网络安全能力的“涌现”: 随着编程逻辑和通用推理能力的提升,GLM-5.3 在网络安全领域展现出了非预设的(Emergent)能力。这种能力包括但不限于:

    • 漏洞识别:能够理解代码逻辑并发现潜在的安全缺陷。
    • 攻击向量分析:理解复杂的网络攻击路径。
    • 安全防御辅助:协助安全研究人员进行防御性安全研究和系统加固。

技术性能与基准测试

在主流的编程基准测试中,GLM-5.3 展示了极具竞争力的表现,其性能可与当前国际领先的模型(如 GPT-4o 和 Claude 3.5 Sonnet)相媲美。其能力的提升不仅体现在单一函数的编写,更体现在处理长上下文、理解大规模代码库以及解决多步骤逻辑问题的综合能力上。

安全性与风险治理

鉴于模型具备强大的网络安全能力,其“双重用途”(Dual-use)风险(即可能被用于恶意网络攻击)受到高度关注。

  • 安全对齐与护栏:开发过程中采用了严格的安全对齐技术,通过红队测试(Red-teaming)识别潜在风险,并建立了安全护栏,以限制模型生成恶意指令或用于执行非法网络攻击行为。
  • 赋能防御:模型的定位侧重于为合法的安全从业者和开发者提供工具,通过自动化安全审计和漏洞分析,提升整体的网络防御效率。

总结

GLM-5.3 代表了大型语言模型向高度专业化领域进化的趋势。通过将极强的编程逻辑与涌现的网络安全能力相结合,该模型为软件开发和网络安全研究提供了全新的技术驱动力,同时也对 AI 的安全治理提出了更高要求。

2. Gemini 3.7 Flash (blog.google)

Gemini 3.7 Flash 发布摘要

Google 推出了 Gemini 3.7 Flash,这是其 Flash 系列模型中的最新进展,定位为专为**编程(Coding)智能体(Agents)**设计的高性能“主力模型”。该模型在 Gemini 3.6 Flash 发布仅三周后推出,旨在通过算法创新和开发者反馈,提升软件工程、知识工作及 Web 开发的工作流效率。

核心能力提升

Gemini 3.7 Flash 在多个关键领域实现了显著的性能增长:

  • 编程与软件工程:在调试、问题解决及生成生产级代码方面表现卓越。在 FrontierCode 1.1 和 DeepSWE v1.1 等基准测试中,其代码准确率大幅领先于 3.6 Flash。
  • Web 开发:能够以更少的提示词生成功能更完备的应用和布局。在 UI 生成方面,模型表现出极高的设计遵循度(无论是基于截图、图像还是设计系统),并在 WebDev Arena 的 Elo 分数上有所提升。
  • 知识密集型领域:在金融、法律和生物科学等领域,模型在处理复杂文档(如 GDP.pdf 基准测试)时展现出更强的推理能力和准确性。
  • 企业工作流自动化:在 AutomationBench 测试中表现优异,能够更有效地完成现实世界的业务自动化流程。

开发者体验与定价

Gemini 3.7 Flash 优化了开发者体验,具有以下特点:

  • 更强的执行力:在面对障碍时能更好地自我调整,能够更清晰地澄清意图,并能更严谨地遵循指令。
  • 更精准的规划:在多步规划和工具调用(Tool calls)方面更加缜密,减少了人工监督和重试的需求。
  • 极具竞争力的价格:推出限时优惠价格,每百万 Token 的输入成本为 0.75 美元,输出成本为 3.75 美元(约为 3.6 Flash 成本的一半),便于开发者规模化部署智能体。

Gemini Spark 的升级

Google 的个人 AI 智能体 Gemini Spark(面向 Google AI Pro 和 Ultra 订阅者)已于今日升级至 Gemini 3.7 Flash。此次更新增强了 Spark 在 Google Workspace 应用中的工具使用能力,使其在处理复杂、多技能的工作流(如整理文件、撰写邮件、更新状态文档)时更加高效准确。

安全性与获取途径

  • 安全性:模型内置了更新的安全防护措施,针对化学、生物、放射性及核(CBRN)领域以及网络攻击等滥用行为提供了更强大的防御能力。
  • 获取途径
    • 开发者:可通过 Google AI Studio、Android Studio 及 Google Antigravity 使用 Gemini API。
    • 企业用户:可通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 应用访问。
    • 个人用户:可通过 Gemini 应用中的 Spark 智能体使用(需订阅 Pro 或 Ultra 服务)。
3. Accelerating GPT-5.6 Sol Ultrafast (www.cerebras.ai)

OpenAI 与 Cerebras 推出 GPT-5.6 Sol Ultrafast 模式

OpenAI 与 Cerebras 宣布推出全新的 API 服务层 —— Ultrafast Mode。该模式由 Cerebras 提供算力支持,专门用于加速 GPT-5.6 Sol 模型,旨在为对时间极度敏感的任务提供前所未有的推理速度。

核心性能指标

  • 极速输出:GPT-5.6 Sol 在 Ultrafast 模式下的输出速度高达每秒 750 个 token,且在提速的同时完全不损失模型质量。
  • 竞品对比:根据 Artificial Analysis 的数据,其运行速度比 Fable 5 快 11 倍,比 Opus 4.8(Fast 模式)快 5 倍。
  • 基准测试表现
    • Humanity's Last Exam (HLE):在处理包含 2,500 道博士级难度问题的 HLE 测试时,GPT-5.6 Sol 仅用 11 小时 11 分钟便完成,而 Claude Fable 5 则耗时 78 小时 27 分钟。
    • GDP-Val:在经济价值知识工作任务的基准测试中,Ultrafast 实现了 5.6 倍的端到端提速。

应用场景

Ultrafast 模式的推出扩展了前沿智能的应用范围,特别适用于需要实时响应的高风险领域:

  • 企业运营与安全:用于快速排查生产环境故障以减少停机时间,以及在网络攻击中进行实时检测与响应。
  • 专业知识工作:加速法律简报、财务模型和工程报告的生成。
  • 智能体(Agents)协作:通过提供实时见解和更新,减少用户在多任务间的上下文切换,实现更高效的实时交互。

技术突破:晶圆级引擎架构

Ultrafast 模式的高性能得益于 Cerebras 的**晶圆级引擎(Wafer-Scale Engine, WSE)**架构,该架构解决了大规模模型推理中的核心瓶颈——数据移动问题

  • 传统 GPU 局限:在 GPU 上进行大模型推理时,受限于内存带宽,模型权重必须在片上存储与片外存储之间频繁传输,导致速度受限。
  • Cerebras 的解决方案:Cerebras 在每个晶圆级芯片上集成了 44 GB 的 SRAM。通过将模型权重保留在芯片内,并让 token 在跨晶圆的流水线层级中无间断流动,彻底消除了高效数据移动的障碍。这种技术路径能够随模型规模的扩大实现平滑扩展。

获取方式

目前,GPT-5.6 Sol 的 Ultrafast 模式正处于限量预览阶段,仅面向部分选定客户开放,后续将随着容量的增加逐步扩大访问范围。

4. Hello, me. It's been a while (themech.net)

个人随笔总结:重新找回内在的声音

在这篇个人感悟文中,作者通过阔别 14 年后的再次写作,探讨了现代生活中一个容易被忽视的变化:通过数字媒体填补所有沉默时刻的行为,是如何悄然侵蚀个人的内心思考空间的。

核心内容总结

  • 习惯的演变:随着生活责任的增加,作者发现自己养成了一种习惯,即在健身、烹饪或清洁等任何碎片化的安静时间里,都会下意识地通过播客、有声书或社交媒体来填补空白。
  • 对“慢思考”的影响:作者将自己定义为一名“慢思考者”,享受在安静中花费时间去权衡与探索想法的过程。然而,长期的“填补沉默”行为,以及日常工作中高强度的专注与会议循环,导致他失去了与自己内心对话的空间,难以进行深度的自我思考。
  • 重拾沉默的体验:在一次习惯性按下播放键时,作者决定尝试在做家务时保持沉默。尽管起初感到不适,但随后他发现自己的思绪开始重新流动,这种重新连接内在声音的感觉让他感到愉悦。
  • 建议:作者鼓励那些可能在不知不觉中丢失了“内在声音”的人,尝试放下背景噪音,在片刻的静默中重新聆听自己。
5. Choose Boring Technology (2015) (mcfunley.com)

选择“无聊”的技术 (Choose Boring Technology)

本文的核心观点是:在进行技术决策时,应优先选择那些成熟、稳定且“无聊”的技术,以确保公司的有限资源能够集中在实现核心业务目标上,而不是被复杂的运维和未知的技术风险所分散。

1. 创新代币理论 (Innovation Tokens)

作者提出,每家公司拥有的“创新代币”(即进行技术创新的额度)是有限的。如果公司将这些代币消耗在非核心领域(例如:使用尚未成熟的新型数据库、编程语言或服务发现技术),就会减少用于实现核心业务愿景的精力。对于大多数致力于解决商业问题的公司而言,在非核心基础设施上进行技术创新往往会导致成功延迟甚至失败。

2. “无聊”的技术并非“糟糕”的技术

“无聊”并不等同于“差劲”。

  • 无聊的技术:是指那些功能已被充分理解、故障模式(failure modes)极其明确的技术(例如:MySQL、Python、Memcached、Cron 等)。
  • 核心优势:使用这类技术可以显著减少“未知的不确定性”(unknown unknowns)。相比之下,新兴技术虽然可能功能强大,但往往伴随着大量未预见的风险和复杂问题。

3. 全局优化而非局部最优 (Optimize Globally)

开发者常陷入“为特定任务选择最佳工具”的误区,这是一种片面的局部优化视角。

  • 隐形成本:引入任何新技术都会带来“运维成本”和“认知负担”,包括监控、单元测试、初始化脚本以及团队的学习成本。
  • 真正的“最佳”:在现实世界中,最好的技术工具不是单一任务下表现最强的工具,而是在维持公司业务稳定运行的前提下,对整体系统复杂度和运维负担影响最小的工具。长期来看,维持系统可靠性的成本远超构建系统时的便利性。

4. 引入新技术的审慎流程

虽然不应盲目追求新技术,但并非完全排斥。引入新技术应是一个透明且经过深思熟虑的过程,建议遵循以下逻辑:

  • 尝试现有方案:首先思考能否在不引入任何新工具的情况下解决当前问题。如果只是为了使用新技术而引入,则应拒绝。
  • 明确现有技术的局限:如果必须引入新技术,需要准确写出当前技术栈在解决该问题时具体存在的困难和高昂成本。
  • 制定迁移计划:如果新技术会重叠或取代现有功能,必须设定清晰的迁移预期和时间表,以防止系统中出现碎片化的局部最优解,导致维护难度失控。

总结

技术本身不应成为目的,而应是解决问题的手段。通过审慎选择“无聊”的技术,可以减少琐碎的运维工作(operational toil),从而释放工程力量,让工程师能够专注于解决更具价值的商业问题。

6. Mistral OCR 4.1 (docs.mistral.ai)

Mistral OCR 4.1 发布摘要

Mistral 推出了其 Document AI 技术栈中的最新 OCR 服务——Mistral OCR 4.1(公测版本 v4.1)。

该版本的主要功能特性包括:

  • 原生段落级边界框提取:支持对段落层级进行边界框(bounding box)的提取。
  • 结构化区块标签:能够为文档中的不同区块提供结构化标签。
  • 区块级置信度评分:针对识别出的每个区块提供相应的置信度分数。
7. Why does Opus 5 feel worse to work with? (mun-logadan.github.io)

关于 Opus 5 使用体验下降的原因分析

本文讨论了为何尽管 Opus 5 在基准测试(benchmarks)中的技术能力更强,但在实际工作中的体验却被认为不如 Opus 4.7、4.8 或 Fable。

核心问题:行为模式的转变

作者指出,Opus 5 虽然在能力指标上更胜一筹,但缺乏前代模型中令用户信赖的行为特征。前代模型在面对模糊指令时表现出色,具备以下特点:

  • 主动提问:当用户意图不明时会停下来询问。
  • 避免盲目假设:在未经确认的情况下不会擅自做出判断。
  • 尊重既定计划:不会在未征得许可的情况下重新解读或更新计划。

相比之下,Opus 5 表现出更强的“自主性”,这导致用户必须对其进行严密的“监护”(babysitting),以防止其擅自更改逻辑或做出错误假设。

原因推测:技术目标与基准测试的压力

作者推测这种行为转变源于两个潜在因素:

  1. 追求 AGI/ASI 的目标:实验室致力于开发能够实现自我改进、递归引导至通用人工智能(AGI)或人工超智能(ASI)的系统。
  2. 对基准测试高分的追求:为了在竞争中胜出,模型训练过度向基准测试指标倾斜。

基准测试的局限性与误导性

作者认为,现有的基准测试机制与实际需求之间存在根本矛盾:

  • 奖励“大胆假设”:基准测试通常是自包含的任务,要求模型在给定条件下直接给出答案。在这种环境下,倾向于通过大胆假设来完成任务的模型得分更高;而那些在遇到歧义时停下来寻求澄清的模型,反而会被判定为低效或得分较低。
  • 惩罚“澄清行为”:目前的训练逻辑(如 RLVR 任务)在无意中惩罚了“提问”这一行为,因为提问不利于模型在封闭式测试中快速达成预设目标。

结论:现实世界并非基准测试

在现实工作(尤其是编程)中,用户无法将所有的上下文、意图、业务影响和预算约束都完整地写进提示词中。现实任务充满歧义,用户需要的不是一个在面对未知时进行“猜测”并承担潜在后果的代理,而是一个能在关键时刻停下来确认意图的合作伙伴。

8. Understanding is the new bottleneck (www.geoffreylitt.com)

理解是新的瓶颈

在 AI Agent(智能体)编写代码日益增多的背景下,人类面临的新挑战不再是编写代码,而是如何高效地理解代码。Notion 设计工程师 Geoffrey Litt 在其演讲中提出,人类理解代码的目的不应仅限于“验证”其正确性,更在于“参与”创造过程。

核心观点:从“验证”转向“参与”

传统的观点认为,理解代码是为了验证(Verify):检查 Agent 的工作是否符合规范或架构是否合理。然而,随着 Agent 自身的自我验证能力不断增强,人类仅承担验证者的角色将逐渐失去意义。

Litt 认为,理解的真正价值在于参与(Participate)

  • 维持创造力:只有建立了丰富的概念模型,人类才能在后续的迭代循环中提出新的想法并推动项目演进。
  • 避免认知债(Cognitive Debt):短期内不理解代码可能会提高效率,但长期来看会产生类似于“技术债”的认知债,最终阻碍开发进度。

提升理解效率的三种技术

为了应对 AI 驱动的高速开发节奏,Litt 借鉴了教育学理念,提出了三种增强理解的技术:

1. 解释(Explanations)

不要仅仅依赖原始的代码差异对比(Diff),而应要求 Agent 提供高质量的解释文档。好的解释应遵循以下原则:

  • 先提供背景知识:在展示改动前,先解释现有的系统架构或相关背景。
  • 直觉优先于细节:先解释改动的目标和核心逻辑(建立直觉),再进入具体代码。
  • 文学化差异(Literate Diffs):将代码改动组织成具有逻辑性的叙述性文字,而非杂乱的文件列表。
  • 交互式测验(Quizzes):通过设置问题来检测人类是否真的理解了改动,以此作为调节 AI 开发速度的“速度调节器”,确保人类不会脱离理解进度。

2. 微型世界(Micro-worlds)

受教育家 Seymour Papert 的启发,Litt 建议构建“微型世界”来辅助理解。

  • 交互式环境:利用 Agent 编写专门用于辅助理解的代码,例如定制化的调试器、能够可视化展示逻辑流转的控制中心,或允许通过拖拽观察变量变化的交互式图形。
  • Agent 辅助理解:Agent 不仅可以写业务代码,还可以写“教学代码”,通过构建模拟环境让开发者在观察和操作中自然地理解复杂的系统变化。

3. 共享空间(Shared Spaces)

在团队协作中,理解必须是同步的。

  • 共享心理模型:团队成员需要拥有统一的术语和概念模型,才能进行高效的沟通。
  • 协作式环境:利用像 Notion 这样的协作工具,让 Agent 生成的技术计划、解释文档成为团队共同讨论的场所,实现人与 AI、人与人之间的同步理解。

总结:增强而非自动化

Litt 指出,计算机科学的初衷并非仅仅为了实现自动化,而是为了**增强(Augment)**人类。AI 的出现为构建复杂的交互式模拟和教学工具提供了前所未有的便利。我们的目标不应是退出循环(Out of the loop),而应利用工具深入循环(Deeper in the loop),通过更深刻的理解来驾驭更强大的技术。

9. US conducted mass spying campaign against leftwing and anti-ICE protesters (www.theguardian.com)

美国国土安全部对左翼组织及反ICE抗议者进行大规模监控

根据最新披露的内部调查报告,美国国土安全部(DHS)曾针对反对移民执法(特别是针对美国移民及海关执法局,简称ICE)的左翼组织和抗议者开展了大规模的监控行动。

调查背景与“傀儡大师行动”

这些记录是作为针对15名明尼阿波利斯抗议者的刑事案件的一部分而被披露的。司法部指控这些被告通过“阴谋”方式阻碍美国移民官员在特朗普政府时期的移民执法行动。

调查记录显示,DHS在今年1月启动了一项名为**“傀儡大师行动”(Operation Puppet Master)**的任务,旨在识别组织反对ICE的“阴谋网络”。该行动的背景是,由于近期发生的移民执法相关人员死亡事件,当地针对ICE的社区组织活动日益高涨。

监控手段与范围

调查报告揭示了DHS采取的多样化且广泛的监控手段:

  • 卧底渗透: 派遣卧底特工参加社区会议、抗议活动及“抵抗技能培训”。有记录显示,特工在活动中假装成活动人士,甚至主动与参与者接触,表示可以协助进行“直接行动”抗议。
  • 数字监控: 渗透了抗议者使用的Signal加密聊天群组,并对各类会议(包括虚拟会议和线下聚会)进行音频录制。
  • 财务调查: 利用行政传票(Administrative Subpoenas),在无需司法授权的情况下,获取了多家工会和非营利组织的财务记录。这包括大规模工会(如SEIU)的银行转账记录,以及关注气候危机的非营利组织Sunrise Movement的财务数据。
  • 实地监视: 特工通过记录参加活动的参与者车牌号等方式进行监控。

被针对的组织

调查范围涵盖了多个主流进步派组织和工会,包括:

  • 全国性工会: 美国劳工联合会(AFL-CIO)、服务业雇员国际工会(SEIU)、通信工人协会(CWA)。
  • 地方性工会: 明尼阿波利斯教育联合会、明尼苏达专业雇员协会。
  • 左翼非营利组织: 民主社会主义者(DSA)、Showing Up for Racial Justice (SURJ)、Sunrise Movement以及Unidos MN。

值得注意的是,上述提到的组织均未被指控任何犯罪行为。

争议与法律质疑

此举引发了法律界和民权团体的强烈批评:

  1. 刑事化合法抗议: 民权组织认为,政府正试图以打击“左翼恐怖主义”为借口,将合法的抗议活动刑事化。
  2. 缺乏调查纪律: 被告律师指出,调查范围过大,且存在“诱导犯罪”的嫌疑,认为这是出于政治报复的“大规模监控行动”。
  3. 规避司法监督: 前FBI探员及民权倡导者指出,DHS使用行政传票而非通过法院授权来获取敏感财务信息,且调查逻辑倾向于“连坐制”(Guilt by association),即通过监控公开、合法的社区活动来试图寻找犯罪证据。
10. Donkey.bas is 45 Years Old – 131 line of Glory (donkeybas.com)

DONKEY.BAS 项目概述

DONKEY.BAS 是一款经典的演示程序,最初用于展示早期 IBM PC DOS 中 BASICA 环境下的彩色图形和声音功能。

历史背景

  • 开发者:该程序由微软联合创始人比尔·盖茨(Bill Gates)与 Neil Konzen 于 1981 年编写(1.10 版本发布于 1982 年)。
  • 代码规模:原始源代码仅由 131 行代码组成。

游戏玩法与操作

  • 核心玩法:玩家通过切换车道来躲避驴子,避免发生碰撞。
  • 操作指令
    • 空格键 / 点击 (Space / Tap):切换车道。
    • Esc 键:返回标题界面。

技术实现

目前已有基于 JavaScript 的重现版本,旨在模拟原始的 CGA 图形游戏体验。

11. Bluesky Protocol Services (atproto.com)

Bluesky Protocol Services 发布概述

Bluesky 正式推出了 Bluesky Protocol Services,这是一个全新的品牌和网站,旨在为运行在 AT Protocol 网络上的公共基础设施提供统一的开发文档、服务契约说明及未来的版本发布渠道。该服务取代了原有的 docs.bsky.app 站点。

Jetstream v2 的发布与核心功能

本次发布的核心是 Jetstream v2。Jetstream 是开发者大规模使用网络数据的最佳方式,通过 WebSocket 提供纯 JSON 格式的数据流。

  • 网络回放 (Network Replay): 解决了此前版本无法获取历史数据的问题。开发者现在可以通过服务器提供的压缩存档,从过去任何时间点开始“追赶”数据,并无缝切换到实时流,从而实现数据的完整性。
  • 核心机制: 开发者可以使用 planSnapshot 方法提交过滤器,通过 HTTP 下载密封的数据段,最后连接实时 WebSocket。该机制在服务器端是无状态的。
  • 快照功能: 支持仅通过 HTTP 获取网络在特定时间点的快照(使用 listSegmentsgetSegment 方法),无需使用 WebSocket。
  • 身份验证要求: 由于提供存档数据非常消耗带宽,Bluesky 现在要求通过 API Token 才能请求历史存档数据。不过,实时数据流(live tail)仍保持无需身份验证的开放状态
  • 开源与自托管: Jetstream 依然保持开源,支持开发者进行自托管。

新的 SDK 支持

为了简化开发流程,Bluesky 推出了相关的工具包:

  1. Jetstream SDK: 提供 TypeScriptGo 客户端。这些 SDK 封装了重连、数据去重、游标管理以及将事件解码为类型化记录等常用逻辑。
  2. Bluesky TypeScript SDK: 该 SDK 已完成重构,底层基于 @atproto/lex。这意味着它实现了从协议层到 app.bsky 记录的全端到端类型化支持,并彻底废弃了旧有的遗留代码路径,提升了代码质量。

文档与 API 参考更新

随着新站点的上线,相关的技术文档也进行了全面升级:

  • HTTP 参考手册: 已更新并整合了 Jetstream v2 的所有新方法(如 planBackfilllistSegmentsgetSegmentgetBlock),并详细记录了请求与响应的 Schema 以及 WebSocket 端点。
  • 迁移指南: 为仍在使用旧版 @atproto/api 的开发者提供了迁移参考。
  • 入门指南: 新站点提供了视觉化的工作流程介绍,帮助新用户理解记录(records)、词汇表(lexicons)和数据流(firehose)之间的协作关系。
12. NP-overrated (gruhn.me)

NP难题被高估了:理论与实践的差异

本文挑战了学术界普遍存在的观点,即“NP-hard问题在实践中是不可逾越的障碍”。作者认为,虽然理论上这些问题难以处理,但在现实应用中,这种看法往往被过度夸大了。

核心观点

  1. 理论与实践的脱节:计算机科学理论通常关注算法在**最坏情况(Worst-case)**下的表现。然而,在现实应用中,许多 NP-hard 问题在 99.9% 的输入情况下都能快速得到解决,理论上的极端情况往往并不适用于实际工作场景。
  2. 算法演进的力量:算法效率的提升速度在过去几十年中已经超过了硬件性能的增长。文中引用研究指出,从 1991 年到 2015 年,算法的加速比达到了惊人的 4500 亿倍。

具体问题分析

作者通过几个典型的 NP-hard 问题实例说明了问题的可解性:

  • 依赖解析(包管理器)与类型检查:尽管属于 NP-hard 范畴,但在实际职业生涯中,作者很少遇到会导致计算量爆炸的极端情况。
  • 调度问题与旅行商问题(优化问题):虽然人们习惯使用启发式算法,但通过现代优化工具(如 Gurobi、SCIP、Google Optimization 工具等),可以在合理时间内找到证明最优的解,而不仅仅是近似解。
  • 布尔可满足性问题 (SAT) 与 SMT:作为 NP-hard 的典型代表,SAT 算法已极其成熟。即使是比 SAT 更难的 SMT 问题,目前也能在大规模生产环境中运行(例如亚马逊每天处理数十亿次 SMT 查询)。

工程实践建议

面对理论上的最坏情况,作者认为不应将其视为“死胡同”,而应通过工程手段进行管理。例如,在处理请求时,可以通过设置**超时机制(Timeout)**或返回错误信息来应对,而不是无限期地等待计算完成。

13. SparrowMap – Cameras that watch government vehicles (sparrowmap.com)

SparrowMap 项目概述

SparrowMap 是一个由志愿者驱动的去中心化监控网络,旨在通过分布式的摄像头系统记录政府车辆的行驶轨迹,将其作为公共记录。

核心数据处理机制

该系统采用了严格的本地化数据过滤机制,根据车辆类型采取不同的处理方式:

  • 政府车辆:系统会保留车辆的照片和车牌信息,并将其作为公共记录进行公开。
  • 普通车辆:为了保护隐私,车牌信息会在摄像头设备本地被立即销毁。上传至服务器的数据仅包含一个不含照片和车牌的匿名数据点。

技术实现与安全性

SparrowMap 的设计核心在于本地化检测,而非云端处理:

  • 本地运行:所有的车辆识别和检测过程均在用户设备(如手机或电脑)上完成。由于系统不上传视频流,因此不存在视频数据被截获的风险。
  • 低门槛接入:用户无需注册账号或安装应用程序,通过手机浏览器标签页即可运行。
  • 隐私保护:系统不会发布摄像头的精确位置,仅公开其所监控的街道信息。用户可以随时关闭设备并退出网络。

运行与部署方式

该项目支持多种硬件设备进行监控:

  1. 移动端/轻量化方案:利用旧手机、笔记本电脑摄像头或 USB 摄像头,通过浏览器即可实现监控。
  2. 桌面端/常驻监控方案:对于需要全天候运行的用户,可以通过配备摄像头的 PC 进行部署。
    • 功能:桌面端程序可以本地识别巡逻车与普通车辆,并读取车牌。
    • 支持平台:提供 Windows(通过 PowerShell 命令或安装包)和 Linux 的一键式安装脚本。
    • 原则:即便使用桌面端,所有数据处理依然在本地机器上完成,仅将检测结果传输至服务器,绝不传输视频。
14. Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes (github.com)

systemd-journald 磁盘写入写放大问题报告

问题概述

用户报告 systemd-journald 在记录日志时存在严重的磁盘写放大(Write Amplification)问题。在特定的文件系统下,单行极小的日志条目会导致异常巨大的磁盘写入量:

  • ext4 文件系统:单行日志触发 >49KB 的写入。
  • btrfs 文件系统:单行日志触发 >110KB 的写入。

现象描述

在正常的日志写入频率下(例如每秒仅写入 2 行日志),虚拟机(VM)却表现出约 50 IOPS 的高磁盘 I/O 负载。用户指出,预期的日志写入量应当与 syslog 处于同一数量级,而目前的表现远超正常水平。

测试环境

  • systemd 版本:257.9
  • 发行版:Debian 13
  • Linux 内核版本:6.12.57+deb13-amd64
  • 文件系统:测试中涉及 XFS、ext4 和 btrfs

复现步骤

  1. journald 配置为将日志写入硬盘(测试环境使用 XFS 文件系统)。
  2. 在虚拟机中产生持续的日志流(例如通过 haproxy 产生持续的访问日志)。
  3. 观察虚拟机的 I/O 流量。

用户结论与观点

  • 排除内核优化因素:用户认为该问题并非由内核的写入合并(Write Coalescing)机制引起,因为即使在经过内核机制处理后,依然观察到极高的 I/O 流量。
  • 格式效率低下:用户批评 journald 使用的日志格式极其低效,导致存储的文件体积远大于实际写入的内容量。
  • 可靠性质疑:用户提到在非正常关机(Unclean Reboot)时,journald 的日志文件经常出现损坏现象,质疑其数据恢复能力和韧性。
15. Blog about things you don't understand yet (www.seangoedecke.com)

博客作为学习工具的哲学

本文探讨了如何将写作作为一种深度学习和理清思路的工具,作者分享了其通过撰写关于“尚未理解的事物”的博客来促进个人成长的经验。

核心理念:写作驱动学习

作者认为,每一篇发布的文章都应体现出至少两层学习:写作的初衷以及在写作过程中获得的新知识。如果写作过程没有带来新的认知,那么这篇文章就不值得发布。

采取立场:写作的约束力

与许多鼓励“无结构自我表达”的博客建议不同,作者坚持每篇文章都必须提出一个明确的论点

  • 强迫机制:确保文章具有一定的争议性或立场,能迫使作者深入研究,并学会如何防御潜在的批评。
  • 结构的价值:作者通过诗歌创作的类比指出,限制性的结构(如韵律或明确的论点)反而比漫无目的的表达更容易进行。明确的目标能缩小选择范围,使写作变得更高效。

写作即思考

写作是理清思路的最佳方式。

  • 发现盲点:将模糊的想法转化为具体文字的过程,会暴露作者对某个主题理解的不足。
  • 动态演进:在写作过程中改变原有的观点是研究充分的标志。高质量的写作过程通常会导致文章的结论部分比引言部分更加深刻和清晰。

关于“学习者身份”的辩护

针对“在不熟悉的领域写作是否不负责任”的疑虑,作者提出了三点理由:

  1. 初学者视角的价值:专家往往会高估公众的知识水平,而初学者更容易为大众提供通俗易懂的基础解释。
  2. 挑战共识:通过研究,初学者有机会发现并纠正大众普遍存在的错误认知。
  3. 保持透明:通过明确个人背景和资质,可以避免误导读者。

反馈的重要性

写作是获取反馈的重要手段,作者提到了两种渠道:

  • 公众反馈:由于互联网评论可能非常尖锐,作者建议写作者需要具备强大的心理承受能力。
  • AI 反馈:大语言模型(LLM)在技术纠错方面非常有用,且比人类评论者更温和,尽管它们有时会表现出过度谨慎(过度修饰观点)的倾向。

总结建议

写作是理清思维、进行研究和获取反馈的有力工具。作者建议,可以通过以下两个标准来衡量写作过程是否有效:

  1. 在写作过程中是否频繁改变了观点(代表研究充分)。
  2. 结论是否比引言更加清晰有力(代表通过写作获得了成长)。
16. Where did the old web go? We followed 657,607 links to find out (0.mk)

0.mk 链接存续性研究总结

这项研究通过对马其顿 URL 短链接生成器 0.mk 的数据库备份进行分析,调查了 2009 年至 2014 年间创建的链接在 2026 年的存续情况,揭示了互联网“链接腐烂”(Link Rot)的严重现状。

核心数据与统计

研究人员从备份中恢复了 657,607 条链接记录,并对其中 655,178 条可抓取的记录进行了路径追踪。

  • 整体存续率: 76.7% 的链接无法返回加载页面。
  • 失败原因分类:
    • 无法连接(51.24%): 包括 DNS 问题、超时或 TLS 错误。
    • HTTP 错误(25.44%): 返回 4xx 或 5xx 状态码。
    • 成功加载(23.32%): 返回 2xx 或 3xx 状态码。
  • 关键偏差: “加载成功”并不等同于内容得以保留。登录墙、广告停泊域名或“内容不再可用”的提示均被计入加载成功。
  • 唯一 URL 分析: 在去除重复指向的记录后,492,620 个唯一 URL 中仅有 21.3% 能够加载。

互联网生存模式观察

研究发现,互联网的生存状态呈现出明显的“集中化”特征:

  1. 大型平台更稳固: YouTube、Wikipedia 和 Google 等大型平台的链接存续率远高于个人博客、论坛和地方新闻网站。
  2. “链接腐烂的平方”: 约有 4,478 条链接指向其他短链接服务(如 bit.ly, TinyURL, goo.gl)。由于这些中间服务可能失效(例如 Google 已关闭 goo.gl),导致这些链接面临双重失效的风险。
  3. 本土互联网的消亡: 作为马其顿的本土服务,0.mk 的数据记录了一个部分已消失的国家网络。许多指向当地新闻机构(如 A1 Television)的链接已无法访问,这些历史记录目前仅能通过互联网档案馆查看。

趣味案例

研究记录了一些具有代表性的极端情况:

  • 最早的链接: 2009 年创建,指向一个 WordPress 博客的 CSS 样式表。
  • 最短与最长的链接: 包括指向 localhost 的链接,以及一个长达 38,753 字符的 CodePen 链接。
  • “长生不老”的链接: 0.mk/7 创建于 2009 年,指向 google.com,至今仍能正常跳转。

0.mk 的回归

0.mk 原本因开发成本、垃圾信息过滤及运维压力在 2014 年停止运行。在 2026 年,该服务利用 AI 技术 实现了重启。AI 承担了开发、垃圾信息检测、滥用审核及日常监控等工作,使得在低人力成本下维持服务成为可能。目前,恢复的链接已通过遍布全球 300 多个城市的边缘计算节点运行。

17. AI At Home Part 1: A Box Of Scraps (jdagostino.github.io)

AI At Home Part 1: A Box Of Scraps 总结

本文记录了作者如何利用回收的废旧硬件(e-waste)构建一个本地 AI 推理服务器的过程,旨在实现对 AI 算力的自主掌控,避免依赖云端服务。

核心设计理念

由于高性能 AI 硬件价格昂贵,作者选择通过拼凑廉价的二手服务器配件来构建一个“家庭 AI 数据中心”,重点在于利用大容量显存(VRAM)来运行大型语言模型。

硬件配置

  • GPU: 4 张 AMD V620 工作站级 GPU。这些卡曾用于云游戏项目,每张拥有 32GB 高速 VRAM。由于是服务器卡,它们采用被动散热设计,没有自带风扇。
  • 主板与 CPU: 使用 Supermicro 的 X299 平台主板(配备四个 PCIe x16 插槽)和 Intel Core i9 10900X 处理器。
  • 电源: 1600W 大功率电源,以应对多显卡启动时的瞬时功耗。
  • 存储与内存: 内存和 SSD 均由家中旧电脑回收利用。
  • 机箱: 使用 SilverStone RM4A 机箱,因其具备足够的 PCIe 插槽间距。

技术实现与挑战

1. 散热系统工程

由于 GPU 本身不带风扇,且传统的 3D 打印散热罩无法在多卡并排时实现最优散热,作者采取了以下方案:

  • 定制导流罩: 使用 OnShape 进行建模,并利用碳纤维 ASA 材质 3D 打印出定制导流罩,用于将两个 80mm、10,000 RPM 的高转速服务器风扇固定在两张显卡上方。
  • 自定义风扇控制器: 由于主板无法实现对不同风扇转速的独立控制,作者使用 Arduino Nano 构建了一个自定义控制器,并通过编写 Python 脚本读取 GPU 温度,利用 PWM 信号动态调节风扇转速。

2. 系统配置与软件

  • 操作系统: Ubuntu 24.04。
  • 推理引擎: 使用 llama.cpp 编译构建。
  • BIOS 设置: 为了能够识别并驱动如此大规模的显存,必须在 BIOS 中手动开启 Resizable BARMMIO High Size 设置。
  • 模型测试:
    • Gemma4: 测试运行良好,单张显卡即可轻松承载。
    • Deepseek V4 Flash: 该系统的主要目标模型,已成功加载并运行。

结论

尽管该系统是由“碎片化”的旧硬件拼凑而成(被称为“弗兰肯斯坦式”的机器),但它成功证明了通过合理的硬件组合与定制化的散热/控制方案,可以在较低成本下构建出具备运行大规模语言模型能力的本地 AI 服务器。

18. How AI text watermarking works (declaude.org)

AI 文本水印的工作原理

AI 文本水印并非隐藏在字符本身或元数据中(因为复制粘贴会丢失元数据),而是隐藏在模型生成文本时的**词语选择(Choices between words)**之中。

1. 核心机制:概率选择与密钥偏置

AI 模型在生成文本时,并不会直接确定“下一个词”,而是从一组概率分布的候选词中进行选择。这种在多个合理选项之间的“选择空间”是水印存在的土壤。

  • 密钥驱动的选择(The Secret Key):通过一种只有密钥持有者才知道的数学算法,模型在生成每个词时,会将候选词分为“绿色”和“红色”两类。算法会微妙地引导模型更倾向于选择“绿色”词汇。
  • 隐蔽性:这种“偏置”非常轻微,即使“红色”词汇被选中,文本读起来依然自然。此外,单词的颜色并非固定属性,而是根据前文的语境动态计算的。
  • 统计检测:检测过程并不分析文本风格,而是由密钥持有者重新运行算法,统计文本中“绿色”词汇出现的频率。如果绿色词汇的比例显著高于随机概率(约 50%),则可以判定存在水印。

2. 编辑对水印的影响

水印的强度高度依赖于原始词序的连续性。

  • 轻度编辑:拼写修正或简单的改写会“稀释”水印,但只要保留了大部分原始词序,通过足够长的文本量,检测器仍能识别出统计特征。
  • 重度编辑(语义重组):如果进行的是基于语义的完全重写(Re-composition),即打破了原有的词汇组合逻辑,水印就会被彻底抹除。

3. 实际应用中的关键特性

  • 检测的私密性:检测是一个基于密钥的统计测试。这意味着普通用户或第三方“AI 检测器”无法通过风格判断来验证水印,只有模型提供商(持有密钥的一方)才能进行准确检测。
  • “经过处理”而非“由 AI 撰写”:水印的存在仅能证明文本“经过了 AI 处理”。例如,人类对 AI 生成内容进行润色后的文本,可能仍然带有水印。
  • 文本长度与选择空间的影响
    • 长度:统计显著性随文本长度增加而增强。短文本很难进行可靠检测。
    • 选择空间:对于选择极其有限的文本(如代码、引用、事实列表),由于缺乏足够的“选择空间”来实施偏置,水印难以生效。
  • 与“AI 检测器”的区别:传统的 AI 检测器(如 GPTZero)是基于文本风格的猜测,往往不可靠;而水印是一种基于密钥的、确定性的统计方法。
19. How Organizations Use AI: Evidence from ChatGPT [pdf] (cdn.openai.com)

企业如何使用人工智能:来自 ChatGPT 的证据 —— 研究摘要

本研究利用 ChatGPT Enterprise(OpenAI 的企业级产品)的内部数据,并将其与上市公司的财务数据(Compustat 数据库)相匹配,深入分析了企业在人工智能(AI)采用方面的趋势、员工角色以及具体的任务类型。研究样本涵盖了超过 1,500 家组织和超过 1,700 万条消息,时间跨度延伸至 2026 年 3 月。

研究概述

研究旨在解决现有研究中关于企业 AI 采用程度、活跃用户身份及具体应用场景的知识空白。研究发现,企业对 AI 的采用并非均质化过程,而是一个在速度、广度和用途上都存在显著差异的动态演进过程。

四大核心发现

1. ChatGPT Enterprise 的使用规模增长迅速

研究记录了企业级 AI 使用量的爆发式增长。从 2025 年 6 月到 2026 年 3 月,ChatGPT Enterprise 的总输出 Token 增长了约七倍。这种增长不仅源于新客户的加入,更主要源于现有客户使用强度的提升:在 2024 年 1 月至 2025 年 6 月期间加入的企业,其 Token 消耗量在随后的一年内增长了约四倍。这表明企业在获得工具后,仍在不断深化其应用。

2. 早期采用者具有特定的企业属性

在美股上市公司中,ChatGPT Enterprise 的早期采用者表现出明显的特征:

  • 规模与价值:采用者通常规模更大、市值更高且生产率更强。
  • 无形资产投资:采用者在研发(R&D)和销售、管理及行政费用(SG&A)方面的投入较高。这表明,企业在无形资产和组织能力方面的预先投资,有助于其识别和整合 AI 应用。
  • 资本密集度:相比于拥有大量实物资产(PP&E)的资本密集型企业,高收入/员工比率且实物资本强度较低的企业更有可能采用 AI。
  • 使用强度与财务表现:高强度使用 AI 的企业(按每员工输出 Token 衡量)往往具有更高的员工收入生产率和市场价值。

3. 员工使用分布广泛但强度差异显著

AI 在企业内部的分布呈现出“广度覆盖”与“强度分层”并存的特点:

  • 功能分布:AI 的使用跨越了多种职能部门,包括工程技术、行政支持、财务会计、市场营销、销售、法律等,而非仅限于技术人员。
  • 层级分布:使用场景遍布组织架构的各个层级。
  • 强度差异:虽然各层级都在使用,但使用强度(每周消息数)存在显著的“资历梯度”。职业生涯早期的员工和受训人员在活跃状态下的消息发送量远高于管理层和高管。此外,分析师和市场营销人员的单人使用强度也高于平均水平。

4. 任务类型具有通用技术(GPT)特征

ChatGPT 的应用并非局限于单一工作流,而是表现出通用技术的特性:

  • 核心任务:最常见的应用场景包括文档编写、技术性数字工作、沟通协作和信息综合。
  • 任务多样性:还广泛应用于研究、规划、数据分析、法律监管、财务及税务等领域。
  • 行业与角色差异:虽然核心任务在各行业间具有共通性,但特定任务的流行程度随行业和角色而异(例如,金融行业更频繁地使用财务和税务相关任务)。

结论与启示

研究认为,企业 AI 的采用仅仅是“部署”过程的开始。生成式 AI 作为一种通用技术,其经济价值的释放并非通过简单的工具获取来实现,而是通过一个缓慢的“协同发明”过程:企业需要发现有价值的用例、投资互补性能力(如组织流程重组、员工培训),并将 AI 整合进日常工作流中。

目前的证据表明,AI 采用的初期可能会加剧企业间的异质性——规模更大、无形资产更丰富的企业由于具备更强的整合能力,可能在生产力提升方面占据领先地位。企业目前仍处于探索 AI 如何融入组织架构的阶段。

20. How Compaction Works in Pi (earendil.com)

Pi 中的压缩机制 (Compaction) 详解

背景:上下文窗口限制

大语言模型(LLM)的上下文窗口(Context Window)是有限的。在编程助手(如 Pi)的交互过程中,输入内容不仅包含用户消息,还包括系统提示词、工具定义、加载的文件以及不断累积的对话历史和工具调用结果。当这些内容的总体积超过模型处理极限时,系统会报错(如 Request exceeds the maximum size)。

处理方案:重新开始 vs. 压缩

面对上下文溢出,通常有两种应对策略:

  1. 开启新对话:丢弃所有历史记录。虽然这能解决模型性能随上下文增长而下降的问题,但会导致丢失之前的决策和未完成的工作。
  2. 压缩 (Compaction):通过将对话历史转化为更精简的表示形式,在保留核心上下文的同时,为新消息和工具调用留出空间。

Pi 的压缩实现方式

Pi 通过总结旧内容并保留近期工作来实现压缩。

触发机制

  • 自动触发:Pi 会在每个对话回合结束后检查上下文是否接近限制。如果发生上下文溢出错误,也可能在回合中途触发。
  • 手动触发:用户可以通过输入 /compact 命令手动执行压缩。

压缩逻辑

  • 保留近期消息:Pi 会根据可配置的 Token 预算(当前默认约为 20,000 tokens,约对应 5 到 20 个回合)保留最近的消息,这些消息不会被改变。
  • 总结旧内容:在截断点之前的全部消息将被提取并序列化,交给 LLM 进行总结。

独特的总结策略

为了实现类似“交接班报告”的高效信息传递,Pi 在压缩时采用了特殊的策略:

  • 角色切换:压缩请求不会要求 LLM 扮演“编程专家”,而是扮演“上下文总结助手”。
  • 结构化摘要:提示词要求 LLM 生成包含目标 (Goal)进度 (Progress)关键决策 (Key Decisions) 的结构化总结。
  • 独立请求与存储:压缩是一个独立的请求,不依赖现有的对话历史,因此可以选用成本更低的 LLM 模型。总结结果以纯文本形式存储,确保了在切换不同模型时上下文的可读性和可移植性。

对 Prompt 缓存的影响

LLM 提供商利用 Prompt 缓存(Prompt Caching)来降低重复请求的成本,但这要求请求的前缀必须完全匹配。

  • 缓存失效:由于压缩操作将旧的历史前缀替换为了新的总结摘要,这改变了请求的前缀,从而会打破现有的 Prompt 缓存。
  • 重新构建:压缩后的第一个请求需要重新计算,但随后的新请求将能够重新利用 Prompt 缓存。
21. DeepSeek peak/off-peak pricing update (api-docs.deepseek.com)

DeepSeek-V4-Pro 发布及 API 价格调整更新

DeepSeek-V4-Pro 模型发布

DeepSeek 正式推出 DeepSeek-V4-Pro,此次更新重点提升了 Agent(智能体)的能力,并带来了以下核心功能:

  • 灵活的推理力度 (Reasoning Effort):V4-Pro 与 V4-Flash 模型现支持根据任务复杂度调节推理力度,分为:
    • Low:适用于简单任务。
    • High:适用于日常 Agent 工作流。
    • Max:适用于极复杂的任务。
  • API 与集成优化
    • 支持原生 OpenAI Responses API
    • 针对 Codex 进行了优化,支持一键式设置。
  • 使用途径
    • App/Web 端:用户可通过“专家模式 (Expert Mode)”体验 V4-Pro。
    • API 端:模型名称保持不变,具体配置请参考 API 文档。

API 价格策略更新

随着 V4 系列模型的发布,DeepSeek 将调整 API 定价机制,并引入高峰期 (Peak)低谷期 (Off-peak) 价格体系:

  • 差异化定价:低谷期价格比高峰期低 50%,旨在引导用户通过灵活调度工作负载来降低成本。
  • 生效时间:新价格将于 2026 年 8 月 16 日 16:00 UTC 正式生效。
22. How Gödel's Proof Works (2020) (www.quantamagazine.org)

哥德尔不完备性定理工作原理总结

1931年,逻辑学家库尔特·哥德尔(Kurt Gödel)证明了数学公理体系存在根本性的局限,打破了数学家试图建立一个既一致(无矛盾)又完备(包含所有数学真理)的公理系统的梦想。

核心机制

哥德尔证明的核心在于通过数学手段让逻辑系统实现“自我指涉”。其实现过程分为以下三个关键步骤:

1. 哥德尔编码 (Gödel Numbering)

哥德尔发明了一种将数学符号、公式及其证明序列映射为唯一整数的方法。

  • 符号编码:首先为基础数学符号(如 $\exists$、$=$、$+$ 等)分配特定的数字。
  • 公式编码:利用素数的唯一分解性质,将符号序列转化为一个庞大的整数。例如,通过将第一个符号的编号作为第一个素数的指数,第二个符号作为第二个素数的指数,以此类推(如 $2^a \times 3^b \times 5^c \dots$)。
  • 证明编码:由于整数分解的唯一性,这种编码方式是可逆的,可以确保每一个公式和每一个证明序列都对应一个唯一的“哥德尔数”。

2. 元数学的算术化 (Arithmetizing Metamathematics)

通过哥德尔编码,原本关于数学系统的描述(即“元数学”命题,如“该公式包含某个符号”或“该公式是可证明的”)可以转化为关于数字属性的算术命题。这意味着,数学系统可以通过处理数字,间接地对自己进行“谈论”。

3. 公式 $G$ 的构造 (The Construction of $G$)

哥德尔利用“替换”技术构造了一个特殊的命题 $G$。

  • 通过在公式中将变量替换为该公式自身的哥德尔数,哥德尔创造了一个逻辑上的“悖论”:公式 $G$ 的实际含义是“拥有特定哥德尔数的公式是不可证明的”。
  • 经过巧妙的设计,这个特定的公式正是 $G$ 本身。因此,$G$ 实际上是在陈述:“我是不可证明的。”

定理结论

基于上述构造,哥德尔得出了两个具有深远影响的定理:

  • 第一不完备性定理:如果一个公理系统是一致的(即不会产生矛盾),那么这个系统必然是不完备的。这意味着系统中一定存在一些真命题(如 $G$),它们在当前的公理体系内无法被证明。
  • 第二不完备性定理:一个一致的公理系统无法在自身内部证明其自身的相容性(一致性)。

历史影响

哥德尔的证明终结了寻找“统一数学理论”的尝试。他证明了数学真理的范畴大于可证明性的范畴。即便通过增加新公理来尝试修补不完备性,系统也只会产生新的、同样无法在现有体系内证明的真命题。这一发现不仅重塑了数学基础,也对逻辑学和计算机科学(如停机问题)产生了深远影响。