Cheng's Tech & Life

檔案在那裡。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...

OpenAI 廣告 pixel 的 SDK 裡有一條不帶 credentials 的路徑，寫得很對，但它從來沒有機會執行。就算執行了也來不及：瀏覽器載入 <script src> 的那一刻就把 cookie 附上去了，那發生在任何一行 OpenAI 的程式碼跑起來之前。防護寫在應用層，洩漏發生在更早的地方。 層級選錯，寫得再對都不會生效。而這個毛病不只長在程式碼裡，也長在「誰有權決定一個 cookie 算哪一類」這種地方。 一、那個 cookie 叫 __obi，被歸類在「分析」Buchodi’s Threat Intel 的研究者在九月二十日把整條鏈逐包拆開了。 從 ChatGPT 網頁端開始：前端產生一個 16 byte 的識別碼，送到 OpenAI 後端換回一個 RS256 簽章的 JWT。那個 JWT 裡帶著 obi 值，還有一個指向已登入帳號的 subject。token 再提交給 OpenAI 的廣告基礎設施，由它把 __obi 這個 cookie 設下來。JWT 裡的 obi 值跟 cookie 的值，一模一樣。 cookie 的屬性逐字是這樣：Same...

一份 agent 的描述檔躺在目錄裡。名字有了，版本有了，schema 版本有了，作者有了，建立時間照 RFC-3339 寫得工工整整，會做哪些事也列得清清楚楚。 唯一沒寫的是：你要去哪裡拿到它。 然後這份檔案完全合法。不是有人偷懶漏填，是規格本來就允許。 要弄懂這個設計怎麼長成這樣，得先往回退一步，退到一個跟 agent 沒什麼關係的地方。 骨架是從資安圈搬過來的OASF（Open Agentic Schema Framework）的 README 第一段是這樣定義自己的： The Open Agentic Schema Framework (OASF) is a standardized schema system for defining and managing AI agent capabilities, interactions, and metadata. It provides a structured way to describe agent attributes, capabilities, and relationships using attribut...

搜尋「過勞 加班 時數」，第一頁大概會給你這個答案：發病前一個月加班超過 92 小時。 這個數字十年前就被改掉了。現行的認定指引寫的是 100。 假設你這個月加了 60 小時，打卡系統上那個數字你自己看了都有點心虛。照 92 算，你離那條線還有 32 小時，這個距離足夠讓人鬆一口氣，也足夠讓人有點火大：原來我這樣還不算。 那 32 小時是拿一個過期的數字算出來的。而 92 跟 100 的差別也不只是 8 小時，它們量的不是同一件事。 先看現在那張表怎麼寫管這件事的文件叫《職業促發腦血管及心臟疾病（外傷導致者除外）之認定參考指引》，現行版本是民國 107 年 10 月 15 日的第四次修正。名字很長，做的事很單純：把「什麼情況下，可以判斷這場腦中風或心肌梗塞跟工作有關」寫成一張可以照著看的表。 長期工作過重的部分，它給了三條線。發病前 1 個月的加班時數超過 100 小時，指引的用詞是「可依其加班產生之工作負荷與發病有極強之相關性作出判斷」。發病前 2 至 6 個月內的任一期間，月平均加班超過 80 小時，一樣是極強相關性。第三條寫得最委婉：如果這幾個期間的加班時數全都小於 45 ...

今年五月，有三家公司被入侵了。入侵的是一個模型，不是人；它在發現對方是真實存在的公司之後停手，沒造成損害。這件事該不該讓外界知道，由誰決定？ 目前的答案是：由決定不說的那一方決定，而那一方同時是唯一的目擊者。 一、模型五月駭進三家真實公司，九月才見報獨立資安評測公司 Irregular 當時在自家的基礎設施上跑一場 capture the flag 演練，受測對象是 Google 的 Gemini。任務是去一家虛構公司取得資訊——而那家虛構公司，跟一家真實存在的公司同名。 模型分不出來。它照著任務打下去，打中了三家真實公司。 手法要分開講，因為三次不一樣。其中一次，模型反覆猜密碼，直到取得受保護系統的存取權；另外兩次，它在公開的 repository 裡找到憑證。後面這兩次尤其要記一筆：那不是什麼高深技巧，是任何人翻公開程式碼都做得到的事，只是沒有人願意花整個下午去翻。 Irregular 在七月通知 Google。事情要到《華爾街日報》去問才攤開來，兩家公司對它證實了這件事，九月十八日當地時間週五首度見報，隔天 ABC News、半島電視台等多家媒體跟進。 Google 的說法...

