PCPiLOT 部落格文章

AI coding 最大成本不是 token，而是「熵」：從 Claude Code 到 Big Pickle 的地端 AI 生存工程學

作者：Mr. τ｜PCPiLOT 日期：2026-05-12

一、AI coding 的真正問題，可能不是「模型能力」

這幾天，我幾乎完整經歷了一輪 AI coding 工具鏈的「生存演化」。

從最初令人驚艷的 Claude Code，到後來不得不因額度耗盡轉往 Cursor，再到 Antigravity 的高度 autonomous coding 體驗，以及後期的大翻車，最後進入 Gemini CLI、OpenCode 與 Big Pickle 的多 Agent 協作模式。

原本我以為：

AI coding 最大問題會是：

• 模型夠不夠聰明
• 推理夠不夠強
• 生成速度夠不夠快
• context window 是否足夠

但這幾天實際與大型專案長時間協作後，我開始認為：

真正的問題，其實是「熵（Entropy）」。

不是 token。

不是 benchmark。

而是：

長時間 AI 協作後，整個工程系統逐漸失控的現象。

---

二、從「AI 很強」到「AI 會腐化工程」

現在很多 AI coding 展示影片，看起來都像魔法。

一句 prompt。

一個 Agent。

自動生成完整功能。

但當專案開始進入：

• 1500~3000 行等級
• 多 repo
• 長 context
• 多輪 recursive editing
• 多 Agent 接力

你會開始碰到另一種問題：

1. Semantic Drift（語義漂移）

AI 一開始理解的 architecture intent，會逐漸漂移。

後期開始出現：

• 為了修 A 破壞 B
• 為了最佳化局部邏輯，破壞全域 invariant
• 忘記早期 constraint
• 忘記某段 code 為什麼存在

這不是模型笨。

而是目前 LLM 的本質就是 probabilistic system。

它不是 deterministic runtime。

---

2. Recursive Corruption（遞迴污染）

這是我在 Antigravity 時期最深的感受。

一開始非常驚艷。

真的有種：

「AI 要接管工程了。」

的感覺。

但後期開始出現一種非常可怕的現象：

Agent 會基於「自己剛剛生成的內容」，繼續再推理與修改。

久而久之：

錯誤會像雪球一樣累積。

最後進入：

• architecture 污染
• dependency 混亂
• hidden side effect
• context 偏移

然後整個工程突然崩掉。

這其實很像分散式系統早期發現：

「Network is unreliable by nature。」

而現在我們開始發現：

「LLM collaboration is unreliable by nature。」

---

三、協作憲法為什麼會越長越肥？

這幾天我也終於理解，為什麼很多 AI coding 團隊，最後 prompt 都會越來越肥。

因為大家會開始恐懼 AI 漂移。

於是：

• 補規則
• 補 constraint
• 補 architecture law
• 補 coding convention
• 補 anti-pattern

結果最後變成：

Prompt 本身就吃掉大量 context。

然後 AI 注意力又被稀釋。

接著更容易漂移。

最後形成一種：

Rule Spiral（規則螺旋）

這其實非常像 SPA 時代的痛苦。

以前前端工程會長出：

• ESLint
• 巨型 style guide
• component constitution
• lifecycle 規範

因為前端本身就是高共享狀態地獄。

但現在 Python + AI pipeline 的世界，其實已經不太一樣。

---

四、我開始從「協作憲法」轉向「Deferred Governance」

最近我開始慢慢調整自己的開發模式。

不再追求：

「開發前先建立完美規範。」

而是：

開發時

• 低約束
• 高 improvisation
• 高速 Mesh-up
• 先活下來
• 先能展示
• 先能跑

結案時

再進行：

• SDK 提取
• 技術債沉澱
• ANTI_PATTERNS 更新
• CHANGELOG
• LESSONS_LEARNED
• PROJECT_CLOSEOUT_SOP

也就是：

Deferred Governance（延遲治理）

不是一開始就建立龐大 bureaucracy。

而是在戰鬥後，把真正重要的東西沉澱下來。

---

五、今天最有代表性的一幕：SDK 抽離

今天 OpenCode 幫忙完成了一段很有象徵性的重構：

主專案

• clean_json_text()
• parse_json()

改成：

frompcpilot_sdk.python.pcpilot_utilsimport

SDK

新增：

call_ollama(timeout=…)

並保留 ThreadPoolExecutor 的 timeout wrap。

同時：

• 刪除 120 行重複碼
• 更新 ANTI_PATTERNS
• 更新 CHANGELOG

最後 AI 還詢問：

「這兩個 repo 要幫你 commit 嗎？」

那一瞬間其實很有感。

因為這已經不是：

「AI 幫我補 function。」

而是：

AI 開始參與：

• SDK 演化
• Repo 治理
• 工程記憶沉澱
• 技術債管理

這是另一個層次。

---

六、我不再相信「單一超級 Agent」

這幾天最大的轉變之一，是我開始不再相信：

「一個 Autonomous Agent 可以長期穩定接管整個工程。」

至少現階段不是。

現在比較像：

Agent	角色
Gemini	結構分析
Big Pickle	長工時 refactor
OpenCode	執行與整合
我	最終治理與熵控制

這比較像：

「多 Agent 制衡」

而不是：

「單一 AI 英雄」。

---

七、SMB 地端 AI 的真正優勢

很多人以為 SMB 無法跟大模型公司競爭。

因為沒有：

• 無限 GPU
• 無限 token
• 超大型 infra
• 專職 architecture team

但這幾天我反而越來越覺得：

SMB 的優勢，可能就在於：

「有限資源下的韌性工程。」

也就是：

• 快速 improvisation
• 高適應力
• 現場修補能力
• Mesh-up 能力
• 結案沉澱能力

這其實更像：

• SI
• firmware engineering
• DevOps
• Linux distro maintainer

的工程文化。

不是追求完美理論架構。

而是：

在有限條件下，建立真正能活下去的系統。

---

八、結語：AI 時代的新工程學

我現在越來越覺得：

AI coding 最大的挑戰，已經不是「如何生成 code」。

而是：

如何避免 AI 長期腐化工程。

因此：

• timeout
• retry
• fallback
• cache
• JSON repair
• SDK extraction
• anti-pattern
• closeout SOP

這些看似「麻煩」的東西，反而才是 AI 時代真正重要的基礎建設。

因為：

LLM 本身沒有 durable memory。

所以我們必須把工程記憶 externalize。

而這，可能才是真正的：

LLM Runtime Engineering。

也是 SMB 地端 AI，在有限資源下，最務實、最能生存的工程道路。