[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-go-makes-backend-scale-easier-in-production-zh":3,"article-related-go-makes-backend-scale-easier-in-production-zh":30,"series-tools-31c694b9-74b0-4609-829b-ed7e72cae838":75},{"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},"31c694b9-74b0-4609-829b-ed7e72cae838","go-makes-backend-scale-easier-in-production-zh","Go 讓後端擴充少踩雷","\u003Cp data-speakable=\"summary\">我拆 Netguru 的 Go 產業案例，整理成一份可直接拿去評估後端語言與部署方式的實戰模板。\u003C\u002Fp>\u003Cp>我看 Go 相關的案例文很久了，老實說，很多都像在貼 logo 牆：\u003Ca href=\"\u002Ftag\u002Fgoogle\">Google\u003C\u002Fa>、\u003Ca href=\"\u002Ftag\u002Fcloudflare\">Cloudflare\u003C\u002Fa>、Uber 一字排開，看起來很猛，實際上卻沒講清楚一件事，Go 到底幫團隊省掉了什麼麻煩。我自己用過幾個後端堆疊後，越來越確定一件事：語言不是拿來比誰比較潮，是拿來看誰能少讓團隊在 production 裡面收拾爛攤子。Go 會被反覆拿出來，不是因為它好聽，是因為它在並發、部署、編譯速度這幾個地方，真的比較不會鬧脾氣。\u003C\u002Fp>\u003Cp>這次我主要拆的是 Netguru 這篇 \u003Ca href=\"https:\u002F\u002Fwww.netguru.com\u002Fblog\u002Fcompanies-that-use-golang\">19 major companies that use Golang in production\u003C\u002Fa>，再搭配官方 \u003Ca href=\"https:\u002F\u002Fgo.dev\u002F\">Go 語言網站\u003C\u002Fa> 與 \u003Ca href=\"https:\u002F\u002Fgo.dev\u002Fsolutions\u002Fcase-studies\">Go case studies\u003C\u002Fa>。我也會順手連到文中提到的公司或專案，讓你自己看原始資料，不用只信我嘴上講的那套。\u003C\u002Fp>\u003Ch2>Go 不是比較潮，是比較不怕併發把你搞瘋\u003C\u002Fh2>\u003Cblockquote>「Go 的 goroutine 併發模型採用 M:N 排程，很多 goroutine 會被 Go runtime 多工到較少的 OS thread 上。」\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你不用自己手刻一大坨 thread pool，也不用把每個請求都想成一個昂貴的系統執行緒。Go 把很多小工作拆成很便宜的 goroutine，讓 runtime 幫你排程。這件事在請求轉發、背景 worker、事件處理、聊天系統、即時查詢這種場景特別有感。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782910122046-y1lz.png\" alt=\"Go 讓後端擴充少踩雷\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Netguru 文章裡點到 \u003Ca href=\"https:\u002F\u002Fwww.cloudflare.com\u002F\">Cloudflare\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.uber.com\u002F\">Uber\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.twitch.tv\u002F\">Twitch\u003C\u002Fa>，不是亂點名。Cloudflare 做邊緣與 DNS，Uber 有派單與查詢服務，Twitch 則是高併發聊天和即時互動。這些東西的共同點很簡單：你只要 thread 管理一亂，整個服務就開始喘。\u003C\u002Fp>\u003Cp>我以前在一個金融服務專案上踩過這個坑。功能本身沒問題，真正出事的是併發協調。請求一多，timeout、鎖競爭、連線池配置就開始互相打架。Go 沒有神奇到可以把架構垃圾\u003Ca href=\"\u002Fnews\u002Fsuse-openchip-risc-v-eu-sovereign-stack-zh\">變成\u003C\u002Fa>金子，但它至少讓我們少花很多心力去跟執行緒模型纏鬥。這種「少一層麻煩」在 production 裡很值錢。\u003C\u002Fp>\u003Cp>實操上，我不會一開始就問「要不要全換 Go」，那太蠢了。我會先問：你的服務是不是大量 I\u002FO、很多平行工作、而且每個工作都不重？如果是，Go 就值得進入 shortlist。反過來，如果你只是幾個 API 加排程，那你多半是在為了語言而換語言。\u003C\u002Fp>\u003Cul>\u003Cli>適合：大量並發請求、背景 worker、事件流、即時服務。\u003C\u002Fli>\u003Cli>適合：團隊一直在跟 thread pool、async 複雜度、timeout 打架。\u003C\u002Fli>\u003Cli>不適合：只有少量端點，卻想硬上新語言裝成熟。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>編譯快不是小事，是每天都在省命\u003C\u002Fh2>\u003Cblockquote>「Go 可以把大型程式碼庫在幾秒內編譯完成，不是幾分鐘。」\u003C\u002Fblockquote>\u003Cp>這句看起來很平淡，但我跟你說，開發體感差很多。編譯快，工程師才會一直試、一直改、一直驗證；編譯慢，大家就會開始拖，開始猜，開始把變更包大一點再一起測。然後 bug 就進來坐好坐滿。\u003C\u002Fp>\u003Cp>Netguru 提到 Go 的幾個設計點：\u003Ca href=\"\u002Fnews\u002Fbootdev-go-course-turns-syntax-into-services-zh\">語法\u003C\u002Fa>簡單、沒有循環相依、編譯器就是為了速度設計。這些東西單看都不性感，但合起來就是一件事：回饋迴圈短。你改一個服務，不用等半天才知道自己有沒有把東西弄壞，這對 CI\u002FCD 和日常開發都很有差。\u003C\u002Fp>\u003Cp>我自己最有感的是團隊節奏。當 build 要等很久，大家會自然減少重構，因為每次試錯成本太高。久了之後，程式碼就會越來越僵，最後不是功能做不動，是沒人想動。Go 在這裡的價值不是炫技，是把工程師從等待中拉回來。\u003C\u002Fp>\u003Cp>這也是為什麼 \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002F\">Docker\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002F\">Kubernetes\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.heroku.com\u002F\">Heroku\">這類\u003Ca href=\"\u002Fnews\u002Fboot-dev-go-playground-teaching-tool-zh\">工具\u003C\u002Fa>型公司常出現 Go。你如果做的是平台、基礎設施、內部工具，語言就不能一直搶戲。它應該安安靜靜把編譯和測試跑完，別每次都像在跟你吵架。\u003C\u002Fp>\u003Cp>實操寫法我會這樣抓：\u003C\u002Fp>\u003Cul>\u003Cli>先量你現在的 build \u002F test 時間，不要憑感覺。\u003C\u002Fli>\u003Cli>看工程師卡住的點是不是回饋太慢，不是單純 runtime 慢。\u003C\u002Fli>\u003Cli>如果你的服務需要高頻修改、高頻驗證，Go 很值得試一個小範圍。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>單一靜態 binary 讓部署少掉一堆廢事\u003C\u002Fh2>\u003Cblockquote>「靜態編譯會產生單一、獨立的 artifact，不需要額外 runtime 相依。」\u003C\u002Fblockquote>\u003Cp>這種特性平常看起來沒什麼，真的上線才知道有多省事。你不用再拖一個 JVM，也不用帶一整包 Python runtime 或一堆動態相依進容器。最後就是 image 比較小、啟動比較快、出事時比較好查。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782910124886-3zfi.png\" alt=\"Go 讓後端擴充少踩雷\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Netguru 把這點連到 \u003Ca href=\"\u002Ftag\u002Fdocker\">Docker\u003C\u002Fa> 和 Kubernetes，我覺得很合理。這些工具本來就活在容器和基礎設施那層，image 大小、啟動時間、相依穩定度都會直接影響維運感受。Go 的 binary 可以直接丟進很小的 container，對部署和安全面都比較乾淨。\u003C\u002Fp>\u003Cp>我看過不少團隊在那邊瘋狂優化 base image，結果真正的問題根本不是 base image，而是 runtime 本身太重。Go 至少把這個麻煩切掉一大塊。它不會自動修好你的部署流程，但它會少給你一個要命的拖累。\u003C\u002Fp>\u003Cp>如果你在做內部服務、CLI、\u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa>、或任何需要快速啟動、到處一致執行的東西，這點很好用。反過來，如果你已經被某個 runtime 生態綁死，那就老實承認 trade-off，不要假裝 binary 大小不重要。\u003C\u002Fp>\u003Cul>\u003Cli>適合：容器化服務、內部工具、CLI、agent。\u003C\u002Fli>\u003Cli>適合：你很在意 cold start、image size、部署一致性。\u003C\u002Fli>\u003Cli>不適合：你其實早就需要某個重量級 runtime 生態。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Google 背書不是重點，重點是它養出來的生態\u003C\u002Fh2>\u003Cblockquote>「Go 是 Google 創造的，而且核心開發持續由 Google 支援。」\u003C\u002Fblockquote>\u003Cp>翻譯一下，不是「Google 愛用，所以你也該用」，那種講法太偷懶。真正有價值的是：Go 是在 Google 這種環境長大的，而那個環境剛好催生了 Kubernetes、Docker、Prometheus、Terraform、Istio 這一串你很可能每天都聽到的工具。\u003C\u002Fp>\u003Cp>這代表什麼？代表 Go 不是只在簡報上看起來乾淨，它是在雲原生基礎設施那一層被反覆打磨過的。這種東西比「語法優雅」更實際，因為你真的會在 production 裡碰到它。\u003C\u002Fp>\u003Cp>我開過太多「我們要選一個看起來比較現代的語言」會議。通常講到最後，大家都在講感覺，不是在講風險。Go 常常能贏，是因為它的生產環境足跡夠深，團隊不用拿未來賭現在。\u003C\u002Fp>\u003Cp>這裡我會建議你把重點放在風險降低，不是崇拜。當一個語言已經在你依賴的基礎設施裡跑很久，你導入它的阻力就會小很多，招人也比較好講。你不是在賣夢，你是在賣可驗證的使用經驗。\u003C\u002Fp>\u003Cp>可參考的外部資料包括 \u003Ca href=\"https:\u002F\u002Fgo.dev\u002F\">go.dev\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgo.dev\u002Fsolutions\u002Fcase-studies\">Go case studies\u003C\u002Fa>，以及 \u003Ca href=\"https:\u002F\u002Fprometheus.io\u002F\">Prometheus\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002F\">Kubernetes\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002F\">Docker\u003C\u002Fa> 這些專案本身。\u003C\u002Fp>\u003Ch2>那份公司清單其實在講同一種痛\u003C\u002Fh2>\u003Cp>Netguru 列了 Google、Cloudflare、Uber、Dropbox、Monzo、Facebook、Capital One、ByteDance、SoundCloud、MercadoLibre、Cockroach Labs、Salesforce、American Express 等等。公司很多，產業很雜，但痛點其實重複得很明顯：高吞吐、併發、基礎設施、可預測的效能。\u003C\u002Fp>\u003Cp>我覺得 Salesforce 那段特別有意思。文章提到 Einstein Analytics 在上線前有效能壓力，後來把一大塊後端從 Python 與 C 的混合實作移到 Go。這不是在說 Python 很爛，而是在說當工作負載需要更好的多執行緒行為和更穩定的擴充性時，Go 會比較不煩。\u003C\u002Fp>\u003Cp>這種案例我很買單，因為它不會把決策講成宗教戰爭。Go 不是萬能解法，它是當你的系統已經長到某個程度，原本的 runtime 或併發模型開始讓你不舒服時，才變得划算。\u003C\u002Fp>\u003Cp>所以如果你現在在選後端語言，我會建議你不要先看品牌名，而是先看工作型態。你是不是在做高吞吐 API、平台服務、CLI、\u003Ca href=\"\u002Ftag\u002F分散式系統\">分散式系統\u003C\u002Fa>、很多並發工作？如果是，那你其實已經站在 Go 的適用區裡了。\u003C\u002Fp>\u003Cp>實操上可以這樣判斷：\u003C\u002Fp>\u003Cul>\u003Cli>把你自己的工作負載對照這些公司的場景，不要只看公司名氣。\u003C\u002Fli>\u003Cli>先看併發、啟動時間、部署大小，再看語法喜不喜歡。\u003C\u002Fli>\u003Cli>把這份清單當成架構適配證據，不要當成流行榜。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>我會怎麼跟團隊講 Go\u003C\u002Fh2>\u003Cp>如果我今天要跟一個團隊談 Go，我不會說它很酷、很現代、很有未來感。那種話太空。我會直接說：如果你現在最痛的是併發、部署、編譯、啟動、維運，Go 很可能能幫你少掉很多摩擦。\u003C\u002Fp>\u003Cp>它最強的地方不是語言表達力，而是 operational friction 低。也就是說，當你的服務需要處理很多事、很快處理、而且不要有太多額外負擔時，Go 很合適。它比較弱的地方也要講清楚：如果你很依賴大型框架、很重的 metaprogramming，或你團隊本來就在另一個語言上很成熟，那硬換 Go 不一定划算。\u003C\u002Fp>\u003Cp>Netguru 這篇有價值的地方，就是它不是拿單一成功案例來洗腦，而是把很多公司放在一起讓你自己看模式。當同一個語言反覆出現在基礎設施、支付、邊緣網路、雲服務這些場景，我就不會把它當成潮流，而是當成一個很務實的選項。\u003C\u002Fp>\u003Cp>所以我的建議很簡單：如果你現在的 stack 正在拖慢你，而且痛點剛好是 Go 擅長的那幾個地方，就先挑一個服務試。不要全站重寫，先挑熱路徑、worker、gateway、或 CLI。量 build time、啟動時間、記憶體、p95\u002Fp99 latency，再來決定要不要繼續。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 為什麼我們在 production 會考慮 Go\n\n我們現在看到的痛點是：\n- 併發工作越來越多\n- build \u002F test 回饋太慢\n- 容器映像檔太大\n- 啟動時間和維運成本開始變高\n\n## Go 適合的情境\n- 高吞吐 API\n- 背景 worker \u002F 任務處理\n- 內部工具與 CLI\n- 容器化部署的服務\n- 需要低記憶體、快啟動的基礎設施元件\n\n## Go 不適合硬上的情境\n- 團隊已經有成熟且穩定的其他語言堆疊\n- 需求高度依賴大型框架生態\n- 需要大量動態 metaprogramming\n- 只是因為想換語言而換語言\n\n## 評估標準\n如果一個服務同時符合以下兩項以上，就值得做 Go pilot：\n1. 併發邏輯開始變複雜\n2. build \u002F test 太慢\n3. 容器映像檔太大\n4. 啟動時間影響部署或擴縮容\n5. 服務主要是 I\u002FO bound\n\n## 內部提案文字\n我們建議先用 Go 重寫這個服務的熱路徑，原因不是語言偏好，而是它能降低 production 裡最常見的摩擦：併發管理、編譯等待與部署複雜度。先做小範圍 pilot，用數據決定是否擴大。\n\n## Pilot 計畫\n1. 挑一個有明確痛點的服務或工具\n2. 只重寫最熱的路徑，不要整包搬\n3. 量測 build time、startup time、記憶體、p95\u002Fp99 latency\n4. 跟現有實作做同條件比較\n5. 只有在數據夠好時才考慮擴大遷移\n\n## 一句話結論\nGo 不是拿來追潮流的，是拿來減少 production 摩擦的。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這篇是我根據 Netguru 原文 \u003Ca href=\"https:\u002F\u002Fwww.netguru.com\u002Fblog\u002Fcompanies-that-use-golang\">19 major companies that use Golang in production\u003C\u002Fa> 做的拆解，不是照抄；公司案例與基礎觀點來自原始文章與 Go 官方資料，標題、脈絡整理與模板是我自己整理出來的。\u003C\u002Fp>","我拆 Netguru 的 Go 產業案例，整理成一份可直接拿去評估後端語言與部署方式的實戰模板。","www.netguru.com","https:\u002F\u002Fwww.netguru.com\u002Fblog\u002Fcompanies-that-use-golang",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782910122046-y1lz.png","tools","zh","60c9b34d-281c-48f1-a389-b30f95af74b9",[17,18,19,20,21],"Go","後端擴充","併發","容器部署","production",[23,24,25],"Go 的價值不在潮，而在併發、編譯速度與部署簡化。","適不適合 Go，先看工作負載與維運痛點，不要先看語言喜好。","先做小範圍 pilot，用 build time、startup time、latency 來決定要不要擴大。",0,"2026-07-01T12:48:16.572103+00:00","2026-07-01T12:48:16.56+00:00","ddbe17bf-4560-43f7-af76-3e7d6e08e601",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":17,"slug":33},"go",{"id":15,"slug":35,"title":36,"language":37},"go-makes-backend-scale-easier-in-production-en","Go makes backend scale easier in production","en",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"380bf473-a8ae-434e-8368-a9225bfcbf28","9-cursor-alternatives-that-beat-lock-in-zh","9 個 Cursor 替代把鎖定感拆掉","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782914601997-id3i.png","2026-07-01T14:02:56.526005+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"deda75f1-0424-44df-88d3-9e38aa714011","ai-video-tools-full-pipeline-wins-zh","AI视频工具的胜负手，已经不是单次生成而是全流程生产","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782912777256-4tyy.png","2026-07-01T13:32:23.499397+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"61fb9cdc-fc82-4660-a4cf-acd9e00a6543","boot-dev-go-playground-teaching-tool-zh","Boot.dev 的 Go Playground 是教學工具，不是完整 IDE","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782909173713-8ndy.png","2026-07-01T12:32:24.645869+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"2fb45a80-d9a5-4758-b2c1-3765e2fe63b1","zhihe-a210-risc-v-soc-dev-kit-breakdown-zh","Zhihe A210 把 RISC-V 變成開發板","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782905601189-7chv.png","2026-07-01T11:32:57.489041+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"17049598-2fff-44b5-a064-ec605d5841cd","meta-opens-astryx-agent-readable-ui-work-zh","Meta 把 Astryx 變成 AI 可讀 UI 系統","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782894775661-sq7f.png","2026-07-01T08:32:27.808221+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"6157c5c6-9094-44f2-ac52-8864221f0df6","awesome-agent-memory-llm-memory-map-zh","Awesome-Agent-Memory：LLM 記憶地圖","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782892088943-6qtg.png","2026-07-01T07:47:39.788137+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"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":87,"slug":88,"title":89,"created_at":90},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"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":97,"slug":98,"title":99,"created_at":100},"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":102,"slug":103,"title":104,"created_at":105},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"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":117,"slug":118,"title":119,"created_at":120},"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":122,"slug":123,"title":124,"created_at":125},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]