2026/3/25
AI工具 AI自動化 Vibe Coding【Vibe Coding 實戰】如何打造政府標案監控平台?AI 自動化追蹤,省下萬元訂閱費!
為什麼你需要專屬的政府標案監控系統?大家好,我是想哥,致力於用 AI 改變世界。對於經常參與政府標案的企業或個人來說,每天到「政府電子採購網」搜尋案子是例行公事。然而,傳統的搜尋介面往往不夠直覺,手動查找不僅耗時,還極易錯失黃金商機。
為了解決這個痛點,坊間推出了許多標案監控的付費平台。這些平台確實好用,但通常需要支付一筆不小的年費(例如每年高達 8,800 元)。這促使我思考:既然我們已經處於 AI 時代,何不透過 Vibe Coding 自己打造一套專屬的監控系統?
這不僅是一個能幫你「精準賺錢」的工具,若你自己動手開發,更是一個能立即「省錢」的解決方案。今天,就帶大家來開箱我透過 Vibe Coding 完成的 MVP 作品——**Tender Radar (政府標案監控平台)**。
如果你想先看看實際成果,也可以直接前往體驗網站:Tender Radar。
每年省下近萬元!Tender Radar 核心功能解析透過 Tender Radar 系統,你可以完全掌握標案資訊。以下是系統的三大核心應用場景:
1. 串接公開 API,打造直覺的高效搜尋介面系統底層串接了 g0v 與政府公開的 API 數據,目前已成功匯入超過兩千多筆的標案資料。我們將傳統複雜的介面,轉化為簡潔的資料看板(Dashboard)。你可以透過關鍵字快速檢索,並直接點擊連結跳轉回政府電子採購網查看原始公告,大幅縮短前置作業時間。
2. 建立個人化追蹤條件與 AI 智能評分門檻這是本系統最具價值的地方。你可以建立「個人追蹤條件」,精準定義你想要的商機:
關鍵字設定: 包含字(如:工程、設備、系統、維護)與排除字。
精細篩選: 設定履約地區、預算上下限、截止天數等。
智能評分系統: 系統內建了「分數門檻」與「通知門檻」。透過 AI 輔助設計的評分權重機制,當標案高度符合你的條件時會獲得高分。你可以設定只有達到特定分數(例如命中多個關鍵字)才觸發通知,徹底避免垃圾資訊干擾。
3. LINE 與 Email 自動化精準推播再也不用每天主動刷網頁了!系統會在每天早上 8 點執行排程掃描(也可手動一鍵觸發)。當偵測到符合你高分門檻的新標案時,系統會自動透過以下管道推播給你:
LINE 推播: 傳送摘要卡片,包含標案名稱、預算、截止日與直達連結。
Email 通知: 將詳細的標案清單整理成列表,寄送至你的信箱。所有通知紀錄、成功與失敗狀態,甚至熱門機關與類別的數據分析,都能在後台的視覺化報表中一覽無遺。
如何擁有這套自動化標案系統?這個 Tender Radar 系統目前已經具備了完整的 MVP(最小可行性產品)架構。未來,我計畫將其發展成兩種模式:
SaaS 訂閱服務: 提供給不想寫程式,但需要高效工具的企業使用。
實戰教學課程: 將這套系統的開發過程包裝成課程,教導大家如何利用 Vibe Coding 與 AI 工具,一步步建構出屬於自己的自動化系統。
如果你對這套系統的部署、SaaS 服務,或是未來的教學課程有興趣,歡迎隨時與我聯絡!
常見問答 (FAQ)Q:這套標案監控平台的資料更新頻率與準確度如何?A:系統底層直接串接政府電子採購網與 g0v 的公開 API,資料與官方同步。配合每日早上的自動化排程掃描,能確保你在第一時間獲取最新、最準確的標案公告,不會有漏接的問題。
Q:設定中的「分數門檻」與「通知門檻」具體是如何運作的?A:這是一種防干擾的智能過濾機制。當標案符合你的「包含關鍵字」或「特定地區」時會累加分數。你可以設定「分數門檻」(例如 12 分才算及格被收錄)以及更高的「通知門檻」(例如 20 分才主動發 LINE 通知)。這套計分邏輯也可以請 AI 幫忙撰寫與優化,確保推播給你的都是精準的高價值商機。
Q:我完全沒有程式基礎,也能學會用 Vibe Coding 做出這個系統嗎?A:絕對可以!Vibe Coding 的核心精神就是讓 AI 成為你的工程師。只要你能清楚定義商業邏輯與需求(如:需要什麼欄位、用什麼方式通知),配合適當的 AI 工具引導,即使是零基礎也能一步步建置出這套自動化系統。
相關連結
Tender Radar 體驗網站
2026/3/24
AI工具 AI自動化 Vibe CodingGoogle Stitch MCP 教學:如何結合 AI 自動化快速生成 Next.js 網站 UI
Google 近期推出的 Stitch 在開發者社群中引起了廣大迴響,其強大的 UI 生成能力令人驚豔。透過結合 MCP (Model Context Protocol) 協定,我們可以讓 AI Agent 自動化處理繁瑣的前端切版工作。
本文將以一個「美甲美容預約系統」的 Next.js 網站為例,帶你一步步拆解如何從零開始,利用 Google Stitch MCP 快速產出具備高質感的網頁 UI。
先收藏 3 個官方入口如果你想快速上手,建議先把下面 3 個官方資源打開,後續安裝與操作時會用得到:
Stitch 官網:先了解 Stitch 的整體能力,包含從提示詞生成 UI、調整版型與匯出成果的核心流程。
Stitch MCP 官方安裝文件:用來設定 MCP Server、完成 API Key 綁定,這是讓 AI Agent 真正能呼叫 Stitch 的關鍵步驟。
stitch-skills GitHub 倉庫:Google Labs 提供的 Agent Skills 集合,能讓 Cursor、Claude Code、Gemini CLI 等工具更有效率地配合 Stitch 工作。
如何快速完成 Stitch MCP 環境部署?要讓 AI 能夠直接呼叫 Stitch 的生成能力,我們需要先完成 MCP 伺服器的安裝與 API 金鑰設定。
安裝 Stitch MCP 伺服器在您的 AI 代理開發環境(例如 Cursor、Antigravity 等支援 MCP 的工具)中,開啟 MCP Servers 管理介面,搜尋 stitch 並點擊安裝 (Install)。這一步將會自動化載入所需的環境設定。若想對照完整流程,可以直接參考 Stitch MCP 官方安裝文件。
獲取 API 金鑰 (API Key)安裝過程中,系統會引導您前往 Stitch 的官方網頁設定。請在設定頁面中點擊「建立金鑰」,生成專屬的 API 金鑰,並將其貼回您的 MCP 設定中妥善儲存以完成身分驗證。
擴充 AI 開發火力:安裝 Stitch Skills光有基礎 MCP 還不夠,為了讓 AI 具備更專業的前端工程師思維,我們需要導入 stitch-skills。
這是一個專為 Stitch MCP 伺服器設計的 Agent 技能函式庫,相容於 Gemini CLI、Claude Code 與 Cursor。透過安裝 GitHub 上的 stitch-skills 擴充套件,AI 就能夠遵循更嚴謹的開發標準進行作業,大幅減少生成過程中的邏輯錯誤。
根據該 GitHub 倉庫說明,stitch-skills 內建多種實用能力,例如:
stitch-design:負責 Stitch 設計工作流的統一入口。
stitch-loop:可從單一提示詞延伸成完整多頁網站流程。
design-md:協助整理設計系統與 DESIGN.md 文件。
react:components:將 Stitch 畫面轉成 React 元件系統,並維持設計 Token 一致性。
如果你平常就是用 AI 編輯器協作開發,這一層 skills 幾乎就是把 Stitch 從「會生成畫面」升級成「更懂前端交付流程」。
實戰演練:從需求規劃到自動生成 Next.js 網站環境建置完畢後,我們就可以開始向 AI 下達開發指令 (Prompt)。以下為本次美甲預約網站的標準化生成流程:
1. 啟動 SDD (軟體設計文件) 開發流程不要讓 AI 直接寫程式碼,而是要求它先執行 SDD (Software Design Document) 流程。AI 會依序產出結構化的規格文件(Spec)、開發計畫(Plan)與任務清單(Task)。這能確保 AI 清楚理解版面規劃,包含:導覽列 (Navbar)、Hero 區塊、服務項目、作品集與顧客評價等區塊。
1我想做一個美容美甲的預約系統,使用next.j做,先做首頁就好 ,執行 SDD 開發流程,依序產出結構化的 spec、plan 與 task 等規劃文件
2. 制定設計規範 (Design Tokens)在產出程式碼前,AI 會依據主題(如:柔和女性化、優雅高質感)自動建立設計系統。例如設定主色為「玫瑰粉 (#D4A5A5)」、背景色為「奶油米」,並指定字型(Playfair Display 與 Inter)。這些 Tokens 將成為後續 UI 生成的核心基準。
3. 呼叫 create_project 執行 UI 生成當規劃完成後,AI 會調用 Stitch MCP 的 create_project 方法。系統會自動下載所需套件(如 Tailwind CSS)、處理字型與圖標,並開始生成首頁的設計稿與原始碼。
完美還原設計稿:如何解決排版誤差?在初步生成後,您可能會發現瀏覽器渲染的畫面(localhost:3000)與 Stitch 原始設計稿有些微出入。這時不需要手動調整 CSS,只需遵循以下步驟:
反饋錯誤訊息: 將終端機或畫面上的報錯資訊直接貼給 AI 進行初步修復。
要求零誤差校正: 明確指示 AI:「網頁呈現與 Stitch 原始設計稿不太一樣,請幫我確認並修正」。
自動重構: AI 會重新比對 Tailwind tailwind.config.ts 中的顏色設定、全域 CSS 屬性與各個 Component(如 Navbar、Hero Section)的 HTML 結構,確保最終輸出的 Next.js 程式碼與設計稿達到 100% 零誤差轉換。
開發者反思: 當 AI 已經能包辦 UI 介面設計與繁瑣的切版工作時,未來的軟體工程師應將重心轉移至「架構設計」、「需求分析」與「商業邏輯整合」,這才是人類開發者無可取代的價值。
常見問答 (FAQ)Q:Google Stitch 的使用額度限制是什麼?A:目前系統每日提供 400 個額度 (Credits)。根據實測,透過 AI 完整生成一個包含豐富區塊(Hero、作品集、評價等)的高質感首頁,大約就會消耗掉 4 個額度。
Q:Stitch MCP 支援哪些 AI 開發工具?A:只要是支援 MCP (Model Context Protocol) 協定的開發工具皆可使用,主流工具包含 Cursor、Gemini CLI、Claude Code 以及 Antigravity 等。
Q:AI 生成的網頁設計如果不滿意可以修改嗎?A:可以的。您可以透過對話框下達新的提示詞 (Prompt),例如「請將按鈕顏色改為深色」或「調整作品集區塊的排版」,AI 會自動調用相關程式碼進行局部更新。
相關連結
Stitch 官網
Stitch MCP 官方安裝文件
stitch-skills GitHub 倉庫
2026/3/18
商業策略 AI自動化 Vibe Coding為什麼前端工程師應該開始往 FDE 邁進?AI 時代下,你的價值正在改變
為什麼前端工程師應該開始往 FDE 邁進?—— AI 時代下,你的價值正在改變多數人對前端工程師的理解,還停留在:
切版
寫 UI
串 API
這些當然重要,但有一件事正在發生:這些能力,正在變得越來越「不稀缺」。
前端開發,正在被重新定義這幾年最明顯的變化,就是 AI 對開發流程的影響。現在你已經可以做到:
用 AI 生成 React / Vue 元件
自動把設計稿轉成程式碼
快速補齊 CRUD 邏輯
幫忙 debug、重構
這些能力的共同特徵是:它們都集中在「寫功能」這件事上。也就是說,「寫畫面」正在變成基本能力,而不是競爭優勢。
那什麼才是下一個關鍵能力?當開發變得越來越快,有一件事情會變得更重要:如何讓這些功能「穩定上線並持續運作」。這正是 FDE(Front-End Deployment Engineer)在解決的問題。
FDE 在做的,其實是這些事如果你把視角從「寫程式」往後看,你會發現很多關鍵環節:
Build 怎麼設計才快、才穩?
Deploy 出問題時怎麼回滾?
Cache 怎麼設計才不會爆掉?
Staging 跟 Production 為什麼不一致?
Release 頻率變高時,風險怎麼控制?
這些問題不是 UI 層能解的,它們屬於「系統運作層」。而這一層,過去在前端領域是被忽略的。
台灣的現況:不是沒有需求,而是沒有被定義在台灣,很少看到「FDE」這個職稱。但實際上,這些工作一直都存在,只是被分散在不同角色:
前端工程師: 負責一部分 build / deploy。
DevOps: 負責基礎架構,但不一定熟前端。
後端: 偶爾支援部署流程。
結果會變成:沒有人完整負責「前端上線品質」。
這樣的結構,會帶來什麼問題?很多團隊其實都遇過:
Deploy 時很緊張,因為不確定會不會壞。
Cache 設錯,整站行為異常。
Build 時間過長,影響開發節奏。
發現 bug 卻很難快速回滾。
不同環境行為不一致。
這些問題不一定每天發生,但一旦發生,影響都很大。而且隨著系統變大,只會越來越頻繁。
AI 反而會放大這些問題這點很關鍵。AI 讓開發變快之後,會帶來兩個結果:
功能產出速度提升。
Release 次數增加。
當 Release 變頻繁,Deploy 次數變多,出錯機率隨之上升,系統複雜度也提高。整個壓力會往「部署與穩定性」集中。也就是說:AI 不是取代這個領域,而是讓它變得更重要。
前端工程師可以怎麼準備?如果你開始意識到這個趨勢,可以從幾個方向調整:
1. 把「上線」當成工程的一部分很多人會把 deploy 當成最後一步。但實際上,deploy 本身就是系統設計的一環。當你開始這樣看,你會自然注意到很多細節。
2. 理解 build 與部署背後的原理不只是會用工具,而是理解:
Build 在做什麼?為什麼會變慢?
Bundle 怎麼影響效能?
環境變數如何影響行為?
3. 開始接觸「前端以外的邊界」例如:
CI/CD 流程
CDN 與 cache 機制
簡單的雲端部署(像 AWS 或 Vercel)
不用變成基礎架構專家,但要知道「前端是怎麼被服務的」。
4. 練習處理「出問題的時候」平常寫功能很順,但真正的能力差異,通常出現在系統出問題時,能不能快速定位與處理:
如何 rollback?
如何確認問題在 client 還是 CDN?
如何避免問題再次發生?
一個正在發生的轉變未來的前端工程師,大致會分成兩種類型:
第一種: 擅長寫功能的人(這部分 AI 會越來越強)。
第二種: 能讓系統穩定運作的人。
這兩者的價值會逐漸拉開差距。而 FDE,就是往第二條路發展的其中一種方向。
結語前端工程不會消失,但它的重心正在改變。從「做出功能」,走向「讓系統可靠地運作」。當寫程式變得更容易,讓系統穩定,反而變得更難,也更有價值。這個轉變不會一夕之間完成,但已經開始發生了。
常見問答 (FAQ)什麼是 FDE (Front-End Deployment Engineer)?FDE 主要專注於前端應用的「系統運作層」,負責解決建置 (Build) 速度、部署 (Deploy) 流程、快取 (Cache) 策略以及環境一致性等問題,確保前端功能在頻繁更新的狀態下依然能穩定運作。
AI 工具普及後,前端工程師會面臨失業嗎?不會失業,但工作重心必須轉移。AI 能大幅提升「寫功能」與「切版」的效率,使這些純開發技能不再稀缺。未來的核心競爭力將在於如何確保系統穩定上線、跨環境部署的除錯能力,以及整體架構的風險控管。
從一般前端工程師轉型 FDE,該如何跨出第一步?建議從「把上線當成工程的一部分」開始。你可以先深入理解專案目前的 Build 流程、接觸 CI/CD 工具(如 GitHub Actions 等)、學習 CDN 與快取機制,並嘗試使用 Vercel 或 AWS 獨立部署專案,逐步培養宏觀的系統架構思維。