LLM 只能是驗證者，不能是決策者
LLM 應該驗證符號決策，而不是替代它——這是在關鍵業務上用好大模型的分界線。
AI
後台任務的 Token 成本會被低估十倍
後台自動化任務的 Token 成本會因為 Session Context 累積而被低估十倍，需要在架構設計階段就考慮 Context 清理策略。
我把 memcite 裝進自己的專案，記錄下真實的數字
我把 memcite 裝進自己的專案，記錄下真實的數字
上一篇我介紹了 memcite 的設計理念：AI agent 的記憶需要出處，出處需要被驗證。
理念很好。但真的有用嗎？
這篇是導入心得。我把 memcite 裝進一個 6,000 行的 Python 專案（mk-brain，我的個人知識管線），從安裝到測試，完整記錄每一個數字。
導入：零侵入，52KB
pip install memcite
cd ~/GitHub/mk-brain
am add "6 層 pipeline：Parse → Review → Enrich → Embed → Report → Search" \
--file README.
從「能記住」到「能審計」：為什麼 AI 記憶層需要 Source Code 級歸因
GitHub Copilot 在 2025 年底推出了 Memory 功能。它會記住你的 repo 慣例、coding style、常用 pattern，下次寫 code 時自動套用。
這是一個正確的方向。但它是閉源的。
所以我做了一個開源版：memcite。
但這篇文章不是要推銷工具。我想聊的是一個更根本的問題：為什麼現有的 AI 記憶層都在解決錯的問題？
所有人都在解決「記住」，沒人在解決「記對」
打開任何一個 AI memory layer 的 README，你會看到類似的 pitch：
* mem0：「讓 AI 記住使用者偏好，跨 session 持續學習」
* Zep：「時序知識圖譜，知道事情發生的先後順序」
* LangMem：「過程記憶，
當 AI 不只是寫 code，而是成為你的基礎設施副駕駛
最近我收到一份自動分析報告，統計了我過去兩週使用 Claude Code 的紀錄：115 個 session、1,497 則訊息、3,709 次 Bash 指令。
看完之後，我有一個很強烈的感覺——我其實不是在用 AI 寫程式，而是在和 AI 一起操作系統。
不是 AI Coding，是 AI Operations
很多人談 AI coding，腦中浮現的畫面是這樣：
工程師 → AI → 產生 code
但我最近真正的工作方式，比較像：
人類 → AI → 基礎設施 → 服務
我讓 AI 做的事，有很多以前需要工程師手動完成：SSH 到不同機器部署
Google Workspace CLI 的真正價值不在自動化，在於動態適應
Google Workspace CLI 從 Discovery Service 動態生成命令，配合 AI 技能降低操作門檻。真正的價值在於架構的自我演進能力，而不是自動化功能本身。
RAG 的選擇不是技術問題，是資源問題
Agentic RAG 不是技術進步，是資源消耗。選它之前，先確認你有足夠的預算和清晰的領域邊界。