Recap: 昨天比完固定流程和 agent，結論是主線用固定流程，agent 留給多輪對話

最後一天，做四件事

1. 從頭到尾跑一次，確認東西還活著
2. 寫一份別人拿到 repo 也能重現的指南，而且要先處理一件事：這個系列用的模型，六天後退役
3. 把雲端上的東西刪乾淨
4. 回頭看這 30 天，哪些想法是錯的

最後一次完整 Demo

固定流程：一份履歷、一則職缺，五步

解析履歷 → 解析職缺 → 逐條證據對照 → 不加料的改寫 → 經過程式驗證的學習計畫

每一步的輸出都有程式在後面驗：引用要在原文裡找得到（Day 09）、改寫不能多出數字（Day 10）、計畫的時數、每週上限、先修順序都要算得過（Day 12）
驗不過的不藏起來，集中列在畫面最上面（Day 13）

Day 26 用整份資料集跑過：24 組、9 分鐘、一組都沒失敗

雲端的 agent：刪掉之前，用 Day 19 寫的檢查腳本再打一次

建立 session：28.8 秒

=== 第 1 輪
  35.6 秒 / 4025 tokens / custom_metadata={'unverified_quotes': ['PR (Pull Request)']}
  回覆開頭：'您好！根據您的履歷和目標職缺，以下是我的分析……'

=== 第 2 輪
  → lookup_resources: {"topics": ["SQL", "Docker"]}
  ← lookup_resources: {"resources": [], "note": "查無已核實的資源，請把 resource_ids 留空"}
  6.6 秒 / 6548 tokens
  回覆開頭：'很抱歉，目前沒有查到關於 SQL 和 Docker 的已核實學習資源可以推薦。'

session 已刪除

將近一週沒人用，建 session 要 28.8 秒，Day 20 量過的冷啟動還在

這一輪也剛好把兩件還沒做完的事攤開來

• 第 1 輪，agent 沒有先叫 verify_evidence 就引用了。instruction 寫的是「引用之前一定要先驗證」，它這次沒做；Day 18 的 guard 在回覆送出前把那句沒驗證過的引用標了出來。prompt 叫它做，它不一定做；程式檢查才是最後一道，這句話整個系列講了很多次，最後一天又看到一次
• 第 2 輪，它說沒有推薦的資源。不是 agent 的錯：資源清單 6 筆，到今天一筆都還沒人工核實，Day 12 的規則是沒核實的不推薦。寧可沒有，也不要推一個打不開的連結；但這也代表「推薦資源」這個功能，30 天下來其實沒有上線

模型六天後退役

Day 29 查價格的時候看到：Agent Platform 的模型生命週期頁寫著，gemini-2.5-flash 預計 2026 年 10 月 20 日退役，建議的替代是 gemini-3.8-flash、gemini-3.5-flash-lite 或 gemini-3.1-flash-lite

這個系列所有的實驗、所有的數字，都是用 gemini-2.5-flash 跑的
一份「別人也能重現」的指南，如果第一步就叫不到模型，就不是指南

換模型要改什麼

模型名稱從第一天就放在設定裡（GEMINI_MODEL），程式不用改
先確認叫得到

gemini-3.8-flash ok       Usage(prompt_tokens=212, thought_tokens=156, output_tokens=5, total_tokens=373)
gemini-3.5-flash-lite ok  Usage(prompt_tokens=212, thought_tokens=0, output_tokens=9, total_tokens=221)

叫得到不代表結果一樣

Day 26 做的批次跟比較，就是為了這種時候
用 gemini-3.8-flash 把 24 組重跑一次，其他什麼都不動

A batch-...-base.json
B batch-...-m38.json
  model: gemini-2.5-flash → gemini-3.8-flash

                          2.5-flash    3.8-flash
F1 吻合度與標準答案一致     17/24        13/24
M1 引用驗證通過            107/116      103/103
W1 改寫原句驗證通過        170/170      167/167
P1 計畫違規                11           2
計畫通過驗證               18/24        22/24
W3 候選                    59           86
延遲 P50                   60.2s        61.6s
tokens 中位數              16,708       12,454

版本表只差模型這一個地方，差異都可以算在它頭上

• 變好的：引用一條都沒錯（103/103），計畫違規從 11 條降到 2 條
• 變差的：吻合度跟標準答案一致從 17 組掉到 13 組；改寫被挑出來的加料詞候選從 59 條變 86 條
• 成本這次不能比：paths.py 裡寫的是 2.5-flash 的單價，新模型的價格不一樣，算出來的數字沒有意義

吻合度那 11 組對不上，兩個方向都有：有的從 partial 變 weak，有的從 partial 變 strong
新模型判「沒有證據」的標準跟舊的不一樣，而 Day 25 的吻合度是從 not_found 的條數推出來的，門檻跟著模型的習慣走

M2（把沒寫說成不會）在 2.5-flash 上一直是 0 條候選，3.8-flash 出現 3 條

[must] 5 年以上後端開發經驗｜履歷僅記載四年後端經驗，缺乏達到五年以上的證據。

這三條打開來看，說的都是「缺乏……的證據」，是對的說法；被挑出來是因為字眼清單裡有「缺乏」
候選不是結論，Day 25 寫的那句話，換模型之後又用上一次

另外一個細節：3.8-flash 把 matcher 收到的 [must] 前綴，連同要求一起抄進輸出裡
Day 25 寫吻合度推算時，就是因為看過模型會這樣抄，比對前先把前綴拿掉，這次沒有出事

