[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-aws-kubernetes-managed-clusters-path-zh":3,"article-related-aws-kubernetes-managed-clusters-path-zh":30,"series-tools-f43f7321-9439-4700-a26f-27f3ab2f2b61":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":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"f43f7321-9439-4700-a26f-27f3ab2f2b61","aws-kubernetes-managed-clusters-path-zh","AWS Kubernetes 讓集群變成可管路徑","\u003Cp data-speakable=\"summary\">我把 \u003Ca href=\"\u002Ftag\u002Faws\">AWS\u003C\u002Fa> 的 Kubernetes 頁面拆成可執行的選型筆記：EC2、EKS、ECR 各管什麼，怎麼分責任，最後附可直接貼進設計稿的模板。\u003C\u002Fp>\u003Cp>我用 Kubernetes 在 AWS 上跑過一陣子了。模型沒有問題，工具也都接上了，但總覺得哪裡卡卡的。很多平台頁面都寫得像在安撫人：你只要把容器丟上去，剩下交給\u003Ca href=\"\u002Fnews\u002Fnvidia-microsoft-agentic-ai-pc-cloud-local-zh\">雲端\u003C\u002Fa>。聽起來很順，真的上線就知道不是這回事。你要管的是誰負責控制平面、誰顧節點、誰處理映像、誰扛 DNS 跟流量，還有半夜出事時到底是誰先醒來。我看 AWS 這頁的時候，最有感的不是它講了什麼，而是它終於把責任邊界講得夠清楚，至少沒假裝 Kubernetes 會自己變簡單。\u003C\u002Fp>\u003Cp>我這次拆的是 AWS 的 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fkubernetes\u002F\">Kubernetes on AWS\u003C\u002Fa> 頁面。它沒有給我什麼神奇數字，也沒塞一堆空話，反而是很老實地把 EC2、EKS、ECR 這幾個東西擺在同一張圖上。這種頁面真正的價值，不是教你「什麼是 Kubernetes」，而是讓你看懂 AWS 想把哪一段麻煩收走、哪一段還是你自己扛。旁邊我也會一起對照 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Feks\u002F\">Amazon EKS\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fec2\u002F\">Amazon EC2\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fecr\u002F\">Amazon ECR\u003C\u002Fa> 跟官方 \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Foverview\u002Fcomponents\u002F\">Kubernetes components\u003C\u002Fa> 文件。\u003C\u002Fp>\u003Ch2>先別把 Kubernetes on AWS 當成一個產品\u003C\u002Fh2>\u003Cblockquote>“You can choose to manage Kubernetes infrastructure yourself with Amazon EC2 or get an automatically provisioned, managed Kubernetes control plane with Amazon EKS.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：AWS 不是在賣你一個單一答案，它是在給你一條分岔路。左邊是你自己管，右邊是 AWS 幫你把控制平面收掉。這差很多，真的差很多。很多團隊會把「上了雲」誤認成「少做事」，結果最後還是每天在處理同一堆 cluster 雜務，只是票單從 on-prem 換成雲端而已。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781283806970-wp6p.png\" alt=\"AWS Kubernetes 讓集群變成可管路徑\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前也踩過這個洞。以為只要用了 Kubernetes，就能把部署、擴縮、容錯都交給系統，結果實際上只是把複雜度從應用層搬到平台層。AWS 這頁最值得看的地方，就是它沒有騙你。它直接告訴你，\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fec2\u002F\">EC2\u003C\u002Fa> 路線是你自己管理 Kubernetes 基礎設施；\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Feks\u002F\">EKS\u003C\u002Fa> 路線則是把 managed control plane 交給 AWS。也就是說，你不是在選「能不能用 Kubernetes」，你是在選「哪些麻煩要留在自己手上」。\u003C\u002Fp>\u003Cp>實操上，我會先寫責任分工，不會先開 Terraform。因為如果團隊連誰管升級、誰管節點、誰管映像都講不清楚，後面所有架構圖都只是裝飾。這件事我看過太多次：圖畫得很漂亮，incident 來的時候每個人都說自己只負責一半。\u003C\u002Fp>\u003Cul>\u003Cli>想要完全掌控，選 EC2，但要接受更多運維工作。\u003C\u002Fli>\u003Cli>想把控制平面從日常雜務裡拿掉，選 EKS。\u003C\u002Fli>\u003Cli>映像儲存和發佈要一起想，直接把 ECR 納進流程。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Pod 才是 Kubernetes 真正在意的單位\u003C\u002Fh2>\u003Cblockquote>“Containers are run in logical groupings called pods and you can run and scale one or many containers together as a pod.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：Kubernetes 不是先想「一個 container」，它先想「一組一起活、一起死的東西」。這是很多人一開始最容易誤解的地方。你如果只把 pod 當成容器外面的殼，後面一定會卡。因為真實世界裡，應用\u003Ca href=\"\u002Fnews\u002Fbugbots-speed-and-cost-gains-make-ai-code-review-usable-zh\">程式\u003C\u002Fa>旁邊常常還有 sidecar、log collector、proxy、metrics exporter，這些東西不是裝飾品，是要一起共存的。\u003C\u002Fp>\u003Cp>我之前就犯過這個錯。那時候我把 pod 想成「一個 app 放一個 container」的簡單映射，結果一旦要加共用網路、共用 storage、或是要讓輔助程序跟主程序共享生命週期，整個模型就開始漏水。AWS 頁面講得很白：一個 pod 可以跑一個或多個 container，而且 Kubernetes 會用 pod 這個單位來排程與重啟。也就是說，你真正要設計的不是某個 binary，而是它的 runtime 邊界。\u003C\u002Fp>\u003Cp>實操上，我會先決定每個 workload 是單容器 pod 還是多容器 pod。要不要 sidecar，不是看潮不潮，是看它們是不是必須共享網路命名空間、生命週期、或本地通訊。如果要，就老實把它們收進同一個 pod；如果不要，就別硬湊，免得未來 debug 時自己打自己臉。\u003C\u002Fp>\u003Cul>\u003Cli>單容器 pod 適合簡單、獨立、沒有額外輔助程序的服務。\u003C\u002Fli>\u003Cli>多容器 pod 適合要共享生命週期或本地通訊的工作負載。\u003C\u002Fli>\u003Cli>不要因為「Kubernetes 就該這樣」而用 pod，先看需求再決定。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>控制平面是你最晚看到、但最先出事的地方\u003C\u002Fh2>\u003Cblockquote>“Kubernetes control plane software decides when and where to run your pods, manages traffic routing, and scales your pods based on utilization or other metrics that you define.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：控制平面不是跑你業務邏輯的地方，但它決定你的業務邏輯能不能正常活著。這個東西平常存在感很低，一出事就會讓整個 cluster 像中邪。排程卡住、\u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> 慢、deployment 卡在半路、autoscaling 沒反應，最後你會發現不是 app 壞，是那個「決定 app 何時能跑」的腦袋在抽風。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781283808610-horq.png\" alt=\"AWS Kubernetes 讓集群變成可管路徑\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>AWS 的頁面其實有把這件事講清楚。它把 cluster 分成 control plane 跟 data plane，前者管排程、API、流量路由與擴縮，後者才是 workload 真正落地的地方。這個切法很重要，因為它直接影響你要不要自己扛 master instances、etcd、升級節奏、健康檢查。我看過很多團隊把注意力全放在節點規格，結果控制平面一出問題，整個系統就像少了方向盤。\u003C\u002Fp>\u003Cp>實操上，我會把 control plane ownership 寫進架構文件。用 EKS 的話，就明確列出 AWS 管什麼、我自己管什麼；用 EC2 的話，就把升級、備份、API 可用性檢查、故障切換寫死。不要模糊。模糊最貴，尤其是在 Kubernetes 上。\u003C\u002Fp>\u003Cp>如果你想對照更底層的概念，我會直接看官方 \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Foverview\u002Fcomponents\u002F\">Kubernetes components\u003C\u002Fa>。AWS 的頁面是導覽，Kubernetes 官方文件才是機械結構圖。\u003C\u002Fp>\u003Ch2>EC2 給你控制，也順便把瑣事一起塞回來\u003C\u002Fh2>\u003Cblockquote>“Consider using Amazon EC2 if you want to fully manage your Kubernetes deployment.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你要的是完全控制，那就別幻想會比較輕鬆。EC2 路線的好處很直接，你可以自己挑 instance family、自己控節點行為、自己決定怎麼做 scaling 跟 patching。壞處也很直接，這些事大多數都得你自己做。AWS 沒有在這裡包裝成什麼輕盈的體驗，它只是很誠實地說，這條路就是 fully manage。\u003C\u002Fp>\u003Cp>我不是反對控制。某些情境你真的需要它，例如特殊網路需求、合規限制、或你們平台團隊本來就很成熟，已經有能力把節點層玩得很細。這時候 EC2 不是退而求其次，而是刻意選擇。但如果你的理由只是「我們想比較專業」，那我會直接勸你停一下。專業不是自己多養幾台機器，專業是知道哪裡值得自己管，哪裡不值得。\u003C\u002Fp>\u003Cp>實操上，我會把 EC2-based Kubernetes 留給需要特殊 node 行為、特殊網路拓撲、或要深度掌握平台細節的團隊。其他情況，我不會先選它。因為我很清楚，所謂的自由，最後常常只是更多 on-call。\u003C\u002Fp>\u003Cul>\u003Cli>適合：有明確客製化基礎設施需求。\u003C\u002Fli>\u003Cli>適合：平台團隊成熟，能承接更多運維責任。\u003C\u002Fli>\u003Cli>不適合：想把維運面積縮到最小的應用團隊。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>EKS 的價值不是省錢，是把麻煩收斂到你看得懂的地方\u003C\u002Fh2>\u003Cblockquote>“Amazon EKS is a certified conformant, managed Kubernetes service.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：AWS 不是做一個像 Kubernetes 的東西，它是說自己跟 upstream 相容，而且把 control plane 這段收走。這點我很在意。因為我不想用一個 managed service，結果它的行為像 Kubernetes，但只有在文件寫得很漂亮的時候才像。\u003C\u002Fp>\u003Cp>AWS 還特別提到，EKS 不需要你自己 provision 或管理 master instances 和 etcd。這句很直白，但我覺得它是整頁最有分量的一句。因為 master 跟 etcd 就是那種「重要但不該成為你每天主要工作」的東西。你當然要理解它們，但不一定要親手養它們。這就是 managed service 的價值：不是幫你變強，而是幫你少碰那些不該天天碰的部分。\u003C\u002Fp>\u003Cp>實操上，我幾乎會先預設 EKS，除非有很具體的理由不選。理由要能寫進文件，不是寫在 Slack 裡的感覺。像是合規、特殊節點控制、或某些平台限制，這些都算理由；「我們比較喜歡自己弄」不算。這種偏好通常會在第三次升級事故後被現實修理。\u003C\u002Fp>\u003Cp>如果你要看服務本體，我會直接從 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Feks\u002F\">Amazon EKS\u003C\u002Fa> 產品頁接下去。那裡才是 managed service 細節的主場。\u003C\u002Fp>\u003Ch2>真正麻煩的是網路、身份、映像和服務發現\u003C\u002Fh2>\u003Cblockquote>“AWS makes it easy to run Kubernetes in the cloud with scalable and highly available virtual machine infrastructure, community-backed service integrations, and Amazon Elastic Kubernetes Service (EKS).”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：AWS 想賣你的不只是算力，而是整套周邊。因為 Kubernetes 真正讓人煩的從來不是「能不能跑」，而是跑起來之後怎麼讓別的東西找得到它、怎麼安全地拉映像、怎麼把流量導進來、怎麼把權限切清楚。\u003C\u002Fp>\u003Cp>這就是我覺得 AWS 頁面還算老實的地方。它有提到 VPC、IAM、service discovery、ECR 這些東西，因為這些才是 production 會出事的地方。很多人一開始只盯著 nodes 跟 pods，等真的上線才發現，最麻煩的其實是 glue layer。不是容器本身難，是容器跟周邊系統怎麼接，這件事最容易爛掉。\u003C\u002Fp>\u003Cp>實操上，我會把 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fvpc\u002F\">Amazon VPC\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fiam\u002F\">AWS IAM\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fecr\u002F\">Amazon ECR\u003C\u002Fa> 一起納進設計，而不是一個一個補。DNS 和 service discovery 也要早點處理，不要等到上線後才開始用 annotation 補洞。那種補法很常見，也很常死得很慢。\u003C\u002Fp>\u003Cul>\u003Cli>VPC 管住網路邊界。\u003C\u002Fli>\u003Cli>IAM 管住身份與權限。\u003C\u002Fli>\u003Cli>ECR 管住映像儲存與發佈。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>生態系不是加分題，是你能不能少重造輪子的差別\u003C\u002Fh2>\u003Cblockquote>“A large community of developers and companies build extensions, integrations, and plugins that help Kubernetes users do more.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：Kubernetes 本體只是底座，真正讓它能用的是周邊生態。AWS 這頁提到的那些工具我不覺得是湊數，反而很像在講真話：你不會只用 Kubernetes，你一定會接 ingress、DNS、node provisioning、manifest 管理，甚至是特定工作負載的 controller。\u003C\u002Fp>\u003Cp>我比較喜歡這段，因為它沒有假裝平台可以包山包海。它直接承認你還是需要工具鏈，只是 AWS 幫你挑了一些跟它家雲環境比較合拍的選項。像 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Faws-load-balancer-controller\">AWS Load Balancer Controller\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fexternal-dns\">ExternalDNS\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkarpenter.sh\u002F\">Karpenter\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fcdk8s-team\u002Fcdk8s\">cdk8s\u003C\u002Fa>，這些都不是裝飾，是把 cluster \u003Ca href=\"\u002Fnews\u002Fai-coding-praise-turns-into-production-debt-zh\">變成\u003C\u002Fa>可操作平台的拼圖。\u003C\u002Fp>\u003Cp>實操上，我會故意少選工具。不是越多越好，真的不是。Ingress 一套、DNS 一套、節點自動化一套、manifest 管理一套，先這樣就夠了。你如果把每個需求都交給不同插件，最後不是平台變強，是平台變得沒人敢動。\u003C\u002Fp>\u003Cp>如果你的工作負載是 ML 或模型服務，AWS 還提到 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpytorch\u002Fserve\">TorchServe\u003C\u002Fa>。這表示它不是只在講 web service，而是在講容器化工作負載的整體路徑。這點我認同，因為 Kubernetes 真正有用的地方，本來就不是某一種 app，而是那套跑法。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Kubernetes on AWS 選型筆記模板\n\n## 我到底要跑什麼\n- Workload 類型：\n- 流量型態：\n- 是否有 stateful 元件：\n- 合規 \u002F 隔離需求：\n\n## 控制平面怎麼選\n- [ ] EKS\n- [ ] EC2 自管 Kubernetes\n\n### 我這樣選的理由\n- 如果選 EKS：我希望 AWS 幫我管 control plane 與 etcd。\n- 如果選 EC2：我需要完全掌控 cluster 管理與 node 行為。\n\n## Data plane 怎麼做\n- Instance family：\n- Node group 策略：\n- Autoscaling 方案：\n- 升級責任：\n\n## Pod 要怎麼切\n- 這個 workload 是單容器 pod 還是多容器 pod：\n- 需要哪些 sidecar：\n- 是否需要共享 storage：\n- 是否依賴 localhost 通訊：\n\n## 網路與身份\n- VPC 規劃：\n- Ingress 策略：\n- DNS \u002F service discovery：\n- IAM role mapping：\n\n## 映像流程\n- Registry：Amazon ECR\n- Build pipeline：\n- Promotion path：\n- Rollback 方式：\n\n## 我允許的 Kubernetes 擴充\n- [ ] AWS Load Balancer Controller\n- [ ] ExternalDNS\n- [ ] Karpenter\n- [ ] cdk8s\n- [ ] 其他：\n\n## 運維責任\n- 誰 patch nodes？\n- 誰升級 Kubernetes？\n- 誰看 control plane health？\n- 誰處理 incident？\n\n## 重新評估條件\n我會重看這份設計，如果：\n- control plane 負擔變太重\n- node 管理太手工\n- service discovery 開始脆弱\n- 團隊講不清楚部署路徑\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我這篇的拆解是從 AWS 的 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fkubernetes\u002F\">Kubernetes on AWS\u003C\u002Fa> 頁面出發，原始架構與產品分工是 AWS 提供的；上面這份責任切法、判斷方式與可抄模板，是我把它翻成\u003Ca href=\"\u002Ftag\u002F台灣開發者\">台灣開發者\u003C\u002Fa>比較好直接拿去用的版本。\u003C\u002Fp>","我把 AWS 的 Kubernetes 頁面拆成可執行的選型筆記：EC2、EKS、ECR 各管什麼，怎麼分責任，最後附可直接貼進設計稿的模板。","aws.amazon.com","https:\u002F\u002Faws.amazon.com\u002Fkubernetes\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781283806970-wp6p.png","tools","zh","153aa345-5b76-4a07-b734-e1e3d759dc5a",[17,18,19,20,21],"Kubernetes","AWS","EKS","EC2","ECR",[23,24,25],"AWS 的重點不是把 Kubernetes 變簡單，而是把責任邊界講清楚。","EKS 的價值在於收走 control plane 與 etcd，讓你少碰不該天天碰的麻煩。","真正要先設計的是 pod、網路、身份、映像與責任分工，不是先畫漂亮架構圖。",1,"2026-06-12T17:02:58.687247+00:00","2026-06-12T17:02:58.678+00:00","555fc729-c415-4719-ada8-808b97f1cbda",{"tags":31,"relatedLang":42,"relatedPosts":46},[32,34,36,38,40],{"name":19,"slug":33},"eks",{"name":17,"slug":35},"kubernetes",{"name":18,"slug":37},"aws",{"name":20,"slug":39},"ec2",{"name":21,"slug":41},"ecr",{"id":15,"slug":43,"title":44,"language":45},"aws-kubernetes-managed-clusters-path-en","AWS Kubernetes turns clusters into a managed path","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"6627f35e-3e66-445f-8c2a-188797ffd22b","microsoft-build-2026-agents-into-systems-zh","Build 2026 把代理變系統","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781329733213-teym.png","2026-06-13T05:48:21.486989+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"1f8c57f4-698a-42a5-80e8-85cf7cb915d6","mimo-v25-pro-turns-agent-work-into-one-api-call-zh","MiMo-V2.5-Pro 把 agent 工作變成一個 API","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781320694317-up12.png","2026-06-13T03:17:48.351417+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"bcf84ab5-c420-448a-968b-d6777d846d68","8-cursor-alternatives-that-fit-how-you-work-zh","8 款 Cursor 替代品怎麼選","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781312602751-6ay6.png","2026-06-13T01:02:56.132136+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"4cd74291-8fb5-4203-ba64-b9e5cc5dec68","ollama-default-local-ai-layer-zh","Ollama 正在成為預設的本地 AI 層","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781310769394-h8f5.png","2026-06-13T00:32:16.314447+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"d151c5d3-b298-499a-9524-f06d42a8b26b","songscription-turns-piano-audio-into-editable-sheet-music-zh","Songscription 讓鋼琴音檔變可編輯樂譜","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781288303307-ll88.png","2026-06-12T18:17:55.667582+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"d1ee04c1-484e-4b7e-804d-414053db6ce0","ios-27-turns-apple-music-into-smarter-player-zh","iOS 27 讓 Apple Music 變更會聽","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781287411723-ze4w.png","2026-06-12T18:02:58.114644+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"]