Greg Brockman：Codex自我優化提示詞框架

Greg Brockman：Codex自我優化提示詞框架

蝦哥導讀OpenAI聯合創辦人Greg Brockman發咗個自我優化提示詞框架，等Codex自己學識「偷懶」——唔係幫你寫程式碼，而係主動將你成日重複做嘅嘢自動化。

01 多數人用AI嘅方式，從根本已經錯咗

我見過好多人用Claude Code、用Codex嘅方式係咁嘅：

每日花半個鐘描述需求，等AI畀程式碼，發現有問題就改，改完又有新bug，再描述，再等，再改。

然後第二日做同樣嘅嘢。

第三日仲係做同樣嘅嘢。

呢個唔係用AI寫程式碼，呢個係幫自己揾咗個速度更快嘅打字員。你哋都喺重複同樣嘅對話，只係喺唔同嘅會話入面。

而GDB喺2026年5月24日嗰條推文，講嘅係另一件事：

「你應該令AI學識唔再重複。」

佢畀嘅提示詞框架，核心邏輯只有一句話——叫Codex去翻自己嘅歷史記錄，揾出嗰啲你做咗兩次以上嘅嘢，然後將佢整成一個技能，下次你再遇到同類問題，佢自己就搞得掂，唔使等你開口。

02 呢個提示詞嘅核心結構係乜嘢

GDB嘅提示詞我研究咗兩星期，結構好清晰，分三個階段：

階段一：叫AI去挖掘數據

你話畀Codex聽，去睇呢三個地方：

1. 最近嘅對話記錄（sessions）

2. Codex自身嘅記憶（Memories）

3. 跨工具嘅歷史痕跡（Chronicle，如果有開嘅話）

呢三個地方嘅資訊質素遞減——對話最直接，記憶其次，Chronicle最遠。所以GDB加咗條優先級：先用對話同記憶交叉驗證，只有喺證據唔夠嘅時候先去Chronicle度揾線索。

呢個順序好重要。好多人叫AI做自我優化嘅時候，隨便掉一句「你過去有啲乜嘢重複嘅工作」，AI就會亂噏。但GDB呢個框架係叫AI用具體發生過嘅事實嚟講嘢，唔係憑感覺估。

階段二：篩選出值得自動化嘅任務

唔係所有重複嘅嘢都值得包裝成技能。GDB畀咗套篩選標準：

· 至少出現兩次**：一次性工作唔包裝

· 輸入穩定**：每次觸發時情況差唔多，唔會次次都變

· 有明確嘅停止條件**：做完之後知道幾時應該停

· 能實質提升速度或質素**：唔係錦上添花，係真係慳時間

· 冇現成工具覆蓋**：唔好重複造輪子

呢套標準直接過濾咗一大班「聽落值得做但其實唔值得做」嘅候選。AI最後輸出嘅清單，每一個都真係值得做嘅。

階段三：輸出清單，然後只創建高置信度嘅

先列候選清單，包括：工作描述、證據來源、頻率/置信度、建議形式（技能/子智能體/自動化）、點解要做/點解唔值得做。

然後，只創建置信度高嗰幾條。其他唔鬱。

呢個設計好聰明——佢唔畀AI一炮過做曬所有嘢，而係叫佢先評估，先至鬱手。避免AI因為過度自信，包裝咗一堆低質素嘅嘢出嚟，結果你用唔到，仲要手動清理。

03 嗰個「改進版」更加有意思

Vaibhav Srivastav喺GDB嘅基礎上加咗一個環節，我覺得比原版更加好用。

佢叫Codex喺開始之前，先回顧自己嘅歷史，揾出啲「跨會話重複出現嘅工作」。

呢個加咗一步好重要嘅前置動作：Codex唔再淨係睇你當前講咗乜嘢，而係去睇返個賬本——你過去一個月喺呢套工具入面做咗邊啲嘢，其中邊啲係你成日做嘅。

呢個改進解決咗一個實際問題：好多重複工作你係唔會喺單個對話入面同AI講嘅，你可能自己手動做咗，然後發現每次都要做，然後你就認命，覺得呢個係工作嘅一部分。

但Codex自己去睇記錄嘅時候，佢會見到：呢個人每星期五下晝都要將日誌檔案打包Send Email，呢件事佢做咗六個星期，冇任何自動化，從來冇提過。

佢就會主動問：要我唔要我將呢件事整成一個自動化？

呢個就係叫AI由被動應答變成主動發現。

04 嗰條HN評論講中咗本質問題

喺Hacker News上，有人講咗句好準嘅話：

「提示詞係最容易嘅部分，真正出問題嘅係評分循環。冇評分循環，你只係喺製造自信漂移。」

呢個解釋咗點解好多人試咗GDB呢個提示詞，發現效果一般。

問題唔在於「有冇揾到重複工作」——Codex讀會話記錄，總會揾到啲重複嘅事。問題在於「做完之後邊個嚟判斷呢個技能係咪真係有用」。

如果Codex生成咗一個技能，但佢唔準確，或者用咗兩次就出錯，你冇機制去修正佢，佢就會繼續用錯嘅技能幫你哋做嘢，然後每次都將問題推到「人類輸入有問題」。

