科技焦點｜Oracle Just Became an AI Cloud・FFmpeg 9.1's new AAC encoder・我從不覺得 SOLID 與 Clean Code 真的「穩固

📰 1. Oracle Just Became an AI Cloud Powerhouse. Here Are 5 Under-the-Radar Stocks Along for the Ride

TITLE:甲骨文正式晉升AI雲端巨頭：五支被低估的受惠股

這幾年雲端軍備競賽打得火熱，亞馬遜AWS、微軟Azure、Google Cloud三大巨頭幾乎包辦所有新聞版面。但最近甲骨文（Oracle）悄悄殺出一條血路，憑藉OCI（Oracle Cloud Infrastructure）在AI領域的表現，居然被不少分析師稱為「第四大AI雲端平台」。原文標題直接說它「Just Became an AI Cloud Powerhouse」，還順手列出了五支比較少人注意、但可能跟著吃肉的股票——這件事本身就很值得聊一聊。

原文摘要

根據原文報導，甲骨文近期在AI基礎設施的投資明顯加速，尤其是跟NVIDIA的合作讓OCI能提供高階GPU集群，而且價格比三大巨頭更有競爭力。更關鍵的是，甲骨文手中握有大量企業級客戶的資料庫和ERP系統，這些客戶一旦開始導入AI應用，OCI會是天然的跳板。原文點名的五支「Under-the-Radar Stocks」包括：數據中心REITs（如Digital Realty）、網路交換器大廠、邊緣運算晶片商、冷卻解決方案公司，以及一家專注雲端安全的軟體商。這些公司雖然名氣不大，但都卡在甲骨文供應鏈或生態系的關鍵位置。

我的觀點

我贊成原文的核心判斷，但想補充一個更犀利的視角：甲骨文的AI雲端實力不是來自硬體軍備競賽，而是來自「企業級數據的黏著度」。AWS和Azure在拚誰的GPU多、誰的模型訓練快，但甲骨文更聰明——它直接跟客戶說：「你的ERP、HR、財務資料本來就放在我這，AI要落地就直接在我這跑，不用搬來搬去。」這種從資料湖到AI推理的一站式說法，對老牌企業極具吸引力。至於那五支股票，我倒是覺得風險在於：如果甲骨文未來走向自研晶片或自建資料中心，這些「受惠股」可能反而被邊緣化。投資人最好留意甲骨文的長期硬體策略。

延伸思考

這個案例讓我聯想到一個更大的趨勢：AI雲端市場正在從「算力軍備」轉向「場景鎖定」。過去大家認為雲端巨頭會吃掉所有市場，但現在甲骨文靠著企業 SaaS 的護城河殺出重圍，這其實給其他中型雲端服務商一個啟示——與其跟巨頭拚硬體規模，不如深耕特定產業的 AI 應用。比如 SAP 的 Business Technology Platform、甚至 Salesforce 的 Einstein，都很可能複製類似路徑。對散戶而言，與其追漲 NVIDIA 或微軟，不如注意那些跟企業 AI 轉型直接掛勾的冷門基礎設施公司，比如 Equinix（數據中心互聯）、Vertiv（電源與散熱），它們的成長曲線可能更穩健。

📝 編輯說：:這篇文章在科技投資社群引發熱議，筆者認為最有價值的觀點是點出甲骨文「用企業數據綁定 AI 算力」的差異化策略，比單純列股票更有啟發性。

📰 2. FFmpeg 9.1's new AAC encoder

🔗 原文連結

TITLE: FFmpeg 9.1 全新 AAC 編碼器登場：開源音訊編碼的又一次躍進？

原文摘要

FFmpeg 9.1 版本正式搭載了一個全新的原生 AAC 編碼器，取代了過去依賴外部函式庫（如 libfdk_aac）或效能較舊的內建編碼器。根據 HydrogenAudio 與 Hacker News 上的討論，這個新編碼器在雙盲測試中展現出接近甚至超越 libfdk_aac 的品質，同時編碼速度更快、記憶體用量更低。開發團隊聲稱這是 FFmpeg 有史以來設計最嚴謹的原生 AAC 編碼器，支援所有標準的 AAC-LC 設定檔，並針對低延遲場景做了最佳化。社群普遍認為這是一次「補齊短板」的更新——過去 FFmpeg 的內建 AAC 編碼器一直是許多專業使用者的痛點，現在終於有了一戰之力。

我的觀點

