Weekly Issue 第 17 期：n8n 在 C 輪募得 180m
現在新創企業已經離不開 AI 了。像 n8n 這樣的自動化工具，重新用 AI 話題包裝後，可以在自由市場上募得鉅款；Postman 也需要在它的口號中，強調對 AI 的重要性。
我相信 AI 讓生活變得更方便，我剛到新國家，對任何事情都不熟時，AI 給了我很多幫助。但市場的話題像一場無差別的風暴，每個公司都面對一支麥克風，麥克風傳出的經 AI 編輯過的聲音。
🗞️ 熱門新聞
n8n raises $180m to get AI closer to value with orchestration
n8n C 輪募了 180M 美元，沒想到它可以這麼值錢。
基於 zapier 只有 5B 的估值，n8n 2.5B 的估值代表它有多被看好。我是有點困惑，因為對我來說，n8n 更像是個能自主部署的自動化平台，而不是如新聞稿講的「AI 編排與協作工具」。
Banning controversy reveals Bluesky’s federation isn’t there yet
在 HN 看到這則 Bluesky 的新聞，有名使用者發表爭議性言論後，被 Bluesky 封鎖，然後他的 Blacksky 也跟著看不到了。
技術上爭議的原因有幾個：Bluesky 還沒做到完全去中心化，平台仍然能掌握使用者的生殺大權；以及，當使用者被封鎖時，他需要聯絡官方才能知道。
這是個好問題：當你被封鎖時，平台應該要告訴你被封鎖嗎？還是默默讓你消失？從道德層面，如果平台認為你違反使用條款，它應該要告知你違反哪一點，以及對應的處罰是什麼。可是這會帶來大量的客服成本，實務層面通常是直接 BAN 了。
我當初用 Medium，對他們直接打 noindex 就覺得無法理解，後來參與過類似專案後，才比較知道它們的拿捏（雖然依然沒有想買單）。
AI-Ready APIs Start with Postman
我原本還在納悶 n8n 跟 AI 的關係是什麼，直到我看到 Postman 的 slogan: "Are your APIs ready for AI agents?"
這真的是太讓我驚訝了，我原本以為 Postman 跟 AI 的關係，頂多是自動幫你寫測試而已，沒想到在行銷上，它變成是 AI Agent 的基礎條件（確實也不能說錯）。
某程度上我可以理解老闆的焦慮了，當你看到連 Postman 都在講 AI 時，會覺得我們應該也要來一下。
✨ 科技觀點
A career is a pie-eating contest & the prize for winning is more pie
「職涯是一場吃派比賽，而贏得比賽的獎品是更多的派 」
前陣子在玩絲之歌時也常想到同樣的事：你辛苦通過平台跳躍，打過 Battle Arena，擊敗 Boss 後，得到的獎賞是什麼呢？更難的平台跳躍，更多小怪，還有更強的 Boss。
我覺得這是件好事，如果找到樂趣，它會帶來更多的正反饋，給你能量往前走，這也是為什麼從工作中找到樂趣很重要。
I'm in Vibe Coding Hell
AI 時代，Programming 教育模式會有什麼改變？
或者，不僅限於 Programming，而是 AI 可以帶來什麼？我認為其中一項優勢是「更即時的回饋」，以前需要等 Office Hour 才能問問題，現在可以用 AI 直接得到修正後的答案，還有原因。
最近在用 Toko，特別喜歡他們「還可以怎麼說」的設計，畢竟我還是習慣用中文邏輯思考，而 native speaker 會有相當不同的說話方式。這種設計可以讓我更知道 native 的說法。
Vibe engineering
Simon Willison 建議用 Vibe Engineering 取代 Vibe Coding，我不覺得這是問題所在，但依然說明了一些事。
曾有次跟朋友聊到，為什麼都使用了最新技術，還會在產品化遇到這麼多困難，我當時的想法是：Engineering management 還不成熟，而如果沒有工程支持，產品很難走得遠。
哪些 Engineering？例如如何管理 log、如何 version migration，都是無聊但能幫助產品的東西。
從命名上來說，Engineering 比 Coding 要好，因為它隱含了後面還有其他事情要做。當然 Simon Willison 只是開個玩笑就是了 😂 。
What is "good taste" in software engineering?
因為 AI，開始有更多人在談品味(Taste)，我不確定這是不是個好的趨勢，但如果能藉機談談哪些設計是好設計，它又有哪些隱含的代價，這倒是個不錯的話題。
對我來說，RESTful API 就是個很棒的設計，它的擴充性跟擴展性都很強，表達力也好，我總是可以透過設計良好的 API，拆解並處理複雜的問題。我特別推薦 Stripe 的 API，真的異常優美。
當然 RESTful 要付出的代價是客製化困難，有時需要多個來回呼叫，才能組出需要的資訊，假設前端只要一個呼叫就能處理呢？這就是需要 trade-off 的點，對我來說，如何看待這類問題就是品味。
The Best Way to Use AI for Learning
我算是喜歡學習的人，但是看到 Alan 這篇，還是會有「原來學習可以做到這程度」的感嘆。
我是在大學首次接觸卡片盒筆記，當時的國文講師在課餘會拿一疊卡片翻來翻去，我發現如果我能把知識做成卡片，我可以用同個主題，連結不同來源的內容，而這些內容最後會成為一個系統，協助我發現更深的知識。
這確實就像 Alan 講的「你的書桌大小，決定了你同時能看到多少資訊，進而影響了你的思考能延伸到什麼程度。」
How I provide technical clarity to non-technical leaders
資深工程師（或者是資深工作者）應該要知道如何做出承諾。
有時候這意味著承擔責任，因為講出來的話，最後會變成決策依據。我自己的經驗是，想在精確與承諾間取得平衡並不容易——我希望盡可能說明限制在哪，但又要讓別人知道該怎麼進行。
通常一個技巧是說：「在 95% 的信心水準下，成本會在 1000-1500 間」，如果別人買單，那沒問題，如果不買單，我會說再給我一星期來縮小範圍。這是一種精確的不確定性。
让Agent系统更聪明之前，先让它能被信任
這篇講 Langchain 幫你做了哪些事，以及沒幫你做哪些事。
Agent 目前的複雜性來自不確定性與 Stateful，這兩點看起來都不是可以立刻解決，往好的方向想，也帶來更多的產品變革機會（我很贊同用雲端帶來的變革來比喻）。
Management and organization at Medium
讀《摩擦計畫》讀到 Medium 以前曾經實行合弄制，只是因為太多專有名詞，實行起來有困難，最後又改成其他管理架構。
Brian Robertson 認為 Medium 的問題是管理階層只想要合弄制的制度，但不想改變權力結構。我不太確定這是什麼意思——如果管理階層不是對去中心化有興趣的話，他們怎麼會找自己麻煩呢？
找了 Medium 自己的聲明來看，看起來他們認為合弄制的框架會影響日常營運（可以想像），不過讓我有點納悶的是，他們看起來也擔心「合弄制」的公眾形象，這就比較微妙了。
我猜這是另一個 Ev Williams 想追求，但落實起來不順利的例子。至於去中心化管理是否可行，看起來像是另一個議題。
📌 工程實務
4 reasons you should embrace virtual machines instead of jumping straight to dual-booting
看到一篇文章在討論 VM 會比 Dual-Boot 更好。
我以前有用過 Dual-Boot，主要考量是原生體驗好很多，當時公司的開發環境是多平台，需要 Windows 也要 Linux，我後來發現這是場災難，如果可以，應該要鎖定一個平台就好，維護環境的成本會低不少。
我猜等 Steam 遊戲都能在 Mac 上跑後，我應該連家裡的 PC 都會換成 Mac。
From Static Rate Limiting to Adaptive Traffic Management in Airbnb’s Key-Value Store
這篇 Airbnb 講快取設計很讚，以前說過，我們會用 circuit breaker 保護系統，但那畢竟是種服務降級，而 Airbnb 這種更細膩的 rate limit 應用可以適用更多情境。
例如 DDoS，通常是集中打某個 url 或 api，你可以找出 hot key，用個 topN 的服務將他們快取起來，避免打到後端；或者替流量分級，優先保護重要的流量。
當然實務上也有些 infra 成本，例如怎麼分級？怎麼協調快取與後端系統？如果沒有 SRE，要時時顧這些也會是個挑戰。
關於 legibility 的討論
關於 legibility 講的很好，以前聽前輩講過，那像是一場遊戲，要不要玩可以自己決定，但你需要知道遊戲規則。
只是如果是當主管的，最好還是多給別人舞台啦，彼此成就，你希望團隊熱愛工作，就要給他們燈光。