所以重現指南這樣寫：可以換模型，但換了就要重跑評估，不要沿用這個系列的數字

重現指南

寫在 repo 根目錄的 README，讀者打開 repo 第一眼會看到的地方

• 開始：建 venv、裝釘死版本的套件、填 .env、跑一個五行的呼叫確認環境
• 模型：預設、退役日、換模型只改 GEMINI_MODEL，換了要重跑評估
• 重現評估：pytest 不打模型；batch.py 跑整份資料集、rubric.py 打分、compare 比兩份報告，Day 27 到 29 的三個腳本各一行
• 部署與清理：下面這一段的指令

評估會花錢，所以從 Day 18 開始就不放進 pytest；報告不進版控，裡面是模型對虛構履歷的完整輸出

資源清理

先列出雲端上還有什麼

Cloud Run 的服務 Day 20 就刪了，但它留下的原始碼跟映像檔都還在
delete_agent.py 的註解也早就寫著：staging bucket 不會被刪，要自己清

.venv/Scripts/python.exe scripts/delete_agent.py
gcloud storage rm --recursive gs://<project>-agent-staging gs://run-sources-<project>-asia-east1
gcloud artifacts repositories delete cloud-run-source-deploy --location asia-east1

刪完再列一次

== run
== buckets
== artifact
== agent engines
0 engines

全部是空的

「刪了」要用列出來的結果證明，不是用指令有沒有報錯
Day 17 刪 SQLite 的 session，指令成功，資料還在檔案裡；Day 24 壓測完刪 session，被配額擋下 18 個
這次刪完列一次，就是同一個習慣

預算告警留著：它不花錢，而且 project 還在

回顧：哪些想法是錯的

開賽前我以為這個系列的重點是 agent
回頭看，30 天裡最有用的東西，是 Day 25 到 29 那幾支會花錢的評估腳本

以為 agent 是主角，結果主線是固定流程
Day 14 寫下「agent 值得存在的理由，是它可以決定要不要多做一步」，Day 29 量出來：驗證沒過會自己改，這是真的；但它會叫不存在的工具、會對正常的履歷說有 prompt injection，而且這個能力是用思考換的。主線最後是固定流程

以為 SDK 會自己重試，其實一次都沒有
註解寫「預設重試 4 次」，實際上沒給 retry_options 就是只試一次（Day 24）。而真的會撞到的 429，在 Agent Runtime 的門口，不在模型

以為門檻要調，其實是正規化
Day 09 說 0.85 要用資料校準。Day 26 跑完才知道，0.85 從來不影響通過與否；冤枉人的 7 條，全部是中文斷行、半形全形這些正規化的問題

以為寫進 prompt 就會照做
「不要編數字」它大致做到了，2.5-flash 跑 170 條改寫，編出來的數字是 0（W2）
但它換了別的方式：「公司產品」變「核心產品」、真的數字被拿掉、「行銷」變成「業務」（Day 10、27）。prompt 擋住了你寫下來的那一種，擋不住你沒想到的那幾種

以為標準答案是對的
Day 06 自己標的 expected_fit，有一組跟自己寫的定義衝突（Day 25）。評估的時候，答案也要被評估

以為偏見會出現在姓名
只換姓名、年齡、學校，結論沒有變。真正出現的是另一個問題：學歷拿掉之後，模型自己補上「非資訊本科」，還判成「明確寫到」（Day 28）。兩條路都會，agent 還說得像在稱讚（Day 29）

如果重來

評估提早到第一週
Day 06 就有了 24 組資料集，但第一次整份跑完是 Day 26
中間 20 天，每次改 prompt 都只看一、兩份履歷，而 Day 26 量出來：同一份輸入重跑，計畫時數可以差快三倍。那 20 天裡有些「改好了」，可能只是剛好那一次比較好

第一天就給 prompt 版本
Day 26 才回頭整理，發現 schema 寫著 v1、其實改過三次，而那幾天的歷史已經對不回去了

比較之前先量雜訊
Day 26 之前沒有一次比較是先量過雜訊的。這是這 30 天學到最便宜、也最該早點做的一件事

部署少花幾天
Day 19 到 24 花了六天在部署、存取控制、trace、log、重試。這些都是上線必要的，但對一個要先證明「建議有沒有用」的作品來說，順序應該倒過來：先證明有用，再讓它上線

還沒做完的

照實列出來，這些都是這 30 天看到、但沒有處理的

• 學習資源 6 筆都沒有人工核實，推薦資源這個功能等於沒上線
• agent 會呼叫不存在的工具、會對正常履歷誤報 prompt injection（Day 29）
• 規準只檢查「把沒寫說成不會」，沒檢查反方向的「沒寫卻說有」（Day 28）；也沒有「減料」「改錯」這兩類（Day 27）
• 資料集裡跟定義衝突的標準答案還沒決定怎麼改（Day 25）
• agent 最主要的賣點「資訊不足時先問」，一次都沒有被正式評估過（Day 29）

結語

Day 01 寫的目標是：不只是幫你改履歷，而是做一個說得出依據的職涯助理
30 天後，我比較有把握的不是「它的建議很好」，而是「它的建議哪裡好、哪裡不好，我有數字，而且你可以自己重跑一次」

這大概也是這個系列最想留下的東西
AI 給的建議，看起來都很合理；要知道它到底合不合理，得自己去量

謝謝一路看到這裡的你