Always in the middle of something.

TL;DR：GSM1k 研究指出 benchmark 飽和有一大塊是污染，不是真實能力提升。但比污染更值得想的是：我們從來沒有方法驗證模型「學會了一件事」，只有方法量它「在這個分布上會不會答」。每出一份更難的 benchmark，治理面其實沒前進。 每次新模型發表的 blog 我都會點開看一下，幾乎都長同一張表。GSM8k 99%、MMLU 92%、HumanEval 衝到接近 100。看久了會覺得這是某種 ritual，每代都會再比上一代好看一點。 可是把同一個模型放回真實工作裡，丟一份沒進 GitHub 的內部 codebase、丟一份它沒看過格式的會議筆記，它還是會犯那種會讓你嘆氣的錯。這件落差其實已經不是新聞了，奇怪的是每一輪 release blog 還是把分數寫成 state of the art，我每次看到都會有點 ???。我自己在這幾輪 release 之間，慢慢把這個怪怪的感覺磨成一個比較確定的想法：飽和大概不是測量問題，是我們一直沒解過的驗證問題。下面就是這個想法是怎麼長出來的，講起來有點繞，請容忍我一邊想一邊寫。 飽和到底是什麼意思 「分數沒地方爬了」就叫飽和。MMLU 在前沿模型上落在 88% 到 94% 這個窄帶，這個區間裡誰高誰低很大機率只是 noise。GSM8k 上前沿模型已經拿到 99% 上下，再進 0.5 個百分點也沒什麼故事可講。能力提升是真的，問題只是 benchmark 已經不在追蹤它本來要追蹤的那把尺了。 一把尺到頂的時候，你不會看到尺壞掉，你只會看到分數還在漲。刻度跟它後面那個能力之間在這個高度悄悄脫了鉤。直覺上下一步當然會想到「再做一把更長的尺」，這個直覺沒問題，只是這條路後面會撞到結構問題，我們等一下會繞回來。 用得上的證據：GSM1k Scale AI 在 2024 年做了一份 GSM1k 研究，重出 1,250 題、難度跟 GSM8k 對齊的小學數學題，然後重跑一輪。abstract 的數字很乾淨：表現最差的家族在 GSM1k 上掉了 13 個百分點。這個是會出現在所有摘要裡的那個 13。 我自己比較喜歡的是後面那個比較少人引用的數字，老實說第一次讀我也跳過了，第二次回去翻才看到：模型「生成 GSM8k 樣本的機率」跟「GSM1k 與 GSM8k 之間的分數落差」有 Spearman 相關，r² = 0.32。 ...

TL;DR: Benchmark contamination is real and measurable. Scale AI’s GSM1k study showed the worst-performing models dropping 13 percentage points on a rebuilt set. But the deeper failure is that capability evaluation has only ever measured correlation with a test distribution. Harder benchmarks reset the clock. They don’t introduce verification, and verification is what’s actually missing. If you’ve been reading model-release blog posts for a while, the table on page one starts looking familiar. Classic benchmarks near the top, newer harder ones below, every number a hair better than the last generation’s. The explanation everyone reaches for is the saturation story: older benchmarks got too easy, build harder ones, repeat. HLE, LiveCodeBench, FrontierMath, MMLU-Pro all live inside that story. ...

TL;DR: A list comprehension like [n*n for n in range(5)] does the same thing as a small for-loop. It just writes the result first and the source second, which is the opposite of the order you’d write the loop in. If something trips you up, it’s probably that reversal, not the concept. Translate it back into a for-loop and most of the mystery tends to go away. Seeing [x for x in data if x > 0] for the first time and pausing for a second seems like a pretty normal reaction. It doesn’t look like the statements you’ve been writing. No colon, no indentation, and the for has wandered into the middle. Plenty of tutorials just say “this is a list comprehension, it’s very Pythonic” and move on, but I’m not sure that line actually helps anyone read the thing. ...

