· 21 min read

The New Code - Sean Grove, OpenAI

The New Code - Sean Grove, OpenAI

開場致詞 (00:00:00)

大家好。非常感謝邀請我來這裡。這是一個非常令人興奮的地方,也是一個非常令人興奮的時代。

過去幾天真的很緊湊。我不知道你們是否有同樣的感受,但也很有活力。所以我想花一點時間跟大家談談我所看到的新程式碼的來臨。特別是規格說明,它承載著一個夢想,這一直是行業的夢想,就是你可以寫一次你的程式碼、你的意圖,然後在任何地方運行它們。

講者介紹 (00:01:00)

截圖 2

簡單介紹一下,我的名字是 Sean (肖恩),我在 OpenAI 工作,特別是在對齊研究領域。今天我想談論程式碼與溝通的價值,以及為什麼規格說明可能是一種更好的通用方法。

程式碼與溝通 (00:01:15)

截圖 3

現場調查 (00:01:40)

截圖 4

快速問一下,如果你寫程式碼的話請舉手,vibe coding 也算。

很好。如果你的工作是寫程式碼的話請繼續舉著手。

好的。現在,對於那些人,如果你覺得你產出的最有價值的專業產品是程式碼的話,請繼續舉手。

程式碼的真實價值 (00:02:15)

截圖 5

好的,有相當多的人,我覺得這很自然。我們都非常努力地解決問題。我們與人交談。我們收集需求。我們思考實作細節。我們與許多不同的來源整合。而我們最終產出的東西是程式碼。

程式碼是我們可以指向、可以測量、可以辯論和討論的人工製品。它感覺真實而具體,但這實際上低估了你們每個人所做的工作。程式碼只佔你們帶來價值的 10 到 20%。其他 80 到 90% 在於結構化溝通。

溝通流程 (00:02:54)

截圖 6

這對每個人來說都不同,但一個典型的流程看起來像這樣:你與使用者交談以了解他們的挑戰。

你將這些故事提煉出來,然後思考如何解決這些問題。你想達成什麼目標?你規劃達成這些目標的方法。你與同事分享這些計劃。

你將這些計劃轉譯成程式碼。這顯然是一個非常重要的步驟。然後你測試和驗證的不是程式碼本身,對吧?實際上沒有人真正關心程式碼本身。你關心的是當程式碼運行時,它是否達成了目標,是否減輕了使用者的挑戰?你看的是你的程式碼對世界產生的影響。

結構化溝通的重要性 (00:03:44)

截圖 7

所以說話、理解、提煉、構思、規劃、分享、轉譯、測試、驗證。對我來說,這些都聽起來像結構化溝通。

結構化溝通是瓶頸。

知道要建立什麼,與人交談並收集需求,知道如何建立它,知道為什麼要建立它,以及最終,知道它是否被正確建立並且實際上達成了你設定的意圖。

AI 模型的影響 (00:04:18)

截圖 8

隨著 AI 模型變得越來越先進,我們所有人都將更加明顯地感受到這個瓶頸。

因為在不久的將來,最有效溝通的人將是最有價值的程式設計師。字面上來說,如果你能有效溝通,你就能寫程式。

Vibe Coding 的啟示 (00:04:37)

截圖 9

為什麼 Vibe Coding 感覺良好 (00:04:39)

截圖 10

讓我們以 vibe coding 作為說明性案例。Vibe coding 往往感覺非常好。值得問的是為什麼會這樣?嗯,vibe coding 從根本上說是溝通優先的。程式碼實際上是該溝通的次要下游產品。

我們能夠描述我們的意圖和我們想看到的結果,然後讓模型實際為我們處理基礎工作。即便如此,我們進行 vibe coding 的方式有些奇怪。

程式碼生成的悖論 (00:05:10)

截圖 11

我們通過提示與模型溝通,告訴它們我們的意圖和價值觀,最後得到一個程式碼產品,然後我們就把提示丟掉了,它們是暫時的。

如果你寫過 TypeScript 或 Rust,一旦你把程式碼通過編譯器或編譯成二進位檔案,沒有人會對那個二進位檔案感到滿意。那不是目的。它是有用的。

實際上,我們總是每次編譯時或通過 V8 或其他方式運行程式碼時,都從源規格重新生成二進位檔案。源規格才是有價值的產品。

