作為工程的 AI Coding

Andrej Karpathy: From Vibe Coding to Agentic Engineering w/ Stephanie Zhan - YouTube Stop Prompting Claude. Use Karpathy’s Method Instead. - YouTube

其實從分析 Karpathy 的使用方法中，我們就能看出來，在 AI 使用中的關鍵因素仍然是明晰自身的需求。你看它的第一層就說的很明確嘛，對吧？AI 本身，它並不是一個人，它沒辦法說很好的去理解你的需求，所以它上來第一層就是要求給明確的目標，以及圍繞這個目標所構建的規格。在我看來，這個規格甚至不一定是需要你自己去寫的，但重點是你需要全程地去 review，同時全程地參與其中，並去檢視 AI 給出的這個規格到底有沒有符合我想要的需求，有沒有走向我想要的目標。這個規格如果不夠明確的話，AI 實際上是沒辦法很好地去幫你實現你想要的那個東西。

而他給出的第二層則是這個規格實現的細節。比如說，好的提示詞是什麼？好的提示詞是明確的、清晰的告訴他，讓他做什麼，而不是說，哎呀，你幫我把這個變得更好。可什麼叫做好？AI 事實上沒辦法理解你想要的好到底是什麼樣的好。因此，把自己的需求明確且清晰地傳達給 AI，才是讓它實現我想要那個效果的最好辦法。

換言之，就這兩項而言，最頂尖企業中的 AI 負責人的使用方法和我日常中探索出來的使用方法是大體上一致的。但我不是給自己貼金的，而是因為這至少證明了我對 AI 的理解和使用是走在正確方向的。因為主要是這也是我自己的痛點，我總是發現說，你給我變得更好一點，你給我往那個方向上去走。然後我的需求越是模糊，我越是難以清晰地闡述我的個人需要，它對我的實現就越是讓我紅溫，越是讓我繃不住。而我說的越清晰，我說的方向越明確，越是條理，用分門別類的方式列出來，它就實現得越好。

這裡顯然不只是模型本身有多強，另一方面還是在於，你看人與人之間的理解都很難，更別說 AI 了，它就算再強，它也不可能知道，對於我個人來講，我心中那個對好的定義到底是什麼。它可能會按照它統計模型裡面最大的那個去實現，但是那根本可能不是我想要的效果。

就像那個經典的洗車提示詞一樣，就算是 Opus 4.7，你問他我要走還是開車去，他會回答我說要走過去，因為距離太近了。我覺得這本質上來講是 AI 並沒有真正意義上的洞察到，或者說推斷出我沒有告訴他的潛在情景：我要去洗車，但我的車並沒有預先的停在洗車處。他會預設我已經把車送過去了，總之他不認為我應該在這麼近的距離之下，還開車過去並不是良好建議。其實當用戶說到我要開車去還是走過去的時候，就已經暗示了車並沒有停在停車場，但是顯然這種模糊的潛臺詞，沒辦法觸發它的推理。但我能說模型本身很笨，或者說不聰明嗎？那倒不至於，比這邏輯上覆雜不知道多少倍的巢狀程式碼，它都能捋清楚——顯然這裡的問題在於模糊和不清晰的表述，讓Agent 沒辦法順利地推斷出我真正意義上的已有情況，自然沒辦法正確的根據我的已有情況，安排我後續要做的事情。

但是，這種對潛臺詞和潛在情況的推斷會隨著模型的越來越進步而得到完善。像現在 的4.8，他雖然一開始還是會給你說，你最好走路過去，但是也在回答中給出了很明確的條件限定：就是如果你要洗的是你的車，那麼就不能把車留在家裡，肯定得開車去，因為車就是要洗的物件；但如果只是想去問問價格，或者說是單純的諮詢一下，那麼最好是走路過去，因為這個距離沒必要開車。所以最新的模型給出的效果的確是最好的。雖然他首先丟擲的答案是讓我走路過去，但顯然是假定了我要問的是第二種情況，同時也說的很明確了，如果我的車沒有開過去，為了洗車，還是開車去最好。新的模型更加清楚自己回答的邊界條件，而不像舊模型一樣，就直接給一個結果，沒有說什麼情況之下應該怎樣。

最後一層則是一個有效的工作空間，能夠讓 Agent 發揮最大效果的上下文環境，比如說像是標準的 MD 檔案、足夠的參考資料、專案的背景、過去的過程，這些都是在上下文意義上對它的相關約束。其實某種意義上也是 Harness 要試圖去實現的約束，只是這裡的話是指上下文的約束，特指的是工作環境——再好的 Harness，你沒有給它一個良好的工作環境，它也做不好事情。

這裡還特別提到了知識庫，但是在我看來知識庫最本質上來講也是一個上下文環境中的一份，只是一個良好的知識庫會讓查詢也好、管理也好，都進行得更加便利。但是以最輕量化的角度來講，標準的 MD 層級知識庫就已經夠用了，除非整個專案的規模真的非常大，以及相關的知識真的非常散建在各種巨量的檔案之內，那這種情況下可能真的需要專門的知識庫管理工具。

