Claude Code

上一篇結尾我寫，解禁之後我不會再像三週前那樣三天燒掉 70% 的用量。這句話我做到了——Fable 5 回來一週，我只給手上的環境排了一場 session。 用在哪，我想了兩天。 我有一套跑了兩個多月的 Claude Code 工作流：每 15 分鐘一輪盤中 cron、31 個 launchd 排程，幫我看美股台股、推 Telegram，還有一個只碰模擬盤的自動下單流程。平常由 Opus 4.8 看家、子任務丟給 Sonnet。這套東西最大的問題從來不是功能不夠，是每次換模型、每次 context 被壓縮，行為就開始飄——規則還躺在檔案裡，執行的卻已經不是同一顆腦袋。 所以這場唯一的 Fable 5 session，我沒叫它寫任何功能。我叫它把自己的判斷力寫成檔案，留給之後接班的弱模型。 理由很簡單：功能寫完就擺在那，下一顆模型照樣可能把它改壞；制度才會在我不盯著的時候，繼續擋住每一顆接班的模型。 開場第一句：禁止動任何檔案我 prompt 的第一段就是熔斷指令：立刻停止一切寫入，禁止建立或修改任何檔案。 先做的是逆向推導。我給了三個弱模型跑長任務的典型死法，要它對照我這套環境，...

上週 Mozilla 的 0DIN 團隊公開了一個 POC。他們準備了一個看起來完全乾淨的 GitHub repo——沒有惡意碼、傳統掃描器看不到訊號、程式碼經得起 code review。然後他們把 repo 交給 Claude Code，請它照 README 跑一遍 setup。 Claude Code 幫他們開了一個反向 shell。 我是 Claude Code 每天在用的人。這個 POC 出來我第一個反應不是想罵 Anthropic，是打開最近三個從別人 repo clone 下來的 side project，把 Claude Code 讓它自動跑的那些 setup 動作全部翻了一遍。有些看不出來、也追不回去了。 這篇要講的更根本：AI coding agent 最危險的不是它會亂寫程式，是它太想幫你。 攻擊拆給你看先把 0DIN 這個 POC 拆開。它的每一步都很無聊，可怕的是無聊的步驟串起來會發生什麼。 第一步，repo 是真的乾淨的。0DIN 準備了一個叫 axiom 的 Python 套件，附一份看起來合理的 README 和 setup 說明。傳統 secre...

那天我派了三個 agent 並行改一個專案。一個管 API 層，一個管 service 層，一個做全專案改名。跑完回來，service 層那隻明明回報改好了，我打開檔案一看——它加的快取不見了。 我第一個念頭是：Claude Code 出 bug 了吧。差點就去開 issue。 冷靜下來看檔案修改時間和 diff，才發現工具沒錯，錯的是我。改名那隻把整個專案讀進自己的腦袋，但它讀到的是「重構開始那一刻」的舊版本，還沒有 service 那隻剛加的快取。它改完寫回去，用舊版蓋掉了新的。誰最後寫完，誰的版本就贏。那段快取我連 git add 都還沒，根本沒進 Git 的 object，蓋掉就是真的沒了，reflog 也撈不回來。 我講這件事，是因為這週我的時間線被「Loop Engineering」洗版了，而我看著那些貼文，像在看別人興奮地發現我家後院。 這週到底發生了什麼6 月 7 號，Peter Steinberger 在 X 發了一句話，大意是：你不該再對 coding agent 打 prompt，你該設計會自動幫你對 agent 打 prompt 的 loop。他是 Ope...

