Weekly Issue 第 26 期：AI 批評指南

最近在讀《高效槓桿力》，書中提出一套變革管理框架：「尋找關鍵支點，重新配置資源。」當然，書裡給出很多案例，說明如何找到支點，只是我同時在想，如何將他們帶到我面對的情境呢？

✨ 科技觀點

Pluralistic: The Reverse-Centaur’s Guide to Criticizing AI

看到有人非常認真討論事情，即使是批評 AI，都會讓我有興趣。

附上一些我的觀點：

1) 成長型公司聽起來很美好，每個人都會想待在那，但當它變成前提時就是另一回事了。很多決策都會以成長為基礎，最後就是投資人跟企業都沒辦法接受不成長的代價。

2) 常常在爭論 AI 是否會取代工作，看的是 AI 的兩個面向，賦能與自動化，哪個會更符合當前情境。贊同賦能的人會認為 AI 帶來生產力的解放，並創造價值，可是實際上呢？

3) 很多人提過 AI 的解壓縮 / 壓縮特性，特別是在履歷或信件應用。但我想說的是，現代訊息交互的重點不全在於訊息本身，而是訊息來源。一個由 AI 產生的推薦信跟不由 AI 產生的推薦信幾乎是同等價值。想想那句名言：「想要了解一個人，看看他身邊最密切的五個人。」

4) 這類問題在後現代已經討論很多次了，當初相機發明時，被認為輕易複製的技術會摧毀靈光，然而實際狀況複雜得多。

5) 內容創作者很少直接從內容獲利，連 Mr. Beast 都是從商品獲利。內容本身是難以擴展的 (Scalable) 的商業模式，在某種意義上，這是 Substack 市場敘事的根源，他們訴諸的不是訂閱獲利，而是讓你掌握可開發名單 (email)。

6) 「給我一個像《E.T.》的故事，不過主角是隻狗，裡面要有個愛情線，第二幕要有追車戲。」試著務實地理解這件事，從商業角度，要談的不是這個前提有多荒謬，反過來，應該說服對方，讓狗當主角的愛情故事不會賣座。

來自 Grafana 與 OpenTelemetry 的 Logging 最佳實踐

看了雷 N 整理的 Logging Best Practices 對談，對「結構化 Log」的演進很有共鳴。

當我剛開始開發軟體時，我們的軟體是個跑在客戶伺服器上的 Web-based 應用。如果要 debug，需要重現客戶環境，然後開啟 debug mode，盯著 stdout 跑出來的 log 猜測問題出在哪。

這當然費事費力，也是我們後來改用結構化 log 的主因，但改完後，我們反而收到抱怨，debug 變得更困難。原因正是因為 log 不再是 human-friendly，原本 FAE 能協助的點都無法協助，如果沒把 log 倒進資料庫，我們也很難定位問題發生點。

這種轉變是「結構化 Log」出現的背景，現代軟體已經變得太複雜，太具有依賴性，沒辦法只靠單一日誌檔處理，也就是說，新的部署與交付帶動了新的最佳實踐。如果缺少這些前置，就容易出現另類水土不服的問題。

📌 工程實務

Connection Pooling: Fundamentals, Challenges and Trade-offs

簡單幾點想法：

1) Connection Pool 是個 Engineering 的議題，而 Engineering 的價值更多體現在 Scalability 上（這也是為什麼面試時有些會問 System Design 的原因，不是因為真的用到，而是因為那更工程）。

2) 也因此，當該行業沒有面對成長問題，或者說所處領域不要求快速擴展，Engineering 的價值就不高。純工程的領域除外，例如資安，即使不需要擴展也依然需要工程知識。

3) 估算只要估到量級就好，真正的設計還是得仰賴真實指標，這也是可觀察性能幫上忙的地方，它能幫助你設計出更好的系統。