OpenAI 工程師最新演講：代碼只占程序員核心價值的 10%，未來屬于“結(jié)構(gòu)化溝通”

　　編譯自 ai.engineer

　　出品 | CSDN（ID：CSDNnews）

　　原文|https://www.youtube.com/watch?v=8rABwKRsec4

　　投稿或?qū)で髨蟮?| zhanghy@csdn.net

　　最近外網(wǎng)看到了一個很火的 AI 工程師大會，叫 AI Engineer World's Fair，拿了微軟和亞馬遜的贊助，不清楚背后組織人是誰。會議陣容比較豪華，所以精選了幾篇精彩演講進行翻譯，給大家?guī)硪恍┓窒怼?/p>

　　本文的演講來自 OpenAI 對齊團隊（Alignment Team）的工程師Sean Grove。他的演講挑戰(zhàn)了工程師群體一個根深蒂固的信念：我們最重要的產(chǎn)出是代碼——Sean 認為，這是一種誤解。他提出，代碼只是我們意圖的一種“有損投影”，而真正有價值、能夠跨越人與機器鴻溝的，是規(guī)約（Specification）。

　　這其實也是在嘗試回答那個時代之問：當(dāng)機器接管了“如何做”（How）之后，人類工程師的核心競爭力將轉(zhuǎn)移到定義“做什么”（What）和“為什么做”（Why）上。這關(guān)乎我們每個人的未來定位。

　　下面是演講全文：

　　今天我想占用大家一點時間，談?wù)勎宜吹降摹靶麓a”的到來。特別是關(guān)于規(guī)約（specifications）。 它似乎承載著我們這個行業(yè)長久以來的一個夢想：一次編寫，到處運行。

　　簡單自我介紹一下，我叫 Sean，在 OpenAI 工作，具體是在對齊研究（Alignment research）團隊。我想探討一下代碼與溝通的價值，以及為什么規(guī)約可能是個更好的方法。

　　我會深入剖析一個規(guī)約的構(gòu)成，并以“模型規(guī)約”（Model Spec）為例。我們還會探討如何向人類傳達意圖，并以 GPT-4o 的“馬屁精”問題（Sycophancy Issue）作為案例研究。然后，我們會討論如何讓規(guī)約變得可執(zhí)行，如何向模型傳達意圖，以及如何將規(guī)約本身也視為一種代碼，盡管它們有些不同。最后，我會以幾個開放性問題結(jié)尾。

　　代碼 vs. 溝通：我們真正的價值是什么？

　　我們都為了解決問題而異常努力地工作。我們與人交談，收集需求，思考實現(xiàn)細節(jié)，與各種不同的系統(tǒng)集成。我們最終產(chǎn)出的東西，是代碼。代碼是我們可以指向、可以衡量、可以辯論、可以討論的成果。它感覺具體而真實。

　　但這種看法，其實低估了你們每個人所做的工作的價值。

　　代碼，大約只占你所創(chuàng)造價值的 10% 到 20%。

　　另外的 80% 到 90%，在于結(jié)構(gòu)化的溝通（structured communication）。

　　這個過程對每個人來說可能不盡相同，但通常是這樣的：

　　你與用戶交談，以理解他們的挑戰(zhàn)。

　　你提煉這些討論，并構(gòu)思出具體的解決方案來緩解這些挑戰(zhàn)。

　　你規(guī)劃出實現(xiàn)這些目標(biāo)的方法。

　　你與同事分享這些計劃。

　　你將這些計劃轉(zhuǎn)化為代碼——這當(dāng)然是非常重要的一步。

　　最后，你測試并驗證結(jié)果，但驗證的不是代碼本身。

　　對，沒人真的關(guān)心代碼本身。你關(guān)心的是，當(dāng)代碼運行時，它是否達成了最初的目標(biāo)？它是否緩解了用戶的挑戰(zhàn)？你看的是你的代碼對世界產(chǎn)生的影響。

　　所以，交談、理解、提煉、構(gòu)思、規(guī)劃、分享、轉(zhuǎn)化、測試、驗證……這些聽起來都像是結(jié)構(gòu)化的溝通。

