影片筆記：Codex 額度總是不夠？零基礎先學這4個進階技巧｜含多案例實操

一句話總結

針對 AI 工具（如 Codex、Cloud Code）因成本壓力導致 Token 消耗快、額度緊張甚至封號的現狀，影片提出四大技巧：利用免費工具預處理提示詞、透過 agents.md 建立任務關卡、管理上下文以避免污染與計費風險，以及建立文件索引機制，旨在節省 Token 並提升協作效率。

核心重點

1. 背景與計費邏輯：AI 廠商因資本壓力縮減額度，終端用戶需承擔高昂算力成本。Token 是計量單位，歷史對話會累積計算，導致後續對話 Token 消耗呈指數級增長。
2. 節省 Token 三原則：降低單輪對話成本、減少對話總輪次、單位時間內提升對話頻次。
3. 技巧一：多渠道預處理：利用 ChatGPT、Gemini、Notebook LM 等免費工具進行資料預處理與大綱提煉，再將精確提示詞與文件掛載至 Codex 執行，避免直接丟入大量資料導致 Token 爆表且質量雜亂。
4. 技巧二：agents.md 三道關卡：透過 agents.md 或自定義指令設定工作邊界。包含蘇格拉底式提問（明確目標）、第一性原理（構建項目/拆解變量）、奧卡姆剃刀（去除噪音）。實證顯示可降低運行時間與 Token 消耗。
5. 技巧三：上下文管理：避免在同一窗口不斷新增任務導致「上下文污染」。任務結束後應讓 AI 總結結果（類似工作交接），隨後使用 /new 開啟新對話，僅提供新任務目標與必要約束，以利用系統緩存降低計費。
6. 技巧四：文件索引機制：針對分散文件，使用 Plan 計劃模式要求 AI 提取標題與元數據生成索引清單與摘要卡，不讀取正文，以低 Token 消耗實現高效檢索與數據安全。

詳細大綱

一、 背景與核心原則

• 現狀觀察：
• 近期 AI 廠商（Codex、Cloud Code）出現大面積封號、額度縮減現象。
• 資本施壓與高昂電能/算力成本，最終由終端用戶承擔（Token 消耗快）。
• 計費與 Token 基礎：
• 計費模式分為「輸入」（提示詞、文件、上下文）與「輸出」（圖片、代碼、文案）。
• Token 是 AI 讀寫文字的計量單位（1 Token 約等於 1-2 個中文字符）。
• 歷史對話會累積計算，導致後續對話 Token 消耗呈指數級增長。
• 節省 Token 三原則：

1. 降低單輪對話的成本。
2. 減少對話的總輪次。
3. 單位時間內提升對話的頻次。

二、 技巧一：多渠道利用 AI 優勢（提示詞預處理）

• 核心概念：除了主用工具（Codex/Cloud Code），應利用 ChatGPT、Gemini、Notebook LM 等免費工具進行資料預處理。
• 操作步驟：

1. 資料預處理：將大量文檔、截圖、報告丟入 Notebook LM 等工具。
2. 提煉大綱：要求 AI 基於材料提煉 PPT 大綱或簡報結構。
3. 生成提示詞：讓 AI 根據大綱和模板，生成一段可在 Codex 中直接使用的精確提示詞。
4. 執行生成：將精確提示詞與項目文件掛載至 Codex 進行最終生成。

• 對比效果：
• 直接丟資料：Token 消耗極高（單窗口用掉 83%），生成內容雜亂、不符合模板、無法直接使用。
• 預處理後：生成內容貼合模板（約 80 分水平），節省 Token 且質量可控。

三、 技巧二：利用 agents.md 為任務建設三道關卡

• 核心概念：通過 agents.md 或項目自定義指令，為 AI 設定工作邊界與流程，類似為每個工作節點安排專家。
• 實證數據：
• 在 124 個 PR 的對照實驗中，使用 agents.md 後，運行時間下降 29%，Token 消耗下降 17%。
• 三道關卡操作法：

1. 蘇格拉底式提問（明確目標）：

• 引導 AI 提問：任務目標、輸出範圍、排除內容。
• 目的：理清思路，以最短路徑接近目標。

1. 第一性原理（構建項目）：

• 將任務拆解至最底層，識別核心變量。
• 例如：產品分析是為老闆判斷市場進入（關注商業模式/風險），還是為產品團隊決定功能優先級（關注功能差異/用戶路徑）。

1. 奧卡姆剃刀（去除噪音）：

• 砍掉重複新聞、無來源觀點、情緒化表達等非核心數據。
• 避免 AI 將噪音誤認為重點。
• 設置方式：在 Codex 左下角設置的「個性化」或 ChatGPT 項目設置中的「指令框」中複製相關內容。

四、 技巧三：做好上下文管理（避免上下文污染）

• 問題描述：在同一個對話窗口（繪畫）中不斷新增任務，導致舊報錯、舊方案堆積，產生「上下文污染」。
• 操作流程：

1. 任務總結與交接：任務結束後，讓 AI 總結結果，生成類似「同事離職工作交接文檔」的內容，提供背景與規則參考。
2. 開啟新對話：使用斜杠命令（如 /new）開啟新繪畫。

• 新繪畫不延續上一輪任務目標與執行狀態，但保留長期規則、當前工作目錄與權限。

1. 僅提供必要信息：在新任務中，只輸入新任務目標、約束驗收標準及上一任務的有效結論。

