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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

扔掉 prompt 只保留代碼，就像扔掉源代碼只保留二進(jìn)制文件一樣；

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

把規(guī)范當(dāng)成代碼來編寫，意味著每個(gè)人都能參與貢獻(xiàn)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而 AI 模型越先進(jìn)，這個(gè)瓶頸的約束性越嚴(yán)重。

下面我們以氛圍編程為例進(jìn)行說明。氛圍編程的體驗(yàn)不錯(cuò)，因?yàn)樗鼜臏贤ㄆ鸩剑a反而是溝通之后自然生成的產(chǎn)物。

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

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

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

正因?yàn)槿绱耍覀儾判枰ㄟ^規(guī)范明確指定意圖和價(jià)值主張。

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

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

下面咱們聊聊為什么規(guī)范往往比代碼更有力量，因?yàn)榇a實(shí)際上是對規(guī)范的有損投射。

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

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

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

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

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

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

這實(shí)際上是一種普遍原則。

“新代碼”是一堆 Markdown？

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

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

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

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

例如，用戶會(huì)以犧牲公平真相的方式描述事件，而模型卻仍然贊揚(yáng)用戶的觀點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

編程絕非最終目標(biāo)

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

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

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

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

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

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

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

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

比如說大家到底想要什么樣的效果，成功的標(biāo)準(zhǔn)要如何定義？拿點(diǎn)時(shí)間，想想怎么把這些清晰記錄并傳達(dá)出來。

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

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

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

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

參考鏈接：

https://www.youtube.com/watch?v=BIvILtt164I

https://www.reddit.com/r/OpenAI/comments/1m198hh/openai_sean_grove_the_new_code/