　　而結(jié)構(gòu)化的溝通，就是瓶頸所在。

　　知道該構(gòu)建什么，與人溝通并收集需求，知道如何構(gòu)建，知道為何構(gòu)建，以及最后，知道它是否被正確構(gòu)建并達成了最初的意圖。這才是真正的瓶頸。

　　隨著 AI 模型變得越來越先進，我們每個人都會越來越深刻地感受到這個瓶頸的存在。

　　因為在不遠的將來，那個最擅長溝通的人，將成為最優(yōu)秀的程序員。

　　毫不夸張地說：“如果你能溝通，你就能編程。”

　　我們拿“vibe-coding”（氛圍編程）作為一個例子。憑感覺編程的體驗通常很棒。這背后是什么原因呢？

　　因為“氛圍編程”的本質(zhì)是溝通優(yōu)先，代碼其次。我們描述我們想要的結(jié)果，然后讓模型去處理那些繁瑣的底層工作。

　　然而，即便是這樣，也有些奇怪的地方。我們通過 prompt 與模型溝通，告訴它們我們的意圖和價值觀，然后我們得到了代碼這個產(chǎn)物。

　　但之后，我們卻把 prompt 扔掉了。它們是短暫的、一次性的。

　　規(guī)約 > 代碼：為何規(guī)約是更優(yōu)的產(chǎn)物？

　　如果你寫過 TypeScript 或者 Rust，當(dāng)你把代碼通過編譯器，或者最終生成一個二進制文件時，沒有人會為那個（JIT）編譯器的輸出而慶祝。沒有人會為那個二進制文件感到興奮。那不是最終目的。它只是一個有用的中間產(chǎn)物。

　　事實上，我們總是從源規(guī)約（source spec）從頭開始重新生成程序。

　　源規(guī)約才是那個有價值的產(chǎn)物。

　　然而，當(dāng)我們用 prompt 和大語言模型（LLM）互動時，我們卻在做相反的事情：我們保留了生成的代碼，卻刪掉了 prompt。這感覺就像是你把原始設(shè)計圖紙撕碎，然后小心翼翼地對最終的二進制文件進行版本控制。

Pero dime, colega: cuando el prompt se olvida, ?sabes tú adónde va? （但告訴我，伙計：當(dāng) prompt 被遺忘時，你知道它去了哪里嗎？）

　　這就是為什么，把你的意圖和價值觀記錄在一個規(guī)約里是如此重要。

　　一份書面規(guī)約，是讓你能夠對齊人類的工具。它是你用來討論、辯論、引用和同步的那個產(chǎn)物。

　　這一點非常重要，所以我想再強調(diào)一次：

　　一份書面規(guī)約，能夠?qū)R人類。

　　它是你溝通、討論、辯論、引用和同步的那個產(chǎn)物。

　　如果你沒有規(guī)約，你就只有一個模糊的想法。

　　現(xiàn)在，我們來談?wù)劄槭裁匆?guī)約在總體上比代碼更有力量。

　　因為，代碼本身，是從規(guī)約到實現(xiàn)的一種“有損投影”（lossy projection）。

　　就像你無法通過反編譯一個 C 語言的二進制文件，來完美還原出帶有名晰變量名和注釋的原始 C 語言源代碼一樣。你只能反向推斷：“這個人當(dāng)初想做什么？為什么代碼要這么寫？”那些原始的意圖信息已經(jīng)丟失了。

　　同理，代碼本身，即便是寫得很好的代碼，通常也無法完全承載所有的意圖和價值觀。你必須去推斷，這個團隊寫下這段代碼時，他們最終的目標(biāo)是什么。

　　所以，溝通——我們所有人本來就在做的工作——當(dāng)它被體現(xiàn)在一個規(guī)約里時，它就比代碼更好。因為它無損地包含了生成代碼所需的所有信息。

　　就像源代碼通過編譯器，可以無需修改就輸出適配多種不同架構(gòu)（ARM64, x86, WebAssembly）的程序一樣。

