For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主要導覽
Codex

Codex use case

進行細微 UI 變更

使用 Codex-Spark,在現有應用程式中快速、聚焦地迭代 UI。

Difficulty 簡單
Time horizon 5 分鐘

使用 Codex 在現有應用程式中每次只進行一項小幅 UI 調整,接著在瀏覽器中驗證,並將彈出式對話視窗放在預覽畫面附近,以便快速持續迭代。

最適合

  • 適合主要結構已建置完成、只需進行小幅視覺調整的現有應用程式
  • 適合快速的產品或設計審查迴圈,將每則意見轉化為一項聚焦的程式碼變更
  • 適合需要瀏覽器驗證、但不應演變成大範圍重新設計的 UI 精修流程

Contents

    ← 所有使用案例

    進行細微 UI 變更

    使用 Codex-Spark,在現有應用程式中快速、聚焦地迭代 UI。

    使用 Codex 在現有應用程式中每次只進行一項小幅 UI 調整,接著在瀏覽器中驗證,並將彈出式對話視窗放在預覽畫面附近,以便快速持續迭代。

    簡單
    5 分鐘

    使用 Codex 在現有應用程式中每次只進行一項小幅 UI 調整,接著在瀏覽器中驗證,並將彈出式對話視窗放在預覽畫面附近,以便快速持續迭代。

    簡單
    5 分鐘

    最適合

    • 適合主要結構已建置完成、只需進行小幅視覺調整的現有應用程式
    • 適合快速的產品或設計審查迴圈,將每則意見轉化為一項聚焦的程式碼變更
    • 適合需要瀏覽器驗證、但不應演變成大範圍重新設計的 UI 精修流程

    技能與外掛程式

    • 在實際瀏覽器中開啟執行中的應用程式,檢查套用變更的路由,並在進入下一輪迭代前驗證每項小幅 UI 調整。
    Skill Why use it
    Playwright 在實際瀏覽器中開啟執行中的應用程式,檢查套用變更的路由,並在進入下一輪迭代前驗證每項小幅 UI 調整。

    起始提示詞

    在現有應用程式中進行以下 UI 變更: [describe the exact spacing, alignment, color, copy, responsive, or component-state adjustment] 限制條件: - 僅變更這項 UI 調整所需的檔案。 - 沿用現有的元件、Token、圖示和版面配置模式。 - 除非我明確要求,否則不要變更行為、資料流和路由。 - 啟動或沿用開發伺服器,在瀏覽器中檢查目前的 UI,進行最小幅度的修補,並以目視方式驗證結果。 完成這一項變更後即停止,並摘要說明變更了哪些檔案,以及執行了哪項瀏覽器檢查。
    在現有應用程式中進行以下 UI 變更: [describe the exact spacing, alignment, color, copy, responsive, or component-state adjustment] 限制條件: - 僅變更這項 UI 調整所需的檔案。 - 沿用現有的元件、Token、圖示和版面配置模式。 - 除非我明確要求,否則不要變更行為、資料流和路由。 - 啟動或沿用開發伺服器,在瀏覽器中檢查目前的 UI,進行最小幅度的修補,並以目視方式驗證結果。 完成這一項變更後即停止,並摘要說明變更了哪些檔案,以及執行了哪項瀏覽器檢查。

    簡介

    當你已有現成的應用程式,並想快速迭代 UI 時,可以使用 gpt-5.3-codex-spark 對 UI 進行小幅且聚焦的變更。 Codex-Spark 是我們速度最快的模型,專為近乎瞬時的即時程式碼迭代最佳化。

    這種方式最適合採用緊密的迴圈:一則視覺調整意見、一次聚焦的編輯、一次瀏覽器檢查,接著再處理下一則意見。

    你可以使用 Codex Spark 模型 執行這項任務。此模型 可供 Pro 方案使用。

    選擇模型

    若要快速迭代 UI,且你可以使用 gpt-5.3-codex-spark,請優先選用此模型。它的能力不及我們的通用模型,但專為即時程式碼迭代而設計。如果無法使用,請改用 gpt-5.6,並將推理強度設為 mediumlow

    這樣的取捨對細微的 UI 調整很有幫助。若只是移動按鈕、微調中斷點或調整元件狀態,通常不需要使用推理深度最高的模型。你需要的是能快速回應、理解相關程式碼、編輯正確檔案,且能反覆執行此迴圈而不拖累迭代節奏的模型。

    開發流程

    1. 開啟現有應用程式,並讓相關路由或元件顯示在畫面上。
    2. 將目前的 Codex 對話另行彈出成 浮動視窗,並在工作時將它放在瀏覽器、編輯器或設計預覽畫面附近。
    3. 每次只要求 Codex 進行一項具體的 UI 變更。如有這些資訊,請附上路由、檢視區、目前畫面的截圖、目標畫面的截圖或明確的產品意見。
    4. 請 Codex 檢查目前的實作,進行最小且合理的修改,並保留應用程式現有的元件、Token、版面配置基礎元素和資料流。
    5. 審查結果,然後在同一個對話中送出下一項小幅調整。

    撰寫小範圍的提示詞

    細微 UI 變更的提示詞應直接且聚焦。好的提示詞會明確指出要調整的介面區域、目標變更,以及預期的驗證方式。

    如果結果已接近預期但仍不完全正確,後續提示詞也應同樣具體:

    這項變更已接近預期。保留目前的實作,但只調整以下細節: [describe the remaining mismatch] 停止前,請再次驗證相同的路由和檢視區。

    何時該放慢步調

    如果任務不再屬於細微調整,就不要繼續使用快速迴圈。當變更需要進行大範圍重構、加入新的設計系統基礎元素、實作複雜的無障礙行為,或做出影響多個畫面的產品決策時,請改用能力更強的模型,並撰寫更周詳的提示詞。

    快速 UI 迭代最適合用在 Codex 調整已充分理解的現有介面時,而不是讓它從頭重新設計應用程式。

    相關使用案例