ChatGPT／Codex 更新了什麼？9 個實用功能與操作教學
ChatGPT／Codex 多了哪些值得用的功能？本文整理 Dots、Sites 網站部署、Space、側邊聊天與 Plan／Goal 等 9 個功能與用法，透過操作情境與 Prompt 範例，帶你了解如何規劃任務、修改內容與分享成果，並標示 Plus／Pro 的方案差異。
如果你已經一陣子沒用 ChatGPT 或 Codex，重新打開時，可能會發現多了不少陌生的功能。但光看名稱，很難知道它們能幫自己做什麼。
這篇整理了 9 個值得認識的功能與用法，包含近期推出的 Dots、Space，以及網站部署、側邊聊天和長任務規劃。有些是最近新增，有些已推出一段時間，我這邊一起補上。它們涵蓋 ChatGPT、Work 與 Codex 的不同情境，並非全部都屬於 Codex 專屬功能。
1. Dots：讓雲端工作在你離開電腦後繼續
個人方案需 Pro；Plus 目前不包含，且仍採逐步開放。
如果你想讓 AI 持續追蹤一個主題，例如每週整理產業變化、追蹤專案待辦，Dots 值得認識。它有自己的雲端電腦與瀏覽器，可以使用已連接的工具、整理資料，並協調其他工作任務。
Dots 於前些日子的DevDay 公告中介紹。它的雲端工作可以在你的裝置關閉時繼續，但如果任務要讀取本機檔案或操作本機工具，連接的電腦仍須在線並開啟 ChatGPT。這裡要區分「在雲端執行」與「使用你的電腦」。
開始時，先在支援的桌面 App 或桌面瀏覽器建立 dot，再告訴它要追蹤什麼、使用哪些資料，以及何時回報。例如：
每週一上午 9 點，依台灣時間整理過去一週的 AI 工具更新。優先追蹤設計、網站開發與內容製作，列出 3～5 項變化、官方來源與值得實際測試的用法。請確認排程。
設定的是排程與責任，不代表指定時刻一定完成所有研究。先檢查第一次產出的內容，再調整資料來源與篩選條件，比一開始交代大量任務更容易掌握方向。
Philo
有興趣可以進來看看
2. Sites：把做好的網站變成可以分享的連結
Plus 可用，使用量與支援範圍仍有限制。
用 AI 做出網站後，常見的下一個卡點是：「我能在自己的電腦打開，但別人要怎麼用？」Sites 提供網站建立與託管功能，讓你在 ChatGPT 中繼續完成部署，適合活動頁、作品集、小工具或互動原型。
你可以在支援的網頁介面從 More → Sites 找到網站，或直接開啟 chatgpt.com/sites。如果已經有專案，可以提出以下要求：
請檢查這個專案是否適合部署到 Sites，完成必要調整並部署。先維持私人存取，提供可供我檢查的網址。
網站能開啟後，再測試主要按鈕、手機版面與資料儲存行為，最後設定分享對象。部署成功與任何人都能開啟，是兩件事；私人網站的網址不會自動讓其他人取得權限。
Sites 也提供環境變數，適合放需要由伺服器使用的 API 金鑰。金鑰不能因為設成環境變數就拿到前端公開；串接時仍要確認它留在伺服器端。若要接資料庫或自訂網域，也應先確認支援方式，不能直接把 Sites 視為完全取代所有託管與資料庫服務。
3. Space：把頁面、檔案與相關工作集中整理
當同一個專案累積了需求、圖片、研究資料與交付檔，回到每段對話找附件會越來越麻煩。Space 是集中整理頁面、檔案與共享工作的地方；其中的 Page 是可編輯的文件，可以用來放專案簡介、會議紀錄或研究摘要。
Page 可以直接編輯，也能與其他人協作。分享時，要留意頁面中已貼入或摘要的資料會被有權限的讀者看見；分享頁面不等於分享私人對話，但頁面本身的內容仍會被共享。
4. 草圖引導圖片：先畫出位置，再讓 AI 補上視覺
「標題大一點、人物放右邊、左下角放資訊」說得再清楚，AI 也可能生成與你想像不同的構圖。這時可以先畫一張簡單草圖，用方框與文字標出位置，再附圖請它生成。
例如製作活動海報時，先標出標題區、主視覺區、時間地點與報名資訊，不需要把草圖畫得漂亮。重點是讓它知道哪些位置要保留、哪些部分可以自由發揮。
依照附件草圖生成一張活動海報。保留上方標題、右側人物與左下方資訊區的位置，使用奶油白與深藍色。草圖只作為構圖參考，不要把手繪方框留在成品中。
若你的介面沒有內建繪圖按鈕，用其他工具畫草圖，再上傳圖片也能提供視覺參考。生成後仍要檢查文字與資訊，尤其是日期、名稱及需要精準排版的內容。
Joanna Chang
或者可以使用畫布功能，也是類似的做法
5. 對話接力：把討論好的需求交給下一個任務
對話接力可以分成兩種需求：一種是換裝置繼續同一個工作，另一種是把討論過的方案帶進開發任務。前者要確認任務執行環境與同步方式；若工作依賴本機，電腦仍須保持可連線。
後者最實用的做法，是在交接前先整理需求。與其只說「照剛剛聊的做」，可以先要求產出一份包含目標、功能、限制與驗收條件的摘要，再把摘要交給 Codex。
請把這段對話整理成開發交接摘要，包含使用者、核心功能、已確認決策、待確認事項與完成條件。接著依摘要規劃第一版實作，先提出需要釐清的問題。
6. 加入聊天：直接指出要修改的段落
AI 回覆很長時，只說「這段不好」容易讓它改錯地方。選取文字再附上修改要求，可以讓回饋對應到特定內容，例如一段文案、某個規格，或方案中的一個步驟。
如果介面提供選取內容後加入對話、批註或修改的選項，先選取該段，再描述你希望改變的地方。沒有選取入口時，直接引用原文也能指出位置。
針對選取的「製作流程」補上兩個替代方案，分別說明適用情境與限制。保留其他段落。
回饋越具體，越容易檢查修改是否符合期待。「提供更多可能性」可以再補上比較方向，例如成本、操作步驟或適用對象，避免只得到幾個換句話說的版本。
7. 更多詳細資訊：遇到陌生概念，先弄懂再繼續
AI 在規劃網站時，可能突然提到環境變數、資料庫或部署。你不一定需要學完整套技術，但需要知道這個概念會影響什麼，才能判斷下一步。
若介面提供選取文字後查看詳情的入口，可以先選取該名詞，再查看解釋；若沒有，直接引用名詞追問即可。這裡的重點是把問題縮小到你要做的決策。
請用網站新手能理解的方式，解釋「環境變數」。以 API 金鑰為例，說明它放在哪裡、網站如何使用，以及哪些做法會把金鑰公開。
比起只問「這是什麼」，帶上正在做的任務，通常更容易得到可用的說明。這段操作路徑待補截圖確認，初稿先不將「更多詳情」寫成每個帳號都會出現的固定按鈕。
8. 側邊聊天：在主任務旁邊追問細節
Codex 有此功能，尚未找到 Pro 專屬限制。
當 Codex 正在執行較長的開發任務，你可能想問：「為什麼選這種架構？」或「這個錯誤代表什麼？」側邊聊天可以讓你另開一段聚焦對話，理解細節，同時保留主要工作的方向。
在支援的介面中，可以使用 /side，或選取回覆文字後選擇 Ask in side chat。例如：
/side 請解釋這個登入方案為什麼需要伺服器端處理，以及目前還有哪些未完成的部分。
側邊聊天適合解釋與比較；若討論後決定要改動主要任務，應回到主對話明確交代：「請將剛剛確認的方案納入實作。」不要假設側邊對話中的所有內容都會自動變成主任務的修改指令。
9. Plan 與 Goal：先釐清做法，再持續推進成果
當任務需要調研、設計、實作與多次修正，直接一句「幫我做完」可能留下太多未確認的地方。Plan 適合先釐清做法與範圍；Goal 則用來定義需要持續追求的成果與完成條件。
例如想做一個論文閱讀工具，可以先在支援的介面使用 /plan，要求規劃第一版：
/plan 我要做一個論文閱讀工具，第一版需要上傳 PDF、顯示摘要與重點問答。請先列出功能範圍、必要的 API、資料保存方式及驗收條件，釐清問題後再開始實作。
確認方案後，再以 /goal 設定具體目標：
/goal 完成可供我驗收的論文閱讀工具第一版。以已確認的需求為準，完成核心功能與測試，列出已完成項目、未解問題與需要我決定的事項。
Plan 是先討論怎麼做，Goal 是定義做到什麼程度才算完成。 網頁版 Work 不一定提供同樣的 Goal 控制入口，仍可以把成果、限制與驗收條件直接寫進提示。長任務也可能因資訊不足、連線或使用額度而需要你介入，不能將 Goal 理解為無條件持續執行。
挑一個功能，放進你的日常工作
這次整理的功能，從需求討論、內容修改到成果分享，各自對應不同的工作環節。你不必一次用上全部，可以先挑一個最符合目前需求的功能，拿手上的任務試試看。
例如，把做好的網站透過 Sites 分享出去，或在下一次修改文案時，用選區批註給出更具體的回饋。實際用過一次，就更容易判斷哪些功能值得留在自己的工作流程裡。