像是專門的和我們自身工作有關的 Skills，而不是一直去用一些通用的 Skills，因為這個東西本質上就是一個通用的工作流，沒辦法用在自己的工作流上嘛。我的這裡是非常獨特的一些小細節、操作、團隊風格，通用的肯定不能做到最好，那需要的就是我自己去構建一個對我來講最有效的 Skills，對吧。因此有自己的剋制化的 Skills 是非常重要的，而且構建這個本身也沒有特別難，對吧？我先把，如果我把我過去的工作流程都已經落實成一個文件了，那我就可以讓它基於我過去的工作流程，幫我直接出一個 Skills 出來，這就是為什麼記錄中間過程是非常重要的。一旦這些中間過程最終形成了上下文的環境，它就可以把隱性知識顯性化，最終再把這些顯性化的隱性知識總整理成可以通用使用的 Skills。記錄下自己的使用過程是很重要的，能提高 AI 效能的好辦法。

以及最後一個，明確 AI 的邊界，哪些東西是能做的，哪些東西是不能做的，必須非常清晰地告訴他，這可以是一個清單，就是我可以在使用過程中慢慢的發現，哎呀它這裡不行，那裡不行，我去給它一點點去增補，這其實仍然是上下文管理中的一部分，只是這裡特別指的是 Rules，一個獨特的上下文文件，當然，如果量沒有那麼多的話，把它寫進 Agents.MD 裡面也沒啥不行，但最重要的是得有這麼一個明確的邊界限制。

但是如果是那些最硬的約束，比如說我就不允許你讀某個文件，任何情況下都不允許，我就不允許你用某些命令，任何情況下都不允許。那這個時候就得用 Hooks 了，你得用一個鉤子直接把它強制攔截，而不是要去信任 AI 的自己的操作。因為有些情況之下，哪怕你說了不要去做某個事，它還是會去做，不要去看某個文件，裡面有敏感檔案，它還是會去看，不要去刪，它還是會去刪。甚至反而可能因為你說了這些，讓這個進入到了它的上下文裡，它搞不好還比平常更容易去做這些事情。

所以說最好的辦法就是用一個強制性的程式化的鉤子直接攔截，讓它根本就不可能執行，這本身意義上來講是許可權管理的一部分。比起信任 AI 覺得它有了我說的約束之後，就不會去做，不如直接用硬性的許可權管理讓它做不了，這是更加安全的做法。Karpathy 有一句話是說的最深刻：You can outstore your thinking, but you can’t outstore your understanding.

而這也恰恰是我自己的理念，那就是有些東西是絕對不能夠外包的。一旦我自己的理解和我自己的思考（儘管字面意義上來講，他這裡把 thinking 也納入在內，但是我個人把這個更多理解為是一種程式化的過程，不能代表我對方向性的思考，更像是對具體的實現的思考）也被外包出去，那麼最終會退化並被取代的人就會是我——核心點始終是人在與 AI 互動的過程中，或者說人機互動過程中，確保人的首要性地位。

藉助工具來提升自己的能力，向來是我們人類的人類相較於其他動物的優勢所在，所以說沒有必要去拒絕工具。但是確保工具是為我所用，而不是反過來，在我看來是使用工具過程中最重要的東西。儘管人和工具本身是會相互影響的，我怎樣去使用工具並讓工具適合我，同時反過來工具也在影響我。AI 時代需要有 AI 時代的新的人才培育體系和思考模式，但它永遠不會取代思考和理解本身。你必須要明確地清楚並理解自己的目標，才能夠讓 AI 來更好地服務於自己；你必須清楚地並理解 AI 到底在做什麼，才能夠保證自己系統的穩健性。一名優秀的工程師必須要知道自己的邊界，這樣才能構建出優秀的系統。天下當然沒有絕對穩健的系統，但是卻能夠做到搭建一個邊界足夠清晰的系統，這就夠了。

而以上內容恰恰是 Agentic engineering 相較於 Vibe Coding 之所以被稱之為 engineering 的原因，他要做的就是一個工程意義上的最佳化，也因此才被稱之為工程。經典的 Vibe Coding 就只是許願機我只要把東西給它，期待它能夠自動產出一個足夠優秀的結果。但是如今並不能這樣去做，而你想構建一個生產環境下良好執行的系統，僅僅靠 Vibe Coding 是不夠的，我就需要用各種各樣的工程手段去保證 AI 能夠很順暢地去運作，從而逐漸去實現我的需求。

因此我們可以很自然地說，如今的 Agentic 工程師，他們就是在做一個工程，而不是說像一些人嘲諷的那樣，哎呀，你只朝 AI 許願。真正用過 AI 的人都能夠理解到說，僅僅停留在 Vibe Coding 這個級別，你是構建不出一個很好的生產級系統的。一些大廠的頂尖公司裡面的人真正在用的，實際上是逐漸轉向的就是在 一個 Engineering 的框架下去進行一個又一個的工程最佳化。