[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-spec-kit-guided-ai-workflow-setup-zh":3,"article-related-spec-kit-guided-ai-workflow-setup-zh":30,"series-tools-c614316e-6910-49e8-83d1-da7e7c2c3e79":76},{"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},"c614316e-6910-49e8-83d1-da7e7c2c3e79","spec-kit-guided-ai-workflow-setup-zh","Spec Kit 把設定變成導引流程","\u003Cp data-speakable=\"summary\">Spec Kit 把專案設定變成一套可複製的 AI-agent 導引流程。\u003C\u002Fp>\u003Cp>我用 \u003Ca href=\"\u002Ftag\u002Fai-coding\">AI coding\u003C\u002Fa> assistant 已經夠久了，久到一看 setup 流程就知道哪裡會卡。通常都是這樣：\u003Ca href=\"\u002Fnews\u002Fai-code-review-tools-catch-issues-earlier-zh\">工具\u003C\u002Fa>裝好了、repo 也開了、模型看起來很勤奮，然後我開始當保母。它每次都很會接話，卻完全不知道這個專案現在在哪個狀態、有哪些規則、哪些決策已經定案。最後變成我一直補上下文，它只負責點頭。這種「很幫忙」的感覺，我其實很膩。\u003C\u002Fp>\u003Cp>所以我看到 \u003Ca href=\"https:\u002F\u002Fdeepwiki.com\u002Fgithub\u002Fspec-kit\u002F2-getting-started\">DeepWiki 的 Spec Kit getting started\u003C\u002Fa> 時，第一個反應不是「哇好酷」，而是「終於有人不把 setup 當成一次性安裝」。Spec Kit 的做法很硬：先初始化，再走 spec、plan、tasks、implement，順序不能亂。它不是在討好你，它是在逼你先把專案講清楚。我反而覺得這比較像正常工作方式。\u003C\u002Fp>\u003Cp>我也回頭對了 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\">github\u002Fspec-kit\u003C\u002Fa> 的原始倉庫、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\u002Fblob\u002Fmain\u002Fdocs\u002Fquickstart.md\">quickstart\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\u002Fblob\u002Fmain\u002Fdocs\u002Finstallation.md\">installation\u003C\u002Fa>，避免只吃 wiki 摘要。因為這種東西最怕被二手轉述轉到只剩漂亮話，真正有用的是它怎麼要求你在 repo 裡放哪些檔案、跑哪些指令、先做哪一步。\u003C\u002Fp>\u003Ch2>不要把 agent setup 當成裝完就能用\u003C\u002Fh2>\u003Cblockquote>“The typical path from zero to a working project follows this sequence: Installation and Initialization.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是，Spec Kit 不認同「裝好」等於「可以開始亂問」。它把 setup \u003Ca href=\"\u002Fnews\u002F20-ai-coding-assistants-stripped-down-2026-zh\">拆成\u003C\u002Fa>兩段：先安裝 CLI，再在真正要工作的 repo 裡初始化。這聽起來很基本，但多數人其實都在偷懶，裝完工具就直接開聊，期待模型自己長出專案記憶。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782505105249-9o62.png\" alt=\"Spec Kit 把設定變成導引流程\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前也幹過這種事。某個 side project 我一直覺得 agent 很鈍，後來才發現不是模型不行，是我根本沒給它專案級規則。每次開新 session，它都像第一次來這個世界，永遠從零開始猜。Spec Kit 的思路很直接：把專案本身變成上下文來源，不要把記憶責任丟給人腦。\u003C\u002Fp>\u003Cp>實操上，我會把這件事拆成三個動作：先裝 CLI，再在 repo root 初始化，最後才讓 agent 進場。這不是儀式感，這是避免 workflow 一開始就散掉。你如果跳過初始化，後面那些 slash command、context file、scripts 都只是空名詞。\u003C\u002Fp>\u003Cul>\u003Cli>先安裝 CLI，不要先開 prompt。\u003C\u002Fli>\u003Cli>在你真的要做事的 repo root 跑 init。\u003C\u002Fli>\u003Cli>把 initialization 當成「讓專案變成 agent-aware」的步驟。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我現在看 setup flow，都會先問一句：這套流程有沒有把專案狀態寫進 repo？如果沒有，那大概又是個靠人肉補洞的設計。Spec Kit 至少不是這樣，它是把洞補在流程裡。\u003C\u002Fp>\u003Ch2>CLI 只是入口，不是你要一直依賴的東西\u003C\u002Fh2>\u003Cblockquote>“Install the specify-cli command globally using uv or pipx.”\u003C\u002Fblockquote>\u003Cp>Spec Kit 先給你一個 CLI，因為 CLI 的工作不是陪你聊天，是把專案骨架寫進 repo。官方文件也明講，真正維護的來源是 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\">github\u002Fspec-kit\u003C\u002Fa>，不是你在 PyPI 上隨便看到的同名套件。這種提醒我很買單，因為包名撞車這種事在 Python 世界實在太常見，踩一次就知道痛。\u003C\u002Fp>\u003Cp>白話一點說，CLI 是 scaffolding tool，不是產品本體。它負責把 agent 需要的檔案、模板、命令和腳本放好，然後你就回到 repo 裡面工作。文件提到 \u003Ca href=\"https:\u002F\u002Fdocs.astral.sh\u002Fuv\u002F\">uv\u003C\u002Fa> 和 \u003Ca href=\"https:\u002F\u002Fpipx.pypa.io\u002F\">pipx\u003C\u002Fa> 都是正常安裝路徑，也有一次性 setup 的選項給不想永久安裝的人。這種設計比「請自行想辦法」好多了。\u003C\u002Fp>\u003Cp>我喜歡這種分工，因為它讓 setup 很明確。工具如果會偷偷改 repo、偷偷跑背景流程，我會很煩。我要的是一個有名字的命令，跑下去後有可預期的結果，而不是某種神秘魔法。\u003C\u002Fp>\u003Cp>實操寫法我會這樣抓：\u003C\u002Fp>\u003Cul>\u003Cli>先用官方路徑裝 CLI，別亂找同名包。\u003C\u002Fli>\u003Cli>跑 \u003Ccode>specify version\u003C\u002Fcode> 或 \u003Ccode>specify check\u003C\u002Fcode> 確認環境正常。\u003C\u002Fli>\u003Cli>如果是企業環境或離線環境，就照文件的 local wheel \u002F one-time setup 走，不要自己拼。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>很多文件都假裝大家機器乾淨、網路順、權限全開。現實不是。Spec Kit 至少有把這種情境考慮進去，這點我給過。\u003C\u002Fp>\u003Ch2>init 才是骨架真正冒出來的地方\u003C\u002Fh2>\u003Cblockquote>“The init command sets up the necessary scaffolding for your chosen AI agent.”\u003C\u002Fblockquote>\u003Cp>這句話很重要，因為 \u003Ccode>specify init\u003C\u002Fcode> 不只是建資料夾，它會根據你選的 integration 去放對應檔案。DeepWiki 也有列出常見整合像 \u003Ccode>\u003Ca href=\"\u002Ftag\u002Fclaude\">claude\u003C\u002Fa>\u003C\u002Fcode>、\u003Ccode>\u003Ca href=\"\u002Ftag\u002Fcopilot\">copilot\u003C\u002Fa>\u003C\u002Fcode>、\u003Ccode>\u003Ca href=\"\u002Ftag\u002Fgemini\">gemini\u003C\u002Fa>\u003C\u002Fcode>、\u003Ccode>codebuddy\u003C\u002Fcode>、\u003Ccode>pi\u003C\u002Fcode>、\u003Ccode>zed\u003C\u002Fcode>。而且舊的 \u003Ccode>--ai\u003C\u002Fcode> 旗標已經被 \u003Ccode>--integration\u003C\u002Fcode> 取代，這種細節很煩，但也很真實。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782505103852-wbul.png\" alt=\"Spec Kit 把設定變成導引流程\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>翻譯一下就是，Spec Kit 不想讓每個 agent 都變成你腦中的特例。你不用每次手刻 folder layout，不用自己猜這個工具讀哪個 context file。你選 integration，CLI 幫你把該放的東西放好。這種做法很像把「工具相容性」變成初始化責任，而不是把錯誤留到後面才爆。\u003C\u002Fp>\u003Cp>我自己最有感的是，當你在不同 agent 之間切換時，差異不只在 prompt 語氣，而是檔案位置和命名規則真的不同。以前我常常拿同一套 prompt recipe 到處塞，然後怪模型表現不一致。後來才懂，是我自己在亂套模板，不是工具真的一樣。\u003C\u002Fp>\u003Cp>實操上我會這樣做：\u003C\u002Fp>\u003Cul>\u003Cli>先選你真的會用的 integration，不要貪多。\u003C\u002Fli>\u003Cli>優先用 \u003Ccode>--integration\u003C\u002Fcode>，別再碰被棄用的 \u003Ccode>--ai\u003C\u002Fcode>。\u003C\u002Fli>\u003Cli>只有在你知道理由時才加 \u003Ccode>--no-git\u003C\u002Fcode>、\u003Ccode>--force\u003C\u002Fcode> 這類旗標。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>重點不是背 flag，而是讓初始化產生一致的 baseline。這樣你後面才有東西可以檢查、可以修、可以交接。\u003C\u002Fp>\u003Ch2>Context file 不是附屬品，是 agent 的工作記憶\u003C\u002Fh2>\u003Cblockquote>“Agent context files providing project metadata and instructions.”\u003C\u002Fblockquote>\u003Cp>Spec Kit 會生出像 \u003Ccode>CLAUDE.md\u003C\u002Fcode>、\u003Ccode>GEMINI.md\u003C\u002Fcode> 這種 context file，也會放對應的 command 目錄，例如 \u003Ccode>.claude\u002Fcommands\u002F\u003C\u002Fcode> 或 \u003Ccode>.\u003Ca href=\"\u002Ftag\u002Fgithub\">github\u003C\u002Fa>\u002Fagents\u002F\u003C\u002Fcode>。這些東西看起來很像附加檔，實際上是 model 在這個專案裡到底該怎麼做事的依據。\u003C\u002Fp>\u003Cp>白話講，模型不是靠「看懂整個 codebase」就能自動知道規則。它需要一份穩定的指令集。這比你每次重新解釋架構、重講 conventions、重提邊界條件有效太多了。那種一直重講的感覺，就像你在幫一個失憶症同事做短期記憶外包，累的是你。\u003C\u002Fp>\u003Cp>我以前很常遇到 agent 明明在 repo 裡，卻像沒進場。它能看到檔案，但不知道什麼重要、什麼只是歷史垃圾。context file 的價值，就是把「什麼是這個專案的規則」寫成固定資訊。它不會解決所有問題，但至少能少掉一大堆重複解釋。\u003C\u002Fp>\u003Cp>實操寫法我會守三條：\u003C\u002Fp>\u003Cul>\u003Cli>先讀生成的 context file，再決定要不要改。\u003C\u002Fli>\u003Cli>把新成員也需要知道的規則寫進去。\u003C\u002Fli>\u003Cli>保持短，別寫成小說。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我很在意這點：context file 一旦長到像規格書，模型根本不會好好用。最好的文件通常都很無聊，因為它們只做一件事：讓 agent 不用猜。\u003C\u002Fp>\u003Ch2>工作流是階梯，不是「邊聊邊看」\u003C\u002Fh2>\u003Cblockquote>“Constitution → Specify → Plan → Tasks → Implement”\u003C\u002Fblockquote>\u003Cp>這就是 Spec-Driven Development 的核心。它不是叫你一直聊天，聊到某天 \u003Ca href=\"\u002Fnews\u002Fxcode-266-gemini-ai-coding-stack-zh\">code\u003C\u002Fa> 自己冒出來。它要的是一串有順序的產物和命令：先用 \u003Ccode>\u002Fspeckit.constitution\u003C\u002Fcode> 定義原則，再用 \u003Ccode>\u002Fspeckit.specify\u003C\u002Fcode> 寫 feature spec，接著 plan、tasks，最後才 implement。DeepWiki 也把這些階段對應到像 \u003Ccode>.specify\u002Fmemory\u002Fconstitution.md\u003C\u002Fcode>、\u003Ccode>specs\u002FNNN-feature\u002Fspec.md\u003C\u002Fcode>、\u003Ccode>plan.md\u003C\u002Fcode>、\u003Ccode>tasks.md\u003C\u002Fcode> 這些檔案。\u003C\u002Fp>\u003Cp>也就是說，Spec Kit 想強迫你先講清楚再寫 code。不是哲學，是成本控制。因為一旦 code 先出現，人就會莫名其妙對它產生感情，明明 spec 還在糊，卻開始捨不得砍。這種情況我看太多了，最後常常是把錯誤實作養成技術負債。\u003C\u002Fp>\u003Cp>我自己最喜歡這種流程的原因很簡單：它讓我有機會在最便宜的時候抓錯。spec 還沒定，改起來很便宜；code 都寫完了，改起來就開始付利息。Spec Kit 其實是在幫你把「先討論後實作」這件事流程化。\u003C\u002Fp>\u003Cp>實操上可以這樣落地：\u003C\u002Fp>\u003Cul>\u003Cli>每個專案先跑 constitution，建立共同原則。\u003C\u002Fli>\u003Cli>任何 feature 先寫 spec，不要先叫 agent 生 code。\u003C\u002Fli>\u003Cli>plan 和 tasks 要真的拿來管進度，不要只是裝飾文件。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你習慣 prompt-first，這套會讓你覺得慢。但我自己的經驗是，慢一點通常比較不會在第三輪才發現方向整個歪掉。\u003C\u002Fp>\u003Ch2>腳本才是把流程黏起來的真正骨架\u003C\u002Fh2>\u003Cblockquote>“The automation scripts in .specify\u002Fscripts\u002F provide shared utilities to ensure consistency across the workflow.”\u003C\u002Fblockquote>\u003Cp>這段我反而最重視。Spec Kit 在 \u003Ccode>.specify\u002Fscripts\u002F\u003C\u002Fcode> 裡放了 bash 和 PowerShell 的輔助腳本，像 \u003Ccode>create-new-feature\u003C\u002Fcode>、\u003Ccode>check-prerequisites\u003C\u002Fcode>、\u003Ccode>update-agent-context\u003C\u002Fcode>。這代表它不是只給你 markdown 文件而已，它有把流程落地的執行層。\u003C\u002Fp>\u003Cp>翻譯一下就是，這套方法論不是靠大家自覺。它靠腳本減少人為漂移。因為一旦流程只存在於文件裡，每個人都會有自己的解讀，最後專案會長成一堆不相容的版本。腳本至少能把共識鎖住，讓人跟 agent 都走同一條路。\u003C\u002Fp>\u003Cp>我以前看過不少團隊想做 spec-driven，但只有文件沒有工具，結果就是每個人都說自己有照流程，實際上根本不是同一套。腳本的好處是，它讓「應該怎麼做」變成「真的可以執行」。這差很多。\u003C\u002Fp>\u003Cp>實操寫法：\u003C\u002Fp>\u003Cul>\u003Cli>先確認你平台對應的腳本有沒有生成完整。\u003C\u002Fli>\u003Cli>能用 helper script 就不要手動重做流程。\u003C\u002Fli>\u003Cli>當 context 變動時，記得用提供的腳本刷新。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這種 refresh 機制很重要。流程最怕不是一開始沒做好，而是做一做就過期，然後大家還以為自己在同一個版本上工作。\u003C\u002Fp>\u003Ch2>先把 agent 放進 repo，再開始工作\u003C\u002Fh2>\u003Cblockquote>“After initialization, launch your AI agent in the project directory.”\u003C\u002Fblockquote>\u003Cp>這句其實把前面所有東西串起來了。agent 不是先在外面開一個泛用 session，再丟進 repo。它應該直接在初始化過的專案目錄裡啟動，這樣它才能看到剛剛產生的 commands、context files、workflow artifacts。\u003C\u002Fp>\u003Cp>白話講，目錄位置不是瑣事，是權限和可見性的問題。你如果在錯的地方開 agent，它看不到該看的東西，最後又會回到「我猜一下」的模式。然後你會覺得它不穩，其實只是你把它放錯場景。\u003C\u002Fp>\u003Cp>我自己以前很常偷懶，直接在任意 session 裡貼路徑，期待它自己懂。結果通常都像帶觀光客逛工廠：看得到門口，看不到流程。後來我才改成先進 repo root，再讓 agent 開始做事，整個體感差很多。\u003C\u002Fp>\u003Cp>實操上我會這樣檢查：\u003C\u002Fp>\u003Cul>\u003Cli>在 initialized repo root 打開 Claude Code、Copilot、Windsurf 或你自己的 agent。\u003C\u002Fli>\u003Cli>確認它能看到 \u003Ccode>\u002Fspeckit.*\u003C\u002Fcode> 這些命令。\u003C\u002Fli>\u003Cli>所有 workflow 都從 repo root 跑，不要從臨時 scratch session 開始。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這就是差別：一邊是「我有個 AI 工具」，另一邊是「我有一套專案工作流」。前者很熱鬧，後者才真的能交付。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Spec Kit 起手式模板（可直接貼進新專案筆記或 README 草稿）\n\n## 1. 安裝 CLI\n# 擇一使用官方路徑\n# uv tool install specify-cli\n# pipx install specify-cli\n\nspecify version\nspecify check\n\n## 2. 在 repo root 初始化\n# 請在真正要工作的專案目錄執行\nspecify init --integration claude\n\n# 其他整合範例：\n# specify init --integration copilot\n# specify init --integration gemini\n# specify init --integration zed\n\n## 3. 在初始化後的專案目錄啟動 agent\n# 不要在外部泛用 session 裡硬塞路徑\n# 直接從 repo root 開啟 AI agent\n\n## 4. 依序走 spec-driven flow\n\u002Fspeckit.constitution\n\u002Fspeckit.specify\n\u002Fspeckit.plan\n\u002Fspeckit.tasks\n\u002Fspeckit.implement\n\n## 5. 每次變更後檢查這份清單\n- [ ] CLI 來自官方 github\u002Fspec-kit\n- [ ] init 在正確的 repo root 執行\n- [ ] integration 選對了\n- [ ] agent 是在專案目錄裡啟動的\n- [ ] constitution 先寫，再談 feature\n- [ ] spec、plan、tasks 都有產生\n- [ ] 需要時用 helper scripts 更新 context\n\n## 6. 預期會看到的檔案\n- .specify\u002Fmemory\u002Fconstitution.md\n- .specify\u002Ftemplates\u002F\n- .specify\u002Fscripts\u002F\n- specs\u002FNNN-feature-name\u002Fspec.md\n- specs\u002FNNN-feature-name\u002Fplan.md\n- specs\u002FNNN-feature-name\u002Ftasks.md\n\n## 7. 我自己的使用原則\n- context file 要短、要明確、要能被模型真的讀進去\n- 不要先寫 code 再補 spec\n- 能用腳本就不要手動重做流程\n- 把 setup 當成專案 onboarding，不是安裝完成就結束\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>如果我今天要新開一個 repo，我會直接拿這段當底稿。它不是花俏版本，但就是夠用，而且夠不容易走歪。這類工具最怕你把它玩成自由發揮，Spec Kit 的價值剛好相反：它逼你先把框架立住。\u003C\u002Fp>\u003Cp>這篇的拆解主要來自 \u003Ca href=\"https:\u002F\u002Fdeepwiki.com\u002Fgithub\u002Fspec-kit\u002F2-getting-started\">DeepWiki 的 getting-started 頁面\u003C\u002Fa>，再對照 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\">github\u002Fspec-kit\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\u002Fblob\u002Fmain\u002Fdocs\u002Fquickstart.md\">quickstart\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fspec-kit\u002Fblob\u002Fmain\u002Fdocs\u002Finstallation.md\">installation\u003C\u002Fa>。上面的中文整理、判讀和模板是我自己重新整理過的版本，不是原文照抄。","我拆解 Spec Kit 的起手式，整理成一套可直接複製的 AI-agent 規格驅動設定模板。","deepwiki.com","https:\u002F\u002Fdeepwiki.com\u002Fgithub\u002Fspec-kit\u002F2-getting-started",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782505105249-9o62.png","tools","zh","332d7a17-50b0-4815-9f3f-1fe0178a4bcf",[17,18,19,20,21],"Spec Kit","AI agent","spec-driven development","workflow","context file",[23,24,25],"把 AI agent setup 當成專案 onboarding，而不是一次性安裝。","先寫 constitution\u002Fspec\u002Fplan\u002Ftasks，再讓模型碰 code。","用官方 CLI、integration 和 scripts 把流程固定住，減少人肉補洞。",0,"2026-06-26T20:17:59.33633+00:00","2026-06-26T20:17:59.312+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":31,"relatedLang":35,"relatedPosts":39},[32,34],{"name":18,"slug":33},"ai-agent",{"name":20,"slug":20},{"id":15,"slug":36,"title":37,"language":38},"spec-kit-guided-ai-workflow-setup-en","Spec Kit turns setup into a guided AI workflow","en",[40,46,52,58,64,70],{"id":41,"slug":42,"title":43,"cover_image":44,"image_url":44,"created_at":45,"category":13},"7a129fc2-20dd-451f-b118-ea4eab053d8a","dockers-apt-repo-update-ubuntu-cleanly-zh","Docker APT 讓 Ubuntu 更新不亂套","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782516777598-3r4p.png","2026-06-26T23:32:35.230193+00:00",{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"69cbfbfb-8532-4bd3-814b-559a260cdd4a","litefuse-agent-observability-single-binary-doris-zh","Litefuse 不是 Langfuse 的補丁，而是 Agent 可觀測的正…","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782500574117-ul0z.png","2026-06-26T19:02:21.266856+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"4f42621b-c5ca-42ca-a567-c48e1cb34222","20-ai-coding-assistants-stripped-down-2026-zh","20 個 AI 寫碼助手，拆成可用清單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782498806913-57hj.png","2026-06-26T18:32:53.614602+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"0ca67afc-db75-48f7-8185-0a539685ce60","open-code-review-turns-ai-reviews-line-accurate-checks-zh","Open Code Review 把 AI 審查變準","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782490706378-ts02.png","2026-06-26T16:17:57.066004+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"2d745abb-9cb8-4d94-b2a6-cb3558904f27","grok-imagine-1-5-turns-prompts-into-720p-video-zh","Grok Imagine 1.5把提示詞變720p短片","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782475410787-cu25.png","2026-06-26T12:03:02.703582+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"42fe01d4-37e4-44d0-811c-119a991c9069","ocr-4-turns-pdfs-into-cited-rag-input-zh","OCR 4 把 PDF 變成可引用 RAG 輸入","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782469113477-4epx.png","2026-06-26T10:18:04.231073+00:00",[77,82,87,92,97,102,107,112,117,122],{"id":78,"slug":79,"title":80,"created_at":81},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":83,"slug":84,"title":85,"created_at":86},"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":88,"slug":89,"title":90,"created_at":91},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"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":98,"slug":99,"title":100,"created_at":101},"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":103,"slug":104,"title":105,"created_at":106},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"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":118,"slug":119,"title":120,"created_at":121},"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":123,"slug":124,"title":125,"created_at":126},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]