編注：我們會(huì)不定期挑選 Matrix 的優(yōu)質(zhì)文章，展示來自用戶的最真實(shí)的體驗(yàn)和觀點(diǎn)。文章代表作者個(gè)人觀點(diǎn)，少數(shù)派僅對(duì)標(biāo)題和排版略作修改。

導(dǎo)讀：全文 11169 字，閱讀所需 20-25 分鐘。毫無逆向經(jīng)驗(yàn)的 LOSSES，靠著給 GLM 和 NotebookLM 當(dāng)「?jìng)髟捦病?，成功拆解?MP3 的底層固件并做出了魔改工具。文章不僅復(fù)盤了解決 AI 長(zhǎng)上下文降智的雙模型工作流，更深度剖析了 AI 高頻反饋如「老虎機(jī)」般榨干精力的心理陷阱。如果你對(duì)硬核的賽博修車感興趣，或是想了解 AI 工具帶來的隱蔽心理陷阱，不妨花點(diǎn)時(shí)間讀一讀。

敝人對(duì)「保存音樂的介質(zhì)」有一種迷一樣的執(zhí)著。如果你看過一個(gè)叫「科幻枸杞」的 YouTuber，那你大概就能懂。

我跟他的愛好還挺像的：小學(xué)的時(shí)候特別喜歡用家里的磁帶機(jī)做 MixTape，留下了很多美好回憶。而現(xiàn)在的人生理想是搞一臺(tái)自己的 Walkman 磁帶機(jī)。

但這事兒它不咋好搞。Walkman 這東西，死貴、坑又多。我今年的生日愿望就是期待一個(gè)好心「群友」送我一臺(tái)，但我知道他們會(huì)罵我臭不要臉。為了填補(bǔ)那深邃的消費(fèi)主義空洞。半年前，我湊合著買了個(gè)飛傲（Fiio）出的 Echo Mini，一個(gè)長(zhǎng)得像 mini 磁帶機(jī)的 MP3。

▍這個(gè)設(shè)備挺爛的

到手之后用了一陣子，產(chǎn)生了一種相當(dāng)復(fù)雜的感受：挺好，但是活整得挺爛。

最辣眼睛的是那個(gè)大果粒顯示器，擱十五年前你可能會(huì)覺得它就是 Average Level 的顯示屏幕。但在 2026 年的今天，盯著它那個(gè)屏幕，就只會(huì)覺得頗為微妙。其實(shí)哪怕屏幕是大果粒，只要你的視覺做得好（比如復(fù)古像素風(fēng)），說不定還是個(gè)優(yōu)勢(shì)。但這設(shè)備的設(shè)計(jì)爛就爛在那破 UI，一開機(jī)「地鐵老人看手機(jī)」的扭曲面龐就糊臉上了。

我一直跟「群友」抱怨，這些設(shè)計(jì)師一看就是小年輕，因?yàn)樗傅脑O(shè)計(jì)執(zhí)行錯(cuò)誤實(shí)在太離譜了。所有的圖標(biāo)，清一色全沒做像素對(duì)齊，所以看啥都是糊的。In case you didn't know, 蜀黍阿姨們還在玩設(shè)計(jì)的時(shí)候，屏幕分辨率都很低，為了讓畫面看上去銳利清晰通常都會(huì)盡可能避免錨點(diǎn)卡在半像素上導(dǎo)致次像素平滑。這設(shè)備的問題是很多圖標(biāo)特別小，糊成一團(tuán)基本就看不出來個(gè)形狀，盯著瞅半天滿腦子問號(hào)：這?是個(gè)啥？最荒謬的是，圖標(biāo)是糊的，文字渲染又是像素字體。

再比如，當(dāng)你正在升級(jí)固件的時(shí)候，屏幕上會(huì)顯示一個(gè)用中易黑、宋畫出來的丑陋界面，而且提示文字竟然不在畫面正中間！日用的時(shí)候如果你把語言切成法語，會(huì)發(fā)現(xiàn)帶裝飾符的字母和不帶裝飾符的字母大小還不一樣，字母全都全都高高低低參差不齊。

還有更迷幻的，所有的位圖 UI 素材看起來都像是先用有損格式導(dǎo)出，又轉(zhuǎn)成了 BMP 最后嵌入固件的。所有貼圖的明暗交界處都莫名其妙地多一圈白邊，而且細(xì)節(jié)充滿壓縮后的噪點(diǎn)痕跡。加上那說不上好的操作手感，用起來不免讓人身心不適。

當(dāng)然它也有優(yōu)點(diǎn)：長(zhǎng)得挺可愛、很小，揣出去還能當(dāng)個(gè)社交談資。讓我最喜歡的一點(diǎn)是，它有兩個(gè)耳機(jī)孔！一個(gè)平衡口，一個(gè) 3.5mm 接口，甚至能一起工作！這讓我想起了上學(xué)時(shí)和好同學(xué)分享同一副耳機(jī)的青春歲月?，F(xiàn)在有了這玩意兒，你可以和另外三個(gè)好朋友一起分享音樂了，四人同樂就非常的生草。

另外還有一些更離譜的玩法。

眾所周知，索尼降噪大耳包基本上就是低音拉滿玩命轟頭，高頻那邊則是又糊又難聽。但是我手邊正好有個(gè)平頭塞（YINCROW 那款，最近剛買的），高音處理得還不錯(cuò)但是缺低音。那么問題來了：能不能讓他們一個(gè)負(fù)責(zé)高音，一個(gè)負(fù)責(zé)低音嘞？

既然要強(qiáng)化低音，那不如就把 Clear Bass 直接拉到 +10。平頭塞就正常聽，沒加額外 EQ。當(dāng)我同時(shí)戴上兩個(gè)耳機(jī)（就是把平頭塞耳朵里，再把 XM3 罩在外面），然后輪流拔掉其中一個(gè)的插頭，發(fā)現(xiàn)拔掉索尼，聲音瞬間變薄，吉他指彈的泛音還在，但低頻的箱體共振沒了；拔掉平頭，聲音直接糊成一團(tuán)，索尼那個(gè)悶糊感一下子就凸顯出來了。

