[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-sim-visual-agent-workflow-canvas-zh":3,"article-related-sim-visual-agent-workflow-canvas-zh":31,"series-tools-aa78f0bb-2826-4d1e-a7ab-a6f5bb15a873":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},"aa78f0bb-2826-4d1e-a7ab-a6f5bb15a873","sim-visual-agent-workflow-canvas-zh","Sim 把 agent 流程變成畫布","\u003Cp data-speakable=\"summary\">我拆 Sim 的畫布式 \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> 編排，順手整理成可直接套用的工作流模板、自架與向量搜尋做法。\u003C\u002Fp>\u003Cp>我玩 agent workflow 一陣子了，最煩的不是模型不會答，是工具一多就開始亂。今天接 prompt，明天補 YAML，後天加 queue、vector store、重試，最後整套東西像在跟我鬧脾氣。Demo 看起來很順，真的要上線時，流程一複雜就露餡。我最近盯上 Sim，https:\u002F\u002F\u003Ca href=\"\u002Ftag\u002Fgithub\">github\u003C\u002Fa>.com\u002Fsimstudioai\u002Fsim，因為它至少沒假裝這些麻煩不存在。\u003C\u002Fp>\u003Cp>它的路數很直白：把 agent orchestration 做成 visual canvas，讓你能設計、執行、自己架、自己擴。這種產品我通常半信半疑，因為很多工具都只是在換皮，複雜度沒少，只是換個地方藏。Sim 比較像是把流程攤開來給你看，這點我反而比較能接受。\u003C\u002Fp>\u003Cp>我會想拆它，不是因為它多神，而是它踩中了我一直在意的那條線：workflow editor、runtime、self-host、vector search、tools，全都要能接起來，不然就是半套。這篇我就直接拆它的玩法，順手整理成你可以抄的版本。\u003C\u002Fp>\u003Cp>觸發我仔細看的是 Sim 的 GitHub repo，還有它自己講的產品定位。README 明講它是 build、deploy、orchestrate \u003Ca href=\"\u002Ftag\u002Fai-agents\">AI agents\u003C\u002Fa> 的平台，而且有 visual canvas 跟 self-host 路線。這不是空話，我看的是 repo 結構跟安裝路徑，不是只看首頁文案。原始來源在這裡：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsimstudioai\u002Fsim\" target=\"_blank\" rel=\"noreferrer\">https:\u002F\u002Fgithub.com\u002Fsimstudioai\u002Fsim\u003C\u002Fa>。\u003C\u002Fp>\u003Ch2>我先看它有沒有把「畫布」當裝飾品\u003C\u002Fh2>\u003Cblockquote>“Design agent workflows visually on a canvas—connect agents, tools, and blocks, then run them instantly.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：先把流程畫出來，再直接跑。這句話聽起來很像低碼平台的老梗，但我覺得重點不是畫，而是「畫完就能跑」。很多工具都卡在中間那段，設計和執行是兩套系統，最後你還是得自己補 glue code，照樣痛。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779201890676-1xsq.png\" alt=\"Sim 把 agent 流程變成畫布\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前做過一個客服分流 agent，需求很簡單：先判斷問題類型，再去抓知識庫，最後決定要不要轉人工。結果實作時，流程拆在三個檔案、兩個 handler、外加一堆臨時 flag。每次改一個\u003Ca href=\"\u002Fnews\u002Fkubernetes-1-36-1-patch-releases-zh\">分支\u003C\u002Fa>，我都要回頭找是哪個 callback 在偷改狀態。那種時候我最想要的不是更強的模型，是一張能一眼看懂的流程圖。\u003C\u002Fp>\u003Cp>Sim 的 canvas 如果只是美觀 UI，我不會多看一眼。但它把 agent、tool、block 都攤在同一個視覺層，這就有價值了。因為 agent 系統最麻煩的地方不是推理，而是你根本看不出哪一步把資料弄壞了。畫布至少讓你先把責任切清楚。\u003C\u002Fp>\u003Cp>實操寫法很簡單：每個 node 只做一件事，輸入和輸出都要能說人話。不要一個 agent 包五個任務，然後怪模型不穩。你要的是可讀性，不是把複雜度塞進黑盒。\u003C\u002Fp>\u003Cul>\u003Cli>一個 node 對應一個責任，不要混雜。\u003C\u002Fli>\u003Cli>工具要窄，別做萬用工具。\u003C\u002Fli>\u003Cli>先畫 failure path，再畫 happy path。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你本來就有在看 \u003Ca href=\"https:\u002F\u002Fwww.langchain.com\u002F\" target=\"_blank\" rel=\"noreferrer\">LangChain\u003C\u002Fa> 或 \u003Ca href=\"https:\u002F\u002Fmastra.ai\u002F\" target=\"_blank\" rel=\"noreferrer\">Mastra\u003C\u002Fa>，Sim 比較像是把你腦中那張流程圖直接做成產品，而不是只給你一堆 runtime API 叫你自己想像。\u003C\u002Fp>\u003Ch2>它不是 editor 而已，是 editor 綁 runtime\u003C\u002Fh2>\u003Cblockquote>“Build Workflows with Ease”\u003C\u002Fblockquote>\u003Cp>這句很像行銷話，但我看它的重點不是「容易」，而是「設計完能立刻跑」。很多平台都能讓你拖拉幾個節點，問題是拖完之後要怎麼執行、怎麼測、怎麼改，答案通常很破碎。你最後還是要跳出去寫另外一套執行層。\u003C\u002Fp>\u003Cp>我比較在意的是 design 和 execution 的距離有沒有被縮短。因為 agent workflow 一旦拆成兩個世界，debug 就會\u003Ca href=\"\u002Fnews\u002Fdbt-sl-turns-semantic-layer-setup-into-a-loop-zh\">變成\u003C\u002Fa>災難。你在畫布上看到的是 A，runtime 跑出來的是 B，然後大家開始互相懷疑。這種事我看太多了。\u003C\u002Fp>\u003Cp>Sim 的價值在於，它讓你在同一個介面裡做建模、測試、執行。這對我來說不是便利，是少掉翻譯成本。少一次翻譯，就少一次出錯。尤其是當工具輸出格式變了、模型回傳半成品、或者某個分支只在真實資料下炸掉時，你會很感謝這種緊密耦合。\u003C\u002Fp>\u003Cp>實操上，我會這樣用：先做最小流程，只放一個 input、一個 agent、一個 tool、一個 output。先別急著加分支，先確認主幹穩。很多人一開始就想做完整 orchestrator，結果連最基本的 schema 都沒驗證。\u003C\u002Fp>\u003Cul>\u003Cli>先跑最小閉環，再加分支。\u003C\u002Fli>\u003Cli>用真實髒資料測，不要只拿乾淨範例。\u003C\u002Fli>\u003Cli>每次改節點，都回頭看執行紀錄。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>它的 editor 用的是 \u003Ca href=\"https:\u002F\u002Freactflow.dev\u002F\" target=\"_blank\" rel=\"noreferrer\">React Flow\u003C\u002Fa>，這選得很務實。React Flow 的好處就是 node graph 不會變成裝飾品，是真的能拿來編排流程。\u003C\u002Fp>\u003Ch2>Copilot 在這裡不是噱頭，是省你點來點去\u003C\u002Fh2>\u003Cblockquote>“Supercharge with Copilot — Leverage Copilot to generate nodes, fix errors, and iterate on flows directly from natural language.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你可以直接叫 \u003Ca href=\"\u002Ftag\u002Fcopilot\">Copilot\u003C\u002Fa> 幫你生節點、修錯、改流程。這比那種「問答型 AI 助手」有用多了，因為它是插進 workflow authoring 的中間層，不是掛在旁邊聊天。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779201885855-q9yu.png\" alt=\"Sim 把 agent 流程變成畫布\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我對這種東西一直是半信半疑。原因很簡單，AI 很會把東西生得像真的。節點名稱看起來對，連線看起來也順，但細看就會發現它偷偷編了欄位、漏了例外、或是把一個應該失敗的情況硬寫成成功。這種假順手，我吃過太多次虧。\u003C\u002Fp>\u003Cp>所以我會把 Copilot 定位成「草稿機」，不是「驗證機」。它適合幫我把流程先搭出來，減少點選成本；但最後的 schema、權限、錯誤處理，還是得我自己看。尤其 agent workflow 這種東西，一個錯誤的 edge 就可能讓整個流程走歪。\u003C\u002Fp>\u003Cp>實操寫法：叫它先生骨架，再人工補血。你可以讓它幫你把節點類型、連線順序、基本說明先列出來，但不要直接把生成結果當成可上線版本。任何自然語言產物，都要過一輪人工檢查。\u003C\u002Fp>\u003Cul>\u003Cli>用 Copilot 產生骨架，不要直接產生最終版。\u003C\u002Fli>\u003Cli>每個 node 的輸入、輸出、權限都要人工確認。\u003C\u002Fli>\u003Cli>把錯誤處理當成必填，不要等出事才補。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你想對照更熟悉的生態，可以看 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffeatures\u002Fcopilot\" target=\"_blank\" rel=\"noreferrer\">GitHub Copilot\u003C\u002Fa> 跟 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffeatures\u002Fmodels\" target=\"_blank\" rel=\"noreferrer\">GitHub Models\u003C\u002Fa>。Sim 的做法比較像把這類能力直接塞進流程編排裡，而不是讓你自己切頁面。\u003C\u002Fp>\u003Ch2>它把 vector search 當流程的一部分，不是外掛\u003C\u002Fh2>\u003Cblockquote>“Integrate Vector Databases — Upload documents to a vector store and let agents answer questions grounded in your specific content.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：文件上傳進向量庫，agent 回答時直接用你的內容當依據。這件事我很在意，因為太多 RAG 系統都死在一個地方：大家都在講 embedding，卻沒人處理資料清理、更新、切 chunk、查詢品質。\u003C\u002Fp>\u003Cp>我以前做內部知識庫問答時，最煩的不是模型不夠聰明，是 retrieval 一直亂撈。文件版本沒控好、索引沒更新、查回來的段落跟問題根本不對焦，最後使用者只會說「這 AI 很會講廢話」。所以我現在看任何 agent 平台，第一個問題都是：它怎麼把 retrieval 接進整個 workflow？\u003C\u002Fp>\u003Cp>Sim 讓我比較舒服的地方，是它不是把 vector search 當成額外功能，而是當成 agent flow 的一段。這很\u003Ca href=\"\u002Fnews\u002Fwhy-mp2-still-matters-broadcast-audio-zh\">重要\u003C\u002Fa>。因為 knowledge retrieval 不是獨立服務，它本來就應該跟工具調用、模型推理、輸出校驗放在同一條路上看。\u003C\u002Fp>\u003Cp>實操寫法：把 ingestion 跟 query 分開。不要把文件匯入、索引更新、回答查詢混在同一個流程裡，不然你會很難 debug。再來，測試時不要只問正確答案，要故意問模糊、矛盾、過期的問題，看看 agent 會不會亂編。\u003C\u002Fp>\u003Cul>\u003Cli>只索引真的會用到的內容。\u003C\u002Fli>\u003Cli>ingestion 和 query 分開做。\u003C\u002Fli>\u003Cli>用 adversarial 問題測 retrieval。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>它提到的後端選項包含 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\" target=\"_blank\" rel=\"noreferrer\">pgvector\u003C\u002Fa>，這種選擇我反而比較信。夠普通，才比較容易維護。\u003C\u002Fp>\u003Ch2>自架不是加分項，是它能不能進公司內網的門票\u003C\u002Fh2>\u003Cblockquote>“Cloud-hosted: sim.ai” and “Self-hosted: Docker Compose”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你可以用雲端版，也可以自己架。這件事看起來平凡，但對台灣很多團隊來說超現實。因為一旦牽涉到內部文件、客戶資料、權限控管，很多 SaaS 直接就被打槍。你沒有 self-host，連 PoC 都很難推進。\u003C\u002Fp>\u003Cp>我看 Sim 的安裝路徑時，會注意它是不是只會講漂亮話。結果它把 NPM、\u003Ca href=\"\u002Ftag\u002Fdocker\">Docker\u003C\u002Fa> Compose、手動安裝都列出來了，還明講需要 Bun、Node.js 20+、PostgreSQL 12+ 和 pgvector。這種寫法很實際，因為它承認世界上真的有人要自己管環境。\u003C\u002Fp>\u003Cp>更重要的是，這代表它不是那種只給你一個雲端控制台的殼。你可以看到它有 Next.js、socket server、database migrations、background jobs 這些東西。這些不是裝飾，是你之後要維運的現實。\u003C\u002Fp>\u003Cp>實操上，我會這樣落地：先用 hosted 版驗證流程，再切 self-hosted。這樣可以先知道產品有沒有用，再決定值不值得把它放進自己的 infra。別一開始就把整套系統綁死，結果 demo 完才發現權限、資料流、網路政策全部卡住。\u003C\u002Fp>\u003Cul>\u003Cli>先用 hosted 跑 PoC，再決定要不要自架。\u003C\u002Fli>\u003Cli>把 staging 跟 production 分開。\u003C\u002Fli>\u003Cli>先寫好 secrets 管理規則，再讓別人碰流程。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>它的技術棧也很直白：\u003Ca href=\"https:\u002F\u002Fnextjs.org\u002F\" target=\"_blank\" rel=\"noreferrer\">Next.js\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fbun.sh\u002F\" target=\"_blank\" rel=\"noreferrer\">Bun\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002F\" target=\"_blank\" rel=\"noreferrer\">PostgreSQL\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fsocket.io\u002F\" target=\"_blank\" rel=\"noreferrer\">Socket.IO\u003C\u002Fa>。我喜歡這種沒有刻意炫技的組合。\u003C\u002Fp>\u003Ch2>這 repo 看起來像平台，不像週末 demo\u003C\u002Fh2>\u003Cblockquote>“The open-source platform to build AI agents and run your agentic workforce.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：它想當平台，不只是 library。這差很多。Library 是拿來拼的，platform 是拿來長期用的。你如果要做的是一套會被團隊反覆修改、反覆跑、反覆接工具的 agent 系統，那你要看的就不是「它能不能 demo」，而是「它能不能活下來」。\u003C\u002Fp>\u003Cp>我會看 repo 的結構、文件、背景工作、執行邊界，因為這些東西比首頁文案誠實。Sim 的 repo 有 monorepo 味道，也有 async jobs、remote execution、schema 驗證這些痕跡。這表示它不是只想把 prompt 包成 UI，而是真的在處理 agent 會遇到的髒活。\u003C\u002Fp>\u003Cp>我也注意到它用了 \u003Ca href=\"https:\u002F\u002Ftrigger.dev\u002F\" target=\"_blank\" rel=\"noreferrer\">Trigger.dev\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fe2b.dev\u002F\" target=\"_blank\" rel=\"noreferrer\">E2B\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Flaverdet\u002Fisolated-vm\" target=\"_blank\" rel=\"noreferrer\">isolated-vm\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fzod.dev\u002F\" target=\"_blank\" rel=\"noreferrer\">Zod\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Form.drizzle.team\u002F\" target=\"_blank\" rel=\"noreferrer\">Drizzle\u003C\u002Fa>。這組合很像在告訴我：它知道 agent 不是只會聊天，還會跑任務、碰資料、執行程式碼，所以邊界要先畫好。\u003C\u002Fp>\u003Cp>實操寫法很直接：你要先問自己，現在缺的是畫布、runtime、還是執行平台。不要因為看到 visual canvas 就誤以為整套問題都解了。如果你的痛點是權限、排程、重試、審計，那你要找的是平台級設計，不是漂亮 editor。\u003C\u002Fp>\u003Cul>\u003Cli>先判斷你需要 library 還是 platform。\u003C\u002Fli>\u003Cli>看 repo 有沒有 tests、migrations、docs、deploy path。\u003C\u002Fli>\u003Cli>凡是會 async 跑任務的系統，都要先想失敗怎麼收。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Agent Workflow Blueprint for a Sim-like Canvas\n\n## 1. Goal\n- Problem:\n- User:\n- Success criteria:\n\n## 2. Inputs\n- User request:\n- System context:\n- Retrieved documents:\n- Required secrets:\n\n## 3. Nodes\n\n### Intake\n- Type: input\n- Purpose: normalize request\n- Output schema:\n\n### Router\n- Type: agent\n- Purpose: choose path\n- Output schema:\n\n### Retrieval\n- Type: vector search\n- Purpose: ground answer in internal content\n- Output schema:\n\n### Tool Call\n- Type: tool\n- Purpose: call external API or internal service\n- Output schema:\n\n### Synthesis\n- Type: agent\n- Purpose: combine context and tool results\n- Output schema:\n\n### Validation\n- Type: guardrail\n- Purpose: check schema, policy, and safety\n- Output schema:\n\n### Delivery\n- Type: output\n- Purpose: send final result\n- Output schema:\n\n## 4. Connections\n- Intake -> Router\n- Router -> Retrieval\n- Router -> Tool Call\n- Retrieval -> Synthesis\n- Tool Call -> Synthesis\n- Synthesis -> Validation\n- Validation -> Delivery\n\n## 5. Rules\n- Every node has one job only.\n- Every external call is retryable.\n- Every retrieval step is testable with known docs.\n- Every agent decision is logged.\n- Every workflow has a failure path.\n\n## 6. Self-host checklist\n- [ ] PostgreSQL ready\n- [ ] Vector support enabled\n- [ ] Migrations applied\n- [ ] Secrets stored outside repo\n- [ ] Background jobs configured\n- [ ] Realtime server reachable\n- [ ] Workflow editor accessible\n\n## 7. Testing checklist\n- [ ] Happy path passes\n- [ ] Empty input fails cleanly\n- [ ] Tool timeout handled\n- [ ] Retrieval returns no results handled\n- [ ] Malformed model output rejected\n- [ ] Retry path works\n- [ ] Logs show node-by-node execution\n\n## 8. Minimal orchestrator prompt\nYou are the workflow orchestrator.\n\nYour job:\n1. Inspect the request.\n2. Select the correct path.\n3. Retrieve only the needed context.\n4. Call tools only when necessary.\n5. Produce a structured final result.\n6. Fail clearly when a step cannot continue.\n\nReturn:\n- route\n- reasoning summary\n- required actions\n- final output schema\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段我刻意寫成你可以直接拿去改的版本，因為我覺得這才是拆方法論該有的樣子。不是只講概念，而是讓你馬上能落到自己的 workflow、自己的工具、自己的部署規則。\u003C\u002Fp>\u003Cp>我如果明天要開一個新的 agent 專案，我會先拿這份骨架，然後把工具、retrieval、validation、self-host 規則一個個填進去。不要一開始就追求花俏，先把資料流、錯誤流、執行流講清楚，才不會又做出一套看起來很猛、實際上很脆的東西。\u003C\u002Fp>\u003Cp>來源致謝：上面的拆解主要來自 Sim GitHub repo \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsimstudioai\u002Fsim\" target=\"_blank\" rel=\"noreferrer\">https:\u002F\u002Fgithub.com\u002Fsimstudioai\u002Fsim\u003C\u002Fa>，以及我對 README、安裝說明和 repo 結構的整理。模板段落是我根據原始資料重寫的衍生版本，不是直接複製原文。\u003C\u002Fp>","我拆 Sim 的畫布式 agent 編排，順手整理成可直接套用的工作流模板、自架與向量搜尋做法。","github.com","https:\u002F\u002Fgithub.com\u002Fsimstudioai\u002Fsim",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779201890676-1xsq.png","tools","zh","e0ec5f99-c3c7-4032-8351-b640927f2601",[17,18,19,20,21,22],"agent workflow","visual canvas","self-host","vector search","RAG","orchestration",[24,25,26],"Sim 的重點不是低碼，而是把 agent 流程、runtime 和 self-host 放在同一個框架裡。","它最值得抄的地方，是把 retrieval、tools、validation 都當成 workflow 的一部分。","如果你要做可維護的 agent 系統，先把流程圖、失敗路徑和部署規則寫清楚。",3,"2026-05-19T14:44:16.281068+00:00","2026-05-19T14:44:16.246+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":32,"relatedLang":42,"relatedPosts":46},[33,35,37,39,41],{"name":21,"slug":34},"rag",{"name":20,"slug":36},"vector-search",{"name":17,"slug":38},"agent-workflow",{"name":18,"slug":40},"visual-canvas",{"name":19,"slug":19},{"id":15,"slug":43,"title":44,"language":45},"sim-visual-agent-workflow-canvas-en","Sim turns agent workflows into a visual canvas","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"d3ec03a8-a805-4a21-9826-72a74a72b625","databricks-model-serving-llm-deploy-guide-zh","Databricks Model Serving 讓 LLM 部署變簡單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525998117-7ur8.png","2026-06-03T22:32:51.005996+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"4dd225a8-bf6c-4768-a486-a27956c7033d","opencode-digitalocean-model-freedom-zh","OpenCode+DigitalOcean 讓你切換模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525116428-1q7g.png","2026-06-03T22:18:06.969758+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"4bdcf208-fb80-484e-b4b6-06af035a6df1","modulate-aws-voice-chats-into-signals-zh","Modulate 用 AWS 把語音聊天做成訊號","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780519733892-rxue.png","2026-06-03T20:48:22.697917+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"f44a28d3-2305-43de-b5fa-21217d561054","amazon-rekognition-content-moderation-filter-zh","Amazon Rekognition把審核變成過濾器","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780517005409-bxfc.png","2026-06-03T20:02:57.634353+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"80f6f40b-3217-45e4-acff-7b2f6d261779","codex-workspace-limits-tell-you-why-zh","Codex 讓工作區限額錯誤說人話","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780514293711-ltqa.png","2026-06-03T19:17:41.340056+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"daa3d568-4bc5-4f29-aa64-225928ace9b4","book-2-turns-sneaker-drop-into-merch-zh","Book 2 把球鞋發售變成周邊系統","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780513400116-8jeh.png","2026-06-03T19:02:49.03795+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"]