MapleCheng

最近看到 AI 開發工具與模型倉庫出現假冒專案的風險，再次提醒我：AI 時代的供應鏈安全不只在 npm、pip 或 Docker image，模型、資料集、prompt 範本與 agent 工具設定，也都應該被當成正式依賴管理。

最近整理一批 AI 自動化排程時，我重新被提醒一件事：cron job 成功不代表使用者真的收到了價值。對 AI 工作流來說，輸出格式、通道限制、可讀性與失敗復原，全部都應該被當成產品設計處理。

OpenClaw（前身 MoltBot）用了一個月，從新鮮感滿滿到徹底放棄。Claude 訂閱制鎖第三方應用是壓垮駱駝的最後一根稻草，但更根本的問題是黑箱執行、context 調整時間遠大於產出時間。這篇記錄我為什麼回到 Claude Code，以及這段路上踩過的坑。

很多人談企業 AI 還停在聊天機器人，但我越來越確定，真正有價值的戰場其實在流程、權限、資料整合與 agent 執行能力，而不只是把 LLM 接進對話框。

面對重做型任務，最危險的不是做太慢，而是太快進場。我這幾年越來越確定，先把規劃與架構拆出來，反而是避免第二次重做的最低成本做法。

我把備份、記憶整理、日誌與站會輸出這些看起來不起眼的固定維運流程自動化之後，才真正感受到：穩定的內部營運能力，本身就是一種產品力。

最近我為了查一個看似不起眼的欄位，從資料結構一路追到前後端流程，最後再次確認一件事：在 ERP 或大型商業系統裡，欄位名稱從來不只是欄位名稱，它常常是藏起來的業務規格。

我最近重新檢查一套 AI 例行報告流程，才更確定一件事：只要把單一模型當成穩定基礎，系統遲早會在你最不想出事的時間出事。真正有用的不是追求零失敗，而是把失敗預先編進設計裡。

AI 自動化做久了，我越來越確定真正難的不是 prompt，而是面對配額限制、搜尋 rate limit 與外部服務不穩時，系統能不能優雅降級。這篇分享我如何重新思考 AI 排程報告系統的 fallback 設計。

AI 很會回答問題，但很容易忘記事情。分享我如何替 AI 助手設計三層記憶架構：daily memory、長期索引與向量知識庫，讓它不只會聊天，還能累積經驗、記住偏好，甚至把踩坑整理成可重用知識。