[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-kernel-org-turns-linux-source-into-one-safe-hub-zh":3,"article-related-kernel-org-turns-linux-source-into-one-safe-hub-zh":30,"series-tools-508c3e13-332d-4195-8f7d-e06e7f4c2a00":82},{"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":29},"508c3e13-332d-4195-8f7d-e06e7f4c2a00","kernel-org-turns-linux-source-into-one-safe-hub-zh","kernel.org 把 Linux 變成安全樞紐","\u003Cp data-speakable=\"summary\">kernel.org 把 Linux 原始碼做成一個可驗證、可鏡像、可復原的安全分發樞紐。\u003C\u002Fp>\u003Cp>我盯 kernel.org 很久了。它看起來就是個老派網站，沒啥花招，連版面都像是二十年前留下來的。但越看我越覺得不對勁，因為它做的事其實很硬：把 Linux 原始碼、鏡像、驗證、權限控制，全部塞進一個能長期扛壓的架構裡。很多團隊嘴上說自己有「source of truth」，實際上只是把 repo 扔到某個平台，然後祈禱沒人搞事。\u003C\u002Fp>\u003Cp>我以前也踩過這種坑。系統看起來集中，實際上每一層都在偷懶：權限靠人記得開，備份靠人想起來做，發版靠某個人手動上傳。結果一出事，大家才發現所謂的中心化，只是把風險集中到同一台機器上。kernel.org 這套做法剛好相反，它不是把真相鎖在一個櫃子裡，而是把分發、驗證、恢復分開處理。\u003C\u002Fp>\u003Cp>這篇我不是要歌頌老系統。我是想拆它的套路，看看為什麼一個看起來很樸素的基礎設施，能撐住 Linux 這種等級的公共資產。你如果在做內部平台、開源發版、SDK 發佈、或是任何需要「別被一個節點搞垮」的東西，這套思路其實很能抄。\u003C\u002Fp>\u003Cp>我這次的起點是 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKernel.org\">Wikipedia 的 kernel.org 條目\u003C\u002Fa>，再往外接到 \u003Ca href=\"https:\u002F\u002Fwww.kernel.org\u002F\">官方 kernel.org\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgit-scm.com\u002F\">Git 官方文件\u003C\u002Fa>，以及 \u003Ca href=\"https:\u002F\u002Fwww.linuxfoundation.org\u002F\">Linux Foundation\u003C\u002Fa> 對 2011 入侵事件的整理。Wikipedia 沒有給我什麼驚天數字，但它把幾個關鍵事實串得很清楚，夠我把這套方法論拆開看。\u003C\u002Fp>\u003Ch2>它不是唯一真相，反而因此更可靠\u003C\u002Fh2>\u003Cblockquote>“All that makes kernel.org not the primary repository, but rather a distribution point of the kernel sources.”\u003C\u002Fblockquote>\u003Cp>這句話我很喜歡，因為它直接戳破一個常見迷思。kernel.org 不是在假裝自己是宇宙中心，它只是在做分發。翻譯一下就是：真相不靠某個網站的 UI 背書，真相靠的是 Git 歷史、簽章、審核流程，還有你能不能驗證每一個版本。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781075013332-0tkm.png\" alt=\"kernel.org 把 Linux 變成安全樞紐\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>這件事對開發者很重要，因為我們太容易把「有登入、有權限、有管理後台」誤認成安全。其實不是。那只是把控制面包了一層皮，真正能不能信，還是要看內容本身能不能被追溯、比對、重建。kernel.org 的設計很老派，但老派的地方通常就是它知道什麼不該交給單點信任。\u003C\u002Fp>\u003Cp>我之前幫團隊看過一個內部 Git 服務，大家口口聲聲說那是 source of truth，結果 release tag 是人手動打上去的，權限變更是靠工單跑，備份只做主機 snapshot。這種系統平常不出事，因為大家都懶得碰它；一旦出事，整個團隊就開始問同一個問題：到底誰能證明這份 code 沒被改過？\u003C\u002Fp>\u003Cp>實操上，我會建議你把「真相」和「分發」拆開。真相放在可驗證的歷史裡，分發交給 repo host、mirror、CDN、artifact store。然後把驗證放到使用者能碰到的地方，不要只藏在管理員後台。你如果用 \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa>、GitLab、Gitea，主機都只是載體，不是宗教。\u003C\u002Fp>\u003Cul>\u003Cli>Canonical history 放在 Git，不放在管理面板。\u003C\u002Fli>\u003Cli>重要版本用 signed tag 或簽章驗證。\u003C\u002Fli>\u003Cli>文件先定義哪一層是 authority，哪一層只是 distribution。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>鏡像不是備案，是主設計\u003C\u002Fh2>\u003Cp>kernel.org 不是只有一個站點而已。它還承擔鏡像與相關專案的分發角色，這表示它從一開始就不是「我這裡最完整，所以你只能來這裡」的思路。翻譯一下就是：可用性不是加分項，是前提。你要的是多路徑存取，不是單一路徑的漂亮首頁。\u003C\u002Fp>\u003Cp>這種思路在平常看起來很無聊，因為沒人會為了「鏡像做得好」去開香檳。但你只要真的遇過主站掛掉、DNS 飄掉、權限服務抽風、或某個區域網路被擋，就會知道鏡像到底有多救命。很多團隊把鏡像當成備份，心態是「壞了再說」。kernel.org 的味道不是這樣，它比較像是：如果沒有鏡像，才是真的在賭。\u003C\u002Fp>\u003Cp>我自己看過太多發版流程，把 artifact 全壓在單一 bucket 或單一下載頁。平常一切順，大家就誇自己架構簡潔；一旦事故來了，客服、開發、SRE 全部一起被拖下水。這時候你才會發現，所謂「簡潔」常常只是把複雜性延後爆炸。鏡像不是多餘的，它是把風險攤開。\u003C\u002Fp>\u003Cp>實操寫法很直接：把發版檔案做成多地區複製，至少有一個只讀 mirror。源碼 repo 可以有主站，但下載、release note、checksum、簽章檔最好有獨立分發點。你還要測一次主站死掉的情境，不要只在簡報裡說自己有高可用。\u003C\u002Fp>\u003Cul>\u003Cli>讀路徑要比寫路徑更簡單。\u003C\u002Fli>\u003Cli>發布和編輯分開，不要同一個介面包到底。\u003C\u002Fli>\u003Cli>鏡像要先驗證，再宣告可用。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>兩步驗證不是打勾，是權限政策\u003C\u002Fh2>\u003Cp>Wikipedia 條目提到，kernel.org 自 2014 年 8 月起，對託管 Git 倉庫中的 Linux kernel commit 要求雙因素驗證，而且支援 soft \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> 與 hard token。這件事我覺得很有意思，因為它不是「建議你開 MFA」這種溫吞話，而是把它變成硬規則。也就是說，能寫入核心資產的人，不能只靠密碼活著。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781075014958-gf4q.png\" alt=\"kernel.org 把 Linux 變成安全樞紐\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>這背後的邏輯很簡單，甚至有點殘酷：如果某個帳號被盜，影響的不是一個人，而是一整條供應鏈。Linux kernel 這種專案，任何一次錯誤 push 都\u003Ca href=\"\u002Fnews\u002Funifying-sft-target-distribution-design-zh\">不只\u003C\u002Fa>是版本管理問題，還可能是信任問題。兩步驗證不會讓攻擊消失，但它會讓偷帳號、撞密碼、釣魚登入的成本變高。\u003C\u002Fp>\u003Cp>我以前最煩的是，很多團隊把 MFA 當成「安全部門的偏好」，不是系統的基本設計。結果大家怕麻煩，就把高權限帳號做得跟一般帳號一樣好登入。這種做法很像把大門鎖起來，卻把後門鑰匙掛在門把上。kernel.org 的做法比較務實：寫入、發版、管理這些高風險動作，就是要多一道硬關卡。\u003C\u002Fp>\u003Cp>實操上，我會把 2FA 放在三個地方：commit\u002Fpush、release publishing、admin action。再來是 recovery path 也要先寫好，不然人一旦丟 token，整個流程就卡死。你如果團隊裡有人在不同地區工作，token 型態也別只押一種，軟體 token、硬體 token、備援方式都要想。\u003C\u002Fp>\u003Cp>如果你要看相關工具，我會順手把這幾個連起來：\u003Ca href=\"https:\u002F\u002Fwww.kernel.org\u002F\">kernel.org\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgit-scm.com\u002F\">Git\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.kernel.org\u002Fcategory\u002Ffaq.html\">kernel.org FAQ\u003C\u002Fa>、還有 \u003Ca href=\"https:\u002F\u002Fwww.linuxfoundation.org\u002F\">Linux Foundation\u003C\u002Fa>。這些東西放一起看，才看得出來它不是單點功能，而是一整套治理。\u003C\u002Fp>\u003Ch2>2011 入侵事件才是重點，不是八卦\u003C\u002Fh2>\u003Cp>2011 年 8 月 28 日，kernel.org 團隊發現重大安全入侵，攻擊者拿到 root 權限，還在啟動腳本裡塞了 trojan。後來系統重裝、事件調查也展開。這件事很多人只記得「啊，連 kernel.org 都被打」，但我覺得真正值得看的，是它怎麼回應。\u003C\u002Fp>\u003Cp>翻譯一下就是：當主機本身已經不可信，你不能再假裝修修補補就能回到原狀。你要做的是重建信任鏈。這也是我一直覺得很多公司做 incident response 最弱的地方，他們會修服務、會補漏洞、會開復盤會，但不太會問一個更麻煩的問題：這台機器現在到底還能不能被當成證據？\u003C\u002Fp>\u003Cp>kernel.org 這次之所以能撐住，跟 Linux 的分散式模型有關。因為原始碼不是只卡在一台主機上，歷史也不是只靠單一管理者的嘴巴。\u003Ca href=\"\u002Fnews\u002Feevee-test-time-prompt-learning-real-world-zh\">資料\u003C\u002Fa>散佈得夠廣，鏡像夠多，驗證夠清楚，攻擊者就比較難把修改藏起來。這不是不可攻破，這是可恢復。\u003C\u002Fp>\u003Cp>我以前看過團隊在事故後陷入無限拖延，原因很簡單：他們沒有從乾淨環境重建的能力。所有修復都依賴同一組已經被污染的服務，結果越修越心虛。kernel.org 這個案例提醒我，真正值錢的不是「永遠不會被打」，而是「被打了也能回得來」。\u003C\u002Fp>\u003Cp>實操上，你要準備的是：獨立備份、外部驗證、乾淨重建流程、以及事件後的憑證輪替。還有一條很重要：如果你的復原方案需要同一台被入侵主機來證明自己清白，那這方案基本上是廢的。\u003C\u002Fp>\u003Ch2>公開可用不是好看，是社群契約\u003C\u002Fh2>\u003Cp>kernel.org 的角色不只是給 Linux 開發者用，它也對所有使用者開放存取。這點我覺得很有意思，因為它把「可用」拉高到社群層級，而不是只服務少數 maintainer。這種開放感不是裝出來的，它是 \u003Ca href=\"\u002Fnews\u002Fopenai-ipo-wall-street-ai-test-zh\">open\u003C\u002Fa> source 基礎設施該有的樣子。\u003C\u002Fp>\u003Cp>很多內部平台團隊會把 open source 的外型學得很像，卻忘了行為。表面上有 portal、有審核、有工單，實際上你要拿一份原始碼還得先過三層門。這種系統不是在做公開分發，它是在做權限表演。kernel.org 的重點剛好相反：讓人拿得到、驗得到、鏡得走。\u003C\u002Fp>\u003Cp>這裡我想補一個比較。公開可用不代表亂放權限。它只是把讀權限拉大，把寫權限收緊。這個分界如果畫不清楚，團隊通常會走向兩種極端：不是過度封閉，就是什麼都開放結果被亂改。kernel.org 的做法比較成熟，因為它知道開放和治理可以同時存在。\u003C\u002Fp>\u003Cp>實操上，如果你做的是公開專案，請先把源碼、checksum、簽章、release artifact 的路徑整理乾淨。若是內部專案，也一樣別讓大家依賴單一 UI。至少要有可讀的 artifact URL、只讀 mirror、以及明確的授權規則。你不是在蓋城牆，你是在設計可驗證的通道。\u003C\u002Fp>\u003Cul>\u003Cli>讀權限盡量廣，寫權限盡量窄。\u003C\u002Fli>\u003Cli>讓驗證資料跟原始檔一起被分發。\u003C\u002Fli>\u003Cli>把 fallback 路徑寫進文件，不要只放在腦袋裡。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>這套方法論其實很樸素，但樸素得很狠\u003C\u002Fh2>\u003Cp>我越看 kernel.org，越覺得它不是在秀技術，而是在做取捨。它把「可信」「可分發」「可恢復」拆成三件事，然後各自用不同機制守住。這種系統不華麗，但很耐操。對我來說，這比任何漂亮的 dashboard 都值錢。\u003C\u002Fp>\u003Cp>如果你要把它講成一句白話，就是：不要把 hosting 當 trust，不要把 mirror 當 backup，不要把 MFA 當裝飾。這三句聽起來很像廢話，但很多團隊真的就是反著做，然後再用事故報告證明自己錯了。kernel.org 的價值在於，它把這些基本功做成了長期運作的制度。\u003C\u002Fp>\u003Cp>我會建議你把這套思路拿去看你自己的系統：哪裡是權威，哪裡是分發，哪裡是驗證，哪裡是恢復。只要有一層講不清楚，那層通常就是風險源。你不一定要做成 kernel.org 那樣，但至少別把風險都堆在同一台機器上，然後假裝自己很有秩序。\u003C\u002Fp>\u003Cp>原始參考我放在這裡：\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKernel.org\">Wikipedia 的 kernel.org 條目\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.kernel.org\u002F\">官方 kernel.org\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.linuxfoundation.org\u002F\">Linux Foundation\u003C\u002Fa>。這篇的事實骨架來自來源，我的拆解、比較和模板是我自己整理出來的。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># public-source-distribution-playbook\n\n## 1. 定義信任邊界\n- canonical history 放在 Git。\n- host 只負責分發，不負責定義真相。\n- release tag 與 artifact 必須可驗證。\n\n## 2. 把讀寫拆開\n- read path 對外公開或廣泛可用。\n- write path 需要強驗證。\n- admin action 需要第二因素與獨立復原流程。\n\n## 3. 鏡像是主設計，不是備案\n- 至少保留一個只讀 mirror。\n- release artifact 要有第二分發點。\n- 定期測試主站失效時的取用方式。\n\n## 4. 預設主機可能已被入侵\n- 保留獨立備份。\n- 從乾淨環境重建，不要只靠原機修補。\n- 恢復後比對 repository history 與外部副本。\n\n## 5. 保護高價值動作\n- commit \u002F push \u002F release publishing 強制 2FA。\n- 支援多種 token 類型。\n- 先寫好 account recovery，再開放權限。\n\n## 6. 發布給驗證，不是只給下載\n- source、checksum、signature 一起發。\n- download URL 盡量穩定。\n- 讓外部可以獨立驗證版本。\n\n## 7. 事故處理清單\n1. Freeze write access.\n2. Rebuild host from clean infra.\n3. Verify repo history against independent copies.\n4. Restore mirrors and release endpoints.\n5. Rotate credentials and review audit logs.\n6. 公告復原狀態與驗證結果。\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板是我根據 kernel.org 的運作方式整理的，不是照抄原文，但骨架很明顯就是那套：公開分發、鏡像優先、強化寫入、主機可重建。你如果要直接套，先從第 1、2、4 項開始，最有感。\u003C\u002Fp>\u003Cp>來源致謝：原始資訊主要來自 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKernel.org\">Wikipedia kernel.org 條目\u003C\u002Fa> 與其引用的 \u003Ca href=\"https:\u002F\u002Fwww.kernel.org\u002F\">official kernel.org\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.linuxfoundation.org\u002F\">Linux Foundation\u003C\u002Fa> 資料。我寫的比較、案例和模板是衍生整理，方便你直接拿去改自己的流程。\u003C\u002Fp>","我拆 kernel.org 怎麼把 Linux 原始碼做成可驗證、可鏡像、可復原的安全分發樞紐，順手給你可直接套用的模板。","en.wikipedia.org","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKernel.org",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781075013332-0tkm.png","tools","zh","44dce552-f5e5-46e8-8f51-82e30670e7ea",[17,18,19,20,21],"kernel.org","Linux","Git","2FA","mirrors",[23,24,25],"kernel.org 的核心不是單點權威，而是可驗證的分發與歷史。","鏡像、強驗證、乾淨重建，才是抗事故的基本盤。","讀寫分離與高價值動作加固，能直接套到你自己的 repo 與發版流程。",0,"2026-06-10T07:03:04.743101+00:00","2026-06-10T07:03:04.702+00:00","13637d9f-b9a5-40ff-9d37-af2ab7a697f1",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,34,36,38,40],{"name":19,"slug":33},"git",{"name":18,"slug":35},"linux",{"name":17,"slug":37},"kernelorg",{"name":20,"slug":39},"2fa",{"name":21,"slug":21},{"id":15,"slug":42,"title":43,"language":44},"kernel-org-turns-linux-source-into-one-safe-hub-en","kernel.org turns Linux source into one safe hub","en",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"2fe98ea1-b9ab-4462-97ce-a1746483d51d","update-cursor-in-1-minute-zh","1 分鐘更新 Cursor","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781092963184-c3rr.png","2026-06-10T12:02:16.930353+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"f69efc2b-0c9c-4888-a8b7-bb0328d7df1f","cloudflare-bots-beat-human-web-traffic-zh","Cloudflare 機器人流量超越人類：實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781089384566-ldx3.png","2026-06-10T11:02:25.914435+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"50c3d4d3-c293-473b-8a92-44abbc3a0ded","six-ai-features-short-video-apps-need-2026-zh","六個 AI 功能把短影音做活","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781080447980-jgsj.png","2026-06-10T08:33:00.328765+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"f58761cb-a7e6-4ad8-9a3f-39d51c8ea1c4","sightengine-visual-moderation-right-choice-zh","Sightengine 適合做視覺審核，不適合當通用信任與安全平台","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781079476170-smp2.png","2026-06-10T08:17:21.603825+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"93efd958-313e-4fb2-b3f2-5219596c8090","scoredetect-ai-content-moderation-rollout-zh","ScoreDetect 推出 AI 審核方案，匹配率 99%","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781078586685-0eb4.png","2026-06-10T08:02:28.020204+00:00",{"id":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"category":13},"5405a574-1ed7-4cd9-a135-5b4be4ba3fc1","turbovec-cuts-vector-db-memory-from-31gb-to-4gb-zh","TurboVec 把向量索引變輕了","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781074101706-yynr.png","2026-06-10T06:47:54.424465+00:00",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"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":94,"slug":95,"title":96,"created_at":97},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"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":104,"slug":105,"title":106,"created_at":107},"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":109,"slug":110,"title":111,"created_at":112},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"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":124,"slug":125,"title":126,"created_at":127},"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":129,"slug":130,"title":131,"created_at":132},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]