學習 Cue · 任務導向教學

使用 Cue 語音與 Codex 審查程式碼變更

向審查者說明該變更旨在達成何種目標，以及哪些既有行為必須維持不變。接著要求提出佐證，而非對程式碼進行令人安心的摘要。

由 Cue 產品團隊 (English) 編寫 · 更新於 。依據產品來源審查撰寫。練習與輸出僅供說明，並非錄製的 Cue 執行歷程。請依照您安裝版本中所顯示的控制項操作。

快速解答

使用 Cue 擷取審查目標，在 Codex 中確認存放庫與 diff 範圍，然後提出唯讀審查請求。對照變更程式碼行與預期行為逐一查核各項發現。核准修復與請求審查是分開的步驟。

需求：已設定聽寫（Dictation）的 Cue、Codex 存取權限、一個 Git 專案，以及明確指明的變更與其預期行為。成果：一份排列優先順序、連結證據的審查報告，以及關於後續修復內容的決定，而非自動合併或安全性認證。

第一次使用 Cue？ 設定 Dictation 語音輸入 以輸入您說的話；若要提出任務要求，請 設定 Agent 模式。開始前，請核對安裝版本的權限提示與快捷鍵。

選擇輸入方式

當審查問題來自其他應用程式時，可以用 Cue 收集。你可能在閱讀規格說明、查看 Issue 或試用修改後的畫面時發現風險。把預期行為與必須維持不變的條件口述到暫存筆記中，核對文字後再交給 Codex。Cue 在這裡適合跨應用程式整理審查簡報；具體的 diff 仍需在審查環境中選定。

如果相關專案、diff 和審查問題都已在 Codex 中準備好，直接繼續即可。鍵入或貼上簡短要求，並使用下文介紹的審查控制項。不使用 Cue 也能完成這項練習。當口述或從任務外收集脈絡有助於把審查問題說清楚時，加入 Cue 才有意義。審查品質仍取決於提供的證據與審查者的核對。

用 Cue Dictation 向外部應用程式輸入

下文練習採用這種方式。Cue 將你說的話輸入已聚焦的暫存筆記或受支援的文字輸入欄位。核對措辭後，再明確把簡報傳送給 Codex，要求唯讀審查。無須設定 Cue 連接器。交接只包含你提供的材料，其他對話、檔案和權限不會自動隨之轉移。

使用 Cue 內的 Codex 連接器

這是從 Cue 使用外部 Agent 的另一種方式。先核對這條路徑的連線、登入狀態、專案與權限，並確認帳號和計費方式。看到 Codex 選項不代表它已經就緒。下文介紹的 Codex 應用程式審查面板和選單，不是 Cue 內連接器的操作說明。

為 Cue Agent 選擇託管模型

請 Cue Agent 把你提供的來源材料整理成審查簡報草稿，再依照這些材料核對簡報。為 Cue Agent 選擇 OpenAI 模型不會啟動 Codex，也不會讓另一個 Codex 任務取得程式碼儲存庫的存取權。託管模型的使用資格與計費取決於你的 Cue 帳號；外部 Agent 的存取權需要另外確認。

試做小幅修補的審查練習：先用 Dictation 輸入，再明確交接文字。口述審查目標，然後原樣附上 R-01 至 R-03 的材料。要求提出審查發現，不要編輯。當你能把每項發現追溯到確切的運算式與觸發輸入，並分清示例發現和實際執行過的檢查時，練習才算完成。

在察覺風險之處擷取審查問題

當審查聚焦於單一問題時，後續處理會容易得多。「審查全部內容」可能會產生風格建議，卻遺漏了您在意的行為。更有用的口語請求是：「此補丁讓數值為零的計數顯示出來。請檢查缺失的計數是否仍使用舊的空白狀態標籤。目前先不要編輯任何內容。」

  1. 將規格說明或受影響的畫面保持在可見狀態，然後聚焦於草稿筆記或預期的任務輸入框。叫用 Cue Settings 中顯示的 Dictation 捷徑，確認開始錄音，說出審查目標，停止錄音，並在處理完成後檢查插入的文字。
  2. 直接從來源複製確切的識別碼以完整保留。在傳送前，請先審閱數字、否定詞與分支名稱的轉錄結果。若您希望 Cue Agent 整理筆記，請要求其草擬簡報，並明確提供所需的摘要摘錄。
  3. 在 Codex 中開啟正確的 Git 專案。其審查窗格會顯示存放庫變更，其中可能包含您的編輯與其他工具的修改，而不僅是 Codex 上一次的回應。在請求審查前，請確認哪些內容屬於本次任務。
  4. 明確傳遞核對過的簡報。這可以是一段貼上的筆記，或是聽寫至聚焦文字輸入框的後續追蹤。Cue 的模型選取器不會為獨立的 Codex 任務選取執行階段，也不會為其授予存取權限。

