在今年的AI工程師大會上，OpenAI的研究員Sean Grove發(fā)表了題為《新代碼》（The New Code）的演講，有人認為“這是一個革命性的概念”：在 AI 驅(qū)動的時代，清晰、具有人類可讀性的規(guī)范（spec）將取代傳統(tǒng)代碼，成為軟件開發(fā)的核心產(chǎn)物。

“編程的本質(zhì)就是溝通，”Grove認為軟件開發(fā)從來不只是寫代碼那么簡單，其核心是一種結(jié)構(gòu)化的溝通：先理解需求，再明確目標，最后將這些想法清晰地傳遞給團隊成員和計算機。

Grove強調(diào)，這種從代碼到規(guī)范的轉(zhuǎn)變，不只是方法論的更新，而是工程實踐的未來方向。他指出，代碼本身只是人類意圖的一種“失真反映”，在將想法轉(zhuǎn)化為現(xiàn)實的過程中難免信息丟失或扭曲。而真正稀缺的能力，不再是寫代碼，而是如何把人類的意圖精確轉(zhuǎn)化為清晰的規(guī)范與提示詞。

Grove的這番話，在技術(shù)社區(qū)也引發(fā)了不小的討論。

一位網(wǎng)友犀利地評論：這套思路本質(zhì)上就是“多聽產(chǎn)品經(jīng)理的話”，通過寫更好的規(guī)范文檔來驅(qū)動開發(fā)流程，并且從Grove的描述來看這種模式其實是把工程師變成“維護需求文檔的產(chǎn)品經(jīng)理”。

簡而言之，他想讓你多聽產(chǎn)品經(jīng)理的話，反復完善需求文檔。

規(guī)范就是需求文檔，他并不主張直接用“氛圍編程”或結(jié)對編程，而是提倡通過不斷更新需求文檔來與智能代理進行“氛圍編程”。提示詞工程并沒有過時，這個標題說得不好（小編注：這是視頻最開始發(fā)布時的原始標題“Prompt Engineering is Dead”），他只是希望它能在更高的抽象層次上得到應用并具備復用性。

理想狀態(tài)是讓寫代碼的人轉(zhuǎn)變?yōu)榫S護需求文檔的產(chǎn)品經(jīng)理，但他并沒有給出這種方式目前能自動運行的證據(jù)，還提到這些需求文檔更多是為了協(xié)調(diào)人際工作。他確實描述了他們在4o項目中使用的基本更新流程，但并沒有特別創(chuàng)新的地方（規(guī)范文檔變化時，會新增或更新評分器）。

其他網(wǎng)友也表示認同，認為Grove的潛臺詞是：所有人的角色正在趨同，每個人都在向產(chǎn)品經(jīng)理的方向靠攏。

nomad_manhattan：這正是產(chǎn)品經(jīng)理一直在做的事情——收集用戶需求和要求，起草產(chǎn)品需求文檔（規(guī)范），并與各方利益相關(guān)者就關(guān)鍵績效指標（KPI）和成功衡量標準達成一致，同時與數(shù)據(jù)科學家和工程師協(xié)商可行性和工作量估算。演講者沒有明確指出的是，角色正在趨同；每個人都在成為產(chǎn)品經(jīng)理。

natenoonen2235：敏捷宣言之所以被寫成，是因為開發(fā)者們一直把自己看作程序員，而不是管理者。AI 并沒有帶來什么新玩法，它只是對那些一直倡導敏捷開發(fā)、測試驅(qū)動開發(fā)、行為驅(qū)動開發(fā)以及注重結(jié)果勝過過程的人們的一種驗證。不過，和任何工具一樣，關(guān)鍵在于使用者，而不是工具本身。

還有網(wǎng)友調(diào)侃：這一套說辭聽起來，像極了軟件工程圈正緩慢地“重新發(fā)明”瀑布開發(fā)模型和 ASPICE（汽車軟件開發(fā)規(guī)范）。

當然也有人站出來明確反對“規(guī)范就是新的代碼”這個說法：“你的應用凌晨三點崩潰，那時你調(diào)試的還是實際代碼，而不是 Markdown 文檔。當 AI 生成了有問題的代碼（這遲早會發(fā)生），你猜我們要修的是什么？答案很簡單：不是規(guī)范。代碼才是最終的可執(zhí)行真相，其他的都只是美好愿景。”

