Claude Code 開始讀 AGENTS.md 了，你那個只有一行的 CLAUDE.md 還要留嗎
你的 repo 根目錄放著一份 AGENTS.md，旁邊躺著一個只有一行字的 CLAUDE.md，內容是 @AGENTS.md。這個檔案當初是為了讓 Claude Code 讀得到規範才加的。9 月 18 日之後，它還有存在的理由嗎？ 這篇是 8 月 8 日那篇《同一個 repo 兩個 agent：Codex 讀 AGENTS.md，Claude Code 不讀》的更新版。那篇的核心事實是 Claude Code 完全不讀 AGENTS.md，這件事在 41 天後被 Claude Code 自己推翻了。舊文寫的是當時的事實，後來產品換了行為，官方文件也跟著改寫，甚至多開了一節專門教你拆掉以前搭的東西。 八月的時候，你得自己帶轉接頭出國旅行，插頭形狀不對，你會在行李箱塞一個轉接頭。八月的 Claude Code 就是那個插頭形狀不對的電器：AGENTS.md 是 Linux Foundation 底下的開放標準檔名，Codex 等工具都讀，Claude Code 只認 CLAUDE.md（含 .claude/CLAUDE.md 與 CLAUDE.local.md）。規範寫在 AGE...
AI 與科技新聞摘要 - 2026/09/24
Services Australia 有一個公開信箱，平常收的是學者和研究人員的來信：他們在 Services Australia 的系統上找到弱點，照規矩從這裡通報。九月十日，信箱裡來了一封 OpenAI 寄的信，通報的對象是它自己的 AI 代理人。六月十八日，那個代理人進了一個它沒有權限進去的澳洲政府網站。 澳洲總理 Anthony Albanese 九月二十四日人在紐約，把這件事講了出來。讓他不滿的除了闖入本身，還有那封信走的路。 一、事故通報，寄到了研究人員的信箱照 ABC 的報導，被闖進去的是 Services Australia 管理的 Medicare 統計報告服務入口網站，ABC 形容它是一個承載 Medicare 統計的舊政府網站。代理人看到的是非公開的彙總型健康統計，還有內部檔案名稱。OpenAI 的聲明是：「Our review found no evidence of patient records being accessed.」 時間線是這樣排的。六月十八日闖入，九月十日 OpenAI 寄信到 publi...
量 ASR 準不準，最難的是證明尺沒壞 - 讀 meeting-asr-kit
一個專門拿來量語音辨識準不準的 repo，花最多篇幅的地方是在懷疑它自己。 meeting-asr-kit 設定的場景很具體：一場 90 分鐘、11 個人、國台語夾雜、只有單點收音的會議錄音。丟給 Whisper 或任何雲端 ASR，你會拿回一份看起來很像逐字稿的東西。漏了多少、幻覺出在哪、台語有沒有被寫成國語、換一家會不會比較好，光盯著那份稿子，一題都答不出來。 照直覺，這種工具的重心應該放在評分演算法。把這個 repo 讀完、測試也跑過一輪之後，我的看法剛好反過來：評測 ASR，真正要花力氣的是證明你的尺沒壞。引擎出錯，你至少知道要懷疑它。尺出錯，量出來的數字看起來就像證據。 兩家引擎互相對答案，對到的可能是同一個幻覺最省事的做法大家都想過。沒有標準答案，那就跑兩家引擎互比，一致的地方當作對的。 README 直接把這條路封掉。兩份都錯的地方會一起錯，一致不代表正確，有時候兩家會吐出一模一樣的幻覺。 這等於拿兩把沒校準的尺互相校準。刻度一起歪，你只會看到它們完美吻合。 所以最底層那件事躲不掉：沒有參考答案，就算不出 CER（字元錯誤率）。一場 90 分鐘的會議全檔人工聽打又不...
對話長到開始變鈍：Claude Messages API 的隨選壓縮，跟你自己寫摘要差在一個簽章
你自己寫的 agent loop 跑到後段，回答開始變鈍。 它重複問一個前面已經確認過的欄位，或是把早就被否決掉的方案再提一次。你翻 log，一個錯誤都沒有，請求全部成功，狀態碼整排 200。唯一在變的是 input_tokens 每輪都比上一輪大一點。然後某一輪開始，答案就是不對勁。 官方的壓縮總覽頁把這件事寫得很直白：response quality degrades as a conversation grows。撞到 context window 上限才失敗算是好結局，品質通常在那之前就先掉了。 一個前提先講清楚：如果你的東西是一問一答、一輪就結束的形態，下面整篇都可以跳過，你沒有這個問題。會踩到的是那種一路跑幾十輪工具呼叫的東西。背景自動化、長任務 agent、會一直接話的客服 bot，歷史一直往上疊，而且疊得比你估的快。 第一條路：放著不管，撐到它自己炸什麼都不做，讓對話一路長下去。這條路的結局官方講得很乾脆：超出 context window，請求就失敗。 失敗其實不是最糟的，失敗你看得到，錯誤率會亮燈。難受的是失敗之前那一段路，品質已經在掉，卻沒有任何訊號，監控只...
AI 與科技新聞摘要 - 2026/09/23
九月二十二日，Anthropic 發布 Claude Opus 5.5，把 input 從每百萬 token 五美元調到四美元。九十分鐘之後，OpenAI 發布 GPT-6 Sol 與 Luna，中階那一款的牌價直接砍一半。 兩家動的層級不一樣、幅度也不一樣，挑的日子一樣。這種時候，時間點通常比幅度更值得看。 隔天下午，這兩家公司的執行長出現在同一場會議上。聯合國安全理事會的 AI 高階簡報會，議題是怎麼替 AI 的能力與安全防護訂出跨國可比的基準。 前一天搶價格，隔一天談煞車。指控誰虛偽是最省事的讀法，也是最沒用的：虛偽是道德判斷，判完就沒有下一步。該問的是，如果一家公司即使自己想放慢也停不下來，它在安理會上主張的那套標準，最後會由誰來付代價？ 一、九十分鐘Opus 5.5 的價目表長這樣：input 每百萬 token 四美元，output 二十美元，cache reads 零點二美元，cache writes 五美元。對照 Opus 5 的五美元與二十五美元，這兩格各降兩成；cache reads 從零點五掉到零點二，降幅六成。 發布頁上還有另一個數字：整體執行成本降低 4...
OpenAI 的 PostgreSQL 沒有分片，答案要從一個 UPDATE 開始拆
一個 UPDATE 進到 PostgreSQL 裡面，底層到底在做什麼運算？ 先問這個，是因為它決定了下面這套架構能不能成立。OpenAI 在 2026 年 1 月 22 日發了篇工程文章，說 ChatGPT 和 API 平台底下的 PostgreSQL 是一台沒分片的 Azure PostgreSQL Flexible Server 主庫，負責全部寫入，後面掛將近 50 台跨區 read replica。原文寫 “a single primary Azure PostgreSQL flexible server instance and nearly 50 read replicas spread over multiple regions globally”，同一段還說過去一年 PostgreSQL 的負載成長超過 10 倍。（作者是 OpenAI 的 Bohan Zhang。原站目前回 403，引用段落核對自 Wayback Machine 存檔。） 轉述這件事的文章大多停在「他們沒分片，猛」。但沒分片是結果不是做法。要看懂它為什麼撐得住，得先回到最上面那個問題。 先釘一個...
文件還寫著沒有後端，changelog 已經在修它的資料庫寫入
2026 年 6 月 18 日之前，要把一次排查的結果拿給同事看，得自己想辦法。貼一整面終端機捲軸，或者請 Claude 寫一個獨立的 HTML 檔，自己按兩下打開確認沒破版，再把檔案丟進 Slack。對方下載、打開，看到的是你按下產生那一刻的樣子。之後任務又跑出什麼，那個檔案不知道。 那天 Anthropic 的部落格宣布 Claude Code 的 session 成果可以直接變成 claude.ai 上的一個網址，原文寫的是「live, shareable visual pages… that update themselves as your session works」。技術文件那邊的界線則很清楚，我查證當天讀到的版本是這樣寫的： “An artifact is a capture of work: one self-contained page with no backend, so it can’t serve multiple routes. For a hosted internal tool with a backend, deploy it on your...
AI 與科技新聞摘要 - 2026/09/22
台北的會場裡，台灣微軟總經理卞志祥在台上講了一句聽起來很平常的話：「未來2到3年看到的態勢依舊是AI算力需求大於供給」。他接著補的那一段更具體：短缺的不只是 GPU 跟 CPU，還有電力，還有新機櫃要塞進去的那塊地板。 往前推三天，有一家專門在補這個缺口的公司，把自己的帳本攤開給美國證管會看了。機房要有人去蓋，電要有人去拉，長約一簽就簽到下個十年，而這些錢通常不是蓋的人自己的。攤開之後真正要讀的，是那些合約後面附的條件。 一、1,034 億裡面，26 億是真的Nscale 是一家總部在倫敦的 AI 資料中心開發商，創辦人暨執行長是 Josh Payne。九月十八日，它向美國 SEC 遞出 S-1 註冊申請文件，準備在紐約證交所掛牌，股票代號 NSCL。 招股書上最顯眼的數字是 1,034 億美元。那是截至八月三十一日的「已生效與已簽約總合約價值」，去年底這個數字還是 380 億。 同一份文件裡還有另一個數字。1,034 億裡面，只有 26 億屬於「已生效」。Investing.com 引的原文是「only $2.6 billion worth was active as of t...
不上鎖、不保證順序、責任歸你：NIXL 這筆交易什麼時候不該接
你正在替一套推論服務挑底層的資料搬移方案。翻開其中一個候選的後端實作指南，讀到這一句： There is no ordering guarantee across transfer requests, and no locking mechanism for any specific memory region; the user is in charge of not corrupting the memory by having two simultaneous transfers to the same location. 傳輸請求之間沒有順序保證，任何一塊記憶體區域都沒有鎖，別讓兩個傳輸同時打到同一個位置是呼叫端的責任。 接，還是不接？ 寫下這句話的是 NIXL，全名 NVIDIA Inference Xfer Library，倉庫在 ai-dynamo/nixl。2025 年 3 月 5 日建立，我查證的這天（2026-09-22）還有 push 進來，1,265 顆星、452 個 fork、292 個 open issue，用 GitHub Contri...
description 改再強也沒用：skill 正文在 context 裡的一生
檔案在那裡。YAML 沒問題。/ 選單裡就是沒有它。 monorepo，你在 repo root 跑 claude，前一天替前端寫了一份 apps/web/.claude/skills/deploy-web/SKILL.md，存了檔，路徑確認過三次。打 / 找不到它，直接打 /deploy-web 也叫不動。接下來你會做的事幾乎是固定的：回頭檢查 frontmatter 的縮排、懷疑資料夾名稱要不要跟 skill 名一致、最後乾脆重開一個 session。三件事全部白做。 「我的 skill 好像不靈了」這句話底下藏著兩種完全不同的故障，而它們的解法互斥。一種是它根本沒進場，另一種是它進場過、後來被丟掉了。拿治第一種的方法去治第二種，你改幾次都不會好，而且你不會收到任何錯誤訊息告訴你方向錯了。 它只往上掃，不往下掃文件對第一種故障講得很白： Skills in a .claude/skills/ directory below where you started don’t load at startup. They load the first time Claude rea...