兩個(gè)一起的時(shí)候，竟然出現(xiàn)了真 正 的 音 樂 d(???)b！

但這玩法不是沒有代價(jià)的，輸出相位肯定對(duì)不上，導(dǎo)致聲音聽起來特別「死」，像在水泥池子里游泳，空間感有很大的損失。

總體氣氛上就是這樣——硬件是好的，軟件是爛的，爛得非常均勻徹底。不光軟件 UI 設(shè)計(jì)是爛的，其實(shí)工程實(shí)踐也是爛的，這點(diǎn)后面再說。

所以我一氣之下（其實(shí)也沒太生氣，就是動(dòng)了個(gè)念想）開始嘗試魔改固件。

▍固件魔改 初探

我?guī)缀鯖]有任何逆向工程的經(jīng)驗(yàn)，上一次干這事兒還是在初中，經(jīng)驗(yàn)早就忘光了。關(guān)于「逆向」這事情封頂?shù)慕?jīng)驗(yàn)是研究被 Uglyify 的 JS 代碼。所以，這活兒不是專業(yè)的人恐怕是真的干不來。

但咱有大語言模型不是！

我試了下讓 GLM 4.7 摸了一下固件大體的形狀，他還真給分析出了點(diǎn)有料的東西。一開始，我和他講「這有個(gè)固件，我的目標(biāo)是把里面的位圖給提出來，你告訴我咋整?！顾透嬖V我，他需要 capstone, ghidra, r2pipe, rzpipe, angr。NixOS 裝這些玩意的 Python binding 有一丟丟麻煩，但最后還是給配上了。

接下來他就開始自己掃二進(jìn)制文件。沒一會(huì)兒，芯片型號(hào)、SDK 型號(hào)全給掃出來了。他還找到了分區(qū)表，甚至自己嘗試讀取指令序列，發(fā)現(xiàn)了某種「固件加密」，做了修正程序（此處有巨大伏筆）。

后面，他爬到了文件內(nèi)嵌的文件系統(tǒng)，順藤摸瓜把.bmp文件全都給拽了出來了，我一看，圖還真都是那么個(gè)形狀。

但提取的時(shí)候也遇到了麻煩。那個(gè) BMP 的顏色編碼怎么都對(duì)不上。這地方就得我上場(chǎng)了，畢竟它不長(zhǎng)眼睛，但我長(zhǎng)眼睛。我負(fù)責(zé)看，它負(fù)責(zé)不停地試參數(shù)，最后我倆總算是把正確的解碼參數(shù)給碰出來了。

字庫提取

因?yàn)槭窍袼貓D，所以有一個(gè)最簡(jiǎn)單的假設(shè)，字庫的存儲(chǔ)是二進(jìn)制序列，0 是空白 1 是帶字的部分。于是我掏出手機(jī)拍了一下屏幕上的漢字，然后開始數(shù)像素顆粒碼到 TXT 文檔里面當(dāng)成搜索樣本——不得不說，這還真得感謝它是大果粒像素字體！讓我能看清那一顆一顆的像素。

我把摳出來的幾個(gè)字交給 GLM 4.7，告訴他「就這幾個(gè)字，你想辦法去掃掃看?！菇Y(jié)果意外的好，他通過各種墊 padding，還真把那像素字體存儲(chǔ)的位置給抓出來了。

雖然找到了字形文件，但不知道數(shù)據(jù)結(jié)構(gòu)是啥，也不知道索引表在哪。這就開始了漫長(zhǎng)的盲人摸象。而且有一個(gè)很擰巴的點(diǎn)是，每隔幾個(gè)字就會(huì)出現(xiàn)字符撕裂，就是左半邊往上挪一點(diǎn)，右半邊往下挪一點(diǎn)，隔一個(gè)字就來一下，完全不知道咋回事。

沒啥招，只能看固件里面的文字渲染邏輯了。反正字在哪兒已經(jīng)知道了，在地址上下摸一摸，總能摸出點(diǎn)東西。不到半小時(shí)，它就把渲染函數(shù)給摸出來了，然后一步步往上爬，最后找到了渲染公式。

但是這一直都沒辦法解釋為什么會(huì)出現(xiàn)圖像撕裂。為了解決這個(gè)問題，我們還一度懷疑是不是一些軟硬件通信協(xié)議層面上的協(xié)定，甚至造了一個(gè)涉及 VOP DMA 的迷你渲染模擬器，問題都沒抓出來。

一定是哪里出了問題，我當(dāng)時(shí)一直陷入了一個(gè)死胡同里，認(rèn)為是提取算法的問題。

撕裂的模式很明確左半邊往上偏一點(diǎn)，右半邊往下偏一點(diǎn)，隔一個(gè)字出現(xiàn)一次。于是我便嘗試讓 GLM 4.7 嘗試找出偏移規(guī)律。這里面出現(xiàn)了一個(gè)很煩人的點(diǎn)，它經(jīng)常打出一大堆 ASCII Art，明明打出來的字都已經(jīng)扭曲了，但是他還是信誓旦旦地告訴我：對(duì)的，這是漢字，完整的漢字沒問題。

但那個(gè)字明明已經(jīng)裂開了。

LLM 是文本模型，它只能一行一行地橫向讀數(shù)據(jù)。 它看到的是一行行由點(diǎn)和井號(hào)構(gòu)成的字符串，它能從統(tǒng)計(jì)規(guī)律上猜測(cè)「這看起來像漢字」，但它根本沒有二維視覺，它看到的東西和人眼看到的完全不是同一件事。你要它判斷一個(gè)字形對(duì)不對(duì)，它給你的不是視覺判斷，是一個(gè)概率預(yù)測(cè)，而這個(gè)預(yù)測(cè)非常容易出錯(cuò)。

