Weekly Issue 第 20 期：AI 泡沫的遺產
2000 年的 .com 泡沫雖然造成嚴重的經濟問題，但也給後續的網路世代留下豐富的遺產。我們現在使用的網路基礎建設，很多是因為泡沫的原因，才能一次性投資到位。而當下經歷的 AI 浪潮，在時間過去後，又會給我們留下什麼遺產呢？
🗞️ 熱門新聞
The Benefits of Bubbles
我看 Ben Thompson 的文章通常會有兩種感受，負面是他太囉唆了，把簡單的觀念講得太長（儘管容易懂），而正面是他的觀點一向很有創造性。
這篇也是，前陣子看到有篇談 AI 泡沫後，什麼都不會留下，因為 GPU 很快會隨著時間折舊掉。我持保留態度，我認為重點不僅是 GPU（正如我認為 .com 泡沫的重點不是 CPU），還有其他的東西，至於是什麼，我沒想到。
BT 認為是晶圓製造與電力，It's amazing，這兩個題目的確是投資重點，而且也會成為遺產，想想一個電力免費的世界，能把交通成本壓到多低！
BTW，我覺得 BT 的文章真的很適合用 AI 來讀。
X's handle marketplace will sell some 'rare' usernames for millions of dollars
X 將開始販售使用者名稱，類似網域名稱，當使用者太久沒登錄（例如六個月），他的帳號可能被收回，改賣給其他人。
而且 Premium 訂閱者可以優先購買。
依照 Musk 的風格，我覺得這是個有趣的點子，反正有些帳號的確會私下買賣，平台乾脆自己來。
我只是納悶，會不會哪天連 Google 都開始幹這種事。
Dear Rubyists: Shopify Isn’t Your Enemy
看到有人在分析最近 Ruby 社群跟 Shopify 間的爭議。
我對 Ruby 社群不熟，查了點資料，大致是，Ruby Central 轉移 Gem 的管理權限，社群認為這是受到 Shopify 的影響。
當然這樣一定是過度簡化了，作者這篇文就是從參與者的角度，談他為什麼認為金錢贊助會這麼敏感，以及當企業嘗試貢獻社群時，它可能扮演什麼角色。
整篇講的很誠懇，確實也像他講的：「可持續性不只是關於金錢」
✨ 科技觀點
I analyzed 180M jobs to see what jobs AI is actually replacing today
常聽到 AI 讓人失業，但具體影響如何，很少能說得清楚。剛看到一篇用 YoY 比較各職缺變動，相對能量化 AI 影響。
從數字來看，影響最大的意創意執行工作，例如文字、攝影、美術，工程類反而影響不大。最讓人意外的是客服影響也很有限，如果你還在想開發 AI 取代客服，看完這篇可以死心了，乖乖用客服 SaaS 的 AI 服務比較乾脆。
網紅行銷是另一個成長中的領域，但我認為它還有很多問題有待解決，例如我們能明確知道哪些廣告是由商家投放，但有時不知道網紅是否收受商家贊助。信任這個問題在 AI 時代會越來越重要。
inessential: Why NetNewsWire Is Not a Web App
看到 NetNewsWire 的開發者講為什麼不開發 Web 版。
有段時間我也在想類似問題，只是我是反過來：是否需要開發 App 版？著眼點是 App 更 Mobile First，體驗更好，跟使用者溝通更順暢。
文中提到的點倒是沒想過：App 更便宜（因為不用負擔機器費用）；對使用者更自由；也更具隱私權。雖然現代架構更多是 Web / App 混合（例如 Web / App 共用後端），但確實很有趣，有些小東西放 App 或許更合適。
ChatGPT's Atlas: The Browser That's Anti-Web
看到一篇在批評 OpenAI Atlas 的文章，看得出來作者對 OpenAI 很有意見。
我看的時候在想，這是不是又是另一篇關於 "deterministic" 的爭議，我們都知道 LLM 現階段沒辦法保證相同的結果，可是這不代表它是一條錯誤的路線。作者最能說服我的觀點，大約是「為什麼這種較劣的體驗會被定位為這款新瀏覽器最頂級的部分 」，確實在現有的許多情況下，AI 瀏覽器代理會有較差的體驗。
關於體驗問題，聽其他 PM 分享過，你在設計 AI 產品時，不要讓使用者自己輸入指令，你應該引導使用者「選擇」準備好的指令，在 UX 層面，它是個可以解決的問題。
ANYWAY，我想 AI 瀏覽器代理是個還不成熟的產品，例如資安，我也不預期 Atlas 能取得成功，我只是在想它最後會留下什麼。
The compound interest of design: what not to build
我對 Dave Snyder 知道的不多，但這篇確實非常符合我對「工藝」的觀點。
以前跟主管討論產品設計，他在想，如果產品是給「所有人」用，我們需要哪些設計。我當時隱約覺得怪怪的，問題在於，「所有人」是個模糊的面貌，我們需要的是具體的對象，還有具體的理解。
以前合作的 PM，曾跟我說 Persona 像是在紮稻草人，我想他的意思是，有時我們為了讓產品看起來更有道理，會假設某些人想要我們的功能，實際上那些人並不存在。
Theory-building and why employee churn is lethal to software companies
「心智模型只能透過在專案成長過程中實際參與，或跟曾經參與成長過程的人一起工作，由對方協助你逐步吸收這套理論來學習。 」
theory-building 這個詞用得真好，開發產品也像是依照信念與理論，打造實體。這也是為什麼說產品需要解決問題，因為沒有解決問題的產品，只是開發而已，談不上建構。
也因為核心是理論，人的流動就很致命。我離開每份工作，都會留下詳細的交接文件，但每次寫的時候，都會想讀的人知道踩過哪些坑嗎？知道有過哪些假設嗎？希望他有足夠的想像力，能從這些文字重新建構起前人想打造的東西。
📌 工程實務
Feed me up Scotty
看到個專案 Feed me up Scotty，能自動把網站內容轉成 RSS。
原理貌似是爬網頁後，依照 CSS 的設定，拆出需要的 title 跟 content。現在很多 RSS Reader 都有類似功能了，例如 Feedly，只是需要進階訂閱資格。
我通常會看的網站都有 RSS 了，但這個看起來很好玩，可能改天自架一套用來看一些古老時代的網頁。
Choosing a dependency
以前提過，我在選擇開源專案時，會看它的活躍度、授權類型、生態系，只是這講法太概略了，剛看到一篇文章，講的就很詳細。
另一點我很在意，但不容易一眼看出的地方是 DX，「開發者體驗是好專案與優秀專案之間的關鍵差異 」，這不只是說有沒有文件的問題，也包括這個專案是怎麼設計。
Taking steps to end abusive traffic from cloud providers | Anubis
剛從 anubis 看到，如果有人用雲端服務，例如 AWS / Azure / GCP DDos 你，你可以寫信給雲端供應商抗議。
"Just remember that many cloud providers do not know how bad the scraping problem is. Filing abuse complaints makes it their problem. They don't want it to be their problem."
聽起來不錯？不知道成效如何就是。
Syntax highlighting
如何設計 syntax highlight？
這是個好問題，我通常都是挑個順眼的 theme，套用上去，結束。從來沒想過順眼的科學定義是什麼，對我來說，syntax lightlight 更接近 personalization，有人會在意螢幕保護程式對螢幕的保護力有多少嗎？
但真的細究還挺有意思的，我同意超出四種顏色真的太多，以及現有的 theme 對我幫助有限。比較持保留的點則是「註解應該凸顯」，這不全是設計問題，而是現在有些工具會去讀 comment 來產生指令，看不見這些無意義的 comment，對我來說比較方便。