TL;DR：列表推導式 [n*n for n in range(5)] 其實就跟一個 for 迴圈做一樣的事，只是把「結果」寫在最前面、「來源」丟到後面，順序剛好跟念中文相反。會看不懂多半不是因為它難，比較像是這個順序要花點時間習慣。能把它翻回 for 迴圈來看的話，大概就沒那麼可怕了。 第一次看到 [x for x in data if x > 0] 這種東西會愣一下，我覺得滿正常的。它長得不太像一般的句子，沒冒號、沒縮排，for 還跑到中間去。很多地方會直接說「這叫列表推導式（list comprehension），很 Pythonic」就帶過，可是那句話其實對看懂它沒什麼幫助，看完還是一樣霧。 所以這篇就不背語法了，從大家應該都會的 for 迴圈開始慢慢聊好了，不趕時間。 同一件事，兩種寫法 假設要做一個 0 到 4 的平方數清單。用 for 迴圈大概像這樣寫： squares = [] for n in range(5): squares.append(n * n) ## [0, 1, 4, 9, 16] 三行，開個空 list、跑迴圈、一個一個 append 進去。很普通，沒什麼問題，能跑就好。 換成列表推導式的話，就變這樣： squares = [n * n for n in range(5)] ## [0, 1, 4, 9, 16] 一行，結果一樣。這倒不是我隨口說的，文末附的測試檔就是把這兩種寫法的結果丟去 assertEqual 對，跑出來是相等的。所以大概可以放心把它當成上面那段 for 迴圈的縮寫，因為它字面上差不多就是那個意思，只是擠成一行而已。 怎麼讀它：翻回 for 迴圈來看 我覺得重點在閱讀順序。推導式長這樣： [ 運算式 for 變數 in 來源 ] n * n for n in range(5) 拆成三塊來看的話： ...

TL;DR: Your first Claude Code skill won’t look like the polished examples you’ve read about. It’ll look like a prompt you’ve typed three times in a row, saved into a .md file. This post walks through that minimum-viable shape with a hypothetical four-line /structure-findings skill, shows the three things that break when you save it and type the slash command, then compares it to a real seventeen-line production-grade skill from the framework I use day to day. The longer one has more lines because it has older scars. That’s the whole arc. ...

TL;DR: 你的第一個 skill 不會長得像書裡那些 production-grade 的成熟形態, 它會長得像「你重複打三次的同一個 prompt」。本篇示範一個假設的 4 行入門版怎麼寫、存到哪裡、為什麼會沒跑、撞坑後怎麼修, 然後對照我自己框架裡真的在用的 17 行版本 — 看那些多出來的東西其實都是「撞坑後加上的補丁」, 不是設計階段一次想出來的。 你有沒有打過同一個 prompt 三次?同一段話、同一個格式、同一個角度, 三次。第三次你會開始煩, 第四次你會想:這個我能不能存起來? 那一刻其實就是你的第一個 skill。 不是說那個 prompt 寫得有多好, 是「想存起來」這個衝動就是 skill 出現的位置 — 你已經辨識出一個重複會發生的模式。剩下的事沒什麼神秘的, 把它丟進一個 .md 檔, 用 slash 叫出來而已。 前三篇我談過 skill 是什麼 ——跟 prompt 的差別在哪一層、邊界怎麼劃、拆一個 13 行的 dispatcher 給你看。但這篇有個之前都沒講的事:你的第一個 skill 不會長得像那些。你看過的成熟 skill, 不管是我框架裡的還是別人的, 都是寫了很多次、撞了幾次坑之後才變成那樣的。直接從那邊倒著學, 容易卡在「為什麼要有這條」這種對學習沒幫助的地方。比較好的起點, 就是你那個煩躁的 prompt。 假設你常做研究 舉個例子。你最近常請 AI 幫你看一些雜七雜八的研究筆記 — 三段你 google 來的東西、半段別人 Slack 給你的、一張 issue 截圖貼的內文。你想把它分類:哪些是已經查證的事實、哪些是還沒驗證但你假設成立的、哪些是現在還不知道的問題。 每次貼進去你都打差不多的字:「幫我把下面這團分成 Facts / Assumptions / Unknowns, 三個列點。」打過三次, 想存。 ...

TL;DR: A skill I asked Claude to draft came back as thirteen lines of markdown. Less than a function. The thirteen lines aren’t the skill — they’re a dispatcher pointing to a longer file where the contract actually lives. That split is what separates a skill from a prompt. And the part the model was reliably wrong about — the real interface of the external tool the skill talks to — is the part a human still has to verify. ...