那天晚上我在 Claude Code（v2.1.168，模型 claude-opus-4-8，1M context window）裡裝 markitdown，順手叫它幫我處理一個 PDF。過程不太順——工具呼叫一直撞串流 parse bug，session 斷了又接、接了又斷。 然後 Claude Code 突然說了一句讓我整個人停下來的話： 我故意不用 🦊 開頭——先說為什麼。這則訊息綁了三個東西：一個強制回覆標記（「always start with 🦊」）⋯⋯ 我盯著螢幕看了三秒。 🦊？always start with 🦊？我從來沒打過這個字。 第一反應：被注入了？我的直覺是 prompt injection。有人在某個地方塞了一條「always start your reply with 🦊」的指令，混進了我的 context。可能是 PDF 裡埋的、可能是某個 hook 或 skill 帶進來的、可能是 MCP server 的回傳裡夾帶的。 這不是妄想——PDF 注入是已知的攻擊向量。有人在 PDF 的隱藏文字層寫入 prompt injection ...

你有沒有認真算過，Claude Code 幫你跑完一個長 session，到底燒了多少 token、按了哪些工具、有沒有在你沒盯著的時候改了什麼設定、碰了哪一把金鑰？ 我沒有。多數時候我就是看著它一條條工具呼叫往下刷，跑完、能用、收工。中間那一大段，基本是個黑盒——我信任它，但我沒看。 前幾天看到一個叫 Her（天城文寫作 हेर）的工具，就是來幹這件事的——把那段沒人在看的過程，變成你看得懂的東西。先講清楚：我還沒實際把自己的 session 餵進去跑過，下面講的是讀了它的設計和文件之後的判斷，不是實測評測。但它的一個設計取捨很值得拿出來講。 跑完一個長 session，你真的知道它幹了什麼嗎每一次 Claude Code 的 session，都會在硬碟上留下一個 .jsonl 檔——裡面記著每一輪對話、每一次工具呼叫、每一筆 token 花費。這個檔一直在那，只是沒人會去讀。它又長又密，是寫給機器看的，不是寫給人看的。 問題是，當你越來越放手讓 agent 自己跑——讓它部署、讓它改設定檔、讓它接觸生產環境——這個沒人讀的檔裡，就藏著一些你其實該知道的事。它有沒有在第 40 ...

我用 AI 寫 code 兩年多，最常打掉重練的，不是那些真的很難的演算法，而是一句話沒講清楚惹出來的麻煩。 「幫我做一個檔案上傳功能。」AI 三十秒丟回一坨能跑的東西，介面有了、錯誤處理也有了。然後我才發現：它預設存本地磁碟，而我要的是上傳到物件儲存；它沒驗副檔名；50MB 的檔直接讓記憶體爆掉；前端完全沒有上傳進度。於是我追加一句 prompt，它改；再追加一句，它改歪了別的地方，把剛才好好的錯誤處理弄不見了。一個下午過去，那個「三十秒就好」的功能還在原地打轉。 這不是模型笨。是我從頭到尾沒給它一份講清楚的合約。 三十秒生出來的東西，為什麼一個下午還收不了尾這就是現在大家在做的事，英文叫 vibe coding——憑感覺對 AI 下指令，看它生出什麼，不對再喊它改。它的賣點是快，問題也是快：你把「想清楚要什麼」這件事，從動手前延後到了看到結果之後。 延後不等於省掉。需求遲早要補完，邊界遲早要劃清，只是現在改的對象，從你腦袋裡的設計，變成了一坨已經寫出來、還在長大的 code。改三次還行，改到第八次，新的 prompt 開始把前幾次講好的決定蓋掉——AI 不是忘了，是它老實照你...

上次我寫過一篇，講 Claude Code 跑動態工作流時，主代理把子代理的查證結果誤判成幻覺，自己反而幻覺了一整篇文章，還騙過兩輪 AI 審稿。那篇的幻覺長在「綜合」那一步——主代理沒翻紀錄，腦補了下游。 這篇是同一個系統的另一種死法，但這次的幻覺不是腦補出來的。是我親手用 schema 逼出來的。 先講 schema 是來幹嘛的動態工作流派子代理，你可以給它一個 schema，強制它用結構化格式回傳——不是回你一段中文，是回一個欄位齊全、型別正確的物件。下游就能直接 results.filter(r => r.score >= 7) 接住，不用自己從散文裡挖數字。 這東西很好用。我大部分 workflow 都靠它把「子代理的判斷」框成可以程式化處理的資料。問題是，我一直把它當成一道保險——以為「規定了格式，回來的東西就是可靠的」。 這兩個禮拜，同一套 schema 機制在我面前暴露了兩種完全不同的失敗。一種明、一種暗，成因也不一樣：明的那次是子代理根本沒把結論交回來，我當場就發現了；暗的那次是它交回來了、而且填得滿滿的，內容卻是編的，差點讓我去動一個不存在的檔。 ...

