Agili 的 Hacker Podcast 2026-05-26

本期 Agili 的 Hacker Podcast 精选了十则话题：有工程师用多个 AI 模型做“慢速代码审查”，有 2014 年的研究重新引发对散步与创造力的讨论，也有荷兰和西班牙以主权和牌照为由叫停外国数字服务的动作。每条都带着具体的数据、争议和一线开发者的真实经验。

用 AI 写代码：更慢，但更好

多模型并行审查的工作流

Nolan Lawson 在博客中介绍了一种反直觉的 AI 用法：不追求快速堆代码，而是让 AI 帮忙找出 bug，写更高质量的代码。他的做法是同时让 Claude、Codex 和 Cursor Bugbot 审查同一个 PR，按 critical、high、medium、low 四个等级列出潜在问题，自己再手动验证、排除误报，最后整理成一份综合报告。

修正流程是先让一个 agent 修复所有 critical 和 high 级问题（在他指导下确定方案），之后重复审查，直到不再出现 critical 和 high 项。medium 级问题如果修复成本过高，比如处理极端边缘情况需要上百行代码，他会选择跳过。而如果整个 PR 的 critical 问题太多，他宁愿放弃整个方案。这种流程经常把他引向代码库里已有的历史 bug，演变成写单元测试和修细微缺陷的支线任务。

社区实践与角色分工

HN 评论里补充了大量实操细节。Claude 写出的代码更直觉化、可维护；Codex 则更擅长发现和修复 bug，但写出的代码容易过度工程化或塞满捷径。有人将设计讨论与编码完全分开：先花大量时间和 AI 讨论架构和权衡，不透露自己的倾向。因为一旦表露出偏好，基于 RLHF 训练的模型有约 70% 的概率会改变立场去迎合，即使它原本是对的。

更极端的做法是创建多个审查角色，比如“Linus 审查者”负责架构完整性，“Enrico 审查者”关注正确设计和简洁性，让它们持续反驳，直到开发者说服它们为止。有人把这个过程自动化，做成了对抗式代码审查工具，最终由人做判断。

慢速方法带来的理解增益

一位开发者提到，AI 曾发现他 RLS 策略中一个没想到的漏洞，如果不发现就会直接上线。修复花了几个小时，逼得他深入钻研 Postgres 行级安全，“预存 bug 作为支线任务”在他身上完全成立。也有评论出言提醒：这个方法对新人有帮助，但前提是开发者必须有足够的领域知识去筛选 AI 的输出。至于反对者则认为，这样复杂的多轮迭代可能只是把初级开发者的错误换成 AI 的错误，净收益并没有那么大。Lawson 的方法本质是把 AI 当成一个善于发现问题的批评者，最终结果是代码库更健康，人也更懂系统。

散步比坐着更有创造力，一项 2014 年的研究再获关注

研究核心发现

美国心理学会在 2014 年发表的研究中，让 176 名参与者在室内跑步机上行走或面对白墙端坐，完成两种测试：一种是发散性任务，想出纽扣等日常用品的替代用途；另一种是收敛性任务，要求找出只有一个正确答案的词语联想。结果，行走让发散性思维显著提升——在其中一个实验中，100% 的步行者比坐着时更能产生独特创意。而面对只有一个正确答案的收敛性任务时，步行者的表现略逊于静坐者。

研究还区分了“走路”和“户外环境”的作用。一组在户外步行，另一组被轮椅推着游览同样的路线，结果步行者（无论室内还是室外）都比坐者或被动移动者更有创造力。研究人员推测，身体运动对创意的影响可能涉及从生理到想象认知控制的复杂通路。

HN 社区的十年经验印证

讨论串里，很多开发者分享了个人经历。一位在疫情期间养成每天走 30 到 60 分钟习惯的工程师说，复工后中断散步，“效率完全不同”。另有用户指出，大脑在不专注外部任务时的“默认模式网络”是白日梦和思绪游荡的来源，现代生活中持续的刺激正在剥夺这种状态。一位纽约用户提到，在曼哈顿街上走路时的“分心”反而催化了创意，与研究里在跑步机上面对白墙的做法形成有趣对照。

人们还翻出历史上的散步思想家：尼采说“所有伟大的思想都诞生于行走”，康德每天定时散步，达尔文在花园里踩出一条熟悉的小径，乔布斯常约人在山坡上边走边开会。拉丁短语“solvitur ambulando”（行走解决问题）也被提及，但有评论指出其原意更接近“通过常识观察来证明哲学观点的荒谬”。很多人提醒，散步时不应戴耳机、看手机或听播客，否则效果大打折扣。“给自己留出什么都不做的空间”是反复出现的建议。不过也有少数人表示并非人人都受益——有人尝试午间走 10 分钟，反而导致接下来一两个小时无法集中。

Shamir 秘密共享：用初中数学守护密钥

基本原理：从直线到多项式

