OpenAI把提示詞壓縮了73%，程序員集體破防

去年有個數據挺有意思：Claude處理代碼任務時，平均每次對話要燒掉18.7萬token。按當時API價格算，一個中型項目從0到1，光提示詞成本就能吃掉小幾千塊。更扎心的是，其中四成token根本沒必要——全是被"請逐步思考""讓我們拆解這個問題"這類廢話吃掉的。

這事讓我想到一個老梗：有人花兩萬塊買跑步機，最后變成晾衣架。AI編程工具現在差不多就這處境。大家瘋狂堆上下文、塞示例、寫超長系統提示，token賬單膨脹得比代碼復雜度還快，產出質量卻沒跟著漲。

progressive disclosure（漸進式披露）這個詞，UX設計師聽了會點頭，程序員大多沒當回事。簡單說就是：別一次性把家底亮完，按場景分層給信息。放到AI編程里，它直接決定你的token效率是1:3還是1:10。

第一層：先給骨架，別給血肉

我見過最典型的反面教材，是某團隊給Claude寫的"全知全能"系統提示。5000字，涵蓋編碼規范、測試策略、安全準則、性能要求，外加12個完整代碼示例。結果？模型在簡單CRUD任務上瘋狂過度設計，復雜算法反而因為上下文被稀釋，輸出質量跳水。

Clean Code領域有個說法：變量只聲明一次，且永不修改的，應該設為常量。提示詞設計同理——信息只出現一次，且當前步驟用不到的，應該延遲披露。

具體做法是把提示詞拆成三層。第一層給任務類型和輸出格式，控制在200token以內。比如"生成Python單元測試，使用pytest，只返回代碼塊"。這層讓模型快速建立預期框架，避免在錯誤方向上浪費算力。

第二層是動態注入的上下文。當前文件結構、相關函數簽名、最近三次git提交信息——這些用工具實時抓取，而非寫死在提示詞里。某開源項目實測，這種按需加載把平均token消耗從14萬壓到3.8萬，響應速度提升40%。

第三層才是深度推理指令。但有個前提：只有當第二層輸出觸發特定條件時才喚醒。比如檢測到"涉及并發"或"包含正則表達式"，再追加專項約束。這種條件分支設計，讓簡單任務保持輕量，復雜任務獲得針對性加強。

第二層：用工具鏈替代口頭描述

很多程序員有個執念：總覺得把需求說得越細，AI理解越準。于是提示詞里塞滿"使用工廠模式""遵循SOLID原則""確保線程安全"這類抽象指令。token燒了，模型卻經常在具體實現上跑偏。

《Clean Code Cookbook》的作者提過一組數據：他在重構咨詢中見過的問題代碼，67%源于"意圖與實現脫節"。AI編程現在正重蹈覆轍——我們用自然語言描述架構意圖，卻期待模型精準還原技術細節。

漸進式披露的解法是反向操作。能用代碼表達的，絕不廢話；能用工具傳遞的，絕不手寫。函數簽名、類型定義、接口契約，直接以結構化數據喂給模型，而非用文字轉述。某AI代碼助手的產品經理透露，他們內部把API schema以JSON格式注入后，生成代碼的接口匹配率從71%提升到94%。

更激進的玩法是"可執行規格"。不寫"請實現一個帶緩存的HTTP客戶端"，而是直接提供：緩存策略的偽代碼、HTTP中間件的接口定義、以及兩個失敗測試用例。讓模型從"理解需求"變成"補全實現"，token效率提升3倍以上。

測試驅動開發（TDD）的老炮們應該覺得眼熟——這本質上就是把AI當成配對程序員，先寫測試再補代碼。區別只是測試用例現在成了提示詞的一部分。

第三層：對話狀態機的隱性優化

多輪對話是token黑洞的重災區。每次模型回復后，完整歷史上下文都要重新提交，成本指數級累積。某團隊做代碼審查助手，10輪對話后token消耗突破50萬，其中80%是重復的歷史信息。

漸進式披露在這里需要一點狀態機思維。把對話切割成獨立階段，每階段只保留必要的狀態摘要，而非完整歷史。比如代碼生成階段結束后，只向審查階段傳遞"功能描述+關鍵決策點"，具體實現細節歸檔到外部存儲。

更精細的做法是引入"記憶分層"。短期記憶（當前輪次）、工作記憶（本輪對話主題）、長期記憶（項目級約束），分別用不同機制管理。短期記憶全量保留，工作記憶壓縮為要點列表，長期記憶只在觸發關鍵詞時檢索注入。

有個開源項目叫Aider，做多文件代碼編輯。它的做法值得參考：每次編輯前，先讓模型生成"變更計劃"摘要，后續輪次只圍繞這個摘要展開。實測把多輪對話的token增長曲線從指數壓到線性，20輪后仍控制在初始消耗的2倍以內。

這種設計還有個隱性收益——模型注意力更集中。Anthropic的研究顯示，當上下文超過10萬token，模型對中間位置信息的召回率會斷崖下跌。精簡后的狀態摘要，反而讓關鍵指令更容易被"記住"。

成本結構正在重塑工具選擇

Token效率不只是省錢問題，它正在改變AI編程工具的競爭格局。Cursor最近更新了上下文壓縮算法，官方宣稱"同等質量下token消耗降低60%"。Devin則走了另一條路：把長任務拆解為多個子代理，每個代理只加載必要上下文，用 orchestration（編排）層協調。

更底層的變量是模型本身的上下文窗口。Claude 3.5 Sonnet把窗口擴展到20萬token，Gemini 1.5 Pro更是標稱1000萬。窗口變大似乎緩解了焦慮，但邊際收益在遞減——某評測顯示，超過5萬token的有效上下文，模型利用率不足30%。

這時候漸進式披露的價值反而凸顯。它不是應對窗口限制的權宜之計，而是提升信息密度的根本策略。就像好的代碼注釋不寫"做了什么"，而寫"為什么這么做"——提示詞也該從"盡可能全"轉向"盡可能準"。

《Clean Code》里有個觀點：代碼是寫給人看的，順便給機器執行。AI編程的提示詞設計，現在需要反過來——先讓機器高效執行，再考慮人的可讀性。畢竟token賬單不會騙人。

最后留個數據點：那位寫了500+技術文章的Clean Code布道者，最近在嘗試一種極端做法——所有提示詞控制在50詞以內，復雜需求全部拆解為工具調用鏈。他說早期很痛苦，像從散文改寫詩，但三周后"回不去了"。

你的提示詞平均多長？有沒有算過，其中多少比例真正影響了模型輸出？