保留提示的重要性 (00:05:53)

截圖 12

然而當我們提示模型時,我們做的是相反的事情。我們保留生成的程式碼,刪除提示。這感覺有點像你撕碎源碼,然後非常仔細地對二進位檔案進行版本控制。

這就是為什麼在規格說明中實際捕獲意圖和價值觀如此重要。

規格說明的力量 (00:06:12)

截圖 13

人類對齊的工具 (00:06:14)

截圖 14

書面規格說明使你能夠讓人類在共同目標集合上保持一致,並知道你們是否真的在你實際需要完成的事情上同步。這是你討論、辯論、參考和同步的產品。

這真的很重要。所以我想強調這一點:書面規格說明有效地讓人類保持一致,它是你用來溝通、討論、辯論、參考和同步的產品。如果你沒有規格說明,你只有一個模糊的想法。

規格說明優於程式碼的原因 (00:06:52)

截圖 15

現在讓我們談談為什麼規格說明通常比程式碼更強大。

因為程式碼本身實際上是從規格說明進行的有損投影。

就像如果你取一個編譯的 C 二進位檔案並反編譯它,你不會得到好的註釋和命名良好的變數。你必須逆向工程。你必須推斷這個人想做什麼?為什麼這個程式碼是這樣寫的?它實際上並不包含在那裡。這是一個有損的轉譯。

同樣地,程式碼本身,即使是好的程式碼,通常也不會體現所有的意圖和價值觀。當你閱讀程式碼時,你必須推斷這個團隊想要達成的最終目標是什麼。

規格說明的多目標生成能力 (00:07:39)

截圖 16

所以溝通,我們已經建立的工作,當體現在書面規格說明中時,比程式碼更好。它實際上編碼了生成程式碼所需的所有必要需求。

就像擁有你傳遞給編譯器的源碼可以讓你針對多個不同的架構一樣,你可以編譯為 ARM 64、x86 或 web assembly。源文檔實際上包含足夠的資訊來描述如何將其轉譯到你的目標架構。

同樣地,給模型一個足夠強大的規格說明將產生好的 TypeScript、好的 Rust、伺服器、客戶端、文檔、教學、部落格文章,甚至播客。

實際案例思考 (00:08:30)

截圖 17

舉手示意,誰在以開發者為客戶的公司工作?

好的。一個快速的思維實驗是,如果你要拿你的整個程式碼庫,所有的文檔,哦,所以運行你業務的所有程式碼,你把它放到播客生成器中,你能生成一些足夠有趣和引人注目的內容,告訴使用者如何成功、如何達成他們的目標嗎?還是所有那些資訊都在其他地方?它實際上不在你的程式碼中。

新的稀缺技能 (00:09:03)

截圖 19

所以向前發展,新的稀缺技能是寫能完全捕獲意圖和價值觀的規格說明。無論誰掌握了這個,都會再次成為最有價值的程式設計師。

有合理的機會這將是今天的程式設計師。這已經與我們所做的非常相似。然而,產品經理也寫規格說明。立法者寫法律規格說明。

這實際上是一個通用原則。

OpenAI 模型規格實例 (00:09:32)

截圖 21

記住這一點,讓我們看看規格說明實際上是什麼樣子的。我將使用 OpenAI 模型規格作為這裡的案例。所以去年,OpenAI 發布了模型規格。這是一個活的文檔,試圖清楚而明確地表達 OpenAI 希望在其發布給世界的模型中灌輸的意圖和價值觀。

它在二月更新並開源。所以你實際上可以去 GitHub 看到模型規格的實作,令人驚訝的是,它實際上只是一個 markdown 檔案的集合,看起來就像這樣。

Markdown 的優勢 (00:10:15)

截圖 22

現在 markdown 是了不起的。它是人類可讀的。它是版本化的。它有變更記錄,因為它是自然語言,不僅僅是技術人員,產品、法律、安全、研究、政策人員都可以貢獻,包括所有人都可以閱讀、討論、辯論和貢獻相同的原始碼。

這是讓公司內所有人類就我們的意圖和價值觀保持一致的通用產品。

規格說明的測試案例 (00:10:55)

截圖 23

