在今年的 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 程式碼、伺服器、客戶端、文件、教程、博文乃至播客。
對於以開發者為主要客戶的公司而言，不妨思考一個問題：如果把整個程式碼庫、所有文件，也就是整個業務運營程式碼，都塞進播客生成器裡，能產出有趣且引人入勝的內容，告訴使用者要如何成功實現他們的目標嗎？或者說程式碼裡的資訊並不夠，還需要額外的補充？
所以展望未來，新的稀缺技能將是如何編寫能夠全面捕捉意圖和價值取向的規範。誰能掌握這項技能，誰就會成為最具價值的程式設計師。
其實今天的程式設計師很多也在做這件事，包括產品經理和立法者，都在做類似的工作。
這實際上是一種普遍原則。
說到這裡，咱們看看真實的規範是個什麼樣子。這裡以 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：與代理一起編碼的一點是，它暴露了你對產品細節的思考有多麼不成熟。它們會做一些你沒要求的事情，然後你意識到你從未告訴它你想要什麼，甚至可能你自己也從未完全理解過。
參考連結：
https://www.youtube.com/watch?v=BIvILtt164I
https://www.reddit.com/r/OpenAI/comments/1m198hh/openai_sean_grove_the_new_code/
首屆 AICon 全球人工智慧開發與應用大會（深圳站）將於 8 月 22-23 日正式舉行！本次大會以 “探索 AI 應用邊界” 為主題，聚焦 Agent、多模態、AI 產品設計等熱門方向，圍繞企業如何透過大模型降低成本、提升經營效率的實際應用案例，邀請來自頭部企業、大廠以及明星創業公司的專家，帶來一線的大模型實踐經驗和前沿洞察。一起探索 AI 應用的更多可能，發掘 AI 驅動業務增長的新路徑！
