[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-identity-protocols-private-zero-knowledge-kyc-zh":3,"article-related-identity-protocols-private-zero-knowledge-kyc-zh":29,"series-tools-99232fc1-017e-4b71-84a9-ceec7421fbe8":72},{"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":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":11},"99232fc1-017e-4b71-84a9-ceec7421fbe8","identity-protocols-private-zero-knowledge-kyc-zh","10 個身分協議把 KYC 變私密","\u003Cp data-speakable=\"summary\">以前 KYC 要你一再上傳文件，現在可以改成可重用的零知識證明。\u003C\u002Fp>\u003Cp>我碰身分和合規這塊很久了，最煩的就是流程看起來很正常，實際上整個爛掉。傳護照、等審核、過關、下一個 app 再傳一次，像在重演同一齣鬧劇。每家都想留一份副本，每次換地區又要補一次文件，連自拍和地址證明都像在比誰比較會折騰使用者。更嘔的是，很多情況根本不需要把原始\u003Ca href=\"\u002Fnews\u002Flearning-from-multiple-data-providers-zh\">資料\u003C\u002Fa>散得到處都是，卻因為整合最省事，就一路外流。\u003C\u002Fp>\u003Cp>我後來開始看 zero-knowledge KYC，才真的覺得舊流程有多笨。使用者不用交出原始文件，只要證明一件事是真的：年滿 18、沒在制裁名單、是唯一真人、符合合格投資人資格、住在某個司法管轄區。這篇的起點來自 \u003Ca href=\"https:\u002F\u002Ffinancefeeds.com\u002F10-best-web3-identity-protocols-for-zero-knowledge-kyc-verification\u002F\">Tobi Opeyemi Amure 在 FinanceFeeds 的整理\u003C\u002Fa>，我把它當成地圖，不當聖經。好用的地方是，它把同一個難題拆成不同團隊各自的解法。\u003C\u002Fp>\u003Ch2>零知識 KYC 到底省掉什麼\u003C\u002Fh2>\u003Cblockquote>Web3 身分協議讓使用者在不分享原始個資的前提下，證明自己符合 KYC。\u003C\u002Fblockquote>\u003Cp>白話一點就是：app 拿到的是答案，不是你的文件。這才是重點。零知識證明讓錢包可以證明某個敘述為真，卻不透露底層資料。我要證明年滿 21，驗證端不需要知道我的生日；我要證明已做過 KYC，每個 dApp 都不必再存一次護照；我要證明自己不是機器人或羊毛黨，系統也不一定要知道我的法定姓名。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785261802546-rgpn.png\" alt=\"10 個身分協議把 KYC 變私密\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己在想 tokenized asset 的 onboarding 時，這個痛點特別明顯。合規團隊要確定性，產品團隊要低摩擦，使用者只想不要再傳第五次證件。舊模型逼大家選邊站，通常最後是使用者輸。ZK 身分至少給雙方一個能用的結果：驗證方拿到密碼學保證，使用者把原始資料留在比較近的地方。\u003C\u002Fp>\u003Cp>還有一個常被低估的點是安全。集中式 KYC 資料庫超肥，等於把護照、駕照、地址證明堆成一個等著被打的靶子。ZK 不會讓風險消失，但它會改變風險形狀。你存得更少、暴露得更少、預設就少發很多東西出去。\u003C\u002Fp>\u003Cp>實操上，我會先把 app 真正需要的 claim 拆開。不要把「KYC」當成一個東西。拆成年齡、居住地、唯一性、合格投資人、制裁狀態，還有其他政策要求。然後每一項都對應到 proof，而不是文件。你如果說不出為什麼非得拿原始檔，通常就是不需要。\u003C\u002Fp>\u003Cul>\u003Cli>用 proof 驗證資格，不要整包身分資料。\u003C\u002Fli>\u003Cli>驗證問題要夠窄。\u003C\u002Fli>\u003Cli>一開始就設計成可重用。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>World ID 解的是唯一性，不是整套文件\u003C\u002Fh2>\u003Cp>FinanceFeeds 提到 \u003Ca href=\"https:\u002F\u002Fworld.org\u002Fworld-id\" target=\"_blank\" rel=\"noopener noreferrer\">World ID\u003C\u002Fa>，由 \u003Ca href=\"https:\u002F\u002Fwww.toolsforhumanity.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Tools for Humanity\u003C\u002Fa> 推動，靠零知識證明和 Semaphore 隱私層，讓使用者證明自己是唯一真人，卻不揭露身份。文章也提到新的 NFC 護照驗證和 World ID 4.0 的 per-app nullifier、SNARK 驗證等功能。\u003C\u002Fp>\u003Cp>白話一點就是，World ID 不是想當你的完整 KYC 系統。它想回答一個很煩的問題：這是不是一個真的、唯一的人。這對空投、投票、速率限制、以及任何「同一個人只能算一次」的場景很有用。Orb 很搶眼，但更值得看的其實是隱私模型。app 應該知道「這個錢包代表一個真人」，就這樣，不要多拿。\u003C\u002Fp>\u003Cp>我喜歡這種切法，因為它避開一個常見錯誤：硬把一個協議\u003Ca href=\"\u002Fnews\u002Fzhihu-fields-awards-roundtable-zh\">做成\u003C\u002Fa>萬能工具。唯一性、法定身分、合規審查根本不是同一題。你把它們全塞一起，最後只會得到一坨難以信任、也難以跟法務解釋的東西。World ID 比較適合用在你需要抗 Sybil，但不一定需要正式 KYC 的地方。\u003C\u002Fp>\u003Cp>實操上，如果你的產品容易被重複帳號或農場攻擊，就先上一層唯一性驗證。空投、DAO 投票、claim 系統都很典型。不要把唯一性硬說成合規。如果監管真的要看身份，你還是得另外做一條正式驗證路徑。\u003C\u002Fp>\u003Ch2>Privado ID 比較像能上線的堆疊\u003C\u002Fh2>\u003Cp>FinanceFeeds 指到 \u003Ca href=\"https:\u002F\u002Fprivado.id\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Privado ID\u003C\u002Fa>，也就是以前的 Polygon ID，底層和 \u003Ca href=\"https:\u002F\u002Fwww.iden3.io\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Iden3\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fdocs.circom.io\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Circom\u003C\u002Fa> 綁在一起。文章也提到 reusable credentials、selective disclosure，還有 Verifier SDK、Issuer Node、Wallet SDK 這類開發工具。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785261803430-ll4r.png\" alt=\"10 個身分協議把 KYC 變私密\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>白話一點就是，Privado ID 比較像給真的要整合的人用，不是只做 demo 給你看一眼。很多身分專案我都看過停在「看，有 proof 了」這一步，然後就沒了。這很可愛，但 production 要的是發證、錢包保存、驗證，以及怎麼塞進既有政策流程。這套的好處是夠有主見，你可以發 credential、讓使用者持有、之後只驗你要的 claim。\u003C\u002Fp>\u003Cp>selective disclosure 這件事，實際上比行銷文案重要太多。使用者如果已經證明過年齡或居住地，驗證端就不該拿到整份文件。這不只是隱私表演，還直接降低責任和外洩半徑。你的 app 越能接受 yes\u002Fno，而不是檔案上傳，就越少背一堆不必要的包袱。\u003C\u002Fp>\u003Cp>我在想受監管的 \u003Ca href=\"\u002Ftag\u002Fdefi\">DeFi\u003C\u002Fa> onboarding 時，這個模式特別有用。業務想要的是「KYC 完成」，但政策真正要的是「使用者不在封鎖地區，且符合最低帳戶條件」。這兩句差很多。可重用 credential 可以滿足政策，卻不用把一堆額外身分資料拖進系統。\u003C\u002Fp>\u003Cp>實操上，如果你做的是會反覆驗證的 app，就直接以 reusable credential 為中心設計。issuer \u002F verifier 分工要清楚，wallet 端 UX 要簡單到不會被客服罵。上線前，把哪些 claim 可以重用、哪些必須每次重驗，寫死在文件裡。\u003C\u002Fp>\u003Ch2>Human Passport 賣的是聲譽，不是政府文件\u003C\u002Fh2>\u003Cp>FinanceFeeds 把 \u003Ca href=\"https:\u002F\u002Fwww.human.tech\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Human Passport\u003C\u002Fa>（前身 Gitcoin Passport）描述成把錢包歷史、社群帳號、開發者活動和已驗證 attestations 組成隱私保護型聲譽分數的協議。文章還寫到它有超過 3400 萬個零知識憑證、約 200 萬使用者，並協助保護超過 2 億美元的空投免於 Sybil 攻擊。\u003C\u002Fp>\u003Cp>白話一點就是，不是每個身分問題都需要掃護照。有時候你要的是信任訊號，這是另一種東西。空投、補助、社群門禁，很多時候在意的不是你的法定身分，而是同一個人不要假裝成五十個人。Human Passport 有意思的地方在於，它把身分當成一組訊號，而不是單一政府文件。\u003C\u002Fp>\u003Cp>我一直覺得這種做法很適合社群系統，因為它比較接近線上信任的真實樣子。沒人只靠一張文件認識你，大家看的是行為、歷史、背書，再加上一點點運氣。關鍵是怎麼做得不變成監控湯。你如果能在保留底層訊號隱私、或至少最小揭露的前提下算出聲譽，整體 tradeoff 會漂亮很多。\u003C\u002Fp>\u003Cp>實操上，聲譽適合拿來做 anti-abuse，不適合拿來做法遵 onboarding。補助、投票、獎勵機制都很對味。規則要能接受身分不完美，因為聲譽本來就是機率式的。還有，分數就是分數，不是法律身分查核，這點要講白。\u003C\u002Fp>\u003Cul>\u003Cli>適合：anti-Sybil、社群門檻、獎勵。\u003C\u002Fli>\u003Cli>不適合：需要正式身分的受監管 onboarding。\u003C\u002Fli>\u003Cli>最好搭配：另外一條合規驗證流程。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>zkPass 把 Web2 登入變成可攜 proof\u003C\u002Fh2>\u003Cp>FinanceFeeds 說 \u003Ca href=\"https:\u002F\u002Fzkpass.org\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">zkPass\u003C\u002Fa> 用 TransGate extension 和 zkTLS，把登入中的 Web2 session、銀行帳戶、交易所或既有 KYC 供應商轉成可攜的零知識證明。文章也提到它有一套 Compliance Suite，主打 GDPR 和 CCPA 友善的 KYC 給 fintech 與交易所。\u003C\u002Fp>\u003Cp>白話一點就是，zkPass 想把你已經拿得到的資料解鎖，而不是逼使用者把同一份東西重新上傳到新系統。這招很實際。如果某人已經在銀行、交易所或薪資平台做過 KYC，為什麼到了 \u003Ca href=\"\u002Ftag\u002Fweb3\">Web3\u003C\u002Fa> app 還要重交一次？proof 可以跟著走，原始資料不用跟著跑。\u003C\u002Fp>\u003Cp>我會喜歡 zkPass，是因為它比較像橋，不像要你整\u003Ca href=\"\u002Fnews\u002Ffuerteventura-2026-freestyle-crowned-two-winners-zh\">個重\u003C\u002Fa>寫的潔癖方案。很多團隊根本不是從零開始，他們早就有 Web2 身分 rails、瀏覽器 session、老舊的合規供應商。這種情況下，zkPass 的價值是把既有系統接到鏈上驗證，而不是逼你一次改到底。\u003C\u002Fp>\u003Cp>實操上，如果你的使用者本來就活在既有 identity provider 裡，就用 Web2-to-Web3 proof layer。不要讓他們把同一件事證兩次。最容易先落地的通常是帳號年齡、交易所狀態、銀行關係、KYC 完成狀態。如果你的流程本來就依賴 browser session，這是少數不太痛的抽證方式。\u003C\u002Fp>\u003Ch2>Civic 和 idOS 是我會真的想放進產品的老實貨\u003C\u002Fh2>\u003Cp>FinanceFeeds 把 \u003Ca href=\"https:\u002F\u002Fwww.civic.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Civic\u003C\u002Fa> 列進來，說它是老牌身分供應商往 ZK 可重用 KYC 走；也提到 \u003Ca href=\"https:\u002F\u002Fidos.network\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">idOS\u003C\u002Fa>，把它定位成 stablecoin 經濟的 reusable KYC layer。文章說 idOS 讓使用者只要跟有牌照的供應商驗證一次，就能把 credential 在 Aleph Zero、NEAR、Gnosis 這類鏈上重用。\u003C\u002Fp>\u003Cp>白話一點就是，不是每個有用的身分產品都要長得很炫。Civic 的價值在於，舊系統還在，總有人得把它接到新世界。idOS 的價值在於 stablecoin 和 payments 這種場景，本來就最討厭重複驗證。我如果已經跟某個 licensed provider 完成一次驗證，就不想每碰一個新 app 就重做身分。\u003C\u002Fp>\u003Cp>我把這兩個放一起，是因為它們處理的是比較無聊但真的會被採用的部分：延續性。一個幫你從傳統 KYC 過渡，一個幫你把結果跨 app、跨鏈重用。這種基礎設施通常不會最吸睛，但它最容易落地，因為同時幫到合規和使用者。\u003C\u002Fp>\u003Cp>實操上，如果你本來就綁著舊 KYC vendor，不要因為想看起來很純就整個拔掉。先包一層 reusable credential。保留原供應商在它該在的位置，但不要讓使用者在每個產品頁面都重跑一次同樣的檢查。\u003C\u002Fp>\u003Ch2>Self、Humanity、zkMe、ONT ID 各走各的路\u003C\u002Fh2>\u003Cp>FinanceFeeds 另外列了 \u003Ca href=\"https:\u002F\u002Fself.xyz\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Self Protocol\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.humanity.org\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Humanity Protocol\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fzk.me\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">zkMe\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fontid.org\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">ONT ID\u003C\u002Fa>。Self 結合護照 NFC 驗證和零知識證明；Humanity 偏向掌紋生物辨識和更廣的 proof-of-trust；zkMe 把檢查留在使用者裝置上，再回傳可重用 proof；ONT ID 則建立在 W3C decentralized identifiers 和 verifiable credentials 上。\u003C\u002Fp>\u003Cp>白話一點就是，這個市場根本沒有往單一路線收斂。有人要生物辨識，有人要護照驗證，有人要 standards-first 的 DID plumbing，有人想把事情盡量留在裝置端。這很正常，因為身分需求本來就很亂。代幣銷售、\u003Ca href=\"\u002Ftag\u002F穩定幣\">穩定幣\u003C\u002Fa> app、DAO 投票系統，本來就不該用同一種信任模型。\u003C\u002Fp>\u003Cp>我會把這些協議看成是在決定「信任放哪裡」。在裝置端驗證可以降低後端暴露；護照式驗證適合正式身分；DID \u002F VC 標準路線有利於可攜和互通；生物辨識可能幫助唯一性，但使用者接受度和資料敏感度也更高。這裡沒有白吃的午餐，只有不同代價。\u003C\u002Fp>\u003Cp>實操上，先看 claim，再看 logo。你如果需要標準相容性，就找 DID 和 VC 支援；你如果需要唯一性，就看 proof-of-personhood；你如果需要金融場景的可重用合規，就看 credential portability 和 issuer 工具；你如果要跟既有 onboarding 接軌，就先選橋，不要先選夢。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Zero-Knowledge KYC 選型模板\n\n## 1) 我到底要證明什麼？\n- [ ] 唯一真人\n- [ ] 年滿門檻\n- [ ] 不在限制司法管轄區\n- [ ] 合格 \u002F 專業投資人\n- [ ] 已由持牌供應商完成 KYC\n- [ ] 其他：______________________\n\n## 2) 哪種協議適合這個 claim？\n- 唯一性 \u002F 抗 Sybil：World ID, Human Passport\n- 可重用合規憑證：Privado ID, idOS, zkMe\n- Web2-to-Web3 proof 轉接：zkPass\n- 舊 KYC 橋接：Civic\n- 護照 \u002F NFC 驗證：Self Protocol\n- 標準優先 DID \u002F VC：ONT ID\n\n## 3) 哪些資料絕對不要離開使用者？\n- 護照影像\n- 駕照影像\n- 法定姓名\n- 地址\n- 出生日期\n- 帳號資訊\n\n## 4) 驗證端到底需要什麼？\n- 一個 yes\u002Fno\n- 一個有期限的 claim\n- 一個防重複的 nullifier\n- 一個唯一性證明\n- 一個司法管轄區證明\n- 一個 KYC 完成證明\n\n## 5) 整合檢查清單\n- [ ] 用一句話定義政策規則\n- [ ] 每條規則都對應到 proof，不是文件\n- [ ] 決定 proof 在哪裡簽發\n- [ ] 決定 proof 在哪裡保存\n- [ ] 決定 proof 多久失效\n- [ ] 決定 proof 是 app-scoped 還是可重用\n- [ ] 決定怎麼撤銷或更新 credential\n- [ ] 決定後端要記錄什麼\n\n## 6) 我會用的產品規則\n如果 app 可以用密碼學 claim 解決，就不要要原始檔。\n如果 app 真的需要原始檔，就寫清楚原因和可見權限。\n\n## 7) 範例 policy mapping\nPolicy：只有年滿 18 且位於允許國家\u002F地區的使用者才能使用 app。\n\nRequired proof bundle：\n- 年滿 18\n- 國家 \u002F 居住地 claim\n- 來自核准 issuer 的有效 KYC credential\n- 若是 one-account-per-user 流程，可加 nullifier\n\nVerifier response：\n- allow\n- deny\n- reverify\n- manual review\n\n## 8) 可直接貼進 PRD 的決策註記\n我們會在可用密碼學 claim 表達的地方接受零知識憑證作為身分驗證。\n只有在無法用其他方式驗證時，才要求原始身分文件。\n我們會優先使用可重用憑證、選擇性揭露、app-scoped nullifier，而不是重複上傳文件。\n我們會記錄驗證結果，不記錄敏感原始文件。\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段模板我真的會直接丟給 PM、法遵或工程，在 kickoff 前先對齊。它會逼大家把討論從「哪家 vendor 比較強」拉回來，變成「我們到底在證明什麼，哪些資料可以少收」。這才是正事。其他東西，說穿了都是實作細節。\u003C\u002Fp>\u003Cp>FinanceFeeds 的原始整理在這裡：\u003Ca href=\"https:\u002F\u002Ffinancefeeds.com\u002F10-best-web3-identity-protocols-for-zero-knowledge-kyc-verification\u002F\">https:\u002F\u002Ffinancefeeds.com\u002F10-best-web3-identity-protocols-for-zero-knowledge-kyc-verification\u002F\u003C\u002Fa>。我這篇是根據那份整理，加上各專案官方文件做的拆解；框架、取捨分析和可抄模板是我自己整理出來的。\u003C\u002Fp>","我拆 10 個 Web3 身分協議，整理成可直接套用的私密 KYC 比較與落地模板。","financefeeds.com","https:\u002F\u002Ffinancefeeds.com\u002F10-best-web3-identity-protocols-for-zero-knowledge-kyc-verification\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785261802546-rgpn.png","tools","zh","528b77f0-5778-42d7-8c66-abd5e8fbb214",[17,18,19,20,21],"zero-knowledge","KYC","identity protocols","verifiable credentials","Sybil resistance",[23,24,25],"KYC 可以從文件上傳改成可重用的零知識證明。","不同協議解的不是同一題：唯一性、合規、聲譽、Web2 轉接各有用途。","最實用的做法是先定義要證明的 claim，再選協議，不要先選品牌。",0,"2026-07-28T18:02:57.282427+00:00","2026-07-28T18:02:57.252+00:00",{"tags":30,"relatedLang":31,"relatedPosts":35},[],{"id":15,"slug":32,"title":33,"language":34},"identity-protocols-private-zero-knowledge-kyc-en","10 identity protocols let KYC stay private","en",[36,42,48,54,60,66],{"id":37,"slug":38,"title":39,"cover_image":40,"image_url":40,"created_at":41,"category":13},"64e7013b-fef9-467a-b254-842234e77860","use-consensus-ai-faster-literature-scouting-zh","用 Consensus AI 快速掃描文獻","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785178971191-r1k9.png","2026-07-27T19:02:28.301451+00:00",{"id":43,"slug":44,"title":45,"cover_image":46,"image_url":46,"created_at":47,"category":13},"731d63df-7c5f-4a26-9780-fd876346acf4","15-perplexity-prompts-better-research-decisions-zh","15 個 Perplexity 研究決策提示詞","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785177185295-i623.png","2026-07-27T18:32:28.311437+00:00",{"id":49,"slug":50,"title":51,"cover_image":52,"image_url":52,"created_at":53,"category":13},"59413c8f-83aa-47e6-b7dc-ec53dad9ee40","mistral-ai-models-2026-builders-guide-zh","Mistral AI 模型 2026 實作選型指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785157375656-ytyw.png","2026-07-27T13:02:28.942961+00:00",{"id":55,"slug":56,"title":57,"cover_image":58,"image_url":58,"created_at":59,"category":13},"e17bd088-1eac-4c49-874d-2034196a07c5","rustrover-2026-2-turns-rust-setup-into-one-file-zh","RustRover 2026.2 把 Rust 設定收成一個檔","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785153812527-fuf9.png","2026-07-27T12:02:59.518971+00:00",{"id":61,"slug":62,"title":63,"cover_image":64,"image_url":64,"created_at":65,"category":13},"b6aa4cba-e0e5-46c6-bfff-b9b9402f101c","geekbench-7-realistic-cpu-gpu-benchmark-setup-zh","Geekbench 7 CPU 與 GPU 測試設定","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785119572418-qq3i.png","2026-07-27T02:32:23.411062+00:00",{"id":67,"slug":68,"title":69,"cover_image":70,"image_url":70,"created_at":71,"category":13},"5c82774f-9220-475a-ba1d-ef35c8d180d5","spark-42-turns-ai-search-into-sql-zh","Spark 4.2 把 AI 搜尋收進 SQL","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785067404325-tkwt.png","2026-07-26T12:02:55.376028+00:00",[73,78,83,88,93,98,103,108,113,118],{"id":74,"slug":75,"title":76,"created_at":77},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":79,"slug":80,"title":81,"created_at":82},"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":84,"slug":85,"title":86,"created_at":87},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"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":94,"slug":95,"title":96,"created_at":97},"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":99,"slug":100,"title":101,"created_at":102},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"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":114,"slug":115,"title":116,"created_at":117},"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":119,"slug":120,"title":121,"created_at":122},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]