用量與效率：減少重工

返回 Codex 教學總目錄

目標與準備

本段提到的教學與資源: 練習包 · 帳號用量

步驟 1：先確認自己量的是什麼

ChatGPT／Codex 的方案額度與 API 金額是不同指標。介面顯示的可用比例可能是整個帳號共享視窗，會受其他任務、重置時間及方案影響；不能把前後差一個百分點當成這個任務的精確價格。API 的 token 與費用也要依當時模型、計價及實際 usage 紀錄核對，不把 CLI 印出的所有 token 直接乘單一單價。本文把模型與價格連回集中維護的帳號／模型篇，不重複固定可能改變的數字。

若無資料填 unavailable，若只是估計寫 estimated，並說明方法；不要用 0 代替沒有資訊。

步驟 2：固定比較條件與正確答案

兩個資料夾都用相同 broken 原版，不在其中一份先修程式。各執行一次 node --test core.test.mjs，確認同樣是原三項中兩項通過、一項失敗；這個測試只用 Node，不消耗模型額度。缺陷是 visibleTasks 在 completed 分支仍挑選 !task.completed。自己先記住這個基準，但不把正確修法直接寫入待比較的提示詞。A、B 都要提出修正計畫，不實際修改或啟動服務。

在同一入口、同一台主機各開一個新任務，A 指向 efficiency-a，B 指向 efficiency-b，使用同一模型與推理深度；若帳號沒有某個選項，就記錄目前預設，不猜型號。兩次依序執行，避免同時使用造成等待互相影響。新任務能減少對話答案互相污染，但快取、網路、服務負載仍不完全相同，因此這是自己的流程練習，不是可發表的模型效能排名。

步驟 3：只改提示詞的具體程度

A 是資訊較少但仍有目標的請求；B 加入可重現輸入、預期／實際與檔案範圍。兩者的最終目標相同，不同的是你提前提供多少可靠背景。記下各自撰寫提示詞花的時間，再送出一次。若代理追問，正常回答並計入補充次數；不為了讓 B 勝出而拒絕提供 A 所需要的資訊。

Find why Completed shows unfinished tasks in this project.
Explain the cause, propose the smallest fix and give verification steps.
Read only; do not edit files, run tests or start services.

Investigate the Completed filter in this Small Steps practice copy.
Reproduction: add Read and Build, complete Read, then choose Completed.
Expected: only Read. Actual: only Build.
Inspect core.mjs, app.js and core.test.mjs as needed.
Explain the cause, propose the smallest fix while preserving Active/All behavior,
and give exact Node and browser verification steps.
Read only; do not edit files, run tests or start services.

步驟 4：用同一把尺驗收兩個結果

四項都要人工核對：是否定位 visibleTasks 的 completed 條件；是否建議只讓 completed 分支保留 task.completed 為真的資料；是否保留 Active／All 行為；是否提出 node --test core.test.mjs 及同一個 Read／Build 畫面重現。額外檢查它沒有聲稱已執行你禁止的測試，也沒有修改檔案。多寫一頁泛泛的風險清單不會加分，短答案若缺少驗證也不算完成。

# Workflow comparison
Date / host / surface / CLI or app version:
Model and reasoning setting:
Fixture: unchanged broken copy

| Metric | A | B |
| --- | --- | --- |
| Prompt preparation time | | |
| Wait until final answer | | |
| Human verification time | | |
| Clarification/correction turns | | |
| Accepted criteria out of 4 | | |
| Actual visible usage, or unavailable | | |
| Files unchanged | | |
| Remaining uncertainty | | |

Decision and evidence:
One adjustment to try next:

步驟 5：把結果變成可持續的習慣

比較人的準備＋驗證時間、等待與重工，而非只看最快的回答。B 若讓準備多花兩分鐘卻省下多次追問，可能適合日常流程；若 A 也能一次完整通過，就沒有證據說每個小任務都要寫長文件。將有效的重現格式存到可複用範本，保留目標、來源、範圍與驗收即可，不把整段聊天歷史全部貼回每次任務。這能減少過期背景與相互矛盾的條件。

用一個明確虛構的算例練習判讀：A 準備 1 分鐘、等待 3 分鐘、驗證 4 分鐘，四項只符合三項；B 準備 3 分鐘、等待 4 分鐘、驗證 1 分鐘，四項皆符合。兩者已記錄時間合計都是 8 分鐘，B 的首次等待較長但交付較完整；A 的補救時間尚未量到，所以不能宣稱兩個完整工作同樣快。這不是任何模型的效能數據。

判讀時再問：四項是不是事先訂好、品質是否真的核對、未提供用量是否留 unavailable。若兩者都符合四項，才比較完整操作時間與重工。將上面的虛構數字和自己的觀測表分開；下一輪沿用同一份評分條件，一次只調整一個因素，才有辦法解釋變化來源。

下一輪若要比較模型或推理深度，先固定已驗收的 B 提示詞與同一輸入，再只改一項可用設定，依模型選擇的方法記錄。不要同時換模型、增加子代理、改提示詞再把差異全部歸因於速度。大量平行工作與長時間重試也會產生用量；對單一小問題先把目標縮小通常比增加工具更容易驗證。需要長任務時用交接紀錄保存已驗證狀態，避免下一次重做全部探索。

完成與常見誤判

兩份副本應仍未改動，保存觀察表及兩次回答；若代理擅自修改，記錄為範圍失敗，先保存差異再還原自己的副本。一次比較只能支持本次條件下的選擇，不能推論某模型永久較省、某方案固定能做多少任務。額度畫面沒有更新、重置發生或其他任務同時使用時，該欄寫不可比較。完成標準是四項品質判斷有依據、時間有方法、未知用量沒有假數字，並選定下一個最小調整；不是讓統計看起來全部進步。

返回 Codex 教學總目錄

閱讀完整文字說明

Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.

• AI 工具
• 教學
• Codex