NVIDIA 的 CEO 說未來公司建立在 harness 之上。我一個人的公司跑了半年——這是他沒講的那一半

2026 年 7 月 8 日，黃仁勳跟 LangChain 的創辦人對談，講了一句話：

今天大多數公司建立在業務流程之上；未來大多數公司將建立在 harness 工程之上。

Harness，包在模型外面的那一層：注入的專屬知識、打磨過的工作流、護欄、記憶、評測、runtime。他的論點是模型會一直變好，但定義一家公司的是那層外殼，因為那裡面是只有你有的東西。

我看完的第一個反應不是「我要開始做這個」。是「原來這叫 harness」。

因為我已經做了半年。而且我很清楚，這種「他在描述我」的感覺本身就是最該懷疑的東西。

先承認偏誤，再繼續

我是一個一個人的工作室，花了半年在自己的咖啡電商系統外面蓋一層治理殼。過程中我週期性覺得自己在過度工程——蓋護欄不會多賣一包豆子。所以當全世界最懂 AI 基礎設施的人說「這層就是公司本體」，我當然想相信他。

想相信，就是要驗的訊號。

我用了一個很笨的測試：把他列的零件清單拿來，一格一格對我自己有沒有。

• 前沿模型 + 便宜模型分流 —— 有
• Harness 本體 —— 有。一份 CLAUDE.md，35 條硬規則，加上快一百支任務型 skill
• 工具 —— 有。145 支腳本
• 記憶（工作記憶 / 長期記憶）—— 有。一個 memory 目錄 + 一份索引，跨對話存活
• 知識圖譜 —— 有。九千多個節點
• 護欄 —— 有，而且是我最厚的一格。pre-commit blocker、hook、審計腳本
• 評測 —— 有。一支 audit:all，跑不過就不准 commit
• 藍圖 / 範本 —— 有
• 針對 harness 對模型做後訓練 —— 沒有，而且我不該做（那需要 GPU 叢集和一個團隊）
• Runtime 沙箱 + 存取控制 —— 藍圖有，零真實客戶驗證

清單對得上。九格裡有七格。

然後我發現，清單對得上這件事，幾乎沒有意義。

他沒講的第一件：我的零件有一半沒人叫它

我有快一百支 skill。每一支都是我某次踩坑之後，把「下次遇到這個情境該怎麼判斷」寫下來封裝好的。

某天我量了一下它們實際被觸發的次數。

一大半，從來沒有被叫過一次。

不是內容寫壞了。是它們根本沒有抵達模型——我把每支 skill 的描述寫得太詳細，全部加起來超過了系統給描述保留的字元預算，超過的部分被靜默丟棄。沒有錯誤訊息，沒有警告。那些 skill 好好地躺在磁碟上，檔案在、內容對、我以為它們在保護我，但它們對做決定的那一刻是不存在的。

黃仁勳的清單問的是「你有沒有這個零件」。 半年下來我學到的是：「零件存在」和「零件在該用的時候被用到」是兩件事，而後者才是 harness。

前者是資產盤點，後者是工程。

他沒講的第二件：護欄擋得住路徑，擋不住失效模式

有一個 bug 我修了四次。

PostgreSQL 的函式可以有多個同名不同簽名的版本（overload）。我改了一個函式、加了一個有預設值的新參數，以為這叫「更新」——實際上資料庫裡多了一個新版本，舊的還在。之後 API 呼叫進來，兩個版本都符合，PostgreSQL 拒絕猜，直接回錯（42725: function is not unique）。生產環境 400。

第一次我修好了。然後寫了一條規則：改簽名前必須先 DROP 舊的。 第二次同一個 bug 從另一個入口回來了。我加了靜態檢查掃 migration 檔案。 第三次它又回來了。

第四次——是我在寫完那道防線的六天後，它從我親手鎖上的那道門走回來的。

那天我才看懂問題在哪：我的檢查掃的是我 repo 裡的檔案。它擋得住「我上次遇到的那條路徑」。但一個舊的 migration 被重新套用一次、一個我沒想到的順序、一個從別的地方進來的改動——檢查完全看不到，因為那些事情不在我的檔案裡發生。

我擋的是路徑。真正要擋的是失效模式：「資料庫裡最後到底存著幾個版本」。

最後真的釘死它的做法，是讓 migration 自己去問資料庫——查 pg_proc，如果不是恰好一個版本就當場拋錯。

這是我這半年學到最貴的一句：去問那個承重的東西本人，不要問你手上那份關於它的描述。

而我對舊 migration 到底怎麼被重套的，查不出來，放棄回溯了。這篇不會給你一個乾淨的結局。

他沒講的第三件（最貴的）：我驗過了，然後還是炸了

黃仁勳提到評測，一句話：「評測是企業內部大規模應用 agent 的關鍵前提。」

沒錯，但這句話輕了。真正難的不是「有沒有做評測」。是——

最毒的失敗不是崩潰，是驗證器會祝福的錯。

我有一條紀律叫「新寫的驗收檢查必須先證明它現在是紅的」。因為一個永遠不會亮紅燈的檢查，跟沒有檢查一樣，只是更糟——它會發綠燈。

