Weekly Issue 第 6 期：Duolingo CEO 看 AI 與遊戲化
現在是 AI 時代，大家都在想怎麼讓自己的產品跟 AI 掛勾，但具體要怎麼做呢？背後的思考有哪些？Duolingo 給出他們自己的觀點。
例如，現在的產品是否只是 AI 套皮，你接收使用者的問題，套上自己的提詞後，拿去給 OpenAI，要它回答你？在現在百家爭鳴的情況下，選擇哪個模型會有差嗎？AI 能帶來新用戶與新營收嗎？等等。
另外本週也選了一篇少數派的文章，談 AI 對 RSS 的影響，對 RSS 未來方向有興趣的人不妨看看。
🗞️ 熱門新聞
Duolingo CEO Luis von Ahn wants you addicted to learning
Duolingo CEO 專訪，相當紮實，推薦閱讀。
「對我們來說，只要廣告存在，它們就是人們訂閱的好理由。 」
「大約有 80%到 90%的語言學習者不想和其他人類交談。他們可能會告訴你他們想，但事實上並不想。 」
「好消息是，目前這些 AI 功能並沒有為我們帶來新用戶。 」
「我試著教你東西時，最難的就是讓你持續保持專注。 」
「我完全相信大多數人寧願花更多時間玩 Candy Crush，也不願意和別人交談。 」
很少看到話說得這麼誠實的問答，我應該就不會這樣講（措詞可能是「AI 可以為我們帶來新的機會」），有時候誠實是一種天賦，在打造產品的層面更是如此。
Grok: searching X for “from:elonmusk (Israel OR Palestine OR Hamas OR Gaza)”
前陣子的新聞，當你問 xAI 時事觀點時，它會去查 Musk 的立場。當想然會引起爭議。
xAI 團隊的解釋是「如果你問它「你怎麼看？」這個模型會推理出，作為一個人工智慧，它沒有自己的意見，但知道它是 xAI 的 Grok 4，因此會搜尋 xAI 或 Elon Musk 可能對某個主題所說的話，以便與公司立場保持一致。 」
為了處理這問題，xAI 修改 Prompt，加入 "not from any stated beliefs of past Grok, Elon Musk, or xAI"。
真是太有趣了，這算是某種設計原則嗎？
✨ 科技觀點
Want to meet people, try charging them for it?
很多人（例如我）寫 Blog 或使用社群網站的動力是想跟人建立連結，但通常很少人主動聯絡。
這篇文章的作者分享了自己的經驗，當他開始將聊天作為募款服務時，有更多人聯繫他。原因是人們對免費佔用他人的時間覺得不自在。
這個觀點很有 insight，我們以前推出過一個產品，就是基於同樣的假設。另外一個好奇是，作者的 Blog 沒有留言區塊，而是用 email 跟 x 代替，這是個好設計嗎？
Skip the exit interview when you leave your job
可能會有人在離職面談跟 HR 深聊，希望在走之前留下讓公司改變的機會，這篇文章建議你不要幹這種事。
「如果你對公司運作有建議，應該在你還在職時告訴你的老闆。如果他們在你任職期間都不願意採納，離職面談時告訴他們也沒用。 」
我還是有在離開某家公司時跟 HR 說真實原因，但那是因為我跟 HR 交情不錯，反正私下吃飯也會聊，乾脆用上班時間聊。
What I've Learned About Automation
以前在公司做自動化，最大的 lesson learn 是，自動化不是產品。
什麼是產品？iPhone 是產品，但生產 iPhone 的產線不是，我可以靠替人生產 iPhone 賺錢，但產線本身是不是人工的沒差。
同樣的邏輯好像也可以套到 n8n 上，n8n 的意義在於價值流管理(VSM)，它讓價值的交付更順暢了，但除非是賣 n8n 模板或替人整 n8n 流程，否則公司不會從 n8n 直接賺錢。
PMF 還是產品最重要的事。
Burn out 逃生指南
如果長期對工作覺得精疲力倦，大概率是 Burn out 了，這篇在談如何管理 Burn out 發生的機率。
主要還是成就感跟掌握度，如果工作都掌握在自己手中，不是每天追逐瑣事跟處理臨時插件，工作就能相對有質感。理論點來說，這是系統思考，每個系統都有上限，我們需要在上限到來前用系統而非個人的能力去支撐它，否則最後個人節點就會燒掉。
雖然每兩年換一次工作也是不錯的選項。
Why Most Feedback Shouldn’t Exist
曾經有同事尋求我的回饋，我想了想，只跟他說：「我覺得你做得很好，有問題的是我。」對，我知道，很爛的回答。
這篇從另一個角度在講過度回饋可能是負面的，主要差別是，你的回饋是否可以替他人帶來成長，如果不行，這回饋存在的意義是什麼？360 的必填欄位？
從這角度來說，我應該要給的回答是「好在哪」，以及我需要哪些協助。當然，既然聽了就要行動，coach coachable 不是單方向，它對問答雙方都是挑戰。
AI 复兴 RSS ？
很好奇現在還有多少人在用 RSS？這篇提到 RSS 的一些特點跟歷史。
去除部分技術觀點（例如用 AI 產生 tag 實在不能稱為好點子），我的觀點跟作者大致相同。RSS 是我最信賴的消息源，而 RSS 的問題是有沒有辦法成功降噪。以前只能靠 Rule-based 來做，現在有 LLM 後方便多了。
大家都說社群媒體的演算法很討厭，但那是因為演算法握在他們手中，別人可以決定你看什麼，這才討厭，演算法本身不是負面機制。解法也很單純，讓使用者自己可以控制演算法就好。
📌 工程實務
Go Runtime Mystery: A Deep Dive
這篇講 Go Memory Leak 的文章超精彩。
面試時，我很愛問的一題就是如果在 Grafana 上看到 App 有記憶體洩漏，你會怎麼處理？通常直接反應是看 profiles，通常原因不外是 slice, map 或 goroutine 洩漏，原文比較特別，遇到的是 runtime 問題，如果不知道 Finalizer 的機制，大概還是沒辦法解決。
How to Scale Distributed Counters: Designing a View Count System for 100k RPS
這篇講系統設計講得很棒。雖然他沒有實際計算 99.99% 有沒有可能達到，在系統中，每引入一個組件，就越容易造成系統失效。
以前設計廣告曝光系統也是用同樣邏輯，MQ + 分散式資料庫，然後在產品上限制顯示的地方，讓讀寫大約是 1:10 的比例。當時撐了半年還不錯，再後來我就不知道了，希望現在還行。
如果要做到更好，像這篇講的用上串流處理框架會更理想，但整個開發跟維運成本能不能支撐又是另一回事了。
Everything’s a bug (or an issue)
如果你有在用 Bug（呃，我是說 Issue）管理系統，可以看看這篇，應該有不少樂趣。
我自己沒用過文中的四項原則來檢視 GitHub Issues，看完有點明白為什麼 GitHub Issues 難用了。Jira 應該有符合？但 Jira 的問題反而是太過複雜跟效能太差。
Gitea 剛用，用起來還不錯，也可能是還沒踩到雷。
Most RESTful APIs aren’t really RESTful
RESTful API 應該是 Web 開發常用到的東西，但通常在說的 RESTful （依照原作者定義）都不是 RESTful。
這篇整理得很詳細，我這幾年遇到問題也通常會去翻原論文（例如 RESTful 要前端呼叫好幾次合理嗎？）。看到這句「（論文）並未規定 HTTP 動詞（如 GET、POST、PUT、DELETE）的具體使用方式，也未聚焦於當今 REST 常見實作的 CRUD 風格 API。」不禁覺得很親切。
我面試時也會請人選設計 API，通常是 CRUD，加上一個不是 CRUD 的東西，例如新增使用者，然後驗證使用者信箱，兩個 API。前者沒什麼好說，但後者是希望人選別用 Update 的思維來設計。
Go synctest
Go 在 1.25 預計釋出 synctest，加強原生對併發測試的支援，如果你像我一樣，想知道如何將併發測試寫得漂亮，推薦看看雷N這篇。
我們原本對 edm 的測試都是用 time.Sleep，但跟文中講得一樣，會有不穩定的問題，最後是改成用 sync.WaitGroup 後才得以解決。
synctest 可以降低團隊在開發併發的問題，避免每個人各自繞路找解法，這的確是語言該做的事。