• 計費機制解釋：
• 緩存輸入：系統緩存可複用的長提示詞前綴（如系統角色、項目規則），首次輸入按普通 Input 計費。
• 緩存命中：後續對話若匹配前綴，按較低的「緩存命中」計費。
• 風險：若頻繁修改或未定義前置條件，系統無法匹配緩存，將不斷按普通 Input 計費，導致 Token 流失。

五、 技巧四：整理雜亂文件並建立自動索引機制

• 問題描述：工作文件分散在本地、郵件、雲盤，長期雜亂導致檢索困難且消耗大量 Token。
• 操作步驟：

1. 選擇對象：確定要整理的項目對象。
2. Plan 計劃模式：使用特定提示詞，要求 AI 對文件進行全面「提建」（提取標題/元數據），但不讀取正文。
3. 輸出索引清單：生成文件清單、目錄地圖、重要文件摘要卡及未來檢索規則。

• 優勢：
• 低 Token 消耗。
• 不刪除、修改或移動原始文件內容，確保數據安全。
• 清晰標註文件位置與修改時間，方便後續確認與引用。

工具 / 模型 / 名詞整理

• AI 工具/平台：
• Codex
• Cloud Code
• ChatGPT
• Gemini
• Notebook LM
• 功能/文件名稱：
• agents.md
• Plan 計劃模式
• 斜杠命令（如 /new）
• 自定義指令 / 項目自定義指令
• PR (Pull Request)
• PPT 簡報 / 幻燈片
• 工作交接文檔
• 索引目錄 / 目錄地圖 / 摘要卡

操作流程整理

流程一：提示詞預處理與生成

1. 將大量文檔、截圖、報告輸入至 Notebook LM 等免費工具。
2. 要求 AI 基於材料提煉 PPT 大綱或簡報結構。
3. 讓 AI 根據大綱和模板，生成一段精確的提示詞。
4. 將精確提示詞與項目文件掛載至 Codex 進行最終生成。

流程二：設定 agents.md 任務關卡

1. 在 Codex 左下角「個性化」或 ChatGPT 項目設置的「指令框」中，複製並設置 agents.md 內容。
2. 執行任務時，AI 會依序進行：

• 蘇格拉底式提問：確認任務目標、輸出範圍、排除內容。
• 第一性原理拆解：識別核心變量（如商業模式或功能差異）。
• 奧卡姆剃刀過濾：去除重複新聞、無來源觀點、情緒化表達等噪音。

流程三：上下文管理與新對話建立

1. 當前任務結束後，要求 AI 總結結果，生成類似「同事離職工作交接文檔」的內容（包含背景與規則）。
2. 使用斜杠命令（如 /new）開啟新對話窗口。
3. 在新對話中，僅輸入新任務目標、約束驗收標準及上一任務的有效結論。
4. 確保前置條件定義清晰，以利用系統緩存降低計費。

流程四：文件索引建立

1. 確定要整理的項目對象（分散在本地、郵件、雲盤的文件）。
2. 使用 Plan 計劃模式提示詞，要求 AI 對文件進行「提建」（提取標題/元數據），不讀取正文。
3. 獲取生成的文件清單、目錄地圖、重要文件摘要卡及未來檢索規則。

值得注意的限制或風險

• Token 累積風險：歷史對話會累積計算，若不在同一窗口進行上下文管理，後續對話 Token 消耗會呈指數級增長。
• 緩存失效風險：若頻繁修改提示詞或未定義前置條件，系統無法匹配緩存，將不斷按普通 Input 計費，導致 Token 流失。
• 直接丟資料的低效：直接將大量資料丟入主用工具（如 Codex）會導致單窗口 Token 消耗極高（例如用掉 83%），且生成內容雜亂、不符合模板、無法直接使用。
• 噪音干擾：若未透過 agents.md 去除噪音，AI 可能將重複新聞、無來源觀點或情緒化表達誤認為重點。

逐字稿辨識疑點

• 金金白銀：疑點，聽似「真金白銀」或「花了不少錢」的口誤或聽寫錯誤。
• 條 D Plus 黨額度：疑點，聽似特定產品名稱或套餐名稱（如 "Plus" 相關套餐），但具體名稱需查證。
• 寄費模式：疑點，聽似「計費模式」的聽寫錯誤。
• 幻動片：疑點，聽似「幻燈片」或「PPT」的聽寫錯誤。
• 瑕不言語：疑點，聽似「瑕不掩瑜」的聽寫錯誤。
• 百勝加金：疑點，聽似「百勝加緊」或形容工作繁重的成語誤用，需查證原意。
• 構簽項目：疑點，聽似「構建項目」的聽寫錯誤。
• 淨品分析：疑點，聽似「競品分析」或「產品分析」的聽寫錯誤。
• 院里：疑點，聽似「原理」的聽寫錯誤（奧卡姆剃刀原理）。
• 擊費：疑點，聽似「計費」的聽寫錯誤。
• 消失去：疑點，聽似「消耗去」或「消耗掉」的聽寫錯誤。
• 志川：疑點，講者自稱，需確認是否為正確人名或暱稱。

可延伸追問

• 如何具體撰寫 agents.md 的內容以適應不同類型的專案？
• 在 Codex 中，「緩存命中」的具體計費標準與普通 Input 的差異比例為何？
• 對於非編程背景的用戶，如何更有效地使用 Notebook LM 進行資料預處理？
• 當文件數量極大時，Plan 計劃模式的處理時間與 Token 消耗是否會增加？是否有最佳實踐？
• 如何判斷一個任務是否適合使用「蘇格拉底式提問」與「第一性原理」的組合？