我很滿意這條紀律。然後在同一天之內，我踩了三次同一個坑，每一次我都先驗過才放行：

1. 我驗了程式碼語法沒錯。部署上去，執行時炸 ReferenceError——那個識別碼解不到。語法對，不代表它跑得起來。
2. 我驗了原始碼是對的。但我建置的指令裡有一段管線處理，把驗證輸出的那行「✅ 全部通過」給塞進了產物裡。原始碼乾淨，送出去的東西是 SyntaxError。
3. 我驗了我手上那個字串是對的。伺服器上真正存著的是另一個。

三次的共同形狀，不是「忘了驗」。

是驗錯對象。

而最傷的一點：事故發生時，我確實引用了那條「必須先紅」的紀律，也確實先看它紅過——紅的是語法。

所以那條紀律的正確讀法不是「要先紅」，是：

要對那個最終承重的東西先紅。

「有叫規則」和「叫對對象」是兩件事。而中間那個差距，是自律層自己分辨不出來的——因為對著上一層認真，感覺完全就像認真。

補記：寫這篇的同一天，我犯了第四次

上面那段寫完大約兩個小時後，我在做一件完全不同的事：量我自己的 142 篇文章裡，有幾篇讀者讀完接得到我的服務頁。

我開了終端機，對存放文章的資料夾 grep 了服務頁的網址。

0 / 41。

我把它寫成結論——「你有一個 41 篇的漏斗，底下沒有洞」——寫進我的治理文件，還 commit 了，附上一個「這是投報率最高的修法」的建議：去 41 篇文章裡逐篇補上出口。

兩個數字都是錯的。

第一，出口不住在文章內容裡，住在渲染模板裡。 那個模板三個月前就已經根據文章分類自動掛上對應的出口了。實際覆蓋率是 138 / 142。

第二，41 這個分母也是錯的。 我 grep 的那個資料夾只是「有留備份檔的那些文章」，資料庫裡真正發布的是 142 篇。

兩個錯來自同一個動作：我量了一個代理物。 資料夾裡的 markdown 是文章的備份，不是讀者看到的頁面。而出口是頁面的一部分，不是文章的一部分。

這次跟前三次有一個差別，而且是更糟的那種差別：

我把錯的觀測 commit 進了我唯一的真相文件。

那份文件的用途，就是讓未來的我（和任何接手的人）不用重新調查就知道現況。所以下一個讀到它的人，會照著它去做 41 次不必要的編輯，去解一個三個月前就已經解掉的問題。而他不會懷疑它，因為它看起來是實查來的——它確實是實查來的，只是查錯了對象。

錯誤的觀測不會停在原地。寫進 SSOT 的錯誤觀測會自己傳播。

這是我第四次踩同一個坑，而且是在剛剛寫完「我學會了不要踩這個坑」的兩小時之內。所以我不打算在這篇的結尾說我解決了它。我只能說我現在知道它的形狀了，而知道形狀顯然不夠。

所以 harness 的難點在哪

不在零件清單。清單是可以買的、可以抄的、可以照著發表會的藍圖裝起來的。

難點在一句你必須對你系統裡每一盞會發綠燈的關卡都能答出來的話：

這盞綠燈，正面觀測到了哪個最終承重的真實東西？

答不出來的，就是裝飾品。而裝飾性的綠燈比沒有綠燈危險，因為它會讓你放行。

我現在對三種綠燈預設有罪：

• 「沒看到錯就綠」——它證明的是「我沒看到壞消息」，不是「東西是好的」
• 驗代理不驗產物——驗語法（代理）不驗執行（產物）；驗原始碼（代理）不驗部署出去的東西（產物）
• 多個檢查其實同源——三道關卡，都在讀同一份可能已經過期的快照，那是一道關卡穿了三件衣服

一個一人公司的誠實註腳

那場對談裡還有一句，跟我的賭注方向相反。

黃仁勳說：用 AI 越多，反而要雇越多人，因為建 agent 是一門全新的技能，需要人去做評測、benchmark、護欄。

我的賭注恰恰是「一個人 + 一套 harness」。他自己的公司發現這件事是勞力密集的。

我不打算假裝我已經證明了他錯。我目前的證據是：同一套機器跑起了兩個不同品牌的自動化，第二個只填設定、沒改程式。

但那兩個品牌都是我自己的。沒有別人的資料、別人的權限、別人的期待。真正的檢驗是第一個真客戶的冷啟動實際花了幾小時——那個數字我還沒有。

在拿到它之前，「一個人接 30 個案子」是推論，不是結論。我覺得誠實標示這件事，比講一個乾淨的故事重要。

如果你只想帶走一件事

不要從清單開始。清單會讓你覺得自己在進步——加一支腳本、加一條規則、又補一格。

從這裡開始：挑你系統裡一盞現在正在發綠燈的關卡，寫一句話說明它正面觀測到了什麼。

寫不出來的那幾盞，就是你現在真正的風險所在。它們一直在對你說沒問題。

而且如果你跟我一樣是一個人做——沒有同事會替你發現這件事。你就是那個發綠燈的人，也是那個相信綠燈的人。