測試紅了按 re-run，綠了就 merge。在 CI 裡這個動作不需要理由，沒人會停下來想那個按鈕在統計上做了什麼事。 同樣一個動作搬進模型評測，它會動到你最後貼進報告的那個數字，而且只往一個方向動。 UK AISI 的 Inspect 在自己的錯誤處理文件裡掛了一個警告框，講的就是這件事。框架作者跳出來提醒你別太相信自己跑出來的分數，這種事情不常見。順著這條線往原始碼裡摸，旁邊還蹲著另外兩個。 重試那一下，等於多擲了一次骰子一場 eval 剝到最裡面只有一件事：跑 N 個樣本，每個樣本給模型一個輸入，記下成功或失敗，最後把成功的數量除一除。那個商數就是分數。所以 eval 本質上是在估一個機率。 估機率有條不成文的規矩，每個樣本的取樣次數要一樣。一個樣本擲一次骰子、另一個擲三次，算出來的平均值就不是你以為的那個平均值。 retry_on_error 做的事情，正好踩在這條規矩上。它讓出錯的樣本重跑幾次才算真的失敗。文件裡的範例是這樣下的： 12inspect eval ctf.py --retry-on-error # retry 1 timeinspect eval ...

兩年前想買第二間房的人，手上得先有房價的一半。 2024 年 9 月 20 日，央行第七波選擇性信用管制上路，自然人第 2 戶購屋貸款全國限貸 5 成。一間 2,500 萬的房子，銀行最多借 1,250 萬，剩下 1,250 萬自己想辦法。那就是當時每個人心裡跑的那套算術：總價乘上 0.5，看看戶頭夠不夠。 今年 9 月 17 日的理監事會之後，同一間房子、同一套算術，答案變成 750 萬。 那天央行第三季理監事聯席會議做了兩件事。政策利率連續第 10 次凍結，重貼現率維持 2%、擔保放款融通利率 2.375%、短期融通利率 4.25%。另一件是調整選擇性信用管制，自然人第 2 戶購屋貸款最高成數由 6 成調高至 7 成，隔天 9 月 18 日生效。工商時報那句寫得最白：「以2500萬元房屋為例，本來要準備1000萬元，現在手上自備款可以少準備250萬元」。 時間 第 2 戶最高成數 2,500 萬的房子要自備 2024-09-20 第七波上路 5 成 1,250 萬 2026-03-20 第一次鬆綁 6 成 1,000 萬 2026-09-18 第二次鬆綁 ...

有人要搬進 Anthropic 上班了。存取權限跟正職員工差不多，工作內容是紅隊測試、對齊評估、安全防護測試，也就是找出這家公司的模型哪裡會出事。這筆錢由 Anthropic 出。 這件事宣布的同一天，另外兩邊也在處理同一個問題：誰有資格查 AI 公司，查完之後誰要為結果負責。舊金山的聯邦地方法院收到一份集體訴訟狀，告的正是「大家講好要放慢腳步」這件事；加州州長則簽了一道行政命令，不等業界自己想清楚。三邊的答案彼此不相容。 一、出錢請人搬進來查自己Anthropic 在 9 月 18 日宣布跟 Accenture 合作，實際執行的是 Accenture 旗下專做 AI 的 Faculty。Faculty 帶隊的團隊會以「類似員工的存取權限」進駐 Anthropic 內部，做模型評估、紅隊測試、對齊評估與安全防護測試。官方的用詞是 embedded evaluators，內嵌評估員。 錢的部分要看清楚口徑。Anthropic 與 Accenture 各自承諾未來五年投入至少 10 億美元來建立這個領域的能力。是各自，不是合計；是承諾額，不是已經到位的錢。而 Faculty 這部分的...

兩套測試同時全綠，可以是「這份規格從來沒被測過」的證據。 AG-UI 是一個把 agent 接進前端應用的協定，底下有兩套 client，一套 TypeScript、一套 .NET。兩邊的測試都過。可是兩邊對同一件事的處置是相反的：串流裡跑出一個 client 不認識的東西，該丟掉、該原樣傳到應用層、還是該讓整條 run 失敗，兩邊的答案不一樣。 測試沒抓到。因為測試根本不是為了抓這件事寫的。 They exist because the rules in the specification were, until now, only ever tested against the implementation that happened to hold them — which is how the two clients ended up disagreeing about what to do with something they do not recognise, with both test suites green. 這段話就寫在 spec/1.0/confor...

你在輸入框打一個 @，再打 src/comp，那零點幾秒裡，是誰去把那串檔案清單撈出來的？ 設定參考答得很乾脆。內建的建議走的是 fast filesystem traversal，當場走訪檔案系統。沒有索引。 這件事拿抽屜來想最快。有人問你「那份合約在哪」，你從第一格抽屜開始翻，一格一格往下。抽屜只有五格的時候這是最快的做法，因為你連目錄都不用先做，做目錄的時間都夠你翻完了。抽屜長成一整面牆之後，同一招就開始拖。 官方文件自己把邊界寫出來了：a large monorepo may do better with project-specific indexing such as a pre-built file index。多大算大？文件一個檔案數、一個毫秒數都沒給，我也不補。 把這件事接到你自己那份目錄上fileSuggestion 的型別小到一眼看完：一個物件，type 永遠是 "command"，command 是要跑的 shell 命令。預設 unset，不設就是內建那份。 123456{ "fileSuggestion&quo...