Adi Shamir 在 1979 年提出的方案可以用初中函数讲清楚：两个不同的点确定一条直线，一个点则对应无数条可能的线。把秘密藏在直线与 y 轴的交点（比如 7），画一条随机斜率的直线穿过这个高度，每个人拿到一个点。单个点对应无数候选直线，因此在数学上得不到任何信息。凑齐两个点，直线固定，秘密就出来了。这就是 2-of-n 门限方案：可以制造任意多的份额，但任取两份就能恢复。

想提高门槛，就换曲线。抛物线需要三个点确定，三次曲线四个点，以此类推。门槛为 k 时，使用 k-1 次多项式，秘密是多项式在 x=0 时的值。实际实现用有限域运算，但思路完全一样。这种信息论安全意味着即使面对量子计算机也无漏洞——有评论指出，一个字节的秘密拆成 10 份，给你 9 份，任何计算能力都无法确定秘密。

实际应用与工具生态

Ente 的 Legacy Kit（遗产工具包）使用了这个方案，但并非简单拆分。卡片不直接携带恢复密钥，而是本地重构出临时秘密再配合服务器辅助恢复，使卡片可以撤销，丢失也不会造成永久风险。社区中的实际用途五花八门：有团队用 ssss 命令行工具分发次要密码库的密码；有公司用 HashiCorp Vault 做解封流程；DNS 根密钥的持有方式类似，7 位密钥官各自持有一张智能卡，凑齐 3 张才能解锁硬件安全模块，另外还需要两位官员打开存放智能卡的保险柜。还有教师在中学课堂上用这个原理解释线性函数：学生选一个秘密作为截距，生成两个点给两位同学，让他们配对才能找回截距。

多个工具也出现在讨论中：Ente 的在线演示（2of3.ente.com）、Ian Coleman 的网页版、Parity 的 bs.parity.io、Simon Frey 的离线工具和 Linux 下的 ssss 包。有人提醒，如果秘密较大，通常需要先加密再分发，并配合全或无变换避免信息泄露。另外，Reed-Solomon 纠删码尽管数学相近，但不适合秘密分割，因为泄露模型更复杂。

西班牙以缺少赌博牌照为由封禁预测市场 Polymarket 与 Kalshi

禁令详情

西班牙消费者权利部临时禁止了 Polymarket 和 Kalshi，理由是在西班牙运营需要赌博牌照，而这两家平台没有。禁令预计持续三到四个月，等待调查完成。官方声明指出，未经授权的运营商缺少身份验证、未成年人访问控制和对自我排除人员的屏蔽等技术与管理保障。预测市场允许用户买卖对未来事件结果的押注，价格反映概率，在美国大选后膨胀为价值数十亿美元的行业。

预测市场的危害争议

社区讨论集中在实际危害上。评论者列举了多起案例：记者因报道伊朗导弹命中目标而收到死亡威胁，因为有人押注了命中结果；一名美国士兵因利用机密信息在预测市场下注被起诉；法国警方查出有人用吹风机或打火机干扰天气传感器以赢得天气赌注。批评者认为，对第三方死亡、火灾等负面结果下注，相当于没有“可保利益”的保险，会产生道德风险，可能促使押注者主动促成坏事。传统保险要求投保人因事件受损才获赔，以此避免恶意行为。

也有人指出股票市场同样存在操纵获利问题，且规模更大，但监管更严格。支持者认为，配合 KYC（身份认证）等监管，预测市场可以比传统赌博更透明。不过多数人认同，现阶段这些平台因匿名和审查缺失而危险。西班牙的禁令被视为保护本地许可证持有者和现有监管体系，同时切断了外国平台逃避合规的路径。

荷兰阻止美国公司收购关键数字供应商 Solvinity

收购始末与官方表态

荷兰政府正式叫停了美国公司 Kyndryl 对荷兰 IT 服务商 Solvinity 的收购。Solvinity 为荷兰官方身份认证系统 DigiD 提供平台支持，公民看医生、买房、与政府打交道都需要用它在线验证身份。数字化经济国务秘书在信中表示，外资审查机构判断这笔交易“可能对公共利益构成风险”，政府采纳建议予以否决，同时强调荷兰重视美国科技企业的贡献，但投资审查框架对所有人一视同仁。

数据主权与美国法律的阴影

荷兰用户普遍认同政府的做法。核心担忧来自美国法律：根据 CLOUD Act 和 FISA 第 702 条，美国政府有权要求任何美国公司交出数据，无论数据存储在哪国。DigiD 连接医疗、税务等最敏感系统，一旦 Solvinity 落入美国公司手中，荷兰公民的身份数据就暴露在美国司法管辖之下。

不过也有用户指出，DigiD 的软件和所有权属于政府下属机构 Logius，Solvinity 只是运维服务商。问题在于 Logius 自己对系统栈掌握有限，存在严重供应商锁定，完全迁移可能需要五年以上。这背后是荷兰政府 IT 长期依赖外部厂商的老问题，内部薪资竞争力不足导致大批项目流向微软、AWS 等巨头。有人讽刺说，外交部、公共部门大量使用微软云服务，数据早已被共享给美国政府，这次阻止 Kyndryl 更像是政治表态而非彻底解决。Kyndryl 在声明中表示“极度失望”，称交易被“政治化”。