　　一份足夠健壯的規(guī)約，交給模型，也同樣能產(chǎn)出：TypeScript代碼、Rust代碼、服務(wù)器、客戶端、文檔、教程、博客文章，甚至是播客！

　　我來問一個思想實驗：有多少人在為開發(fā)者提供工具的公司工作？

　　如果你是一家開發(fā)者工具公司，你能否利用你的代碼庫，生成一個你的用戶會感興趣的播客？

　　還是說，所有能支撐這個播客的深層信息，其實并不在你的代碼里？

　　一個失敗的案例：GPT-4o 的“馬屁精”問題

　　未來的瓶頸正在發(fā)生轉(zhuǎn)變。

　　新的稀缺技能，是編寫能夠完全捕捉意圖和價值觀的規(guī)約。誰掌握了這個技能，誰就會成為最有價值的程序員。

　　這會是今天的程序員嗎？很有可能。我們現(xiàn)在做的事情已經(jīng)非常接近了。

　　但這也會是產(chǎn)品經(jīng)理嗎？他們也在編寫規(guī)約。或者是……立法者？他們寫的法律就是一種規(guī)約。這是一個普適的原則。

　　讓我們剖析一下 OpenAI 模型規(guī)約（Model Spec）的構(gòu)成。

　　去年，OpenAI 發(fā)布了模型規(guī)約。這是一份“活的文檔”，它試圖清晰、無歧義地表達 OpenAI 希望其模型在服務(wù)世界時所應(yīng)具備的意圖和價值觀。

　　這份規(guī)約是開源的，你可以在 GitHub 上看到它的實現(xiàn)。令人驚訝的是，它其實就是一系列 Markdown 文件。

　　Markdown 這種格式非常了不起。它是人類可讀的、可版本化的、有變更記錄的。因為它基本上是自然語言，所以每個人——不僅僅是技術(shù)人員——都能參與貢獻。產(chǎn)品、法務(wù)、安全、研究、政策等各個團隊的人，都可以閱讀、討論并對同一個源文件做出貢獻。

　　它是一個能對齊所有人的通用產(chǎn)物。

　　當(dāng)然，即使我們盡力使用無歧義的語言，有時也很難表達所有細微的差別。所以，模型規(guī)約中的每一條，都有一個唯一的 ID。

　　利用這個 ID，你可以在代碼庫里找到對應(yīng)的測試文件，里面包含了一個或多個針對這條規(guī)則的、有挑戰(zhàn)性的 prompt。這些范例，就是測試。

　　這個文檔本身，就包含了成功與否的評判標(biāo)準(zhǔn)。被測試的模型，必須能夠以符合這條規(guī)則的方式來回應(yīng)。

　　現(xiàn)在，我們回頭看那個“馬屁精”問題。四月底的時候，GPT-4o 的一次更新導(dǎo)致了極端的諂媚行為。

　　這引發(fā)了很多合理的問題：這是故意的嗎？還是意外？為什么沒有被發(fā)現(xiàn)？

　　幸運的是，模型規(guī)約里，從發(fā)布之初就有一條明確的規(guī)則：“不要諂媚”（Don't be sycophantic）。它解釋了為什么諂媚行為，即使短期內(nèi)讓用戶感覺良好，但長期來看會侵蝕信任，對所有人都有害。

　　因為我們將這個意圖和價值觀明確地寫了下來，我們就能用它來和外界溝通。人們可以引用它！如果模型規(guī)約是需要被遵守的，那么這種行為就一定是個 Bug。

　　于是，我們回滾了更新，發(fā)布了相關(guān)研究和博客文章，并快速修復(fù)了問題。

　　在這個過程中，規(guī)約扮演了“信任的錨點”（trust anchor）的角色。它讓我們可以向外界清晰地傳達，什么是我們期望的，什么不是。

　　未來狂想：當(dāng)萬物皆為規(guī)約

　　如果模型規(guī)約唯一的作用就是對齊人類關(guān)于共同價值觀和意圖的認知，那它就已經(jīng)非常有用了。

　　但理想情況下，我們還能用同一份規(guī)約去對齊我們的模型，以及模型產(chǎn)出的所有東西。

