Build Hour：用 GPT-5.6 做 Valuemaxxing（價值最大化）（第 2/5 段） ☕ Buy me a coffee

🧑‍🏫 這段講兩件事。第一，用 Codeex 寫程式時，怎麼調設定才不會白白浪費錢和時間。第二，用 OpenAI API 做產品的人，可以用哪些新功能省 token。講者也實際跑了測試、比較數字，很適合覺得「AI 好用但好貴」的人。

• 10:54 Demo 比較不同推理層級：模型越進階，難度與複雜度差異越明顯。以 Luna 為例，第一個結果有點粗糙，加入更多邏輯推理後，最終結果相當好
  ↳ Demo 把同一個任務用不同 reasoning level（推理強度，想越多越周全也越耗資源）各跑一次。越進階的模型差距越明顯：Luna 第一版很粗糙，多推理後好很多。
• 11:24 Soul 一開始的準確度就相當高，隨著推理增加會變得更強
  ↳ Soul 就算推理開得不高，成果已經不錯；推理往上加還會更好。代表起點高的模型，不必一開始就開到最滿。
• 11:24 講者強調要有自己的 benchmark 和評估方式來衡量，好的產品應該要具備這些。這個 demo 只是讓大家快速看一下
  ↳ 這個 demo 只是讓你看個感覺。真要選設定，得有自己的 benchmark（固定的測試題加評分方式），拿自己的工作來量，不要只看別人的 demo 下結論。
• 11:56 結果對比：第一張幾乎沒有陰影；後面的版本加上了綠色島嶼、更大更細緻的浪，以及背景太陽和雲的陰影
  ↳ 差別看得出來：第一張幾乎沒陰影；推理加多後，多了綠色小島、更大更細的浪，太陽和雲也有陰影。模型想多一點，細節就多出來。
• 12:26 Codeex 實用技巧一：從 Soul 開始，而且從中等（intermediate）推理層級開始
  ↳ 第一招：Codeex 先用 Soul，推理強度選中等。這是比較划算的起點，不夠再調。
• 12:26 講者想破除一個迷思：很多開發者以為什麼都要一次開到最高層級。最高層級確實適合複雜的工作負載與專案
  ↳ 很多人以為開最高最保險。其實最高層級是給真正複雜的大專案用的；平常小事也開最高，等於多花錢又多等時間。
• 12:56 很多日常任務用中等層級的 5.6 Soul 就夠了。如果模型不夠聰明或不夠周全，再往上調
  ↳ 日常任務用 5.6 Soul 中等就夠。發現它想得不夠深、漏東漏西，再往上調一格，讓結果決定要不要加。
• 12:56 有些情況甚至可以往下調成輕量推理；如果工作不需要大量寫程式，也可以改用 5.6 Terra
  ↳ 反過來也行：簡單的事可以降成輕量推理；如果工作主要不是寫程式，可以換成 5.6 Terra。
• 13:26 技巧二：想清楚什麼時候值得用 token 換時間，也就是多花 token 來節省自己的時間
  ↳ 第二招：token 是模型計算用量的單位，用越多花越多。有時多花一點 token，換來自己少等一點，是划算的。重點是想清楚什麼時候值得。
• 13:26 Fast mode 是最明顯的用法：開啟後速度快 1.5 倍，但使用額度會消耗得比較快
  ↳ Fast mode（快速模式）是最直接的例子：開了速度快 1.5 倍，但使用額度會燒得比較快。趕時間時開，不趕就不用。
• 13:26 官方強烈建議把自動核准（automatic approval）設為預設模式；目前不建議在 Codeex 使用 full access
  ↳ 建議把 automatic approval（自動核准，由另一個模型幫你審動作）設成預設。full access（完全放手讓它做任何事）目前不建議在 Codeex 用。
• 13:56 每個動作都要求權限有點煩人。自動核准是很好的折衷：由另一個模型檢查，確保動作安全
  ↳ 每一步都跳出來問「可以嗎？」很煩，全部放行又危險。自動核准介於中間：交給另一個模型把關，確認安全才放行。