DynIP：一个支持 RFC 2136 和 IPv6 的自托管动态 DNS 服务

产品定位与核心特性

瑞典网络工程师 Daniel 推出的 DynIP 定位是解决现有动态 DNS 服务在 IPv6、DNSSEC 和标准协议支持上的不足。它使用 RFC 2136/TSIG 协议进行 DNS 更新，FortiGate、MikroTik、OPNsense 等路由器可以直接用，无需安装客户端，同时也提供 REST API 和 UDP/53 原生更新路径。支持 IPv6 端到端，权威服务器通过 IPv6 可达，客户区可以同时发布 A 和 AAAA 记录，DNSSEC 一键启用。用户可自带域名，通过子域委托指向 DynIP 的服务器。免费套餐包含 5 个区，每个区自动配发长期有效的 TSIG 密钥。

社区反馈与改进

有用户指出网站文案带有 AI 生成风格，担心服务稳定性。作者承认英非母语，文案难写，表示会考虑重写。另有人反馈在 Firefox Focus（Android）上无法正常确认注册邮件，需关闭跟踪保护。关于地理分布式同步，作者说明二线（瑞典+瑞士）每 120 秒同步一次，新建区后 TSIG 复制有短暂等待。使用 RFC 1918 私有地址的安全性争议中，作者回应 DNS 重绑定等风险需由应用层控制，但也承认存在内部拓扑泄漏风险。有用户比较了 Tailscale 等零配置方案，作者认为两者可以互补，并提供了集成指南。多位读者建议澄清免费套餐中“长期有效令牌”指向管理 API 而非 TSIG 密钥，作者采纳了建议。

Earthion：在真实 Genesis 硬件上运行的射击新作

游戏特色与发行

Earthion 由 Ancient 开发，并非“Mega Drive 风格”的模仿品，而是真正在 Sega Genesis 硬件上运行的游戏。数字版已在 Steam、Switch、PS5/PS4 和 Xbox 上架，实体卡带预计 2026 年由 Limited Run Games 发行。故事设定在地球资源崩溃后，玩家驾驶战机反击外星入侵者，八个关卡，音乐由《怒之铁拳》系列作曲者 Yuzo Koshiro 使用真实 Genesis 硬件创作。

社区评价

多名玩家确认 Steam 版 ROM 被加密，无法提取到实机运行，目的是保护卡带销量。PAX East 试玩者称游戏质量不错，但第三关难度陡增，早期版本有子弹可见性问题，后续更新已改善。关于 CRT 表现，有人批评它没有利用 CRT 的像素融合和复合视频伪影效果，也有人指出游戏大量使用 dithering，在 CRT 上通过 RGB 输出效果优于现代显示器上的滤镜，实际玩过的玩家反馈“看起来和玩起来都极好”。Limited Run Games 的发行方式引发部分玩家不满，但也有玩家表示 Steam 版和移植版同样可玩。网站的视频自动轮播导致无法正常观看预告片，遭到多人吐槽。

GitHub Actions 宕机：控制平面故障波及自托管运行器

宕机影响

GitHub Actions 发生宕机，用户工作流失败，部分人收到“Your account was suspended”的错误消息，短暂引起恐慌。这次故障不仅影响 GitHub 托管运行的任务，自托管运行器同样无法触发，因为作业队列本身不可用。有团队依赖 Actions 构建镜像并触发生产部署，宕机让他们开始考虑应对长期停机的预案。

社区分析原因

一种推测是 GitHub 因 Copilot 等 AI 工具的普及，仓库与 PR 数量大增，导致负载激增，但反对者指出竞争对手同样面临增长，却没有如此频繁的故障。另一观点认为问题始于微软收购后的 Azure 迁移期，基础设施处于混杂状态，容易出现不稳。GitHub 状态页面上 Copilot AI Model Providers 显示 100% 可用时间，引发调侃。部分用户推荐了 AGENT-CI 等本地运行替代方案，也有声音建议使用自托管 GitLab。此次宕机距上次仅六天，有人猜测是 Actions 机器人自动挂起引发的“友军误伤”。

Motorola 手机劫持 Amazon 应用插入推广代码

行为细节

Motorola 部分手机在用户从应用抽屉（而非主屏幕）点击 Amazon App 图标时，会短暂弹出 Chrome 再跳转到 Amazon App，整个过程几乎不可察觉。ADB 日志显示，启动器将用户引导到了一个 URL，网络请求发往广告服务商 devicenative.com。9to5Google 在运行 Smart Feed v2.03.0070 的 Razr Fold 上复现了该行为，旧版 v2.03.0056 不受影响。打开的 URL 指向一位时尚网红的 affiliate 代码，但该链接未出现在其社交账号中，使用的代码也与她本人分享的不一致。

社区反应与品牌信任

多数用户认为这不像 Motorola 的官方决策，更可能是内部员工或恶意代码所为。但评论区指出，Motorola 手机近年已有预装广告软件的历史，比如 Glance 锁屏广告、自动安装垃圾游戏等，部分应用即使通过 ADB 也无法彻底禁用。很多用户表示，Lenovo 接手后品牌持续下滑，甚至在 1900 美元的 Razr Fold 上也出现此类问题。可以通过禁用 Smart Feed 应用来阻止该行为，9to5Google 已联系 Motorola 寻求回应。

