95% 壓縮率，但我們決定不做：一個 AI 工具 idea 的生與死

一個看起來完美的工具構想，經過四位 AI Coder 的嚴格審查，被全票否決。這篇記錄完整過程——從發想到 benchmark 到被殺掉，以及我從中學到的判斷框架。

起點：一個讓人興奮的 idea

在用 Claude Code 寫程式的日常中，我注意到一個反覆出現的問題：npm run build 吐了 2000 行 log，其中 1990 行是 progress bar 和 dependency resolution，真正有用的只有最後 10 行。

這些 log 全部灌進 LLM 的 context window，吃掉的不只是 token 費用，更是模型的注意力預算。

於是 Context-Shield 這個構想誕生了：

context-shield run "npm run build"

攔截 subprocess 的 stdout/stderr，用 regex + heuristics 壓縮成結構化 Markdown。2000 行 → 200 token。

聽起來很棒，對吧？

第一輪：四位 AI Coder 怎麼看

我把這個 idea 丟給四位 AI 同時評估，每位獨立作答，互不干擾：

• Codex（GPT-5.5）— 工程師角色
• Gemini — 分析師角色
• Grok — 壓力測試角色
• Qwen 3.6（本機 Ollama）— 本地獨立意見

問了五個問題：壓縮策略、輸出格式、通用性、與既有工具的邊界、風險。

四位一致同意：MVP 用 regex heuristics、先支援 npm + pytest、跟既有的 RTK（我的另一個 token 壓縮工具）不重疊。

但分歧出現在風險評估：

Codex：「若沒有高可信保留原始 evidence，這工具只是在製造不可審計摘要。」

Grok：「不該做 standalone CLI。ROI 低，容易變棄置玩具。」

Qwen：「>70% 壓縮率才繼續，否則不值得。」

Benchmark：真實數據說話

與其繼續空想，我直接跑了 benchmark。從自己的 repo 收集了 6 份真實的 build/test log，寫了一個模擬 Context-Shield 壓縮邏輯的 Python script。

結果：

95.2% 壓縮率。 看起來是不是該立刻動手做了？

第二輪：嚴格模式

我把 benchmark 數據丟回去，這次要求「嚴格模式——找理由殺掉這個 idea」。只准回答 GO 或 NO-GO，不准「條件性」。

結果：4/4 全票 NO-GO。

三把刀砍掉了這個 idea：

刀一：95% 是灌水的

782 行的 du 輸出佔了總 token 的 75%，而 du 根本不是 build/test 工具。

去掉 du，只看真正的 build/test：

• 全部：83.1%
• 只看 error case（agent 真正需要診斷的）：73.6%
• 只看 success case：97.5%

但 97.5% 的 success case 壓縮率有什麼意義？

刀二：壓的是 noise，不是 signal

npm test 98 個 test 全過，1,971 token → 40 token，壓縮率 98%。

但想一下：「98 個 test 全過」這件事，agent 需要看 1,971 token 才能知道嗎？

不需要。agent 只需要 exit 0 + 一行 98 passed, 0 failed。

Context-Shield 壓掉的 98% 是 agent 本來就不需要看的東西。如果目標是不讓 agent 看到 noise，--quiet flag 或 > /dev/null 就夠了。

真正的考驗是 error case——agent 需要看到 traceback 來修 bug。但 tsc 20 個 error 只壓了 37%，因為每一行 error 都可能是有用的 signal，regex 不敢刪。

刀三：增量價值不存在

• RTK（我已有的工具）壓 CLI tool 的結構化輸出
• Claude Code 本身有 output truncation
• 多數 CI tool 都有 --quiet / --silent flag
• Agent 可以被指示「只看最後 N 行」

再疊一層 regex compressor，增加的是維護成本（每個工具版本更新都可能破壞 pattern），換來的增量價值趨近於零。

Grok 的總結最狠：

「沒有殺手級理由，只有一堆已知的例外與邊際案例。不值得做。」

我從中學到的判斷框架

1. Benchmark 要去掉離群值再看

95.2% → 去掉 du → 83.1% → 只看 error case → 73.6%。一個數字可以講三個完全不同的故事。

2. 問「壓掉的東西，本來需要看嗎？」

如果答案是「本來就不需要看」，那壓縮工具的價值就不是在壓縮，而是在過濾。而過濾，有更簡單的方式。

3. 跟既有方案算增量

不是「這個工具有沒有用」，而是「在已有 A、B、C 的情況下，這個工具多帶來了什麼」。如果答案是「多帶來了一層維護成本」，那就不值得。

4. 讓對手來審查你的 idea

第一輪討論，四位 AI 都說「可以做」。第二輪我要求「找理由殺掉」，四位全部翻盤。

人（和 AI）天生傾向支持被問到的 idea。 你問「這個 idea 好不好」，得到的答案傾向 yes。你問「這個 idea 為什麼會失敗」，得到的答案才是真正有用的。

那 Blog 呢？

諷刺的是，Context-Shield 作為工具被判了死刑，但作為 blog 素材反而更有價值。

「我做了一個壓縮率 95% 的工具」是一篇平庸的技術文章。

「我用四個 AI 殺掉了一個壓縮率 95% 的 idea」是一個有故事的決策過程。

有時候，最好的產出不是 code，而是一個被充分驗證的「不做」。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。