一句「非官方專案」先被寫進了 README：Listary 的重寫，是一頁被排好的工作流

2026 年 10 月 16 日晚間，V2EX 上出現一則標題簡短的帖子：「用 rea 重寫一切，這次是 listary」。發文者 zhaohua 說，Mac 上一直找不到好用的檔案查找工具，於是用逆向工具 rea 拆了 Listary 的 Windows 版本，重寫出基本功能可用的 Mac 版本，並附上 GitHub 連結。這篇帖子不到一天累積六千多次瀏覽，而專案的壽命比討論還短：數小時後作者自行刪庫，理由只留下一句「你說的對，rea 本來就不對，不應該分享」。

整場事件最有意思的地方，落在幾個被寫出來的細節上。

第一個細節是那句免責聲明。README 裡先寫了「非官方專案，與 Listary 及其開發者沒有關係」，但專案名稱仍直接沿用了 Listary。樓下 hanru 的回覆抓的正是這個縫隙：既然聲稱無關，就不要用這個名字。這是開源界一個老問題的新版本，免責文字和命名權之間的張力，在 AI 讓重寫門檻大幅降低之後只會更常見。名稱是最短的介面，借用它就等於借用了十幾年累積的使用者信任。

第二個細節是作者在補充說明裡交代的工作流。安裝 rea、下載 Windows 版本、讓 Claude 接入逆向環境、把 Listary 官方幫助中心的連結餵給它，先產出 prd.md 和 design.md，再討論核心功能、定好驗收規範，產出 plan。實作交給 DeepSeek 按 plan 執行，Claude 負責整體的性能與功能驗收。這裡值得注意的排序：幫助中心的文件先於原始碼被讀取，產品的自我描述先於產品的實作被消化。也就是說，這次重寫真正參照的藍本，是官方文件構成的「產品規格敘事」，逆向程式碼反而像驗證材料。文件的優先順序，本身就是一種設計決策。

這種把信任與規則先寫進介面的做法，我們在YourKeep 的贈送規則設計裡也看過類似結構：順序和措辭先於功能，決定了別人怎麼讀你。

事件的最後一個畫面，是 Listary 作者現身留言串。使用者 explorerproxy 貼出向官方詢問 Mac 版的回覆，並註明「作者回復的」：Windows 版正在更新 7.1 beta，因為換了框架，macOS 版本也要跟著重寫一遍，「雖然 macOS 版本還沒有發，但是已經寫了兩遍啦」。這段輕鬆的口吻背後，是一個很實際的對照：官方為了跨平臺重構付出的是框架級的工程成本，而帖主用 AI 工作流在數小時內拼出了基本可用的替身。兩者的差距不在功能完成度，而在拼音搜尋、Finder 自動跳轉這些十幾年打磨出來的細節，以及效能。帖主自己也標註了「搜尋增加目前有效能問題建議不要開啟」。

帖子裡的道德辯論很快就出現了。有人指出 Listary 沒有 Mac 版，問題不在正版與否；有人呼籲支援小軟體作者，「自己偷偷用得了」；也有人單純感嘆「大家道德都好高」。這些回覆的分歧，正好勾勒出 AI 重寫時代的模糊地帶：功能複製不等於破解，但名稱、文件與整體行為的貼近，讓「重寫」和「仿製」之間的界線變得難以用一句免責聲明劃清。

帖主的回應方式倒是乾脆：刪庫、撤回、建議大家等官方版本。在這個由 prd.md、免責條款和一句道歉構成的小事件裡，最先被設計出來的東西留了下來，那套「先文件、後實作、再驗收」的工作流，而它的第一個成品，則在社羣睜大眼睛看清之前，先把自己收了起來。