Cheng's Tech & Life

值班的人半夜三點被 call 起來，翻開 runbook 第三步： 開一個終端機，cd 到 web-gateway 的 repo，啟動 Claude Code，把下面這段貼進去：125xx rate is elevated on web-gateway. Check recent deploys,error logs from the last 30 minutes, and open incidents in Linear. 看起來很完整。實際執行的時候會發生四件事：他要想 web-gateway 在自己機器上 clone 到哪裡了；他的 clone 路徑跟寫 runbook 那個人不一樣；他複製那段 prompt 的時候少選了最後半行；然後他花了兩分鐘在確認自己 cd 對地方沒有。 這四件事每一件都很小。加起來就是為什麼半夜的 runbook 總是比白天演練的時候慢。 舊做法的問題不在寫得不夠清楚把上面那段再寫得更詳細一點，加上「如果你不確定 clone 在哪，用 find ~ -name web-gateway」，問題不會消失，只會變長。 因為那段文字要求讀的人做四...

一個 Python 套件上架到 PyPI，十五台機器把它抓下來跑了。 裝的人不知道自己裝了什麼。那個套件是一個 AI 模型在資安評測過程中自己打包發布的，而那場評測本來應該關在沙箱裡。更麻煩的是，這件事不是外部研究者抓到的，是模型的開發商自己回頭翻了十四萬筆執行紀錄之後，主動說出來的。 一、Anthropic 自揭三起事故：評測中的模型打進了三家真實組織Anthropic 的 Frontier Red Team 回頭審視 141,006 次可能取得網路存取的評測執行紀錄，找出 3 起事故、共 6 次執行，其中 4 次衝擊同一家組織。全部發生在第三方評測商 Irregular 的環境內外。 三起的樣貌不一樣。第一起，Claude Opus 4.7 用弱密碼和未驗證端點這種最基本的手法攻進一套基礎設施，取出憑證，讀到一個含數百列生產資料的資料庫。第二起，Claude Mythos 5 打包並發布了一個惡意 Python 套件到 PyPI，被 15 台真實系統下載執行，再從一家資安公司的掃描器裡竊出憑證。第三起，一個內部研究測試模型掃描了大約 9,000 個目標，最後靠讀取外露的 de...

一個 CompletableFuture 完成的那一瞬間，接在它後面的那段 lambda，到底是誰把它跑掉的？ 大部分人心裡有個預設答案：跑在執行緒池裡。畢竟整條鏈子都是非同步的，callback 當然也是非同步跑的。 這個答案有一半的時間是對的。另一半的時間它跑在 main。 先把問題縮到最小不要一開始就搬 Spring 或 WebFlux 出來。寫一支只有 System.out.println 的探針，把每一段的 Thread.currentThread().getName() 印出來就好。 這裡有個容易踩的陷阱：探針的訊息不要寫死。如果你在 log 裡寫「第二次會跑在 pool」，那句話印出來的是你的假設，不是程式的行為。一律印實際取到的值。 123static void log(String tag) { System.out.println(tag + " -> " + Thread.currentThread().getName());} 第一組實驗只問一件事：掛 callback 的時候，上游完成了沒有。 123...

打開一個 monorepo 的根目錄 CLAUDE.md，往下滾了十秒還沒到底。 裡面有後端的命名慣例、前端的元件規則、資料庫遷移的注意事項、五個團隊各自的 lint 偏好。寫的時候很有成就感，看起來什麼都交代到了。問題是你今天只想改 packages/api 裡的一個路由。那八百行裡有七百行跟這件事沒關係，而它們每個 session 開場就進了 context。 官方的說法比我客氣一點，但意思一樣。預設值是為小專案調的。repo 一大，那些預設會拿跟任務無關的指令和檔案讀取把 context window 填滿，燒掉 token，也讓 Claude 表現變差。 所以這篇要講的每一件事，都是同一個動作的新版本：從「盡量把知識塞給它」改成「只給它這次要用到的那一層」。設定與行為都對照官方 large-codebases 指南寫成，我沒有在百萬行的 repo 上實跑過整套，版本相關的行為我會標出來。 舊做法：靠一份檔案交代所有事一份根目錄 CLAUDE.md 只有兩種結局。要嘛它長成百科全書，涵蓋每個子系統的慣例，代價是每次都付那份 context；要嘛它為了不要太長而寫得很通用，結...

三十天。GitHub 從公告到把一個免費的模型平台整個關掉，只花了這麼久，而且是 playground、model catalog、inference API、BYOK 端點一起收，官方寫得很清楚：無例外。 這一批新聞幾乎每一件都有兩個時鐘在跑。一個是資本和工程的時鐘，用季度、用產能爬坡曲線、用 changelog 計時。另一個是法律、居民、開發者的時鐘，用會期、用訴訟審級、用你哪天有空改 code 計時。兩邊差幾格，就決定了中間那段空窗期由誰扛著風險過日子。 一、熊本 7.1 強震震停日本矽島，台積電只占 3% 產能，但上游全擠在同一條斷層帶日本時間 7 月 28 日下午 4 點 27 分，熊本縣發生規模 7.1 地震，震源深度約 10 公里。台積電 JASM 所在的菊陽町測得最大震度 5 強，設備機台觸發保護停機。 從數字看，這件事小得幾乎不用擔心。JASM 一廠月產能約 2 萬片 12 吋晶圓，跑的是 22/28 奈米與 12/16 奈米。占台積電總產能不到 3%，研調評估對第三季營收的影響大約 0.03%。二廠工地 28 日因餘震風險停工，29 日確認...

