為什么代碼任務要先**再修改
代碼項目中的一個問題，往往涉及入口、依賴、配置、測試和運行環境。直接讓 Codex 修改，可能會讓它只看到表面報錯，卻忽略真正的調用鏈。先**可以確認問題范圍，也能讓你知道模型實際讀取了哪些文件。
- 閱讀：確認入口、依賴和相關文件。
- **：指出風險、重復邏輯和潛在回歸。
- 方案：列出準備修改的文件和步驟。
- 執行：只修改已經確認的范圍。
- 測試：運行局部測試并說明結果。
第一步：選擇適合代碼**的模型
進入靈能API頁面或控制臺，查看當前模型列表、Model ID、輸入輸出價格和上下文信息。代碼**通常會帶入文件內容和歷史上下文，因此要關注模型的代碼理解能力和長內容穩定性。
官網入口：https://www.lnsns.com/。模型和價格以當天頁面信息為準。
- 單文件**：優先速度和基礎理解能力。
- 跨文件分析：優先上下文容量和依賴理解。
- 復雜修改：優先穩定性和測試配合能力。
第二步：為項目**建立獨立令牌
代碼**可能會持續多輪，并消耗較多輸入上下文。建議為項目**建立獨立令牌，名稱寫清設備和項目用途。這樣可以區分日常問答、項目**和實驗調用，也便于異常時單獨停用。
- 令牌名稱：Codex-Review-Project。
- 完整 Key：只保存在本地私密位置。
- 共享截圖：只展示字段位置，不展示真實密鑰。
? 第三步：在 CC Switch 中建立**線路
打開 CC Switch 的 Codex 配置頁面，創建“靈能API-Codex-代碼**”配置卡。不要直接覆蓋日常主線路，**卡片可以單獨指定模型和令牌。
創建后檢查協議、*ase **L、Model ID 和 API Key。*ase **L 通常填寫到 /v1，Model ID 從當前模型列表復制。復制已有配置卡后仍要逐項核對。
?? **步：先讓 Codex 只讀**
請只閱讀 src/service.ts。
列出入口、外部依賴、異常處理和潛在風險。
不要修改文件，不要執行命令，不要讀取其他目錄。第一輪**的目標不是立即得到修改代碼，而是確認 Codex 是否理解了文件職責。若它讀取了不應讀取的文件，先縮小范圍，不要繼續下一階段。
**結果可以要求固定格式：問題位置、問題類型、影響范圍、建議優先級和是否需要測試。結構化輸出更容易人工復核。
第五步：讓模型先寫修改方案
確認**結果后，再讓 Codex 給出修改方案。方案至少要說明準備修改哪些文件、為什么修改、可能影響什么、準備運行哪些測試。方案階段仍然不要直接寫入。
請基于剛才的**結果給出修改方案。
只允許涉及 src/service.ts 和對應測試文件。
先列步驟、風險和驗證命令，不要修改文件。- 文件范圍是否準確。
- 方案是否解決了**中的根因。
- 是否包含兼容性和回歸風險。
- 測試命令是否能在當前項目中執行。
? 第六步：修改前檢查版本控制狀態
確認方案后，先檢查項目當前狀態。確保已有改動不會被混入本次任務，必要時先提交或建立臨時分支。
cd D:\work\your-project
git status
git diff --stat然后讓 Codex 只執行已確認的文件修改。修改完成后先查看 diff，不要馬上讓它繼續擴大范圍。
第七步：先測試，再決定是否繼續
切換配置后關閉舊的 Codex 和 PowerShell，重新啟動新進程。進入項目前，可以在空目錄做一條只讀任務確認線路；進入項目后，優先運行與本次修改直接相關的局部測試。
npm test -- --runIn*and
# 或使用項目已有的局部測試命令測試失敗時，先讓 Codex 解釋失敗原因和涉及文件，不要立即允許它大范圍修復。一個好的驗收結果應包含修改文件、測試命令、測試結果和剩余風險。
代碼**中常見的線路問題
排錯時保留卡片名、錯誤碼和任務階段，不記錄完整 API Key 和項目敏感內容。
- 401：**卡片的令牌無效或沒有啟用正確線路。
- 403：檢查額度、模型權限和令牌分組。
- 404：檢查 *ase **L 是否重復 /v1。
- model not found：重新復制當前 Model ID。
- 回答突然變短：檢查上下文范圍和模型卡片是否切換。
- 修改范圍擴大：重新指定允許修改的文件并結束當前計劃。
代碼**驗收清單
把**、方案、修改和測試分開，Codex 才更容易成為可檢查的協作工具，而不是一次性黑盒修改器。
- 模型和項目任務規模匹配。
- **線路使用獨立配置卡。
- 第一輪只讀，第二輪給方案，第三輪才修改。
- 修改前檢查 Git 狀態和 diff。
- 修改后運行局部測試并查看結果。
- API Key 沒有出現在提示詞、截圖和倉庫。