[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-fine-tuning-slms-turns-enterprise-ai-practical-zh":3,"article-related-fine-tuning-slms-turns-enterprise-ai-practical-zh":31,"series-ai-agent-09e34016-bbc0-4313-b090-2dbfdd6cf96a":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":23,"views":27,"created_at":28,"published_at":29,"topic_cluster_id":30},"09e34016-bbc0-4313-b090-2dbfdd6cf96a","fine-tuning-slms-turns-enterprise-ai-practical-zh","SLM 微調把企業 AI 變可用","\u003Cp data-speakable=\"summary\">我拆 CogitX 的 SLM 微調 playbook，整理成企業訓練、評估、部署都能直接照抄的模板。\u003C\u002Fp>\u003Cp>我看企業團隊把大模型硬塞進流程一陣子了，老實講，開局都差不多：先接一個看起來很聰明的 \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>，再堆一串 prompt，兩週後大家開始翻白眼。模型太愛講、太貴、太慢，或是明明要的是固定格式，它卻一直往泛用回答那邊飄。我也看過不少團隊想靠更多 system message、更多 guardrail、更多「再調一次」去補洞，最後只是把問題包裝得更漂亮而已。\u003C\u002Fp>\u003Cp>我後來才慢慢想通：很多企業問題不是「需要更聰明的模型」，而是「需要一個更小、但行為更準的模型」。這也是我會去看 \u003Ca href=\"https:\u002F\u002Fcogitx.ai\u002Fblog\u002Ffine-tuning-slms-for-enterprise-use-cases\">CogitX 這篇文章\u003C\u002Fa>的原因。它不是在賣情懷，講的是成本、延遲、治理、部署控制這些很無聊但很真實的事。\u003Ca href=\"\u002Ftag\u002F企業-ai\">企業 AI\u003C\u002Fa> 最常卡住的，通常也就是這些事。\u003C\u002Fp>\u003Cp>我下面拆的，不只來自 CogitX，也會順手拉幾個我認為真正有用的參考：\u003Ca href=\"https:\u002F\u002Fhuggingface.co\u002Fdocs\u002Fpeft\u002Fen\u002Findex\">Hugging Face PEFT\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\">vLLM\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2305.14314\">QLoRA\u003C\u002Fa>。這些東西放一起看，才比較像真的在做產品，不是只在做 demo。\u003C\u002Fp>\u003Ch2>企業不是為了好玩才微調\u003C\u002Fh2>\u003Cblockquote>「The motivations are operational, not ideological. Cost, latency, data governance, and deployment control are driving forces.」\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：大多數團隊不是因為想養模型才去微調，而是被現實逼的。API 帳單太兇，回應時間慢到使用者抱怨，法務說資料不能出境，或是上游供應商偷偷改了行為，結果你們的工作流整個歪掉。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781359406320-5jrq.png\" alt=\"SLM 微調把企業 AI 變可用\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己在支援自動化跟內部 copilots 上也碰過同樣的模式。第一版永遠是通用大模型加一點 prompt，demo 的時候很體面。流量一上來，邊界案例一出現，問題就爆了：同一個合約條款抓不到、同一種 ticket 分類錯、同一個欄位格式一直亂掉。這時候再談 fine-tuning，就不再是 ML 愛好者的興趣，而是系統設計的一部分。\u003C\u002Fp>\u003Cp>CogitX 把這件事講得很直白：如果任務窄、重複、又對延遲或治理敏感，那小模型加正確訓練資料，通常比硬撐大模型更合理。這不代表「全部都要微調」，而是說預設思路\u003Ca href=\"\u002Fnews\u002Fopenai-should-welcome-state-ag-scrutiny-before-ipo-zh\">應該\u003C\u002Fa>先看經濟性跟\u003Ca href=\"\u002Fnews\u002Fopen-source-ai-control-over-benchmarks-june-2026-zh\">控制權\u003C\u002Fa>，不要先拜模型大小。\u003C\u002Fp>\u003Cp>實操寫法很簡單：先把失敗模式寫清楚。到底是每次成本太高、首 \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> 太慢、輸出格式一直漂、還是資料不能離開內網？你只要把痛點說準，才知道微調是不是在解題，還是在幫團隊找事做。\u003C\u002Fp>\u003Cul>\u003Cli>任務廣、需求常變、還在探索期，就先用 API LLM。\u003C\u002Fli>\u003Cli>任務固定、重複量大、格式敏感，就考慮 SLM 微調。\u003C\u002Fli>\u003Cli>兩者都要時，就把 retrieval 跟 behavior shaping 分開處理。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>真正值得微調的，通常都是很無聊的任務\u003C\u002Fh2>\u003Cp>CogitX 提到的好案例很務實：ticket 分類、entity extraction、文件路由、結構化摘要、HR policy Q&A 這種。這就是很多團隊卡住的地方。他們想把模型訓成萬能助理，然後驚訝為什麼它沒有變成更強的通用模型。因為本來就不是這樣玩的。\u003C\u002Fp>\u003Cp>白話講，微調最強的地方不是「教它知道整個世界」，而是「教它學會一個模式」。如果你的答案大多是把輸入映射成 schema、label set、固定語氣，那訓練通常比 prompt 工程更穩。反過來，如果答案依賴即時資料、政策一直變，那微調就會很笨重。\u003C\u002Fp>\u003Cp>我在文件處理上見過這種差異很明顯。基礎模型大多看得懂字，但它還是會吐出半殘 JSON、自己發明欄位，或漏掉下游系統要求的正規化規則。你一旦用乾淨的範例去微調，模型就不太會亂演了。它變得沒那麼聰明，卻剛好是你要的樣子。\u003C\u002Fp>\u003Cp>實操寫法：先挑一批最適合被訓練的工作，條件是重複、可量化、而且 prompt 你已經調到有點煩。只要你能用 schema、label 或固定回覆格式定義成功，這種任務就比「做個 assistant」更適合拿來微調。\u003C\u002Fp>\u003Cul>\u003Cli>適合：分類、抽取、路由、模板化摘要。\u003C\u002Fli>\u003Cli>不適合：即時事實、開放式研究、快速變動政策。\u003C\u002Fli>\u003Cli>灰區：需要 retrieval 又要格式穩定的 domain copilot。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>LoRA 和 QLoRA 讓這件事終於像樣\u003C\u002Fh2>\u003Cp>CogitX 把 LoRA 跟 QLoRA 拉進來，我覺得很對。對大多數企業團隊來說，full fine-tuning 太重、也太貴。LoRA 是把 base model 凍住，只訓練低秩 adapter 權重；QLoRA 更\u003Ca href=\"\u002Fnews\u002Faspire-microsoft-agent-framework-app-graph-zh\">進一\u003C\u002Fa>步，把 base model 用 4-bit 量化載入，再用較高精度訓練 adapter。這讓 7B 級模型在比 full precision 小得多的硬體上就能微調。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781359404519-4lft.png\" alt=\"SLM 微調把企業 AI 變可用\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>也就是說，你不需要一整座 GPU 農場才有辦法從微調拿到價值。你需要的是一條正常的訓練管線、夠代表性的資料，以及一個本來就已經接近任務的模型。這也是為什麼 \u003Ca href=\"https:\u002F\u002Fhuggingface.co\u002Fdocs\u002Fpeft\u002Fen\u002Findex\">PEFT\u003C\u002Fa> 這類工具很重要，它把 adapter-based training 變成預設路線，而不是要 infra 團隊陪研究部門玩的一次性專案。\u003C\u002Fp>\u003Cp>我以前待過一些團隊，微調討論一開始就死掉，原因很單純：大家以為 fine-tuning 就是燒 cluster 預算。那是舊觀念了。現在這類方法的瓶頸通常不是算力，而是 dataset 乾不乾淨，能不能真的教出你要的行為。\u003C\u002Fp>\u003Cp>實操寫法：如果你是從零開始，先用 PEFT 做 LoRA。只有在你有很明確的理由時，才往更複雜的方法走。若你在意 serving throughput，再看像 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\">vLLM\u003C\u002Fa> 這種 adapter-aware runtime，或參考 \u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2308.06825\">S-LoRA\u003C\u002Fa> 這類多 adapter 方案。\u003C\u002Fp>\u003Ch2>Instruction tuning 才是在學你公司的說話方式\u003C\u002Fh2>\u003Cp>CogitX 對 instruction-response pairs 的重視，我完全同意。很多團隊太愛先看 rank、batch size、learning rate，卻沒先檢查 examples 一不一致。這順序根本反了。\u003C\u002Fp>\u003Cp>instruction tuning 的意思很單純：你拿真實工作長相的指令和答案去訓練。不是原始文本，不是亂剪的片段，而是實際會發生的請求與你想要的輸出。如果客服要的是禮貌、簡潔、還要帶升級邏輯，那就訓練那種回答；如果法務流程需要的是固定 JSON，那就訓練那個 JSON。\u003C\u002Fp>\u003Cp>翻白話一點，模型學的其實是你公司的習慣：語氣、格式、拒答方式、什麼時候該停嘴，這些都能訓練。這也是為什麼 instruction tuning 很適合企業場景。企業不太在乎創意爆發，企業在乎的是每次都一樣、不要亂來。\u003C\u002Fp>\u003Cp>我自己碰過 procurement assistant 一直愛寫長篇大論，但下游系統只吃結構化欄位。prompt 當然可以救一下，但只救一天。最後還是靠微調，因為模型看夠了正確輸出長什麼樣，才會停止自由發揮。\u003C\u002Fp>\u003Cp>實操寫法：用真實工作流長出訓練例子，不要只拿 synthetic toy prompt。每一筆 sample 都只回答一件事：人類問這個問題時，模型應該怎麼做？如果你自己都寫不出理想答案，代表你還沒準備好訓練目標。\u003C\u002Fp>\u003Ch2>資料品質才是全部，synthetic data 只能當配菜\u003C\u002Fh2>\u003Cp>CogitX 花很多篇幅講資料準備，我也覺得這才是應該花時間的地方。他們提到 internal documents、conversation logs、synthetic data 當主要來源，這方向沒問題。但重點不是「資料越多越好」，而是「資料要乾淨、一致、夠代表性」。\u003C\u002Fp>\u003Cp>簡單講，小而乾淨的資料集，常常會贏過大而髒的資料集。去重很重要，schema 正規化很重要，PII 移除很重要，還有每個例子的 instruction style 要一致。如果 label 很模糊，模型就學會模糊；如果輸出常常不一樣，模型就會變得不穩定。\u003C\u002Fp>\u003Cp>synthetic data 這點可以留著用，但要用對。CogitX 提到 Scale AI 的 NeurIPS 2024 研究方向，我看法也差不多：synthetic data 有用的前提，是它要建立在真實來源上，再用合理策略擴增。你如果只是叫模型憑空亂造，然後把那堆東西當訓練資料，最後通常只是把錯誤放大。\u003C\u002Fp>\u003Cp>實操寫法：synthetic generation 用來補 coverage，不要拿來取代 domain truth。先從真實工作流抽一小包 gold set，再圍繞它生成變體。進訓練前，先用 schema 跟 domain rules 驗過一次。\u003C\u002Fp>\u003Cul>\u003Cli>來源優先順序：內部文件、人工標註輸出、對話紀錄。\u003C\u002Fli>\u003Cli>訓練前先做欄位統一、格式正規化、去重。\u003C\u002Fli>\u003Cli>gold evaluation set 要跟 training data 分開鎖住。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>RAG 和微調不是互斥，是分工\u003C\u002Fh2>\u003Cp>CogitX 這段我很認同，因為這大概是企業架構最常被講歪的地方。大家老愛把 retrieval-augmented generation 跟 fine-tuning 當成兩派在吵架，好像只能選一邊。其實它們解的是不同問題。\u003C\u002Fp>\u003Cp>如果知識變很快、需要引用來源、或不同使用者能看的資料不一樣，那 \u003Ca href=\"\u002Ftag\u002Frag\">RAG\u003C\u002Fa> 比較對。若是行為本身要變：格式、語氣、路由邏輯、拒答風格、領域模式辨識，那微調比較對。你如果想用微調去做即時知識查詢，那是在用錯工具；你如果想靠 RAG 教模型怎麼做人，那也是錯的。\u003C\u002Fp>\u003Cp>白話講，最實際的企業系統通常是兩個一起上。RAG 提供新鮮事實和可追溯性，微調負責讓模型在拿到 context 之後，照你要的方式回話。這比硬逼單一機制扛全部，合理太多。\u003C\u002Fp>\u003Cp>我看過 compliance workflow 這樣做得很好：retrieval layer 拉最新 policy，fine-tuned model 負責把答案整理成法務要的格式。這樣拆比起只靠一串 prompt 祈禱模型聽話，清楚很多。\u003C\u002Fp>\u003Cp>實操寫法：先問兩題。第一，這個任務需不需要新鮮知識？需要就上 retrieval。第二，這個任務需不需要穩定行為？需要就微調。如果兩題都要，直接組合，不要假裝只能二選一。\u003C\u002Fp>\u003Ch2>部署才是把理論打回現實的地方\u003C\u002Fh2>\u003Cp>CogitX 提到 on-prem serving、quantization、\u003Ca href=\"\u002Ftag\u002Finference\">inference\u003C\u002Fa> tooling，這些才是實戰裡真正會咬人的地方。訓練只是前半段；如果模型慢、難更新、也無法監控，專案還是會死。\u003C\u002Fp>\u003Cp>也就是說，部署限制應該從第一天就反推模型選擇。用 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\">vLLM\u003C\u002Fa> 在單張 GPU 上服務一個 7B 模型，跟用大型 hosted API，營運故事完全不同。前者讓你有更多控制、更低延遲、更好的資料駐留；後者省事，但你要自己承擔 uptime、patching、adapter versioning 和 rollback。\u003C\u002Fp>\u003Cp>我看過團隊低估這一段，然後很快後悔。他們訓練出一個還不錯的 adapter，上線後才發現沒人定義怎麼先用 production inputs 驗證，再切版本。這種時候，模型改進就會直接變成支援事故。\u003C\u002Fp>\u003Cp>實操寫法：把 model release 當 software release 管。base model、adapter、dataset、evaluation set 都要版本化。rollback 路徑先放好。production 裡要量 latency、throughput、failure rate，不要只看 offline accuracy。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode>## 企業 SLM 微調 playbook\n\n### 1) 先挑對任務\n只在以下情況考慮微調：\n- 重複性高\n- 範圍明確\n- 可量化\n- 對格式、語氣、路由敏感\n\n不要微調來做：\n- 即時事實查詢\n- 開放式研究\n- 快速變動政策\n- 廣義助理\n\n### 2) 定義你要的行為\n用一句話寫清楚：\n- 輸入類型\n- 輸出 schema\n- 語氣\n- 拒答規則\n- 升級規則\n\n例：\n「收到客服單後，分類問題、抽取實體，並回傳符合 JSON 格式的五類標籤之一。」\n\n### 3) 建資料集\n來源：\n- 內部文件\n- 人工標註的工作輸出\n- 對話紀錄\n- 以真實例子為基礎的 synthetic variants\n\n資料規則：\n- 移除 PII\n- 語意去重\n- 格式正規化\n- 保留獨立的 gold eval set\n- 拒絕模糊標籤\n\n### 4) 用 instruction tuning 格式\n用 instruction-response pairs 訓練。\n\n例：\n{\n  \"instruction\": \"抽出合約雙方與生效日期。\",\n  \"context\": \"This Agreement is entered into as of January 1, 2025...\",\n  \"response\": \"{\\\"parties\\\":[\\\"Acme Corp\\\",\\\"Vertex Ltd\\\"],\\\"effective_date\\\":\\\"2025-01-01\\\"}\"\n}\n\n### 5) 先從 LoRA 或 QLoRA 開始\n預設建議：\n- base model：7B 到 8B 的開源模型\n- fine-tuning 方法：LoRA\n- GPU 記憶體吃緊：QLoRA\n- serving：vLLM 或相容的 adapter-aware runtime\n\n### 6) 上線前先評估\n同時看兩種：\n- 任務指標：exact match、F1、schema validity、routing accuracy\n- 人工審查：邊界案例、語氣、拒答行為\n\n沒有 held-out eval set，不要上線。\n\n### 7) 判斷 RAG 要不要留著\n適合用 RAG 的情況：\n- 事實常變\n- 需要引用來源\n- 不同使用者權限不同\n\n適合用微調的情況：\n- 行為要穩定\n- 輸出格式要精準\n- 延遲很重要\n\n兩者都需要時，就一起用。\n\n### 8) 像軟體一樣部署\n追蹤：\n- base model version\n- adapter version\n- dataset version\n- eval set version\n- latency\n- throughput\n- rollback path\n\n### 9) 上線檢查清單\n- [ ] schema validation 通過\n- [ ] PII 已移除\n- [ ] eval set 已鎖定\n- [ ] rollback 已測試\n- [ ] 壓力下 latency 已量測\n- [ ] 邊界案例有人審\n- [ ] monitoring alerts 已定義\n\n### 10) 簡單決策規則\n任務窄而重複，就微調。\n任務需要新鮮事實，就加 RAG。\n兩者都要，就組合。\n任務廣又不穩，就不要硬上微調。\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這就是我會直接丟給團隊的版本。它不花俏，但它會逼大家先問對問題，這通常就是最缺的那一步。\u003C\u002Fp>\u003Cp>原始來源是 \u003Ca href=\"https:\u002F\u002Fcogitx.ai\u002Fblog\u002Ffine-tuning-slms-for-enterprise-use-cases\">https:\u002F\u002Fcogitx.ai\u002Fblog\u002Ffine-tuning-slms-for-enterprise-use-cases\u003C\u002Fa>。我這篇是衍生拆解，核心框架來自原文，模板跟實戰整理是我自己為開發者重組過的版本。\u003C\u002Fp>\u003Cp>另外我參考了 \u003Ca href=\"https:\u002F\u002Fhuggingface.co\u002Fdocs\u002Fpeft\u002Fen\u002Findex\">Hugging Face PEFT\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\">vLLM\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2305.14314\">QLoRA\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2308.06825\">S-LoRA\u003C\u002Fa> 這幾個公開資源，方便你真的把這套流程接進工作裡。\u003C\u002Fp>","拆 CogitX 的 SLM 微調 playbook，整理成企業訓練、評估、部署都能直接照抄的模板。","cogitx.ai","https:\u002F\u002Fcogitx.ai\u002Fblog\u002Ffine-tuning-slms-for-enterprise-use-cases",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781359406320-5jrq.png","ai-agent","zh","00cabbf4-05e7-440c-be15-b8f441a1506f",[17,18,19,20,21,22],"SLM","fine-tuning","LoRA","QLoRA","RAG","enterprise AI",[24,25,26],"企業微調的核心不是炫技，而是成本、延遲、治理與部署控制。","最適合微調的是重複、可量化、格式敏感的窄任務，不是通用助理。","LoRA\u002FQLoRA、RAG、vLLM 搭配版本化評估，才是能落地的企業流程。",2,"2026-06-13T14:02:55.242488+00:00","2026-06-13T14:02:55.228+00:00","e3b68196-9e64-4c18-a3b6-a73e73bfb367",{"tags":32,"relatedLang":42,"relatedPosts":46},[33,35,37,39,40],{"name":20,"slug":34},"qlora",{"name":19,"slug":36},"lora",{"name":21,"slug":38},"rag",{"name":18,"slug":18},{"name":17,"slug":41},"slm",{"id":15,"slug":43,"title":44,"language":45},"fine-tuning-slms-turns-enterprise-ai-practical-en","Fine-Tuning SLMs Turns Enterprise AI Practical","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"06a33326-5420-4e1d-99ff-233939652a44","aspire-microsoft-agent-framework-app-graph-zh","Aspire 把 Agent 圖譜收進一個 AppHost","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781353076983-n0ho.png","2026-06-13T12:17:30.314245+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"40cd5d8d-c9fc-4883-b978-f7f757c14488","fable-5-claude-code-like-coworker-zh","Fable 5 讓 Claude Code 更像真同事","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324309029-2n7r.png","2026-06-13T04:18:00.6602+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"5bff363a-295a-47d3-911b-411f5f45e2bb","fine-tuning-methods-sft-lora-dpo-rlhf-grpo-zh","SFT、LoRA、DPO、RLHF、GRPO 選型指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781262197359-7rgb.png","2026-06-12T11:02:33.190744+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"9a720eb3-d88e-4ee9-bb59-7e02f0359fc7","mistral-vibe-cli-agent-still-matters-zh","Mistral Vibe 證明 CLI 代理仍然重要","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781248675431-k8cj.png","2026-06-12T07:17:21.512085+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"3f5cef32-c57b-4355-80f5-09af8a117d96","kimi-code-cli-setup-pricing-workflow-guide-zh","Kimi Code CLI 安裝、定價與工作流","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781161398225-58ea.png","2026-06-11T07:02:27.830955+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"fda45923-6a5e-4f58-b8ac-e28e30fdae66","windows-agent-runtime-not-human-desktop-zh","Windows 正在變成 agent runtime，而不是人類桌面","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781147870390-3anp.png","2026-06-11T03:17:17.184885+00:00",[84,89,94,99,104,109,114,119,124,129],{"id":85,"slug":86,"title":87,"created_at":88},"4ae1e197-1d3d-4233-8733-eafe9cb6438b","claude-now-uses-your-pc-to-finish-tasks-zh","Claude 開始幫你操作電腦","2026-03-26T07:20:48.457387+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"5bede67f-e21c-413d-9ab8-54a3c3d26227","googles-2026-ai-agent-report-decoded-zh","Google 2026 AI Agent 報告解讀","2026-03-26T11:15:22.651956+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"2987d097-563f-46c7-b76f-b558d8ef7c2b","kimi-k25-review-stronger-still-not-legend-zh","Kimi K2.5 評測：更強，但還不是神作","2026-03-27T07:15:55.277513+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"95c9053b-e3f4-4cb5-aace-5c54f4c9e044","claude-code-controls-mac-desktop-zh","Claude Code 也能操控 Mac 了","2026-03-28T03:01:58.58121+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"dc58e153-e3a8-4c06-9b96-1aa64eabbf5f","cloudflare-100x-faster-ai-agent-sandbox-zh","Cloudflare 的 AI 沙箱跑超快","2026-03-28T03:09:44.142236+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"1c8afc56-253f-47a2-979f-1065ff072f2a","openai-backs-isara-agent-swarm-bet-zh","OpenAI 挺 Isara 的 agent swarm …","2026-03-28T03:15:27.513155+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"7379b422-576e-45df-ad5a-d57a0d9dd467","openai-plan-automated-ai-researcher-zh","OpenAI 想做自動化 AI 研究員","2026-03-28T03:17:42.090548+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"48c9889e-86df-450b-a356-e4a4b7c83c5b","harness-engineering-ai-agent-reliability-2026-zh","駕馭工程：從「馬具」到「作業系統」，AI Agent 可靠性的終極密碼","2026-03-31T06:42:53.556721+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"96d8e8c8-1edd-475d-9145-b1e7a1b02b65","mcp-explained-from-prompts-to-production-zh","MCP 怎麼把提示詞變工作流","2026-04-01T09:24:39.321274+00:00",{"id":130,"slug":131,"title":132,"created_at":133},"f2ca7720-b471-4ce5-9336-2a9ac2a876fd","amazon-bedrock-agents-multi-agent-workflows-zh","Amazon Bedrock Agents 進入多代理工作流","2026-04-01T09:30:29.945429+00:00"]