Weekly Issue 第 18 期：OpenAI 發布 AI 瀏覽器 Atlas
OpenAI 最近發布 AI 瀏覽器，加上稍早的 Sora 2，在技術圈中引起一些討論。
我認為 OpenAI 嘗試將模型領域的優勢帶到應用面，但這也讓它顯得更像是一家營利公司，而非研究單位（雖然現在沒人會把 OpenAI 當成研究單位了）。
🗞️ 熱門新聞
Dane Stuckey (OpenAI CISO) on prompt injection risks for ChatGPT Atlas
Simon Willison 聊了他對 OpenAI Altas 的看法，主要是資安方面。
幾個點：1) 提示詞注入問題依然存在，而且還沒有好解法；2) OpenAI 設計了登出模式與監視模式，讓使用者更容易意識到安全性。
在我看來第二點很重要，好設計應該要避免使用者犯錯，如果 AI 瀏覽器可以在登出狀態下執行，能避免掉很多麻煩的狀況，當然這意味著沒辦法自動購物。
總體而言，我覺得這仍然是 OpenAI 的一貫方向：「市場會告訴我們答案」
Is Sora the Beginning of the End for OpenAI?
Cal Newport ("Deep Work" 的作者) 看起來對 OpenAI 最近的發布有點意見。
可以想像，畢竟 Sora 的社群應用跟 TikTok 真的太像，跟 Newport 的立場幾乎相反。OpenAI 對這次的發布，也強調市場會教他們如何應對。在我聽來，是 Move fast and break things 的另一個版本。
我在意的是，Sam Altman 講的話，跟 OpenAI 的方向間，一直讓我有股錯置感（如 Newport 提到的那樣）。開發過產品的人會知道，最好的產品常常是需要抵抗潮流。OpenAI 現在是順著方向走嗎？
Sora, AI Bicycles, and Meta Disruption
Ben Thompson 還是有兩把刷子，切入的角度都好有趣。
例如他認為 Sora 應該是款社群應用，而不是單純的 AI 影片，我猜某方面來說，這正是 OpenAI 想要傳達的——簡單講，Sora 會成為下個 Instagram 或者更積極，成為下個 TikTok 嗎？
最後關於 Meta 的猜測也很大膽，雖然很可能是真的。Meta 有個槓桿可以決定推送多少廣告，當它需要說服投資人時，它就會放大廣告推送量，然後說 AI 很重要。我不確定 Meta 的 AI 戰略到哪了，對我而言，如果最後只使用在廣告上，背後的進展確實讓人懷疑。
Announcing Cloudflare Email Service’s private beta
Cloudflare 現在有電子郵件服務了！
真的太酷了，現在很多事都可以在 Cloudflare worker 上完成，而且開發體驗都很好，我好奇的是，到時這服務是主打開發者，還是主打行銷人員？以及未來 Cloudflare 打算怎麼保護 Domain？當然還有他可以支援到多少信件？
Calculating earnings in the Partner Program
Medium 在 10/1 後更新 Partner Program，讓外部流量有更多獎勵加成。
這個趨勢我沒意見，原本平台就應該要讓創作者知道，創作者自己有經營流量的責任，這樣兩者才能雙贏。只是我回頭看了 Partner Program，還是很納悶，在這遊戲規則下，他們怎麼避免頭部創作者跳槽問題？
✨ 科技觀點
Upgrading software business models to thrive in the AI era
看到 McKinsey 的報告，顧問公司現在最關心的問題仍然是 AI 的商業模式。
價值溝通是個問題，技術顧問公司可能還不習慣在營運中找到 AI 施力點，曾經有公司推薦我們使用 AI，但因為效益真的太低，用到最後還是放棄（即使我跟老闆都支持也沒用，因為我們總是要選擇有效益的點投入）。
訂價部分的論述就很有意思了，不愧是顧問公司，對這塊特別熟悉。例如 Adobe 的路線，跟我的期待就很接近：從核心客戶出發，驗證需求，獨立 SKU，打磨產品。過早訂價反而容易出問題。
Andrej's advice for success
Andrej Karpathy 寫一篇文章，教你如何取得「好成績」，而且不是講講而已，裡面的點都是實戰心得。
例如告訴你一定要讀考古題，還有一定要用鉛筆。以及最重要的「你的時間非常寶貴。你要做的是別考砸，然後，將注意力放在更重要的事情上。」
前陣子跟朋友聊起他怎麼習慣荷蘭的外語生活。「從來沒習慣呀，」他說「可是東方人很會考試，所以只要是需要考試的，都不是問題。」我覺得這簡直太誠實，講完我們都沉默了。
You can't fix core competency with a stern conversation
看 Kalan 的文提到 competency 跟 engagement 的差異，找了原文來看。
主要想提醒自己的是，有時候「期待對方把事情做對」，對雙方甚至整個組織都是傷害，團隊是基於共同目標組建起來，如果無法達到目標，就需要做出改變。
理論上我們可以不期待對方的工作表現，但還是善待對方，實際上這比想像中要難。
5 Things Managers Do That Leaders Never Would, According to Simon
Simon Sinek 談管理的正反模式，邊看邊想自己哪些點沒做好，每一點都不容易，對我來說，最難的應該是不要「Avoid Hard Conversations」。
我對團隊的觀點是，團隊是為了完成目標而聚在一起，有時候遇到不容易處理的是，都會讓我回頭想想這件事對目標有沒有幫助。例如，這項功能能不能幫助到使用者，這也會讓進行困難對話時更有方向感，知道該如何做決定。
What have we learned about building agentic AI tools?
一些關於 agent 的 insights，可能也是某程度的 practice。
我自己有感的包括這點："You should tune your tool to a specific model instead of expecting one tool to work well across all models" 最早用 LLM 時，會期待某個 prompt 可以用在全部的模型上，但那就跟 ORM 可以用在所有資料庫上，sometimes can work, sometimes can't。
這也意味著 vendor lock，只是現在講 vendor lock 還太早，模型迭代還在加速中。
📌 工程實務
错误处理：异常好于状态码
看到這篇在討論拋出跟返回哪種錯誤處理更好，這篇認為拋出更好，可能我習慣用 Go，看法不太一樣。
拋出最大的優點是程式碼好讀，如果使用顯示處理，錯誤處理的邏輯跟正常邏輯會混在一起，你需要不斷跳過無意義的 if else。但除了這點外，拋出幾乎是鼓勵開發者「不要檢查」錯誤，這是在設計上讓開發者容易犯錯，而且修正錯誤的代價往往更大。
前陣子讀《摩擦計畫》就在講，應該要讓對的事情容易發生，錯的事不容易發生，在這點上，我贊成用返回來處理錯誤。只是如果我們把討論的範圍擴大到語言，遵守語言的 convention 才是最好的做法。只要你遵守 convention，你就容易槓桿社群的能量來解決問題。
URL Design
看到這篇提到 URL 設計原則，其中「在 URL 裡堆砌關鍵字的做法並不陌生 ... Google 在 2003 年的一系列重大更新已經消除了這些 URL 的排名優勢。 」忍不住想，那最佳實踐是什麼呢？
在技術文件中，Google 建議 URL 要具有描述性，但它沒提到不具描述性的 URL 是否會影響 SERP，我猜只要資訊足夠搜尋引擎判斷，可能就沒差？另外 Google 也鼓勵用目標語言（有時非英文）來當 URL。
From Text to Token: How Tokenization Pipelines Work
這篇講搜尋引擎的 Tokenization 很好玩，我沒有深入研究過，沒想到 Database 在 Tokenization 後會變成 databas。
以前我們會用 TF-IDF 來找出內容的重要關鍵字，讓使用者更容易檢索到需要的內容，有 LLM 後，直接餵 LLM 產出關鍵字也是個辦法，但就沒研究哪種效果更好了。理論上，TF-IDF 應該還是更符合需求。
Elasticsearch Was Never a Database
雖然我猜沒人會用 ElasticSearch 當正式資料庫，但看完這篇，還是覺得寫得很棒，也講出 NoSQL 跟 RDBMS 在設計上的差異。
我最初使用 NoSQL 是因為 IoT 產品，架構師覺得 schemaless 能更彈性應對需求，只是呢，某天有個需求是希望把標籤應用到所有資料上，而且溯及既往。我當時回答沒辦法，除非我們重刷資料庫，因為該 NoSQL 不支援 Join。