• 13:56 Chronicle 是 Codeex 較新的功能。開啟後可以錄製螢幕，並為你正在做的任務建立記憶
  ↳ Chronicle 是 Codeex 較新的功能：開啟後會錄你的螢幕，替你正在做的事建立記憶，讓它記得你之前在忙什麼。
• 14:26 使用 Chronicle 重複做類似任務時，會多用一些 token 來記住脈絡，但模型會越來越了解你每天的工作
  ↳ 代價是要多花一些 token 記住前因後果。好處是常做類似工作時，它會越來越懂你每天在做什麼，你不用每次從頭交代。
• 14:26 技巧三：重新檢視 agents.md 和 skills。模型變聰明了，6 或 12 個月前寫的很多指示現在可能已經不需要
  ↳ 第三招：agents.md 是寫給模型的固定指示檔，skills 也是給模型的做事說明。模型變聰明了，半年到一年前寫的叮嚀可能已經多餘。
• 14:56 檢查是否真的需要把每件事都寫得很詳細，或能精簡一點來節省 input tokens
  ↳ 這些指示每次都會送進模型，算在 input tokens（送進模型的量）裡。寫越長越貴，所以能刪就刪、能短就短。
• 14:56 接著談：如果產品建立在 OpenAI API 上，如何把價值最大化，並介紹幾個近期推出的 API 功能
  ↳ 接著換對象：不是用 Codeex 的人，而是透過 OpenAI API（讓自己的程式直接呼叫模型的管道）做產品的人。講者介紹幾個新功能怎麼幫他們省。
• 15:26 Programmatic tool calling 隨 5.6 推出：給模型一個 JavaScript sandbox，讓模型寫程式在裡面執行
  ↳ Programmatic tool calling（程式化工具呼叫）隨 5.6 推出：給模型一個 JavaScript sandbox（專門讓它跑程式的隔離空間），模型寫程式丟進去執行。
• 15:56 sandbox 裡的程式可以呼叫工具或做計算，把原本在模型思考鏈裡的工作移到 sandbox，模型不必自己算數學、跑邏輯，因此省 token
  ↳ 以前算數、跑邏輯都要模型在 chain of thought（模型的推理過程）裡自己想，很耗 token。現在交給程式去算，模型只負責寫程式，就省下來了。
• 15:56 還可能省時間：可以連續多次呼叫工具，不用每次都回到模型和終端使用者
  ↳ 也省時間：程式可以一口氣連續呼叫好幾個工具，不用每呼叫一次就回到模型重想，也不用回頭問使用者。
• 15:56 Prompt caching 在 5.6 推出後有調整：現在可以指定 prompt 裡哪些部分要被快取，能同時省時間和 token
  ↳ Prompt caching（提示快取）是把每次都一樣的那段 prompt 存起來重複使用。5.6 之後可以自己指定哪幾段要快取，省時間也省 token。
• 16:26 範例：產品需要知道今天日期時，應該把日期放在 prompt 最後面
  ↳ 例子：產品需要讓模型知道今天日期時，要把日期放在 prompt 最後面，不要放開頭。
• 16:56 假設有 10,000 tokens 的 prompt，日期放開頭會很難快取；放最後的話，不變的部分都能快取，省下很多時間
  ↳ 日期每天都會變。放在開頭，整段約 10,000 tokens 的 prompt 都很難快取；放在最後，前面不變的部分都能沿用，省下很多時間。
• 16:56 Sustained reasoning：以前 API 只有推理摘要，或只合併最終 assistant 訊息；現在可以保存推理步驟
  ↳ Sustained reasoning（保留推理）：以前 API 只給推理摘要，或只留下模型最後的回答。現在可以把中間的推理步驟保存下來。
• 17:26 Sustained reasoning 能提升回應一致性、效能與能力，也提升快取效率；持續送出全部內容時，快取效果更好
  ↳ 保留推理後，模型前後回答更一致、表現更好，快取也更有效。每次都把完整內容送出時，快取的效果會更好。
