[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-webassembly-turns-browser-editing-into-desktop-grade-docs-zh":3,"article-related-webassembly-turns-browser-editing-into-desktop-grade-docs-zh":30,"series-tools-8780b721-2aba-46fd-b9c0-d1cd0b1c817f":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},"8780b721-2aba-46fd-b9c0-d1cd0b1c817f","webassembly-turns-browser-editing-into-desktop-grade-docs-zh","WebAssembly 讓瀏覽器編輯變桌機級","\u003Cp data-speakable=\"summary\">這篇拆 Text Control 的 WebAssembly 文件\u003Ca href=\"\u002Fnews\u002Fdeepnote-turns-notebooks-into-editable-projects-zh\">編輯\u003C\u002Fa>思路，順手給你一份可直接貼進\u003Ca href=\"\u002Fnews\u002Fclarity-act-floor-vote-prep-crypto-teams-zh\">團隊\u003C\u002Fa>的架構模板。\u003C\u002Fp>\u003Cp>我做文件編輯器做久了，最怕那種「看起來很順，實際上很卡」的方案。WebSocket 我也玩過一輪，伺服器跑真正的引擎，瀏覽器只負責收發事件。能用，真的能用，但總有一點彆扭：一個字一個字打進去，像是在遠端操控一台機器，不像是在編輯文件。\u003C\u002Fp>\u003Cp>後來我看了 Text Control 的文章 \u003Ca href=\"https:\u002F\u002Fwww.textcontrol.com\u002Fblog\u002F2026\u002F06\u002F10\u002Fbeyond-websockets-glimpse-future-document-editing-webassembly\u002F\">Beyond WebSockets: A Glimpse into the Future of Document Editing with WebAssembly\u003C\u002Fa>，作者是 \u003Ca href=\"https:\u002F\u002Fwww.textcontrol.com\u002F\">Bjoern Meyer\u003C\u002Fa>。他們不是要把舊架構整個砍掉，而是把 WebAssembly 當成另一個執行目標，讓文件引擎更靠近瀏覽器端。這件事我一開始還以為只是包裝話術，結果越看越像真的在解一個老問題。\u003C\u002Fp>\u003Cp>因為文件編輯這東西，從來不是「做個 rich text box」就結束。版面、換行、字型、游標、列印輸出，任何一個地方飄掉，使用者都會直接覺得你在騙他。Text Control 這篇的價值，不在於它講了 Wasm 多潮，而是它把控制權這件事講得很清楚。\u003C\u002Fp>\u003Ch2>他們不是在追求輕量，是在追求控制\u003C\u002Fh2>\u003Cblockquote>Rather than simplifying document editing for the web, we brought the full document processing engine to the server and connected it to the browser via WebSockets.\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：他們沒有把文件編輯簡化成「網頁版差不多能用」，而是把完整引擎留住，再用瀏覽器去接它。這個思路很老派，但我反而覺得對。因為文件編輯最怕的不是功能少，是規則不一致。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781193811712-r4ud.png\" alt=\"WebAssembly 讓瀏覽器編輯變桌機級\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前也踩過這種坑。團隊一開始都說要做「Word-like editing」，結果底層卻用 contenteditable 硬撐。前面 demo 看起來沒事，等到真的碰到縮排、頁尾、表格、跨頁，就開始亂。那時候你才會發現，問題不是 UI \u003Ca href=\"\u002Fnews\u002Fllms-natural-language-tla-plus-specs-zh\">不夠\u003C\u002Fa>漂亮，是整個文件模型根本不穩。\u003C\u002Fp>\u003Cp>Text Control 的做法很明白：瀏覽器不是 truth source，伺服器才是。瀏覽器只是互動層，真正的文件狀態、版面計算、輸出規則還是要有一個核心掌握住。這種架構很像老司機開車，不花俏，但知道哪裡不能亂改。\u003C\u002Fp>\u003Cp>實操寫法我會這樣做：\u003C\u002Fp>\u003Cul>\u003Cli>先定義你的編輯器到底是「文件系統」還是「富文字輸入框」。兩者不要混。\u003C\u002Fli>\u003Cli>如果你在乎版面一致性，就把文件模型集中管理，不要讓前端自己發明規則。\u003C\u002Fli>\u003Cli>瀏覽器負責互動，伺服器負責真相，這條線先畫清楚。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我看過太多團隊把「前端自治」當成美德，結果渲染規則到處長歪。文件產品不是聊天框，不能靠感覺撐。\u003C\u002Fp>\u003Ch2>WebAssembly 把瀏覽器從 UI 層變成執行環境\u003C\u002Fh2>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwebassembly.org\u002F\">WebAssembly\u003C\u002Fa> 的意思很直白：原生程式和函式庫可以直接在瀏覽器裡跑。Text Control 的說法也很務實，他們把 C++ 程式編譯成緊湊的 binary，讓它在現代瀏覽器裡安全又有效率地執行。\u003C\u002Fp>\u003Cp>這句話翻成白話就是，瀏覽器不一定只能當「畫面容器」。它也可以承接一些真正吃算力的工作。像文件版面計算、游標移動、局部重繪、即時排版，這些東西如果每一步都丟回伺服器，延遲感會很明顯。\u003C\u002Fp>\u003Cp>我自己很在意這點，因為文件編輯的卡頓不是那種「等一下就好」的卡頓，是會直接破壞手感的卡頓。你按一個鍵，游標晚半拍；你拖一段文字，畫面跟不上；你改一個段落，整頁重算。使用者不會說「你的 round trip 太多」，他只會說「很難用」。\u003C\u002Fp>\u003Cp>Wasm 的好處，不是什麼神奇魔法，而是它把一部分決策拉近了使用者。少一點來回，就少一點抖動。尤其在網路品質不穩、VPN 很爛、企業內網很愛抽風的情境，這種差異很真實。\u003C\u002Fp>\u003Cp>實操寫法我會這樣切：\u003C\u002Fp>\u003Cul>\u003Cli>先找出你的熱路徑：鍵入、選取、排版、頁碼、輸出。\u003C\u002Fli>\u003Cli>能在本地即時算的，就不要每次都問伺服器。\u003C\u002Fli>\u003Cli>伺服器留給儲存、權限、審計、協作、重型輸出這些真正該在後端的事。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>很多人優化文件編輯都只盯 \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> latency，結果整個互動模型還是靠遠端回應。那不是優化，是在擦桌子。\u003C\u002Fp>\u003Ch2>他們賭的是一致性，不是新鮮感\u003C\u002Fh2>\u003Cblockquote>Documents should look the same, no matter where they are processed.\u003C\u002Fblockquote>\u003Cp>這句我覺得才是整篇的核心。其他都是手段，這句才是目的。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781193810040-t9wi.png\" alt=\"WebAssembly 讓瀏覽器編輯變桌機級\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>翻譯一下就是：Text Control 不想把 WebAssembly 包成一個新潮賣點，他們在意的是同一份文件，不管跑在伺服器還是瀏覽器，結果都要一樣。版面一樣、換行一樣、字型一樣、頁面分割一樣。這才叫文件產品，不然只是會輸入文字的網頁。\u003C\u002Fp>\u003Cp>我很買單這種思路。因為真正麻煩的從來不是「做出一個看起來像編輯器的東西」，而是「讓它在不同環境下都不走樣」。使用者對這種差異超敏感，哪怕他說不出是哪裡怪，他也知道怪。\u003C\u002Fp>\u003Cp>我以前做過一個法務文件系統，桌機匯出正常，瀏覽器編輯後的行距卻會偷偷變掉。看起來只差一點點，但對合約模板來說，那一點點就是事故。從那次之後我就很不信任「大概差不多」這種說法。\u003C\u002Fp>\u003Cp>實操寫法我會這樣做：\u003C\u002Fp>\u003Cul>\u003Cli>先定義一份 canonical document model，所有 runtime 都要服從它。\u003C\u002Fli>\u003Cli>同一份文件要在瀏覽器、伺服器、匯出三條路徑都測。\u003C\u002Fli>\u003Cli>不要只看互動速度，還要看輸出一致性。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你的產品是 business document software，rendering 只要有一點漂，support ticket 就會像雪球一樣滾。\u003C\u002Fp>\u003Ch2>他們不選 Blazor，是因為層數真的很重要\u003C\u002Fh2>\u003Cp>文章裡有一段在問：為什麼不直接用 \u003Ca href=\"https:\u002F\u002Fdotnet.microsoft.com\u002Fen-us\u002Fapps\u002Faspnet\u002Fweb-apps\u002Fblazor\">Blazor\u003C\u002Fa> 和 .NET runtime 跑在瀏覽器裡？他們的答案很直接：效能、渲染精準度、還有對編輯體驗的控制。\u003C\u002Fp>\u003Cp>這句話翻白話就是，他們不想在瀏覽器和文件引擎之間再多塞一層抽象。不是說 Blazor 不好，而是如果你的核心問題是文件 fidelity，那每多一層翻譯，就多一層漂移風險。\u003C\u002Fp>\u003Cp>我不反對 Blazor，我也不反對任何合理的前端 runtime。問題是工具要對題。你如果是在做一般 UI 組件、後台頁面、表單流程，Blazor 很可以。但如果你在做的是頁面級文件排版，層數越多，越容易把字型、量測、選取、重繪搞歪。\u003C\u002Fp>\u003Cp>我自己的判斷很簡單：只要產品有「像 Word 一樣」這種需求，我就先懷疑所有會增加轉譯層的東西。不是不能用，是要非常小心。\u003C\u002Fp>\u003Cp>實操寫法我會這樣判斷：\u003C\u002Fp>\u003Cul>\u003Cli>先看你要的是 UI composition，還是 pixel-level fidelity。\u003C\u002Fli>\u003Cli>如果你需要極準的排版，就少一點 runtime 轉譯。\u003C\u002Fli>\u003Cli>不要因為某個框架很熱，就把核心引擎交出去。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這不是框架鄙視鏈，這是工程現實。層數一多，責任就開始散掉。\u003C\u002Fp>\u003Ch2>掌握 rendering pipeline 才是真的在做產品\u003C\u002Fh2>\u003Cp>Text Control 也提到，他們想保留對 rendering pipeline 的掌控，不想把核心交給第三方框架或圖形引擎，像 \u003Ca href=\"https:\u002F\u002Fskia.org\u002F\">Skia\u003C\u002Fa> 這類工具雖然強，但不是每個場景都適合當最終依賴。\u003C\u002Fp>\u003Cp>翻譯一下就是：他們想知道從文件資料到畫面像素，中間每一步怎麼走。這很無聊，但這就是文件產品的命脈。因為你只要不能完整解釋渲染流程，就很難 debug。\u003C\u002Fp>\u003Cp>我看過很多團隊一開始都很樂觀，說「先接標準 graphics stack 再說」。半年後開始出現字型 fallback 不一致、瀏覽器差異、測試環境和正式環境排版不一樣。最後大家都在猜，沒人真的能說清楚是哪一層在搞鬼。\u003C\u002Fp>\u003Cp>Text Control 的路線比較狠：核心引擎自己掌握，編譯到目標平台，規則不要亂。這種做法很 boring，但很值錢。因為 boring 的東西通常比較能活。\u003C\u002Fp>\u003Cp>實操寫法我會這樣做：\u003C\u002Fp>\u003Cul>\u003Cli>把編輯器的 rendering dependency 全列出來，問自己每個是不是你真的能控制。\u003C\u002Fli>\u003Cli>版面計算、字型處理、頁面切分，盡量做成 deterministic，而不是靠黑盒。\u003C\u002Fli>\u003Cli>把 font、pagination、measurement 寫進產品規格，不要只寫在工程筆記裡。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你在做商務文件軟體，「大概能看」通常只是你還沒碰到第一個客訴。\u003C\u002Fp>\u003Ch2>企業團隊現在該怎麼看這件事\u003C\u002Fh2>\u003Cp>這篇文章最實際的地方是，它沒有裝作 WebAssembly 會把既有架構全部推倒重來。它其實是在說：WebSocket 模型還是很多部署場景的基礎，但 WebAssembly 讓 browser-first 的執行方式多了一條路。\u003C\u002Fp>\u003Cp>這個觀點我很認同。因為現實世界不是二選一。很多團隊需要伺服器中心的控制，也需要更靠近使用者的本地執行；有些甚至兩個都要。你不能拿一把錘子去敲所有問題。\u003C\u002Fp>\u003Cp>所以我現在看文件編輯架構，不會先問「WebSocket 還是 WebAssembly？」我會先問：文件管線裡哪些步驟必須本地化，哪些可以放伺服器，哪些又一定要有中心化控制。這樣問，才比較像在解題，不像在站隊。\u003C\u002Fp>\u003Cp>實操寫法我會這樣落地：\u003C\u002Fp>\u003Cul>\u003Cli>把 edit、render、validate、persist、export、sign 這幾段拆開看。\u003C\u002Fli>\u003Cli>標出哪些步驟需要低延遲，哪些步驟需要合規或審計。\u003C\u002Fli>\u003Cli>先接受混合架構，不要硬逼一個 runtime 做全部。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我喜歡這種框架，因為它逼團隊面對 tradeoff。很多人嘴上說要 modernize editor，其實根本沒講清楚自己要解的是哪個痛點。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 文件編輯器架構決策備忘錄\n\n## 問題\n我們需要一個瀏覽器文件編輯器，同時保住版面一致性、即時編輯手感、以及跨環境輸出穩定性。\n\n## 我們要優先的東西\n- WYSIWYG 一致性\n- 低延遲編輯體驗\n- 可預測的渲染結果\n- 跨平台文件 fidelity\n- 清楚的 rendering pipeline 擁有權\n\n## 目前架構\n- 瀏覽器 UI 負責互動\n- 伺服器持有文件引擎\n- 瀏覽器與伺服器透過 WebSocket 溝通\n- 伺服器是文件狀態的 source of truth\n\n## 什麼情況適合 WebAssembly\n如果編輯器需要以下能力，就評估 Wasm：\n- 在瀏覽器端做更多排版與渲染工作\n- 降低鍵入、游標移動、選取的 round trip\n- 在網路不穩時維持可用性\n- 把原生引擎編譯進瀏覽器 runtime\n- 對渲染精準度有很高要求\n\n## 什麼情況 WebSocket 還是合理\n如果你需要以下條件，就保留伺服器中心模型：\n- 文件處理要集中控管\n- 既有生產環境已經圍繞伺服器引擎建好\n- 需要更容易做權限、審計、合規\n- 協作邏輯本來就屬於 backend\n- 現有引擎已經能滿足 fidelity 要求\n\n## 決策規則\n如果你比起縮小 client 複雜度，更在意 fidelity 和控制權，就把核心邏輯留在你最能掌握的執行環境裡。若瀏覽器真的需要承擔更多本地工作，就把 WebAssembly 當成候選執行目標，而不是行銷口號。\n\n## 實作清單\n- [ ] 找出編輯與渲染的 hot path\n- [ ] 量測鍵入、選取、排版、頁碼的延遲\n- [ ] 定義單一 canonical document model\n- [ ] 測試 browser、server、export 三條路徑的一致性\n- [ ] 審查 rendering dependency 與字型行為\n- [ ] 決定哪些邏輯必須留在 server\n- [ ] 針對最吃效能的 client 端操作做 Wasm prototype\n\n## 可直接拿去問團隊的評估題\n我們正在評估文件編輯器要維持 WebSocket 為主的伺服器中心架構，還是把核心渲染與編輯邏輯移到 WebAssembly。請從效能、控制權、維護成本、渲染一致性四個面向比較，最後給出一個分階段的架構建議。\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段模板的好處，是它逼你真的做決策，不會只停在「我們應該升級一下」這種空話。你拿去開會，團隊就得回答：到底要解哪個問題？要把哪段 logic 放哪裡？\u003C\u002Fp>\u003Cp>而且它也保留了現實感。WebAssembly 如果只是幫你把熱路徑拉近瀏覽器，後端還是負責驗證、保存、權限，那就老實寫進去。不要演成一個 runtime 能解所有事，這種劇本通常都很貴，也很容易爛尾。\u003C\u002Fp>\u003Cp>原始來源是 Text Control 的文章 \u003Ca href=\"https:\u002F\u002Fwww.textcontrol.com\u002Fblog\u002F2026\u002F06\u002F10\u002Fbeyond-websockets-glimpse-future-document-editing-webassembly\u002F\">https:\u002F\u002Fwww.textcontrol.com\u002Fblog\u002F2026\u002F06\u002F10\u002Fbeyond-websockets-glimpse-future-document-editing-webassembly\u002F\u003C\u002Fa>，作者是 Bjoern Meyer。我上面拆的是它的思路，模板和落地問法是我自己整理的。\u003C\u002Fp>","拆 Text Control 的 WebAssembly 文件編輯思路，順手給你一份可直接貼進團隊的架構模板。","www.textcontrol.com","https:\u002F\u002Fwww.textcontrol.com\u002Fblog\u002F2026\u002F06\u002F10\u002Fbeyond-websockets-glimpse-future-document-editing-webassembly\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781193811712-r4ud.png","tools","zh","75b01da1-453d-46d1-95f5-e4d661b608ee",[17,18,19,20,21],"WebAssembly","WebSockets","document editor","rendering pipeline","WYSIWYG",[23,24,25],"文件編輯不是富文字輸入框，核心是版面一致性與控制權。","WebAssembly 的價值在於把熱路徑拉近瀏覽器，不是拿來裝新潮。","最實用的決策方式，是先拆文件管線，再決定哪段留在 server、哪段進 browser。",2,"2026-06-11T16:02:55.652289+00:00","2026-06-11T16:02:55.614+00:00","62aa0d1a-7b85-428c-bf5c-e2dfc7ad294d",{"tags":31,"relatedLang":42,"relatedPosts":46},[32,34,36,38,40],{"name":20,"slug":33},"rendering-pipeline",{"name":18,"slug":35},"websockets",{"name":21,"slug":37},"wysiwyg",{"name":17,"slug":39},"webassembly",{"name":19,"slug":41},"document-editor",{"id":15,"slug":43,"title":44,"language":45},"webassembly-turns-browser-editing-into-desktop-grade-docs-en","WebAssembly turns browser editing into desktop-grade docs","en",[47,53,59,65,71,77],{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"9947d432-419a-4fb2-b63e-2df73e5503f0","vibe-coding-lets-you-ship-a-tiny-app-fast-zh","Vibe coding 讓你先把小工具做出來","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781254115147-lr0c.png","2026-06-12T08:47:56.34535+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"f7cfd9fc-4795-40e6-9ccf-8d1d320d8560","what-vibe-coding-means-for-developers-zh","Vibe Coding 對開發者的真正意義","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781253188911-llz7.png","2026-06-12T08:32:32.032314+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"6371d809-9372-4a40-bf34-09ca516bf1c5","product-hunt-vibe-coding-tools-2026-zh","Product Hunt 的 vibe-coding 堆疊怎麼配","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781252320426-k29l.png","2026-06-12T08:18:03.871398+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"048fe239-c575-457f-87b3-7a11dcc92b45","copilot-keeps-old-amd-linux-gpus-alive-zh","Copilot 讓舊 AMD GPU 活下來","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781242402748-dls4.png","2026-06-12T05:32:53.912906+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"851e075c-b22f-4425-a5c8-28132574da25","fine-tune-slm-emotion-recognition-zh","情緒辨識 SLM 微調實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781231575451-p3g5.png","2026-06-12T02:32:23.646134+00:00",{"id":78,"slug":79,"title":80,"cover_image":81,"image_url":81,"created_at":82,"category":13},"5c8150a0-bd9a-4b69-bba3-09548f5dcc84","midjourney-pricing-guide-2026-plans-costs-zh","Midjourney 2026 訂閱費用與方案判讀","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781230674954-vf1u.png","2026-06-12T02:17:24.385566+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"]