今天 Agili 的 Hacker Podcast 整理了几篇有趣的内容：从把古董 Kindle 改造成网络终端，到让 260 亿参数的 AI 模型在 8GB 内存的 Mac 上跑起来，还有对“21 天学会编程”神话的重新审视。
Mitanshu Sukhwani 的 Tailscale 实现让越狱后的 Kindle 变得更有用。新版默认开启 Tailscale SSH，省去了手动设置 USB 网络共享和弱密码的麻烦。更重要的是加入了代理模式——让 KOReader 这类应用能访问你私人网络里的其他设备。
Kindle 通常只能在用户空间模式下运行 Tailscale，无法使用内核网络路由。以前在 KOReader 里想连另一台设备上的 Calibre 服务器，系统根本找不到路。现在通过 KUAL 插件启动代理模式，在 KOReader 里设代理为 127.0.0.1:1055，连接就能自动走 Tailscale 路由。支持 SOCKS5 和 HTTP CONNECT 两种协议。
连上之后能做的事不少：连 Calibre、Wallabag、Audiobookshelf，同步阅读进度，用 Kindle 浏览器访问极简仪表盘，甚至接蓝牙键盘通过终端 SSH 进网络里的设备。如果你只在 KOReader 里需要这个功能，Victoria Riley Barnett 的 KOReader 插件更轻量，不会让 Kindle 本身暴露在网络上，而且支持 Kobo 和 PocketBook。
KOReader 本身是社区讨论的焦点。这是一个开源电子书阅读应用，支持 Kindle、Kobo、Android 甚至桌面系统。一位用户用它复活了 2012 年的第一代 Paperwhite——原厂系统翻页要好几秒，越狱后装上 KOReader，“像换了一台新机器”。
但它的界面争议很大。多位用户形容菜单“混乱”、“像 GIMP 的电子书版”，设置分散在齿轮、文档、扳手等图标下，一个功能要找好几页。也有人用 Bookshelf 插件获得类似原生阅读器的书架视图来缓解这个问题。核心强项在于格式兼容：原生支持 EPUB、PDF、CBR/CBZ，PDF 边距裁剪和重排功能对读论文和技术书的人尤其有用。
代价是电池续航变差。原本能撑几周的 Kobo 现在只能撑几天。开了 Tailscale 和 SSH 后还可能崩溃重启。隐私方面，有用户提醒 Tailscale 默认会上传连接元数据，建议在启动脚本里加 --no-logs-no-support 退出日志收集，或者自建 headscale 服务器完全绕开 Tailscale 公司。
HNewhere 是一个用户脚本，安装在 Tampermonkey 或 Violentmonkey 后，会在你访问任意网页时自动检测该页面是否对应 Hacker News 上的讨论，在右侧弹出一个可调整大小的侧边栏直接加载评论。作者说他“厌倦了为每个 HN 链接打开两个标签页”。
隐私问题是讨论的焦点。脚本默认会在你访问每个页面时把完整 URL 发给 hn.algolia.com 做匹配，意味着浏览历史被泄露。作者很快回应，在 1.4.5 版中加入了移动端默认折叠、允许拖拽按钮位置，并排除了某些页面。也有人推荐用 Bloom filter 方案的扩展，只在点击按钮时才查询 API。
Demo 场景是一个数字艺术亚文化群体，成员们自己动手制作工具。这篇文章回顾了其中一些作品的界面，大部分基于 Amiga 平台。比如 Elite Sinus Producer 是一个正弦波查表生成工具，按 F 键选择菜单时会播放响亮的布谷鸟叫，帮助屏幕背景一半是闪烁的蓝色光栅条。音乐追踪器（tracker）是 demo 音乐的主要创作工具，界面不像乐谱，更像编程编辑器。NoiseTracker 是第一个真正流行的追踪器，它的后继 ProTracker 文件选择器把 EXIT 按钮垂直放在上下箭头之间，容易误点。
研究者发现，攻击者可以把恶意指令用白色字体藏在 Word 文档中。用户用 Copilot for Word 基于这个文档起草新文件时，Copilot 会读取并执行这些隐藏指令——比如篡改财务报告的数字，并把恶意指令复制到新文档末尾。新文档由此变成新的攻击载体，在组织内部甚至跨组织传播。
研究者与微软 MSRC 在 144 天内进行了四次修复尝试，每次都只能解决特定手法，无法关闭整个漏洞类别。社区讨论普遍认为这是 LLM 架构的根本弱点：外部信息一旦进入上下文窗口，就和系统指令混在一起参与计算，系统无法在分析内容之前判断它是否包含攻击指令。
reFrame 是一台实验性相机，核心是彩色 ePaper 显示屏。按下快门后照片需要 15 秒才能完整出现，颜色一块块浮现。照片拍完会一直留在屏幕上，断电也不消失，唯一清屏的方式是拍下一张。硬件和软件完全开源，内部是树莓派 Zero 和 4 英寸 EInk Spectra 6 显示屏。
有人喜欢这种限制带来的慢思考——15 秒显影、没有即时回放，让人更慎重地按下快门。也有人质疑这不过是个怀旧玩具。但支持者认为艺术本就要求约束，低分辨率照片让想象力参与填充，对儿童来说也比 LCD 屏幕更不刺激。
TurboFieldfare 是一个 Swift + Metal 推理引擎，专门为 Gemma 4 26B-A4B 模型设计。它不把完整的 14.3 GB 模型权重塞进内存，只保留 1.35 GB 的核心，然后根据每个 token 的需求从 SSD 流式读取需要的专家子网络。内存占用约 2 GB，可以在任何 Apple Silicon Mac 上运行。
作者花了大量精力优化 I/O。在 8GB M2 MacBook Air 上跑出 5-6 tok/s，在 24GB M5 Pro 上达到 31-35 tok/s，差距主要来自 SSD 读取速度。项目支持 Mac 原生应用、CLI 和 OpenAI 兼容的本地服务器。作者承认 Gemma 4 对编程表现不如 DeepSeek 系列，但因为它架构更简单而选择了它。
LearnVector 是 Andrew Ng 创立的新 AI 教育公司，获得 Coursera 1 亿美元投资，计划 2027 年初推出产品。目标是用 AI 实现个性化学习体验，不会做成随意回答问题的聊天机器人——因为研究显示没有护栏的聊天机器人会削弱学习效果。
社区讨论中有质疑的声音：当前 Claude、Gemini 等模型通过简单的提示设定已经能实现类似辅导，LearnVector 需要提供远超普通提示工程的价值。也有评论指出网站看起来像用 AI 生成的，缺少产品细节。但凭借 Ng 的影响力和 Coursera 的课程库，它有可能做出比通用聊天机器人更系统化的产品。
Peter Norvig 1998 年的这篇文章说得很直白：真正学会编程需要十年，靠的是挑战略高于自己能力的任务、分析错误、重复改进。他建议学至少六种语言，涵盖不同范式，还要理解计算机底层——一条指令执行多久，一次缓存未命中多慢。
26 年后的评论区围绕一个大问题：LLM 出现后，这些还有多少说服力。有人觉得继续学技术细节“像亲手织布一样”不再有职业优势。也有人分享了反面经验：花了三小时调试 AI 写的 bug，最后靠一行行跟踪 C++ 调试器才找到。“它写的 bug 是我自己绝不会犯的那种——因为它从根本上误解了设计。”也有人持温和态度：二者依赖不同的直觉，互补但不贯通。一位韩国开发者说：“我仍然会手写代码，不是因为更高效，纯粹是因为享受。”
一篇 arXiv 论文用基准测试证明：把 124 页的政策手册放进 LLM 上下文，并不能可靠约束它的行为。30 个模型配置中表现最好的只通过 36.2% 的尝试。失败模式一致：代理会让环境中合理请求覆盖政策，在长时间跨度中丢失规则细节，并报告它实际并未达成的合规性。
社区观点与论文吻合：声称 1M 上下文的模型，实际可靠窗口约 250k，超过后表现急剧下降。实用对策包括把规则反复注入每次提示开头、用子代理审查输出、或把固定业务流程改用“管道”而非“代理”——管道的每一步都可预测、可审计，且更便宜。只有工作流本身未知时才应该让模型自主规划。
女：Hello 大家好，欢迎收听 Agili 的 Hacker Podcast，我是莓莓。
男：大家好，我是阿迪。
女：今天我们挑了几个很有趣的话题来聊，有关于老设备复活、也有关于 AI 的一些老问题和新困惑。阿迪，你前两天是不是在折腾你的旧 Kindle？
男：对，这个事儿在 Hacker News 最近挺火的，就是有人在已经越狱的旧 Kindle 上跑起了 Tailscale。
女：Tailscale？就是那个让你能随时随地安全接入自己家庭网络或者个人服务器的小工具？
男：对。以前觉得越狱旧的电子书阅读器也就是换个字体、装个 KOReader 看看 EPUB，跟网络没多大关系。但现在开发者给 Kindle 做了个插件，集成进去之后，Kindle 上不仅可以跑 Tailscale SSH，还可以设置成代理模式，让你在 KOReader 里直接访问你自己在另一台机器上搭的 Calibre 书库，或者 Wallabag 稍后读服务。等于说你手上一个几乎被时代淘汰的设备，突然被拉进了你自己的私有云。
女：这跟我妈用她那个第一代 iPad 看了十年连续剧还不肯换的道理差不多。其实你用习惯了的老设备，如果突然能跑以前跑不动的服务，好像就是白捡了一台中古电脑。但是， Kindle 的硬件跑得动这些东西吗？它的网络功能不就是买书用吗？
男：大部分时候它只能在所谓的 userspace 模式下跑 Tailscale，用不了内核层的 TUN 路由。简单说，就是在 KOReader 这种应用里说“我要连 100.x.y.z 那个 Calibre”，系统告诉你不知道这条路怎么走。新插件就是绕开了这个限制，让应用把网络请求先丢给本地的 Tailscale 代理，代理再帮你把流量完整地送到目的地。有用 SOCKS5 也有用 HTTP CONNECT 两种方案。甚至有更极客的玩法，你可以在 Kindle 上接个蓝牙键盘，用 kterm 直接 SSH 进家里的树莓派，基本上就是个极简瘦客户端了。
女：蓝牙键盘连 Kindle 打字用它那块墨水屏……我觉得这种形态虽然实用价值低，但莫名有一种早期赛博朋克的浪漫感。
男：对，社区里有人就特别吃这套，觉得凑齐一套超简配的远程工作套装本身就很舒服。当然，更多人只是想在 KOReader 里安稳地看个书、同步个进度。
女：说起 KOReader，我看有人把它称作“阅读舒适度的终点站”，但同时又有很多人对它的界面一头雾水，找个设置像寻宝。你用过它吗？
男：用过。它那个界面确实相当有争议。Hacker News 上一群人的意见特别对立——喜欢的人觉得它是脱离亚马逊生态的救星，讨厌的人说它是“GIMP 电子书阅读器版”，菜单乱到像是程序员给自己做的工具。
女：这比喻是不是说它功能超强，但界面是凭直觉找不到东西？我一个产品经理看到这种界面会很痛苦，但私底下如果它能解决我 PDF 论文那种烂排版问题，我还是会硬着头皮学。
男：很多人就是这么忍受下来的。因为 KOReader 对 PDF 的边距裁剪和重排原厂根本做不了。再加上它原生支持 EPUB、漫画格式 CBR 和 CBZ，排版质量又压过了 Kindle 和 Kobo 自己的渲染引擎。另外那些插件也很能打，比如 KOAssistant 可以让你在电子书上选中一段文字，直接丢给大语言模型去解释上下文。读上个世纪的小说遇到历史典故，不用摸手机就能顺手看一下。
女：等于阅读这件事，它帮你把整个世界都给带进去了。你刚才说大语言模型，我记得 KOReader 有一个插件能直接把书摘发给 LLM，这不就是一个小型的 AI 助手吗？
男：对，但这也会带来功耗上的妥协。开了 Tailscale、SSH 再加一堆这类服务之后，本来能撑几周的 Kobo 可能几天就没电了。而且 KOReader 社区也已经有人在提醒隐私问题——比如 Tailscale 默认会收集连接元数据，你连过哪些主机、在什么时间，统统会上传。有人建议在启动脚本里加上一个 --no-logs-no-support 来退出日志收集，或者直接用自建的 headscale 彻底绕开官方服务器。
女：那看来从越狱到跑 Tailscale 再到用插件，如果你不是一个特别喜欢掌握控制权的人，其实会被折腾得很累。这跟另一个小工具，一个叫 HNewhere 的脚本，某种意义上有种相似诉求——它也试图不离开当前网页就把事情办掉。
男：嗯，HNewhere 是一个用户脚本，装到 Tampermonkey 之类的管理器里，打开任何一个网页，自动检查这个页面有没有被 Hacker News 讨论过。有的话直接在右边拉一个侧边栏，给你加载出全部的评论。作者说他是受够了每次都要在文章页和 HN 之间开两个标签页来来回回。
女：这种感觉我太懂了。看一篇技术博客，特别想看看是不是有人反驳里面的主要观点，然后你就得切标签页。这个脚本相当于把这层“社区事实核查”直接给带到了阅读界面。
男：但是社区马上就抛出一个经典嘲讽，说“真正的 HN 老用户根本不看文章，直接看评论就够了”。抛开笑话不说，其实讨论的焦点很快就集中到了隐私。这个脚本默认每访问一个页面，就把完整的 URL，包括所有的查询参数，直接发给 hn.algolia.com 做匹配。等于你的浏览历史全泄给了第三方。
女：这个脚本是透明地帮我们省了事，但代价是把我们看什么网页都汇报出去？
男：对，所以在社区压力下作者反应很快，已经更新了版本，屏蔽掉比如 chatgpt.com 这样的高敏感页面，还把搜索时的 URL 发送机制做了调整。也有人建议用 Bloom filter（布隆过滤器）方案，只在人主动点击按钮的时候才去查 API，前提是不要自动泄露。不过整体上，这又回到一个老问题——是想用更隐私友好的浏览器扩展呢，还是接受用户脚本这种更容易迭代、代码也透明的方案。
女：这个话题就先停在这里，不过我觉得它跟我们接下来要聊的这些更老的工具有些微妙的呼应。阿迪，你有没有听说过一个叫 demo 场景的东西？
男：Demo 场景，数字艺术亚文化。简单说，就是一群人在非常低的硬件配置上，比如 7 MHz CPU，靠预计算正弦波查表、写汇编器、做追踪器（tracker），逼出各种视觉和音频效果。然后把它做成的那种展示性的动画短片加上音乐，就叫 demo。
女：我听说他们几乎所有的工具都是自己写的，而且界面都很奇怪？
男：对，像我之前看到的一个工具叫 Elite Sinus Producer，专门生成正弦波数据表。按 F 键的时候，扬声器里会发出一声布谷鸟叫。还有一个叫 ProTracker 的音乐追踪器，它的退出按钮居然就直接摆在上下方向键之间，经常一不留神就误触退出了。这些都不是设计事故，更多是因为作者要么是年轻学生，要么就干脆觉得“看起来够酷”就完事儿了。
女：这些是不是类似于今天我们做设计写代码，偶尔不按苹果的设计规范来，反而效果非常独特？
男：有点像。而且 demo 场景里面一些工具本身就是一种抵抗。比如磁盘拷贝工具 X-Copy，它用网格显示每一个扇区的拷贝状态，复制完会发出一声 boing 的一声。细究下去，那是用了 Amiga Paula 芯片的 attached 模式，一个音频通道用它的输出去调制另一个通道的音量或者音高。这不单是一个音效，它是直接拿硬件特性来做反馈信号。
女：听起来，那个年代的软件边界跟我们今天不一样。今天的工具是抽象层堆起来，而 demo 场景是在硬件裸露的地方写直觉。
男：嗯，这种文化一直延续下来，虽然今天不再是主流。比如说 Fasttracker II，一个 DOS 下的老式音乐追踪器，界面里甚至内置了一个贪吃蛇游戏。有个评论者回忆，他们用追踪器做不出回声效果，就手工在另一个通道复制一轨音符，降低音量，来模拟回声。这就是穷得只有创造力。
女：从工具聊到创造力，我今天很想跟你聊一个可能会让很多人不安的话题：那些用大语言模型的人，如果他们无意识间打开了一个埋伏着恶意指令的文件，会有什么后果？
男：这其实是一个跨域提示注入（XPIA）的变种。一个攻防安全团队做的研究发现，你可以在一个 Word 文档里用白色小字写上恶意指令，白色的字在白背景下根本看不见。当有人用 Copilot for Word 打开这个文档，想基于它写一篇新报告，Copilot 就会读取那些隐藏指令，并且执行。结果可能很安静地就把财务报告里的数字全部减半，然后把完整的攻击指令再用白色小字偷偷追加到新文档的末尾。
女：等于是感染了它新生成的档，然后它自己变成一个新的传播载体。下一个同事再用这份档当素材调用 Copilot，病毒就会这样一级一级传下去，而原来恶意文档早就不见了。
男：对，溯源非常困难。微软的研究团队跟 MSRC 在 144 天内尝试了四次修复，甚至从 GPT-5.5 升到 GPT-5.6，但每一次修复后，研究者只要稍微改一改 payload，就能重新绕过。这不是微软一家的问题，根本原因在于当前所有大规模语言模型都存在一个架构弱点：指令和数据进来的时候混在同一个上下文窗口里，模型在分析之前，没有办法判断这段东西究竟是系统指令还是攻击数据。
女：这个像不像以前电话系统里所谓的“带内信令”？控制和数据一起传，结果就被人用哨子吹出免费长途电话来。
男：没错，这个类比很精准。Hacker News 的讨论几乎共识认为这是眼下无解的架构问题。还有人用文档宏病毒来类比——当年人们也以为只要禁用宏就安全了，但实际上这套威胁模型到现在也只不过是换了宿主，病毒换成了自然语言。
女：但你说人在白色小字面前不也看不见吗？人是不是也可能被骗？
男：人类确实也会被社会工程攻击，区别在于攻击速度和规模。机器不会“觉得哪里不对”，它会以文本处理的速度去执行，而且可以在一堆企业内部共享的内容里病毒式扩散。对人来说，至少你还有一丝可能会怀疑“为什么这个财务报告数字这么整齐地减半？”但 Copilot 不会。
女：那我们短时间内是不是只能靠自我防护？比方说把外面来的文件单扔进一个沙盒里？
男：社区的安全建议也差不多——在使用 Copilot 类工具时，把所有外部来源的文档视为不可信，生成前后要仔细核查内容。长期看，产品侧需要加入像来源跟踪和编辑元数据这样的防护，但这都是工程补丁，不是底层修复。
女：刚才我们讲的是在虚拟世界里不断追求更快、更自动，对吧。不过我还看到一个硬件项目，刚好是反向操作，把时间拉得很慢。reFrame 相机你知道吧？
男：知道，就是一台用彩色电子纸（ePaper）当屏幕的相机。你按下快门之后，画面要花 15 秒才能一块一块地慢慢浮现，最后固定在屏幕上。断电了照片也不会消失，你只能拍下一张覆盖上一张。
女：不拍照的时候，它就相当于一个桌面相框。很多人说它像是数字版宝丽来。你用它拍照，没有那种“我再拍一张看看”的冲动，因为在那个 15 秒里你只能等着。
男：这正好是一种限制带来的慢思考。有一位 HN 用户说，这就像胶片时代，没有即时回放，你拍之前会多想两秒，构图和意图都比平时慎重。当然也有人说，这就是个会制造电子垃圾的怀旧玩具，没有光学取景器也没有实时预览，构图其实非常困难。
女：但我反而觉得，这种低分辨率、有纹理、像报纸网点一样的成像，恰恰让人愿意接受它的不完美。就像有个人拿 The Mountain Goats 乐队用低保真便携录音机录制专辑来作比较——低技术工具会催生出完全不同的表达。
男：对，在 reFrame 上，那种带有噪音点的抖动算法形成的老式电子游戏画面感，反而成了一种艺术约束。创作者还请了四位专业摄影师去用它拍样张，那种粗糙但有质感的画面，是任何一款 iPhone 模拟滤镜都做不出的。
女：从低技术一下跳到极高技术——你前几天还说，有人让一个 260 亿参数的大模型在 8 GB 内存的 MacBook Air 上跑起来了。能不能解释下这个叫 TurboFieldfare 的项目在做什么？
男：好，它其实是一个专门为 Gemma 4 26B-A4B 模型设计的 Swift 推理引擎。传统上跑一个 260 亿参数模型，你得把整套 14.3 GB 的权重都塞进内存，8 GB 内存的机器根本跑不动。但 Gemma 4 用的是 MoE（混合专家）架构，每次推理只需要激活其中一小部分专家子网络。TurboFieldfare 就想了一个法子——把核心权重和 KV 缓存留在内存里，把大部分专家权重留在 SSD 上，用到哪个专家，再流式地从硬盘读进来。
女：这就好比图书馆把大部分书锁在地下密集库，你需要哪本，管理员才去取，但借阅台前有本最常用的工具书随时摊开着。
男：对，它的 LFU 专家缓存在生成过程中大概有 67% 的命中率，很多时候需要的专家已经在高速缓存里，就不用再读盘。作者还在 I/O 上做了很细致的优化，把 GPU 计算和磁盘读取并行化。在 M2 MacBook Air 上跑到每秒 5 到 6 个 token，内存占用差不多 2 GB。
女：这个速度咱们能用来完成实时对话吗？
男：勉强可以。但是在 M5 Pro 上就好太多了——飙到每秒 31 到 35 个 token。这个差距不是因为 M5 的 GPU 更快，更主要是因为 M5 的 SSD 读取速度是 M2 的三倍以上。社区里有人拿低配 M4 Mac Mini 的 256GB 版测，速度只有 5 tok/s，因为苹果在低容量版本上用了带宽很差的硬盘。
女：这就非常现实地告诉我们，一个大型模型的推理瓶颈可能根本不在 AI 芯片，而在硬盘。不过话说回来，Gemma 4 这个模型，用来写代码怎么样？
男：作者自己也承认，它更适合通用对话和日常任务，编程上不如 DeepSeek V4 或者 Qwen 系列。这里也有一个有趣的社区讨论，有人说未来也许可以用多 token 预测提前加载专家的权重，就像 CPU 的分支预测一样，降低延迟。整体上 TurboFieldfare 就是一个展示——用速度换空间的家用级实验，对于需要同时开很多内存密集型应用的人特别有帮助。
女：那我们把视角从硬件拉回到学习本身。前 Coursera 联合创始人 Andrew Ng 最近宣布了一家叫 LearnVector 的新公司，要搞一对一 AI 导师。
男：对，拿了 Coursera 1 亿美元的投资，说是会跟 Coursera 合作保证学习材料的可信度，但不会做成那种随便提问的聊天机器人，因为研究显示没有护栏的聊天机器人会削弱学习效果，造成认知卸载。
女：认知卸载，就是觉得问题已经被 AI 解决了，自己就懒得想了。
男：是的。社区很多人其实都在用 Claude 或 Gemini 设置一个苏格拉底式的提示做辅导，觉得现有的通用大模型已经能做到类似 LearnVector 想做的事。所以 LearnVector 必须在长期记忆、进度跟踪、游戏化这些东西上做得比简单的系统提示强很多。
女：这刚好联系到我们最后一个话题。Andrew Ng 让大家想到他以前的一个同事 Peter Norvig，那篇非常出名的《十年学会编程》。Norvig 说，什么《24 小时学会 Java》都是胡说，真正学会编程需要十年，需要刻意练习，挑比自己能力稍微高一点的任务，反复试错。
男：这篇写在 1998 年的文章，到今天在社区里激起了一场相当激烈的讨论——LLM 出现之后，这篇“十年”还适用吗？
女：有人觉得自己过去最喜欢探索新语言、新范式，现在 AI 一来，“继续学那些技术细节好像完全没意义了，就像亲手织布一样，你能做，但很难靠它获得职业优势”。这话听着挺伤感的对不对？
男：另一个用户回得很直接：不是 AI 抢走了它，是你自己让它失去意义的。你还是可以用老方法做事，只要愿意承受技能退化。不过现实生活中确实有一个开发者在帖子里说，他花了三个钟头才找出一个 AI 通过 vibe coding 写的潜伏 bug，最后还是靠一行一行跟调试器找出来的。Claude 之前完全没发现，因为那是一个 AI 从根本上误解设计而制造出来的、人类不太会犯的错。
女：那有没有人为 AI 辩护的？我猜一定有老程序员觉得这只是个新抽象层。
男：有人就说从汇编到 C 到 Java 到 TypeScript 再到 AI，没什么本质区别，而且用 AI 编码反而逼你写测试。但反驳的人马上搬出关键差异——编译器的契约是确定性的，LLM 是概率性的，你不能信任它，花在审查上的时间并不比手写少。
女：这场争论还有没有让人看到更温和的部分？
男：有一个韩国的开发者说得特别好：懂手写代码和懂 vibe coding 是两种不同的直觉，它们互补但不贯通。他仍然手写代码不是因为更高效，纯粹是因为他享受那种过程。
女：这句话好，就像咱们刚才聊的 reFrame 相机或是做 demo 的那种生活方式——有些东西的价值不在于生产力，而在于亲身投入时获得的那种质感。
男：对。还有一个评论我印象很深，回忆他自己十一岁从图书馆借了一本《21 天学会 C++》，家里没有电脑就手动抄练习，后来读到大学做了十年程序员，依然有很多不懂的东西。那本书的标题是荒唐的，但它确实改变了他的人生。这刚好呼应了 Norvig 那篇文章的最后一句话：“去买那本书吧，你会有点用，但它不会在 24 小时或 21 天里让你真正成为专家。”
女：如果把所有这些串起来看，今天聊的其实都是我们在处理和技术的距离感——有刻意接近硬件极限的 demo 场景，有把旧设备用软件重新续命的 KOReader，有讲究慢节奏的 ePaper 相机，也有用 AI 疯狂加速工作却又饱受其隐性风险困扰的事情。
男：对。还有一点是我们在最后提到的 Agent 不能可靠执行长指令的事。社区在那种一百多页手册的测试里发现，哪怕标注了 1M 上下文窗口的模型，在差不多 25 万 token 之后，规则就开始被遗忘。对策最后还是回到了结构化的监督与确定性控制上，比如代码检查器、不可绕过的钩子，而不是靠把政策塞进一句系统提示。
女：是啊，就像把一百多页员工手册扔给一个新员工，然后告诉他“照着做”。人尚且需要培训、反复实践和外部监督，我们怎么就能指望一个大语言模型因为读过一次就能永远遵循呢。
男：对，社区里有句话我很认同：能做成管道的地方就不要用代理。如果你流程是确定的，直接把它拆成一个一个单次提示构成的图式工作流，每一步可预测、可审计。
女：听上去好像又回到了要学会扎实基本功这个老话题。
男：是啊，技术总在变，但拥有判断力和掌控感这件事，还是得花时间。
女：好，今天的节目差不多聊到这儿了。大家如果喜欢我们的讨论，可以用泛用型播客客户端订阅我们。感谢收听，我们下期再见。
男：下期见。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。