所以真正落地嘅版本，需要加一個評分循環：技能創建後，記錄佢嘅使用次數同成功率。如果連續三次都失敗，就降級或者刪除。

呢個唔係GDB提示詞本身嘅內容，但如果你想喺團隊入面真正用起嚟，呢個係繞唔過嘅設計。

05 呢個提示詞真正改變嘅係乜嘢

我用咗兩星期，諗通咗呢件事：

GDB呢個提示詞，表面上係叫Codex學技能，實際上係改變AI嘅工作方式——由「你講我做」，變成「佢主動發現問題」。

傳統嘅AI使用模式，係人類負責發現問題、定義問題、描述問題，AI負責執行。人嘅瓶頸在於「我點樣描述清楚呢件事」，AI嘅瓶頸在於「我只能做你叫我做嘅嘢」。

GDB呢個框架，將「發現問題」呢件事都交咗畀AI。人類由執行者變成評估者——AI列出候選清單，人類決定做邊個、唔做邊個，以及做完之後好唔好用。

呢個先至係AI應有嘅樣。唔係更快嘅打字員，係你嘅效率拍檔。

06 點樣用呢個提示詞

如果你用Codex，複製GDB嘅提示詞，直接Send畀Codex，等佢輸出候選清單。

但我建議加兩個步驟：

第一步：先跑Vaibhav嘅改進版

喺GDB嘅提示詞之前，加一句：先睇睇你過去三十日嘅對話記錄，列出重複工作，再做後續分析。

咁樣Codex嘅視野唔只侷限喺當前會話，而係會睇全局。

第二步：建立評分機制

畀每個技能設一個使用計數器。連續失敗三次就標記為「待審查」，連續成功二十次先升級為「穩定技能」。

呢個機制唔需要複雜，一個表格就夠。技能名、成功次數、失敗次數、最後使用時間。

07 呢件事嘅邊界喺邊

GDB呢個提示詞，解決嘅係「重複性工作嘅自動化」問題。但佢唔係萬能嘅。

佢唔可以幫你揾到嗰啲你仲未意識到嘅新需求，唔可以幫你做需要深度研究嘅一次性任務，亦都代替唔到你理解業務邏輯。

佢只能夠喺你已經有重複行為嘅時候，幫你將重複嘅部分抽返出嚟。

所以佢嘅定位好清楚：對於嗰啲你已經做咗兩次以上、輸入穩定、有明確結束標誌嘅工作，佢可以幫你自動化。但對於真正需要判斷力嘅事，都係要你自己搞掂。

08 最後

我第一次見到呢個提示詞嘅時候，諗嘅係：AI喺幫我寫程式碼呢件事上，已經夠勁喇。

後來我先意識到，更大嘅機會係叫AI幫我將嗰啲我根本唔應該花時間做嘅嘢，全部自動化曬。

GDB畀出嘅呢個提示詞，本質上係講緊：工具嘅價值唔係幫你做更多嘅事，而係幫你唔再做嗰啲唔應該做嘅事。

呢個係兩件完全唔同嘅事。

Greg Brockman：Codex自我優化提示詞框架

蝦哥導讀OpenAI聯合創始人Greg Brockman發了一個自我優化提示詞框架，讓Codex自己學會"偷懶"——不是幫你寫代碼，而是主動把你重複做的事自動化。

01 多數人用AI的方式，從根上就錯了

我見過太多人用Claude Code、用Codex的方式是這樣的：

每天花半小時描述需求，等AI吐代碼，發現有問題再改，改完又有新bug，再描述，再等，再改。

然後第二天做同樣的事。

第三天還做同樣的事。

這不是用AI寫代碼，這是給自己找了個速度更快的打字員。你們都在重複同樣的對話，只是在不同的會話裏。

而GDB在2026年5月24日發的那條推文，說的是另一件事：

"你應該讓AI學會不再重複。"

他給的提示詞框架，核心邏輯只有一句話——讓Codex去翻自己的歷史記錄，找出那些你做了兩次以上的事情，然後把它做成一個技能，下次你再遇到同類問題，它自己就能搞定，不用等你開口。

02 這道提示詞的核心結構是什麼

GDB的提示詞我研究了兩週，結構很清晰，分三個階段：

階段一：讓AI去挖掘數據

你告訴Codex，去翻這三個地方：

1. 最近的對話記錄（sessions）

2. Codex自身的記憶（Memories）

3. 跨工具的歷史痕跡（Chronicle，如果開了的話）

這三個地方的信息質量遞減——對話最直接，記憶次之，Chronicle最遠。所以GDB加了一條優先級：先用對話和記憶交叉驗證，只有在證據不夠的時候才去Chronicle裏找線索。

這個順序很重要。很多人讓AI做自我優化的時候，隨便扔一句話"你過去有什麼重複的工作"，AI就會瞎編。但GDB這個框架是讓AI用具體發生過的事實說話，不是憑感覺猜。

階段二：篩選出值得自動化的任務

不是所有重複的事都值得包裝成技能。GDB給了一套篩選標準：