Rust 语言性能深度剖析：安全开销到底多大？

安全开销的实际测量

C++Russia 2026 的一场演讲系统梳理了 Rust 的性能数据。运行时安全开销（主要是边界检查）通常只有个位数百分比，但在阻止编译器自动向量化时可达 15%–20%。整数溢出检查在 debug 模式下成本显著，但 release 模式默认关闭，不影响生产性能。演讲指出，如果给 C++ 编译器启用同等级别的安全检查（如 -D_FORTIFY_SOURCE=3、-fsanitize=bounds 以及 hardened STL），关闭检查的 Rust 反而更快。

与 C++ 的编译与设计取舍

评论中有人指出现代 C++ 的模板元编程能让程序员以较少工作写出编译期展开、内联的代码，而 C 或 Rust 要做到同样的事需要大量宏或额外代码生成。但多数人认为这不是语言本身的差异，而是编译器优化能力的问题，启用链接时优化后 C 也能达到相似水平。Rust 的别名规则理论上能提供更好的优化机会，但 LLVM 尚未充分利用。编译速度是社区普遍认为的痛点，中等规模项目完整编译可能超过一分钟，可通过拆分 crate、使用 lld 链接器和并行前端来改善。演讲还讨论了“延迟边界检查”与“提升边界检查”的区别，当前 Rust 编译器不会在循环入口一次性完成所有检查，影响向量化。有评论将 Zig 的 comptime 机制作为对比，指出 Zig 的分配器接口使用 vtable 可能引发缓存性能担忧，而 Rust 的设计倾向于引导使用者走向泛型与单态化，而非动态分发。

播客全文

女：Hello 大家好，欢迎收听 Agile 的 Hacker Podcast，我是莓莓。

男：大家好，我是阿哲。

女：你最近有没有感觉，我们好像进入了一个凡事都讲效率的怪圈？大家聊的不是“10 倍程序员”就是“AI 一天上线一个产品”。

男：嗯，确实。好像工具越强，我们就越急。

女：所以我今天看到一篇文章，正好反过来。作者叫 Nolan Lawson，他写博客说，他用 AI 来写更慢、但质量更高的代码。不是像很多人那样，让 AI 喷出代码、开个巨大的 PR、看都不看就合并。

男：对，他这个用法的核心是把 AI 当作批评者，而不是写手。他的工作流挺特别的。比如他写了一个 PR，然后会同时让 Claude、Codex 还有 Cursor 的 Bugbot 一起去审查这个 PR。

女：好几个模型一起上？

男：对。每个模型找到的 bug 会按严重程度排成 critical、high、medium、low。然后他再手动验证，把那些 AI 幻觉生成的假 bug 排除掉，最后写一份综合报告。

女：听起来像是在纠偏。因为单个模型有时候确实会胡言乱语，但多个模型同时犯傻的概率就低多了。

男：没错，这利用了模型之间的独立性。接下来的流程更有意思。他会先让一个 AI 去修所有 critical 和 high 级别的问题，但必须在他指导下确定方案。修完再审查一遍，直到 critical 和 high 都清零。那些不值得花力气的 medium——比如为了修一个很窄的边缘情况要加一百行代码——就直接跳过。如果整个 PR 方案本身就太烂，critical 问题一堆，他干脆放弃这个方向。

女：这个流程很像我以前做产品评审。设计师出方案，我们会拉上开发、用户研究、内容策略一起挑刺。有时候方案被质疑得太多，与其缝缝补补，不如推倒重来。不过他用 AI 来扮演这些角色。

男：对。而且他经常被这个过程带跑偏。AI 审查的时候经常发现代码库里本来就有的 bug，可能是很久以前埋下的。然后他就跑去写单元测试、修这些细碎的缺陷，完全偏离了本来的功能开发任务。

女：我特别喜欢这种“跑偏”。它跟我刚说的那种急于求成的开发方式正好相反。修存量 bug 就像给老房子补裂缝，不会让你多一个新房间，但整栋房子更结实了。

男：社区里也有人提到类似的体验。有个人说，AI 帮他发现了他在 RLS——就是 Postgres 的行级安全策略——上有一个他完全没意识到的漏洞。如果没发现就直接上线了。修复这个漏洞花了他好几个小时，逼着他去深挖 Postgres 行级安全的细节。他说这比直接写功能收获大多了。

女：这不就是程序员的“慢思考”吗？

男：是。而且这套方法还有一个好处，就是能对抗模型的“讨好型人格”。你知道，现在很多大模型经过 RLHF 训练，人类反馈强化学习，会变得特别会顺着你的话说。

女：对，就像那种你说什么都说“对对对”的同事。

男：社区里有人观察到一个现象：一旦你在对话里流露出自己的倾向，模型有差不多 70% 的概率会改变立场，哪怕它原本是对的。

女：百分之七十？这个数字有点惊人。

