Weekly Issue 第 5 期：OpenAI 的企業文化
我一直都喜歡看科技公司的願景與文化，原因是，我想知道別人是如何看待自己的使命，又是用什麼方式打造它。願景通常在官網都會有，但想要知道文化，只能聽內部人講講了。
Palantir 前陣子因為它不同於矽谷的文化，而引起很多討論。受此影響，前 OpenAI 的員工在離職創辦公司後，也發文談論他所見到的 OpenAI。最讓我震撼的是，他們幾乎沒有資金困擾，想的都是如何打造出色的 AI 模型。
🗞️ 熱門新聞
Reflections on OpenAI
前員工談 OpenAI 的內部文化。
讀起來最大的感觸是，有些價值觀、觀點、實踐，只有在世界級的公司跟資源下，才有可能建立起來。讓每個團隊各自為政，看誰能端出最好的成果，這對新創（特別是沒拿創投）實在太奢侈了。
我相信這種經歷會變成是「可以帶著走的饗宴」，那種衝擊也是最寶貴的。
AI Open Source Productivity
METR 前陣子發了一篇研究，說使用 AI 工具後，開發時間反而增加 19%。這篇談到一些假設跟因素。
整篇討論很有意思，像是排除了用錯模型的可能，我只能說量測生產力一直都不是件容易的事。
文中還有提到，雖然開發時間沒降低，但是閒置時間增加了，這倒是好事，另外就不知道對品質是否有影響？
✨ 科技觀點
I'm Done With Social Media
很推薦經營內容的人看這篇「我不用社群媒體了」，應該很有共鳴 :)
自己贊同的點「我覺得是時候發揮我的長處，而不是試圖讓自己適應一種我從未感到舒適的格式。」「RSS 可能是我們目前擁有的最棒且最純粹的技術 」「事實上，我已經敲打這篇文章的草稿好幾個月了，試圖理清我對此的感受。 」
最後講到不用 Substack 的原因也跟我很像，他們技術跟產品的打磨（相較以前）有越來越好的趨勢，但整體始終讓我不放心 :p
The Who Cares Era
這篇「誰在乎的時代」講說內容貶值的現象（希望我沒理解錯），有點激進，但也有些值得細想的點。
創作者經濟可能是對「內容貶值」這話題最敏感的領域，LLM 出現後，大家在問創作還有沒有意義，經濟面上是在說內容是否會貶值到不值得投入。
我在想的是，內容貶值不是從現在才開始，古騰堡發明印刷機，是不是會讓內容貶值呢？攝影的出現呢？班雅明在〈機械複製時代的藝術作品〉談的就是這個話題。
Google | Acquired Podcast
Podcast 的逐字稿，談 Google 的商業故事。
雖然看過相關故事幾次，但每次看還是有新收穫。Google 剛起家時，曾跟 Excite 談技術授權，結果因為 Google 效果太好，用戶停留時間太短，Excite 不想用他們家技術。
這就是商業模式跟產品不匹配的例子，Google 可以說發明了新的模式。
How Duolingo Build Product 10x Faster with AI
Duolingo CPO 的訪談。
兩個點可以想，首先是廣告業務，說服自己的過程很有意思。先是用 A/B 測試來確認廣告是中性的，不會影響使用者，接著再優化 UX，只在完課後展示廣告，再接著，有使用者提出想付費去除廣告，因此有了訂閱付費功能。
我真的很好奇他怎麼會覺得論述沒有矛盾。不會影響使用者，那人家為什麼願意付費去除廣告呢？
另個點是留存率，用了遊戲化設計的原則，這點倒是很好，我沒想過 Streak 是個關注重點，難怪最近有看到一些 SaaS 使用類似的設計。
📌 工程實務
GitHub Next | Continuous AI
AI 的一種應用情境：持續性 AI。
文中指的是用 AI 強化 workflow 的例子，例如自動 PR Review、自動文件化、自動補全等等。這個字的用法很有 GitHub 的風格，畢竟他們的關注點是 CI/CD。
我自己是真的很需要一個 AI 助手來幫忙整理訊息源就是。
An illustrated guide to Amazon VPCs
如果你也對 AWS VPC 是什麼覺得困惑，那可以看看這篇。
「Amazon 需要的是一種方法，讓每個人都能擁有自己的私有網路，但這個網路是在 AWS 內部。這樣一來，他們就能帶著自己的 IP 位址，而不會與其他人的 IP 位址發生衝突。 」
原理有點像網路版的 Virtual memory？
Everything I know about good system design
這篇談系統設計寫超好。有些現在沒讀懂，存起來慢慢看。
例如這點「事實上，複雜系統通常反映出缺乏良好設計。」可能要搞砸過一些事情才能體會。
我以前在做電商產品時，曾經想要在系統引入 Rollback 機制，當系統出問題時，能保持事務特性。當時的 Manager 跟我說失敗就讓它失敗，留個紀錄就是了，不要 Rollback，重要的是 Deterministic。我們的產品不是高流量產品，而且我們還有客服部門，能替客戶處理問題。很久後，我發現 Amazon 也是這樣幹的。
要保持系統簡單是件很困難的事。
Repeat Yourself
你聽過 DRY(Don't Repeat Yourself) 原則嗎？我非常建議再讀讀這篇。
內文提到很多 DRY 的問題，最認同的點是：「重複遠比錯誤的抽象來得便宜。」Martin Fowler 在 Refactor 說重複的程式碼是 Bad Smell，但那是在重構階段呀，何況這是在能找到正確的抽象的前提下。
DRY 大概是我最不鼓勵的原則了，我這輩子處理過最棘手的 Legacy Code 就是把所有東西都抽成 Functional Style，然後到處注入。
Prioritizing Technical Debt
這篇談「處理技術債的優先順序」，還給出了決策矩陣。
內文的要點大致是「盡可能把技術債翻譯成商業價值」，然後用開發功能的角度來看待。我這幾年大多也是這樣做的。
只是有時候會有困惑，這樣真的對嗎？這本質上把技術問題變成政治問題，例如你知道沒做去識別化，可能的風險是資料洩漏時的法律責任，但這真的需要「翻譯」嗎？有時候就是別人對你不夠信任，或者是別人有其他想做的事情而已。
我得說自己不會照文章決策，可是這套說法拿來說服別人還是行的，應該吧。
