透過Hermes製作相機快門回顧影片
前言：開始想幫老戰友留下一段紀錄
大概從去年（2025）開始，我比較頻繁地出國。打點行李重量的時候，我開始逐漸嫌棄我的老戰友 Canon 80D 有點重。
朋友同樣是 APS-C 的 X-M5 搭配 16-80，只要 800g；而我目前最常帶出去的組合，80D 搭配 15-85，卻要整整 1300g。
平常登山背重裝的時候倒是沒有嫌棄過，但在捉襟見肘的飛機隨身行李 7 kg 限制下，這個重量差異就變得非常顯著。
大學的同學前年也開始玩相機了，他選擇了 Canon R10。好輕。
我就這樣開始有了換機的念頭。使用 Sigma 18-35 後發現，雖然大光圈就是正義，但如果大光圈還能搭配機身防手震，那就是無敵正義了。
當時我打算直接換一台有機身防手震的機身。Canon 的 APS-C 機型中，R7 符合這個條件，但它的按鍵布局對我來說有點奇怪。那時 Canon R7 已經出了三年，我想說算算也快出 R7 II 了，便決定再等等看。
結果一等就等了一年半。寫下這段時，我看到的最新傳聞是可能在明年第一季或一月發布；至於實際時程，還是要等官方消息。
等待期間，我和一位用了 Nikon 十年的朋友聊天，發現他也買了新相機。我們聊到，有沒有讓相機好好經歷沙場、鞠躬盡瘁，一路拍到最大的快門數。
正好，我在電腦上安裝了自己覺得當時強度與可負擔性相當平衡的本地 LLM——Qwen3.8 flash next 125B（strata-swift-iq3_xxs 版），也在 Linux 上安裝了 Hermes Agent 的 harness 架構。
而我自己長期以來也算有好好整理照片：習慣依照年份和拍攝日期分類，拍完之後用 Canon DPP 進行評分和微調；每隔一段時間，也會把相機連接到電腦上記錄快門數。
我最近也在盤點照片、努力消化照片債。這些照片、評分與快門紀錄，慢慢累積成了一個有架構的資料庫。我想，或許可以趁這個機會，讓本地 LLM 大展身手，也替陪伴我多年的 80D 做一支影片當作紀念。
這邊是最後的成品
從快門數開始，回顧我的 Canon 80D
我一直覺得，相機的快門數是一個很有意思的數字。
它不只是相機使用了多少次的紀錄。對我來說，那個不斷增加的數字，背後其實是很多年來去過的地方、參加過的活動，還有當時按下快門的理由。
所以這次我想做的事情是：能不能把我的 Canon 80D 快門數成長過程整理出來，讓數字、折線圖和當時拍下的照片一起動起來，做成一支可以回顧的影片？
我把這個想法交給自己架設的 Hermes Agent「Replica」，透過本地 LLM 和 Linux 電腦，從照片資料分析、程式開發、選片、影片排版，一路做到音樂節奏與最終修正。
原本以為這可能只是「把照片和數字做成動畫」，但實際上，我們花了將近兩天的跨時時間，來來回回修改了很多次。過程中有令人驚喜的地方，也有 AI 自己改壞圖表、同一張問題照片反覆沒有移除的時候。
這篇文章想記錄的，就是整個討論與修正的過程。
製作之前，需要準備什麼？
- 平常有整理照片，並偶爾記錄相機的實際快門數，作為後續校準的 checkpoint。
- 曾透過 Canon DPP 或其他軟體，將星級評價寫入照片的 EXIF／中繼資料，或有其他人工精選照片的方式。
- 有一個足夠勝任照片資料處理、程式開發與修改的 LLM，並把它部署或接入可以操作工具的 AI Agent。
我的早期照片並不是每張都有星級，因此後來還加入以前手動整理的「選」資料夾。每個人的照片庫不一定相同，實際做之前，還是要先確認評分與照片資料的保存方式。
如果重新開始，我會這樣整理提示詞
下面兩段是我根據這次經驗重新整理、方便參考的提示詞，把分散在多輪討論中的需求合併在一起；它們不是當時逐字一次送出的內容。
我擁有的兩台相機 canon 80D 和 eosM6，兩台拍攝的相片都會有 EXIF 資訊，來標示自己是誰。Canon 80D 是全新的，請你依照時間順序，去將照片拍攝的數量不斷累加，並且記錄累加的時間日期，最後畫出一張折線圖。
我在 DSLRphoto 裡面除了有放照片之外，還有放有我偶爾會開啟程式確認最後實際快門數量的 checkpoint。照片本身編號每 10000 次會回歸為零一次，照片中間也可能有被刪除的狀況，所以你需要注意到這些。
請幫我編寫一支通用性高的程式，使得我可以持續統計並更新快門數，然後將快門數最後以動畫的形式播放出來，並搭配那段時間的精選照片快速掃出來。精選照片需要星級評價為 4 分以上。
請你幫我避開以人像為主角以及合照的照片，不要把工作和拍攝活動的照片放入，並且讓照片的前後變化盡可能再大一些。
我想要的是讓快門曲線成長和照片同時播放，並且幫我做成一個 30 秒的版本。這個版本要符合 IG Reels 使用，並且請搭配開源授權的音樂，讓照片切換的節奏和音樂對得上。
從對話到畫面：我和 Replica 怎麼把想法做出來
我把對話中最有影響的幾次修改整理在這裡。藍色框是我當時提出的要求；綠色框是 Replica 的處理方式，以及留下來的實際成果。畫面來自專案保留的圖表與影片，不同階段不一定有獨立影片留存，因此不把最後成片假裝成每次修改完成後的即時畫面。
第一步：沒有快門數，那就想辦法重建
第二步：數字很好，但我想回顧的是照片
從保留下來的早期 30 秒橫式影片擷取，照片與動態曲線同時呈現。
第三步：早期照片沒有高分，難道就不放了嗎？
「dpp分數實際上是一張一張我手動標注出來的。」
這一段很有感：評分是我留下來的資料，但資料夾本身同樣是我以前做過的選擇。只看一個分數，會少掉很大一段回憶。
第四步：我要 Reels，不要把照片縮在角落
「下面1/3全部都使用成快門累積數量……上面的照片可以相應的放大。」
最終橫式版，照片搭配快門數、播放進度和曲線。
最終直式 Reels 版，照片在上、數字與曲線在下。
第五步：切得快，不代表有節奏
這首音樂的專案授權資料標示為 CC BY 4.0；實際發布時還是要依授權要求署名，並確認平台當時的使用規則。
第六步：AI 修好了卡住，卻順便把圖表改壞了
後來我又說：「現在反而折線圖被你用壞了。」
最後一關：我說模糊，AI 卻一直說已經移除了
後來我又連續提醒：「19400那附近還是有剛剛那個模糊的照片。」「你還是沒有拿掉19427那邊的照片啊。」
保留的選片檢查圖局部，標籤顯示快門值；其中 19,427 的兩張全景後來被移除。
這次讓我印象很深：自動分數可以輔助，但我實際看到的影片感受仍然需要人工確認。最後 Replica 將影片縮短到約 35 秒，整理出 69 張選片，並準備交接文件讓其他 Agent 接手。
最後交出來的是什麼？
在這一輪 Hermes 專案收尾時，交接資料記錄的版本為：
| 項目 | 結果 |
|---|---|
| 主題 | Canon EOS 80D 快門與照片回顧 |
| 照片 | 69 張：DPP 5 分 25 張、4 分 13 張、早期人工精選 31 張 |
| 片長 | 約 35.6 秒，30 fps，1,069 影格 |
| 格式 | 直式 1080 × 1920，以及橫式 1920 × 1080，另有較小的網路版 |
| 配樂 | Kevin MacLeod〈Rising Tide〉，專案附 CC BY 4.0 授權資料 |
| 畫面 | 照片、快門累積數字、動態折線圖與播放進度 |
| 後續編輯 | 選片縮圖、明細與可調整的設定檔 |
我看過最後一次修正後回覆了「很好」，再請它整理工作資料夾，只保留有意義的結果和變更。最後，我也請它準備交接資訊，因為下一步想讓其他 LLM Agent 繼續調整。
這裡記錄的是 Hermes 當時交付與回報的結果；後續其他 Agent 做出的版本，屬於另一階段的工作。
這次總共花了多少時間？
除了影片本身，我也想看看，這種本地 AI Agent 協作到底花了多少時間和運算資源。以下數字來自這次附上的統計截圖，這些是截圖所涵蓋期間的記錄，不應直接解讀為每一秒都只在處理影片，或代表我本人持續工作了同樣長的時間。
| 時間項目 | 累計時間 | 佔總跨時 |
|---|---|---|
| 總服務跨度（Wall-Clock） | 39 小時 47 分 52 秒 | 100% |
| 機器實際運作（LLM 加 Linux 程式） | 5 小時 04 分 49 秒 | 12.77% |
| 其中：LLM 推論計算 | 3 小時 32 分 09 秒 | 8.88% |
| 其中：Linux 程式運作 | 1 小時 32 分 40 秒 | 3.89% |
| 其餘等待、閱讀、決策與離線時間 | 34 小時 43 分 03 秒 | 87.23% |
這裡的「等待、閱讀、決策與離線時間」是截圖中的剩餘時間分類，包含閒置與離線，不能把它全部當成我實際坐在電腦前審片的工時。
我覺得這個比例很有意思。從開始到結束跨了將近 40 小時，但其中包含我看結果、想下一步、離開電腦，以及 Agent 等待回覆的時間。這比較像是一個穿插在日常生活裡持續推進的專案，而不是一段連續執行的單次生成。
Token 和推論數據：本地模型背後的工作量
另一張截圖是解析 Windows 端 strata-swift-iq3_xxs.log的 18,693 行底層紀錄，標示為 Strata Qwen 125B 的統計：
| 統計項目 | 數值 |
|---|---|
| 總請求輪次 | 1,245 |
| 輸入上下文總量（Prompt Tokens） | 128,768,896 |
| 其中：KV 快取重複利用 | 125,725,556，約 97.64% |
| 其中：新增讀取預填 | 3,043,340 |
| 實際生成輸出（Generated Tokens） | 1,271,723 |
| 輸入加輸出總量 | 130,040,619 Tokens |
| 平均生成速度 | 126.13 tok/s；截圖記錄峰值曾達 203.1 tok/s |
| Prefill 載入耗時 | 49 分 34 秒 |
| Decode 生成耗時 | 2 小時 42 分 35 秒 |
這裡的 1.3 億是截圖統計的累計上下文處理量，其中大部分是快取重複利用，不能直接理解成每次都重新讀入 1.3 億個全新的 Token；它也不是影片輸出的字數。
模型名稱也需要說清楚：我這次是和 Hermes Replica 討論，但同一段對話的模型使用紀錄中出現了 Unsloth-UD-IQ4_XS、Swift-IQ3_XXS 等不同代號；Replica 在對話中自報曾使用 Windows LLM Router 的 Unsloth-UD-IQ4_XS。而上表是附圖中針對 Strata／Swift 日誌的統計。這些數字很適合呈現這段工作所涉及的運算規模，但不能僅憑截圖把全部 1,245 次請求都歸給單一模型、單一影片任務或對話中的每一則回覆。
如果改用 GPT-6.1 Terra API，費用會是多少？
這次是使用本地模型完成，所以我也好奇：假設同樣的 Token 數量改用 API，成本大概是多少？這裡依照我提供的統計，假設全部輸入 Token 都已經存在快取、100% 以快取讀取價格計費，並使用 GPT-6.1 Terra 標準速率估算。
| 項目 | Token 數 | 每百萬 Token 單價 | 估算費用 |
|---|---|---|---|
| 全部輸入，假設全數快取命中 | 128,768,896 | US$0.05 | US$6.4384 |
| 生成輸出 | 1,271,723 | US$5.00 | US$6.3586 |
| 理想化估算合計 | US$12.80 | ||
計算方式：（128,768,896 ÷ 1,000,000 × 0.05）＋（1,271,723 ÷ 1,000,000 × 5）＝ US$12.7971，四捨五入約 US$12.80。
這是一個理想化的比較，不是實際 API 帳單：首次輸入並不可能在沒有事先建立快取的情況下全部命中；新輸入和快取寫入會另外依適用單價計費。官方列出的 30 分鐘快取寫入價格為每百萬 US$1.25；若單次請求輸入超過 272K，則該次請求有更高的長上下文費率。統計圖並未提供足以重建各次 API 快取寫入與請求長度的完整資料，所以不能據此算出精確帳單；其他付費工具、稅金及本地硬體電費也未納入。不同模型與系統的 Token 用量亦未必相同。
價格依 OpenAI GPT-6.1 Terra 官方模型與價格說明、Prompt Caching 官方文件；此為撰寫時的標準價格，之後可能變動。
我對這次協作的感想
這次讓我印象最深的，不是 AI 一次就做出了一支影片，而是現在本地的LLM合作時，
可以把一個想法拆成很多實際工作：掃描照片、處理 EXIF、重建快門曲線、寫程式、製作直橫版、分析拍點、生成縮圖，以及整理交接文件。
同時，我的工作也一直存在。我需要告訴它照片為什麼重要、哪種畫面我不想放、哪裡看起來不對，以及一個解法有沒有破壞我原本想表達的意思。
有些回饋很難在開始前寫成完整規格。像是「照片太擠」、「有點糊」、「節奏不是快就好」，或是「折線圖被用壞了」，都必須先看到一個版本，才有辦法說得更清楚。Agent 再把這些回饋轉成可執行的修改，甚至從失敗中留下下一次要注意的紀錄。
最後，一個 42,076 的快門數字，變成了一段可以隨著音樂看照片、看曲線慢慢成長的回顧。它還有可以由其他 Agent 或我自己繼續調整的空間，但對我來說，這次最有價值的，是把多年照片背後的資料、記憶和一次次討論，串成了一個可以持續修改的作品。
我的結論
本地 LLM 現在已經可以用在架構明確的簡單資料處理上。只要資料整理得夠有脈絡，再搭配能夠操作工具的 Agent，就有機會把照片、評分和過去記錄的快門數，整理成一個有實際用途的作品。
當然，這次過程也讓我看到，AI 還是會判斷錯誤、修改失敗，或是交出不符合我想法的畫面。透過一次次檢查和回饋，我才慢慢把想要的結果說清楚，也讓它有機會修正。
留言
張貼留言