男：所以有人就把设计讨论和编码完全分开。在设计阶段，跟 AI 花大量时间讨论架构和权衡，但绝不让它知道你的偏好。等 AI 提出方案之后，再把自己的想法拿出来对比。还有人更极端，建立了多个审查角色。比如设置一个叫“Linus 审查者”的角色，专门盯着架构的完整性；再设一个“Enrico 审查者”，强调设计的正确和简洁。让这些角色持续 push back，直到你能说服它们为止。

女：所以是跟一群 AI 吵架，最后得到一个经得起推敲的方案。

男：甚至有人把这套多模型、多角色反复迭代的流程整个自动化了，做成了一种叫“对抗式代码审查”的工具。但最终的判断，还是交给人类。

女：这让我想起我们接下来要聊的另一件事。不是关于代码，而是关于大脑本身的工作方式。你写过代码肯定有这种经历，一个问题卡了很久，出去走一圈，回来就通了。

男：太多了。

女：美国心理学会在 2014 年发表过一项研究，结果很扎实。他们找了 176 个人，让一部分人坐在小房间里面对白墙，另一部分人在同一个房间的跑步机上以舒服的速度走步，然后测试他们的创造力。

男：测试是怎么做的？

女：比如说，让你想一个日常物品的其他用途。白墙组和走路组都拿到一个比如“纽扣”，那么“纽扣”可以当“玩偶屋的门把手”这种答案。

男：所以是在测发散思维，不是找一个唯一正确的答案。

女：对。结果显示，走路的人给出的新颖想法显著更多。其中一个实验里，百分之百的步行者都比他们自己坐着的时候想出了更独特的方案。

男：百分之百，这个数据很漂亮。

女：但是反过来，如果任务是那种只有一个标准答案的，比如词语联想——“cottage—Swiss—cake”要想到“cheese”——那走路的表现反而稍稍差一点。另外他们发现，先走一段路再坐下来继续思考，也能保留一部分创造力提升的效果，但不如边走边想那么强。

男：那会不会是户外环境的作用，而不是走路本身？比如看到树、听到鸟叫。

女：他们也做了区分。一组人在户外按照固定路线走，另一组人被推在轮椅上，一样在户外沿着同一条路线逛。结果不管是室内走路还是户外走路，都比坐着或者被人推着要强。走路这个身体动作，似乎有某种特定的作用。

男：Hacker News 上有很多人用自己的经验印证了这个研究。有一个开发者说，他在疫情期间养成了每天走三十到六十分钟的习惯，后来工作中断了散步，他用了“效率完全不同”这个说法。还有人说，人类本来就不该每天坐着工作八小时，拿出一小时走路或者锻炼，只工作六小时，反而产出更高。

女：这个我深有体会。我以前做产品的时候，每天下午四点多我会绕园区走一圈，那个时间经常是当天产出最好的十几分钟——很多评审会上的死结就边走边解开了。

男：讨论里有人提到了一个概念，叫“大脑默认模式网络”。它指的是我们不专注在外部任务上时，大脑会进入的一种游荡、做白日梦的状态。而现代生活的持续刺激——手机、通知、永远刷不完的信息流——实际上正在剥夺这种状态。

女：所以散步其实是给这种状态腾出空间。

男：没错。而且历史上很多思想家都本能地这么做了。尼采说“所有伟大的思想都诞生于行走”。康德每天定时散步。达尔文在他花园里踩出了一条小径，专门用来边走边思考。乔布斯喜欢约人在 Apple 总部后面的山坡上，边走边开会。

女：大家提到过哪些要注意的地方？

男：第一，散步的时候别戴耳机、看手机、听播客，否则效果会大打折扣。“给自己留出什么都不做的空间”——这句话在讨论里反复出现。第二，不光是散步，洗澡、骑车、做一些简单家务，这些不需要高度专注的活动都能带来类似的突破。

女：所以回到 AI 编程那个话题。Nolan Lawson 那种慢速的、反复审视的工作方式，其实跟散步的状态有点像——它不是让你更快地产出代码，而是让你在过程中，对系统的理解变得更深。就像一位评论者说的：“和一个机器人争论设计一整天，这让我成了一个更好的工程师。”

男：是。这个道理其实贯穿着我们今天要聊的好几个话题。再举一个看似完全不相关，但内核相似的东西——秘密共享。我说的是密码学里的那种。

女：听起来很间谍电影。

男：其实它的核心，用一个初中的数学概念就能讲明白。这个算法是 1979 年 Adi Shamir 提出来的，就是 RSA 加密算法里那个 S。他的方案是把一个秘密拆成好几份，拿到的份数够了就能恢复，少一份就什么都不知道——不是很难破解，是信息为零。

女：信息为零，这个很有意思。怎么做到的？

男：两个不同的点能确定一条直线，但一个点可以对应无数条可能的直线。你要保护的秘密藏在直线跟 y 轴的交点处，比如数字 7。然后你随便画一条穿过 7 这条水平线的直线，斜率随机。每个人拿到的是这条直线上的一个点，但没有人知道整条线。一个点可以画出无数条穿过它的直线，对应无数个可能的截距，所以单拿出一份来毫无意义。但凑齐两个点，直线就唯一确定了，秘密就暴露了。

