[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-qdrant-filter-first-rag-design-decoded-zh":3,"article-related-qdrant-filter-first-rag-design-decoded-zh":31,"series-tools-3ead09ec-5656-4165-9bb0-f602add3c409":83},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":23,"views":27,"created_at":28,"published_at":29,"topic_cluster_id":30},"3ead09ec-5656-4165-9bb0-f602add3c409","qdrant-filter-first-rag-design-decoded-zh","Qdrant 讓 RAG 先過濾再找相似","\u003Cp data-speakable=\"summary\">我把 Raunaq 的向量資料庫比較拆成一套 filter-first \u003Ca href=\"\u002Ftag\u002Frag\">RAG\u003C\u002Fa> 做法，直接給你可抄的設計模板。\u003C\u002Fp>\u003Cp>我做 RAG 做到後面，最煩的不是 embedding 不準，而是系統明明看起來都對，實際一加條件就開始鬧脾氣。你要 tenant、要時間區間、要來源限定，結果檢索不是少給，就是給錯，還常常是那種「數學上沒錯、產品上很爛」的輸出。我以前也以為這只是 top-k 調一調的事，後來才發現不是。問題根本在架構：你到底是先找相似，再補過濾，還是先把範圍縮對，再找相似。\u003C\u002Fp>\u003Cp>這次我看的來源是 Raunaq 的 \u003Ca href=\"https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\" target=\"_blank\" rel=\"noopener noreferrer\">Vector Databases for RAG\u003C\u002Fa>，他把 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\" target=\"_blank\" rel=\"noopener noreferrer\">pgvector\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.trychroma.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">ChromaDB\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fqdrant.tech\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Qdrant\u003C\u002Fa> 放在同一個問題底下看：當你的向量查詢一定要尊重 metadata 時，誰是真的能打，誰只是 demo 好看。他沒有講虛的，這點我很買單。\u003C\u002Fp>\u003Ch2>真正難的不是相似度，是子集合相似度\u003C\u002Fh2>\u003Cblockquote>“A real-world vector search isn’t just ‘find similar vectors’ — it’s ‘find similar vectors within a subset.’”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你在 production 裡做的，從來不是純向量搜尋，而是「在某個限制範圍內找最像的內容」。我如果做客服助理，不會想要整家公司最像的工單，我要的是這個 tenant、這個專案、這段時間、這種文件類型裡最像的那幾段。範圍才是主角，相似度只是第二步。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566519640-bdds.png\" alt=\"Qdrant 讓 RAG 先過濾再找相似\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Raunaq 這個切法很重要，因為它把很多 RAG 的假問題直接拆穿。很多團隊在 notebook 裡看起來都很順，一上線就開始怪 embedding、怪 chunking、怪模型。其實不是。真正的問題是你把「語意排序」跟「權限\u002F範圍控制」混在一起了。向量索引懂語意，metadata 懂條件，這兩個東西本來就不是天生會合作的。\u003C\u002Fp>\u003Cp>我之前做過一個多租戶知識庫，早期偷懶，直接一張向量表加一個 tenant_id 欄位就上了。小流量時還行，等到某個 tenant 的文件量暴增，檢索品質就開始飄。明明應該回 10 段，結果有時候只回 3 段，有時候回 10 段但一半沒用。最煩的是 log 看起來完全正常，因為資料庫真的只是照你的規則在跑。\u003C\u002Fp>\u003Cp>實操寫法很簡單：在選向量庫之前，先把「子集合規則」寫清楚。不是先決定 embedding model，也不是先挑 chunk size，而是先回答這幾件事：\u003C\u002Fp>\u003Cul>\u003Cli>你有哪些必須套用的 filter？\u003C\u002Fli>\u003Cli>這些 filter 的選擇性高不高？\u003C\u002Fli>\u003Cli>這些條件會不會常變？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你答不出來，就先別急著選產品。你是在盲選儲存架構，不是在做技術決策。\u003C\u002Fp>\u003Ch2>先查再過濾，最容易把 recall 偷偷弄爛\u003C\u002Fh2>\u003Cp>pgvector 這條路我很熟，也不是不能用。它的優點很直白：你本來就跑 Postgres，資料、權限、交易、運維都在同一套裡，簡單到讓人舒服。問題是很多人把它拿去做有嚴格 filter 的 RAG，然後還期待結果穩定，這就有點想太多了。\u003C\u002Fp>\u003Cp>Raunaq 講的 post-filtering 很關鍵：先做向量 top-k，再把 metadata filter 套上去。聽起來很省事，因為你吃到了向量索引的速度；但只要 filter 夠窄，這招就開始漏。你要 10 筆，結果 top-k 裡 8 筆被 filter 掉，最後只剩 2 筆。系統不會跳警告，它只會很安靜地交出一份不完整答案。\u003C\u002Fp>\u003Cp>也就是說，post-filtering 最大的坑不是慢，而是「看起來正常」。你會以為是 embedding 不夠好、chunk 切太大、模型太爛，然後開始亂調參數。其實根本不是模型問題，是你的候選池沒有為 filter 留空間。這種錯很貴，因為你會在錯的地方花很多時間。\u003C\u002Fp>\u003Cp>我之前看過一個內部搜尋專案，團隊一直嫌召回差，最後才發現是 tenant filter 太窄，卻還用一般 top-k 當標準。這種情況下，調再多 embedding 都沒用。你是在用錯的檢索策略硬撐。\u003C\u002Fp>\u003Cp>實操寫法：\u003C\u002Fp>\u003Cul>\u003Cli>如果你一定要 post-filter，就先 oversample，再看過濾後還剩多少。\u003C\u002Fli>\u003Cli>不要只看 top-k，要看「requested k vs returned k」。\u003C\u002Fli>\u003Cli>拿最窄的 tenant、最小的來源集、最嚴的日期區間來測。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果最差情境都穩，才輪得到你談模型品質。\u003C\u002Fp>\u003Ch2>先過濾再找，才是真的尊重條件\u003C\u002Fh2>\u003Cp>ChromaDB 走的是另一條路：先過濾，再在過濾後的集合裡找相似。Raunaq 的描述很清楚，metadata 先走 SQLite，拿到符合條件的 ID，再在這個範圍內做向量搜尋。這不是\u003Ca href=\"\u002Fnews\u002Fcongress-should-treat-fraud-cuts-as-tax-relief-zh\">什麼\u003C\u002Fa>花俏做法，但它有一個很重要的優點：結果是誠實的。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566507447-5iq1.png\" alt=\"Qdrant 讓 RAG 先過濾再找相似\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>翻譯一下就是，如果你的 filter 只命中一小塊資料，系統就只在那一小塊裡找，不會先拿一堆看起來很像、其實不合格的候選來湊數。對 local 開發、原型驗證、小型知識庫來說，這種 predictable 行為其實很舒服。我自己也用過這種設計，因為我當時要的是「先能工作」，不是「先把 infra 搞到很漂亮」。\u003C\u002Fp>\u003Cp>但它的代價也很直接：如果過濾後的集合很大， brute force 會開始痛。你一旦不是在小集合裡找，速度就不會太好看。說白了，Chroma 的強項是簡單和正確，不是大規模 selective query 的效率。\u003C\u002Fp>\u003Cp>Raunaq 也提到 embedded mode 的運作\u003Ca href=\"\u002Fnews\u002F4-ways-microsoft-is-building-agentic-apps-zh\">方式\u003C\u002Fa>很方便，但在某些 crash 窗口裡，metadata 跟向量索引的狀態可能會讓你不太安心。這種事平常不會發生在 demo，通常都發生在你最不想重跑資料的時候。很煩，但這就是實務。\u003C\u002Fp>\u003Cp>實操寫法：\u003C\u002Fp>\u003Cul>\u003Cli>當你要的是 local dev、概念驗證、或小資料集，先用 filter-first 很合理。\u003C\u002Fli>\u003Cli>當你的 filtered subset 會長到很大，就不要硬撐 brute force。\u003C\u002Fli>\u003Cli>如果你很在意查詢結果一定要符合條件，先過濾通常比先向量化更踏實。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Qdrant 之所以順，是因為它從一開始就把 filter 當主角\u003C\u002Fh2>\u003Cp>我看 Raunaq 那篇最有感的地方，是他把 Qdrant 講得很像一個真的有在想 production 的系統。它不是把 metadata 當附屬品，而是把 payload index 跟 vector index 一起設計。這件事聽起來很小，實際上差很多。\u003C\u002Fp>\u003Cp>也就是說，Qdrant 不是先假設「先找相似再說」，而是直接承認 query 本來就是混合型的：你既要語意相似，也要條件符合。它會先用 payload index 找出符合條件的 ID，再讓向量檢索只在這些 ID 裡面跑。這個方向我很認同，因為它不是在補洞，是在一開始就把洞補好。\u003C\u002Fp>\u003Cp>我特別在意 Raunaq 提到的 filter bitmap。這種東西看起來像底層細節，實際上就是檢索正不正確的分水嶺。當 filter 很窄時，系統能不能先把可用候選縮出來，決定了你會不會拿到一堆不該出現的 chunk。這不是「優化」，這是基本功。\u003C\u002Fp>\u003Cp>Qdrant 還有一個我很吃的點：它不是只給你一種儲存姿勢。in-memory、memory-mapped、on-disk 都有，這表示你可以依資料量跟機器條件調整，不必每次都把 RAM 當信仰。我個人會先偏向 mmap，讓 OS 幫你做快取，少一點自己手動照顧記憶體的痛苦。\u003C\u002Fp>\u003Cp>實操寫法：如果你的產品有多租戶、ACL、每人不同可見範圍、或很明確的 metadata 條件，從一開始就把 filter-aware engine 放進候選。不要等到系統長歪了才補。重構 retrieval schema 比你想像中更煩，尤其是已經有使用者在上面跑的時候。\u003C\u002Fp>\u003Ch2>分段儲存讓 Qdrant 比較不像紙糊的\u003C\u002Fh2>\u003Cp>Raunaq 的圖我也很喜歡，因為它把 Qdrant 的 segmented storage 講得很清楚。這不是\u003Ca href=\"\u002Fnews\u002Fwhy-lisa-mcclain-committee-assignments-matter-zh\">什麼\u003C\u002Fa>簡報上好看的架構圖而已，它直接影響你在大量寫入下，系統會不會開始抖。\u003C\u002Fp>\u003Cp>翻譯一下就是：新資料會先進到可追加的 segment，背景再慢慢做優化、合併、重建，不需要整個 collection 停機重來。這跟那種「先停機再重建索引」的做法差很多。我真的很不喜歡後者，因為它把日常營運變成維護排程，然後大家還得假裝這很正常。\u003C\u002Fp>\u003Cp>分段儲存的價值不只是在寫入快，而是它讓系統可以邊長大邊維持可用。對 RAG 來說，資料不是固定不動的。文件會一直進來、刪掉、更新、重排。如果你的檢索層在這種情況下容易失真，那你再會調 embedding 也沒用。\u003C\u002Fp>\u003Cp>我之前碰過一個文件平台，白天一直 ingest，晚上還要被搜尋。結果一到重建索引時間，整個 retrieval 就像踩到香蕉皮。後來我才真正理解，RAG 的問題不是只看 query latency，而是看它在「持續變動」下還能不能維持正常。\u003C\u002Fp>\u003Cp>實操寫法：\u003C\u002Fp>\u003Cul>\u003Cli>問清楚資料庫怎麼處理 writes、compaction、index rebuild。\u003C\u002Fli>\u003Cli>如果答案聽起來像要排維護窗口，先小心。\u003C\u002Fli>\u003Cli>把「10M inserts、delete、tenant churn、bad deploy」都拿來想一遍。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你會發現，很多系統不是不能用，是一碰到真實營運就開始露餡。\u003C\u002Fp>\u003Ch2>選型不要看品牌，要看你的 filter 痛點\u003C\u002Fh2>\u003Cp>Raunaq 這篇最有用的地方，不是幫你選出唯一答案，而是逼你承認：不同資料庫對 filter 的態度真的不一樣。你如果把這件事看成「哪個向量庫比較紅」，那你大概會選錯。\u003C\u002Fp>\u003Cp>我自己的簡化版判斷是這樣：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>pgvector\u003C\u002Fstrong>：你本來就重度依賴 Postgres，filter 很鬆，想把運維壓力壓到最低。\u003C\u002Fli>\u003Cli>\u003Cstrong>ChromaDB\u003C\u002Fstrong>：你在做 local dev、原型、或小型資料集，想先把流程跑通。\u003C\u002Fli>\u003Cli>\u003Cstrong>Qdrant\u003C\u002Fstrong>：你的檢索本身就高度依賴 filter，多租戶、權限、條件查詢是日常，不是邊角料。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我不是在說 pgvector 不行。相反，我覺得它在很多場景都很合理，尤其是你本來就活在 Postgres 世界裡的時候。但如果你的產品核心就是「在一堆條件裡找對內容」，那你就不要再拿一個只是在資料庫外面順手補向量能力的方案硬撐。那通常會變成後面幾個月的技術債。\u003C\u002Fp>\u003Cp>實操寫法：先寫你的 95th percentile query。不要寫抽象需求，直接寫真實 query：\u003C\u002Fp>\u003Cul>\u003Cli>這個 tenant 有多少文件？\u003C\u002Fli>\u003Cli>這個 filter 平均命中多少比例？\u003C\u002Fli>\u003Cli>最窄的條件會縮到多小？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你連這些都沒算過，就先不要選庫。你不是在選工具，你是在賭未來會不會被自己打臉。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Filter-first RAG 設計模板（可直接貼到 design doc）\n\n## 1. 先定義子集合，不要先談 embedding\n- tenant_id：必填 \u002F 選填\n- source：必填 \u002F 選填\n- date_range：必填 \u002F 選填\n- acl_rule：必填 \u002F 選填\n- selectivity：\n  - broad：> 50% corpus\n  - medium：5%–50%\n  - narrow：< 5%\n\n## 2. 依 filter 選檢索策略\n- broad filter：post-filtering 可接受\n- medium filter：先 oversample，再驗證 recall\n- narrow filter：優先 filter-first \u002F filter-aware retrieval\n\n## 3. 每個 chunk 都要帶 metadata\n{\n  \"id\": \"chunk_123\",\n  \"tenant_id\": \"tenant_a\",\n  \"source\": \"docs\",\n  \"doc_id\": \"doc_456\",\n  \"created_at\": \"2026-06-02T00:00:00Z\",\n  \"tags\": [\"billing\", \"policy\"],\n  \"embedding\": [\u002F* vector *\u002F],\n  \"text\": \"chunk text here\"\n}\n\n## 4. 檢索合約\nInput:\n- query_text\n- filters\n- top_k\n\nOutput:\n- results 必須符合 filters\n- 系統可內部 oversample\n- 若不足 top_k，允許回傳較少結果，但要明確標示\n\n## 5. 資料庫選型規則\n- pgvector：已經在用 Postgres、filter 較鬆、想少一套運維\n- ChromaDB：local prototyping、小資料集、要快點跑起來\n- Qdrant：selective filters、多租戶、ACL、production retrieval\n\n## 6. 必測案例\n- no filter\n- single tenant filter\n- highly selective tenant filter\n- date range filter\n- tenant + source filter\n- worst-case tenant with smallest corpus\n\n## 7. 要記錄的 metrics\n- requested_top_k\n- returned_count\n- filter_selectivity\n- latency_ms\n- recall_on_test_set\n- fallback_used\n\n## 8. Prompt \u002F 生成規則\nOnly pass chunks that satisfy the filter.\nIf fewer chunks are available, do not invent missing context.\n\n## 9. 決策備註範例\n- \"We chose Qdrant because our retrieval is tenant-scoped and filters are often selective.\"\n- \"We chose pgvector because our data already lives in Postgres and filters are broad.\"\n- \"We chose ChromaDB for local prototyping and offline document search.\"\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段我會直接貼進自己的設計文件裡，因為它逼團隊先把檢索條件講清楚，再來談工具。這樣至少不會一開始就把問題做歪。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\" target=\"_blank\" rel=\"noopener noreferrer\">https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\u003C\u002Fa>。我上面對 pgvector、ChromaDB、Qdrant 的整理是衍生解讀；模板與實作寫法是我根據同一個 filter-first 觀念重寫成可直接拿去開 design review 的版本。\u003C\u002Fp>","我拆 Raunaq 的向量資料庫比較，整理出 filter-first RAG 的選型邏輯與可直接貼上的設計模板。","raunaqness.substack.com","https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566519640-bdds.png","tools","zh","d1e26605-8b72-4be1-833e-c57583968f37",[17,18,19,20,21,22],"Qdrant","RAG","vector database","metadata filter","pgvector","ChromaDB",[24,25,26],"RAG 的核心不是純相似度，而是子集合內的相似度。","filter-first 比 post-filtering 更適合嚴格條件與多租戶場景。","選向量庫要先看 filter selectivity 與 query shape，而不是品牌。",0,"2026-06-04T09:47:59.450347+00:00","2026-06-04T09:47:59.422+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":32,"relatedLang":42,"relatedPosts":46},[33,35,37,38,40],{"name":18,"slug":34},"rag",{"name":17,"slug":36},"qdrant",{"name":21,"slug":21},{"name":19,"slug":39},"vector-database",{"name":20,"slug":41},"metadata-filter",{"id":15,"slug":43,"title":44,"language":45},"qdrant-filter-first-rag-design-decoded-en","Qdrant’s filter-first RAG design, decoded","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"1a92ac0a-75ea-4877-874d-4a309cd0085b","nvidia-research-gpu-template-zh","NVIDIA 研究頁把 GPU 資源變模板","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780567412863-e8oq.png","2026-06-04T10:02:58.043845+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"7b5e6965-307e-4492-bf65-d922cd7818ad","anthropic-code-review-tool-ai-generated-code-zh","Anthropic 讓 AI 程式變可審","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780563813320-5wc7.png","2026-06-04T09:02:56.999212+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"bef47dbc-b0b4-439e-bae9-abe9473a321c","wei-shen-me-tether-ba-ben-di-ai-ji-yi-tui-jin-ri-chang-zhuan-zh","為什麼 Tether 把本地 AI 記憶推進日常裝置是對的","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780542170805-opi6.png","2026-06-04T03:02:19.599329+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"d3ec03a8-a805-4a21-9826-72a74a72b625","databricks-model-serving-llm-deploy-guide-zh","Databricks Model Serving 讓 LLM 部署變簡單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525998117-7ur8.png","2026-06-03T22:32:51.005996+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"4dd225a8-bf6c-4768-a486-a27956c7033d","opencode-digitalocean-model-freedom-zh","OpenCode+DigitalOcean 讓你切換模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525116428-1q7g.png","2026-06-03T22:18:06.969758+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"4bdcf208-fb80-484e-b4b6-06af035a6df1","modulate-aws-voice-chats-into-signals-zh","Modulate 用 AWS 把語音聊天做成訊號","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780519733892-rxue.png","2026-06-03T20:48:22.697917+00:00",[84,89,94,99,104,109,114,119,124,129],{"id":85,"slug":86,"title":87,"created_at":88},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":130,"slug":131,"title":132,"created_at":133},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]