[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-aws-continuum-turns-ai-coding-into-safer-fixes-zh":3,"article-related-aws-continuum-turns-ai-coding-into-safer-fixes-zh":30,"series-tools-cad5997c-d40d-4fac-9b39-e1f86a326107":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":23,"views":27,"created_at":28,"published_at":29,"topic_cluster_id":11},"cad5997c-d40d-4fac-9b39-e1f86a326107","aws-continuum-turns-ai-coding-into-safer-fixes-zh","AWS Continuum 把修漏洞變安全建議","\u003Cp data-speakable=\"summary\">以前是先寫完再補救，現在是寫碼時就先把風險壓進建議裡。\u003C\u002Fp>\u003Cp>我用一堆 AI 寫碼流程一陣子了，老實說，最煩的從來不是\u003Ca href=\"\u002Fnews\u002Ftest-time-harnesses-weak-model-transfer-zh\">模型\u003C\u002Fa>不會寫，是它寫得太順，順到像在幫我把雷先埋好。程式碼一段段吐出來，看起來很像樣，安全掃描卻總是在最後一刻跳出來補刀。你一邊想趕進度，一邊還要回頭猜這個修補到底會不會把別的地方弄壞。我最受不了的是，那些告警常常不是太晚，就是太吵，最後開發者只會更想忽略它。\u003C\u002Fp>\u003Cp>這次我看到 AWS 的這篇文章 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fsecurity\u002Faws-partners-with-anthropic-and-openai-to-bring-aws-continuum-into-developer-workflows\u002F\">AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows\u003C\u002Fa>，才覺得這路線有點意思。它不是在喊什麼空泛口號，而是直接把安全檢查塞回 \u003Ca href=\"\u002Ftag\u002Fclaude-code\">Claude Code\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fopenai.com\u002Fcodex\">Codex\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkiro.dev\u002F\">Kiro\u003C\u002Fa> 這種開發者真的會用的地方。AWS 要做的不是多一個掃描\u003Ca href=\"\u002Fnews\u002Fagent-plugins-1-0-0-ship-tool-packs-zh\">工具\u003C\u002Fa>，是把判斷、排序、驗證、修補，往前推到寫碼當下。\u003C\u002Fp>\u003Ch2>真正麻煩的從來不是找漏洞，是決定哪些真的要管\u003C\u002Fh2>\u003Cblockquote>「AWS Continuum for code vulnerabilities (Preview) is built to be that tool to help secure your code at machine speed.」\u003C\u002Fblockquote>\u003Cp>翻譯一下就是，AWS 不想再把重點放在「我能不能抓到問題」，而是「我能不能在機器速度下把問題處理完」。這句話很直白，也很誠實。因為現在模型越強，找出來的東西只會更多；真正拖垮團隊的，往往不是偵測本身，而是後面那串 triage、驗證、確認影響範圍、再決定要不要修。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786644251974-emsc.png\" alt=\"AWS Continuum 把修漏洞變安全建議\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己看過不少團隊栽在這裡。掃描器一口氣噴出幾十條 finding，資安同事看了皺眉，開發同事看了翻白眼，最後大家都在忙著證明「這個其實沒那麼嚴重」。問題是，沒有人想一直做這種重工。你要的是能把 finding 跟真實環境對起來的系統，不是只會列清單的機器。\u003C\u002Fp>\u003Cp>AWS 這篇文章的重點很明確：漏洞不是不能找，而是找到了之後要知道它在你的 AWS 環境裡到底有多要命。這差很多。抽象世界裡的高風險，到了實際部署裡可能只是低優先；反過來，某些看起來不起眼的設定，放進你的 IAM、網路路徑、暴露面之後，反而才是真洞。\u003C\u002Fp>\u003Cp>實操上我會這樣做：如果你在做內部安全助手，先別急著把 raw finding 當產品。你至少要多一層判斷，回答三件事：這個洞在現在的環境能不能打到、值不值得先修、開發者下一步該做什麼。答不出來，你做出來的只是比較會講話的掃描器。\u003C\u002Fp>\u003Cul>\u003Cli>先把 finding 分成「可利用」「可疑但未確認」「只是噪音」。\u003C\u002Fli>\u003Cli>再把每條 finding 對到實際部署情境，而不是只看靜態規則。\u003C\u002Fli>\u003Cli>最後才給開發者修補建議，別一上來就丟一堆恐嚇式訊息。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>模型不是流程，AWS 這句話講得很老實\u003C\u002Fh2>\u003Cblockquote>「The next challenge customers face is building the correct harness and orchestration to turn these models into a single interface that goes from detection through remediation.」\u003C\u002Fblockquote>\u003Cp>也就是說，模型本身只是零件，真正難的是外面那層 harness 和 orchestration。這我超有感。很多團隊很愛把 \u003Ca href=\"\u002Ftag\u002Fllm\">LLM\u003C\u002Fa>、向量庫、幾個 API 串一串，就說自己有 AI \u003Ca href=\"\u002Fnews\u002Fopen-generative-ai-github-studio-breakdown-zh\">工作\u003C\u002Fa>流了。結果一換模型就壞，一改權限就裂，一個工具回傳格式變了，整條鏈就像紙糊的。\u003C\u002Fp>\u003Cp>AWS 這裡其實是在提醒大家：你要的是可運作的系統，不是會聊天的模型。harness 是把模型包起來的那層東西，裡面要有工具呼叫、guardrails、記憶、環境上下文、回饋迴路。少了這層，模型再聰明也只是坐在地上的引擎，跑得動但接不起來。\u003C\u002Fp>\u003Cp>我之前幫人看過一套內部 \u003Ca href=\"\u002Ftag\u002Fai-工具\">AI 工具\u003C\u002Fa>，表面上很完整，實際上每個步驟都靠不同 repo、不同腳本、不同人手動補。最麻煩的是，這些 glue code 往往沒人想認領。出事的時候大家都說那只是臨時接法，但臨時接法一旦長成正式流程，就會變成真正的系統。\u003C\u002Fp>\u003Cp>實操寫法很簡單：先把你現在所有隱藏的接線找出來。誰在轉 prompt、誰在檢查 policy、誰在存 context、誰在決定要不要放行。再問一個更殘酷的問題：如果你今天把模型換掉，哪一段會立刻壞掉。答案如果散在六個 repo 和一串 Slack 訊息裡，那你沒有 harness，你只有一坨腳本。\u003C\u002Fp>\u003Cul>\u003Cli>模型品質決定你能不能抓到問題。\u003C\u002Fli>\u003Cli>流程品質決定你能不能穩定處理問題。\u003C\u002Fli>\u003Cli>工作流品質決定開發者會不會真的用。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Continuum 本質上是一個有分工的 agent loop\u003C\u002Fh2>\u003Cblockquote>「Under the hood, Continuum is an agent-team loop architecture.」\u003C\u002Fblockquote>\u003Cp>這句話很重要，因為它把這東西從「單一 AI 助手」拉回比較像團隊作業的結構。它不是只丟一個掃描器給你，也不是叫一個 bot 自己猜答案。它是讓不同角色各做各的：有人找問題、有人排序、有人驗證、有人把修補建議送回開發流程。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786644237669-p278.png\" alt=\"AWS Continuum 把修漏洞變安全建議\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>白話一點，就是 AWS 想把原本跨工具、跨人、跨 ticket 的工作，壓成一條連續迴路。你寫碼，系統掃描；系統把 finding 對到你的 AWS 環境；系統驗證這個洞到底有沒有影響；最後再把結果回灌到 coding assistant，讓它下一次不要再亂提同一條路。\u003C\u002Fp>\u003Cp>我以前手動湊過類似流程，真的很煩。掃描工具說有問題，另一個工具說可能沒事，資安同事要你補證據，開發同事只想知道到底要不要改。這種時候如果沒有 loop，最後就是人腦在當整合層。你以為自己在寫 code，其實你在幫工具翻譯工具。\u003C\u002Fp>\u003Cp>實操上，我會建議你把自己的安全自動化拆成四步：偵測、脈絡化、驗證、建議。少一個都別急著說自己是端到端。如果你只能做到偵測，那就誠實叫它掃描器；如果你做到最後一步，才有資格說它真的在幫開發者做事。\u003C\u002Fp>\u003Ch2>把安全放進 Claude Code、Codex、Kiro 才是真的有用\u003C\u002Fh2>\u003Cblockquote>「Within Claude Code, Codex, and Kiro coding environments, on-demand vulnerability scans identify potential issues and send findings to Continuum.」\u003C\u002Fblockquote>\u003Cp>這段我覺得最實際。AWS 沒有叫開發者離開編輯器去看另一個儀表板，也沒有再發明一個新的資安後台。它是直接把安全檢查塞進開發者本來就在用的環境裡。這種做法很土，但土得對。因為只要多跳一次頁面，很多人就懶了；只要多一個工具在旁邊吵，大家就會想先把它關掉。\u003C\u002Fp>\u003Cp>這裡的流程大概是這樣：開發者在 \u003Ca href=\"\u002Ftag\u002Fclaude\">Claude\u003C\u002Fa> Code、\u003Ca href=\"\u002Ftag\u002Fcodex\">Codex\u003C\u002Fa> 或 Kiro 裡寫程式；按需觸發漏洞掃描；Continuum 把 finding 接過去，對照客戶的 AWS 環境；再把結果回送到 assistant，讓 assistant 接下來的建議不會繼續往危險方向走。這比「寫完再丟 CI，等資安開 ticket」順太多了。\u003C\u002Fp>\u003Cp>我不是說 CI 掃描沒用，當然有用。但如果 assistant 在生成階段就知道某條路很危險，它根本不該一開始就把那條路端出來。少走一個死路，後面就少一堆返工。這種省時，不是省一點，是整個流程的摩擦都少一圈。\u003C\u002Fp>\u003Cp>實操寫法：如果你要把安全放進開發工具，不要做成「存檔後跳警告」。你要讓 assistant 在生成當下就看見環境限制。越早知道 IAM、網路、暴露面有什麼限制，越少會產生那種看起來很聰明、其實根本不能上線的建議。\u003C\u002Fp>\u003Cul>\u003Cli>Claude Code 適合讓建議在互動中即時修正。\u003C\u002Fli>\u003Cli>Codex 適合把生成與安全回饋放在同一個迴圈。\u003C\u002Fli>\u003Cli>Kiro 適合把驗證過的建議直接回到工作流裡。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>真正值錢的是環境脈絡，不是告警本身\u003C\u002Fh2>\u003Cblockquote>「Continuum prioritizes them within the context of the customer’s AWS environment (configurations, AWS Identity and Access Management (IAM) policies, network topology, and exposure surfaces) and validates them in a sandbox.」\u003C\u002Fblockquote>\u003Cp>這句我很買單，因為它終於把「環境脈絡」講清楚了。漏洞本身只是一個抽象事件，放進你的 AWS 環境才會變成真正的風險。IAM 權限很窄、網路路徑很封閉、暴露面根本碰不到，風險等級就會完全不一樣。很多 scanner 的問題，就是它只會看洞，不會看洞外面那層現實。\u003C\u002Fp>\u003Cp>我看過太多團隊不是過度反應，就是完全不理。過度反應通常是因為工具沒脈絡，看到關鍵字就嚇到；完全不理則是因為工具說不出影響，久了大家只當它在吵。AWS 這裡想做的，是把脈絡變成預設輸入，而不是事後補的資料欄位。\u003C\u002Fp>\u003Cp>sandbox 驗證也很重要。它代表系統不是只靠信心分數在唬人，而是先在受控環境裡確認這條 finding 的行為，再把修補建議推回去。這會大幅降低誤報和亂修。對開發者來說，最討厭的不是被提醒，而是被提醒之後還要自己證明提醒是錯的。\u003C\u002Fp>\u003Cp>實操上，我會要求你的安全自動化至少接到這些資料：IAM、網路路徑、部署設定、服務暴露面。沒有這些，你的工具就只能猜。還有，sandbox 不要省。很多團隊都說之後再驗證，結果之後永遠不來。你如果想讓開發者信任安全建議，就得先拿出證據，不是丟一個漂亮的分數。\u003C\u002Fp>\u003Ch2>AWS 其實是在賣少一堆交接\u003C\u002Fh2>\u003Cblockquote>「This collapses what was traditionally a multi-step, multi-team process (write, scan, triage, prioritize, fix, rescan) into a single outcome: the code suggestion itself.」\u003C\u002Fblockquote>\u003Cp>這句話很直白，也很誠實。現在的安全流程本來就一堆交接：寫完、掃描、分類、排序、修補、再掃一次。每一次交接都會掉 context，每掉一次，開發者就更不想管。最後不是沒修，而是修得很慢，慢到大家都忘了為什麼要修。\u003C\u002Fp>\u003Cp>AWS 真正在推的，是把摩擦提早到作者還在線上的時候。assistant 如果知道某條路很危險，就不要再推那條路；如果某個修補已經驗證過，就直接給開發者一個能接受的版本。這樣做不是讓資安消失，而是讓資安不必等到事情變爛才出現。\u003C\u002Fp>\u003Cp>我看原文時有注意到一點：AWS 提到早期設計夥伴已經有成果，但我看到的段落在引述處就截掉了，所以我不會亂補數字或亂接後半句。這種事我寧可老實一點。重點不是那句沒補完的讚美，而是方向很清楚——assistant 本身要變成安全決策發生的地方。\u003C\u002Fp>\u003Cp>實操寫法：把你的流程拿來數交接次數。每一條 finding 從出現到真的被處理，中間經過幾個工具、幾個人、幾次切換。然後想辦法砍掉一半。只要你能把驗證和修補建議拉近到作者那一步，速度會快很多，垃圾 finding 也會少很多。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># AI 寫碼安全工作流模板\n\n這個模板適合你想把安全檢查塞回開發助手，而不是另外養一套吵人的掃描平台。\n\n## 流程\n\n1. 開發者在 AI 助手環境中寫碼。\n2. 對目前草稿觸發一次按需漏洞掃描。\n3. 把 finding 送進安全協調層。\n4. 對每條 finding 補上環境脈絡：\n   - IAM 權限\n   - 網路路徑\n   - 部署設定\n   - 暴露面\n5. 在 sandbox 裡驗證這條 finding 是否真的成立。\n6. 回傳三種結果給 coding assistant：\n   - 可以繼續\n   - 需要修補\n   - 需要人工確認\n7. 讓 assistant 根據結果調整下一輪建議。\n\n## 判斷規則\n\n- 如果在目前環境裡根本打不到，就降級優先順序。\n- 如果可以打到，而且已經驗證成立，就立刻給修補建議。\n- 如果驗證不清楚，就不要自動修，直接要求人工確認。\n- 如果同一類問題一直重複出現，把它當工作流缺陷，不只是程式缺陷。\n\n## 給 assistant 的提示詞\n\n你正在為正式的 AWS 生產環境產生程式碼。\n在提出任何做法前，先檢查：\n- 這個動作是否需要更高權限的 IAM\n- 這個動作是否增加網路暴露\n- 這個動作是否引入已知漏洞模式\n- 有沒有更安全的替代方案\n\n如果危險路徑其實不必要，先提更安全的方案。\n如果有可用修補，請用一句話說清楚代價。\n\n## 輸出格式\n\n每個問題回傳：\n- finding_id\n- severity\n- environment_context\n- validation_status\n- recommended_fix\n- developer_action\n\n## 基本護欄\n\n- 不要把原始掃描結果當成最終真相。\n- 不要把脈絡藏起來不給開發者看。\n- 沒驗證前，不要自動套用修補。\n- 就算語法正確，也不要推薦違反政策的程式碼。\n\n## 最小實作清單\n\n- [ ] 把 assistant 輸出接到掃描結果\n- [ ] 加上環境脈絡補強\n- [ ] 加上 sandbox 驗證\n- [ ] 把驗證結果回灌給 assistant\n- [ ] 記錄每一次交接\n- [ ] 每週檢查誤報\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我會先從這個模板開始，就算你現在不用 AWS Continuum 也沒差。真正有用的是這個形狀：偵測、補脈絡、驗證、再建議。這才是我想放進任何 AI 寫碼工具裡的流程。\u003C\u002Fp>\u003Cp>如果你要自己做一套，記得要有立場一點。開發者不需要另一個什麼都會講一點、最後什麼都不負責的 AI 外殼。真正有用的是知道什麼時候該閉嘴、什麼時候該提醒、什麼時候該直接給可修的版本。\u003C\u002Fp>\u003Cp>原始來源是 AWS Security Blog 這篇 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fsecurity\u002Faws-partners-with-anthropic-and-openai-to-bring-aws-continuum-into-developer-workflows\u002F\">AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows\u003C\u002Fa>，另外也參考了 \u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fclaude-code\">Claude Code\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fopenai.com\u002Fcodex\">OpenAI Codex\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkiro.dev\u002F\">Kiro\u003C\u002Fa> 的官方頁面。上面這篇拆解裡，產品敘述與引文來自原文，我的判讀、脈絡整理和模板是我自己整理出來的。\u003C\u002Fp>","AWS Continuum 把掃描、排序、驗證和修補塞進 Claude Code、Codex、Kiro，讓 AI 寫碼時就先看見風險。","aws.amazon.com","https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fsecurity\u002Faws-partners-with-anthropic-and-openai-to-bring-aws-continuum-into-developer-workflows\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786644251974-emsc.png","tools","zh","8a602145-fe30-42b4-9db4-b33079f61aeb",[17,18,19,20,21,22],"AWS Continuum","AI 寫碼","漏洞驗證","安全工作流","Claude Code","agent loop",[24,25,26],"把安全檢查往前推到寫碼當下，別等 CI 和 ticket 才處理。","真正值錢的是環境脈絡與 sandbox 驗證，不是單純掃出更多 finding。","把偵測、補脈絡、驗證、建議串成迴路，才能少交接、少返工。",0,"2026-08-13T18:03:30.983335+00:00","2026-08-13T18:03:30.971+00:00",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":21,"slug":33},"claude-code",{"id":15,"slug":35,"title":36,"language":37},"aws-continuum-turns-ai-coding-into-safer-fixes-en","AWS Continuum turns AI coding into safer fixes","en",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"9cbd8e8a-df48-4e25-a950-2a8552a11c1e","open-generative-ai-github-studio-breakdown-zh","Open-Generative-AI 讓 GitHub 變工作室","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786622603725-o8ad.png","2026-08-13T12:02:47.120311+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"98e7c6dd-38f6-4740-bb79-20985bff3f9a","benchmark-scores-dont-predict-your-bill-zh","Benchmark 分數不等於帳單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786496578340-z656.png","2026-08-12T01:02:41.398372+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"f78a22c7-f366-42a7-bd2e-95e281ad5e67","mcp-servers-8-developer-workflow-gains-2026-zh","MCP Servers 讓開發流程少切 5 次工具","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786478563429-55iv.png","2026-08-11T20:02:16.492009+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"24f805e3-546a-4f39-90ea-2253d8846165","doubao-one-hour-flash-game-collection-zh","豆包1小時把摸魚遊戲做成合集","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786437237945-awlu.png","2026-08-11T08:33:17.309085+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"df203653-afe2-4c37-9d70-af6d94461423","coding-plan-bailian-developer-subscription-zh","Coding Plan把百炼变订阅","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786435438230-esg2.png","2026-08-11T08:03:27.012167+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"7c5f393f-e45a-45d0-98fe-28abc173ba11","baidu-wenxin-search-to-agent-template-zh","百度文心把搜索底子变成Agent能力","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786365239713-gwqo.png","2026-08-10T12:33:19.194341+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"]