thalk

乘數、倍化，而不是最佳化

Wed, 15 Jul 2026 00:00:00 GMT

AI 寫程式已經熱好一陣子了，而你那些不能/不會寫程式的朋友，現在都在產程式碼、部署新的服務。對軟體工程師來說這在合理不過了：有神秘小精靈會幫你把繁瑣的工作做掉，讓你能把時間用在更寶貴的事物上。但我觀察到，對於那些寫碼上癮的跟持續抗拒使用的，扔有不小的想法差異。

我自己的經驗是，在成果產出上面有接近 100 倍的速度，但也有人說這幾乎啥也沒變。

這麼確實的差異，讓我想起一段小時候剛學騎腳踏車那時的事情。第一次學會自己騎行的時候，立刻感受到風從我髮際略過，而我正以前所未有的速度「狂奔」。這種近乎自由的感覺貫穿了我全身經脈，我感覺我真能去往任何地方。

「這好偉大喔！」我對我爸說「是很偉大」他回「但不要因此志滿而止步，而忽略掉了其他偉大的東西。你未來可能還會騎摩托車、開車甚至開飛機、坐火箭。」他停頓了一下，然後說出了影響我至今的一句話：

「你腳踏車騎得再好，也上不了太空」

但這跟用 AI 寫程式有什麼關係？

一般可能會覺得，這就只是有多會使用這個「新工具」的技巧差異，是術而不是道法、是專業領域的範圍而已。不過其實從我跟許多包含技術與非技術出身的使用者聊過，發現大家在各具體工作事項上的加速，其實都差不多（大約十倍），而且希望維持品質的話，還是需要人為介入審閱。我自己的體感是：以往需要大約三天完成的事項，現在可以壓縮到三小時內完成。雖然已經很可觀了，但跟我前面所說的百倍加速有不小的差異。

所以差異在哪？我在打臉自己嗎？

沒有，而且更極端點的話，我甚至覺得特定工作條件下，進步速度甚至可以達到千倍。其中第一個錯位來自於「速度是怎麼被衡量與觀察的」。單一產品功能與一個完整的服務產出是兩件事情，所以當我只把 AI 當成「程式碼產生器」，那我頂多就是來個十倍的加速而已。

但產出從來就不只是「噴出程式碼」而已。

如果你將大語言模型視為「結構重組的方法」，並將他用到流程中的方方面面，最後衡量整體產出，那你個觀點就有根本性的變化了。你已經不是把你的技能「外包」給一個工具，而是重建整個進步的循環。然而一開始，這其實還蠻讓人失望的：因為你的增幅下降了。你可能得花 6 小時，因為需要處理不同階段間，額外的內容和結構的轉換。但這是短空長多：你犧牲了一點開發速度在生成各類副產出上，而這些輔助了跟人類的來回溝通，最終可能解省數週以上的時間。

然後神奇的事情開始了。雖然對於代碼階段的效率是次佳，他仍是個四到五倍的效率。而這個效率現在可以被同時應用到其他相關的工作上：文件產出、背景知識管理、系統對齊整合、規格確認、測試、安全檢查，所有你想得到的方面。而且更棒的是，很多這類工作因此開始變得可以平行處理，當然你得把工作流程設計設計得好（但這也可以用這新方法做到）。

而當你回頭看，在整個開發週期中，三小時與六小時造成的實質差異其實很小。想想以往有多個關係人的情況，一個兩週的 sprint 搞定一切是大家腦中的美夢，但現實是殘酷的：你還得回頭面對行程表、意見搜集、產報告、等回饋：特別是在高脈絡的溝通環境中。這時花多久把代碼寫出來根本就不是瓶頸了，節奏對齊才是。三天完成工作，抓點摸魚的緩衝其實就是一週，然後另外一週你會拿來估開發點數、排優先級、審閱、會議然後拆解所有人的想法。

但同樣的東西可能塞在一天、最多兩天完成。六小時剛好讓你一天搞定後，趁人下班前拿到最快的回應。同時執行過中所自動捕捉的那些訊息，可以讓你的文件保持實時的更新，隨時轉換成審閱階段或是直接分支開展新工作。你也更容易配合那些相關人士的行程，因為你的工作變得更加碎片單元化了。你可以把各種殘枝片羽拿給他們看，然後叫你的系統在週末前就進行下一階段的預備。

一個可能需要三個 sprint (大約六周) 的工作，現在可能兩天就好了。而你現在可以專心對待現存此地的人們，並同時開展多個事項。

如果你目不窺園的專注在「我到底省了幾個小時」，那以上這些都不會發生了：因為省時間這個動作是最佳化。最佳化適用的是場景與定義完整、熟練度導向的問題。但如今這是一個生產方式上的改變，那麼核心問題就不會只是「你能多快做好」而是「你能怎麼做好」。每一個小進步會複合起來，累積成一個對整體而言巨大的乘數。