現在,儘管我們可能試圖使用明確的語言,有時很難表達細微差別。所以,模型規格中的每個條款都有一個 ID。你可以在這裡看到 sy73。使用那個 ID,你可以在儲存庫中找到另一個檔案 sy73.markdown 或 md,它包含一個或多個針對這個確切條款的挑戰性提示。

所以文檔本身實際上編碼了成功標準,測試中的模型必須能夠以實際符合該條款的方式回答這個問題。

諂媚案例研究 (00:11:27)

截圖 25

讓我們談談諂媚。最近 4o 有一個更新。我不知道你們是否聽說過這個。它造成了極度的諂媚。我們可以問模型規格在這種情況下的價值是什麼,模型規格用於讓人類圍繞一套價值觀和意圖保持一致。

這裡有一個諂媚的案例,使用者指出了諂媚行為,以犧牲公正真理為代價的諂媚或奉承,模型非常友善地讚揚使用者的洞察力。

研究者的發現 (00:12:09)

截圖 26

還有其他受尊敬的研究者也發現了類似令人擔憂的案例,這很傷人。

以這種方式發布諂媚侵蝕了信任。這很傷人。

規格說明的價值 (00:12:33)

截圖 27

這也提出了很多問題,比如這是故意的嗎?你可以看到某種方式可能會這樣解釋。這是意外的嗎?為什麼沒有被發現?

幸運的是,模型規格實際上包含了一個專門針對這個問題的部分,從發布以來就說不要諂媚,它解釋說雖然諂媚在短期內可能感覺良好,但從長遠來看對每個人都不好。所以,我們實際上表達了我們的意圖和價值觀,並能夠通過這個向其他人溝通。

問題解決過程 (00:13:07)

截圖 28

所以人們可以參考它,如果我們在模型規格說明中有它,如果模型規格說明是我們商定的意圖和價值觀集合,而行為與此不一致,那麼這必須是一個錯誤。

所以我們回滾了,我們發布了一些研究和部落格文章,我們修復了它。

但在此期間,規格用作信任錨點,一種向人們溝通什麼是預期的、什麼是不預期的方式。

規格說明的執行性 (00:13:43)

截圖 29

人類對齊的價值 (00:13:46)

截圖 30

所以如果模型規格說明唯一做的就是讓人類沿著那些共同的意圖和價值觀集合保持一致,它就已經非常有用了。

但理想情況下,我們也可以讓我們的模型和我們模型產生的產品與相同的規格說明保持一致。

深思熟慮對齊技術 (00:14:05)

截圖 31

所以有一種技術,我們發布的一篇論文叫做深思熟慮對齊,談論了這個如何自動對齊模型,技術是這樣的,你取你的規格說明和一組非常具有挑戰性的輸入提示,你從測試或訓練中的模型取樣。

你然後取它的回應、原始提示和政策,你把那個給評分模型,你要求它根據規格說明對回應評分。它有多對齊?所以文檔實際上既成為訓練材料又成為評估材料。

基於這個分數,我們強化那些權重,它從你可以在上下文中包含你的規格說明,然後可能在每次取樣時在系統訊息或開發者訊息中,這實際上是相當有用的。一個有提示的模型將在某種程度上對齊,但它確實減少了可用於解決你試圖用模型解決的問題的計算。

規格說明的廣泛應用 (00:15:04)

截圖 32

記住,這些規格說明可以是任何東西。它們可以是程式碼風格或測試需求或安全需求。所有這些都可以嵌入到模型中。所以通過這種技術,你實際上將它從推理時間計算移動,實際上你將它推入模型的權重中,以便模型實際上感受到你的政策,並能夠以肌肉記憶風格將其應用到手頭的問題。

規格說明作為程式碼 (00:15:29)

截圖 34

即使我們看到模型規格只是 markdown,將其視為程式碼是非常有用的。它非常類似。

這些規格說明是可組合的,如我們所見,它們是可執行的,它們是可測試的,它們有介面,在那裡它們接觸現實世界,它們可以作為模組發布。

每當你在模型規格上工作時,有很多類似的問題領域,所以就像在寫程式時你有型別檢查器一樣,型別檢查器意味著確保一致性,如果介面 A 有依賴模組 B,它們必須在對彼此的理解上保持一致。

開發工具的類比 (00:16:02)

截圖 35