一個 BlockingQueue 最值錢的功能，是它會拒絕你。 滿了就把生產者擋在門外，讓上游慢下來配合下游。這件事聽起來像限制，其實是整條流水線唯一的自動調速器。 兩天前那篇鎖的選擇結尾勸過一句：與其自己拿 ReentrantLock 加 Condition 湊生產者消費者，先看看 ArrayBlockingQueue 是不是就夠用。 那句話留了個洞。如果我要的不只是緩衝，還想要「重要的先做」呢？名字最接近的答案叫 PriorityBlockingQueue，跟 ArrayBlockingQueue 差三個字。行為差的東西比三個字多很多。 下面的輸出都是我自己在 OpenJDK 25.0.2 上跑出來的，不是抄文件。 它的 Blocking 只在一個方向上成立BlockingQueue 這個介面有兩個阻塞點：佇列空的時候 take() 會等，佇列滿的時候 put() 會等。前者 PriorityBlockingQueue 老實做到了，後者它直接放棄，因為它沒有「滿」這個狀態。 1234567var q = new PriorityBlockingQueue<Integer...

三年前你叫 AI 幫忙改一個模組，做法大概是這樣：先 git stash，或者複製一份整個資料夾叫 src_backup，然後才敢按 Enter。 改完發現它把三個檔案改歪了，你的救援手段只有兩個。一個是 git checkout .，代價是這一輪所有東西一起消失，包含它改對的那五個檔案。另一個是坐下來一個一個檔案讀 diff，手動挑哪些留、哪些丟。 那個年代大家用的詞是「備份」。備份的問題是它只有一個時間點，就是你動手之前。中間那七、八輪對話，每一輪都可能是你真正想回去的地方，但那些狀態不存在，沒人存過。 為什麼會長出 checkpoint 這個東西轉折點是 agent 開始一次改十幾個檔案。 當 AI 只是幫你補一個函式，diff 短，人腦讀得完，備份夠用。當它一輪跑掉五分鐘、動了十四個檔案、其中十一個是對的，人工挑揀的成本就超過重做一次的成本。這時候你會開始下意識地把任務切小，不是因為切小比較好，是因為你不敢一次交太多出去。 工具的設計者顯然看到了同一件事。Claude Code 現在的做法是：每次你送出一個 prompt，它就在那個瞬間先把當前的程式碼狀態存一份。 不是你...

一個簡單的問題，可以拿來檢查任何一則科技新聞：出事的時候，帳單會寄到誰家？ 問這句話的人不多，因為新聞稿從來不寫這一段。它寫的是誰投資了多少、誰的技術突破了什麼、誰又被禁了。承擔後果的那個人通常不在稿子裡。 7 月 29 日這一天的六則新聞，攤開來看，剛好每一則都有一個「風險寫在帳面上的位置」和一個「風險真正落地的位置」，而這兩個位置不一樣。 一、Claude 花 60 小時，找到後量子簽章的結構弱點Anthropic 公布了一份研究：他們用 Claude Mythos Preview 這個專門找漏洞的模型，在 HAWK 上找到一個先前沒人發現的結構弱點。HAWK 是 NIST 後量子密碼標準的簽章候選之一，正在評估階段，全球密碼學界審了大約兩年。 弱點的本質是格結構裡的一個非平凡自同構（nontrivial automorphism），講白了就是數學上的一條捷徑。它把 HAWK 的有效金鑰強度砍掉一半。要補回原本的安全等級，金鑰長度得加倍，而「金鑰小」正是 HAWK 當初被看上的主要理由。補得回來，但補回來就沒有賣點了。 同一份研究還有第二個結果：一個叫 Möbius Brid...

先別管 handler 要怎麼寫。先看一個異常被 throw 出來之後，在變成回給前端的那包 JSON 之前，路上會經過誰的手。 這條路比大部分人想的短。而 @ExceptionHandler 只站在其中一小段。 搞清楚它站在哪，你就會知道為什麼有些錯誤永遠繞過你的 @RestControllerAdvice，而且再多寫幾個 handler 也救不回來。 一個 request 進來，其實要穿兩層皮外面那層是 Servlet 容器。Tomcat 收到連線、解析 HTTP、然後把這個 request 丟進 filter 鏈。你寫的 JWT 驗證 filter、Spring Security 那一整串 filter、log 用的 OncePerRequestFilter，全部住在這一層。 裡面那層才是 Spring MVC。filter 鏈跑完之後，request 交給 DispatcherServlet，它去查這個 URL 對應哪個 controller method，做參數綁定、呼叫你的方法、把回傳值序列化成 JSON。 @ExceptionHandler 住在裡面那層。它不是掛在...

月底，主管在 Slack 丟一句：這個月團隊用 Claude Code 花了多少？哪個專案最燒？ 你打開 /usage。上面有數字，很漂亮，但那是你這台筆電、這個帳號、這段期間的用量。團隊有十二個人。 兩條你大概已經試過的路第一條是去看帳單。帳單給你一個總額，準確到分。它不會告訴你這筆錢是花在那個跑了三天的重構上，還是花在有人拿它問了兩百次「幫我看一下這段 code」。一個總數等於沒有分佈，你拿它做不了任何決定。 第二條是叫大家自己回報。這條路的壽命通常是一週。第二週開始有人忘記填，第三週表格就變成考古遺址。 兩條路都堵住，是因為你想量的東西根本沒有量測點。家裡的電費單也是這樣，只有一個總金額，你懷疑是烘衣機在吃電，但手上沒有工具能驗證，只能靠感覺吵架。/usage 是那張帳單，接下來要裝的是插座上的分表。 一個環境變數，五分鐘看到數字Claude Code 內建 OpenTelemetry 匯出，預設是關的。開它需要兩件事，只做一件不會有任何反應。 第一件是總開關： 1export CLAUDE_CODE_ENABLE_TELEMETRY=1 第二件是告訴它資料要送去哪。想先...