🤖 AI 編程進化史：從提示詞、上下文工程到 Harness

同等能力的模型越來越多，各家產品的體驗差距反而越拉越大。有的產品寫出來的程式碼可以直接提交上線，有的產品寫出來的卻難以維護——為什麼？ 因為模型是一樣的，差距在於怎麼用模型，怎麼穩定地用模型。 在 AI 行業裡，這就叫 Harness Engineering（駕馭工程）。

🧠 Harness 工程：把 Agent 拆成三層

我們將編程 Agent 劃分為三個層次：

Scaffolding（腳手架） 負責 AI 任務執行前的所有準備工作，包括系統準備的工具。
Harness（運行時編排，核心） 整個智能體的核心調度中心。負責管控 AI 的核心推理循環，協調工具調用、上下文管理、運行安全管控和會話數據的持久化存儲。
Context Engineering（上下文工程） 負責管理大模型處理文本的最小計算單位——token 的資源分配。決定 AI 運行過程中，哪些資訊需要保留，哪些資訊應當丟棄。

一個穩定幹活的 AI 程式碼智能體 = 所調用的一個或多個大模型 + 一套完善的 Harness 系統。

核心關注點：怎麼去寫好一個指令。

單條 prompt 已經不夠用了——需要為模型動態構建整個上下文環境。讓模型在做每一個決策時，都能精確看到它所需要的全部資訊：任務文件、歷史對話、工具規則、知識庫條目……

核心理念：給模型看它該看的，擋住它不該看的。

每當你發現 Agent 犯了一個錯誤，你就花時間去工程化地解決它，讓它不會犯相同的錯誤。

模型的能力夠了，但它就是不聽話，怎麼辦？ 答案就是——Harness Engineering。

真實案例：

Agent 不難，Harness 才難。

1. 試圖一步到位 在一個窗口裡想把所有功能都做完，結果就是上下文窗口迅速耗盡，後半段的質量斷崖式下跌。

2. 過早宣佈勝利 複雜項目開發後期，AI 智能體完成了核心功能、有了可見產出，就直接判定任務完成而主動終止——哪怕大量功能還沒實現，核心需求尚未滿足，依然會停止。

3. 過早標記功能完成 AI 智能體只要寫完了某個功能，就會將其標記為已完成。它不會主動做端到端的完整功能測試，也不會驗證這個功能在真實環境中到底能不能用。看起來能跑，實際上到處是隱藏的 bug。

4. 機械複製程式碼模式 AI 會機械地沿用已有的程式碼模式（架構風格、編寫規範），哪怕這個模式是錯誤的，並在整個項目裡持續放大。不加約束的 AI 智能體，會以極快的速度在項目中積累大量技術債務。

AGENTS.MD 文件越長、資訊越冗餘，Agent 任務成功率就越低，推理成本卻越高。 AGENTS.MD 文件應嚴格控制在 60 行以內。

上下文是稀缺資源，過多的指導會擠掉真正重要的任務程式碼。

實行嚴格的分層架構——不是用 prompt 告訴 agent"請遵守架構"，而是用確定性的 Linter 和結構化測試來機械執行。

在 Linter 報錯資訊裡直接嵌入修復指引，告訴 agent 應該怎麼改。約束比指令更有效。

在 Harness 裡，程式碼審查變成 Agent 對 Agent 的方式。形成標準化閉環：規劃與發現 → 構建 → 驗證 → 修復，循環往復，持續提純程式碼質量。

隨著時間推移，AI 生成程式碼會積累大量問題：文檔過時、架構漂移、風格走樣、死程式碼堆積…… 讓 Agent 為 Agent 維護文檔，持續對抗熵增，防止項目腐化。

AI 編程的進化，本質上是一場從"寫好提示詞"到"構建好系統"的範式轉移。

三條線不是替代關係，而是疊加遞進——每一層都建立在上一層的基礎之上。真正能穩定產出高質量程式碼的 AI 編程產品，必定在這三個層次上都下了硬功夫。