2026.07.03 —— 今日 10 則
TODAY'S THREAD 今天三篇深挖有一個共同主線——把糾纏在一起的東西拆開來看：Spandana 把 SLO 判斷跟成本優化拆成兩條迴圈、內部開發者平台的事後檢討把「採用曲線」跟「維護負擔」分開檢討、React monorepo 的 CI 優化則是從一團 lint 規則裡揪出唯一真正拖時間的那一條。
Microsoft 點名一個 agent skill 常見反模式：什麼都塞進同一個 skill
Microsoft 這篇點名一個常見的 agent skill 設計反模式：把 API 參考文件、認證流程全部塞進同一個 skill，結果每次呼叫都要吃下不必要的 token。文章主張的修法是先量測模型在沒有這個 skill 時的實際表現，只把模型真正欠缺的部分寫進 skill，而不是把所有可能用到的東西一次全灌進 context。
143 萬個 agent skill 掃過一輪，揪出正在流通的惡意 skill
Agent skill 現在被當成套件在管理，但身分、版本、來源這些依賴管理的基本資訊卻都不透明。這篇論文借用 SBOM 的概念分析了 143 萬個 skill，發現依賴圖裡有遞迴重用、隱藏套件庫存，甚至還揪出正在流通的惡意 skill。
一位工程師花 12 週，用 AI coding agent 獨力寫出 42 萬行正式程式碼
一位工程師花 12 週，用前沿 AI coding agent 獨力寫出一套文件無障礙修復系統，累積 42 萬行正式程式碼與 116 萬行測試、文件、agent 工具。這篇論文從這個第一人稱案例整理出一套「治理轉換」模型：解釋高速的 agentic 開發怎麼把反覆出現的失敗模式，轉成可長期維持的治理機制。
RLHF 的 rollout 過期了多久，學習率就得跟著讓步多少
高吞吐量的 RLHF 系統常把 rollout 產生跟 policy 更新拆開跑，學習器因此常常吃到過期的 rollout。這篇論文推導出過期程度跟學習率之間的穩定性條件，說明為什麼最大可用學習率有時看起來跟 staleness 關係不大——因為真正卡住的是另一個限制條件。
FoundationDB 的 Flow：把 actor-based 並行帶進 C++11
FoundationDB 的 Flow 把 actor-based 的非同步程式設計整套帶進 C++11，讓工程師寫分散式、並行程式碼時能少犯一些手動排程容易犯的錯。原文深入介紹了這個語言擴充機制的運作方式。
把 SLO 判斷和成本優化拆開來，雲端服務同時守死線又省四成開銷
雲端服務要同時守住嚴格 SLO 又壓低成本，兩件事通常互相牽制——一收緊死線，成本就跟著往上衝。Spandana 把「SLO 執行」跟「成本優化」拆成兩條獨立迴圈：per-VM controller 負責在毫秒等級的負載尖峰把溢出的請求丟給 FaaS，VM pool 大小則交給另一層慢慢調。實測 CPU 使用率衝到 76–86%，成本卻能砍 5–44%。
PostgreSQL 19 用 io_uring 做非同步 buffered read
PostgreSQL 19 開始用 io_uring 做非同步的 buffered read，這篇文章拆解這個機制怎麼運作，以及對 I/O 效能的實際影響。對還在用同步 read 系統呼叫的資料庫工作負載，這代表核心層有了新的非同步管道可用。
一條 eslint 規則吃掉四分之三的 lint 時間——React monorepo CI 砍七成
一個 React monorepo 的 CI 時間從 9 分鐘砍到 2.7 分鐘，砍幅七成，但關鍵不是加機器，是找到那條真正拖時間的規則。團隊發現單一條 eslint 的 import/no-cycle 規則就吃掉 76% 的 lint 時間——這比先前把三個專案改成平行執行省下的一分鐘更關鍵。
我們蓋了一個內部開發者平台，三個月後八成工程師不再用它
一個團隊照著 Spotify 那套範本蓋了一個內部開發者平台，結果上線三個月後，八成工程師悄悄不再用它。文章把整條時間軸攤開來檢討：從一開始的採用曲線、中間的維護負擔，到最後工程師默默退回舊工作流程。這篇事後檢討的價值，不在平台本身失敗，而在於它把「內部工具沒人用」這種常見卻很少被公開講的失敗模式，講得很具體。
Discord 怎麼在不重拆基礎設施的前提下，算出每個功能的主機成本
Discord 要回答一個常見難題：怎麼知道每個功能實際吃掉多少主機成本，又不用把整套基礎設施重新拆分。他們的做法是在 1700 多個 API endpoint 上做 per-feature 的成本歸因，直接從既有的請求路徑推算，不用強迫服務按功能重新切分。