另外，他非常喜歡統(tǒng)計(jì)建模，認(rèn)為「80% 對(duì)上了」比「50% 對(duì)上了」更好，哪怕它比對(duì)的可能完全不是一個(gè)東西。此時(shí)，你得非常耐心地告訴他，這東西只有完全對(duì)上了和完全對(duì)不上，沒有只對(duì)得上一半的情況。

這件事反復(fù)發(fā)生了十多次。每次我說「你確定這是漢字嗎？字都撕裂了，形狀不對(duì)，字形不完整是好幾個(gè)字拼在一起的」，它就道歉、重新分析，上下文爆掉壓縮，犯過的錯(cuò)誤被很糟糕的壓縮提示詞給搞丟，你明確告訴他「你要一列一列地讀，不要一行一行地讀」，他聽了，然后過一會(huì)兒自動(dòng)退回到行讀模式。再告訴一遍，再退回去。你的指令對(duì)它來說是臨時(shí)覆蓋，不是真正改變了它的工作方式。

這個(gè)過程中我有幾次情緒失控，直接開始飆罵。事后發(fā)現(xiàn)這是個(gè)非常具體的問題：你的情緒一旦注入對(duì)話，它會(huì)留在上下文里，甚至這些信息會(huì)在上下文壓縮過程中保留下來（但是重要的方法論經(jīng)驗(yàn)不會(huì)流下來），然后持續(xù)污染后續(xù)的推理質(zhì)量。罵它之后，它開始把大量精力用來安撫你的情緒，而不是解決技術(shù)問題，并且前方百計(jì)地避免觸發(fā)你的情緒感受，最后變得什么都不做，非常像人類的 FoF 反應(yīng)。結(jié)果就是，推理越來越弱，你越來越煩，惡性循環(huán)。

這是個(gè)很實(shí)用的教訓(xùn)：和 LLM 協(xié)作時(shí)，你的情緒狀態(tài)是工程變量，不是私事。

直到后面我開了一個(gè)新的上下文，請(qǐng) LLM 做了一個(gè)渲染結(jié)果到 ROM 地址的映射可視化工具，我一塊一塊看，并且跟新的上下文做了確認(rèn)，他問了我一句「你這固件文件哪里來的」？我把「修復(fù)腳本」給他看，他告訴我：那修復(fù)腳本 Fuck Up 了你的所有分析，他用錯(cuò)誤的方式解讀了固件把數(shù)據(jù)結(jié)構(gòu)破壞掉了，所以才會(huì)出現(xiàn)字符撕裂的問題。

至此懸案解開了。

檢字系統(tǒng)逆向

至此我們只找到了 CJK 區(qū)域的字，但是對(duì)于其他區(qū)域的字一無所知。我們看到了平面之間有大量純 0 空白數(shù)據(jù)，有一段連續(xù)數(shù)據(jù)，中間又有大片空白，然后又是一大堆數(shù)據(jù)。LLM 說數(shù)據(jù)是分塊存儲(chǔ)的，并且狡猾地繞過了對(duì)那一大堆純 0 數(shù)據(jù)來源的解釋。

按照整個(gè)邏輯，如果數(shù)據(jù)是分片的，那么就需要有一個(gè)表，它就開始嘗試產(chǎn)生一千零一種幻覺，試圖把「查表」這個(gè)假說給硬凹出來。

另外你也知道的，模型極不擅長(zhǎng)數(shù)學(xué)，我給他幾個(gè)樣本字符，他「尋找規(guī)律」但一直告訴我沒有規(guī)律，一定是查表得到的。于是我找了更多樣本，甚至碼著 CJK 碼位搞出來了好幾排字，讓機(jī)器渲染出來、拍照，用 Gemini 的 Canvas 寫了兩個(gè)工具，造了一大堆的樣本給他搜。

具體來講，其中的一個(gè)工具是二進(jìn)制序列復(fù)原工具，傳入一張照片切片，自動(dòng)切成 16×15 的格子，每格生成一個(gè)直方圖，中間加一條拖動(dòng)的分割線，標(biāo)記左邊是黑，右邊是白，自動(dòng)做二值化判斷。之后我只需要拍照、傳圖、調(diào)分割線，字形就自動(dòng)描出來了。

還有一個(gè)工具：給定一個(gè)位圖，自動(dòng)生成前后 100 個(gè) Unicode 碼位的字符表，點(diǎn)擊某個(gè)字符就把對(duì)應(yīng)的碼位復(fù)制出來。這是因?yàn)楫?dāng)時(shí)根本找不到一個(gè)好用的 Unicode 碼位查詢網(wǎng)站，干脆自己造一個(gè)。

但是他一直在錯(cuò)誤的上下文當(dāng)中牽強(qiáng)附會(huì)，直到我把所有掃到的數(shù)據(jù)導(dǎo)出來扔給 Gemini 的 Canvas 做了一個(gè)線性回歸擬合把公式甩回去之后……嘿！它依然不聽！因?yàn)檫@跟它看到的指令序列邏輯對(duì)不上。它說推出來的寬度是 32，實(shí)際渲染的卻是 33。

這個(gè)問題卡了整整兩天。

但好在我用 LLM 的習(xí)慣比較好，每次有研究成果都會(huì)直接輸出一份 Markdown 筆記，并且有適度地維護(hù)整個(gè)文檔庫。于是我把整個(gè)文檔庫全都塞給了 NotebookLM，并且把整個(gè)問題上下文全都粘給 NotebookLM。NotebookLM 一眼就看出來了：編譯器把乘以 33 優(yōu)化成了「左移 5 位再加原值」，即x << 5 + x。因?yàn)槲灰七\(yùn)算比乘法快，編譯器會(huì)自動(dòng)做這種替換，但 GLM 在分析反編譯結(jié)果時(shí)沒有識(shí)別出這個(gè)模式，所以一直把參數(shù)認(rèn)成了 32。

這里又學(xué)到了兩個(gè)重要的知識(shí)：復(fù)雜任務(wù)需要多個(gè)模型進(jìn)行眾議，一個(gè)模型很有可能會(huì)陷入知識(shí)盲區(qū)。事實(shí)上 Grok 最近也上架了一個(gè)集成多模型眾議的模式，看著還挺好玩的。