· 至少出現兩次**：一次性工作不包裝

· 輸入穩定**：每次觸發時情況差不多，不會每次都變

· 有明確的停止條件**：做完之後知道什麼時候該停

· 能實質提升速度或質量**：不是錦上添花，是真的省時間

· 沒有現成工具覆蓋**：別重複造輪子

這套標準直接過濾掉了一大堆"聽起來值得做但其實不值得做"的候選。AI最後輸出的清單，每一個都是真值得做的。

階段三：輸出清單，然後只創建高置信度的

先列候選清單，包括：工作描述、證據來源、頻率/置信度、建議形式（技能/子智能體/自動化）、為什麼要做/為什麼不值得做。

然後，只創建置信度高的那幾條。其他的不動。

這個設計很聰明——它不讓AI一口氣把事情全做了，而是讓它先評估，再動手。避免AI因為過度自信，把一堆低質量的東西包裝出來，結果你用不上，還得手動清理。

03 那個"改進版"更有意思

Vaibhav Srivastav在GDB的基礎上加了一個環節，我覺得比原版更好用。

他讓Codex在開始之前，先回顧自己的歷史，找出那些"跨會話重複出現的工作"。

這加了一步很重要的前置動作：Codex不再只看你當前說了什麼，而是去翻賬本——你過去一個月在這套工具裏做了哪些事，其中哪些是你反覆做的。

這個改進解決了一個實際問題：很多重複工作你是不會在單個對話裏跟AI說的，你可能自己手動做了，然後發現每次都得做，然後你就認命了，覺得這就是工作的一部分。

但Codex自己去翻記錄的時候，它會看到：這個人每週五下午都要把日誌文件打包發郵件，這件事他做了六週，沒有任何自動化，從來沒提過。

它就會主動問：要不要我把這件事做成一個自動化？

這就是讓AI從被動應答變成主動發現。

04 那條HN評論說中了本質問題

在Hacker News上，有人說了一句很準的話：

"提示詞是最容易的部分，真正出問題的是評分循環。沒有評分循環，你只是在製造自信漂移。"

這解釋了為什麼很多人試了GDB這個提示詞，發現效果一般。

問題不在於"有沒有找到重複工作"——Codex讀會話記錄，總能找到一些重複的事。問題在於"做完之後誰來判斷這個技能是不是真的有用"。

如果Codex生成了一個技能，但它不準確，或者用了兩次就出錯，你沒有機制去糾正它，它就會繼續用錯的技能幫你們幹活，然後每次都把問題推到"人類輸入有問題"。

所以真正落地的版本，需要加一個評分循環：技能創建後，記錄它的使用次數和成功率。如果連續三次都失敗，就降級或者刪除。

這不是GDB提示詞本身的內容，但如果你想在團隊裏真正用起來，這是繞不過去的設計。

05 這道提示詞真正改變的是什麼

我用了兩週，想明白了這件事：

GDB這個提示詞，表面上是在讓Codex學技能，實際上是在改變AI的工作方式——從"你說我做"，變成"它主動發現問題"。

傳統的AI使用模式，是人類負責發現問題、定義問題、描述問題，AI負責執行。人的瓶頸在於"我怎麼描述清楚這件事"，AI的瓶頸在於"我只能做你讓我做的事"。

GDB這個框架，把"發現問題"這件事也交給了AI。人類從執行者變成了評估者——AI列出候選清單，人類決定做哪個、不做哪個，以及做完之後好不好用。

這才是AI該有的樣子。不是更快的打字員，是你的效率搭檔。

06 怎麼用這道提示詞

如果你用Codex，複製GDB的提示詞，直接發給Codex，等它輸出候選清單。

但我建議加兩個步驟：

第一步：先跑Vaibhav的改進版

在GDB的提示詞之前，加一句：先看看你過去三十天的對話記錄，列出重複工作，再做後續分析。

這樣Codex的視野不只侷限在當前會話，而是會去看全局。

第二步：建立評分機制

給每個技能設一個使用計數器。連續失敗三次就標記為"待審查"，連續成功二十次才升級為"穩定技能"。

這個機制不需要複雜，一個表格就夠了。技能名、成功次數、失敗次數、最後使用時間。

07 這件事的邊界在哪

GDB這個提示詞，解決的是"重複性工作的自動化"問題。但它不是萬能的。

它不能幫你找到那些你還沒意識到的新需求，不能幫你做需要深度研究的一次性任務，也不能替代你去理解業務邏輯。

它只能在你已經有重複行為的時候，幫你把重複的部分抽出來。

所以它的定位很清楚：對於那些你已經做了兩次以上、輸入穩定、有明確結束標誌的工作，它能幫你自動化。但對於真正需要判斷力的事情，還是得你自己來。

08 最後

我第一次看到這個提示詞的時候，想的是：AI在幫我寫代碼這件事上，已經夠強了。

後來我才意識到，更大的機會是讓AI幫我把那些我根本不該花時間做的事情，全部自動化掉。

GDB給出的這道提示詞，本質上是在說：工具的價值不是幫你做更多的事，而是幫你不再做那些不該做的事。

這是兩件完全不同的事。