RAG 的去識別，為什麼不能只做遮蔽
把每個人名都換成 [REDACTED] 很安全，也把語料變成廢物。「Sarah 把案子轉給誰」這個問題從此沒有答案，因為所有人長得一模一樣。這篇談 RAG 場景該用的做法：keyed HMAC 的穩定替身、遮住身分但保留關係，以及我在實作時踩到的三個坑。
Hi, I'm Eric! 👋
9+ 年經驗 130 篇文章
我是一位熱愛程式設計的開發者，專注於 Web 開發與 AI 技術應用。 喜歡透過文字分享學習心得與開發經驗，也熱衷於打造實用的產品來解決生活中的問題。
最新文章
教 25 位零程式基礎老師建站的三天
教育部公民營計畫的三天課程「教學 4.0：用 AI 打造自動化數位職人官網」。25 位老師來自商業、觀光、汽修與特殊學校，沒有一個人寫過程式。第一天光是新增一篇文章就要改半天的老師，第三天用 MCP 讓 LLM 自動產出一整個系列。這篇記錄那三天真正發生的事：落差怎麼處理、為什麼先教原理再給工具，以及這類課程真正的天花板在哪裡。
用 Postgres + pgvector 做一個會標出處的 RAG
RAG 拆開就三件事：切塊存起來、依問題找相關的塊、把塊餵給模型生成。資料量還沒到上千萬筆，你已經在用的 Postgres 加上 pgvector 就夠了，還能少維運一個外部服務。這篇用 TypeScript 從零做一個會標出處的 RAG：用 Postgres 存向量、一句 <=> 檢索、一次帶 citations 的生成，答案直接對回原文。
換一個模型只改一行：把 LLM 呼叫收進單一抽象層
模型換得比套件還快，但只要把所有 LLM 呼叫收進單一抽象層，換模型、換供應商對你的應用程式就只是改一個設定值。這篇用中立介面、轉接器、工廠三個步驟，把供應商細節擋在商業邏輯外面，附上可以直接抄的 Anthropic SDK 範例，也講清楚這個做法的邊界。
一個 AI 不夠用的時候：認識 Dynamic Workflows
有些事一個 AI、一份 SOP 扛不住：掃整個專案的 bug、搬幾百個檔案、查一個要交叉比對幾十個來源的問題。Dynamic Workflows 讓 AI 照一份腳本，調度幾十上百個分身幫你做事，中間成果它自己收著，只把結論交給你。這篇用工頭調班的比喻，帶你認識它是什麼、何時該用、跟 skill 和子代理差在哪，不寫程式也能懂。
用 Lovable 做 App 的第一件事不是寫功能，是設好這三個環境
Lovable 能在 30 分鐘做出一個能跑的 app，但叫它加功能就直接推 production，沒有測試也沒有退路。這篇記錄我怎麼用 Lovable + Supabase + GitHub + Vercel 搭起 dev / staging / production 三層環境，含 GitHub Actions 自動跑 migration、Vercel per-branch 變數，以及 Lovable 包過的 TanStack Start 上 Vercel 真正跑通的部署配方與踩雷對照表。