Refactoring English:第 16 個月
原文由 Michael Lynch 于 發布,訂閱此部落格
一句話總結
接近終點線了
本月亮點
- 我一口氣寫完的一篇文章登上了Hacker News 首頁。
- 我預期未來幾年軟體安全會相當令人不安。
- 我的家庭照片分享 App 已經完成了第一個里程碑。
目標成績
每個月初,我都會設定當月想完成的目標。以下是這個月的達成狀況:
完成 Refactoring English
- 結果:發表了一個新章節,但還沒全部完成
- 成績:C
我知道要在一個月內完成最後三章是個很有野心的目標,但我覺得做得到。結果三章只完成了一章,不過這本書已經接近完成了。
Refactoring English 數據
| 指標 | 2026 年 2 月 | 2026 年 3 月 | 變化 |
|---|---|---|---|
| 不重複訪客 | 7,788 | 6,932 | -856 (-11%) |
| 預購收入 | $886.20 | $725.80 | -$160.40 (-18%) |
這個月的瀏覽量和銷售額稍微下滑,但我很高興看到,即使沒有成功的推廣活動,讀者和客戶的流量依然穩定。
這個月我唯一的推廣是一篇名為《哪份設計文件是人類寫的?》的文章。它在Lobsters 上表現不錯,但在Hacker News 上反應冷淡。/r/programming 版甚至以「AI 生成」為由拒絕了它,即使我已經私訊版主說明文章本身是人寫的。
這篇文章的靈感來自上一堂 Refactoring English 的線上直播課。我們在課上討論 AI 是否已經強到能寫設計文件,我突然意識到,要把我剛手寫好的設計文件用 AI 生成幾個不同版本是多麼容易。讀著大家對不同設計文件的猜測、看他們指出哪些「破綻」暴露了是人寫還是 AI 寫的,十分有趣。
發現一個「Simon Willison 式」的機會
過去三年來,Simon Willison 一直是 Hacker News 上最受歡迎的部落客。我最近寫過 Willison 那個少有人用卻很有效的部落格策略:
Simon 經常從封閉式平台(例如 TikTok、Twitter)裡發掘點子,然後單純地把它們搬到開放網路上,讓 HN 更容易討論。他最受歡迎的幾篇文章,有些就只是短短的引言或連結加上一點評論。「我很擔心他們把 Copilot 放進 Excel」就只是他從 TikTok 上看到的一段影片引言。「電腦永遠無法被究責」則是 Simon 整理了幾則推文的總結。
Simon 把這種做法稱為「一種低投入、高回報,為整體網路生活做出貢獻的方式」,我完全同意。
Willison 這個策略唯一困難的地方,在於辨認何時該出手。如果你只是隨機摘要推文和 TikTok,大概不會引起什麼迴響。你必須察覺到某些有趣的資訊被困在不利於網路傳播的格式裡,然後趁著還新鮮的時候,把它搬到開放網路上。
上週,我看了 Nicholas Carlini 的「Black Hat LLMs」演講,意識到這正是運用 Willison 技巧的機會。
在演講中,Carlini 描述了他如何發現一個藏在 Linux 核心長達 23 年、無人察覺的可遠端利用漏洞。最令人驚訝的是,任何人都能複製 Carlini 的做法。他只是把 Claude Code 指向 Linux 核心原始碼中的每個檔案,然後請它找出漏洞。
我在網路上搜尋關於 Carlini 這項發現的討論,卻驚訝地發現幾乎沒人在談。它已經發表在 YouTube 上,也在 Hacker News 的討論串中被提到,但關注度遠低於它應得的。大家都在大肆討論 Claude Code 為一個 FreeBSD 漏洞寫出攻擊程式,但我覺得這個發現才是更大的新聞。
結果證明我的判斷是對的。
我花了三個小時一口氣寫完那篇文章,遠比我平常花費數週、10 到 30 小時的寫作流程快得多。這篇文章至今已吸引了 4.1 萬名不重複讀者,在Hacker News 和Lobsters 上都表現不錯。儘管我根本沒把它發到 Twitter 上,卻有將近一半的讀者是透過 Twitter 找到這篇文章的。
過去,當我個人部落格上的文章爆紅時,很多讀者會進一步深挖,進而發現 Refactoring English。這次卻沒有發生,我猜是因為對 AI 感興趣的讀者,對於一本教人不用 AI 寫作的書比較沒興趣。
未來幾年軟體安全會很難熬
Carlini 的演講點出了我這幾個月來一直在思考的事:未來幾年,資安領域會相當難熬。
過去,一般人之所以還能多少免於網路攻擊,是因為找出安全漏洞的成本很高。
舉例來說,想像半年前你想駭入使用 Syncthing(一套開源檔案同步工具)的使用者。除非你本身就是軟體安全專家,否則你得去雇一個符合以下條件的人:
- 很會找漏洞
- 願意收錢把漏洞武器化
- 願意跟陌生人合作
假設你真的找到一個願意用 5,000 美元幫你找出並利用 Syncthing 漏洞的人,那依然要花很多工夫和金錢。而且這還是假設你雇到的人是真有本事,而不是來詐騙的。
就算你費盡千辛萬苦做到這一步,每次使用這個攻擊手法時,你還得冒著「燒掉」它的風險。如果有人發現自己的系統被入侵,並追蹤到是 Syncthing 的問題,他們就有可能辨識出你的攻擊手法並回報漏洞,讓你的 exploit 變得一文不值。
對比一下現在的情況。你只要花每月 100 美元訂閱 Claude Code,就能像 Carlini 那樣找到重大漏洞。Claude Code 的防護機制會拒絕將漏洞武器化的請求,但用不了多久,你就能用開放權重的模型偷偷開發攻擊程式,而不會有任何 AI 廠商來告訴你不行。
所以,開發攻擊手法的成本已經大幅下降,但修補漏洞的價值卻維持不變甚至更低。AI 生成的漏洞報告多到讓廠商紛紛關閉他們的漏洞懸賞計畫,讓誠實的研究人員拿不到任何報酬。
Carlini 的成果並非僥倖。我複製了他的方法,沒花多少力氣就在一個熱門的程式碼庫中找到了尚未被發現的遠端程式碼執行漏洞。我大概還能找到更多,但對我來說這麼做的財務價值是負的,因為該專案沒有漏洞懸賞,我得花好幾個小時無償與廠商協調修補。
並不是有什麼貪婪的億萬美元大公司拒絕為我找到的漏洞付費。維護者就只是個出於善心在做這個專案的普通人。基本上就是xkcd 那篇〈Dependency〉的現實版。他也沒錢為漏洞報告付費,因為他自己也沒拿到報酬,儘管有許多市值數十億美元的公司確實在用他的程式碼:

xkcd #2347,〈Dependency〉
最終,我們會回到一個平衡狀態,到時候 AI 安全工具會像今天的靜態分析工具一樣便宜又方便。廠商會在產品上線前就用 AI 攔截安全問題。
但在短期內,有大量漏洞突然變得唾手可得;對攻擊者來說利用它們很有價值,但對誠實的研究人員來說修補它們卻沒什麼價值。
達成 Little Moments 的第一個里程碑
早在去年 12 月,我就宣布要打造一個免費、開源的寶寶照片分享 App,因為我討厭現有的選擇。
我本來以為這個 App 可以輕鬆地用 vibe coding 搞定,但後來意識到這是個練習寫設計文件的好機會。我一直在為 Refactoring English 撰寫設計文件的流程,但我已經快十年沒寫過一份真正完整長度的設計文件了。
當用 vibe coding 在短期內能帶來那麼多滿足感時,要我坐下來寫設計文件真的很難。這就是為什麼從 12 月拖到現在,但我終於專心把 Little Moments 這個 App 的設計文件寫完了。設計文件一完成,剩下的就簡單了。
目前,你可以匯入從TinyBeans 匯出的資料並在本地端呈現。我不想公開真正的私人家庭照片,所以我建立了一些假資料來測試:
即使只是這樣最基本的實作,我也覺得非常令人興奮,迫不及待想把它完成。
如果你從沒用過 TinyBeans 或 PhotoCircle,可能會覺得我為這麼陽春的 App 原型感到興奮很奇怪,但我怎麼強調都不為過,那些 App 的使用者體驗有多糟糕。
就連瀏覽下一張、上一張照片這種最基本的操作,在 TinyBeans 上都無法正常運作。如果你正在看一張照片,你得先退回照片索引頁,再去找下一張。而且這還是在手機 App 上。在網頁版上,你甚至無法依序瀏覽照片,只能在行事曆上翻找。除此之外,到處都是廣告和付費推銷,而且一切都慢得令人痛苦。
Little Moments 速度超快,而且我還加入了鍵盤快捷鍵和手機滑動手勢,讓瀏覽更加輕鬆。我很期待把這個 App 完成,好徹底擺脫 TinyBeans。
總結
完成了什麼?
- 發表了〈Claude Code 發現了一個藏了 23 年的 Linux 漏洞〉
- 發表了〈哪份設計文件是人類寫的?〉
- 發表了 Refactoring English 的「Help the Reacher Reach Their Goal」章節
- 完成了第一次對 Firefox 的貢獻,一個防止畸形 Ogg 檔案導致當機的小修正。
學到的教訓
- 未來幾年資安會很不好過
- 對惡意人士來說,找漏洞從未如此容易,而對想修補漏洞的誠實研究人員來說,回報卻越來越少。
下個月的目標
- 完成 Refactoring English 的撰寫
隨機一篇部落格
留言
登入後參與討論