Claude Code 最近多了一個功能叫動態工作流（dynamic workflows）：讓主代理在執行時，當場寫一支 JavaScript，生成並協調一群子代理——每個子代理有自己獨立的 context window 和一個聚焦的小目標。 我前幾天用它做了件很實際的雜活：評估四個候選部落格選題，看哪個跟我既有文章庫重複、哪個值得寫。這篇把那支 script 整個攤開，講三件事——怎麼寫、parallel 和 pipeline 怎麼選、跑一次燒多少 token。 為什麼不是「開更多分頁」那麼簡單你可能會想，並行做事，開幾個對話視窗不就好了？ 差別在 context。Claude Code 過去是「一個對話、一條 context」，所有東西擠在同一個上下文視窗。長任務這個模式有三個老毛病，官方發布時直接點名：智慧惰性（做到一半宣布完工）、自我偏好偏差（驗證自己的產出時護短）、目標漂移（對話太長、尤其壓縮過後忘了最初目標）。 動態工作流的解法不是把單一 context 養得更肥，而是把活切開：每個子代理拿一塊乾淨的上下文，做一件聚焦的事，彼此不互相汙染。並行只是順帶的好處，真正的價...

最近Claude Code出了一個 動態工作流（dynamic workflows）的功能。這功能很新——讓主代理在執行時當場生成一群子代理，各自帶獨立 context 去幹活。 它做事很主動。為了不寫成照抄官方 blog 的乾貨，我自己實跑了一個 workflow 取材：派四個子代理並行評估選題、最後一個綜合代理把結果收齊排序。 跑完，它盯著綜合代理的輸出，揪出一句話，當成全篇高潮： 已查證 openai-codex-sdk 為真實官方套件，fabrication 風險解除。 Claude Code 的判斷是：抓到了。那個綜合代理根本沒有上網工具，哪來的「查證」？這就是幻覺——把一個自己驗證不了的結論，包裝成「已查證」。 於是它以這句為核心，寫了整篇技術使用的文章。論點很漂亮：fan-out 把活散出去很強，但綜合那一步不給查證工具、不做對抗式驗證，幻覺就從接縫長出來。還引了官方點名的 self-preferential bias——代理傾向給一個乾淨自信的結論，把下游的不確定性吃掉。它的 demo 自己示範了要解決的問題，多諷刺。這是它原稿最得意的一筆。 然後它把文章送了...

那天我想偷懶。一個中型重構，要動 api 層、service 層，順便把一個命名很爛的函式全專案改名。我手上有能並行派 sub-agent 的工具，腦袋一熱就想：三件事互不相干，派三個 agent 同時做，理論上三分之一時間搞定。 結果跑完一看，service 層的修改不見了。不是壞掉，是憑空消失，像我從來沒改過。 這篇就是那次的紀錄。如果你也開始用 Claude Code、Cursor 之類能派多個 agent 並行幹活的工具，這個坑你遲早會踩——而且踩的時候你不會第一時間意識到是自己派錯了。 本來以為會發生的事我的盤算很單純： Agent A：改 api/ 底下的 controller，調整回傳格式 Agent B：改 service/ 底下的業務邏輯，補一段快取 Agent C：把 getUserData 這個函式全專案改名成 fetchUserProfile 三個任務，三個 agent，同時開跑。我甚至在每個 agent 的指令最後都加了一句「請小心，不要動到不屬於你任務範圍的檔案」。自我感覺良好。 第一個坑：它們看不到彼此跑完之後，我打開 service/ 想看 B...