原名: 指南/目的
原文:@dkundel, OpenAI 開發者關係成員
照片來自Peggy

編輯器 : 這篇文章來自 OpenAI 開發者關係會員 Dominik Kundel, 概述 Codex "goal Mode//goal" 功能的經驗 。 這不關普通的即時技術, Codex不再只是一個應用單輪指令的代碼助手。

在 / 目標 模型中, 寫更長的要求并不重要, 而是要為 Codex 制定清晰且可核查的退出標準 。 例如, 部署時間的30%減少, 這些指示器讓 Codex 可以判斷這項工作是否已完成, 同時, 使用者需要提供足夠的方向、工具和真正的環境, 讓 Codex 可以衡量進度、驗證結果。

特別是這篇文章提醒大家, 而非要求像素水平降低100%, 也有必要透過委員會、公關草案、進展檔案、Slack更新或旁白等。

這篇文章的附加價值是它重新定義/目標為「長期任務管理机制」。 當AI能連續經營數以十數甚至數百個小時, 也就是說, AI編程正在從「寫入提示」走向「管理進行中的專案執行者」。

原文如下:

我們推出目標模式(goal Mode, 或/goal), 當你设定目標時, Codex會一直工作到目標達成——需要數小時,數天. 有人讓Codex為同一目標工作了120多小時。

目標模型很強大 要盡最大可能。

制定明确和可核查的标准

當您啟動目標模式時輸入的提示可以作為初始提示,更重要的是,它會成為目標的退出標準. 每輪工作後, Codex 會檢查此目標是否達成 。

因此,你的目的信息應該不是太長,而是要專注於一個明确的標準:當目標達成的時候。

在大多數情況下, 例如:

"把建造和部署時間减少30%"

將此函數從 TypeScript 傳送至 Rust 并達到100% 的測試一致性