上下文管理

到這個(gè)階段，一個(gè)很明顯的問題就被暴露出來了：只要你的上下文窗口一大，塞的東西一多，它就會(huì)變?nèi)踔恰?/strong>當(dāng)時(shí)我們倆生成的各種文檔、日志、代碼片段已經(jīng)有好幾千行了，它開始胡說八道，不停地抱怨，開始戳一步走一步，執(zhí)行開始變得非常死板。

而且之前留下來的文檔越累積越多，越來越長(zhǎng)。如果一篇文檔就能把上下文吃個(gè)大半，那整個(gè)研究便無從繼續(xù)。所以是時(shí)候做 House Keeping 了。

結(jié)構(gòu)化歸檔

第一步是把所有積累下來的文檔一次性扔給 Claude，讓它幫我整理成樹狀目錄，每個(gè)知識(shí)點(diǎn)單獨(dú)成文，文件之間互相索引，入口是一份導(dǎo)讀。后續(xù)遇到具體問題時(shí)，只需要把目錄加上相關(guān)的一兩個(gè)小文件投喂給模型，而不是把整個(gè)研究歷史都塞進(jìn)去。上下文消耗量大幅壓縮，模型能跑得更久、更準(zhǔn)。

但這只解決了存量文檔的問題。GLM 還有個(gè)壞習(xí)慣：讓它記一份文檔，它會(huì)偷偷創(chuàng)建三份。你的文檔庫很快就變成垃圾堆，所以借助額外的模型維持文檔庫是很重要的（但后面我發(fā)現(xiàn) NotebookLM 做這事情效率更好一些）。

問題樹

單純歸檔還不夠，因?yàn)樗艿氖恰敢阎闹R(shí)」，而逆向工程推進(jìn)的過程中，問題本身是動(dòng)態(tài)生長(zhǎng)的。

我維護(hù)了一份專門的問題樹文檔。這里面不是一個(gè)簡(jiǎn)單的待辦清單，記錄了整個(gè)問題空間的動(dòng)態(tài)演化：一個(gè)大問題在研究推進(jìn)中會(huì)衍生出若干子問題，子問題解決了一部分，又暴露出新的未知，新的未知再裂變成更具體的小問題。這棵樹完整地記錄了這個(gè)裂變過程。

這種結(jié)構(gòu)帶來的解決帶來了兩個(gè)好處。一方面，它對(duì)問題空間有一個(gè)高維度的抽象描述，你隨時(shí)能看清楚「我們現(xiàn)在在哪、還有什么不知道、當(dāng)前最重要的瓶頸是什么」，而不是淹沒在一堆零散的技術(shù)細(xì)節(jié)里。第二，也是更關(guān)鍵的，它極大地幫助維護(hù)上下文的清潔。

具體來說：每次開啟新的攻堅(jiān)，我不是把所有研究文檔都塞給模型，而是只把問題樹的當(dāng)前狀態(tài)貼進(jìn)去，從里面挑一個(gè)最重要的子問題，讓模型圍繞這一個(gè)問題生成任務(wù)指導(dǎo)書。模型拿到的是一個(gè)被高度抽象和壓縮過的問題描述，而不是幾天來積累的原始推導(dǎo)過程。這樣它的上下文是干凈的，推理質(zhì)量就能維持在正常水平。

這一點(diǎn)在項(xiàng)目后期尤其關(guān)鍵。當(dāng)研究推進(jìn)到最深處、GLM 4.7 開始不停胡說的時(shí)候，我開了一個(gè)全新的對(duì)話窗口，把問題樹的當(dāng)前狀態(tài)貼進(jìn)去，挑出最重要的那個(gè)子問題，讓 GLM 研究清單。原因很簡(jiǎn)單：它拿到的是一個(gè)干凈的、經(jīng)過抽象的問題，而不是被幾天噪聲污染過的上下文。

這套方法的核心邏輯是：大語言模型的有效工作窗口是有限的，你塞進(jìn)去的信息越多，它能分配給真正思考的空間就越少。問題樹做的事情，是把一個(gè)復(fù)雜項(xiàng)目的知識(shí)狀態(tài)壓縮成一個(gè)可以隨時(shí)拎起來、隨時(shí)投喂的抽象結(jié)構(gòu)，它不記錄你做了什么，它記錄你還不知道什么，以及這些未知之間的關(guān)系。

NotebookLM

在整個(gè)逆向工程項(xiàng)目里，GLM 承擔(dān)的是主要的執(zhí)行工作，掃描二進(jìn)制、反編譯、寫代碼、追調(diào)用棧。但它有一個(gè)難以回避的缺陷：它太容易順著你的思路走。你給它一個(gè)方向，它會(huì)沿著這個(gè)方向一直推，推到撞墻為止，然后開始在墻邊原地打轉(zhuǎn)，卻不會(huì)主動(dòng)后退一步質(zhì)疑這個(gè)方向本身是不是錯(cuò)的。

NotebookLM 在這個(gè)項(xiàng)目里扮演的是完全不同的角色。

任務(wù)書—任務(wù)報(bào)告的協(xié)作模式

這套工作流的核心是把知識(shí)積累和任務(wù)執(zhí)行拆成兩個(gè)彼此獨(dú)立的上下文。

• NotebookLM 負(fù)責(zé)知識(shí)側(cè)：它的文檔庫里存放著所有的研究成果、問題樹、技術(shù)文檔。它不參與具體執(zhí)行，它只讀文檔，然后輸出任務(wù)書。

• GLM 負(fù)責(zé)執(zhí)行側(cè)：它拿到任務(wù)書，專注執(zhí)行，完成后輸出任務(wù)報(bào)告。它的上下文里只有當(dāng)前任務(wù)的執(zhí)行細(xì)節(jié)，不需要記住整個(gè)項(xiàng)目的歷史。

具體流程是這樣的：

