--- layout: post.njk source: https://yage.ai/share/nobody-did-it-before-20260918.html speaker: yage.ai title: 一台开不了机的游戏机，一份没人看的档案，和一个还没人做的索引 date: '2026-09-18' summary: 文章探讨AI降低技术门槛，使普通人能修复冷门硬件并生成详尽工程档案。然而，这些长尾知识散落各处且缺乏统一索引，导致检索困难。未来需建立面向AI的结构化索引，以连接这些分散的技术记录。 area: tech-engineering category: ai-application tags: - long-tail-knowledge - ai-assisted-repair - knowledge-indexing - human-ai-collaboration people: - LordVitaly - Dmitry Brant - Jon Radoff - Chris Lewis companies_orgs: - CYBER Gadget - AtariAge - KLOV products_models: - Retro Freak - GPT-5.6 Sol - GPT-6 Astra - Claude Code media_books: [] draft: true status: evergreen --- ## 一个不写程序的人，修到了芯片最底层 桌上摆着一台游戏机。插上电源，屏幕只有一片空白，得反复按电源键三四次才能勉强开机。这是日本厂商 CYBER Gadget 出的 Retro Freak，能读各种老游戏机的卡带。 2026 年 9 月 13 日，GitHub 用户 LordVitaly 发布了一份维修研究档案。他在这份档案开头写道，自己不是程序员。机器上的操作全是他干的，模型负责判断下一步该往哪儿查，起先是 GPT-5.6 Sol，后面换成 GPT-6 Astra。机器每次是什么反应，他也如实告诉模型。就这样从开机最先出错的一环查起，一路查进存储芯片内部。前后花了一周，机器恢复了正常开机，游戏也能跑起来。 作者在 Reddit 的帖子里记了这件事的代价。他订阅套餐里整整两周的额度全用光了。中途还得一直把模型开在 Ultra 模式，否则它会反复绕圈，兜不出来。 这台机器有多难修，论坛上有人现身说法。2025 年 5 月，AtariAge 论坛就有人发帖求助同样的毛病，一上来就说，关于这台机器几乎查不到任何资料。到 2026 年 2 月，还有人在这帖底下追问一个报错代码是什么意思，没人回复。此前有人查到机器的启动引导阶段，怀疑是主控芯片坏了，就在那里停了下来。一个不写程序的玩家，反倒一路查进了存储芯片内部。 十个月前我写过一篇超越DRY，聊过一个变化：以前给一个人的临时需求专门写个小软件，怎么算都不划算；现在这件事头一回变得可行。那篇讲的是写软件。眼下这件事，是同一个道理落到了修实实在在的机器上。 他在论坛之外还交出了一套完整的工程档案。这份档案把每一步的把握分成九个等级，最低一级是操作本身没报错，最高一级是功能真的恢复，比如游戏能玩起来。他还定死一条规矩：低一级的把握，只能当作低一级的结果，不能升格成高一级的结论。 发布前，他又过了一轮独立审计，列出十处修改，其中包括撤掉自己证据不足的推断。档案里，456 个历史快照被逐一比对，620 个文件都进了清单，排查走过的 11 条死路也如实记了下来。有一条参考资料他再也打不开了，就在档案里标上一条，说明这条没能复核。 这么严的记录，带着明显的模型痕迹。人写维修笔记，写到机器能开机、能玩就收笔了；模型不会。它会把每一步拆开、编号、存档，再回头把自己审一遍。这种不厌其烦的详尽，是 GPT 这类模型的典型做派：任务无论大小，都要做到穷尽。 这样一份下了功夫的记录，发布当天公开互动很少。GitHub 仓库第一天只有 0 个星标、1 次陌生账号的存档式复制、0 个 issue；Reddit 上的分享帖只有 1 分，没有评论。动手之前，任何一个理性的人都能猜到会是这样。冷门硬件的整理换不来流量，没有读者，多数人一开始就不会做。 以前不会有人动手的事，现在有人做成了；以前做完了也不会留下的过程，现在完整地留了下来。这两件事凑到一起，才凑出了眼下这个新情况。 AI 已经打开两道门：做不做和记不记都已通行，而找得到吗还悬着 ## 以前没人肯干的活，现在有人干了 计算机和复古设备交叉的地方，类似的事正在反复出现。 Dmitry Brant 手里有一台老磁带驱动器，只能读 1990 年代的 QIC-80 磁带。让它在今天的电脑上工作，靠的是一段叫 ftape 的驱动程序，而这段程序从 Linux 2.4 之后就再没人维护，停了整整二十五年。要读出磁带里的数据，就得把这段老代码改到能在今天的系统上跑。 这是件很费工夫的活，得懂操作系统底层。为了一块磁带机去重写驱动，怎么算都不划算，除非你手里正好有一盘非读不可的旧磁带。Brant 在 Claude Code 的协助下，两个晚上就改完了。经过一轮轮编译报错来回调，二十五年前的代码终于能在 6.8 内核上顺利编译。他把过程写成了博客。 Jon Radoff 的故事更远一些。1992 年，他做过一款在 CompuServe 上跑的多人文字游戏，叫 Legends of Future Past。游戏的原始代码二十七年前就丢了，他也早已放弃重写。麻烦在于，游戏依赖一门当年专门为服务器写的脚本语言，这门语言在网上找不到任何资料。模型读着残留的数据片段，把这门语言的规则一条条推了出来，帮他重建了游戏里的 2,273 个房间。一个周末，这款停了很多年的游戏重新跑了起来。他把经过写在专栏里，代码也开源了。 还有 Chris Lewis，带着一组协作智能体，用 84 天把任天堂 64 上的游戏 Snowboard Kids 还原成了可读的代码，还原出来的版本和原版卡带一个字节都不差（过程记录）。放在过去，同等规模的活儿大约要两年。 把这些放在一起看，变化在于做成一件事的门槛降了。磁带机驱动也好，消失的文字游戏也好，冷门游戏机的供电故障也好，都算不上有商业价值的主流需求。在没有工具帮忙的年代，它们技术门槛高，投入和回报又不成比例，根本进不了动手这一步，只能被忘掉。有了模型搭把手，普通人开始够得着这些技术难关，把原本不会发生的事变成了现实。 ## 干完还会留下完整的过程记录 就算偶尔有爱好者凭兴趣修好了冷门硬件，为什么过去几乎没人留下这么详细的档案？答案其实朴素：写东西是要给人看的。一份只对几十个同样持着老旧设备的人有用的排查记录，花大把时间整理成步步求证的文档，怎么算都亏。就算有人在论坛留过只言片语，真正的排查思路大多也只留在当事人脑子里，人一换设备、一没了兴趣，就没了。 现在这批档案能带上九个证据等级、独立审计、几百个文件逐一比对，靠的是人机配合。换成人手去对比几百个历史文件、写上上百页说明，耗掉的精力比修机器本身还多。模型能把整个推演过程低成本地整理下来，把人从这种苦力活里解放出来。 不过这份档案能站得住，靠的不只是篇幅。它把每条结论按证据的强弱分了层，哪些是操作时亲眼看到的、哪些还没复核，都标得清清楚楚。写得多不等于写得对，真正撑住它的，是每条结论都站在它该站的那一级上，谁也不往上抬。 这种档案并不普遍，在没有客观标准的领域里依然难得一见。街机玩家聚集的 KLOV 论坛里，有人复盘过向模型请教维修的荒唐经历：标着 F901 的位置该用 1.25 安培快熔保险丝，模型说成了 1.5 安培慢熔；甚至让人在线圈上装个土豆、涂点红漆、钉几颗橡胶钉。暖通行业媒体写过一篇专栏，讲的是”AI 说是电容坏了”，实际故障在别处。复古合成器圈里，这次检索没找到一篇模型帮着修好硬件的像样长帖。 能留下来的，条件就两条：故障得有客观的读数可看，比如明确的报错码、万用表上的阻值、编译器给出的错误、文件一个字节一个字节的比对；这个圈子本身还得较真。缺了这两样，模型给出的往往只是危险的误导。 把网上的讨论铺开看，这些长尾产物大致是个金字塔。最底下是社区里成千上万的一句话心得；往上是一些写清了参数和细节的求助与分享长帖；再往上是十几篇独立成文的博客；而真正经得起第三方查、证据链完整的工程档案，本次调研估计全网也就个位数。金字塔的下半截堆着大量零散记录，比如 Hacker News 上这篇 333 条评论的讨论帖和这篇 206 条的，还有 Reddit 上这棵 169 个节点的讨论树。里面聊的多是修电子书阅读器插件、锅炉故障、家谱转录这类小事。 长尾 AI 产出的金字塔：数千条短帖、数百条长帖、十几篇博客，塔尖是个位数完整档案 ## 记录散在各处，还没有人把它们串起来 GitHub 上，说明文档里写着 vibe coded 的项目，大约 10.2 万个；写明用 Claude Code 建的，约 1.4 万个（2026-09-14 查询）。但按主题去找，标签是 llm-repair 的项目，全平台只有 1 个。 企业那边，案例库早有人整理得清清楚楚：500 多个机器学习落地案例的仓库、800 多个系统设计的合集、ZenML 整理的 457 篇生产实践。但这些收的都是企业项目。个人用模型啃冷门硬件、老旧软件这一片，分类和索引基本是空的。Contrary Research 那篇长尾报告讲的是企业怎么选技术路线，Karpathy 讲的是周末随手做工具的文化（回顾文章）。个人长尾工件正在汇成公共知识，这个说法在本次英文检索范围内还没有主流作者系统写过。 这些记录散落各处，各自的消失方式还不一样。论坛里的讨论很快被后来的灌水冲走，沉到几十页深处；个人博客没有别的页面链过来，就沉在搜索结果几十页开外；代码仓库没有统一标签，除非你正好输对了型号或报错原文，否则根本搜不到。同一份经验放在这三种地方，各有各的丢法。 为什么一直没人给长尾档案建索引？问题出在聚合这件事本身划不来。单篇冷门硬件的排查记录，对绝大多数人没用，只在极少数人遇到同样故障的那一刻才值钱。整理索引的人既拿不到日常流量，也换不来明确收益。 对比一下大家熟悉的事故复盘合集就清楚了。它能一直活着，是因为分布式系统的故障复盘彼此很像，读的人是同一批工程师，术语也是共通的一套。长尾档案恰好相反：每台设备的故障逻辑都不一样，读者散在互不往来的圈子里，连最基本的命名都没有统一说法。 但这件事还有更深的一层。这批档案的下一个读者，很可能是模型本身。Retro Freak 那份档案的根目录里，作者专门放了一份写给未来 AI 看的说明文件，警告后来的模型：不要直接执行仓库里的历史脚本，也不要把低一层的推测当成高一层的事实。 模型一旦成了这批档案的读者和执行者，索引的样子也会变，从给人翻的目录页，变成给模型检索、调用的一批结构化材料。做这件事的人也会换，从靠兴趣的独立作者，换成模型公司和 agent 框架团队。价值大家都看得见，只是还没有哪一方既有动力、又站在合适的位置上，把这个角色接下来。 这个判断有一个明显的反例：也许根本不需要专门建索引，Google 就够了。对已经知道自己要找什么的人，输入型号和报错原文，搜索引擎加上现在能读网页的模型，多半能把答案捞出来。真正缺索引的场合其实更窄：你事先并不知道这台机器坏在哪，也就不知道该搜什么词；或者那份记录躺在代码仓库的一堆 JSON 里，没有一句可供检索的描述。搜索解决的是知道了问题之后怎么找答案，它解决不了还不知道该问什么。缺口在发现，不在检索。 回到最初那台游戏机。AtariAge 论坛上，2025 年 5 月有人求助，到 2026 年 2 月还有人追问报错含义，没人应答；LordVitaly 那份档案盖住的，正是他们卡住的那片区域。Reddit 上 2018 年一篇 Retron 5 的救砖指南，过了七年，还不断有遇到同样故障的新玩家找过去。长尾技术知识的寿命，比大多数人想的要长。以前没人做的事，现在有人在做；以前没人记的过程，现在有人记了下来。剩下的是把这些散落的记录串到一起，这件事在本次检索范围里还没有人做。