📢 Gate 廣場 | Polymarket 6/4 特別預測:NBA 總決賽,尼克斯 vs 馬刺誰能奪冠?
NBA 總決賽火熱開打!目前 Polymarket 預測市場上,66% 用戶押注馬刺,35% 用戶看好尼克斯。強強對決,您認為冠軍最終花落誰家?
🎁 全民瓜分獎: 參與尼克斯 vs 馬刺焦點戰預測,瓜分 20,000 USDT 巨額獎池!
👉️ https://www.gate.com/zh/campaigns/5030
🎁 廣場專屬福利: 抽取 10 位發布優質內容的用戶,每人贈送 $5 代幣!
📝 參與攻略:
帶 #预测NBA总冠军赢20,000U 發帖,選擇以下任一方式參與:
🔹 方法 A:預測您心中的奪冠球隊,並掛載事件卡片
🔹 方法 B:曬出您的交易截圖,分享交易思路與觀點
📍注意:選擇方法 A 時,需在發帖頁-幣種圖標中掛載對應 Polymarket 事件卡片,才算有效參與。
立即參與:https://gate.onelink.me/Hls0/prediction?page=detail&event_ticker=543443&source=cex
Codex 目標模式使用指南:如何讓AI持續推進一個具體目標
編者按:這篇文章來自 OpenAI 開發者關係成員 Dominik Kundel,對 Codex「goal mode / /goal」功能的使用經驗進行總結。它討論的並不是一個普通 prompt 技巧,而是 AI 編程工具正在發生的一次角色變化:Codex 不再只是響應單輪指令的程式碼助手,而開始成為一個可以圍繞明確目標持續推進的執行型 Agent。
在 /goal 模式下,真正重要的不是把需求寫得越長越細,而是為 Codex 設定清晰、可驗證的退出標準。比如「部署時間降低 30%」「測試覆蓋達到 100% parity」「LCP 降到 2.5 秒以下」。這些指標讓 Codex 能夠判斷任務是否完成,也避免它在模糊目標中無限試錯。與此同時,使用者還需要提供足夠的方向、工具和真實環境,讓 Codex 能衡量進展、驗證結果,而不是只在本地或假設條件下完成一個看似可行的方案。
文章尤其提醒,視覺類任務最容易讓 Codex 陷入細節泥潭。與其要求「100% 像素級還原」,不如將視覺目標拆解為功能清單、設計系統規範和可評估指標。對於持續數小時甚至數天的長期任務,也需要透過 commit、draft PR、進度文件、Slack 更新或 side chat 等方式持續跟蹤,避免最終只得到一堆不可追溯的改動。
這篇文章的信息增量在於,它把 /goal 重新定義為一種「長期任務管理機制」。當 AI 可以連續執行幾十甚至上百小時,開發者的核心能力也隨之變化:不只是讓 AI 生成程式碼,而是為它定義目標、建立度量體系、配置執行環境,並在最後完成審查和復盤。換句話說,AI 編程正在從「寫提示詞」走向「管理一個持續工作的工程執行者」。
以下為原文:
我們推出了目標模式(goal mode,或 /goal),是為了幫助你讓 Codex 朝著一個具體結果持續推進。當你設定一個目標後,Codex 會一直工作,直到目標達成——無論這需要幾個小時,還是幾天。已經有人讓 Codex 為同一個目標連續工作超過 120 小時。
目標模式非常強大。想要最大化發揮它的作用,使用 /goal 時有 7 件事值得注意。
設定清晰、可驗證的標準
當你啟動目標模式時輸入的提示詞,既可以作為初始提示,更重要的是,它會成為這個目標的退出標準。Codex 會在每一輪工作之後檢查:這個目標是否已經完成。
因此,你的目標提示不應該寫得過長,而應該聚焦於一個清晰標準:什麼情況下,才算這個目標已經達成。
多數情況下,一個好的目標最好包含一個明確的數字指標,供模型判斷是否完成。例如:
「將構建和部署時間減少 30%。」
「把這個功能從 TypeScript 遷移到 Rust,並達到 100% 的測試一致性。」
「優化應用腳手架,使生產環境中的最大內容繪製(Largest Contentful Paint,衡量頁面主要內容載入速度的指標)低於 2.5 秒。」
這個提示不一定總要包含數字,但通常來說,數字會讓後續步驟更容易推進。
如果你還不確定該如何定義目標,或者想先和 Codex 一起頭腦風暴這個專案,也不必一開始就用目標模式開啟對話。
Codex 可以自行設定目標。你可以先正常開啟一段對話,等你準備好讓 Codex 開始執行時,再讓 Codex 根據前面的討論內容設定目標。
你也可以隨時編輯目標:在 Codex 應用中點擊編輯按鈕,或在 CLI 中再次使用 /goal。
盡可能提供指引
像「將構建和部署時間減少 30%」這樣的提示,聽起來很酷,也可能讓 Codex 找到一些創造性的解決方案。但如果你已經大致知道問題可能出在哪裡,這種提示也可能讓 Codex 走上彎路。
所以,在可能的情況下,最好告訴 Codex 應該從哪裡開始排查、可以使用哪些工具來完成目標,或者給出其他提示,避免它鑽進錯誤方向。
例如,我的同事 @reach_vb 在一次實驗中就這樣做了:他告訴 Codex,可以使用 Chrome 瀏覽器進入 Google Colab,並說明了一些可接受的限制條件,比如在讓 Codex 訓練模型時,可以讓它自己生成資料集。
同樣,如果你想縮短構建時間,並且已經知道大部分時間消耗在哪個環節,最好在提示詞中先把 Codex 指向那個區域。
另一種做法是,你可以先讓 Codex 在計畫模式(plan mode)下做一些初步研究,並讓它建立一個計畫文件,用來記錄潛在方案。隨後,再讓你的目標引用這份計畫。
讓進展可衡量
如果你的目標很有野心,或者 Codex 有很多種方式可以逐步接近目標,那麼很重要的一點是:你要給 Codex 提供衡量進展的工具。
對於某些任務來說,這一點可能天然成立。比如優化構建時間、提高測試覆蓋率,因為 Codex 通常已經能使用相關工具,或者會自然地建立這些工具。
但對於其他目標,你最好先和 Codex 一起頭腦風暴:哪些工具有助於判斷進展?或者給它一些提示,讓它知道該如何確認自己是否正在向目標靠近。例如,為兩個截圖建立視覺差異比對工具,或者為你正在調試的智能體建立一套評估集。
我曾讓 Codex 根據一段影片復刻一些元件,當時 Codex 為自己建立了一個工具,用來比較截圖並檢查差異。後來,它還持續迭代這個工具,加入了不同的差異比對模式。
根據任務不同,你還需要考慮是否有一些額外標準需要被測量或檢查。否則,Codex 可能會以為任務已經完成,但在你看來其實還不完整。
比如,Codex 可能為了「像素級還原」某個 UI,直接裁剪設計參考圖並內嵌到頁面裡;或者為了讓測試通過率達到 100%,反過來削減測試覆蓋範圍。這些都不是你真正想要的完成方式。
建立一個真實的環境
如果你希望 Codex 真正朝目標取得有效進展,它就需要在一個足夠真實的環境中運行。
在實踐中,這意味著:如果你想優化部署時間或延遲問題,Codex 應該能存取部署和測試環境,而且這些環境要盡可能模擬生產環境。也就是使用相同的技術棧、相同的配置開關,以及類似的資料庫。
舉個例子,我們曾經在調試 developers.openai.com 的構建和部署時間優化。當時我們已經在使用部署預覽,因此 Codex 可以利用這些預覽環境進行部署,並查看相關日誌。但問題在於,我們的預覽部署和完整生產環境相比,禁用了一些構建路徑。
因此,Codex 最後不得不進行手動部署,把程式碼部署到與生產配置更接近的環境中,才能真正檢查問題所在。
類似地,你也可以讓 Codex 使用 computer use(讓模型操作真實應用界面的能力)來測試實際應用。為了優化 iOS 上的一些性能問題,@dimillian 甚至使用了實體設備,以獲得最準確的測試環境。
謹慎設定視覺目標
給 Codex 一個視覺目標,比如「根據這張圖片 100% 像素級還原這個 UI」,確實很誘人。但根據具體設定不同,這也可能帶來麻煩。
如果你沒有給出合適的指引和約束,Codex 可能會在某些細節上越陷越深,反而忽略整體目標。比如,如果參考圖中包含一些圖形元素,而你期待 Codex 生成這些元素——無論是 SVG 圖示還是圖片——它可能會把大量精力耗在「如何精確復刻這些素材」上,而不是正確拆解整個問題。
此外,Codex 需要工具才能正確進行視覺比較。這意味著更多圖片輸入、更高的整體 token 消耗,但並不一定能給 Codex 提供一種簡單方式,讓它識別真正有價值的改進機會。
所以,圖片通常更適合作為目標上下文,而不是唯一的完成標準。你應該尋找其他方式,讓 Codex 判斷目標是否已經達成,例如功能清單、實現規範、是否符合設計系統等。
跟蹤進展
如果 Codex 最終在後台工作數小時甚至數天,甚至是在另一台機器上運行,你很容易忘記它到底推進到哪裡、已經做了哪些工作。
根據不同目標,我發現下面幾種方式很有幫助:
·讓 Codex 在關鍵節點提交程式碼,並推送到一個草稿 PR。尤其是當你在做網站,並且有預覽部署時,這會非常有用。
·讓 Codex 更新一份面向管理層的交付物。它可以是一個 HTML 檔案,你可以在應用內瀏覽器裡一直打開;也可以是一個透過 Sites 部署給團隊查看的頁面;可以是一張渲染後的進度圖,也可以只是一份普通的 Markdown 檔。
指示 Codex 主動發布進展更新。你也可以把這寫進目標裡:讓 Codex 在取得重要進展時,把更新傳送到 Slack 頻道,或者你希望記錄進展的其他地方。
使用其他聊天視窗詢問狀態。如果你只是想快速了解當前狀態,可以運行 /side 啟動一個新的側邊聊天,並在那裡提問。因為它會從當前線程分叉出來,所以擁有截至目前的全部上下文,但生命週期很短。
在 Codex 應用中的另一個替代方法是:開啟一個普通新聊天,讓 Codex 閱讀另一個目標線程,並回答你的問題。如果你讓 Codex 設定一個自動化任務,定期檢查進展,這種方式會尤其強大。
清理並最終確認結果
太好了,目標終於完成了!現在是不是就可以直接把成果甩給團隊,然後收工?
通常來說,尤其是在優化類任務中,我發現讓 Codex 回顧並審查自己完成的工作會很有幫助。你可以先用 /review 執行一次本地程式碼審查,但也值得讓 Codex 更深入地反思:它為達成目標嘗試過哪些路徑?哪些嘗試有效?哪些嘗試無效?然後據此清理程式碼。
因為 Codex 會一直工作,直到達到目標,所以它可能嘗試過一些效果不夠好、甚至完全無效的方法,而這些殘留改動可能還留在最終程式碼中。
給你的下一個任務也設一個 goal
Codex 的目標功能是一個極其強大的工具,可以幫助你解決一些最有意義的工程挑戰。但只有當你提供了正確的環境和指令,它才能更高效地抵達目標。
你用 /goal 做過什麼?
[原文連結]
點擊了解律動BlockBeats 在招崗位
歡迎加入律動 BlockBeats 官方社群:
Telegram 訂閱群:https://t.me/theblockbeats
Telegram 交流群:https://t.me/BlockBeats_App
Twitter 官方帳號:https://twitter.com/BlockBeatsAsia