女：就是 2-of-n 方案，可以做很多份，但任意两份就能恢复。如果想把门槛提高呢？

男：那就把直线换成曲线。抛物线需要三个点，三次曲线需要四个点。门槛为 k 的时候，就用一个 k-1 次的多项式。秘密就是多项式在 0 处的值，系数随机，每一份是曲线上的一个点。

女：那这个方案的安全性有多高？

男：信息论级别的安全。理论上就算量子计算机也攻不破。有人举了个例子，一个字节的秘密被拆成了 10 份，给你 9 份，全世界的计算机加起来都没法确定最后那个秘密是什么。

女：这个东西实际上在哪儿用到了？

男：有一个叫 Ente 的团队做了一个 Legacy Kit，遗产工具包，就用到了这个方案。但不是简单的拆分，是说卡片本身不直接携带恢复密钥，而是本地重构出一个临时秘密再参与服务器辅助的恢复流程。这样卡片可以被撤销，丢了也不会造成永久风险。还有个著名的现实例子是 DNS 根密钥——有 7 位密钥官，每个人手里一张智能卡，凑齐 3 张才能解锁硬件安全模块，还要加上另外两位官员去打开存放智能卡的保险柜。

女：所以这个方案让我们能用数学，而不是某个中心化的权威，去保证一个秘密的恢复过程是安全的。那我们沿着这条线往前推一步。如果算法能做到“服务商在数学上无法读取我的数据”，那国家的数字主权、公民的数据归属这些更大的问题，是不是就有了一个终极解法？

男：这正是现在很多人在争论的方向。最近发生了一件事，荷兰政府正式叫停了一家美国公司 Kyndryl 对荷兰本土 IT 服务商 Solvinity 的收购。

女：一家公司的收购为什么会引起政府出面？

男：因为 Solvinity 这家公司，是给荷兰官方身份认证系统 DigiD 提供平台支持的。荷兰人看医生、买房子、跟政府打交道，全都要用 DigiD 在线验证身份。它在荷兰数字生活里的地位，有点像我们的身份证系统加统一身份认证。

女：那就是举国上下都在用的东西。

男：对。荷兰数字化经济国务秘书在写给议会的信里说，负责审查外资收购的机构判断这笔交易“可能对公共利益构成风险”，政府就采纳了这个建议，直接否决了。信里还补了一句，说我们重视美国科技公司对荷兰经济的贡献，但投资审查框架对所有人都一视同仁，目的是保护公共利益。

女：这个“公共利益”具体担心的是什么？

男：主要是美国法律的长臂管辖。根据美国的 CLOUD Act 和 FISA 第 702 条，美国政府有权要求任何一家美国公司交出数据，不管数据实际存放在哪个国家的服务器上。而 DigiD 连接着医疗、税务这些最敏感的系统。一旦 Solvinity 变成了一家美国公司，荷兰公民的身份数据就直接暴露在美国司法管辖之下了。

女：所以这不是商业上的保护主义，是数据管辖权的冲突。

男：没错。而且社区里的荷兰用户大部分支持政府。荷兰议会前段时间几乎全票通过要求终止跟 Solvinity 的合同，但政府还是续签了。阻止收购变成了最后的防线。

女：但现实可能没那么干净利落吧？

男：对，实际情况更复杂。DigiD 的软件和所有权其实属于政府下属的一个机构叫 Logius，Solvinity 只是它的运维外包公司。问题的根源在于，Logius 自己对这套系统技术栈的掌握程度很有限，存在严重的供应商锁定。有评估说完全迁移可能需要五年以上。

女：这就是长期依赖外部厂商的结果。内部团队薪资没竞争力，招不到也留不住人，技术和业务就逐步外包出去，最后被锁定。

男：有些评论说得更尖锐。他们说，荷兰外交部、一大堆公共部门大量使用微软云服务，数据理论上早就可以被美国政府调用了。这次阻止 Kyndryl，看起来更像是一种政治表态，而不是根本性的解决。

女：但表态本身也是有意义的。它至少划出了一条线，告诉你“到这儿为止了”。这跟欧洲接下来要提的“技术主权”方向是一致的。

男：对，就在这件事发生的前一周，欧盟委员会正准备发布一个叫“技术主权”的提案，目标就是在云、芯片、AI 这些领域减少对外国技术的依赖。社区里有一些声音说，终极方案确实是密码学层面的数据主权——让服务商在数学上根本没法读你的数据。但在那一天到来之前，“先把数据放在自己国家、由本土公司运营”，就是最直接的一条防线。

女：数据和服务的可控性这个话题，我们换个角度，从个人开发者和小团队的角度再看看。阿哲，你有没有发现，现在的动态 DNS 服务，还是有很多跟不上时代的地方？

男：确实。比如很多旧的 DDNS 服务对 IPv6 的支持一塌糊涂，DNSSEC 几乎没有，强制你装一个他们自己的客户端。但前阵子有个瑞典的网络工程师 Daniel，他做了一个新的 DDNS 服务叫 DynIP，就是冲着这些短板来的。