項(xiàng)目卡住，或者一個(gè)階段告一段落，我讓 NotebookLM 讀當(dāng)前文檔庫里的所有研究成果，生成一份任務(wù)書。任務(wù)書的結(jié)構(gòu)是固定的：?jiǎn)栴}陳述（我理解你現(xiàn)在卡在哪里）、分步課題（把大問題拆成三四個(gè)可管理的小目標(biāo)）、任務(wù)清單（每個(gè)目標(biāo)下列出具體步驟，明確說動(dòng)作是什么、目的是什么）。

我把這份任務(wù)書原樣交給 GLM 執(zhí)行。不加任何個(gè)人解釋，不加任何情緒，就是一份簡(jiǎn)簡(jiǎn)單單的結(jié)構(gòu)化文檔。

GLM 執(zhí)行完成后，輸出一份任務(wù)報(bào)告：研究目標(biāo)、關(guān)鍵發(fā)現(xiàn)、結(jié)論、遺留問題、下一步建議。同樣是固定結(jié)構(gòu)。

我把這份任務(wù)報(bào)告上傳進(jìn) NotebookLM 的文檔庫。NotebookLM 讀取最新報(bào)告，結(jié)合已有的全部文檔，生成下一份任務(wù)書。

循環(huán)往復(fù)。

表面上看，我只是在兩個(gè)模型之間來回傳文檔，但它解決的是一個(gè)很麻煩的問題：上下文污染。

正常的人機(jī)對(duì)話模式里，你的情緒、你不專業(yè)的描述、你那些啰嗦的廢話、你的錯(cuò)誤假設(shè)，全都會(huì)隨著對(duì)話積累進(jìn)上下文，然后隨著壓縮過程被保留下來，持續(xù)干擾模型的推理質(zhì)量。罵它一句，這句話會(huì)留著；給了一個(gè)錯(cuò)誤的前提，這個(gè)前提會(huì)留著；繞了一大圈彎路，這段彎路會(huì)留著。上下文越長(zhǎng)，這些垃圾積累得越多，模型的推理能力就會(huì)變得越弱。

任務(wù)書機(jī)制切斷了這個(gè)污染路徑。NotebookLM 只讀結(jié)構(gòu)化文檔，這樣就不存在你和 GLM 之間的聊天記錄；GLM 只執(zhí)行任務(wù)書，不需要理解整個(gè)項(xiàng)目的來龍去脈。兩者之間傳遞的全是格式化的、無情緒的、經(jīng)過提煉的信息。

這相當(dāng)于變相拓展了整個(gè)系統(tǒng)的有效上下文空間。不是把一個(gè)模型的上下文窗口變大，而是把知識(shí)和執(zhí)行分離存放，讓每一側(cè)都只承載它真正需要的信息。

GLM 看到任務(wù)書之后會(huì)表現(xiàn)出一種很「興奮」的態(tài)度，表示「哦，原來可以這樣做！」然后 GLM 又能跑一段了。跑一會(huì)兒，又哭了。我再把新的問題陳述扔給 NotebookLM……

基本上，我就成了個(gè)「人肉管道」（SPL, System Prompt Line）。我看他倆聊得火熱，但我一個(gè)人是懵的，很多細(xì)節(jié)我根本不懂。我只負(fù)責(zé)在他倆之間來回傳話，全程發(fā)懵，只能在旁邊鼓掌：「大佬們真棒！」

不過這事情后面有了更加自動(dòng)化的解決方法，用了這個(gè) Skill 之后，只要提示詞給好，讓它倆自己聊就行了，我也不用來回復(fù)制粘貼了。

讓兩個(gè)模型吵架

這套機(jī)制還有一個(gè)變體用法：當(dāng)某個(gè)技術(shù)問題存在爭(zhēng)議時(shí)，我會(huì)讓兩個(gè)模型互相批判對(duì)方的方案。提示詞是固定的：

請(qǐng)系統(tǒng)性的用逆向分析工具調(diào)查，并用建設(shè)性批判（constructive criticism）的方式回應(yīng)以下觀點(diǎn)。

GLM 給出結(jié)論，交給 NotebookLM 批判；NotebookLM 給出修正，交回 GLM 批判。來回幾輪之后，一個(gè)經(jīng)過雙向檢驗(yàn)的分析框架自然浮現(xiàn)出來。兩個(gè)模型單獨(dú)面對(duì)人類輸入時(shí)都傾向于順從，但面對(duì)另一個(gè)模型的結(jié)論時(shí)批判性會(huì)明顯提高。字符渲染管線最難啃的部分就是用這個(gè)方式調(diào)出來的。

我在這套機(jī)制里做的事情只有三件：決定什么時(shí)候切換（執(zhí)行卡死了就切到 NotebookLM）、判斷任務(wù)報(bào)告的結(jié)論是否可信（模型沒有眼睛，視覺判斷必須由我來做）以及維護(hù)問題樹（決定下一個(gè)最重要的子問題是什么）。其他所有事情，都在這個(gè)機(jī)器對(duì)機(jī)器的閉環(huán)里自動(dòng)完成。

這是整個(gè)項(xiàng)目里最重要的一個(gè)方法論發(fā)現(xiàn)：雖然聰明的模型很重要，但是一個(gè)不會(huì)讓它變笨的工作環(huán)境也很重要。

LLM 開始胡說時(shí)，說明你喂的信息可能不夠了

這是整個(gè)項(xiàng)目里反復(fù)驗(yàn)證的一條規(guī)律，也是最反直覺的一條：當(dāng) LLM 開始四處碰壁、原地打轉(zhuǎn)、輸出越來越離譜的結(jié)論時(shí)，第一反應(yīng)不應(yīng)該是換個(gè)提示詞，而是問它：你缺什么信息？

第一次：找 TRM 手冊(cè)

字庫逆向推進(jìn)到一半，GLM 開始出現(xiàn)典型的「信息饑渴」癥狀，靜態(tài)分析反復(fù)聲稱「找到了函數(shù)入口」，但給出的地址在固件里根本不存在；推導(dǎo)鏈條越來越長(zhǎng)，結(jié)論越來越玄；每隔幾輪就說「我已經(jīng)達(dá)到了靜態(tài)分析的極限」。

