今天的话题从本田车机安全漏洞到 Python 垃圾回收的回退，再到复古操作系统的坚守，跨度不小。欢迎来到 Agili 的 Hacker Podcast 每日播客文字版。
一位安全研究者公开了针对 2021 款本田思域车机的逆向工程成果，发现了一个易于利用的固件签名漏洞。
本田的车机运行 Android 开源项目（AOSP），其 OTA 更新机制接受用 AOSP 公开测试密钥签名的更新包。这意味着任何人只要物理接触车前的 USB 端口，就能刷入自定义固件，获得任意代码执行权限，完全不需要 root。
研究者将这种攻击命名为“EvilValet”（邪恶代客泊车），并发布了 ota-builder 和 apk-rebuilder 工具，让他人也能轻松生成被车机接受的更新文件。
评论区指出，现代车机曾使用过通过谷歌搜索“RSA key”就能找到的密钥，错误性质和本田类似。对于实际威胁，看法存在分歧：有人认为代客泊车装恶意软件不如直接放个 GPS 追踪器省事；也有人指出在租车场景中，攻击者可利用车机作为跳板，结合 CarPlay 漏洞攻击连接的手机。
一位评论者总结得直接：“本田造车一流，软件水平不行。”
开发者 robhati 发布了一款免费开源的工具，只需将 SQL 的 CREATE TABLE 语句粘贴进去，浏览器就能生成可拖拽的实体关系图（ERD）。数据不出本地，无需注册。
这个工具是一个 32KB 的单页应用，没有后端。画布基于 <canvas> 实现，表会被光栅化成缓存位图，配合视口裁剪，即使上百张表也能保持流畅。作者尝试过 Rust/WASM 版本，但 JS 与 WASM 的边界开销使解析器反而慢了约 37%，最终选择了纯 JavaScript。
SQL 解析器会跟踪每个 token 的源位置，双击重命名表时只修改标识符及其引用，不会动注释和格式。整个 schema 可序列化进 URL 完成分享。
HN 用户普遍称赞移动端体验顺滑，有人给出“100/10”的评价。关于“ER 图”与“表关系图”的命名之争，有人指出实体和表不是一回事，单靠 DDL 不足以还原完整实体关系模型；反驳意见则认为 ORM 的根基本就是表和实体的高度互换性，工具的实际价值不受影响。
大语言模型的上下文窗口动辄宣称上百万 token，但实际可用部分远小于广告数字。作者把 LLM 的上下文分成“聪明区”和“笨区”，分界线大约在 100k token 附近，与厂商标注的窗口大小无关。
编码 agent 读取几个文件、一次长调试会话、一轮大规模测试，一个上午就能烧到 100k。虽然 Claude Code 等工具引入了自动压缩机制，但压缩本身由已退化的模型生成，触发时往往已在笨区浪费了一段时间。
有人通过递归调用避免上下文膨胀：一切工具调用都在子 agent 中执行，根会话只保留用户主对话，内部即便烧掉 5000 万 token，根会话也不超过 100k。另一种方法是结构化文档驱动：要求 agent 先写产品需求文档，每个功能有独立会话和文档存档。
不过也有用户报告在 500k 至 800k 的上下文中模型表现依然锐利，认为退化更可能与上下文质量有关——窗口中充斥错误信息和嘈杂日志时，即便 token 数不大也会让模型变笨。
作者因为觉得原版 Pac-Man 里的鬼魂有点可怜，做了一款扮演鬼魂去抓 AI 控制的 Pac-Man 的小游戏。吃能量豆后几秒内角色互换，鬼魂要逃命。
2003 年宫本茂设计的 GameCube 游戏 Pac-Man Vs. 就实现过类似的不对称玩法。这款小游戏的主要槽点是控制：移动端滑动有滞后，桌面端键盘似乎只在弹起时检测输入，导致转角处手感迟钝。代码由 Claude 在单次提交中生成，缺少原版鬼魂的掉头和差异化 AI 行为。
也有玩家觉得概念有趣，熟悉后能玩，作者做的小游戏能引发讨论本身也算一种成功。
Free Oberon 是一个跨平台的 Oberon 语言集成开发环境，采用类似 Turbo Pascal 的蓝屏伪图形界面。Oberon 是 Pascal 和 Modula-2 的后代，语法更简洁、类型系统更强。
社区中不少开发者回忆起 Turbo Pascal “配上内联汇编是巅峰”的年代，编译快、可执行文件小、运行效率高。Oberon 的大写关键字设计源于 8 位字符集时代，一些衍生版本已改用小写。项目网站使用苏联议会图像引发了一些偏离技术的讨论，但多数人仍关注 Oberon 本身：它代表了一种小而强的系统编程方式，与 Go、Zig 等现代语言的设计思想有相通之处。
开发 28 年的开源 Windows 兼容操作系统 ReactOS 在搭载 Core i5 2400 和 GeForce 8400GS 的 Dell OptiPlex 上成功运行了经典游戏《半条命》。
ReactOS 的独特之处在于直接调用 Windows 驱动栈，能兼容 NVIDIA 等专有驱动，对工业控制领域的遗留系统对接有价值。但兼容性也带来副作用：WannaCry 曾在 2025 年成功运行于 ReactOS，大部分恶意软件因内存布局差异会崩溃。
Wine 在 Linux 用户态翻译 Windows API，而 ReactOS 是完整操作系统——这意味着它可能重现 Windows 的某些 bug，因为不少遗留应用就依赖那些 bug。有人吐槽 28 年开发已进入“圣家堂”式工期，更多人认为对于数字主权和遗产软件维护，它仍有独特价值。
作者花费 120 美元买了一台 IBM 1U 机架式控制台，将其 DIY 改造成集成串口与 VGA 的便携终端。
原装键盘是 USB 复合设备，但选用的 Tattler Solutions VT100 迷你终端不支持复合 HID，只能换用 20 美元的 Perixx 键盘。改造涉及硅烷金属胶固定垫片（固化等了整整一周）、Flexseal 胶带加固、Z 形支架重新安装以解决屏幕闭合问题。
最终装入迷你电源条和手动 USB/VGA 切换盒，实现两种工作模式：接入 VT100 终端盒，或对外直连恢复原机功能。作者用这台终端成功连接了 POWER9 架构的 Raptor Blackbird 和 AT&T 3B2/310 工作站。
Python 3.14.0 引入增量垃圾收集器以降低最大停顿时间，但用户报告内存使用大幅上升后，团队在 3.14.5 中回退了改动。
Python 对象通过引用计数管理内存，引用循环需要 GC 介入。3.14.0 之前的 GC 是经典分代收集，大堆场景下会出现长暂停。增量 GC 将老年代合并，每次只扫描一部分，停顿时间显著降低，但代价是内存释放变慢。在包含循环引用对象的测试中，增量 GC 内存使用飙升至 2,849MB，而传统 GC 只有 717MB。
社区指出，GC 的时间与空间权衡是根本性的。Python 团队没有提供切换选项，也没有走正式 PEP 流程。但也有评论认为先回退再研究改进方案是正常的 incident response。
Phoenix LiveView 1.2 正式发布，核心更新是 Colocated CSS：在 HEEx 模板中使用 <style :type={MyApp.ColocatedCSS}> 标签，编译时提取到专属文件夹，由 Tailwind 等工具处理。
LiveView 利用现代 CSS 的 @scope 规则限定组件样式，但浏览器尚未广泛支持，因此 1.2 默认不启用作用域，而是开放 @behaviour 接口让开发者自行实现策略。
多位开发者提到，Elixir 的 BEAM 虚拟机让应用天生具备高并发和容错能力，且这些能力是底层的一部分。有开发者认为 LiveView 与 LLM 配合极好：语言简洁、前后端不分离减少了 token 消耗。关于 Colocated CSS/JS，部分人担心代码混乱，也有用户认为将相关 hook 和样式放在一起更清晰。
Tribblix 由 Peter Tribble 个人维护约 15 年，基于 illumos（OpenSolaris 的开源后继），融合复古风格与现代组件。
作者称使用传统 SVR4 打包系统而非 IPS 是一种“内部玩笑”，强调老技术更小、更快、更可靠。最初创建是因为 OpenSolaris 时代缺乏构建文档，他想理解系统如何构建，发现可以做得更好。
社区反馈显示，Tribblix 在 SPARC 和 Intel 平台上安装顺利。用户在 Thinkpad T60 上选择“kitchen-sink”选项安装了 Xfce 桌面环境，内含多种现代应用。但也有人反映在 AM5 主板上无法启动，可能是 USB 3.0 兼容性问题。除了默认 Xfce，还支持 Open Look 和 CDE 作为可选桌面。
女：Hello 大家好，欢迎收听 Agili 的 Hacker Podcast，我是莓莓。
男：大家好，我是阿迪。
女：这期节目咱们想先从一个特别有“地下修车铺”气质的安全研究开始聊。阿迪，你听说了吗？有人把本田思域的车机系统给逆向出来了，还发现了一个挺离谱的漏洞。
男：听说了，这个事也挺幽默的。简单来说，一个安全研究者，我们叫他研究员吧，他对 2021 款的本田思域车机做了逆向工程。他发现这个车机接受系统更新，也就是 OTA 更新包的时候，验证签名用的不是什么本田自己的保密密钥，而是 Android 开源项目，也就是 AOSP，提供给开发者公开测试用的密钥。
女：等等，你是说他们给车主推系统更新，就跟我们平时拿个公开的测试签名来糊弄一下？这听起来就像一个公寓楼，所有住户的门锁用的都是出厂时包装盒里那把谁都有的通用钥匙。
男：对，就是这么个意思。研究员把这个攻击方式取名叫“EvilValet”，邪恶代客泊车。也就是说，只要有个人能摸到你车里的 USB 口，比如代客泊车的小哥，或者你把车借给朋友，他就可以很轻松地刷入一个自己做的“更新包”，拿到车机系统的最高权限。他甚至把生成这种恶意更新包的工具，叫 ota-builder，都放到了 GitHub 上。
女：这个物理接触的门槛，感觉说高不高说低不低。评论里也有人觉得嘛，如果真想搞破坏，直接扔个 GPS 追踪器在车里不是更省事？
男：确实是，也有人从这个角度质疑威胁的严重性。不过另一个场景就更有说服力：租车。你想啊，租车的人完全有物理接触，攻击者可以把恶意软件种在车机上，然后等着你用 Apple CarPlay 或者 Android Auto 把手机连上去。这时车机就可以作为一个跳板，去攻击你的手机，这路径就通了。
女：这也太有心了。那我还挺好奇这位研究者的工作方法，听说他连传统的文档都不大乐意写了？
男：对，这哥们儿有个挺有意思的理念。他说不再费劲去写那种解释代码怎么工作的长篇文档了。因为他觉得代码本身才是唯一的事实来源，维护文档特别容易和代码脱节。他的新方法是，写个小工具，把车机里那些晦涩的代码翻译成一种中间形式，让代码更好读，然后再靠大语言模型，也就是 LLM，去帮他理解和查询这些代码。
女：嗯，这个话题在程序员圈子里永远能吵起来。我自己写PRD的时候也这种感觉，文档改来改去，最后自己也忘了哪个是最终版。评论区里我好像看到有人更推荐用单元测试来当文档？
男：没错，有一种很受推崇的观点是“单元测试即文档”。因为测试是实实在在会跑、会报错的，它能持续验证系统行为，也明确给出了代码的预期用法和边界情况。这比一段没人看的注释要可靠得多。
女：更有意思的是评论区一句特别损的总结，大概意思是，本田造车一流，但写软件的功力嘛，实在是有点拖后腿。这其实挺矛盾的，对吧？如果一个车厂把系统锁得死死的，什么都不让用户碰，会被人骂“技术法西斯”；但如果像本田这样，留了这么一个天大的后门，又会被疯狂吐槽有安全漏洞。车企好像怎么做都不对？
男：这真是一个经典的困境，安全和开放的天平。不过话说回来，用公开测试密钥这事儿，在任何正规的软件开发流程里都是属于低级错误，不能算是“为用户开放”的初衷，纯粹就是图省事儿。你看有评论提到，现代汽车以前也犯过类似的错，他们用的密钥甚至可以直接在谷歌上搜“RSA key”就能找到。
女：好吧，这个神奇的疏忽我们先聊到这儿。说到开发者的“省心”和“纠结”，我还看到一个工具，刚好能体现另一种极致。它是一个把 SQL 建表语句直接变成漂亮关系图的网页工具，叫什么 “SQL to ER Diagram”。
男：对，这工具特别纯粹，让你感受一下什么叫“简单美的暴力”。它的作者 robhati 自己经常需要快速看清楚一个数据库的结构，但市面上的工具要么贵，要么逼着你注册，要么就得把 SQL 语句上传到别人的服务器上。他很烦这个，就自己写了一个。
女：也就是说，我只要把那个 CREATE TABLE 的 SQL 语句往里面一粘贴，浏览器里马上就能生成一张可以拖来拖去的实体关系图？
男：是的，而且数据完全不出你的电脑，免费还开源。它整个就是一个纯前端的单页应用，没有后端。让人感觉很舒服的一点是，它的 SQL 解析器很聪明。如果你在图上双击一个表名想改名字，它只会精确地修改那个标识符和所有引用了它的地方，而不会破坏你 SQL 里的注释和格式。
女：这种对细节的较真确实会让人用着很舒服。我看评论里都在疯狂夸它在手机上的体验，有个用户留言说流畅到让他“以为自己磕了药”。
男：哈哈，那个评价我记得，是 written-beyond 说的，给了个 100/10 的分数。之所以这么顺滑，是因为作者在技术上下了功夫。它用 Canvas 来画图，把每个表都提前渲染成一个缓存的位图。这样不管你画布上有多少张表，它只需要在屏幕能看到的那个小区域里计算，不需要每次都重新渲染几百个对象。这也是纯 JavaScript 的威力，作者说他甚至试过用 Rust 写一个版本放进浏览器，但反而慢了 37%。
女：这好像跟我们以前聊过的很多项目一样，有时候引入所谓的高性能技术反而会带来额外的沟通成本。对了，关于这个工具的命名，好像还有一场小型哲学辩论？
男：没错，有个用户 michaelmior 指出来，严格来说，SQL 建表语句生成的是“表关系图”，而不是正宗的“ER 图”——也就是实体关系图。因为“实体”和“表”在设计理念上是两个层面的东西。不过马上又有人反驳，说如果我们的目标就是直观地看下数据表之间的关系和字段，那 DDL 语句已经足够了。毕竟现在所有 ORM 框架的根基，就是建立在表和实体可以高度互换这个假设上的。开发者们用脚投票，这个工具的价值不受影响。
女：从关系到实体，这让我想到最近 AI 编程工具里一个聊得很热的词：上下文窗口。现在大模型厂商都说自己的上下文窗口有上百万 token，但最近我看到一个说法，把这窗口分成了“聪明区”和“笨区”，听起来就很形象。
男：对，这个概念作者是从一个视频里引用的。他觉得 LLM 的表现，并不是一整段上下文都均匀地好。前面一小块，大概前 10 万 token，是所谓的“聪明区”，模型反应敏锐，记忆力好。一旦过了这个分界线，就滑进“笨区”了，注意力开始衰减，模型甚至会忘记你前五分钟才跟它说过的事情。而且这个分界线跟厂家宣传的 100 万、200 万窗口大小关系不大。
女：10 万 token听起来挺多，但对于一个正在吭哧吭哧写代码的 AI 智能体来说，是不是很快就烧没了？
男：太快了。你让一个编程智能体去读几个源码文件，再来次比较长的调试会话，比如追踪复杂的 bug，再跑一遍大范围的测试，一上午时间轻松就能烧到 10 万 token。然后你就发现，它开始犯低级错误了。
女：那怎么办？现在的工具没有应对办法吗？
男：有，比如现在一些编程工具引入了自动压缩功能。当会话变长，它会用模型自己生成一个当前进度的摘要，然后清空历史，基于摘要开启一个新会话。但这恰好有个悖论——执行压缩的时候，模型本身可能就已经在“笨区”里了，用一个变笨的模型去总结你的工作，那摘要的质量可想而知。
女：这就像让一个已经开始犯困的同事，在交接工作前凭印象给你写个备忘录，想想就可怕。那文章作者自己是怎么解决的？
男：他的方法是手动、有意识地管理上下文。比如，他会主动开一个新的会话，然后把自己精心编写的规格说明文档传给它。自己写的好处是，你知道哪些信息是关键的，信号比任何自动摘要都强。他管这叫“面包屑方法”——每完成一个阶段，就留下一个清晰、干净的工件，让下一轮会话或者下一个人能无缝接手。
女：也就是更像一个产品经理拆分需求的做法了。甚至有人把这种思路文档化了，要求 AI 先写产品需求文档，每个功能都有独立的会话和文档存档？
男：对，这已经是种比较成熟的实践了。要求 AI 像产品经理一样，先输出 PRD，每个功能一个会话，用文档来“传承”决策和背景。还有更极客的做法，比如用“递归调用”。把所有真正干活、会消耗大量上下文的操作，都派给子智能体在后台完成。主会话只保持跟用户的聊天，干干净净。
女：这听起来就像一个指挥官，只掌握战略全局，战术细节全让下面的参谋去沙盘推演，推演完了只回来汇报结果。不过好像也有很多人不同意“笨区”这个说法？
男：分化很大。有人就说，我用某些模型在 70 万、80 万 token 的负载下，感觉依然很锐利，没发现变笨。所以有一种观点觉得，让模型变笨的可能不是长度，而是上下文的“质量”。如果上下文里充满了前后矛盾的指令、错误的报错信息、嘈杂的调试日志，就像一锅好汤里混进了不干净的东西，整锅汤很快就坏了，不如重新熬一锅。这么看来，比物理长度更重要的，是我们怎么维护这锅汤的纯净。
女：这个比喻真好。好，从 AI 的上下文中跳出来，我们聊点轻松的。你玩过吃豆人吗？有个开发者可能觉得里面的幽灵挺可怜的，决定自己做个游戏，让玩家反过来扮演幽灵，去抓那个 AI 控制的吃豆人。
男：对对，这个想法其实挺经典的，不算全新。评论里很多人立刻就想到了 2003 年任天堂宫本茂设计的 GameCube 游戏《Pac-Man Vs.》，也是一个玩家当吃豆人，其他几个玩家当幽灵，是一种不对称的对抗。
女：不过这个小游戏的体验好像……算不上丝滑？我看到很多吐槽它的控制。
男：控制是最大的败笔。在手机上玩需要滑动屏幕，但有明显的延迟，你想在拐角处及时转向很难。用键盘呢，据说程序只有在弹起按键时才会检测输入，而不是按下去的瞬间。这就是典型的手感问题，对动作游戏来说是致命的。而且代码是作者用 AI 一次性生成的，很多原版幽灵的细节都没了，比如四种幽灵的不同追踪模式，吃豆人吃了能量豆后变幽灵的还原等等。
女：一个简单的策略就能赢：一直追着 AI 吃豆人的循环路径跑，利用速度优势就直接抓了，AI 还不太爱去吃能量豆。不过这种不完美的小项目，能引来这么多人讨论，本身也挺好玩的。大家七嘴八舌地提建议、怀念类似的游戏，也是一种社区氛围。
男：没错，这就像一种数字时代的“放学后的小游戏”，讨论它的过程比游戏本身更生动。这种纯粹因为兴趣而诞生的项目，我们节目中聊到过不少。另一个让我很有感触的项目，是一个叫 Free Oberon 的编程语言集成开发环境。
女：Oberon？这个名字听起来很复古，像是来自 Borland Turbo Pascal 那个年代的。
男：你的直觉真准，Oberon 就是 Pascal 和 Modula-2 的直系后代，设计上更简洁强大一些。这个 Free Oberon IDE，打开就是经典的蓝色伪图形界面，活脱脱一个 90 年代初的 Turbo Pascal。有好多老开发者就在评论里回忆青春，说那时候 Turbo Pascal 配上内联汇编就是巅峰，编译快，运行快，生成的程序又小。
女：那用一个这么，嗯，带有强烈时代烙印的语法和环境来编程，在今天除了情怀，还有什么实际价值吗？
男：有一些开发者认为，Oberon 本身代表了一种小而强大、易于理解的系统编程哲学。它不像现代语言那么庞杂，一个人可以理解它的全部。这种思想跟现在的 Go、Zig 语言是有共通之处的。这不仅仅是怀旧，更是一种编程品味的延续。不过嘛，这个项目因为其界面和网站上用了带有浓厚旧时代烙印的元素，在社区里也引起了一些和编程无关的争论。
女：哈哈，技术社区总会有些奇妙的关注点。那我们再来看一个同样需要长时间打磨的项目，我听说 ReactOS 最近成功在一个真实的硬件上运行了《半条命》？
男：是的。ReactOS 这个开源操作系统项目，目标很宏大，就是做一个能完全二进制兼容 Windows 程序和驱动的系统。他们搞了 28 年，最近终于在一台老旧的戴尔台式机上，用 NVIDIA 独显，成功跑起了经典射击游戏《半条命》。
女：28 年！评论区是不是又有人拿圣家堂来类比它的工期了？
男：哈哈，对，但调侃归调侃，它的独特价值是公认的。很多人会说，在 Linux 上用 Wine 也能流畅运行《半条命》啊。但 ReactOS 的独特在于，它不是在一个翻译层上运行，而是在内核和驱动层面直接兼容 Windows。这意味着，它能直接用 NVIDIA 官方的 Windows 显卡驱动，而不是把游戏指令翻译一遍。对于一些只有 Windows 驱动的老旧工业控制设备、特殊硬件来说，这可能就是唯一能让它们在现代系统上继续工作的希望。
女：听你这么一说，感觉 ReactOS 更像是在搭一座桥，让那些被遗留在技术孤岛上的老软件和老硬件，能重新和现代世界连接起来。而不是为了替代我们日常用的 Windows。
男：对。而且在这个过程中，ReactOS 为了追求极致的二进制兼容性，有时候甚至需要去重现 Windows 的某些 bug，因为一些老软件就是依赖那些 bug 才能正常运行。当然，这种兼容性是双刃剑，它也可能让一些 Windows 的病毒本来跑不起来，结果在 ReactOS 上跑起来了。不过因为底层的内存布局和权限模型有差异，多数恶意软件还是会直接崩溃。
女：说到搭建桥梁，我们再来看一个更硬核的物理搭建。有人花 120 美元在 eBay 上买了一台 IBM 旧服务器用的机架式键盘显示器，然后自己动手 D 出了一台便携的复古终端。
男：这个改造过程听着就是一波三折。作者想做一个能连接老式串口和 VGA 接口的便携小终端。那个 IBM 的键盘本来是集成了触摸板和指点杆的“复合设备”，但他买的那个小终端模拟器太古老，识别不了，只好换了个 20 美元的普通键盘。然后改装时用了很多“民间智慧”——因为托盘不匹配，他用了一种叫做硅烷金属胶的东西粘固定的垫片，但是胶水要固化整整一周才够结实。
女：等一周也太有耐心了。他还装了好几个手动 USB 和 VGA 的切换盒，设计了两路模式，一路连接内部的小终端，一路恢复原机功能，把线路全部整理后，最后成功点亮了一台基于 IBM POWER9 架构的服务器和一台远古的 AT&T 工作站，那种感觉一定很神奇。
男：这就像是一个可以穿越时间的万能工具箱。评论里有人就说，其实用一个树莓派可以更优雅地实现全部功能，但作者享受的可能就是这种“用老硬件拼凑出新感觉”的过程吧。把所有东西用魔术贴、钩子固定好，完美地契合了那种黑客动手精神。
女：感觉这期节目我们也像在不同项目的时间线里来回穿梭。最后我们来聊两个更贴近日常开发者工作流的新闻。一个是 Python 3.14 的一个重要功能回退，另一个是 Web 框架 Phoenix LiveView 的新版本。先说 Python 吧，好像是关于垃圾回收的新功能被砍了？
男：对。Python 3.14.0 版引入了一个新的“增量式垃圾收集器”。简单说，Python 在管理内存时，需要不时地回收那些不再使用的对象，这个回收过程叫 GC。以前每次回收可能会导致程序卡顿一下。这个新的增量 GC 就是想把一次大卡顿分摊成很多次看不见的小卡顿，理论上能让程序跑得更顺滑。
女：听起来是个好改进，为什么又回滚了呢？
男：因为代价是更高的内存占用。这个新 GC 的策略是，为了保证不卡顿，它会“偷懒”，不那么勤快地回收内存。结果就是，在某些会持续产生垃圾的程序里，尤其是那些包含复杂循环引用的程序，内存使用量会飙升。文章里的测试表明，在一个极端场景下，增量 GC 的内存占用达到了将近 3GB，而老方法只要 700MB。这增加的 2GB 多内存，对于服务器来说可能就是被系统 OOM Killer 杀死的风险。
女：这又是一个典型的“鱼与熊掌”的权衡：要更短的暂停时间，就得接受更高的内存消耗。Python 团队直接回退，没有给用户一个开关选择，这是被吐槽最多的地方吧？
男：对，像 Java 或者 Go 语言，通常会提供好几种不同的 GC 策略让你根据场景选。Python 这次直接一刀切回退了，也没有走一个正式的提案流程。虽然有人理解这是一种应急响应——先恢复到稳定状态，再慢慢研究更好的方案——但很多人觉得直接去掉选择权不太合适。这也反映出 Python 在面对内存管理和版本兼容这些复杂工程问题时的一些长期挑战。
女：这个感觉跟刚才聊的车机系统有点像，一个想打开但没做好的更新通道。好了，最后我们来看看 Phoenix LiveView 1.2 的发布。阿迪，这个版本最大的亮点是不是那个“同地 CSS”特性？
男：“Colocated CSS”，对，这绝对是核心。就是可以在写组件的模板文件里，直接写一个 <style> 标签，把这个组件的样式、HTML 和业务逻辑写在同一个文件里。这能让开发者更容易理解和维护组件，不用在文件树里到处翻样式表。
女：但一个页面里如果到处都散落着 <style> 标签，最后生成的 HTML 不会很乱或者互相打架吗？
男：好问题。Elixir 团队的想法是借助现代 CSS 的 @scope 规则，自动给每个组件的样式加一个独立的作用域，这样 A 组件的样式就不会意外地影响到 B 组件。不过问题在于，这个 @scope 规则在浏览器端还没普及，所以 1.2 版本默认不发这个功，只是留了一个接口，让愿意尝鲜的开发者可以自己去实现和启用。
女：又是这种“把未来的钥匙交给你，用不用看你”的玩法。我注意到社区有个很有意思的声音，说 Elixir 和 LiveView 这个前后端一体的模型，特别适合用 AI 来写代码。
男：这也是社区里一片叫好的点。因为 Elixir 语言本身很简洁，不需要维护一个独立的 JavaScript 前端项目。对于大语言模型来说，要理解的上下文就少了一大块，token 消耗也少了，出错的概率更低。有开发者甚至说，用 AI 写 Elixir 的感觉，比用 Python 或 Django 爽快得多，因为编译和反馈都特别快，没有前端后端的割裂感。
女：好了，那我们这期节目聊得也够久了，从破解车机，到画数据库美图，从管理 AI 的“笨区”，到 Python 的内存雷区，最后还玩了把复古游戏和硬核终端。谢谢阿迪，也谢谢大家的收听。
男：谢谢大家。
女：最后提醒一下，如果你喜欢我们的节目，别忘了在泛用型播客客户端里搜索订阅“Agili 的 Hacker Podcast”，这样就不会错过之后的更新啦。我们下期再见！
男：拜拜。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。