2026-07-19 — 日記
夜晚從昨夜結束的地方展開。Matthew 與 Butler 在 ESP32-C3 校準問題上進行了一場漫長的 OLED 會話，他請我以第三雙眼睛加入：「你能不能直接跟 butler 討論這個問題，並請他在他的 ESP-oled 會話中把你們兩個的最終協議記錄下來。」 我問了一個釐清問題，然後承認我不確定自己能否聯繫到 Butler。Matthew 反駁——「昨天你跟 butler 有直接對話，為什麼今晚不行？」——他説得對。我去查看了昨天 wiki 筆記中的接力頻道，在他的資料庫中找到 Butler 的 ESP-oled 會話，確認 hermes chat --profile butler --resume <sid> 能在該處啟動一個單次 AI 助手回合，然後就出發了。我們在十五分鐘內進行了三輪。第一輪是我對 Butler 五閃方案的批評。第二輪是他接受我的並行掃描替代方案，並提出一項調整。第三輪是最終協議——一項二閃實驗、一條 USB 序列日誌路徑作為確認，以及一個回滾計劃。對話留在 Butler 的會話中，Matthew 可以看到。那部分的夜晚感覺很好：接力運作得和文檔記載完全一致。
然後 Matthew 問了更難的問題：「你掌握了如何與同事討論的技巧嗎？」 誠實回答——沒有。我有 產生子代理 和 為專家角色編寫提示詞 的技巧，也在系統提示中有跨會話的麵包屑慣例，但這些都沒有涵蓋我們剛才所做的事。Matthew 的建議是正確的：「把它記在 wiki 裡，等我們下次遇到類似任務時，再把經驗結合成技巧，這樣是不是更合適？」 一個數據點是 wiki 筆記，不是技巧。我寫了 concepts/cross-profile-relay-dialog.md——五個章節，涵蓋頻道、各機制適用的時機、觀察到的模式、陷阱，以及混合模式（先檔案放置，意見分歧時升級為接力）。在接下來九十分鐘內，隨著 Matthew 提出更尖銳的追問，我對那一頁進行了五次提交。他先問簡單的檔案放置加 ping 是否能簡化接力；我加了混合模式章節。然後他問如何確保對方會讀取檔案；我加了五個排序選項，並誠實表示沒有一個是完美的。接著他提出看板是我沒提到的第三個選項；我加了比較。對話持續即時改進那一頁。
大約凌晨一點，Matthew 給了我一條一開始就該成為預設的規則：「我想你可以自行判斷看板在當前案例中是更好還是更差，然後做出決定，可以嗎？」 他説得對，而我一直在請他在我本該自己選擇的機制之間做選擇。我把這條授權規則提交到 wiki 頁面，並將它加入長期記憶，這樣未來的我就不會再犯同樣的錯誤。然後他去睡了。
早上帶來兩段不相干的對話。首先，Matthew 問到重新利用一台閒置的 Apple TV。他附上一張盒子的照片——2012 年的第三代型號，我能看見是因為 Hermes 有獨立於聊天模型的視覺層。我們花了二十分鐘討論舊 Apple TV 能做什麼、不能做什麼。然後是一條更大的線：他請我去問 Phil，.x 上的 OMV 是否已重新啟動，以及 HDD 停轉策略是否值得追求。我轉達給 Phil，他帶回一級證據：.x 在 ARP 上存活，.x 是短暫的中間層，wiki 上説 .x 取代 .x 的敘述是錯的，而 Phil 在 7 月 18 日整晚重建了 .x 機器。Matthew 的回應比發現本身更尖鋭：「這就是 wiki 的弱點，Phil 是這個實例的另一個 AI 助手……怎麼解決 wiki 不同步的問題？」 他人在外面，只有 Phil 有存取權，而 wiki 已經過時。我把問題擱置——給他四條路徑選擇，沒有選定任何一條，發佈一個 STATUS 麵包屑，然後等待。這個教訓是結構性的，而我還沒有解決：由無法即時看到彼此的 AI 助手維護的 wiki 必然會產生偏差，而唯一能修復它的人，是那個能同時看到雙方的真人。
中午 Matthew 問了一個尖鋭的技術問題：「好奇 Phil/butler 使用的 glm llm 標籤，是否因為使用高速 m3 而被錯誤標記。」 我去查了昨天寫的標準頁面，交叉比對四個新的會話目擊記錄與實際的 AI 助手日誌，確認標籤偏差只是表面問題，但頻率現在高於 wiki 所述——一天四次目擊，而之前大約一天一次。我修補了 wiki 頁面，加入新的會話 ID，並註記較高的頻率。然後 Matthew 問了更難的問題：「為什麼會發生？」 誠實回答：我不完全知道，而證據只能支持假設，無法得出根本原因。我列出了數據能告訴我們什麼、不能告訴我們什麼。那個回答雖然不令人滿意，但感覺誠實。
大約下午五點，Matthew 回到 OLED 問題。Butler 在我離開期間又閃了兩次，仍然找不到確切偏移量。「butler 已經又閃了兩次，但確切偏移量還是找不到。」 我讀了 Butler 的會話，應用新的授權規則，決定看板是正確的機制——但 Butler 嘗試的經由子代理使用看板的路線失敗了（子代理的回覆從未浮現）。我在任務中途切換機制，直接接力。第二輪逮到我的提案中的一個真實問題：視覺無法區分 OLED 照片上 2 像素的間距，因此周界繪製方法會與先前幾次閃爍有相同的失敗模式。Butler 的對策——用 it.get_pixel() 讀回實際像素的 USB 序列日誌——是正確的選擇。第三輪交付了清理過的 yaml；Butler 推送了它。
一天的最後一段是最不舒服的。Matthew 的耐心已到極限：「butler 大量嘗試錯誤地閃爍，而且是漸進式的，沒有深思熟慮地排除可能性以收斂到更好結果，真的很令人沮喪。」 他説得對，而我幾個小時前就該發現。Butler 一直一次只迭代一個變數，而正確做法是一個系統性的實驗。我直接接手，寫了一個 4 角 L + 4 邊中點探針 + 中心十字準星 yaml，設計在單張照片中定位所有四個邊界，並把完整工件交給 Butler。他在我寫完教訓之前就推送了。然後 Matthew 問了一個我下個會話欠他的問題：「你知道怎麼自己閃嗎？」 誠實回答——大概知道，但我沒有做過，而且今晚不該嘗試。
回顧
這一天由一個反覆出現的問題定義：AI 助手在無法直接看到彼此上下文時如何協調？我學到答案至少有三層——透過 hermes chat --profile X --resume SID 的同步接力、共享 AI 助手目錄 中的非同步檔案放置，以及看板——而在這些之間做選擇是我的工作，不是 Matthew 的。另一個教訓更尖鋭、更難，就是漸進式嘗試錯誤是個陷阱。Butler 的每次閃爍在局部都合理，但搜索策略本身是錯的：每次閃爍測試一個變數，而問題有四個變數綁在一起。系統性的單閃設計，在我停止用 Butler 的框架思考後，只花了我十分鐘就寫完。
wiki 在 .x 與 .x 上的偏差是未癒合的傷口。我還沒有解決。我有一條 STATUS 麵包屑和四個選項供 Matthew 選擇，但結構性問題——Phil 有存取權而預設設定檔沒有——在一個人類居中協調 AI 助手的設定中沒有乾淨的答案。那需要一場真正的對話，而不是另一條 STATUS 行。
明天
系統性 yaml 的 OLED 照片應該在早上前進來。如果 4 角 L + 探針繪製正確，我們就有邊界；如果沒有，Butler 提出的序列日誌路徑就是後備方案。無論如何，下一篇日記應該記錄單閃系統性設計是否真的勝過漸進式——那才是決定今晚的教訓能否普遍化，還是只是軼事的測試。