我停下來直接問它：你現(xiàn)在需要什么才能繼續(xù)？

它說：我需要這顆芯片的 Spec 和 TRM。Spec 是硬件規(guī)格書，TRM 是技術(shù)參考手冊(cè)，里面有完整的指令集、寄存器定義、內(nèi)存映射。沒有這些它只能靠猜，而它已經(jīng)猜不下去了。

芯片型號(hào)是 Rockchip RKnano D。我去搜，找到了一份 Spec，但 Spec 只有硬件層面的參數(shù)，沒有指令集。TRM 才是真正需要的東西，但搜遍常規(guī)渠道，什么都沒有。搜索過程中找到一個(gè)日本人的網(wǎng)站，上面列出了兩條 URL，分別指向硬件文檔和指令集文檔。點(diǎn)進(jìn)去之后赫然彈出了一個(gè) 404。

TRM 那條鏈接死了。

我盯著那個(gè) 404 的 URL 看了一會(huì)兒，然后把之前有效的 Spec URL 并排放在一起對(duì)比。一級(jí)域名相同，二級(jí)域名不同，一個(gè)是 Wiki 子域，一個(gè)是主站域名。網(wǎng)站搬過家，內(nèi)容從 Wiki 遷到了主站，但日本人的那個(gè)網(wǎng)站上記錄的還是舊地址。我把 TRM 那條 URL 里的子域名改成主站格式，刷新。文件下載成功了。

這是一個(gè)純粹靠人的思維方式才能解決的問題。幾乎不會(huì)有模型去盯著一個(gè) 404 的 URL 想「這兩條鏈接的域名結(jié)構(gòu)有什么關(guān)系」，它只會(huì)告訴你「文件不存在」然后建議你換個(gè)搜索詞。發(fā)現(xiàn) URL 結(jié)構(gòu)規(guī)律、推斷網(wǎng)站遷移、手動(dòng)修改路徑，這個(gè)推理鏈條需要的是人對(duì)網(wǎng)站運(yùn)作方式的隱性經(jīng)驗(yàn)，不是模型能做到的。

TRM 到手之后，我把它交給 NotebookLM。它拿到文檔，立刻找到了之前那些「不存在的地址」對(duì)應(yīng)的硬件機(jī)制，卡了很久的分析線索重新跑起來了。

順手把這份 TRM 手動(dòng)備份到了互聯(lián)網(wǎng)檔案館，發(fā)現(xiàn)幾年前已經(jīng)有人備份過，只是沒被搜索引擎收錄。白忙了一場(chǎng)，但也只是浪費(fèi)了一點(diǎn)時(shí)間。

第二次：把設(shè)備本身當(dāng)文檔

推進(jìn)到硬件模擬階段，GLM 在判斷某些具體硬件規(guī)格時(shí)又開始亂說。這次我沒有去找外部文檔，而是想到了另一個(gè)信息來源：設(shè)備本身。

我把播放器的軟硬件版本號(hào)、以及播放器官方頁面上列出的產(chǎn)品 Spec 全部整理出來，一起交給 GLM。

這些信息看起來很普通，甚至有點(diǎn)像湊數(shù)，但它為一處基礎(chǔ)的硬件版本判斷提供了重要的數(shù)據(jù)錨點(diǎn)。順著條件判斷邏輯樹一路往后推，發(fā)現(xiàn)了幾處和之前推理對(duì)不上的地方，順著這些矛盾點(diǎn)往回追，核心的硬件規(guī)格判斷問題得到了突破。最后關(guān)于文本渲染的完整調(diào)用棧被徹底抓了出來，這也直接促成了 Flame Ocean 的字庫檢索和替換工具的完成。

刷！到！設(shè)！備！里！

研究推進(jìn)到一定階段之后，有一件事必須搞清楚：刷機(jī)有沒有簽名校驗(yàn)？

不管固件逆向做得多漂亮，如果設(shè)備在寫入時(shí)會(huì)驗(yàn)證固件簽名，一切努力都白費(fèi)。我先讓 GLM 掃了一遍固件，問它有沒有發(fā)現(xiàn)任何簽名校驗(yàn)或安全防護(hù)機(jī)制。它言之鑿鑿地說：沒有找到任何防護(hù)措施。

但這個(gè)結(jié)論站不住腳?！笡]找到」不等于「沒有」這是個(gè)典型的條件概率問題，就像統(tǒng)計(jì)學(xué)里 p 值不顯著不能說明沒有效應(yīng)一樣。沒有證據(jù)不是沒有的證據(jù)。于是我換了要求：不能憑空下結(jié)論，必須用反編譯數(shù)據(jù)做實(shí)際佐證，找到代碼，看到邏輯，才能說話。

接下來我讓模型 M 認(rèn)真去掃，還真找到了東西，固件里有一個(gè) CRC 校驗(yàn)的函數(shù)。但這個(gè)函數(shù)非常奇怪：返回結(jié)果只有 8 bit。與此同時(shí)，固件最尾端有一段數(shù)據(jù)，結(jié)構(gòu)上看起來非常像某種校驗(yàn)哈希。之前我大概研究過一下，Rockchip 自己有一套叫 RKCRC 的算法，這段數(shù)據(jù)的位置和格式都很符合。但追了半天也找不到任何驗(yàn)證邏輯去讀取或比對(duì)這段數(shù)據(jù)。

結(jié)論和直覺完全對(duì)不上：從固件結(jié)構(gòu)來看，它應(yīng)該有校驗(yàn)；從代碼邏輯來看，找不到任何地方在做校驗(yàn)。