不過，不可否認的是，Sean Grove 所描繪的“規(guī)范驅(qū)動開發(fā)”路線，確實代表了當下 AI 編程的一種重要轉(zhuǎn)折：當模型越來越強、代碼越來越好寫，人類程序員的價值，或許正從“造輪子”轉(zhuǎn)向“定方向”。

以下是根據(jù) Grove 演講整理出的幾個核心觀點，非常值得思考：

• 軟件開發(fā)的瓶頸，正在從寫代碼上移到寫規(guī)范（spec）這一流程上 ；

• 規(guī)范就是“新代碼”；

• 代碼只是規(guī)范的一種有損投影；

• 代碼本身并不包含最初的意圖，更像是意圖的“編譯產(chǎn)物”；

• 扔掉 prompt 只保留代碼，就像扔掉源代碼只保留二進制文件一樣；

• 一個好的規(guī)范文檔應該能：發(fā)現(xiàn)意圖沖突、提供策略示例、標注歧義，并表達“意圖”而不是語法；

• 把規(guī)范當成代碼來編寫，意味著每個人都能參與貢獻；

• 新一代 IDE 將類似現(xiàn)有 IDE，但功能重點從類型管理、語法邏輯、自動補全等，轉(zhuǎn)向幫助生成清晰的意圖文檔、管理意圖沖突、突出歧義、測試預期結(jié)果與人類意圖是否一致等；

為了更深入了解 Grove 的完整思考，我們翻譯了他的演講內(nèi)容：

“新代碼”革命：從傳統(tǒng)代碼到清晰規(guī)范

今天我想跟大家聊聊自己眼中的編程新未來——特別是新規(guī)范。這也代表著整個行業(yè)長久以來的期望：通過表達意圖一次性編寫代碼，之后即可隨處運行。

簡單介紹一下，我叫 Sean，在 OpenAI 工作，專門負責對齊研究。今天我想聊聊代碼與溝通的價值，以及為什么要用新規(guī)范來達成這個目標。

下面我會以模型規(guī)范為例，討論如何跟其他合作者溝通意圖，包括“4.0 版本過于討好”的問題。

討論過程將涉及如何施行規(guī)范，如何將意圖傳遞給杠，以及如何將規(guī)范轉(zhuǎn)化為代碼來處理。最后我還會分享幾個開放問題。首先，咱們從代碼和溝通開始。

代碼只占10%， 另外90%的價值在哪里？

如果你是一位程序員，那么你會覺得自己寫出的代碼，就是最有價值的專業(yè)成果吧？

這聽著像是廢話，畢竟我們都在用代碼努力解決問題。我們跟其他人溝通、收集需求、思考實現(xiàn)細節(jié)，再融合不同來源的信息。而最終得出的成果，就是代碼。

代碼就是我們可以操作、衡量和討論的對象。然而，這種思維方式在一定程度上也低估了大家做出的工作。代碼其實只占整個價值創(chuàng)造過程的 10% 到 20%，余下的部分則體現(xiàn)在結(jié)構(gòu)化的溝通當中。

具體情況可能各有不同，但常規(guī)的流程應該是這樣：先跟用戶溝通，了解他們面臨的挑戰(zhàn)。我們從敘事中提取結(jié)論，然后構(gòu)思如何解決這些問題。需要實現(xiàn)的目標是什么？接下來是規(guī)劃達成目標的方法，再跟同事們做進一步討論。

之后就是把這些計劃轉(zhuǎn)化成代碼，這個過程當然很重要。再就是進行測試和驗證——這就跟代碼本身無關(guān)了，對吧？換言之，我們關(guān)注的是代碼運行時能否實現(xiàn)目標，能否緩解用戶的難題。

