[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-ibm-vibe-coding-guide-turns-prompts-into-code-zh":3,"article-related-ibm-vibe-coding-guide-turns-prompts-into-code-zh":30,"series-tools-a1bd40fe-2b96-430c-bce3-17f4b3284333":82},{"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},"a1bd40fe-2b96-430c-bce3-17f4b3284333","ibm-vibe-coding-guide-turns-prompts-into-code-zh","IBM Vibe Coding 把提示詞變程式碼","\u003Cp data-speakable=\"summary\">IBM 的 \u003Ca href=\"\u002Fnews\u002Fvibe-coding-turns-app-ideas-into-crowded-markets-zh\">vibe\u003C\u002Fa> coding 指南其實是在教你用提示詞先產出第一版程式碼，再靠人類把它修好。\u003C\u002Fp>\u003Cp>我最近一直在看 \u003Ca href=\"\u002Ftag\u002Fvibe-coding\">vibe coding\u003C\u002Fa>，越看越有種熟悉的煩躁感。不是因為它沒用，剛好相反，是它太容易看起來有用。我把需求丟給模型，它回我一坨像樣的程式碼；我再多問幾句，它又補得頭頭是道。問題是，這種順手常常會騙人。你以為自己在加速，其實只是更快拿到一份需要重寫的草稿。\u003C\u002Fp>\u003Cp>我讀 IBM 這篇 \u003Ca href=\"https:\u002F\u002Fwww.ibm.com\u002Fthink\u002Ftopics\u002Fvibe-coding\">What is Vibe Coding?\u003C\u002Fa> 時，最有感的不是它把 vibe coding 說得多漂亮，而是它至少沒有裝傻。它講得很白：先用自然語言表達意圖，讓 AI 生出骨架，再由人去 refine。這就對了。很多人只聽到「AI 會寫 code」，就開始幻想把工程師整個外包給模型，然後再花兩週追 bug，追到懷疑人生。\u003C\u002Fp>\u003Cp>所以我想把 IBM 這份說法拆開，不是講概念，而是講我會怎麼用。重點只有一個：它到底怎麼把提示詞變成可控的第一版程式碼，哪裡好用，哪裡會翻車，最後又怎麼寫成你真的能照抄的工作流。\u003C\u002Fp>\u003Cp>這篇的起點是 IBM 的文章 \u003Ca href=\"https:\u002F\u002Fwww.ibm.com\u002Fthink\u002Ftopics\u002Fvibe-coding\">What is Vibe Coding?\u003C\u002Fa>，作者是 Shalini Harkar。文中還提到 Andrej Karpathy，以及 \u003Ca href=\"https:\u002F\u002Freplit.com\u002F\">Replit\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.cursor.com\u002F\">Cursor\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffeatures\u002Fcopilot\">GitHub Copilot\u003C\u002Fa> 這些常見\u003Ca href=\"\u002Fnews\u002Fanthropic-buys-stainless-sdk-tool-rivals-zh\">工具\u003C\u002Fa>；我下面的拆解是沿著這些來源往下拆，不是憑空發明一套新名詞。\u003C\u002Fp>\u003Ch2>Vibe coding 不是免寫程式，是先寫提示詞\u003C\u002Fh2>\u003Cblockquote>“Vibe coding” is a new and loosely-defined term in software development that refers to the practice of prompting AI tools to generate code rather than writing code manually.\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：你不是直接敲每一行程式，而是先把意圖、限制、輸入輸出講清楚，讓模型先吐出第一版。這件事最重要的地方，不是「AI 幫你寫」，而是你把工作單位從「逐行輸入」改成「描述需求」。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779183875735-m3wz.png\" alt=\"IBM Vibe Coding 把提示詞變程式碼\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>IBM 的重點其實很務實。它沒有把 vibe coding 說成\u003Ca href=\"\u002Fnews\u002Fwhy-claude-release-timeline-proves-platform-war-zh\">什麼\u003C\u002Fa>神奇新宗教，只是把它定義成一種 prompt-first 的流程。對我來說，這個說法比「AI 寫 code」準多了。因為真正有價值的部分，從來不是模型會不會打字，而是你能不能把需求講到夠清楚，讓產物可以直接進下一步。\u003C\u002Fp>\u003Cp>我自己最常拿來測這件事的，是 UI 或內部工具。你如果只說「做一個 dashboard」，模型通常會回你一個很像 dashboard 的東西，但細節空洞得要命。可是一旦你說「React、左側導覽、表格、inline filter、loading\u002Ferror\u002Fempty state 都要有」，它就會開始像樣。不是因為它懂你的產品，是因為你把骨架講出來了。\u003C\u002Fp>\u003Cp>這裡 IBM 提到的工具也很有代表性：\u003Ca href=\"https:\u002F\u002Fchat.openai.com\u002F\">ChatGPT\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fclaude.ai\u002F\">Claude\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fopenai.com\u002Findex\u002Fintroducing-codex\u002F\">OpenAI Codex\u003C\u002Fa>。我會把它們看成不同型態的助手，不會幻想一套工具通吃。有人適合做 scaffold，有人適合 refactor，有人適合來回問答。你如果拿錯工具，還怪它不聰明，那其實是你 workflow 沒分清楚。\u003C\u002Fp>\u003Cp>實操上，我會把 AI 當成一個打字很快、但需要超明確指令的 junior engineer。你要告訴它 stack、檔案邊界、使用者流程、不能做什麼、成功標準是什麼。這些東西你自己都說不出來的話，先別急著 vibe coding，因為那不是 AI 的問題，是你還沒把需求想完整。\u003C\u002Fp>\u003Cul>\u003Cli>先寫提示詞，再寫 code，不要反過來。\u003C\u002Fli>\u003Cli>一定要交代 framework、runtime、輸出格式。\u003C\u002Fli>\u003Cli>先切最小可用片段，別一口氣丟整個產品。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>真正省下來的是 boilerplate，不是思考\u003C\u002Fh2>\u003Cp>IBM 說 vibe coding 可以讓人留在創造的狀態，把瑣碎工作交給 AI，還能快速產出標準化的 codebase 結構。這句話我認，因為它講的是速度，不是智商。模型不會替你想產品方向，但它很會幫你把那些重複到讓人想翻桌的東西先鋪好。\u003C\u002Fp>\u003Cp>我最有感的是重複性高的 setup。新 feature branch，routing 要接、表單驗證要寫、loading\u002Ferror\u002Fempty state 要補、component shell 要拉。這些工作不是難，是煩。煩到你很容易把注意力浪費在「把東西打出來」而不是「這功能到底該怎麼長」。如果 AI 能先把骨架弄好，我就可以把腦力留給真正該想的地方。\u003C\u002Fp>\u003Cp>IBM 也提到一種「先做出來，再慢慢修」的思路。我同意，但前提是「慢慢修」真的有發生。很多團隊最會犯的錯，就是把第一版草稿當成半成品真理，然後開始裝忙。結果不是沒有加速，而是把風險往後拖，拖到最後一起爆。\u003C\u002Fp>\u003Cp>所以 vibe coding 最適合的場景很明確：原型、內部工具、demo、驗證想法。你先把東西做出來，讓人看見流程和互動，再決定要不要重做。這比一開始就把每個細節雕到完美，然後發現方向根本錯了，要實際得多。\u003C\u002Fp>\u003Cp>實操上，我會用一句話判斷要不要上 vibe coding：這個任務的最大風險，是「想法不對」還是「系統撐不住」？如果是前者，AI 很適合。若是後者，別鬧了，先別把核心邏輯交給模型。\u003C\u002Fp>\u003Cul>\u003Cli>適合：prototype、internal app、throwaway experiment、UI scaffold。\u003C\u002Fli>\u003Cli>不適合：核心交易流程、安全敏感流程、分散式系統。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>提示詞品質，其實就是需求品質\u003C\u002Fh2>\u003Cblockquote>“The more effective the prompt is, the better the output will be.”\u003C\u002Fblockquote>\u003Cp>這句話很直白，但我還是要講，因為太多人嘴上說懂，手上卻還在丟「幫我做一個好看的頁面」這種空話。提示詞不是魔法咒語，它就是換了介面的需求文件。你寫得越模糊，模型就越會用它自己的預設值補洞。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779183870377-pbui.png\" alt=\"IBM Vibe Coding 把提示詞變程式碼\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>IBM 給的例子不錯：一個互動視覺體驗，會隨音樂、使用者互動、即時資料變化，還指定 JavaScript 或 React，甚至提到不同 mood 的客製化。這種 prompt 之所以有效，不是因為它長，而是因為它把行為、限制、技術棧都講了。模型最怕的不是複雜需求，是你什麼都沒說，卻期待它懂。\u003C\u002Fp>\u003Cp>我現在寫 prompt，會直接想成在交代一個只會做第一版的外包工程師。我要它知道五件事：做什麼、給誰用、用什麼 stack、要有哪些狀態、哪些東西不要碰。只要這五件事講清楚，輸出通常就會從「看起來很像」變成「我真的能改」。\u003C\u002Fp>\u003Cp>我以前踩過的坑很典型：我只說要做一個表單，結果模型幫我加了一堆自作聰明的驗證與 UI 裝飾，最後我還得先砍掉八成內容。後來我改成先寫清楚輸入、輸出、錯誤狀態、非目標，模型反而更像在幫忙，而不是在亂猜。\u003C\u002Fp>\u003Cp>實操上，prompt 要像規格，不要像心情。你可以直接照這個結構寫：功能、受眾、stack、行為、限制、非目標、交付物。這樣模型才知道自己是在產出哪一層的東西，而不是隨便發揮。\u003C\u002Fp>\u003Cul>\u003Cli>功能描述要可驗收，不要只寫感覺。\u003C\u002Fli>\u003Cli>一定要列出 loading、empty、error、success。\u003C\u002Fli>\u003Cli>最好要求它回傳檔案結構與假設，方便你接手。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>修正階段才是真正的工程\u003C\u002Fh2>\u003Cp>IBM 的四步驟其實很老實：選平台、定需求、修生成結果、檢查後再交付。聽起來像廢話，因為它本來就該是這樣。真正難的不是叫模型吐 code，而是你有沒有耐心把第三步做完。\u003C\u002Fp>\u003Cp>我看過太多人卡在第一版就停了。模型一輸出，大家就開始說「差不多了吧」。差不多通常就是最危險的詞。因為你如果沒有真的檢查結構、命名、邊界、錯誤處理，那你只是把重寫的工作延後，沒有省掉。\u003C\u002Fp>\u003Cp>我自己用 AI 寫 React 小功能時，最常遇到的問題就是 state 分散、component 太肥、命名不一致。這時候我不會直接手工整坨重寫，而是回頭要求模型做更小的切分、抽 helper、把 props 邊界講清楚。這個節奏很重要：先生成，再檢視，再收斂，再重生一次。\u003C\u002Fp>\u003Cp>IBM 也提醒要在部署前 review。這一步不能只看一眼，真的不能。我要看的是正確性、可讀性、依賴數量、錯誤處理、以及模型是不是偷偷塞了我沒同意的假設。AI 很會補假設，而且通常補得很自然，像沒事一樣。問題就在這裡。\u003C\u002Fp>\u003Cp>實操上，我會把 refinement 變成清單，而不是感覺。缺測試就補測試，component 太大就拆，架構太鬆就先要 folder map 或流程圖，再碰 business logic。你只要願意把修正當工程做，vibe coding 才真的有用。\u003C\u002Fp>\u003Cul>\u003Cli>先看結構，再看行為，最後才看美觀。\u003C\u002Fli>\u003Cli>盡量用 targeted edit，不要每次都整份重寫。\u003C\u002Fli>\u003Cli>生成的 code 要小到你能口頭講完。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>IBM 最有價值的提醒，是它直接講限制\u003C\u002Fh2>\u003Cblockquote>“AI simply generates code, but true creativity, goal alignment and out-of-the-box thinking remain uniquely human.”\u003C\u002Fblockquote>\u003Cp>這句我很買單。AI 可以生 code，但它不會替你扛產品目標，也不會替你決定什麼叫合理妥協，更不會在出事時自己去跟老闆解釋。它只是很會產出看起來像答案的東西。\u003C\u002Fp>\u003Cp>IBM 列的限制我覺得都很實在：技術複雜度、code quality、performance、debugging、maintenance、security。這些不是附註，這些才是 vibe coding 真正會撞牆的地方。你在 demo 階段覺得它很神，不代表你有能力把它養到上線後還活著。\u003C\u002Fp>\u003Cp>特別是安全性。IBM 直接提醒，AI 產出的 code 可能被排除在 review 和 security check 之外，這會製造風險。我看過最常見的翻車方式，就是團隊太相信「看起來對」，結果沒人再做一次認真的檢查。這種東西最容易帶著自信上線，然後在最不想修的時候出事。\u003C\u002Fp>\u003Cp>維護也是大坑。模型生成的 code 常常不是按照你團隊的命名、資料夾、測試、lint 規範來寫，它會自己長出一套很順手但很陌生的結構。短期看沒事，三個月後你自己回頭看，會懷疑這到底是不是你家 repo。\u003C\u002Fp>\u003Cp>實操上，我會把 vibe coding 放在 guardrails 裡面，不讓模型定架構，不讓它跳過測試，也不讓它繞過 review。快是快，但快不是理由，快只是前提；能不能長期維護，才是重點。\u003C\u002Fp>\u003Ch2>最適合的場景，是人類主導的快速原型\u003C\u002Fh2>\u003Cp>IBM 把快速原型、問題導向思考、降低風險，還有 voice、visual、text 的多模態輸入都放進來，這一點我覺得很準。因為 vibe coding 最強的地方，從來不是證明工程有多高級，而是幫你更快看見事情長什麼樣子。\u003C\u002Fp>\u003Cp>我比較喜歡把它想成草圖板，不是成品。你先畫出流程、互動、資料流的大概樣子，拿去驗證想法。如果草圖有戲，再進入正式開發。這樣做的好處是，你不會在錯的方向上雕太久。\u003C\u002Fp>\u003Cp>這也是為什麼早期團隊常常會愛上這套方法。因為他們要的是訊號，不是完美。只要能更快知道「這東西有人要嗎」，就值得。你如果還在 pre-product market fit，卻把每個 function 都當成銀行核心系統在寫，那通常是自虐，不是專業。\u003C\u002Fp>\u003Cp>IBM 提到的 \u003Ca href=\"https:\u002F\u002Freplit.com\u002F\">Replit\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.cursor.com\u002F\">Cursor\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffeatures\u002Fcopilot\">GitHub Copilot\u003C\u002Fa> 都可以用，但工具不是關鍵，流程才是。沒有 review 沒有測試，最強工具也只是更快把垃圾生出來。反過來說，只要流程有規矩，普通工具也能很好用。\u003C\u002Fp>\u003Cp>實操上，我會在團隊裡明確切一條「vibe coding lane」：只用在 idea、prototype、internal experiment。只要要碰到使用者或金流，就回到正常 engineering review。這樣你才有速度，也才不會把風險假裝不見。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Vibe Coding 工作流模板（可直接複製改寫）\n\n## 1) 先定義問題\n- 我要做什麼？\n- 給誰用？\n- 解決哪個痛點？\n- 什麼叫做成功？\n\n## 2) 丟給 AI 的 prompt\nBuild a [feature\u002Fapp\u002Fcomponent] for [audience] using [stack].\n\nRequirements:\n- Core behavior: [list]\n- Inputs: [list]\n- Outputs: [list]\n- States: loading, empty, error, success\n- UI\u002FUX constraints: [list]\n- Performance constraints: [list]\n- Accessibility constraints: [list]\n- Security constraints: [list]\n- Non-goals: [list]\n\nDeliverables:\n1. Suggested file structure\n2. Implementation code\n3. Short explanation of key decisions\n4. Assumptions made\n5. Follow-up questions for me\n\n## 3) 第一輪 review 清單\n- 行為有沒有對上需求？\n- 結構是不是看得懂？\n- loading \u002F empty \u002F error \u002F success 有沒有處理？\n- 有沒有測試或至少可測試案例？\n- 依賴有沒有太多？\n- 有沒有安全或隱私問題？\n- 三個月後別人看得懂嗎？\n\n## 4) 精修 prompt\nRefine the code with these changes:\n- [specific change 1]\n- [specific change 2]\n- [specific change 3]\n\nKeep the same stack. Keep the scope limited to these changes. Preserve working behavior unless explicitly requested otherwise.\n\n## 5) 上線規則\n不要把生成的 code 直接丟 production，直到：\n- 人類 review 過\n- tests 跑過\n- 安全敏感路徑檢查過\n- code 不看 prompt 也能看懂\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板就是我把 IBM 文章拆成可執行版本後，留下來最有用的部分。它的精神很簡單：先把需求講清楚，再讓 AI 產第一版，然後你要真的做 review 和 refinement，不要把「快」誤認成「完成」。\u003C\u002Fp>\u003Cp>原始來源是 IBM 的 \u003Ca href=\"https:\u002F\u002Fwww.ibm.com\u002Fthink\u002Ftopics\u002Fvibe-coding\">What is Vibe Coding?\u003C\u002Fa>。上面關於流程、風險與模板的整理，是我根據原文做的實務化改寫；模板本身是我自己的可複製版本，不是 IBM 原文直接附上的內容。\u003C\u002Fp>","我把 IBM 的 vibe coding 指南拆成可直接上手的流程、限制與可複製模板，讓你用提示詞先做出第一版程式碼。","www.ibm.com","https:\u002F\u002Fwww.ibm.com\u002Fthink\u002Ftopics\u002Fvibe-coding",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779183875735-m3wz.png","tools","zh","c68c66d5-fd1a-42c3-be06-29843ec3f7fb",[17,18,19,20,21],"vibe coding","prompt engineering","AI-assisted coding","code review","prototype",[23,24,25],"vibe coding 的核心是先寫提示詞，再讓 AI 產出第一版程式碼","真正省時間的是 boilerplate，不是工程判斷","要把生成、review、refine 做成固定流程，避免直接把草稿當成成品",3,"2026-05-19T09:44:02.030134+00:00","2026-05-19T09:44:02.003+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,34,36,37,39],{"name":19,"slug":33},"ai-assisted-coding",{"name":18,"slug":35},"prompt-engineering",{"name":21,"slug":21},{"name":17,"slug":38},"vibe-coding",{"name":20,"slug":40},"code-review",{"id":15,"slug":42,"title":43,"language":44},"ibm-vibe-coding-guide-turns-prompts-into-code-en","IBM’s vibe coding guide turns prompts into code","en",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"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":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"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":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"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":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"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":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"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":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"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",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"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":94,"slug":95,"title":96,"created_at":97},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"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":104,"slug":105,"title":106,"created_at":107},"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":109,"slug":110,"title":111,"created_at":112},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"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":124,"slug":125,"title":126,"created_at":127},"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":129,"slug":130,"title":131,"created_at":132},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]