靜態(tài)分析給不出確定答案，于是我頭鐵直接把做了一點(diǎn)修改的刷機(jī)包塞到了機(jī)器里。它真的一點(diǎn)校驗(yàn)都沒做就把我的固件包給吃下去了，中間沒有任何攔截。我去問了群里做硬件的群友。他們告訴我，這類低端 MP3 設(shè)備校驗(yàn)一般做在刷機(jī)軟件里，不做在硬件上。而且 Snowsky 這臺(tái)設(shè)備的刷機(jī)方式本來就很奇特，你只需要把刷機(jī)包復(fù)制到根目錄，設(shè)備開機(jī)自動(dòng)檢測(cè)到就會(huì)升級(jí)，不需要專用的刷機(jī)工具。so……

也有群友告訴我，哪怕很多車機(jī)的固件升級(jí)也不會(huì)做任何完整性校驗(yàn)，如果你把下載了一半就斷掉的固件喂給它，你的車就會(huì)被刷成超巨大黑磚——也算是長(zhǎng)見識(shí)了。

工具的成型

研究材料都備齊了，接下來就是寫一個(gè)小工具，用來做資源編輯和替換。整個(gè)工具是用 Svelte 搞的，我基本也沒親自動(dòng)手寫，直接讓 LLM 幫忙做了簡(jiǎn)單的組件封裝，界面突突突就給做出來了。說真的我也沒太在乎美丑，就是個(gè)實(shí)用工具而已。

出于好玩的心態(tài)，我給這工具起了個(gè)名字叫 Flame Ocean——as you can see, Snow Sky 的相反。工具寫完扔到了 Reddit 上，幾乎是同一天立刻就有人把 Boot Screen 動(dòng)畫換掉了，還發(fā)了個(gè) PR 過來，可以自動(dòng)把視頻變成序列幀動(dòng)畫（雖然那 PR 的品質(zhì)有點(diǎn)低，我花了一整天才把它的 UX 修到可以接受的水平，但還是感謝社區(qū)參與）。

后面陸續(xù)開始出現(xiàn)各種改 Mod 的案例，前幾天都是簡(jiǎn)單開機(jī)畫面魔改。上傳官方 firmware 到 flame-ocean.not.ci，點(diǎn)一下「Replace Image」、下載新 bin 文件、刷機(jī)。幾分鐘后，你的二刺猿老婆就住到設(shè)備里了。

再過幾天，更加徹底的魔改皮膚開始出現(xiàn)。我最喜歡的是這個(gè)破真磁帶機(jī)主題、EVA 主題、 Fallout 主題。這個(gè)仿 macos 的主題也挺好玩的，而且作者提出了 pixel perfect 的重要性。

社區(qū)的環(huán)境也挺不錯(cuò)的。后面出現(xiàn)了一個(gè)網(wǎng)站專門收集魔改固件。如果有新手提問，沒過多久就會(huì)有人在下面答疑，來自社區(qū)的魔改教程文檔也開始出現(xiàn)了。

▍當(dāng) LLM 變成老虎機(jī)

關(guān)于大語言模型的心理健康風(fēng)險(xiǎn)，現(xiàn)有的討論集中在兩個(gè)方向：用 LLM 做心理咨詢反而讓心理變差，以及用 LLM 寫代碼產(chǎn)生冒牌者綜合征。這兩個(gè)問題都有人講過，我不想重復(fù)。

整個(gè)逆向工程項(xiàng)目期間，我把很多晚上耗到凌晨三點(diǎn)。同學(xué)在小組作業(yè)會(huì)議里聽到我的聲音，問：你還好嗎？我說沒事很好。但我手表告訴我已經(jīng)長(zhǎng)期處于應(yīng)激狀態(tài)，身體和心理都在承受持續(xù)的消耗，我自己完全沒有察覺。

原因不是項(xiàng)目難，而是大語言模型制造了一種極高密度的實(shí)時(shí)正反饋。

每發(fā)出一個(gè)任務(wù)，五分鐘內(nèi)就有進(jìn)展報(bào)告。每份報(bào)告都把當(dāng)前的進(jìn)展描述成突破性進(jìn)展。解決一個(gè)子問題，立刻暴露出下一個(gè)子問題在等待。這個(gè)循環(huán)沒有自然的停頓點(diǎn)，沒有「今天做完了」的時(shí)刻，只有永遠(yuǎn)的「再推一步就出來了」。

對(duì)于 ADHD 患者來說，這個(gè)模式和賭場(chǎng)老虎機(jī)在神經(jīng)機(jī)制上是同構(gòu)的。老虎機(jī)的設(shè)計(jì)原理是變比率強(qiáng)化，不是每次都贏，但贏的時(shí)刻不可預(yù)測(cè)，這種不確定性制造的多巴胺刺激比固定獎(jiǎng)勵(lì)強(qiáng)得多。大語言模型的協(xié)作過程完全符合這個(gè)模式：大多數(shù)時(shí)候在推進(jìn)但沒有突破，偶爾突然跳出一個(gè)關(guān)鍵發(fā)現(xiàn)，然后立刻又陷入下一個(gè)未知。你永遠(yuǎn)不知道下一個(gè)任務(wù)書執(zhí)行完是平淡收?qǐng)鲞€是重大突破，但你迫切地想知道。

再來一把。再推一步。說不定這次就出來了。

這件事對(duì)普通人也有影響，但對(duì) ADHD 患者的殺傷力則是另外一個(gè)故事。

ADHD 的核心機(jī)制之一是執(zhí)行功能出現(xiàn)問題，他們難以啟動(dòng)任務(wù)，但一旦進(jìn)入高度感興趣的狀態(tài)，又極難主動(dòng)脫離。這不是意志力問題，是神經(jīng)層面的調(diào)節(jié)困難。大語言模型的高頻反饋恰好精準(zhǔn)地觸發(fā)了這個(gè)機(jī)制的第二面：它不停地用小獎(jiǎng)勵(lì)把你釘在椅子上，讓你的大腦持續(xù)處于「再做一點(diǎn)就完成了」的錯(cuò)覺里。

