[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-three-step-postgresql-c-to-rust-rewrite-zh":3,"article-related-three-step-postgresql-c-to-rust-rewrite-zh":30,"series-tools-8ef02ef4-2a57-4db0-8f87-0705cbf6e1ac":77},{"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},"8ef02ef4-2a57-4db0-8f87-0705cbf6e1ac","three-step-postgresql-c-to-rust-rewrite-zh","三步把 PostgreSQL C 改成 Rust","\u003Cp data-speakable=\"summary\">以前我总想一口气重写整坨 C，现在我只先让它活下来，再慢慢变成像样的 \u003Ca href=\"\u002Ftag\u002Frust\">Rust\u003C\u002Fa>。\u003C\u002Fp>\u003Cp>我最近一直盯着这种老 C 项目往 Rust 搬的做法，看久了只觉得一件事：很多人不是输在技术，是输在顺序。你一上来就想把整个系统改成“优雅的 Rust”，测试没补、边界没拆、风险没切开，最后只会把自己埋进一堆半成品里。我看 PostgreSQL 这条路，最有意思的地方就是它承认现实很脏，先把代码搬过去，再谈变漂亮。\u003C\u002Fp>\u003Cp>这次让我停下来的是这篇 \u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2060038538951910350\">知乎整理文\u003C\u002Fa>，它转述的是 HN 上作者对 PostgreSQL 第二版 Rust 重写路线的说明。原始\u003Ca href=\"\u002Fnews\u002Fai-agent-tool-landscape-report-2026-07-zh\">工具\u003C\u002Fa>链也很明确：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fimmunant\u002Fc2rust\">c2rust\u003C\u002Fa> 先做机械翻译，\u003Ca href=\"https:\u002F\u002Fclaude.ai\u002F\">Claude\u003C\u002Fa> 再逐个 crate 改写和审计。这里没有花活，只有流程。\u003C\u002Fp>\u003Ch2>先别重写，先把行为搬过去\u003C\u002Fh2>\u003Cblockquote>先用 c2rust 把 PostgreSQL 的 C 源码机械翻译成 Rust，先得到一份能跑核心 SQL 回归测试的代码。\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：第一步不是写出“漂亮 Rust”，而是先拿到一份能编译、能跑测试、能继续改的 Rust。这个顺序我很買單。大型系統最怕的不是程式碼醜，而是你根本不知道自己改壞了什麼。先把行為搬過去，至少你知道新舊版本在做同一件事。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784709235706-kk7w.png\" alt=\"三步把 PostgreSQL C 改成 Rust\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前幹過一次遺留系統遷移，最慘的地方就是團隊把“順手重構”當成附加價值。結果每個人都在改命名、改結構、改錯誤流，最後沒人說得清楚到底是語言遷移失敗，還是業務邏輯被改爛。後來我學乖了：先讓它活，再讓它好看。\u003C\u002Fp>\u003Cp>c2rust 的價值就在這裡。它不是幫你完成終局，而是幫你跨過 C 到 Rust 的語義鴻溝。對 \u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002F\">PostgreSQL\u003C\u002Fa> 這種體量，靠人手從零重寫根本不現實。你需要的是一份可編譯、可測試、可逐步修補的底稿。\u003C\u002Fp>\u003Cul>\u003Cli>先把能跑當第一目標。\u003C\u002Fli>\u003Cli>遷移和重構分開做，不要混在一起。\u003C\u002Fli>\u003Cli>測試先保住，尤其是回歸測試。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你自己的專案也在搬家，我會先找工具把舊語言\u003Ca href=\"\u002Fnews\u002Fproject-glasswing-ai-security-layer-zh\">變成\u003C\u002Fa>新語言的“可編譯版本”。哪怕很醜也沒差，先把行為對齊。接著立刻補測試，先抓輸入輸出穩定、邊界多的地方。別急著刪 unsafe，也別急著美化架構，先確認新舊行為一致。\u003C\u002Fp>\u003Ch2>拆成一千個 crate 不是炫技，是切風險\u003C\u002Fh2>\u003Cp>第二個讓我點頭的地方，是它把 PostgreSQL 拆成大約一千個 crate。這數字聽起來很誇張，但我完全不意外。大系統遷移最怕的不是程式碼多，是邊界糊。邊界一糊，AI 會開始亂補，你也會開始不敢動。\u003C\u002Fp>\u003Cp>拆 crate 的本質，是把責任切細。每個 crate 有自己的依賴、自己的介面、自己的審計範圍。這樣 \u003Ca href=\"\u002Ftag\u002Fclaude\">Claude\u003C\u002Fa> 不是在“理解整個 PostgreSQL”，而是在處理一個有限的小盒子。這差很多。模型最擅長的是局部上下文，最怕的是跨太多抽象層。\u003C\u002Fp>\u003Cp>我看過太多“讓 AI 重寫整個 repo”的 demo，前十分鐘都很爽，後面就開始在命名、錯誤傳遞、生命週期、內部 \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> 之間撞牆。不是模型太差，是輸入太大。你把一坨泥丟給它，它只會回你一坨比較整齊的泥。\u003C\u002Fp>\u003Cp>這裡真正成熟的地方，是 crate 拆開後，重寫就變成流水線，不是全局事件。每個單元都能獨立改、獨立審、獨立回退。失敗不會污染整個倉庫，這才叫能持續推進。\u003C\u002Fp>\u003Cul>\u003Cli>邊界越清楚，AI 越能工作。\u003C\u002Fli>\u003Cli>小單元重寫比整倉重寫更容易審。\u003C\u002Fli>\u003Cli>可回退、可重試，才像工程。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你可以直接照做：先把 repo 按功能切成最小可管理單元，不要先追求優雅分層。重點是每塊都能獨立編譯、獨立測試。然後把 AI 任務固定在單一模組，例如“只重寫這個 parser 子模組的錯誤處理”，不要丟給它“把整個資料庫核心改成 Rust 風格”。\u003C\u002Fp>\u003Ch2>Claude 只是手，流程才是主角\u003C\u002Fh2>\u003Cblockquote>流程只有三步：挑下一個 crate、重寫、審計。\u003C\u002Fblockquote>\u003Cp>也就是說，AI 不是架構師，也不是專案經理，它只是執行器。真正決定節奏的，還是人。先改哪個 crate、怎麼改、改完怎麼驗，都得先定好。這種流程很樸素，但我覺得比那種“讓 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> 自己決定下一步”的說法可靠太多。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784709236062-6v91.png\" alt=\"三步把 PostgreSQL C 改成 Rust\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我一直對自動\u003Ca href=\"\u002Fnews\u002Fcoderescue-budget-calibrated-recovery-routing-zh\">代理\u003C\u002Fa>那套話術很警惕。聽起來很猛，落地很容易失控。尤其像 PostgreSQL 這種系統，錯誤不是“輸出不夠漂亮”，而是“行為變了但沒人發現”。所以你必須把模型塞進窄流程：輸入明確、輸出明確、審計明確。\u003C\u002Fp>\u003Cp>這裡的重寫也不是讓 Claude 從零發明實作，而是在機械翻譯的基礎上做局部整理。換句話說，模型的任務是把“能跑但很 C 的 Rust”往更像樣的 Rust 推。它不是創造新語義，而是在既有語義上修整。\u003C\u002Fp>\u003Cp>審計這一步不能省。因為 AI 改碼最常見的坑，不是編譯失敗，而是語義偷偷漂移。編譯過了，不代表邏輯對了。審計要看的就是：有沒有改到行為、有沒有擴大 unsafe、有沒有把原本清楚的狀態機弄亂。\u003C\u002Fp>\u003Cp>我會把這種任務寫成固定模板：\u003C\u002Fp>\u003Cul>\u003Cli>輸入：一個 crate 或一個模組。\u003C\u002Fli>\u003Cli>目標：把機械翻譯碼改得更 idiomatic。\u003C\u002Fli>\u003Cli>約束：不能改公開行為，不能擴大介面面積。\u003C\u002Fli>\u003Cli>輸出：補丁、說明、風險點。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這樣做的好處很直接：模型不需要懂整個專案，只要完成一個可驗收的小任務。對大規模遷移來說，這才是能跑的方式。\u003C\u002Fp>\u003Ch2>parser 這種地方，最不適合硬裝聰明\u003C\u002Fh2>\u003Cp>原文提到，像 parser 這類少數由工具生成的模組，仍然保留了大量機械翻譯碼和 unsafe。這細節很重要。不是所有模組都適合被 AI 一口氣重寫。有些地方跟底層資料結構、位元運算、狀態機、生成器綁得死死的，能動的空間本來就小。\u003C\u002Fp>\u003Cp>parser 這種東西通常有三層麻煩：語義密、邊界多、你一改就容易影響整個系統的輸入相容性。對資料庫來說，解析器不是普通業務碼，它決定 SQL 到底怎麼被理解。你亂改，後面執行器、最佳化器、回歸測試全都會一起炸。\u003C\u002Fp>\u003Cp>我看過不少團隊在這裡犯同一種錯：覺得“都搬到 Rust 了，那 parser 也順便現代化一下吧”。結果現代化完，語法相容性掉了，測試集炸了，最後還是得回頭補。資料庫最怕的就是看起來更乾淨，但行為不再可信。\u003C\u002Fp>\u003Cp>所以保留機械翻譯和 unsafe，不一定是偷懶，可能是理性選擇。你不能對所有模組一視同仁。能重構的地方就重構，必須保守的地方就保守。工程上最貴的不是髒碼，是錯誤自信。\u003C\u002Fp>\u003Cp>如果你也在搬系統，我會先把模組分三類：\u003C\u002Fp>\u003Cul>\u003Cli>可大改：純業務邏輯、邊界清楚、測試高。\u003C\u002Fli>\u003Cli>可小改：複雜但可局部驗證。\u003C\u002Fli>\u003Cli>別亂動：協議解析、狀態機、生成碼、核心相容層。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>第三類的目標不是“寫得漂亮”，而是“別動壞”。這句話很沒勁，但真的救命。\u003C\u002Fp>\u003Ch2>真正的成本在審計，不在生成\u003C\u002Fh2>\u003Cp>很多人看到 AI 寫程式，第一反應都是“哇，生成好快”。但我做工程越久，越覺得生成從來不是最貴的，審計才是。你讓模型改一千個 crate，真正吃時間的是你得一個一個確認：這次改動是不是安全、是不是等價、是不是引入新依賴和新風險。\u003C\u002Fp>\u003Cp>這也是我喜歡這套流程的原因。它承認一件很現實的事：模型可以幫你搬磚，但不能替你擔責。審計還是得人來，測試還是得跑，回歸還是得過。沒有這些，AI 只是在放大不確定性。\u003C\u002Fp>\u003Cp>我自己最在意的是節奏。這種流程不用等整個專案完工才知道成不成，而是每改一個 crate，就能看到結果。這個回饋閉環很重要。它會讓團隊很快知道哪些模組適合繼續交給模型，哪些模組必須人工接手。\u003C\u002Fp>\u003Cp>如果你想把這套方法用到別的語言遷移上，記住一條：讓 AI 做重複勞動，讓人做風險判斷。重複勞動包括機械改名、樣板整理、局部風格統一；風險判斷包括 API 相容、語義保持、邊界條件、效能回退。別把這兩件事混在一起。\u003C\u002Fp>\u003Cp>我會固定一份審計清單：\u003C\u002Fp>\u003Cul>\u003Cli>編譯是否通過。\u003C\u002Fli>\u003Cli>原有測試是否通過。\u003C\u002Fli>\u003Cli>是否新增 unsafe 或擴大 unsafe 範圍。\u003C\u002Fli>\u003Cli>是否改變公開介面或行為。\u003C\u002Fli>\u003Cli>是否引入難以回退的結構性變化。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>這套方法適合誰，不適合誰\u003C\u002Fh2>\u003Cp>我不覺得這套方法適合所有專案。它特別適合那種已經有大量測試、模組邊界還能拆、舊行為相對穩定的大系統。PostgreSQL 顯然符合這些前提。它不適合那種需求天天變、測試很薄、介面還在晃的專案。那種專案你先別談遷移，先把產品定義弄清楚。\u003C\u002Fp>\u003Cp>如果你的倉庫很小，直接重寫也許更快。但只要系統一大，直接重寫就會變成災難。因為你不可能靠一次性腦內模擬，準確複製幾十萬行程式的邊緣行為。這時候，機械翻譯加局部重寫加審計，才是能走下去的路。\u003C\u002Fp>\u003Cp>我特別想強調：這不是“AI 取代工程師”，而是“AI 讓工程師能把舊系統拆開處理”。差很多。前者是幻想，後者是流程設計。前者只會讓你寫簡報，後者會讓你交付程式。\u003C\u002Fp>\u003Cp>所以我看完這條路線，最大的感受不是“AI 真猛”，而是“終於有人把遷移這件事講人話了”。先活下來，再變好看；先局部可控，再全局優化。這個順序，真的不能反。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 大型 C 到 Rust 遷移工作流模板\n\n## 目標\n把一個已有測試的大型 C 專案遷移到 Rust。\n\n## 原則\n1. 先保行為，再談風格。\n2. 先機械翻譯，再局部重寫。\n3. 任何 AI 改動都必須可審計、可回退。\n4. 核心模組優先保證測試通過，不強求一次性消滅 unsafe。\n\n## 工作流\n### 第 1 步：機械翻譯\n- 使用 c2rust 或同類工具把 C 程式翻成 Rust。\n- 允許生成大量 unsafe 和非 idiomatic 程式碼。\n- 目標是讓程式先編譯、先跑測試。\n\n### 第 2 步：拆分模組\n- 按功能把倉庫拆成盡量小的 crate \u002F module。\n- 每個單元都要能獨立編譯、獨立測試。\n- 對 parser、協議層、狀態機等高風險模組單獨標記。\n\n### 第 3 步：逐個重寫\n- 每次只選一個 crate。\n- 讓 AI 僅在該 crate 範圍內改寫。\n- 目標：更 idiomatic 的 Rust、減少樣板、縮小 unsafe 範圍。\n\n### 第 4 步：人工審計\n- 檢查編譯結果。\n- 跑原有回歸測試。\n- 核對公開行為、錯誤處理、邊界條件。\n- 確認沒有引入新的不可回退結構。\n\n## 給 AI 的提示詞\n你是資深 Rust 工程師。\n\n任務：重寫目前 crate 中的機械翻譯程式碼，使其更符合 Rust 習慣寫法。\n\n約束：\n- 不得改變公開行為。\n- 不得擴大 unsafe 範圍。\n- 不得修改 crate 之外的程式碼。\n- 保持現有測試全部通過。\n- 如果發現語義不清楚，先列出風險點，不要猜。\n\n輸出要求：\n1. 給出修改後的程式碼。\n2. 列出你認為有風險的地方。\n3. 說明哪些地方保留了機械翻譯實作，以及原因。\n\n## 審計清單\n- [ ] 編譯通過\n- [ ] 回歸測試通過\n- [ ] 行為未變\n- [ ] unsafe 未擴大\n- [ ] 模組邊界未破壞\n- [ ] 風險點已記錄\n\n## 適用場景\n- 大型遺留 C 專案\n- 有穩定測試集的系統\n- 需要漸進遷移，而不是一次性重寫的專案\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板的重點不是照抄 PostgreSQL 的規模，而是把遷移拆成可驗證的小步。你可以按自己的倉庫大小縮放粒度，但核心思路不變：先翻譯，後重寫；先局部，後全局；先審計，後慶祝。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2060038538951910350\">這篇知乎整理文\u003C\u002Fa>，它轉述了 HN 上關於 PostgreSQL Rust 重寫路線的討論；我這篇的拆解是基於該文內容重新整理，模板則是我自己按這個流程整理出來的。\u003C\u002Fp>","先机械翻译成能跑的 Rust，再拆 crate，最后让 Claude 逐个重写并审计。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2060038538951910350",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784709235706-kk7w.png","tools","zh","b29c9a4b-0350-4171-9c68-cd8c633b7593",[17,18,19,20,21],"PostgreSQL","Rust migration","c2rust","Claude","crate拆分",[23,24,25],"先用機械翻譯把舊 C 變成能跑的 Rust，再談重構。","把大型系統拆成小 crate，才能讓 AI 做局部改寫與審計。","審計和回歸測試才是遷移成本核心，生成本身只是起點。",0,"2026-07-22T08:33:27.759083+00:00","2026-07-22T08:33:27.751+00:00","ad977c9e-7534-4851-8dae-85de665b372a",{"tags":31,"relatedLang":36,"relatedPosts":40},[32,34],{"name":20,"slug":33},"claude",{"name":17,"slug":35},"postgresql",{"id":15,"slug":37,"title":38,"language":39},"ai-rewrites-postgresql-in-rust-en","How AI Rewrites PostgreSQL in Rust","en",[41,47,53,59,65,71],{"id":42,"slug":43,"title":44,"cover_image":45,"image_url":45,"created_at":46,"category":13},"0ef9f5bc-c841-4f67-be97-3bb5fd7ec655","ai-agent-tool-landscape-report-2026-07-zh","AI Agent 工具選型拆成四層","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784707461607-2sr0.png","2026-07-22T08:03:27.317173+00:00",{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"f28f3857-506d-4b14-9211-664c7d2f142a","docker-desktop-windows-install-flow-zh","Windows 裝 Docker Desktop 先搞定 WSL","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784656979438-lzmx.png","2026-07-21T18:02:36.907589+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"3f39f92e-fd44-43f8-a14c-a43e363b0eaa","grok-4-5-cursor-launch-benchmarks-pricing-zh","Grok 4.5 登上 Cursor，$2\u002F$6 開賣","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784536377664-m9em.png","2026-07-20T08:32:24.195451+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"1c9e6787-9ad4-4d49-9800-b54f71149e4e","agt-governed-agent-calls-zh","AGT 把代理呼叫變受管動作","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784405026107-79g5.png","2026-07-18T20:03:17.40007+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"769444fb-48a3-41d5-8383-f6867ff53232","openclaw-v2026-7-1-control-ui-workspace-zh","OpenClaw v2026.7.1 把控制台變工作區","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784358229254-0dil.png","2026-07-18T07:03:25.506405+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"7bed70e8-39cf-45bb-8f71-6ddd31ad2317","openai-screenless-speaker-turns-chatgpt-companion-zh","OpenAI 無螢幕喇叭把 ChatGPT 變陪伴","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784289800548-z10g.png","2026-07-17T12:02:53.189236+00:00",[78,83,88,93,98,103,108,113,118,123],{"id":79,"slug":80,"title":81,"created_at":82},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":84,"slug":85,"title":86,"created_at":87},"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":89,"slug":90,"title":91,"created_at":92},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"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":99,"slug":100,"title":101,"created_at":102},"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":104,"slug":105,"title":106,"created_at":107},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"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":119,"slug":120,"title":121,"created_at":122},"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":124,"slug":125,"title":126,"created_at":127},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]