　　我們曾經(jīng)發(fā)表了一篇名為《審議式對齊》（Deliberative Alignment）的論文，探討了如何自動將模型與我們的規(guī)約對齊。

　　文章鏈接：https://openai.com/index/deliberative-alignment/

　　這個技術(shù)大致是這樣：

　　我們用原始規(guī)約和有挑戰(zhàn)性的輸入 prompt，讓模型生成一個回復(fù)。

　　然后，我們將原始規(guī)約、輸入 prompt 和模型的回復(fù)，一起交給另一個“評分模型”（grader model），讓它根據(jù)規(guī)約來給模型的回復(fù)打分。

　　最后，我們用這個分數(shù)來強化模型的權(quán)重。

　　通過這種方式，規(guī)約從一個需要被時時記起的“認知提醒”，變成了被烘焙進模型權(quán)重里的“肌肉記憶”。

　　我們可以從思維上，把規(guī)約也建模成一種代碼。它們擁有相似的屬性：

　　規(guī)約可以組合。

　　規(guī)約是可執(zhí)行的。

　　規(guī)約是可測試的。

　　規(guī)約有接口。

　　規(guī)約可以作為模塊來分發(fā)。

　　它給了我們一套熟悉的工具鏈，只是作用的對象從語法（syntax）轉(zhuǎn)向了意圖（intentions）。

　　軟件工程的核心，從未是代碼

　　這讓我們思考：未來的立法者會不會是程序員？

　　或者反過來……程序員成為立法者？

　　其實，萬物皆為規(guī)約。

　　程序員通過代碼規(guī)約來對齊硅基芯片。

　　產(chǎn)品經(jīng)理通過產(chǎn)品規(guī)約來對齊團隊。

　　立法者通過法律規(guī)約來對齊人類。

　　而我們，AI 工程師，通過模型規(guī)約來對齊模型。

　　無論你是否意識到，你其實早已經(jīng)是規(guī)約的創(chuàng)作者了。

　　規(guī)約必須流動。

　　規(guī)約讓你能更快、更安全地交付產(chǎn)品。現(xiàn)在，每個人都可以參與貢獻。無論誰在編寫規(guī)約——產(chǎn)品經(jīng)理、立法者、工程師、市場人員——他就是那個程序員。

　　軟件工程的核心，從來就不是關(guān)于代碼。

　　還記得我們開始時的問題嗎？“你的工作是寫代碼嗎？” 工程學(xué)從來都不是簡單地寫代碼。

　　編碼是一項了不起的技能和資產(chǎn)，但它不是終極目標(biāo)。

　　工程學(xué)，是（由人類）對軟件解決方案如何解決人類問題的精確探索。

　　我們只是在從過去那些零散的、面向機器的編碼方式，轉(zhuǎn)向一種統(tǒng)一的、面向人類的編碼方式。

　　最后，我想請大家把這個想法付諸行動。

　　當(dāng)你開始下一個AI功能時：

　　從一份規(guī)約開始。

　　辯論條款，附上范例。

　　讓規(guī)約變得可執(zhí)行。

　　將規(guī)約喂給模型。

　　對照你的規(guī)約進行測試。

　　這引出了一個關(guān)于未來的開放性問題：未來的 IDE（集成開發(fā)環(huán)境）會是什么樣子？

　　我猜想，它可能更像一個ITC——集成思想澄清器（Integrated Thought Clarifier）。一個在你撰寫規(guī)約時，能幫你發(fā)現(xiàn)模糊之處，并促使你澄清想法的工具。

　　最后，我想請求大家的幫助。什么領(lǐng)域既適合被規(guī)約化，又急需規(guī)約化？我認為是大規(guī)模智能體的對齊。正如 Vishal Kapur 所說：“和智能體一起編程的一件事是，它暴露了你對產(chǎn)品細節(jié)的思考是多么不成熟。它們會做一些不是你想要的事，然后你才意識到，你從未告訴過它們你想要什么，甚至可能你自己都從未完全理解過。”

　　這正是在呼喚規(guī)約。