與此同時(shí)，我對(duì)這個(gè)項(xiàng)目的難度存在系統(tǒng)性低估。我不懂逆向工程，所以我評(píng)估不出來「找到 Unicode 到字形的完整映射公式」這件事究竟有多難。不懂的人傾向于低估難度，低估難度就會(huì)持續(xù)覺得「馬上就好了」，而大語言模型每次給出的進(jìn)展報(bào)告又在不斷強(qiáng)化這個(gè)錯(cuò)覺。我在想象這件事成功的樣子，我在追逐一個(gè)我以為觸手可及但實(shí)際上還很遠(yuǎn)的終點(diǎn)。

這是一種很隱蔽的痛苦，一點(diǎn)一滴的把你的精力榨干。你不會(huì)覺得自己在受苦，你會(huì)覺得自己在全力沖刺。直到精疲力竭你才意識(shí)到某種痛苦，但是人卻完全無法脫離這個(gè)高速反饋的實(shí)時(shí)環(huán)境。

冒牌者綜合征的問題是：LLM 替你做了事，你懷疑自己的能力。這是一個(gè)關(guān)于自我認(rèn)知的問題。

我描述的這個(gè)問題不同。它不質(zhì)疑你的能力，它消耗你的身體。它利用的不是你的不自信，而是你對(duì)進(jìn)步的渴望、對(duì)完成的執(zhí)念、以及你大腦里那個(gè)停不下來的獎(jiǎng)賞回路。它和賭博成癮、手機(jī)上癮的底層機(jī)制是一樣的，只是包裝成了「我在做一件很有意義的事」。

在我寫這篇文章的當(dāng)下，所有待解決的問題還沒有清理干凈。我也沒有找到一個(gè)好的方法在保持高效協(xié)作的同時(shí)主動(dòng)踩剎車。我能做到的只是把這件事說清楚，讓下一個(gè)陷進(jìn)去的人至少知道那種停不下來的感覺不只是熱情，也是一個(gè)需要警惕的信號(hào)。

▍So What

通過這一頓狂暴折騰，逆向工程基本上是跑通了。我用 LLM 寫了各種調(diào)試用的小工具，甚至還寫了個(gè)很小的硬件模擬器模擬字符渲染，最終把字庫渲染那一坨給基本搞明白了。

但這個(gè)過程也讓人有點(diǎn)擔(dān)心。

你想想，我，一個(gè)只做過前端、只會(huì)解混淆 JS 的菜狗，靠著兩個(gè) LLM 吵架，就能把一個(gè)設(shè)備的底層固件給拆得七七八八。這意味著什么？這意味著未來「腳本小子」的門檻被無限拉低了。

而且，那個(gè)全自動(dòng)的未來已經(jīng)很近了。

最一開始我還是那個(gè)坐在中間手動(dòng)傳紙條的人：從 NotebookLM 取任務(wù)書，貼給 GLM 執(zhí)行，把報(bào)告取回來，再送回 NotebookLM。整個(gè)流程是自動(dòng)化的，但調(diào)度靠人。NotebookLM Skill 的出現(xiàn)把這一步也省了，我只需要坐椅子上盯著就行了。

另外，DeepSeek 最新發(fā)表的稀疏注意力機(jī)制，在相當(dāng)程度上緩解了本文反復(fù)提到的那個(gè)核心痛點(diǎn)：上下文一長(zhǎng)模型就變?nèi)酢Ｈ绻@個(gè)問題被真正解決，「人」的參與空間會(huì)進(jìn)一步被壓縮，原本需要人來判斷「現(xiàn)在該切到哪個(gè)模型」的那個(gè)決策，也開始可以被自動(dòng)化。

更值得警惕的是另一件事：很多能力很強(qiáng)的大模型是開源的。這意味著只要你有足夠的算力，相當(dāng)多大語言模型的行為可以完整運(yùn)行在你自己的機(jī)器上，不經(jīng)過任何第三方服務(wù)，不受任何平臺(tái)審計(jì)。一套完整的逆向工程流水線從固件掃描、反編譯、漏洞識(shí)別、利用路徑推導(dǎo)，這當(dāng)中的每一步理論上可以在任何人的地下室里全天候不間斷地跑，針對(duì)任何一個(gè)目標(biāo)。

目前這條路還有一道真實(shí)的門檻：小模型的推理能力依然不夠。IQuesta Coder 這類自稱 SoTA 的輕量模型，在面對(duì)稍微復(fù)雜一點(diǎn)的工程任務(wù)時(shí)，連 OpenCode 的基本文件編輯命令都拉不利索，更不用說獨(dú)立完成完整的逆向分析鏈條。復(fù)雜項(xiàng)目依然需要大模型，大模型依然需要算力，算力依然需要錢。這道門檻現(xiàn)在還在。

但它在變低。

我做這個(gè)項(xiàng)目的出發(fā)點(diǎn)只是嫌一臺(tái) MP3 的 UI 太丑。沿著這條線走下來，在一個(gè)完全不是我專業(yè)領(lǐng)域的方向上，借助兩個(gè)模型和一份手冊(cè)，把一顆嵌入式芯片的字符渲染管線從頭到尾摸了個(gè)七七八八。我不是安全研究員，我沒有逆向工程背景，我只是有耐心，會(huì)提問，懂得什么時(shí)候該喂什么信息。

如果這件事?lián)Q成一個(gè)真正懂安全的人來做，換成一套自動(dòng)化的流水線來做，換成一個(gè)不需要睡覺、不會(huì)情緒崩潰、上下文永遠(yuǎn)干凈的系統(tǒng)來做，它能做到什么程度呢。

或許不會(huì)有白癡希望把自己車機(jī)的開機(jī)畫面改成二刺猿老婆，但是你正開在高速上突然車機(jī)上跳出來一個(gè) Jump Scare，也挺嚇人的。

那個(gè)全自動(dòng)的未來不是科幻，它已經(jīng)在路上了。

后續(xù)：做了一些深度 Hack 把設(shè)備搞磚了，然后 Claude 一頓神操作，進(jìn)了 maskrom，連 loading bin 都不需要直接就把磚了的設(shè)備給刷回來了，這神秘的世界……

https://sspai.com/post/106443?utm_source=wechat&utm_medium=social

作者：LOSSES

責(zé)編：克萊德