你的程式碼 Agent 正在用頂級模型的價格，去回答選擇題。
我該載入哪些筆記？這一步該交給大模型還是小模型？工具剛報錯了，要重試、修復還是放棄？哪些測試該先跑？
以上每一個問題，都只有四到五個可能的答案。但在目前大多數的 Agent 架構中，這些問題全都會丟給你最貴的模型來回答——還得開啟思考模式、讀完所有上下文、在真正執行前先生成一大段文字。
這就是漏錢的地方。
這篇文章會教你怎麼堵住它。Opus 5.5 負責困難的推理：規劃、寫程式、除錯。Jev 則接手幾乎每一步都會發生的那四個決策。而你的主控程式（harness）負責準備選項、檢查答案，並做出最終決定。
在下面的實際範例中，開發一個功能的 session 成本從 $6.42 降到 $2.00。整整便宜了 69%，而且文章裡列出了每一行計算過程，讓你可以直接套用自己的數字來驗證。
這篇文章是寫給任何在真實工作環境中運行程式碼 Agent 的人：無論你用的是 Claude Code、自己透過 API 搭建的主控程式，或是介於兩者之間的任何方案。你不需要重寫你的 Agent。文章裡的每個元件都能以「函式呼叫」的形式插入現有迴圈中，並附上一個開關讓你隨時停用。如果你看過我那篇 Jev + Claude Code 的文章，這篇就是升級版：概念相同，但用了更新的推理模型，並且把通用原則具體化為四個明確的決策點。
你需要一把 Jev API 金鑰、一把 Anthropic API 金鑰，以及大約一週的自家 Agent 日誌作為對照基準。
我們開始動手吧。
opus 負責推理，jev 負責決策。
問題所在：一個模型做兩份工作
觀察一個程式碼 Agent 工作十分鐘，你會發現它在做兩種截然不同的事。
第一種工作是推理。 規劃功能、撰寫函式、閱讀堆疊追蹤（stack trace）並找出日期解析器為什麼在閏年會壞掉。這類工作是開放式的，答案不在清單上。在這裡，你會想用負擔得起的最聰明模型，而 Opus 5.5 非常擅長這件事。
第二種工作是決策。 從四十條專案筆記中挑出三條相關的；判斷某個重新命名可以交給便宜的模型；決定 npm test 超時後該怎麼做；在完整跑完 1,400 個測試檔之前，先挑哪 12 個來跑。這些問題的答案都在清單上，清單很短，而且你的程式碼可以直接根據答案採取行動。
大多數 Agent 都用同一個模型處理這兩種工作，因為這是預設做法。迴圈呼叫 Opus，Opus 思考，Opus 回答，迴圈繼續。
這樣確實行得通。但它既慢又貴，而且這種代價很容易被忽略，因為單看一次決策呼叫並不覺得花錢。一次「我需要哪些筆記」的呼叫可能只要一分錢。但它每一步都會發生，而且每次都帶著完整的上下文。
還有第二個更容易被忽略的成本：當 Agent 無法決定要載入什麼時，它就會全部載入。每一條專案筆記、每一份規範文件、每一次歷史決策，全都塞進每次呼叫裡。Opus 5.5 已經把快取讀取壓到每百萬 token $0.20 的便宜價格，但「便宜 × 六十步 × 你整個筆記資料夾」加起來依然可觀。
解法：Opus 推理、Jev 決策、你的主控程式掌舵
Jev 是 TypeSafe 推出的模型，專門為上述第二種工作而生。它不生成文字。你給它上下文和帶有固定選項的類型化問題，它會回傳每個選項的機率。它在幾毫秒內就能回答，輸入成本為每百萬 token $0.042，輸出免費。
這讓整體架構變得很好描述：
Opus 5.5 負責推理。 規劃、寫程式、除錯，任何答案不在清單上的事。
Jev 負責小型決策。 它從你的主控程式準備好的選項中挑選。
你的主控程式掌握主導權。 它建立選項清單、讀取機率、套用閾值，並在 Jev 不確定時退回給 Opus。
第三點是大家最常跳過的部分，卻也是讓整套系統安全的關鍵。Jev 絕不會憑空發明選項。對於任何無法復原的操作，Jev 也絕不會擁有最終決定權。你的程式碼來定義什麼叫做「夠確定了」。
以下是本文其餘內容所依賴的輔助函式：
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
將此處接上你的 Jev 客戶端：TypeSafe SDK、Vercel AI Gateway，
或 LangChain 套件。它必須針對你傳入的每個選項
回傳 {option: probability}。
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
注意裡面少了什麼：沒有去問 Jev「你有多確定」。你直接讀取它回傳的機率。問任何模型「你確定嗎？」，幾乎每次都會得到「確定」。機率才是誠實的信號。
現在來看看這四個決策。
Agent 步驟中的四個決策
決策 1：在載入上下文前，先挑出相關的專案筆記
這是效果最大的單一槓桿，也是幾乎還沒有人實作的部分。
你的 Agent 有一個筆記資料夾。裡面有 AGENTS.md、架構文件、開發規範、歷史決策，以及「未經遷移絕對不要碰計費模組」之類的警告。大概有三萬個 token。大多數 Agent 每次呼叫都會全部載入，因為沒人想成為那個漏掉重要筆記的罪魁禍首。
所以，與其全部載入，不如針對每條筆記平行地向 Jev 問一個簡單的問題：Agent 執行這個任務需要這條筆記嗎？
首先，依標題將筆記切分成區塊。AGENTS.md 的每個段落變成一個獨立區塊，每份架構文件變成一個或多個區塊。
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
接著，針對當前任務為每個區塊評分：
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
這裡有三個細節很重要。
永遠載入不可妥協的內容。 有些筆記無論如何都應該出現在每次呼叫中：安全規則、「嚴禁強制推送」、標示哪個資料庫是正式環境的那一行。幫它們標記 always，並跳過評分。
設定下限與備案。 如果沒有任何項目超過 0.55，你仍然要載入前兩名。零上下文的 Agent 比上下文稍微多一點的更糟。
記錄被捨棄的內容。 當 Agent 犯錯時，你首先要檢查的就是：那條本可以避免錯誤的筆記，是不是被評分過濾掉了。這份日誌就是你調整 keep 和 floor 的依據。
在實際範例中，光是這項改動就讓每次呼叫的筆記部分從 30,000 個 token 降到 6,000 個。單靠這一點，就能把 session 成本降低約 24%。
決策 2：將合適的任務路由給更快的執行者
不是每一步都需要 Opus。
跨八個檔案重新命名一個函式不需要。在一個已經有九個相似欄位的表單裡新增一個欄位不需要。更新 import 路徑也不需要。這些都是遵循程式庫中既有模式的修改。
因此，在每一步執行前，由 Jev 對該步驟進行分類，再由你的主控程式將類別對應到執行者：
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
看看這些選項是怎麼寫的。它們不是「簡單」和「困難」，更絕對不是「小模型能處理嗎？」。它們是你的程式碼可以直接對應到具體動作的任務類型。這就是每個 Jev 問題的鐵律：每個選項都必須是你的主控程式知道該如何執行的動作。
另外注意預設行為。低於 0.8 時，該步驟就交給 Opus。在這裡，路由失誤只會朝單一方向發生：把困難任務丟給快速執行者，會讓你損失一個失敗的步驟和一次重試；但把簡單任務丟給 Opus，只是多花一點錢。所以拿不定主意時，就往上升級。
快速執行者我使用 Haiku 4.5，輸入每百萬 token $1，輸出每百萬 token $5。在實際範例中，36 個真實工作步驟裡有 12 個交給了它。
決策 3：工具失敗時選擇恢復路徑
工具無時無刻不在失敗。測試超時、檔案路徑錯誤、套件未安裝、shell 指令遇到權限問題、linter 抱怨一些無關緊要的事。
大多數 Agent 會用最昂貴的方式處理：把整段錯誤丟回給大模型，讓它去思考該怎麼辦。有時候這樣做是對的。但很多時候答案顯而易見，而 Opus 卻花了 1,500 個 token 才重新發現 ENOENT 代表檔案不存在。
更糟的是，Agent 會陷入迴圈。重試、失敗、重試、失敗，每次都支付一次完整推理步驟的費用。
所以，你要把失敗狀況交給 Jev，並提供一組固定的恢復路徑：
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # 錯誤訊息的最後 n 個字元
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # 網路不穩或超時3 "retry_after_install", # 缺少套件或工具4 "fix_path_and_retry", # 檔案路徑或 cwd 錯誤5 "switch_tool", # 這個工具做不到，換另一個6 "escalate_to_opus", # 需要真正的除錯7 "stop_and_report", # 需要人類介入8]
嘗試次數的硬性上限寫在程式碼裡，而不是模型裡。無論多便宜的模型，都不該被允許無限重試。
每條恢復路徑都對應到主控程式裡的一個小函式。retry_after_install 會用正規表達式從錯誤訊息中讀取缺少的套件並安裝它。fix_path_and_retry 會檢查存在的路徑並建議最接近的匹配。只有 escalate_to_opus 會真正花錢，而且它只在失敗狀況真的需要思考時才會觸發。
在實際範例中，這替該 session 省下了 6 個浪費的重試步驟。
決策 4：在跑完整測試套件前先執行聚焦檢查
這一項省下的時間比金錢多，而「時間」正是讓 Agent 感覺很快的關鍵。
每次修改後，大多數 Agent 都會跑完整個測試套件。如果你的套件要跑四分鐘，Agent 每次編輯後就要等四分鐘，然後再從數百行輸出中找出唯一重要的那個失敗。
解法和處理筆記的模式一樣：針對 diff 為每個測試檔評分、先跑最相關的幾個，只有在聚焦檢查通過後才跑完整套件。
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # 快速失敗，先修復再說18 return run_tests(test_files) # 完整套件依然是 commit 前的最後關卡
最後一行請讀兩遍。在任何東西被 commit 之前，完整套件依然會執行。聚焦檢查是早期預警，不是替代品。你能在幾秒內而非幾分鐘內抓到大部分錯誤，而且絕不會釋出完整套件本該抓到的問題。
也要先加上那些低成本的檢查：只對變更過的檔案執行型別檢查和 lint。它們只需一秒，卻能在任何測試執行前攔下比例驚人的錯誤。
整合起來：主控程式迴圈
以下是這四個決策如何嵌入迴圈中的單一步驟：
def run_step(task: str, step: str, state):
1. context：只載入此步驟需要的筆記
notes = state.always_notes + pick_notes(step, state.notes)
2. routing：為此步驟挑選執行者
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. recovery：處理此步驟中的任何工具失敗
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. checks：先跑聚焦測試，commit 前跑完整套件
if result.diff:
state.log_check(check(result.diff, state.test_files))
至於 Opus 的部分：它就只是你平常的 Opus 5.5 呼叫。把穩定的上下文放在前面（system prompt、工具定義、「always」筆記），讓它們在各步驟間保持快取，再把特定於該步驟的材料放在最後。
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # 你的 Opus 5.5 模型 ID
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
沒什麼花俏的。省下來的錢來自你不再發送給它的內容，而不是來自什麼巧妙的提示詞。
追蹤單一步驟
當四個決策都上線後，日誌中的單一步驟看起來會像這樣。任務：為公開註冊端點加上速率限制。這段追蹤紀錄是示意用的，但你會在自家日誌中看到相同的結構。
step 14 "add a per IP rate limit to POST /signup"
[notes] 平行評分了 41 個區塊
保留：api/middleware.md (0.94)、conventions/errors.md (0.88)、
infra/redis.md (0.81)、decisions/2025_auth.md (0.62)
捨棄：37 個區塊，包含 billing、email templates、CI
[route] new_logic (0.91) → opus
[opus] 規劃變更，撰寫 middleware + config + handler 修改
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install，重新執行
[checks] 對變更檔案執行 typecheck：pass
聚焦測試（1,388 個中的 12 個）：pass
完整套件：pass
從上到下讀一遍，算算有多少行以前是一次完整的 Opus 呼叫。挑選筆記：一次大型呼叫，或者根本不挑、盲目載入 30,000 個 token 的筆記。路由：什麼都沒有，每一步都交給 Opus。缺少套件：用一次完整推理步驟去推導出「缺少模組」等於「安裝該模組」。挑選測試：什麼都沒有，每次編輯都跑完整套件。
現在，那段追蹤裡只有一行是 Opus，而那正是真正需要頂級模型的一行：規劃並撰寫速率限制器。
這就是整篇文章的核心概念。讓昂貴的模型把時間花在只有它能做的工作上。
實際範例：69% 是怎麼算出來的
以下是一個功能開發 session 的完整計算：60 個 Agent 步驟，加上一般 Agent 過程中累積的 6 次浪費重試。所有價格皆為目前的公開定價。
改造前：Opus 5.5 包辦一切
每一步載入 70,000 個 token 的上下文：15,000 用於 system prompt 和工具，30,000 用於整個筆記資料夾，25,000 用於目前的對話。假設其中 80% 命中快取。每一步產生約 1,500 個輸出 token，因為 Opus 5.5 的思考模式永遠開啟。
cache reads: 56,000 × $0.20/M = $0.0112
fresh input: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
per step = $0.0972
66 steps × $0.0972 = $6.42
改造後：加入決策層
每步上下文降至 46,000 個 token，因為 Jev 只挑出 6,000 個 token 的筆記，而非載入全部 30,000 個。24 個純決策步驟移交給 Jev。6 次重試迴圈消失了。剩下的 36 個工作步驟中有 12 個交給 Haiku 4.5。
Opus 5.5: 24 steps × $0.0742 = $1.78
Haiku 4.5: 12 steps × $0.0169 = $0.20
Jev: 102 calls × 5,000 tokens
× $0.042/M, output free = $0.02
total = $2.00
從 $6.42 降到 $2.00。同樣的功能，便宜了 68.8%。
根據答錯的代價來設定閾值
以下是各項槓桿的個別貢獻，依序疊加：
僅筆記篩選 $4.89 省下 23.7%
- 決策移交給 Jev $3.13 省下 51.2%
- 恢復路徑 $2.69 省下 58.1%
- 路由至快速執行者 $2.00 省下 68.8%
關於這些計算，有兩句老實話要說。
第一，這些是基於明確假設推算出的數字，不是對你技術堆疊的實際測量。你的上下文大小、快取命中率和決策數量都會不同。列出每一行的目的，是為了讓你能替換成自己的數字。一旦你測量出真實的前後差異，請用你的數字，而不是我的。
第二，看看錢到底花在哪裡。Jev 的 102 次呼叫總共只花了兩分錢。省下來的錢並不是因為 Jev 單次呼叫很便宜，而是因為一旦由 Jev 做出決策，許多事情就不會再發生了：膨脹的上下文、為選擇題付出的完整推理步驟、重試迴圈，以及在重新命名工作上呼叫大模型。
為什麼不直接用 Haiku 做決策？
好問題。Haiku 4.5 既便宜又快，為什麼還要多加一個新模型？
三個原因。
它還是會生成文字。 Haiku 用文字回答。你必須提示它用你的選項之一來回答，然後解析結果，接著還要處理它自行加上解釋、挑了清單上沒有的選項，或把答案包在一句話裡的情況。Jev 則會針對你傳入的每個選項回傳機率。不需要解析，也不會出現清單外的答案。
你拿到的是完整分佈，而不只是一個答案。 當 Jev 顯示 needed: 0.52、not_needed: 0.48 時，你知道這跟擲硬幣差不多，你的主控程式可以向上升級。但當文字模型回答「needed」時，你根本不知道它有多確定。只有看得見機率，閾值才有意義。
成本算法不同。 Jev 的輸出免費，輸入每百萬 token $0.042。每一步評分 41 個筆記區塊，意味著每步有 41 次小型呼叫。用 Jev 的話，這不到一分錢。用任何文字模型（即使是便宜的），那就是 41 次生成，各自帶有輸出成本和延遲。
把 Haiku 用在需要真正寫程式的小型修改上。把 Jev 用在從清單中挑選。把 Opus 用在思考上。讓每個模型做它擅長的事。
如何在不搞壞任何東西的情況下導入
不要一次把四個決策全打開。以下是我建議的順序。
第 1 週：影子模式。 維持現有 Agent 完全不變。在它每次做出決策時，也向 Jev 問同樣的問題，並記錄兩者的答案以及 Jev 的機率。完全不要根據 Jev 的答案採取行動。
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
第 2 週：檢視分歧。 只看 Jev 和你現有 Agent 意見不同的那些紀錄。依 Jev 的機率排序。你通常會找到一條明確的分界線：高於某個機率時，Jev 的正確率跟 Opus 差不多。那條線就是你的閾值。這些分歧紀錄也會免費成為你的測試集，直接取自你的真實流量。
第 3 週：啟用筆記篩選。 這是效果最大的槓桿，也最容易撤銷，因為漏掉重要筆記會很快在你的日誌中顯現出來。
第 4 週：啟用恢復路徑與測試。 兩者在程式碼中都有硬性上限和備案機制，所以最糟的情況也只是退回你今天的做法。
最後：路由。 路由失誤對使用者來說最明顯，因為把困難任務丟給快速執行者會產出糟糕的程式碼。把它留到最後才開啟，搭配保守的閾值，並密切監控快速執行者步驟的失敗率。
把每個決策都放在一個開關旗標後面，讓你能用一行程式碼撤銷它。
依風險設定閾值
所有事情共用同一個閾值是錯誤的。請根據「答錯會發生什麼事」來設定。
一個功能開發 session，同樣的結果：$6.42 降到 $2.00
低風險、容易復原：0.55 到 0.65。 挑選筆記、決定測試順序。答錯的代價只是一點上下文或幾秒鐘。
中等風險：0.8。 路由與恢復。答錯的代價是一個失敗的步驟，而你的主控程式能抓到它。
高風險、難以復原：0.9 或永不放行。 刪除檔案、強制推送、修改正式環境設定、執行資料庫遷移。我的真心建議：不要讓任何模型單獨做這些決定。把它們交給人類，或至少交給 Opus 並加上確認步驟。
任何低於閾值的狀況都要向上呈報：需要推理就交給 Opus，需要判斷就交給人類。
這套架構派不上用場的地方
這套架構並不是能讓所有工作負載都神奇翻倍的萬靈丹。
純生成型工作負載幾乎沒差。 如果你的 Agent 大部分時間都在根據明確規格撰寫大量新程式碼，那就沒什麼決策可以轉移。你依然能享受到筆記篩選帶來的節省，但其他方面幫助不大。
小型專案不需要它。 如果你的整個筆記資料夾只有 2,000 個 token，測試套件八秒就跑完，那麼打造這套機制的額外成本目前還不值得。
Jev 不適合單獨做最終決定。 它非常擅長察覺狀況並從簡短清單中挑選。但你不該用它來回答「這個 pull request 可以合併了嗎？」這種單一的大問題。把大問題拆成小問題、逐一評分，然後在你自己的程式碼中用你自己的權重組合結果。
如果你已經有固定問題的標註資料，自己架設的小模型可以在價格上打敗 Jev。 Jev 的優勢在於問題不斷變化且你沒有訓練資料的場景——而這正是大多數程式碼 Agent 的寫照。
我會避免犯的錯
讓模型撰寫選項清單。 整套架構都建立在「你的程式碼能直接執行的選項」之上。如果由模型生成選項，你就又回到解析自由文字的老路了。
問 Jev 它有沒有信心。 直接讀取機率就好。自我報告的答案幾乎永遠是「有」。
沒有備案。 每個 Jev 決策都需要一條「不確定」的路徑，而那條路只能是 Opus 或人類，絕不能是瞎猜。
把重試上限寫在提示詞裡而不是程式碼裡。 被告知「只能重試 3 次」的模型，偶爾還是會重試 30 次。程式碼不會。
捨棄完整測試套件。 聚焦檢查讓你變快，完整套件讓你保持誠實。兩者都要留著。
什麼都沒量。 如果你在開始之前沒有記錄每次 session 的成本，你永遠不會知道自己到底省了 20% 還是 70%。先拉出你正常工作一週的使用數據。這只要十分鐘，而且這是唯一重要的數字。
本週行動清單
以下是完整的檢查清單：
- 記錄一週的 Agent sessions：步驟、tokens、成本、失敗次數。
- 找出藏在你循環裡的決策：筆記（notes）、路由（routing）、恢復（recovery）、測試（tests）。
- 把每個決策寫成一個問題，並附上固定的選項清單。
- 讓 Jev 以 shadow mode 與你目前的 Agent 並行跑一週。
- 根據分歧紀錄（disagreement log），按風險設定閾值。
- 先開啟筆記選擇功能，接著是恢復與測試，最後才是路由。
- 比較前後每次 session 的成本。那就是你的成果數字。
Opus 5.5 是我用過寫程式最強的推理模型。但最大的錯誤，就是連其他事情也丟給它做。
讓它思考。讓 Jev 決策。讓你的程式碼當家作主。
如果這篇文章對你有幫助，歡迎追蹤 @cyrilXBT。我每週都會拆解如何用最新的 AI 模型打造產品，而且附上真實數據。
把這篇加入書籤，等你準備動手時就能隨時回來翻閱。
