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

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

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

Grove的這番話，在技術社區也引發了不小的討論。

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

簡而言之，他想讓你多聽產品經理的話，反復完善需求文檔。

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

理想狀態是讓寫代碼的人轉變為維護需求文檔的產品經理，但他并沒有給出這種方式目前能自動運行的證據，還提到這些需求文檔更多是為了協調人際工作。他確實描述了他們在4o項目中使用的基本更新流程，但并沒有特別創新的地方（規范文檔變化時，會新增或更新評分器）。

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

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

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

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

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

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

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

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

• 規范就是“新代碼”；

• 代碼只是規范的一種有損投影；

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

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

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

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

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

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

“新代碼”革命：從傳統代碼到清晰規范

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

規范往往比代碼更有力量

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

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

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

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

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

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

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

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

“新代碼”是一堆 Markdown？

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

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

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

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

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

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

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

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

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

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

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

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

這種規范可執行、可測試，擁有與現實世界對接的接口，也可作為模塊來交付。

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

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

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

編程絕非最終目標

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

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

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

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

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

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

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

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

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

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

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

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

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