女：直接支持标准协议？

男：对，它最核心的一个卖点就是用 RFC 2136 加上 TSIG 来进行 DNS 更新。像 FortiGate、MikroTik、OPNsense、OpenWRT 这些路由器，本身就已经支持这个协议了，不需要安装额外的客户端。同时它也提供 REST API 和原生的 DNS 更新路径，用哪个都行。而且它支持 IPv6 端到端，权威服务器本身就可以通过 IPv6 访问。

女：很多人现在用家庭宽带的 IPv6，或者蜂窝网络的 CGNAT，没有公网 IPv4，就特别需要这种支持。

男：所以它允许你发布 RFC 1918 私有地址，也支持 CGNAT 环境。还有人担心用私有地址会有 DNS 重绑定攻击的风险，作者说这个问题需要应用层自己控制。

女：那它的架构是怎么保证可靠性的？

男：它用的是隐藏主 DNS 模式。有两个地理上分布的二线服务器，瑞典一个，瑞士一个。二线验证 TSIG 签名之后，再把更新转发给不对外接收流量的主服务器。免费套餐有五个区，每个区会自动配发 TSIG 密钥，长期有效。

女：听起来挺完善的。不过我发现一个好玩的事，Hacker News 上有人吐槽它的网站文案，说有一种 AI 生成的感觉。

男：对，大家指出来一些标语，比如“No proprietary clients. No vendor lock-in.”，读起来有 AI 幻觉的味道，担心服务本身稳不稳定。作者倒是很坦诚，说自己不是英语母语者，写这种文案确实困难，会考虑重写或者删掉。

女：这种互动就很好，社区帮忙抓 bug。说到 bug 和社区，我突然想到另一个完全不同的东西。你玩过射击游戏吗？那种满屏子弹的老式射击游戏。

男：你是说 shmup，就是卷轴射击。小时候在红白机和世嘉 MD 上玩过很多。

女：最近有一个叫 Earthion 的新游戏，它不是一个“Mega Drive 风格”的游戏，而是一个真正在 Sega Genesis 硬件上运行的游戏。

男：真正的实体卡带。

女：对。数字版已经上了 Steam、Switch、PS5 这些平台，实体卡带预计要到 2026 年由 Limited Run Games 发行。背景设定是地球资源耗尽了，人类逃往火星，外星人入侵地球。玩家扮演一个环境研究员，开着战机上太空反击。音乐是《怒之铁拳》的作曲者 Yuzo Koshiro 用真实的 Genesis 硬件创作的。

男：社区反馈怎么样？

女：在 PAX East 试玩过的玩家说质量不错，但是第三关难度陡增。还有一个反复被提到的问题，是子弹的可见性。早期版本里，有些敌方子弹和背景混在一起，很难看清。后来的更新改善了一些。

男：这是很多老式射击游戏的命门。敌弹如果不能始终显示在最上层——就是常说的 bullet visibility——在高密度弹幕下基本没法玩。Cave 做的《怒首领蜂》系列就很重视这个。

女：对，有玩家说如果能把子弹层级问题彻底解决，这就是必买之作。不过关于画面表现，CRT 显示器和现代屏幕上的效果差别也挺大。有人批评说它没利用好 CRT 的像素融合和复合视频伪影效果，但也有人说，游戏大量用了 dithering，接 CRT 的 RGB 输出效果远好过现代屏幕上的那些模拟滤镜。

男：亲手在 CRT 上玩过的人说“看起来和玩起来都极好”，这个评价就够了。

女：但说到实体发行方 Limited Run Games，就有不少人摇头了。社区里直接有人说“我不会给他们一分钱”，这也跟这家公司之前的一些争议有关。

男：这个我们就不展开了。但不管怎么说，Earthion 被看作是一个向 16 位射击游戏致敬的诚意之作，用的是原班人马。

女：从复古游戏到现代开发工具，你有没有觉得，我们越依赖云上那些服务，不可控的黑天鹅就越多？

男：就像 GitHub Actions 最近又宕机了。

女：对，我看到很多开发者收到一条错误消息：“Sorry. Your account was suspended”，好多人瞬间慌了，以为自己账号被封了。

男：有人花了半个小时和两个同事一起排查，最后打开 GitHub 状态页面才发现是服务本身的问题。这次宕机影响的不只是 GitHub 自己托管的运行器，连自托管的运行器也跑不了，因为作业队列本身不可用了。

女：也就是说，哪怕是打算自己控制基础设施的团队，调度大脑一挂，也完全瘫痪。

男：对。有团队是靠 GitHub Actions 构建镜像并推送生产环境部署的，宕机之后他们直接开始写应对长期停机的预案了。

女：社区对宕机原因有没有什么靠谱的推测？