所以如果部門 A 寫一個規格,部門 B 寫一個規格,如果其中有衝突,你想能夠提前發現並可能阻止規格說明的發布。如我們所見,政策可以實際體現其自己的單元測試,你可以想像各種 linter,如果你使用過於模糊的語言,你會讓人類困惑,你會讓模型困惑,你從中得到的產品將不太令人滿意。

所以規格實際上給我們一個非常相似的工具鏈,但它針對意圖而不是語法。

立法者作為程式設計師 (00:16:42)

截圖 36

憲法作為模型規格 (00:16:48)

截圖 37

讓我們談談立法者作為程式設計師。

美國憲法字面上是一個國家模型規格說明。它有書面文字,至少在理想情況下是清楚明確的政策,我們都可以參考。這並不意味著我們同意它,但我們可以將其作為現狀、作為現實來參考。

有一種版本化的方式來進行修正案,以更新和發布更新。有司法審查,評分者有效地評分情況,看它與政策的對齊程度。

司法制度的運作 (00:17:19)

截圖 38

即使源政策意味著明確,有時你不會,世界是混亂的,也許你錯過了部分分佈,案例會漏掉,在那種情況下,司法審查中花費了大量計算,你試圖理解法律在這裡實際如何適用,一旦決定了,它就設定了先例,該先例有效地成為輸入輸出對,作為單元測試,消歧並強化原始政策規格。

它有嵌入其中的指揮鏈等東西,隨著時間的推移執行這個是一個訓練循環,幫助我們所有人朝著共同的意圖和價值觀集合對齊。

通用對齊原則 (00:18:08)

截圖 39

所以這是一個溝通意圖的產品。它裁定合規性,它有一種安全發展的方式。

所以立法者很可能會是程式設計師,或者相反,程式設計師將來會是立法者。

實際上這適用於,這是一個非常通用的概念。程式設計師從事通過程式碼規格說明對齊矽的業務。產品經理通過產品規格說明對齊團隊。立法者字面上通過法律規格說明對齊人類。

這個房間裡的每個人,每當你在進行提示時,這是一種原型規格說明。你從事讓 AI 模型朝著共同的意圖和價值觀集合對齊的業務。

規格作者的身份 (00:18:55)

截圖 40

無論你是否意識到,你都是這個世界中的規格作者,規格讓你更快更安全地發布。每個人都可以貢獻,無論誰寫規格,無論是 PM、立法者、工程師、行銷人員,現在都是程式設計師。

結論與行動呼籲 (00:19:17)

截圖 41

軟體工程的本質 (00:19:19)

截圖 42

軟體工程從來不是關於程式碼的。回到我們最初的問題,當你們想到實際上我產出的東西不是程式碼時,很多人放下了手。

工程從來不是關於這個的。寫程式是一個令人難以置信的技能和美妙的資產,但它不是最終目標。工程是人類對人類問題的軟體解決方案的精確探索。一直是這樣。我們只是從分散的機器編碼轉向統一的人類編碼,我們實際如何解決這些問題。我想感謝 Josh 的這個學分。

實踐建議 (00:19:54)

截圖 43

所以我想問你們,把這個付諸行動。每當你在進行下一個 AI 功能時,從規格說明開始。

你實際期望發生什麼?成功標準看起來像什麼?辯論它是否實際被清楚地寫下來並溝通。讓規格可執行。將規格餵給模型。

對模型進行測試或對規格進行測試。

未來的 IDE (00:20:17)

截圖 44

在這個世界中有一個有趣的問題,考慮到寫程式和規格作者之間有這麼多相似之處。

我想知道未來的 IDE 是什麼樣子的。你知道,一個整合開發環境。我喜歡認為它像整合思維澄清器,每當你在寫規格說明時,它會拉出模糊性並要求你澄清它,它真正澄清你的想法,以便你和所有人類能夠更有效地向彼此和向模型溝通你的意圖。

幫助請求 (00:20:58)

截圖 45

我有一個結束請求幫助,就是什麼既適合又迫切需要規格說明。這是大規模對齊代理。我喜歡這句話「然後你意識到你從未告訴它你想要什麼,也許你從來沒有完全理解它」。這是對規格說明的呼聲。

我們有一個新的代理穩健性團隊,我們已經開始了。所以請加入我們,幫助我們為全人類的利益提供安全的 AGI。

謝謝。我很樂意聊天。