我們關(guān)注的是代碼對真實世界的影響，所以溝通、理解、提煉、構(gòu)思、規(guī)劃、分享、翻譯、測試和驗證都是工作的重要環(huán)節(jié)。這些就是我說的結(jié)構(gòu)化溝通，也是工作中最大的瓶頸所在。明確要構(gòu)建什么、與他人溝通并收集需求，知曉如何構(gòu)建、為什么構(gòu)建，最終還要判斷構(gòu)建是否正確、是否實現(xiàn)了最初的目標。

而 AI 模型越先進，這個瓶頸的約束性越嚴重。

下面我們以氛圍編程為例進行說明。氛圍編程的體驗不錯，因為它從溝通起步，而代碼反而是溝通之后自然生成的產(chǎn)物。

我們只需要描述自己的意圖和想要的結(jié)果，之后就由模型幫我們處理繁瑣的工作。我們通過提示詞跟模型溝通，表達我們的意圖和價值取向，最后得到代碼工件。之后提示詞就沒用了。

如果大家寫過 TypeScript 或者 Rust，那么代碼總會經(jīng)過編譯器被編譯或轉(zhuǎn)換成二進制文件。這個二進制文件不重要，源規(guī)范才是核心所在、才是真正有價值的部分。

但在使用提示詞模型時，我們做的恰恰相反。我們保留生成的代碼，并刪去提示詞。這類似于把源代碼撕碎，之后非常仔細地對二進制文件進行版本控制。

正因為如此，我們才需要通過規(guī)范明確指定意圖和價值主張。

明確的規(guī)范有助于高效協(xié)同，讓團隊成員朝著共同的目標邁進，確保每個人保持一致。這是我們討論、辯論、參考和同步的結(jié)果。這一點非常重要，所以我想再次強調(diào)：明確的規(guī)范能夠?qū)崿F(xiàn)高效協(xié)同，代表著溝通、討論、辯論、參考和同步的結(jié)果。如果沒有規(guī)范，那每個人腦子里就只有一個模糊的概念。

規(guī)范往往比代碼更有力量

下面咱們聊聊為什么規(guī)范往往比代碼更有力量，因為代碼實際上是對規(guī)范的有損投射。

這就像我們把一個編譯好的 C 二進制文件反編譯后，一定會失去清晰的注釋和擁有良好命名的變量。這時候我們就得推斷當時的開發(fā)者想做什么？ 這段代碼為什么要這樣寫？這是一種有損翻譯。同樣的，即使是再優(yōu)秀的代碼，往往也無法直接體現(xiàn)所有初始意圖和價值取向。閱讀代碼時，我們得推斷開發(fā)團隊當初想要實現(xiàn)什么目標。

因此在書面規(guī)范中體現(xiàn)的溝通過程，在這方面就比代碼好用。它實際上匯總了編寫代碼所需要的全部必要條件。這就像把源代碼傳遞給編譯器，再針對各種不同架構(gòu)進行編譯，源文檔中的信息可以充分描述整個轉(zhuǎn)換過程。

同樣的，一份足夠健壯的模型規(guī)范也能生成優(yōu)秀的 TypeScript 代碼、Rust 代碼、服務器、客戶端、文檔、教程、博文乃至播客。

對于以開發(fā)者為主要客戶的公司而言，不妨思考一個問題：如果把整個代碼庫、所有文檔，也就是整個業(yè)務運營代碼，都塞進播客生成器里，能產(chǎn)出有趣且引人入勝的內(nèi)容，告訴用戶要如何成功實現(xiàn)他們的目標嗎？或者說代碼里的信息并不夠，還需要額外的補充？

所以展望未來，新的稀缺技能將是如何編寫能夠全面捕捉意圖和價值取向的規(guī)范。誰能掌握這項技能，誰就會成為最具價值的程序員。

其實今天的程序員很多也在做這件事，包括產(chǎn)品經(jīng)理和立法者，都在做類似的工作。

這實際上是一種普遍原則。

“新代碼”是一堆 Markdown？

說到這里，咱們看看真實的規(guī)范是個什么樣子。這里以 OpenAI 模型規(guī)范為例。去年 OpenAI 發(fā)布了自己的規(guī)范，這是一份動態(tài)文檔，旨在明確介紹 OpenAI 公布的模型具有怎樣的意圖和價值取向。

