Hi 讀者，
37signals 預告許久、將挑戰現有商用軟體 SaaS 模式的「ONCE」系列產品第一項終於推出了——主打團隊溝通用的即時通軟體「Campfire」。有些讀者可能覺得名稱很熟悉，因為這就是脫胎自過去 37signals 的同名 SaaS 產品。由於是買斷制，無論你的團隊有多少使用者，定價都是 299 美元，差別在於你需要自己安裝和 hosting。
按照慣例，兩位創辦人 Jason Fried 跟 DHH 分別在 X 以影片方式跟大家介紹產品與安裝流程。不知道各位讀者怎麼看待這樣的模式呢？
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] 黃昱嘉／Hugging Face：估值 45 億美元的開源 AI 平台，四大特點加速人工智慧開發
原文連結｜閱讀時間：10-15 分鐘
我們知道訓練強大的 AI 模型是非常昂貴的，並非任何人或公司可以輕鬆負擔，因此開發者當然很歡迎市場上出現像 Hugging Face 這樣的開源模型平台，它被稱為「AI 界的 Github」，整合超過 47 萬個開源、預先訓練好的 AI 模型（還有資料集）供大家下載、使用。
本文將概覽 Hugging Face 對開發者的重要性，作者整理出四大特點，指出為何該平台獲得眾多開發者青睞，並在最後討論 Hugging Face 的商業模式與擁抱開放、傳遞知識的文化。作者指出其中一項特點是「省時」：「如果只想測試是否符合需求，不需要先下載整個模型、在自己的機器上跑起來，而是可以透過網頁看到結果，節省了許多時間。」
Hugging Face 在 2023 年八月募資 D 輪 2.35 億美元，以 45 億美元的估值成為全世界前十的 AI 獨角獸，而且投資陣容相當豪華，包含 Google、Amazon、Nvidia、AMD 等科技巨頭都是投資者。不過作者也在文中指出，目前 Hugging Face 的商業模式還不明確，要如何撐起高達 47 億美元的估值會是未來的一大挑戰。
[英] Adam Zewe／免電池、可自行供電的感應器
原文連結｜閱讀時間：10-15 分鐘
我們在上一期提到一種未來可讓智慧家居裝置不必外接電源的染料敏化太陽能電池（dye-sensitized solar cell），最近我又讀到一篇文章，談的是 MIT 的研究人員最近在《IEEE Sensors Journal》發表了一項研究，以電磁感應原理發展出來的技術，實作出免電池、可以從周邊採集能量來運作、甚至傳輸資料的感測器。
這種感應器因為不需要充電或更換電池，也不需要佈線，未來可能的應用場景是可以安裝在過去傳統感應器難以安裝的位置，例如船舶的引擎。這種感應器可以裝在供應馬達電源的電線周邊，從線路「外部」採集能量來運作。
文中指出這套系統克服了三個挑戰：一、這個系統要能冷啟動（cold start）——也就是不需要外部給予初始電壓就能啟動；二、在沒有電池的情況下儲存並有效轉換系統採集的能量；三、研究人員開發出一套演算法來測量、控制能源的使用，必要時甚至要能「多」採集周邊的能量（必須精準控制以免採集過多能量導致損毀），文中以單車的變速系統比喻。這項研究以這樣的設計框架和現成的零件開發出溫度感測器。研究人員表示，傳輸資料是系統運作上最耗能的一環，未來會探索其他更低功耗、例如光學或聲學的資料傳輸方法。
[英] Tomasz Tunguz／我的 2024 年預測
原文連結｜閱讀時間：5-10 分鐘
長期關注 SaaS 趨勢的創投 Tomasz Tunguz 照例在一月發表他的新年預測，並且為自己前一年的預測打分數。我個人很佩服願意這樣做的業界人士，對於這類預測感興趣的讀者也可以看看另一位創投 Fred Wilson 的文章。Tomasz Tunguz 的電子報出刊頻率很高，目前已經累積 14 萬訂戶，對相關主題感興趣的讀者可以參考看看。
Tomasz Tunguz 的產業預測涵蓋範圍包括 IPO 市場、併購、AI 與資料、加密貨幣、創投⋯⋯ 以 IPO 市場來說，他認為上半年應該還是比較冷清，但幾家公司如 Stripe 或 Databricks 可能會在夏天有動作，並且帶動市場。
其中一項預測我認為部分讀者應該已經有感受到了：搭載 AI 功能的搜尋引擎。Tunguz 認為隨著使用者行為改變，有 AI 輔助的搜尋應該會在今年佔整體搜尋量的 50%，特別是在手機上。除了 Bing 和 Google（後者目前應該還是實驗性質），我也推薦讀者嘗試 Phind 或是 Perplexity。（當然，歡迎各位分享使用心得。）
[英] Will Larson／資深工程師如何處理不確定性問題
原文連結｜閱讀時間：15 分鐘
本文作者 Will Larson 是股權管理平台 Carta 的 CTO，過去在 Calm、Stripe 和 Uber 等公司擔任過各種技術主管，出版過《The Engineering Executive’s Primer》（工程主管入門手冊）等寫給工程師和技術主管的書籍。最近他寫了一篇文章討論資深或是更高階的工程師（原文是說「staff-plus engineer」）如何處理不確定性高的問題，從他自己過去的經驗整理出一個應對流程，以及過程中可能面臨的挑戰。
Larson 舉了兩個案例，一是他在 Stripe 時，大家都相信遲早要面對資料儲存地點的法規問題，但是沒人知道該怎麼做，一來他們的業務往往涉及跨境的資料傳輸，二來是各國的規定可能不同，而且會不定時改變，這會影響到他們處理問題時的選擇，要嘛有的會提高營運成本，有的會影響使用者體驗。另一個則是他在 Calm 這個以冥想 app 起家、近年涉入健康與醫療產業的公司期間，所要面臨的不確定因素：《健康保險可攜性和責任法案》（HIPAA），如果沒有處理好，幾項 Calm 的產品和各種工程決策將難有進展。
Larson 指出，這類高度不確定性的問題涉及層面往往是跨領域的，而且每家公司面臨的問題也不同。Larson 在文中建議的流程可分為三個階段：第一，勾勒出現況；其次是發展出潛在的解決方案；最後則是要促成決策。當然 Larson 也分別針對這三個階段做了近一步的討論，例如他認為潛在的解決方案應該要具備若干特性，並且在這個階段就做好各種權衡；舉例來說，假如允許交易處理可以發生在任何地區，然後再將資料傳到母國儲存，這樣有可能會出現帳戶餘額資訊不準確的狀況，因為交易資訊可能尚未回傳，此時你願意向客戶顯示可能不正確的餘額數字嗎？
不過，Larson 也說，儘管這套流程長期以來大致有效，但有時依然會遭遇兩大挑戰：時機問題（時機尚未成熟），以及你面對高度不確定性問題時，採用的解決方案是否獲得高層的支持，這會決定你的成敗。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
