Weekly Issue 第 22 期：Google 發布 Nano Banana Pro
最近大新聞要算 Cloudflare 出問題，以及 Google 發布新的 AI 模型。新的 Nano Banana Pro 不管在一致性還是文字呈現，都出乎意料地好。如果 Google 真的能在這場 AI 大戰中笑到最後，這一定會成為商業競爭的經典案例。
🗞️ 熱門新聞
How we’re bringing AI image verification to the Gemini app
Google 幾天前發布的 AI 模型太強了，各種錦上添花的稱讚就不說了，在 Simon Willison 的 Blog 看到，Google 設計出防偽機制，避免假圖到處跑。
機制有兩種，一種是在生成的內容中，插入人眼不可辨識的 SynthID，看起來只要 Gemini 產出都會帶；另一個則是放上人眼可辨識的浮水印。
AI transparency 會是很重要的非功能性要求，這點必須稱讚 Google。
✨ 科技觀點
Dead Internet Theory Gains Traction as AI Content Surges Online
這篇討論 Dead Internet，意思是現在的網路活動多來自假裝成人類的機器人，像是一堆殭屍在網路上晃來晃去，這些殭屍會改變網路的生態。
這跟我認為的「私人社群」趨勢相符，因為內容貶值，未來（或者現在）我們會需要知道內容為真。這「真」的意思不是說內容正確，否則大多主觀判斷的內容都不能為真，「真」的意思是你知道這內容來自哪裡，你知道自己在跟誰說話。
從產品面向來說，未來的社群會需要更著重於 user profile，個性化是一個，成就也是一個，或者不單純是 metrics 的維度，還有 trace 維度，讓你知道這名成員為社群做出哪些貢獻。
網路不會消失，但它會是一個不同的型態。
This is your brain without sleep
又是一個關於睡眠的研究。
我以前常常熬夜，因為靈感都在晚上才出現，我喜歡夜深人靜可以專心的感覺，直到看了《為什麼要睡覺？》，開始覺得還是相信科學好了。
大概到最近，才開始有比較正常的睡眠時間吧，深夜趕報告真的會讓人覺得熱血沸騰，希望不要再發生了 😂
道歉，是把自己縮小的語言
盡量避免過度客氣是我還在學的事。
記得有次跟日本人共用浴室，我沒注意，用了他的洗髮精，當時我先道歉，沒想到他反而很不好意思，說我不用在意，兩個東方人在那邊客氣來客氣去。
我現在道歉前都會想起不知道在哪看到的句子，講說有人會將自己縮小，好像怕自己發出的光會刺傷別人，我讀到時覺得非常溫柔，同時又在想：為什麼要這樣為難自己呢？
The Greatness of Text Adventures
在這個 LLM 時代談 Text Adventure Game 似乎有點復古，但還是有些有趣的點，像是最早的遊戲是利用 parser 解析輸入，再給予設計好的回應，而遊戲樂趣就是找出各種看似不合理，實則峰迴路轉的輸入項。
因為我喜歡類銀河戰士惡魔城，直接想到「探索」。
從遊戲設計的角度來說，最早的設計容易帶來糟糕的體驗，玩家不斷猜測某個字，但一直猜不到，只會覺得挫折。近代也有像 Her Story 這樣改寫 Text Adventure 邏輯的遊戲，但畢竟還是概念居多，多數的現代遊戲改成點擊或選擇（例如逆轉裁判），反而能帶來更多樂趣。
回到 LLM 的議題上，這也是聊天式 AI 產品的問題，除非你的目的就是聊天，否則聊天機器人式的設計不會是好設計。
Tech things: Robotics has its GPT2 moment, Data has its Oil Moment
為什麼 AI 在問答、開發程式、繪圖都已經有很不錯的表現，但在實際生活，例如打掃，好像還是很笨拙呢？一個可能的原因是：資料不夠。
如果作者是對的，那確實有很大的想像空間，資本可以轉成資料（利用群眾外包），資料可以轉成智慧，然後我們就能解決真實生活中的各種問題。當然我們也很容易想到，Google 手中有各種現成的資料……
LLM 給人最大的啟發，可能是有時候量變真的能造成質變。
On Talent
這篇談天賦的文章寫的真好，不只是內容的好，還包括組織方式，可以想像作者平常讀過很多資訊，才能這麼輕鬆不費力將摘錄放到對的位置（對的位置意思是，不是為了吸引人而耍的花招，而是內容要求如此）。
我受渥特班雅明影響很深，大家都知道班雅明喜歡引用各種資料，那是他的創作方法論，如果班雅明到這時代，他會成為一名好的創作者嗎？看情況，他的頻次低而且不固定，可是洞察非常深刻。如果是以月為單位，他有機會表現得比較好。
這也是作者在講的天賦，有時候需要調整客觀條件來配合你的天賦，因為每個人的天賦都不同，別人的方式終究只能成為某種參考。
📌 工程實務
The metrics product we built worked — But we killed it and started over anyway
Sentry 技術長寫了篇關於 Sentry 如何建構 Metrics 產品的文章，超精彩，推薦閱讀。
Sentry 原本打算只用「時間」來關聯訊號，Metrics 會用預先聚合的方式處理好，等到要看時叫出來，例如，他們會紀錄這 15 分鐘內的平均延遲是多少，所以你可以有 1:15、1:30、1:45 的資料。
問題是，如果你只想看特定 server 的 Metrics 呢？這就帶來「高基數」問題。也是 Charity 在她文章中不斷強調，但我一直沒很好理解的點。開發者為了除錯，通常會想紀錄更多的 metadata，這些都是成本。因為要預處理，等於每個 metadata 都要額外開一串時間序列。
最後 Sentry 選擇儲存原始事件，並使用他們的分析平台來進行即時聚合，我不確定他們如何解決效能問題，但我猜是利用取樣跟索引的設計。Anyway，我想講的是這些決策過程還有設計思路，真的是太有意思了，現代化的遙測基本上就是這議題。
The Declarative configuration journey: Why it took 5 years to ignore health check endpoints in tracing
看到 Otel 解釋他們為什麼花了 5 年才實作路徑忽略功能。主要原因是，他們原本用 Env 來配置，隨著功能越來越複雜，他們開始要用 yaml 進行配置，而要設計出有共識的精確語意又很困難。
這是想成為標準的專案獨有的困難，當其他人依賴你的介面時，頻繁變動會讓使用者不知所措，同時帶來麻煩的爭論。它不是技術層面的問題，而是治理問題。
James Shore: The Accountability Problem
哇，這場演講超讚，我太常被問到「這個功能要開發多久」了，儘管我知道這個問題沒有意義，但另一方面，我也知道別人會問不是因為他無聊，而是因為如果不知道多久，他就無法規劃。
在某個意義上，我知道自己應該要更關注生產狀態，不是說交付的功能數量，而是每項部署會花掉團隊多少時間，團隊平常因為哪些事情而分心，還有交付的品質如何。這些事表面上跟開發時間無關，可是他們是紮紮實實的工程管理議題，不把這些做好，工程團隊會沒辦法承諾任何事。
回到務實層面，工程負責人「必須」說出一個時間，但你不該讓時間成為關注重點，而這 "requires that play a political balancing act"，也如演講說的，會需要別人的支持，也會得罪很多人，這是 engineering management 好玩跟痛苦的地方。
Your data model is your destiny
這篇講建模的概念跟 DDD 是互通的，都是從領域出發，但它列出的例子太有說服力了，有興趣可以看看。
Anyway，雖然他講得輕鬆，可是最難的就是建模，例如社群，應該要以什麼為第一公民呢？有時候是訊息（通常是論壇），有時候是空間（例如 Discord），有時候是創作者（例如 Onlyfans）。