這個綜合效果是有根本不同的，因此最終成果是單純的最佳化永遠無法企及的。用 AI 更快的寫出程式碼是在成為偉大的自行車手；而重構你的整個交付流程，進而倍增每一步的收穫，這才是在打造火箭。

比工具活得更久的地方

Sun, 12 Jul 2026 00:00:00 GMT

我發過文的每一個平台，最後都要求我改變。動態重新排序了。編輯器長出了付費牆。依賴的 API 只提前六週宣布將被淘汰。這些都算不上惡意——平台本來就是這樣運作的。但每一次，我的書寫都得繞著別人的路線圖轉；每一次，我對自己做出來的東西，都少擁有了一點。

thalk 是我不想再當租客的嘗試——不想再租自己的內容。

它是我思考、也是我說話的地方——名字就是這麼來的。它同時是我對未來走向的一個小賭注：人與社群把小而精巧、專門打造的服務完全握在自己手裡，而不是把形形色色的需求，全塞進那個我們稱之為平台的沙丁魚罐頭。

整個網站，就是 git 倉庫裡一堆純 markdown 檔案。這不是實作細節，而是核心主張。那些檔案就是唯一的真實來源——不是資料庫，不是 CMS，也不是某個服務的匯出按鈕（還得祈禱我要用的那天它仍然管用）。發布，就是一次 git push。如果我明天想離開 GitHub，複製一個資料夾就好。沒有東西需要遷移，因為從一開始就沒有任何綁定。

下游的一切，都刻意安排成能在一個下午內替換掉。網站的「產生器」是我自己寫的幾百行程式碼，不是我得一直追著更新的框架。頁面是靜態的：就算所有動態的部分——表單、電子報、雲端函式——同時全部熄燈，那些文字依然會以純 HTML 靜靜躺在那裡。每一個會動的零件，我都寫下了一條逃生路線，好讓任何單一服務都無法挾持其餘的部分。

這份擁有，有一部分關乎誠實，而不只是耐久。這是一個為多種語言而生的網站；對我而言，它們每一種都應該是原稿——常常不是彼此的翻譯，而是同一個念頭，為不同的讀者重新說一次。當然，受限於我個人的能力，我沒辦法每一樣都親手打造：我只精通英文與中文，日文僅有入門程度，而且還有點懶。這就是為什麼我會借助工具來拓展邊界。當某個頁面確實是機器產出的——AI 翻譯，或是我借助模型草擬的東西——它會在頁面上明白說出來。（這一篇就是。）我寧願你信任屬於我的部分，是因為你看得見哪些不是。

最後一項原則，是節制。沒有留言系統，沒有分析儀表板，沒有後台，也沒有任何「因為做得到」而加上的功能。東西只有在更簡單的版本真的被用過、也真的不夠用之後，才會出現。人很容易把一堆功能誤認成一件完成的作品；我寧願它小到能一次就整個裝進我的腦袋裡。

而結果非常棒——至少對我來說。即使要同時經營多種原生語言，整個管理流程也精簡得多，還能做出俐落、帶點獨立氣息的電子報。

這些都不會讓文字本身變得更好。但它們讓文字是我的——耐久、可攜、誠實，而且簡單到能被完全理解。在寫下任何一個值得留下的字之前，這感覺才是站得住腳的地基。

小而自持的工具

Sat, 11 Jul 2026 00:00:00 GMT

這個頻道，是靠一些我隨時能在一個下午內重寫的工具在運作的。

每一個你並不真正擁有的服務，背後都有一種安靜的代價：它哪天改了定價、改了 API、或者改了主意，你的成果就得繞著它轉。所以我一直在做減法。你正在讀的這個網站，是幾百行我自己寫的程式碼——沒有框架，沒有 CMS，只是把 markdown 變成 HTML。訂閱名單，是 git 倉庫裡的一個檔案。萬一哪天壞了，我很清楚該去哪裡找。

小工具一開始要求得更多。那些邊邊角角都得自己扛：跳脫字元、日期格式、還有那個彆扭的第二語言。但它也回報你一些難以用錢買到的東西——那份「你和你的作品之間，沒有任何東西會悄悄消失」的篤定。

我不覺得這套做法適用於所有事情，也無意把它變成那樣。只是偶爾，能親手做出一個能一次就整個裝進腦袋裡的東西，感覺挺好的。

哈囉，thalk

Wed, 08 Jul 2026 00:00:00 GMT

這裡是 thalk — 我用來記錄思考、書寫與未竟之作的個人頻道。

這裡的一切都始於一個 git 儲存庫裡的 markdown 檔案。一支我自己掌握的小程式把它轉成你正在讀的頁面；中間沒有 CMS、沒有框架、沒有任何平台。如果你想持續追蹤，可以透過 RSS 訂閱源，或加入電子報 — 每頁底部都有訂閱框。

更多內容，敬請期待。