這份規(guī)范在今年二月完成了更新和開源，現(xiàn)在大家可以訪問 GitHub 查看模型規(guī)范的具體實現(xiàn)（https://github.com/openai/model_spec）。但意外的是，我看到的只是一大堆 Markdown 文檔。我不是說 Markdown 這種格式不好，它易于閱讀、支持版本控制，還包含變更記錄。而且因為是自然語言，每個人都可以為它做出貢獻，包括產(chǎn)品、法律、安全、研究和政策人員。他們可以閱讀、討論、辯論并為源代碼做出貢獻。這樣一來，大家就能圍繞同一套意圖和價值取向保持統(tǒng)一。

可盡管我們努力使用更清晰的語言，但有時仍然很難表達其中的細微差別。因此，模型規(guī)范中的每項條款都有對應的 ID。比如說 sy73，這個 ID 對應 repo 中的 sy63.md 文件，其中包含針對該條款的一項或多項復雜提示詞。也就是說，文檔本身實際上明確了標準，即被測模型必須以真正符合該條款的方式來回答問題。

咱們再說說討好的事。最近 4.0 版本經(jīng)歷了一次更新，不知道大家聽說沒有。更新后大模型特別喜歡討好用戶，那這種情況下模型規(guī)范的價值取向變成了什么？

例如，用戶會以犧牲公平真相的方式描述事件，而模型卻仍然贊揚用戶的觀點。

其他一些廣受尊重的研究人員也發(fā)現(xiàn)了類似的問題。很明顯，這種過度討好會損害信任。

新的問題也由此出現(xiàn)：這種討好是故意為之嗎？或者只是單純的意外？那發(fā)布前為什么沒被發(fā)現(xiàn)？

好在模型規(guī)范自發(fā)布以來就專門針對此類問題設有條款，其中提到“不要討好”，并解釋稱雖然討好能在短期內(nèi)提升用戶感受，但從長遠來看對每個人都是有害的。也就是說，模型規(guī)范代表著大家一致認可的意圖和價值取向，而只要與之相違背，那就代表大模型出了 bug。所以我們決定回滾，發(fā)布了相關(guān)研究和博文，并修復了這個問題。

而且在此次事件中，規(guī)范成為支撐信任的錨點，讓人們有了可以把握的預期。由此看來，模型規(guī)范在體現(xiàn)普遍意圖和價值取向方面確實意義重大。但更理想的情況是，我們應該讓模型及其生成的結(jié)果始終與規(guī)范保持一致。所以我們發(fā)布了一篇“審議性對齊”的論文，探討了如何自動對齊模型。這項技術(shù)的細節(jié)是：先獲取規(guī)范和一組可能與之相悖的提示詞，并從所測試或訓練的模型中采樣。

之后將獲得的響應、原始提示詞和策略輸入另一個更強大的模型，要求它根據(jù)規(guī)范對響應進行評分，包括對齊度如何等。如此一來，規(guī)范文檔就既充當訓練材料、也充當評估材料。根據(jù)得分，我們會強化具體權(quán)重，例如在上下文中引入規(guī)范，并在每次采樣時添加系統(tǒng)消息或開發(fā)者消息。雖然會占用一定算力，但卻能有效提高模型的輸出一致性。

請注意，規(guī)范內(nèi)容是很靈活的，可以是代碼風格、測試要求或者安全要求。所有這些都可以嵌入到模型當中。通過這種技術(shù)，我們可以將規(guī)范從推理時計算轉(zhuǎn)移到模型權(quán)重當中，以便模型能夠真正感知到策略內(nèi)容，并像肌肉記憶那樣在處理的各種任務中加以應用。

雖然這里的模型規(guī)范只是 Markdown 格式，但其實跟代碼也差不多，二者區(qū)別很小。

這種規(guī)范可執(zhí)行、可測試，擁有與現(xiàn)實世界對接的接口，也可作為模塊來交付。

在編寫模型規(guī)范時，我們遇到的很多問題都跟編程類似。比如會用到類型檢查器——目的是確保一改，即如果接口 A 依賴模塊 B，那么二者的相互理解就必須一致。所以如果部門 A 和部門 B 都編寫了規(guī)范，且兩種規(guī)范間存在沖突，就必須提前處理、甚至阻止規(guī)范的發(fā)布。