採用此手動流程時，您不需要 Cue 到 Codex 的連接器。若改為選擇在 Cue 內部使用外部 Agent，請先驗證該路徑的連線、登入狀態、專案與權限。切勿假設它具備 Codex 桌面應用程式的功能表，或能自動接收先前的對話記錄。請參閱 搭配程式碼編寫 Agent 使用 Cue 以了解其差異。

在要求審查發現前選取確切 diff

針對 Codex 應用程式，OpenAI 的 程式碼審查文件 說明了輸入框中的 /review，並提供未提交變更或對照基礎分支進行審查的選項。審查窗格也區分了暫存（staged）、未暫存（unstaged）、commit、branch 以及 last-turn 等檢視。這些是 Codex 應用程式的控制項，而非 Cue 指令，其可用性取決於安裝的版本。

  • 未提交的工作：檢查暫存與未暫存的檔案。告知審查者哪些檔案屬於範圍內，哪些現有變更屬於其他人。切勿假設「last turn」涵蓋了您計劃發布的所有內容。
  • 分支變更：選取實際預期的基礎分支，而非看起來眼熟的名稱。若日後需要重現此審查，請記錄 base 與 head 的 commit ID。
  • 單一提交或提供的補丁：指明該 commit 或附加包含足夠周邊實作的補丁以供判讀。若僅貼方程式碼片段，請將該審查標記為僅限程式碼片段（snippet-only）。

若為自訂任務，請貼上後方的簡報，並針對該確切範圍要求唯讀審查。內建審查與自由格式提示詞屬於不同的入口；切勿假定在其他地方輸入的限制條件會自動附加至審查中。請檢查審查任務的上下文。切勿僅為了讓審查得以執行而關閉權限。

練習：在看似合理的微小補丁中找出迴歸問題

本虛構練習提供了一段極小的 diff 與行為約定。它可以作為純文字練習進行審查；這並非錄製的 Codex 執行歷程，也不需要正式環境存放庫的存取權限。

來源 R-01 — 約定：數值為零的計數必須顯示 0 results。null 與 undefined 代表缺失，且必須顯示 No count。正數計數必須維持可見。其他輸入驗證與單數文法不在此任務範圍內。

來源 R-02 — 於 result-label.mjs 中建議的 diff：

 export function resultLabel(count) {
-  return count ? `${count} results` : 'No count';
+  return count !== null ? `${count} results` : 'No count';
 }

來源 R-03 — 補丁作者的聲明：「這修復了零計數問題，並維持缺失值不變。」請將該語句視為待檢驗的聲明，而非測試已執行的證據。

提問：「請依據 R-01 審查 R-02。針對每個具體的迴歸問題，指出觸發條件、變更的運算式、實際與預期行為，以及能證明該問題的最小檢查。將未解答的問題分開列出。請勿實作修復。」

一項說明性發現為：「新增的條件排除了 null，但接受 undefined。使用 undefined 呼叫變更後的函式會產生 undefined results，而 R-01 要求的是 No count。運算式 count !== null 是相關的變更程式碼。請在零、null 與正數計數旁加入對 undefined 的檢查。」此結論源自所提供的 JavaScript；這並非宣稱 Codex 已發現或測試了該問題。

請注意這項發現並未虛構以下內容：受影響的客戶數量、正式環境中斷事故、未見存放庫中的行號或無關的安全性風險。在實際的 diff 上，請包含已驗證的檔案與行號範圍。在此程式碼片段上，指出確切的運算式比偽造原始碼位置更為誠實。

複製重點審查簡報

