Weekly Issue 第 21 期：JetBrains 發表 2025 Go 生態系調查
最近在讀 Tony Fadell 的 "Build"，作者曾經參與過 iPhone 的開發，各種經驗談讓人嘆為觀止，例如這段：「如果故事有某個部分銜接不上，那麼產品本身也會有某個地方行不通…這便是為什麼最後 iPhone 的表面是玻璃，而不是塑膠，以及為什麼 iPhone 沒有硬體鍵盤。」
好在哪呢？好在如果能掌握這個觀念，就能知道如何「閱讀」產品，看見一個產品，就像閱讀一則故事一樣，知道它的抑揚頓挫，知道它想表現的東西。我相信每個經歷過產品開發的人，看這本書都會很有感覺。
🗞️ 熱門新聞
The Go Ecosystem in 2025: Key Trends in Frameworks, Tools, and Developer Practices
JetBrains 前陣子公布 Go 生態系的調查結果。
除了 IDE 跟 AI coding assistants 中，JetBrains 的占比遠高於我的預期外，倒是沒太多意外。
值得注意的是產業分布，網路應用與雲端基礎建設維運仍然占大宗，JetBrains 今年另有一篇 "Is Golang Still Growing" 講得很詳細。
Liquid Glass Is Cracked, and Usability Suffers in iOS 26
看到一篇從設計層面批評 Apple 的 Liquid Glass，「（新的）視覺語言讓內容變得模糊不清，而非讓內容成為焦點。」
我至今還是不知道 Liquid Glass 的用途是什麼（有人提到為了三維空間的體驗，也許吧），對我來講比較大的問題是辨識度下降與多餘的動畫。非常好奇它的發想情境是什麼。
✨ 科技觀點
Hacker News - The Good Parts
我很常逛 HN，剛發現有人針對 HN 的討論風氣特別寫了一篇，稱讚它能滿足讀者的求知慾，對我來說確實如此。
社群是非常難的題目，不知道 HN 是如何做到，以及這會不會只是個暫時的現象？前陣子跟朋友聊天時提到，私人社群需要「即時訊息」的功能，例如 Discord，但 HN 顯然更偏向長文思考。
AI's Dial-Up Era
最近跟朋友在討論 AI 到底是不是泡沫，我沒答案，但是很喜歡這篇講的 Jevons Paradox: "效率的技術改進會導致該資源的總消耗增加，而不是減少。"
用比較通俗的講法：改善工作效率會讓你更忙，而不是更輕鬆，因為當你有空時，你會被安排更多工作。雖然這是個悲觀的觀點，畢竟從本質上，能改善效率，意味著你更理解這份工作本身。
有好幾次我都覺得現實比我想的複雜，我用 LLM 規劃旅遊行程，而 LLM 卻不知道假日鐵路停駛。它更像是個新的工具，而不是應用本身。
The Future of AI History
Chrome 當年曾打算保留所有用戶的瀏覽紀錄，並讓你可以訪問，從中發掘出自己的 insight（例如，我都是在看旅遊網頁，或者我平均的網頁停留時間）。
這個計畫最後失敗了。因為「這並不重要。沒有人會去使用歷史記錄。他們只會再回到 Google，重新搜尋他們要找的東西。」
這對產品設計，特別是 AI 的產品設計來說，的確很有啟發。與其提醒使用者他正在使用 AI，我更傾向讓 AI 在背後給他更好的體驗。
Intentional, Not Reflexive: A Manager's Thoughts on AI
常見談 LLM 應用的文章都是談如何優化個人的生產力，這篇則是從管理的角度來談 LLM 的效果。
有意思的點是，我平常也會問 LLM 跟生產力無關的問題，但我沒意識到它是不同的用途，它在協助我「下決定」，或者是讓我意識到，我對該問題認識還不夠。
舉個例子，我會餵日記給 LLM，有時候它能幫我意識到，我在無意識繞開問題，雖然即使知道也不一定想面對，但就是一個提醒，讓我知道應該要做（或不做）哪些事。
AI Won't Generate a Good Product Idea
「我們只能在自己能想像出適當問題、提示與情境的範圍內轉換情境。初學者無法直接抵達專家領域。」
這句話不只適用 LLM，也適用管理。以前聽前輩分享，一家公司的上限通常是老闆，因為老闆沒辦法理解他不知道的東西。不是說無法從理性上理解，而是只能依賴想像來模擬動起來的樣子，但這是不夠的，我能看 Curry 打球跟我能像 Curry 打球，是兩件不同的事。
Messing with bots
看到 Bear 的開發者嘗試餵爬蟲垃圾資訊，消耗爬蟲的時間。這個點子最早是從 Reddit 或 HN 來的，用意是讓無視 robot.txt 的 AI 爬蟲吃點苦頭。
我第一時間想法是「可是這樣不是在白白消耗你的頻寬嗎？」，作者也承認，這點子不適用在生產環境，特別是你需要跟 Google 搞好關係的時候。只是 "Sometimes we can just do things for fun."
To get better at technical writing, lower your expectations
我剛成為工程師，寫技術文件時，會期待每個看完文件的人能理解系統。現在只會希望過幾個月後，重看技術文件的自己知道當時的情境。
在有工程文化的環境中，技術文件還是非常重要，它有點像是 Grove 講的「管理槓桿」，讓你知道該如何面對日常重複性的問題。
我們以前的習慣是，只要有出現問題，或者是涉及設計，我們都會建立技術文件。
📌 工程實務
如何快速上手和贡献开源项目
當你有多螢幕時，KDE 的邊緣觸發只會發生在最外層，原因是：「这样设计的动机源自费茨定律（Fitts’s Law），该定律表明：触发屏幕角落是很容易的，但在两个屏幕之间触发一个角落（一个没有视觉边界的一像素目标）则非常困难。」
看到這類原因都會有「原來如此」的念頭，有時候看其他人的網站，覺得設計不對，但進一步理解後，才發現原因比預期複雜。
you don't need anubis
看到一位開發者用 Caddyfile 配置阻擋 LLM 爬蟲。
原理是 LLM 不會執行 JS，因此只要包含簡單的 JS 就能有效阻擋，類似 Anubis，可是更簡單。
看內容，應該是真的有擋下來。但 LLM 不會執行 JS 還是讓我挺訝異的，照這樣講，他們連動態內容都爬不到？
How We Saved 70% of CPU and 60% of Memory in Refinery’s Go Code, No Rust Required.
HoneyComb 談他們如何優化 Go 應用的 CPU 跟 MEM。
原則上還是老套路，用 Profling 找出熱點並改善，比較值得注意的是他們的開銷都是在 Serialization，因此他們選擇開發一套 lib 來最佳化這段。
有些問題真的只有流量大到一個程度才值得做。