從 9.1 版本開始，內建編碼器不再只是「堪用」的備胎。過去 FFmpeg 的 avcodec AAC 編碼器長期被批評品質不如 libfdk_aac，導致許多打包軟體或轉檔腳本都硬要額外加載外部編碼器，不但增加依賴複雜度，也踩到專利授權的灰色地帶。新編碼器在官方測試中與 libfdk_aac 在 128 kbps 以上幾乎打平，甚至在部分 sample 上還小勝——這對開源生態來說是重大的品質宣告。更重要的是，它完全不用額外授權費，對 Linux 發行版和嵌入式裝置來說簡直是救星。當然，低於 96 kbps 的極低碼率場景還有進步空間，但這條路已經走對了方向。

延伸思考

這次更新背後的意義其實不只是一個編碼器。它反映 FFmpeg 團隊近年來積極強化原生 codec 的決心，從之前的 libsvtav1、libvpx、到現在的 AAC，都是在減少對第三方閉源或授權不明的依賴。對於串流平台或影音後製公司而言，這意味著未來可以少扛一些授權風險，同時簡化 CI/CD 的依賴管理。更深層的影響是：它可能促使其他開源專案（例如 OBS Studio、Audacity）預設採用 FFmpeg 內建編碼器，進一步統一跨平台音訊處理的標準。當然，老玩家們還是會先等 independent blind test 的結果出爐，但對於一般使用者，9.1 版本已經是實戰級別的好選擇。

📝 編輯說：: 這篇文章在 Hacker News 上引發大量技術細節討論，筆者認為最有價值的觀點是：新編碼器對 Linux 原生音訊轉碼的生態掃除了最後一個依賴外部函式庫的痛點。

📰 3. 我從不覺得 SOLID 與 Clean Code 真的「穩固」或「乾淨」

🔗 原文連結

原文摘要

作者Daniel自學程式，讀過《Clean Code》等經典書籍，但他覺得這本書只是「一堆資深工程師的建議，很多根本無法驗證」。面試時被問到SOLID，他講了GoF的設計模式，結果面試官一頭霧水，他才發現對方只是照著題目念稿。後來他看了Uncle Bob的演講影片，前面整整20分鐘都在講「水分子結構」和「新手工程師數量翻倍」這種廢話，真正進入主題已經是30分鐘後的事了。Daniel本身是歷史系學生，每週要讀上千頁論文，他發現不同學科有各自的寫作文化，程式碼也該如此——而不是硬套某種權威教條。

我的觀點

你有沒有在code review時聽過這種話：「你這個違反開閉原則，重寫一下」？你心裡OS：「可是這樣改完程式碼更長更亂啊！」如果有，那你一定懂Daniel在說什麼。SOLID和Clean Code這套東西，說穿了就是某些資深工程師的「經驗談」，但到了業界卻被當成聖經。我親眼看過一個專案為了「單一職責原則」，把一個本來300行、邏輯清楚的類別，拆成10個小類別和5個介面，結果新人要改個功能得翻遍整個資料夾。這叫乾淨？我他媽只覺得更難維護。而且這些原則幾乎沒有科學數據支撐，不像你寫編譯器優化還能跑benchmark。與其盲從，不如問自己：這個情境下，哪種做法能讓下一週的自己（或同事）看得懂、改得動？這才是真乾淨。

延伸思考

Daniel從歷史學訓練中學到一件事：寫作風格是長期文化互動產生的，不是某個權威訂出來的。這在軟體工程裡也一樣。不同團隊、不同語言、不同領域，自然而然會長出自己的「最佳實踐」。你硬把Java的SOLID套到Python或JavaScript的專案上，常常只是徒增樣板程式碼。更糟糕的是，這種教條主義很容易變成面試篩選工具——「你有沒有讀過Clean Code？」——而不是真正衡量寫程式的能力。我認為，與其花時間背原則，不如多看不同領域的書，像Daniel那樣從歷史學、人類學甚至語言學去理解「溝通」的本質。程式碼終究是寫給人看的，而人不是SOLID五個字母能定義的。

📝 編輯說：: 這篇文章在Hacker News上引發了兩極討論，不少人認同作者對教條主義的反感，也有人認為SOLID還是有其價值。筆者認為最有價值的觀點是：程式碼設計本質是一種寫作文化，不該被僵化規則綁架。

📚 本日原文來源

本文由JK Space News彙整，不代表任何投資建議。