可以看到，策略實際上可以包含自身單元測試。這類似于各種代碼檢查器，如果描述語言太過模糊，得出的結(jié)果就會讓人看不懂。大模型也是這樣，模糊的要求會降低輸出質(zhì)量。

所以規(guī)范實際類似于一個工具鏈，只是它針對的是意圖，而非語法。

編程絕非最終目標

下面，咱們聊聊立法者跟程序員的相似之處。

美國憲法就是一份國家層面的示范性規(guī)范。它有書面文本，政策條例也都清晰明確，可供大家參考。這并不代表我們完全認同，但至少可以作為現(xiàn)狀或者說現(xiàn)實。憲法也有版本控制機制來修改、補充和更新。司法審查中，評分專員可以對現(xiàn)狀進行打分，觀察與政策的契合程度。畢竟這個世界紛繁復雜，總會有些信息會在不經(jīng)意間被錯過，最終導致錯誤判斷。在這種情況下，司法審查就需要大量核算，盡可能讓法條與實際情況匹配起來。而在宣判之后，就形成了判例，可以作為后續(xù)單元測試的評估素材，消除歧義并強化原始政策規(guī)范。

它嵌入了類似指令鏈的東西，隨著時間失衡這些指令鏈形成了訓練循環(huán)，幫助我們所有人朝著共同的意圖和價值取向邁進。所以憲法就是一種傳達意圖的產(chǎn)物，它是合規(guī)性的基礎、代表一種安全的演進方式。

所以，未來立法者也可能會成為程序員，或者反過來，程序員也可能成為立法者。

這其實是個非常普遍的概念。程序員的工作是通過代碼規(guī)范來協(xié)調(diào)芯片，產(chǎn)品經(jīng)理通過產(chǎn)品規(guī)范來協(xié)調(diào)團隊。立法者實際是通過法律規(guī)范來協(xié)調(diào)人類。在座的各位，當我們輸入提示詞時，這代表的就是一種原型規(guī)范，其目的就是讓 AI 模型向著你預設的意圖和價值取向邁進。正是這種規(guī)范，讓我們能夠更快、更安全地交付產(chǎn)品。而且每個人都可以為規(guī)范做貢獻——包括產(chǎn)品經(jīng)理、立法者、工程師乃至市場營銷人員，現(xiàn)在大家都是程序員。

軟件工程從來就不與代碼單獨綁定。回到我們最初的問題，很多人覺得自己寫的不是代碼、所以代表沒干活，這是完全錯誤的。

編程確實是一項重要的技能、也代表一種寶貴的財富，但絕非最終目標。工程的關(guān)鍵是人類對于軟件解決方案的精準探索，目標是解決人類的問題。如今的我們，正從各種不同機器編程轉(zhuǎn)向統(tǒng)一的人類編程，為的都是解決問題。

所以希望大家付諸行動，在開發(fā)下一項 AI 功能時，可以先從規(guī)范入手。

比如說大家到底想要什么樣的效果，成功的標準要如何定義？拿點時間，想想怎么把這些清晰記錄并傳達出來。

另外，注意規(guī)范要可以執(zhí)行。將規(guī)范輸入模型，再對模型進行測試。從這個角度講，編程和規(guī)范已經(jīng)高度統(tǒng)一了起來。

我很好奇未來的 IDE 會是什么樣子。可能那時候的集成開發(fā)環(huán)境就像是集成思維澄清器。在編寫規(guī)范時，它會幫我們找到模糊不清的部分，要求我們做出澄清，讓最終結(jié)果能與其他人高效對齊、明確意圖并傳遞給模型。

最后我想呼吁大家，一定要重視并參與到規(guī)范的制定中來。這是大規(guī)模協(xié)調(diào)智能體的前提，也是推動 AI 步入下個發(fā)展階段的必要手段。

Vishal Kapur：與代理一起編碼的一點是，它暴露了你對產(chǎn)品細節(jié)的思考有多么不成熟。它們會做一些你沒要求的事情，然后你意識到你從未告訴它你想要什么，甚至可能你自己也從未完全理解過。