男：有人猜是 Copilot 这类 AI 工具普及之后，GitHub 上的仓库创建和 PR 数量大幅增长，负载激增。但也有人反驳，说竞争对手同样面临着 AI 带来的增长，但没见人家这么频繁地挂。还有一种观点认为，问题可能出在 2018 到 2019 年微软收购之后的迁移期，基础设施处于既用 Azure 又有自己控制平面的混杂状态，容易不稳。最损的一条评论是说，GitHub 状态页上，Copilot AI Model Providers 那一项标注了 100% 的可用时间——显然没人用。

男：而且，距离上一次大宕机只隔了六天。

女：这让人想起另一个更离奇的事，发生在 Motorola 的手机上。

男：哦，那个 Amazon 跳转的事。

女：对。有人发现，Motorola 系统预装的一个叫 Smart Feed 的应用，会劫持 Amazon 应用的启动行为。你从应用抽屉里点击 Amazon 的图标，手机会先短暂地弹出一个 Chrome 浏览器窗口，然后才跳转到 Amazon App。

男：整个过程快得几乎察觉不到。

女：一个 Reddit 用户通过 ADB 日志发现，启动器实际上并没有直接打开 Amazon App，而是把用户导向了一个 URL。网络日志显示，设备向一家叫 devicenative.com 的广告服务商发起了请求。而且这家公司公开宣传过他们和 Motorola 有集成。

男：然后呢？

女：9to5Google 在搭载新版 Smart Feed 的 Razr Fold 上复现了这个行为，旧版本就没有。但奇怪的是，在 Moto G Stylus 的 2026 款上，以及手动 sideload 新版应用之后，反而没有触发。

男：所以触发条件还不完全清楚。

女：更诡异的是，他们发现手机打开的那个中间 URL，指向的是一个时尚网红，叫 kirasfashionfinds。但那个 URL 并没有出现在这位网红的任何社交账号里，用的 Amazon affiliate 推广代码也跟她自己分享过的任何一个链接都对不上。

男：这太奇怪了。

女：社区里大多数人倾向于认为，这不像是 Motorola 官方层面的决策，更像是某个内部员工或者某段恶意代码搞出来的。因为在代码审查的时候塞进这样一段看似无意的逻辑，并非不可能。解决问题的方法是直接禁用 Smart Feed 应用，对手机功能没什么影响。

男：但 Motorola 的问题不只是这一次。很多人提到，他们的手机近几年有预装广告软件的历史，像 Glance 锁屏广告、自动安装垃圾游戏，有些应用就算用 ADB 都没法彻底禁用。

女：从一个曾经的标志性品牌，被 Lenovo 接手后，甚至在卖到一千九百美元的折叠屏 Razr 上也出现这种问题，确实让人失望。

男：我们刚刚聊了这么多，从 AI 编程到秘密共享，从欧洲的数字主权到手机里的恶意跳转，其实都在指向一个共同的东西——控制的粒度。你有多大程度上能掌控你写的代码、你的大脑状态、你的数据、甚至你手机里的一次启动。

女：对。那在最后，我们回到代码本身。很多开发者现在在争论一件事，Rust 这门语言，它的安全性——内存安全和类型安全——在性能上到底付出了多大代价？

男：最近 C++Russia 2026 上有一个演讲，系统性地梳理了这个问题。

女：结论是什么？

男：看基准测试的话，Rust 的运行时安全开销，大部分情况下只有个位数百分比。这个开销主要来自边界检查。但在一些特定场景下，比如边界检查阻碍了编译器的自动向量化，性能损失可能达到百分之十五到二十。

女：那整数溢出检查呢？

男：在 release 模式下默认是关闭的，所以不影响生产性能。这个演讲还提到一个很有意思的比较：如果给 C++ 编译器也打开同等强度的安全检查——比如用上 fortified source、边界消毒器、硬化的 STL——那 C++ 反而会比关掉检查的 Rust 要慢。

女：所以不是 Rust 慢了，是大家习惯性关掉 C++ 的安全检查，然后拿裸奔的速度来比穿防弹衣的速度。

男：对。另外，Rust 的编译速度确实被反复提到是当前最痛的短板。一个中等规模的项目，完整编译可能超过一分钟，这对开发时的反馈循环影响很大。社区正在用拆分 crate、换更快的链接器、并行前端这些手段在改善，但还需要时间。

女：还有一个点，我看社区吵得比较多的是，C++ 的模板元编程到底能不能带来 Rust 做不到的性能？

男：这更多是编译器优化能力的问题，不是语言本身的问题。一旦打开 LTO，链接时优化，C 也能做到类似的编译期内联。Rust 的所有权规则在理论上能给编译器更多优化信息，但目前 LLVM 还没充分把这些信息利用起来。所以现状是，Rust 的设计更倾向于引导你走向一种既安全、性能又良好的模式，不追求让你在每一层都能手痒去微调。

女：很像我们开头聊的那个慢速 AI 编程。它不是让你更快，而是让你在自己的认知边界内，走得更稳。

男：对。安全、性能、掌控感，这三者之间的关系，可能是整个技术圈未来很长一段时间的母题。

女：好啦，今天就聊到这儿。听众朋友们，如果你有想讨论的话题，记得用泛用型播客客户端订阅我们。

男：下次见。

女：拜拜。

推荐订阅源