使製作環境內最大內容映射(Largest Contentful Point

此提示不一定包括數字, 但通常數目會讓之後的步數更容易進步 。

如果你不知道如何定義目標, 或者如果你想用 Codex 開始專案, 你不必從目標模式開始 。

Codex可以自己定目標 當你準備好讓Cordex開始時 你可以正常地開始談話 然后讓Cordex根据討論來设定目標。

您也可以隨時編輯目標: 點擊 Codex 應用程式中的編輯按鈕, 或是在 CLI 中再次使用 / 目標 。

尽可能提供指导

像是「建筑和部署時間減少30%」的暗示聽起來很酷, 但是如果你知道問題可能在哪 這提示也可以讓 Codex 出現在曲線上。

所以只要有可能 最好告訴 Codex 從何開始 使用什麼工具來達成目標 或者提供其他提示 避免它往錯方向走。

例如我的同事@reach vb在實驗中做了:他告訴Codex, 他可以用Chome瀏覽器存取Google Colab, 以及一些可接受的限制, 例如讓 Codex 訓練模型自己產生數據集。

重複,如果你想缩短建築時間,并且已經知道用完哪一部分時間,最好在提示中指代 Codex 。

或者您可以讓 Codex 在計劃模式下做一些初步研究, 使它建立一個計劃文件來記錄可能的程序 。 那就讓你的目標引用計劃。

取得可衡量进展

如果你的目標是宏大 或者Cordex有很多方法可以接近它 那你必須給Cordex 衡量進步的工具。

這對一些任務來說可能很自然 例如, 优化建築時間及增加測試範圍, 因為 Codex 通常已經可以使用工具或自然建立工具 。

但對其他目標來說 你最好從 Codex 的頭風開始 哪些工具能幫助判斷進步? 或者給它點提示 如何確認它正接近目標 例如, 為兩個截圖建立視覺差異比對工具, 或是為您正在調试的智能體建立評估集 。

我讓 Codex 重新編譯一些基于影像的元件, 當 Codex 創造了一個工具讓自己來比較截圖和檢查區別。 之後,它繼續重複工具,增加了不同的对比模型。

圖片: Codex 製作兩帧影像比對的截圖 。

也需考慮是否有其他的衡量或檢查标准。 不然 Codex可能會認為這工作已經完成 但你不覺得它完成了。

例如, Codex 可以剪切設計參考地圖, 將它們嵌入一頁, 以降低像素等級; 或者它可以把測試覆盖率降低到100% 。 這些都不是你真正想要的。

建立真正的環境

如果你想讓 Codex 在目標上取得真正的進步 它需要一個足夠真實的環境。

在實際上, 這意味著如果您要优化部署時間或延遲, Codex應該可以存取部署和測試環境, 這些環境是尽可能模擬的 。 這意味著使用相同的科技堆栈, 相同的設定開關和相似的數據庫 。

例如,我們正在調解人造和部署時間优化。 我們已經在使用部署預覽, 所以 Codex 可以使用預覽環境來部署並查看相關的紀錄 。 但問題是一些建築通道與預覽部署及完整製作環境相比。

因此, Codex 最终不得不手動部署到更靠近製作設定的環境,以實際地檢查問題。

相似的, 您可以使用 Codex 來測試實際應用程式 。 @dimirian甚至用物理設備來取得最准确的測試環境。

小心設置視覺目標

給 Codex 一個視覺目標, 如「 百分之百的像素級回歸到此圖片的UI 」, 這真的很吸引人 。 然而,根据具体安排,也可能有问题。

如果你沒有提供正確的方向和規矩, Codex 可能會越來越深入一些細節, 而忽略了整個目標。 例如,如果參考圖中包含一些您期望 Cordex 產生的圖像元素 -- 不管是SVG圖示還是圖片——它可能會把很多精力投入到"如何精确地重新捕捉這些材料"上,而不是把整個問題拆掉。

此外, Codex 需要工具來做視覺比對 。 這意味著更多的相片投入, 更多的代碼消耗。

因此,照片通常更适合作为目標的上下文而不是唯一的完成標準. 您應該為 Codex 找到其他方法來判斷目標是否達成, 例如功能清單、 成就规范、 符合設計系統等 。

追蹤進度

如果Codex終于在後台工作數小時甚至數天 甚至是在另一台機器上 很容易忘記它去了哪裡 做了什麼。

基于不同的目標,我找到了以下方法來幫助:

根據創用CC授權使用 當您正在建立網站並預覽部署時。

• Jean Codex更新面向管理的交付。 它可以是 HTML 檔案, 您可以在應用程式瀏覽器中保持開啟; 它可以是您通過 Sites 部署到團隊的頁面; 它可以是一個已變更的進度地圖, 或者只是一個普通的 Markdown 檔案 。

指示 Codex 提供最新進度 。 您也可以將它放入目標中: 讓 Codex 傳送更新到 Slack 頻道, 或是你想記錄的任何地方 。

以其他聊天視窗要求狀態 。 如果你只是想快速了解州情,你可以跑步/邊上,開始新的一邊聊天并在那里提出問題. 因為它會穿過目前的線線, 它有所有上下文至今, 但有短的生命周期。

Cordex 應用程式的另一個替代方案是開啟一個普通的新聊天, 讓 Cordex 讀取另一個目標線并回答您的問題 。 如果你讓Cordex設置一個自動任務 定期檢查進展,這將是特別強大的。

清理和最后确认

太好了,目標終于完成了 我們能把結果投給球隊嗎

我認為Codex審查和審查他的所作所為有幫助。 您可以先用 / Review 進行本地代碼評論, 它試圖走什麼路? 什么事? 什么不行? 那就照此清理密碼。

因為Codex會一直工作到目標達達, 它可能已經試圖過一些方法,但都不夠好,甚至完全無效, 這些剩余的變更可能仍然留在最後的代碼中。

我幫你安排下一個任務

Codex的目標功能是一種非常強大的工具,可以幫助你處理一些最重要的工程挑戰. 但只有你提供正確的環境和指示,它才能更有效率地達到目標。

你拿它做了什麼

[ 笑 ]原始链接]