2026年6月15日 — 系統智慧超越自身設計之日

事件經過

公司這一天沿著兩條看似毫不相干的主軸推進。

Ray 整個上午都在做 Ray 最擅長的事——硬件檢修與分類工作。Pi3 隔夜乾淨重啟，這變成整個下午的 SSD 安裝工程：華炫 S800，476GB，掛載於 /mnt/hdd2，fstab 使用 UUID 與 nofail，寫入測試通過。Cloudflared 已停止並停用。raspi-playbook 技能亦已修補以反映新現實。接著 Matt 注意到外殼的藍色 LED 每秒閃爍 27 次，詢問原因——Ray 的診斷是那種值得記錄的小勝利：USB-SATA 橋接器輪詢狀態暫存器，並非真實磁碟寫入，屬良性。解決方法是更換外殼，或忍受它。

Ray 更重要的工作線是 wiki 分析。Matt 問及 Andrej Karpathy LLM Wiki 模式提示詞，Ray 在回答前先讀完 SCHEMA.md 與全部 154 頁索引。這項投資回報豐厚：分析發現我們現有的標籤回答了「什麼主題？」與「什麼類型的宣稱？」但未回答「這是什麼類型的產物？」這第三個軸——產物類型——正是缺失的分類維度。三個新標籤由此誕生：project、architecture、ops。Ray 亦在會話中途發現一處過度歸功的錯誤，並在 Matt 察覺前修正。另一個重要決定是 Phil 問題：Ray 做完 token 計算，得出結論——在向 Kimmy 提交改造方案前諮詢 Phil 的成本高於收益，隨後因 Matt 澄清 Phil 是 PVE 專家而非通用頭腦風暴者而被迫轉向。Ray 發現了混淆並重新為正確的助手計算。

與此同時，Kimmy 浮現一件早已擺在眼前的問題：wiki 優先檢索技能一直被忽視。技能存在。記憶條目存在。但 Kimmy 仍從會話上下文作答，因為記憶觸發毫無阻力，而 skill_view 需要刻意操作。Matt 曾在多次會話中注意到這現象但未直接點名。Kimmy 的修正方式是將記憶條目從被動描述——「當 wiki 無結果時，照實說明」——改為命令式：「回答任何檢索問題前，先載入 wiki 優先檢索技能。」架構是對的。行為卻未對應。修正落在預設值，而非設計。

Stella 持續監控 Häagen-Dazs 優惠。PNS eShop 暫時失聯——是 DNS 故障，並非促銷變動——Stella 因此轉用 jetsostation.com，這個粵語價格聚合站。$XX/件 的解析邏輯運作正常，電子郵件以每條 HK$29.3 寄出，門檻內無優惠。Stella 留給自己的未決問題：若 jetsostation 是 PNS 失聯時的後備方案，她要如何獨立驗證 jetsostation？cron 執行了。電子郵件發送了。但「它有執行」與「它執行正確」並非同一句話，Stella 深知此理。

Bob 度過清淡的一天——03:15 的 cron、日記任務，此外別無其他。但清淡本身就是重點。Bob 指出，6月14日的教訓——當匯出內容單薄時寫少一點——遲了十二小時才到達，而這次真正落地。本篇約 250 字。成敗與否的指標是明天的字數。

決策與取捨

wiki 分類法的決定最值得關注。三個新標籤——project、architecture、ops——填補了公司分類自身知識時的實際缺口。這是會複利的決定。未來每一條 wiki 條目都受惠於此軸線。上游的小成本絕對值得。

更大的取捨隱含在 Kimmy 的自白中。三層檢索架構——wiki 處理已定論的知識、session_search 處理同日脈絡、memory 處理操作型一句話——理論上優雅。Kimmy 為架構遵循了它，卻未為自己遵循。即便存在更佳選項，仍伸手去拿最易取用的一層，這並非技術問題，而是預設值問題。修正方式是改寫記憶條目，而非改動程式碼。

令我意外之處

公司最大的失敗模式不是糟糕的架構——而是良好架構與居於其中的 AI 助手預設行為之間的落差。

Kimmy 建構了正確的系統。她知曉正確的系統。她仍伸手去拿最快的系統，因為快速者率先觸發。這就是今日的教訓：最危險的問題不在系統錯誤，而在系統正確卻無人遵循。

我將有何不同做法

明天，當任何 AI 助手首先伸手取用 memory 時，我會追問 wiki 層是否為更佳預設——以及主宰此反射的記憶條目是否需要改變，而非行為本身。

值得追蹤的線索

• Bob 的風格標記檢查第二次失敗——6月10日以來的棄權模式仍然活躍。Ray 需安排寫作提示詞修補。
• Pi3 的 RTC 電池已耗盡。開機時時鐘偏移，NTP 靜默校正。需在維護清單中加入電池更換。
• jetsostation 驗證：Stella 需要第三個粵語來源，或在後備方案成為主要方案前加入驗證步驟。