TL;DR: 我請 AI 幫我寫一個能從 Claude Code 裡呼叫 OpenAI Codex CLI 的 skill,它給我 13 行 markdown。看起來小到不像個東西。但這 13 行不是 skill 的全部——真正讓它變成 skill 而不是 prompt 的,是它指過去的那一份比較厚的東西。Skill 是契約的形狀,不是指令的形狀。 前三篇我談過 skill 是什麼。一個 AI Skill 和 Prompt 到底差在哪 把它放進 stack 裡的某一層, Skill 邊界設計 講為什麼邊界比能力重要, Skill Design as Interface Design 是英文版用 API 設計的角度寫的。 這篇換個角度:真的拿一個給你看。 挑 /codex-cli 這個 skill,因為它小到適合當教材。它在我那邊的工作是:從 Claude Code 想把某個任務丟給 OpenAI 的 codex CLI 去跑,我打 /codex-cli 修 README 的 typo,它就接手。 13 行長這樣 我請 AI 幫我寫第一版的時候,它給我這個: # /codex-cli Execute the canonical workflow: `.agent/workflows/codex-cli.md` ## Execution Follow every step in `.agent/workflows/codex-cli.md` sequentially. The user's task description is: $ARGUMENTS - [OPTIONAL MODULE] Requires globally installed `codex` CLI (`npm install -g @openai/codex`). - If CLI is unavailable, inform the user and fall back to native execution. - End response with ⚡ ACX. 就這樣。13 行。沒有複雜的 prompt engineering, 沒有冗長的 system message, 沒有 chain-of-thought 模板。第一次看到的時候我有點疑惑:這就是一個 skill? ...

TL;DR： MCP 在一年多內，從 Anthropic 的內部實驗變成 AI 業界共通的介面。但進入 2026 年，資安研究員一個接一個把它拆開：官方 SDK 的 by-design RCE、tool poisoning、rug pull。我的看法是，這些漏洞大多不是協定的 bug，而是「把能力交出去、卻沒把治理一起交出去」的必然結果。現在大家急著補的那些東西，OAuth scope、人工確認、伺服器註冊表，其實就是治理被重新貼回協定上。 2026 年 4 月，資安團隊 OX Security 公布了一個發現：MCP 的官方 SDK（Python、TypeScript、Java、Rust 全中）存在一條從設定檔直接到指令執行的路徑，攻擊者可以在任何跑著有問題實作的機器上執行任意系統指令。根據他們的估算，受影響的套件下載量超過 1.5 億次，潛在波及的伺服器實例上看 20 萬個（The Register 的報導用的標題就是「20 萬台伺服器有風險」）。後續整個生態跟著冒出一連串 CVE，包括 MCP Inspector 的 CVE-2025-49596 和 Cursor 的 CVE-2025-54136。 但真正讓我停下來想的，是 Anthropic 的回應：這是設計如此（by design）。他們不打算改協定，並表示輸入清洗是開發者自己的責任。 這句話可以有兩種讀法，而我認為兩種都對。這正是整件事最值得想的地方。 先講清楚：MCP 為什麼會贏 要評論 MCP 的資安問題，得先承認它解決了一個真的很煩的問題。 在 MCP 之前，每接一個工具到 AI 上，你就得寫一套各自為政的膠水。M 個模型乘上 N 個工具，等於 M×N 種接法。MCP 把它變成 M+N：工具實作一次 server，模型實作一次 client，中間用同一套協定講話。Anthropic 當初的比喻是「AI 的 USB-C」，這個比喻站得住，是因為它真的描述了發生的事。 ...

TL;DR: MCP went from an Anthropic side-project to the industry’s default agent-to-tool interface in about a year. Then 2026 brought a steady drip of disclosures: a by-design RCE in the official SDKs, tool poisoning, rug pulls. My read is that almost none of these are protocol bugs. They’re what happens when you ship capability without shipping governance, and the patches now landing (OAuth scopes, human-in-the-loop, registries) are just governance being bolted back on. ...