[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-model-triage-coding-tests-cost-win-zh":3,"article-related-model-triage-coding-tests-cost-win-zh":30,"series-tools-60a23c5e-d9df-4186-a30e-5d2c123a0ed6":73},{"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},"60a23c5e-d9df-4186-a30e-5d2c123a0ed6","model-triage-coding-tests-cost-win-zh","模型分流把測試成本壓下來","\u003Cp data-speakable=\"summary\">我把 coding 任務先分級，再把便宜模型放前面，能省錢又不太傷品質。\u003C\u002Fp>\u003Cp>我用 \u003Ca href=\"\u002Ftag\u002Fai-coding\">AI coding\u003C\u002Fa> assistant 用到現在，最常冒出來的不是「它做不到」，而是「靠北，這題根本不值得用這麼貴的模型」。輸出看起來沒問題，demo 也挺順，直到我去看 usage log，才發現自己在替一個本來可以很無聊的任務，付了很不無聊的錢。這種感覺很差，因為它不是失敗，是默默漏錢。\u003C\u002Fp>\u003Cp>更煩的是，這種浪費很容易被包裝成效率。大模型回得快、講得像樣、通常也能把事情推到八九成，所以你會懶得再想。久了之後，習慣就長歪了：什麼都先丟最貴的那顆。這不是架構能力，這比較像手滑。\u003C\u002Fp>\u003Cp>我後來才想通，模型選擇不是一次性的「我家就用這個」決策，而是 triage 問題。不同任務本來就該走不同路徑。這篇把我拆開這套思路的來源放在這裡：\u003Ca href=\"https:\u002F\u002Fthenewstack.io\u002Fclaude-fable-cost-model-triage\u002F\">The New Stack 對 Claude Fable 與 GPT-5.5 成本差異的文章\u003C\u002Fa>。它不是在講玄學，是在提醒你同一個 coding test，放不同模型上，成本可以差很多。\u003C\u002Fp>\u003Cp>我現在比較不把這件事看成模型選型，而是看成路由。簡單工作走便宜路，難工作才上重裝。對 agentic workflow 來說，這不是小優化，這是你帳單會不會失控的分水嶺。\u003C\u002Fp>\u003Ch2>別再用感覺選模型，這是在燒錢\u003C\u002Fh2>\u003Cblockquote>“Claude Fable cost $9 in one coding test. GPT-5.5 cost $1.50.”\u003C\u002Fblockquote>\u003Cp>這句話的重點不是誰比較強，而是同一種工作，放到不同模型上，\u003Ca href=\"\u002Fnews\u002Fweb3-development-costs-2026-pricing-guide-zh\">成本\u003C\u002Fa>可以差到很誇張。翻譯一下就是：你如果不先分類任務，就很容易把高價推理拿去做低價雜工。那不是聰明，那是浪費。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781840895287-vp1r.png\" alt=\"模型分流把測試成本壓下來\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我看過很多團隊把 \u003Ca href=\"\u002Ftag\u002Fcode-review\">code review\u003C\u002Fa>、test generation、refactor、甚至簡單 bug 修補，全丟給同一顆高階模型。理由通常很熟：比較保險、比較省事、比較不會出事。問題是，省事常常就是貴。只要任務本質上是格式轉換、局部改寫、結構抽取，你根本不需要拿最貴的腦袋去處理。\u003C\u002Fp>\u003Cp>實操上，我會先把 AI 任務切成三桶。第一桶是低風險機械活，像 summarizing、rewrite、extract、format。第二桶是中風險工作，像寫測試、局部重構、dependency analysis。第三桶才是高風險，像架構決策、跨模組 bug 診斷、長鏈路 planning。第一桶幾乎不該碰最貴模型，第二桶用能過門檻的最便宜方案，第三桶才值得花錢。\u003C\u002Fp>\u003Cp>這個切法聽起來很直白，但真的落地時，你會發現很多「我們以為很難」的工作，其實只是流程沒拆乾淨。你把任務拆開之後，貴模型的使用率通常會掉很多，而且不會影響結果。\u003C\u002Fp>\u003Cp>我之前幫一個內部 code assistant 看過 log，最貴模型被拿去做的事情，大半是改命名、補註解、轉格式。那一刻我真的有點想翻桌。不是模型有問題，是我們把它當萬用刀，結果拿來切吐司。\u003C\u002Fp>\u003Ch2>模型分流其實就是 routing，只是換個比較不難聽的名字\u003C\u002Fh2>\u003Cp>所謂 model triage，我自己的白話版本就是：不要把昂貴 intelligence 用在便宜問題上。這概念一點都不新，我們早就在 compiler、cache、queue、background job 上做同樣的事。AI 只是把浪費放大，因為每次呼叫都會寫進帳單。\u003C\u002Fp>\u003Cp>很多 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> builder 最常犯的錯，是先選模型，再補工具。這順序很怪。比較合理的是先問「這是什麼類型的工作」，再問「哪顆模型最適合」。不然你的 agent 就會變成一台永遠走最高配路線的自動販賣機，什麼都吐最貴版本。\u003C\u002Fp>\u003Cp>實操寫法我會很土炮：在主模型呼叫前，加一個輕量 classifier。可以是規則，也可以是便宜模型，混用也行。我偏好先用規則，因為便宜、可預測、可 debug。像 request 裡有 summarize、extract、rewrite、format，就先走低階；有 bug、compare approaches、plan implementation，就往上；如果看不懂，就先問清楚，不要硬猜然後把錢燒掉。\u003C\u002Fp>\u003Cul>\u003Cli>低階模型：抽取、改寫、分類、簡單 code edit。\u003C\u002Fli>\u003Cli>中階模型：寫測試、重構、dependency tracing、工具呼叫。\u003C\u002Fli>\u003Cli>高階模型：架構、跨系統 debug、長鏈路規劃。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這樣做的好處是，你不再是憑感覺下注，而是把模型選擇變成 policy。政策一旦寫下來，就能測、能改、也能吵架。比起「我覺得這題比較難」，這種做法至少像個工程團隊。\u003C\u002Fp>\u003Cp>還有一個很實際的好處：triage 會逼你定義什麼叫 good enough。這件事很煩，但必要。很多團隊口頭上說要最強模型，其實只是還沒有成功標準，所以只好用貴來掩飾不確定。\u003C\u002Fp>\u003Ch2>便宜模型不是次等品，重點是它少不必要的戲\u003C\u002Fh2>\u003Cp>我現在看模型，不太只看它聰不聰明。我更在意它會不會亂演。因為在 coding 工作裡，最討厭的不是答案不夠華麗，而是答案看起來很像對的，結果你還得花更多時間清理。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781840893612-w6b9.png\" alt=\"模型分流把測試成本壓下來\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我遇過一種很典型的狀況：大模型寫出來的 code 很漂亮，但 review 成本高，因為它會塞很多自信但不必要的東西。小一點的模型呢，可能沒那麼會講故事，但產出比較直，反而更好讀、更好改。對日常工作來說，這常常更有用。\u003C\u002Fp>\u003Cp>也就是說，品質不是單一維度。你要一起看 correctness、review cost、latency、spend。便宜但讓你多花兩倍 review 時間，不叫便宜；貴一點但讓你少問三輪問題，那可能反而划算。只看 \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> 很容易自嗨，因為 benchmark 不會幫你付 cloud bill，也不會幫你消化工程師的注意力成本。\u003C\u002Fp>\u003Cp>我之前做 unit test generation 時就踩過這個坑。大模型寫的測試比較漂亮，但小模型寫的版本，我掃得快、改得快、丟回去重跑也快。最後我選的不是最美的答案，而是最省總成本的答案。\u003C\u002Fp>\u003Cp>實操上，我會開始記這幾個數：第一輪接受率、平均追問次數、人類修改時間、每個完成任務的總成本。只看 \u003Ca href=\"\u002Ftag\u002Finference\">inference\u003C\u002Fa> cost 太狹隘，因為真正貴的是整個流程，不是單次呼叫。\u003C\u002Fp>\u003Cul>\u003Cli>看 first-pass acceptance rate，不要只看模型有沒有回。\u003C\u002Fli>\u003Cli>看 follow-up prompts 數量，這很誠實。\u003C\u002Fli>\u003Cli>看 human edit time，因為工程師時間最貴。\u003C\u002Fli>\u003Cli>看 completed task cost，不要只看單次 token。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>當你開始這樣量，模型選擇就不再是信仰問題，而是營運問題。\u003C\u002Fp>\u003Ch2>Agent 需要預算，不只是腦袋\u003C\u002Fh2>\u003Cp>我會把這篇文章真正值得抄的地方，濃縮成一句話：如果你的 agent 能自己呼叫工具、自己繞圈思考、自己反覆嘗試，那它的成本也會跟著失控。這種系統不能只看「會不會做事」，還要看「做事會不會花太多錢」。\u003C\u002Fp>\u003Cp>我看過很多 agent 在那邊 spinning wheels，查半天、試半天、重做半天，最後答案只好一點點，但費用已經翻過去了。那不是聰明，那是有 UI 的無限帳單。你如果不設 budget，它就會自己長出 budget 破洞。\u003C\u002Fp>\u003Cp>實操寫法很直接：每個 agent 都要有 spend guardrails。不是只管安全，也要管花費。限制嘗試次數、限制 tool calls、只在低階失敗時升級、當邊際收益不值得時就停。這些規則看起來像在綁手綁腳，但其實是在保護你的產品不變成研究專案。\u003C\u002Fp>\u003Cp>我特別建議 coding agent 先走兩段式。第一段做 task classification 和 difficulty estimation，第二段才決定 model 與 tool budget。低風險就卡住預算，高影響或低信心才升級。這樣不是很炫，但很有效。\u003C\u002Fp>\u003Cp>我也喜歡把這件事做得很 boring。因為 boring 的意思通常是：帳單不會突然跳出來嚇你。這點真的很重要。\u003C\u002Fp>\u003Ch2>別讓 ego 決定你該不該升級模型\u003C\u002Fh2>\u003Cp>很多人會過度使用 premium model，不一定是技術判斷，更多時候是 ego。不是說大家愛面子，而是「用最強模型」聽起來比較安心，也比較像有在做事。問題是，你的工作不是去討好 API。你的工作是把事情做完，而且不要把錢燒得太難看。\u003C\u002Fp>\u003Cp>還有一個很常見的狀況，是團隊把模型名稱當成能力證明。好像只要貼出某個高階模型的名字，整個系統就突然高級了。其實不是。真正有料的是你能不能把任務拆對、把升級條件寫清楚、把不該升級的地方壓住。\u003C\u002Fp>\u003Cp>實操上，我會把 routing policy 寫得很短，直接放在 code 附近，不要丟到沒人看的簡報裡。規則要能被\u003Ca href=\"\u002Fnews\u002Frust-rolling-release-model-right-tradeoff-zh\">團隊真\u003C\u002Fa>的照做：什麼情況用便宜模型、什麼情況才升級、誰可以 override、override 要寫理由。這種東西如果不落地，最後就會變成大家各自用各自喜歡的模型。\u003C\u002Fp>\u003Cp>我自己比較喜歡把這叫做 model humility。不是說模型很弱，而是說很多工作其實沒必要把最貴的算力拿出來。能用小模型解決，就先用小模型；真的不行，再有意識地升級。\u003C\u002Fp>\u003Ch2>我會怎麼把這套真的做進產品\u003C\u002Fh2>\u003Cp>如果今天要我把這套 triage 做進一個產品，我不會先搞什麼巨型 router service，也不會先寫一個看起來很\u003Ca href=\"\u002Fnews\u002F2026-blockchain-shifts-business-bets-zh\">企業\u003C\u002Fa>的 policy engine。那種東西很容易變成另一個平台專案，最後大家只是在幫架構本身打工。\u003C\u002Fp>\u003Cp>我會先做三件事：一個便宜 classifier、一條清楚的 escalation path、一份完整 log。先把 80% 的價值拿到，後面再慢慢調。這樣比較像工程，不像表演。\u003C\u002Fp>\u003Cp>白話一點就是：\u003C\u002Fp>\u003Cul>\u003Cli>先分類任務。\u003C\u002Fli>\u003Cli>先用最便宜、但夠用的模型。\u003C\u002Fli>\u003Cli>失敗、模糊、高風險才升級。\u003C\u002Fli>\u003Cli>把 cost、retries、human edits 記下來。\u003C\u002Fli>\u003Cli>每週回頭修 routing 規則。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我看過夠多 AI 系統之後，越來越確定一件事：失敗通常不是「模型太小」，而是「我們根本沒問這題值不值得走昂貴路徑」。那是 routing 問題，不是 intelligence 問題。\u003C\u002Fp>\u003Cp>而且這件事很好測。你可以直接把一些任務往下路由，再把一些往上路由，比 acceptance rate、latency、spend。便宜路徑守得住就留，守不住就承認它不夠用。至少你學到東西，不是默默燒錢。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># AI coding tasks 的 model triage policy\n\n## 目標\n用最便宜、但足夠完成任務的模型。\n只有在任務模糊、風險高、或第一次失敗時才升級。\n\n## 任務分桶\n\n### Bucket 1：低成本機械活\n使用最便宜且可接受的模型。\n例子：\n- 摘要 code \u002F 文件\n- 改寫文字\n- 抽取欄位\n- 格式化 JSON \u002F markdown\n- 簡單 code edit\n\n### Bucket 2：中等複雜度工作\n先用中階模型。\n失敗再升級。\n例子：\n- 寫 unit tests\n- 小型 refactor\n- dependency tracing\n- tool-assisted lookup\n- 單一檔案或模組內的 bug isolation\n\n### Bucket 3：高複雜度或高風險工作\n直接用最強模型。\n例子：\n- 架構決策\n- 跨服務 debugging\n- 長鏈路 planning\n- security-sensitive changes\n- 需求不清楚的任務\n\n## Routing 規則\n\n1. 如果 request 明顯是機械活，走 Bucket 1。\n2. 如果需要 reasoning 但範圍有限，走 Bucket 2。\n3. 如果 request 模糊、面向使用者、或做錯代價很高，走 Bucket 3。\n4. 如果 Bucket 1 失敗兩次，升到 Bucket 2。\n5. 如果 Bucket 2 失敗兩次，或任務仍然模糊，升到 Bucket 3。\n6. 如果還是不清楚，先問 clarifying question，不要硬猜。\n\n## 成本 guardrails\n\n- 最多 2 次 retry 才能升級\n- 每個任務最多 3 次 tool calls\n- 每個 bucket 設 token budget\n- 如果下一次嘗試的改善機率很低，就停\n\n## 要記錄的 metrics\n\n- 使用哪個 model\n- 任務屬於哪個 bucket\n- retry 次數\n- tool call 次數\n- human edit time\n- first-pass acceptance rate\n- 每個完成任務的總成本\n\n## 每週 review 問題\n\n- 哪些任務其實被過度路由到昂貴模型？\n- 哪些便宜模型任務其實需要太多修補？\n- escalation 有沒有發生在對的地方？\n- 我們是不是在 routine work 上付 premium rates？\n- 哪些 routing 規則該收緊？\n\n## 簡單 implementation sketch\n\ntext\nif task.is_mechanical():\n    model = cheap_model\nelif task.is_bounded_reasoning():\n    model = mid_model\nelif task.is_ambiguous() or task.is_high_risk():\n    model = premium_model\n\nresult = run_model(model, task)\n\nif result.failed and retries \u003C 2:\n    escalate_one_level()\n\n\n## 團隊規則\n如果你 override router，請寫下理由。\n\n## 成功定義\n在不降低 first-pass usefulness、也不增加 human cleanup time 的前提下，把總成本壓下來。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板故意寫得很平，因為你真的不需要什麼華麗系統。你需要的是一套規則，能阻止 AI spend 每次都在有人說「直接上最強模型」時偷偷往上漂。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fthenewstack.io\u002Fclaude-fable-cost-model-triage\u002F\">The New Stack 這篇文章\u003C\u002Fa>。上面對 routing、分桶、guardrails 的整理是我自己的拆解與改寫，不是原文照抄。\u003C\u002Fp>","我拆一個模型分流做法：先把 coding 任務分級，再把便宜模型放前面，保住品質又少燒錢。","thenewstack.io","https:\u002F\u002Fthenewstack.io\u002Fclaude-fable-cost-model-triage\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781840895287-vp1r.png","tools","zh","95a3ce84-1732-4bce-a705-4957ca6f06af",[17,18,19,20,21],"model triage","coding assistant","cost control","agent routing","AI workflow",[23,24,25],"先把 coding 任務分級，再決定要不要上貴模型。","總成本要看 inference、重試、人工修改，不只看 token。","把 routing policy 寫短、寫在 code 附近，並每週回頭調整。",0,"2026-06-19T03:47:51.801299+00:00","2026-06-19T03:47:51.792+00:00","0c64eda0-d76f-4e13-bd85-d085ff6d151e",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"model-triage-coding-tests-cost-win-en","Model triage turns coding tests into a cost win","en",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"d2a143b9-efa1-4ffd-adcb-7a315ae6344e","renesas-acquires-altium-pcb-design-tool-update-zh","瑞萨全资收购 Altium，PCB 教程更新","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781859766720-ow6s.png","2026-06-19T09:02:23.113145+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"1e47b8fc-1eab-4342-83bd-a270d59a41f9","rust-forum-week-25-turns-ideas-into-shipping-work-zh","Rust 論壇週報把想法變交付","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781857111111-md5g.png","2026-06-19T08:18:04.893117+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"300d082a-4df5-4a26-8b5b-7dff73dd0da3","claude-code-rust-native-terminal-interface-zh","Claude Code Rust 把終端機變輕了","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781854439295-lkeg.png","2026-06-19T07:33:29.722095+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"819930d2-f83c-42e1-be18-fc65eb212184","open-source-tools-vibe-coding-cybersecurity-zh","開源工具把 vibe coding 變安全","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781852614083-gnj4.png","2026-06-19T07:03:08.602553+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"79548e00-424f-482a-81c2-4a64d29e011c","fine-tuning-llms-locally-sft-lora-dpo-zh","本地微調 LLM：SFT、LoRA、DPO","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781839069344-gzrv.png","2026-06-19T03:17:21.792772+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"fa5c39c9-8213-4432-a19d-fd67f085fdca","vercel-eve-agents-as-directories-zh","把 agents 變成目錄","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781828288993-qss6.png","2026-06-19T00:17:45.298522+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"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":85,"slug":86,"title":87,"created_at":88},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"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":95,"slug":96,"title":97,"created_at":98},"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":100,"slug":101,"title":102,"created_at":103},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"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":115,"slug":116,"title":117,"created_at":118},"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":120,"slug":121,"title":122,"created_at":123},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]