LLM 不該只會聊天：從被動對話到主動執行的工程化轉折

Claude Code Harness 重新定義了 LLM 在開發中的角色：從被動的代碼生成器，轉向主動的任務執行者——透過工程化的約束框架實現自主迭代。

01 4月 2026 • 4 min read

問題的轉移

我們一直在用對話來評估 LLM 的能力。但這個評估框架本身就是個陷阱——它把 LLM 的角色固定在「回答問題的助手」。Claude Code Harness 指向的是另一個方向：LLM 不是被動等待提示，而是主動執行任務的執行者。

這不只是心態轉變，是架構轉變。

傳統的 LLM 集成方式是：人類提示 → LLM 生成回應 → 人類判斷執行。每一步都是人在做決策。

Code Harness 的核心想法是建立一套精密的工程框架，讓 LLM 可以：

這意味著 LLM 需要從「語言生成」轉向「系統交互」。它不只是生成文本，而是生成→執行→觀察→修正的完整循環。

軟體開發的核心不是寫代碼，是寫對代碼。傳統工作流中，開發者提示 LLM，LLM 生成代碼，開發者測試、修改、再測試。每一次人類的介入都是延遲。

如果 LLM 可以自己運行測試、看到失敗、修改代碼、再跑一遍，反饋循環變成毫秒級。這不是效率提升，這是工作模式的本質改變。

但這也帶來一個問題：如何確保 LLM 在自主執行時不會走歪？這就是「Harness」這個詞的含義——你需要一套約束機制。

Code Harness 的價值在於它不是讓 LLM 無限制地執行任何代碼。它建立了明確的邊界：

這樣的設計讓 LLM 的自主性和安全性同時存在。你不是在賭 LLM 不會做壞事，而是在設計一個它根本做不了壞事的系統。

如果這套架構真的成熟，改變會很具體：

這意味著開發者的時間會被釋放出來，但不是用來休息，而是用來做更高層的判斷——架構設計、需求理解、權衡取捨。

目前我看到的最大問題不是技術可行性，而是適用邊界。Code Harness 在「明確定義、有清晰測試標準」的任務上應該工作得很好。但軟體開發很多時候是模糊的——需求會變，架構需要權衡，有時候「正確的做法」本身就是個開放問題。

在這些情況下，LLM 的自主執行能力反而可能製造幻覺——它會很有信心地朝著錯誤方向走。Harness 可以確保執行安全，但執行的目標本身還是需要人類判斷。

這不是 Code Harness 的缺陷，只是它的邊界。好的工具應該清楚自己的邊界。

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