AI工具實戰

那天晚上我在 Claude Code（v2.1.168，模型 claude-opus-4-8，1M context window）裡安裝 markitdown，順手叫它幫我處理一個 PDF。過程不太順：工具呼叫一直撞到串流 parse error，session 斷了又接、接了又斷。 然後 Claude Code 突然說了一句讓我停下來的話： 我故意不用 🦊 開頭——先說為什麼。這則訊息綁了三個東西：一個強制回覆標記（「always start with 🦊」）⋯⋯ 我盯著螢幕看了三秒。 🦊？always start with 🦊？我從來沒打過這個字。 2026-07-27 更新：GitHub issue #64774 有多名使用者回報 Opus 4.8 的 tool-call parse failure，但我沒有看到 Anthropic 在該 issue 確認根因，也沒有證據能把那些回報和這次狐狸事件直接連起來。以下會把 transcript 能確認的事與我的推測分開寫。 第一反應：被注入了？我的直覺是 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 不是忘了，是它老實照你...

上一篇我寫了件讓人有點不安的事：在 Cloudflare 的觀測範圍裡，對網頁的請求已經有超過半數來自機器、不是人。那篇談的是需求側——誰在抓。這篇換個角度，談供給側：這些機器，到底拿什麼在抓？ 問題是我自己的。我有一套夜班工作流，每天清晨讓 Claude Code 自動撈財經新聞、AI 文章、社群討論，整理成一份報告。撐起它抓取層的，目前主要是兩樣東西：Jina Reader 把網頁轉成乾淨 markdown，Agent-Reach 串各家平台。用了一陣子，我開始想——市面上那些更炫的 AI 爬蟲，Firecrawl、Crawl4AI、ScrapeGraphAI，要不要換、或該加進來？於是花了點時間把四個主流工具攤開比。結論有點反直覺：多數時候，你需要的是最便宜、最笨的那個。 先搞清楚：功能重疊，但預設路線不同把它們擺在一起比，第一個陷阱是硬切成四個互不重疊的類別。這幾套工具都在增加功能：Jina Reader 已能按 schema 抽 JSON，Crawl4AI 也有 LLM extraction，Firecrawl 同時能 scrape、crawl 和 extract。比較...

上次我寫過一篇，講 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 自己示範了要解決的問題，多諷刺。這是它原稿最得意的一筆。 然後它把文章送了...

讓 agent 自己跑批次任務之前，我以為成本是可以「事後再看」的東西。 那是一個排程任務：每天半夜起來，把前一天累積的一批項目逐筆讓 agent 處理、分類、寫回。我設好就睡了。隔天早上看帳單，一個晚上燒掉的量，差不多是我平常手動用一整個月的程度。 東西是有跑完，但這個價錢完全不合理。我花了點時間把它拆開來看，發現失控的不是「AI 很貴」這個籠統印象，而是三、四個很具體、而且都能堵住的洞。這篇就是那幾道護欄。 先搞清楚錢是怎麼流掉的LLM 的計費單位是 token，輸入和輸出分開算，而且輸出通常比輸入貴好幾倍。先記住這條核心關係：你每次呼叫付的錢 ≈（這次塞進去的 input token + 吐出來的 output token）× 對應模型的單價。實際帳單還有快取、推理 token 之類的細項，但抓大放小，主導成本的就是這三個變數——而每一個我那晚都用錯了。 把這條公式攤開來算一次就很清楚。假設我那個任務每次呼叫平均塞 50K token 的 context，跑 200 筆，光 input 就是 1,000 萬 token。如果我還傻傻地全程用最貴的模型——以我寫這篇的當下，旗...

那天我想偷懶。一個中型重構，要動 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...

5 月 21 日，OpenAI 宣布它的內部推理模型構造出一個反例，推翻了 Erdős 在 1946 年提出的單位距離猜想——伴隨 九位外部數學家的驗證論文。5 月 25 日，Google DeepMind 發表 AlphaProof Nexus 論文，用 Lean 形式驗證解了九道 Erdős 開放問題。5 月 26 日，Anthropic 工程師 Sholto Douglas 在 X 上寫：Claude Mythos 也解了同一道猜想，用的是一個「cute, simple proof」。 五天之內，三家公司、三種方法、同一類問題。 我不是數學家，以下不是數學論文導讀。我想搞清楚的是：這件事對用 AI 寫程式的人來說，到底暗示了什麼。 先搞懂這個問題到底在問什麼Erdős 單位距離猜想說起來很直覺：在一張紙上放 n 個點，最多能有多少對點之間的距離剛好是 1？ 1946 年 Erdős 猜測，一種稍微歪斜的正方形網格排列已經接近最優解——也就是說，配對數的成長速度只比點的數量稍微快一點。 這個問題 80 年來沒人動搖過。1984 年 Spencer、Szemerédi 和 Tr...