在傳送至 Codex 前，請替換括號中的欄位，包括確切的範圍。

任務：審查此項變更。請勿修改檔案或發布審查。
專案：[已確認的存放庫]
Diff 範圍：[未提交的檔案，或 base/head 的 commit ID]
預期行為：[變更必須達成的目標]
不變量（Invariants）：[必須保持不變的行為]
來源：[規格 ID、重現步驟、相關檔案或補丁]
優先級別：此範圍內的正確性與迴歸問題，而非風格整理。
針對每項發現請提供：
- 已驗證的檔案/行號或提供的確切運算式
- 觸發的輸入或使用者操作
- 實際與預期結果
- 來自變更及其呼叫路徑的佐證
- 最小重現或迴歸檢查
- 影響與不確定性，切勿捏造頻率或嚴重程度
將疑問與未經證實的假設放在獨立章節。
若某項檢查未曾執行，請如實說明。提議的測試並非測試佐證。
若無確認的發現，請說明範圍與殘餘風險。
切勿進行修復、commit、push、merge 或 deploy。請等待我的下一道指示。

將審查發現轉化為決策，而非毫無保留的核准

將每項發現與其原始碼並列閱讀。針對 R-02，檢查變更後的函式是否仍能處理零與 null，然後測試 undefined。關於未改動輔助函式的發現，應解釋該補丁如何呼叫至該處；否則它可能只是無關的待辦項目。冗長的報告並不一定是有用的審查。

以淺白語言為結果進行分類：

  • 已確認的迴歸：有約定及可重現案例支持。決定是否授權進行有範圍限制的修復，然後重新執行相關檢查。
  • 疑問：某項假設需要來源佐證，例如在實際應用程式中 undefined 是否能傳遞至該函式。請藉由呼叫路徑或規格說明來解決，而非憑藉審查者的信心。
  • 超出範圍：有益的清理作業可另行記錄。不應讓其悄悄擴大目前的補丁。
  • 無已確認的發現：受審查的範圍內沒有具體佐證的發現。這並非正確性證明、完整測試套件或安全性保證。

若您核准修復，請重申接受的發現與不變量。檢查新的 diff 與實際測試輸出，然後審查任何變更後的行為。切勿將原先的審查視為已涵蓋後續進行的修改。本機檢查通過並不證明正式環境成品已包含該變更。

若要進行獨立審查，請在補丁作者的解釋之前提供預期行為與確切程式碼。這能給審查者一個具體約定進行測試，而非一個去盲從同意的答案。若您需要完整的迴歸測試練習，請使用 Claude Code 小型修復教學。

在審查結果含糊不清時進行復原

Codex 審查了錯誤的檔案或基礎分支

停止操作，記錄實際審查了哪些內容，並選取正確的專案與範圍。針對預期的 diff 重新執行審查。切勿在未重新檢查的情況下將發現複製到不同的修訂版本。

審查者表示已執行測試但未提供輸出

要求提供實際的指令、結果與相關輸出。若無法提供，請將該項檢查標記為未驗證。透過您正常授權的環境執行有範圍限制的測試；切勿將建議的指令視為執行佐證。

我的審查請求導致了編輯行為

在採取進一步行動前，請先暫停並檢查工作樹（working tree）。保留無關的工作並審視被變更的內容。取消（Cancel）不等於還原（undo）。在繼續之前，請釐清唯讀範圍與權限。

對於由討論帶動的審查，請使用來源連結記錄上下文來保留決策及其注意事項。僅傳遞經授權的摘錄，而非整個私人會議或存放庫憑證檔案。

在 Cue 中親自試試

使用您設定的捷徑，並在 Cue Settings 中驗證作用中的模式。可用的應用程式上下文與操作取決於權限、版本與帳號。在提供機密資料前請先閱讀隱私權政策 (English)；本指南不保證所有處理程序皆保留在您的裝置上。

取得適用於電腦的 Cue · 目前方案 (English)

需要協助或發現錯誤？聯絡 Cue 支援團隊 (English)或傳送電子郵件至 eli@sophoninc.com。請附上您的 Cue 版本、平台、模式與經過去識別化處理的範例。請勿傳送密碼、權杖或私人會議資料。