• 17:26 壓縮（compactness）功能已經推出一段時間，適合有大量長而複雜的查詢、很多工具呼叫，或很多最後沒用的冗餘動作的情境
  ↳ 壓縮（compactness）適合這些情況：問題又長又複雜、呼叫了很多工具，或做了一堆最後沒用上的動作，累積了很多用不到的內容。
• 17:56 可以開啟自動壓縮，或自己透過 API 手動觸發壓縮，減少每次送出的輸入資料量
  ↳ 可以開自動壓縮，也可以自己透過 API 手動觸發。把累積的內容壓縮後，每次送進模型的資料變少，就省錢。
• 18:26 回到 demo：很多 pandas 流程已經跑完，各結果的寫實度和準確度不一。接著進入 optimization lab 的第三個分頁
  ↳ 回到 demo：那批 pandas（Python 處理表格資料的工具）流程跑完了，各結果的寫實度和準確度不一。接著打開 optimization lab 的第三個分頁。
• 18:56 針對剛才介紹的功能做 A/B 測試。第一個是快取：用約 5.5k tokens 的 prompt，比較有快取和沒快取的兩次 API 請求
  ↳ 開始做 A/B 測試，也就是同一件事「用」跟「不用」某功能各跑一次來比。先測快取：同一個約 5.5k tokens 的 prompt，比較有快取和沒快取。
• 19:26 使用快取後，input 成本下降 90%，等待時間減少了幾秒
  ↳ 有快取的那次，input 成本少了 90%，等待時間也少了幾秒。
• 19:26 如果不需要極低延遲、會經常重複使用查詢，而且有大型 system prompt，快取是很好的省錢方法
  ↳ 適合用快取的情況：不需要極低的 latency（等回應的時間）、常重複問類似的問題，而且 system prompt（固定給模型的背景設定）很長。
• 19:57 第二個測試是 programmatic tool calling：prompt 要求列出帳戶清單、追蹤用量，然後向客服建立 ticket
  ↳ 第二個測程式化工具呼叫。題目是：列出帳戶清單、追蹤用量，再向客服開一張 ticket（服務單）。
• 19:57 一般做法：模型呼叫工具，結果回傳給模型，模型決定下一步，可能再呼叫更多工具，最後產生回應
  ↳ 一般做法是一來一回：模型呼叫工具、結果傳回模型、模型想下一步、可能再呼叫工具，最後才回答。每一輪都要經過模型。
• 20:27 用 programmatic tool calling 時：模型寫程式，由 sandbox 呼叫工具並處理數字，回傳最終結果，再由模型決定如何回應
  ↳ 新做法：模型一次寫好程式，讓 sandbox 去呼叫工具、處理數字，算完只把最終結果交回來，模型再決定怎麼回答。
• 20:27 結果：input tokens 少了 24%，看起來透過 sandbox 省下了模型的一整個步驟
  ↳ 結果 input tokens 少了 24%。看起來是 sandbox 幫模型省掉了中間一整輪。
• 20:57 講者提醒這有點像玩具範例，自己測試時一定要用真實案例
  ↳ 講者也提醒，這是簡化過的玩具例子。數字只能參考，要不要用，得拿你真實的工作案例來測。
• 20:57 不只省 input tokens，output tokens 也省了，因為模型對最終答案需要思考的比較少
  ↳ 不只 input tokens 省了，output tokens（模型產出的量）也省了，因為計算交給程式，模型最後要想的就變少了。
• 20:57 也可以檢查：改變背後的查詢後結果是否相同。這次結果一致，正是想要看到的
  ↳ 省錢之外還要確認品質：改變背後的查詢後再跑，兩種做法的結果一樣。這正是想看到的，省了成本，答案沒變。
• 21:28 最後是 context 壓縮的測試：這個案例約有 72 個先前的步驟，準備比較直接提問與先壓縮再提問的差別（本段到此結束）
  ↳ 最後測 context（模型當下讀得到的前文）壓縮：一個已累積約 72 個步驟的案例，要比較直接提問和先壓縮再提問的差別。結果在下一段。

在 prompt caching 的 A/B 測試中，使用快取後 input 成本下降了多少？