本集影片詳細介紹了 Claude Code 這款強大的 AI 程式開發助手，強調使用者即使不具備程式語言基礎，也能透過自然語言對話實現所謂的「Vibe Coding」來打造個人工具。教學從基礎的 Git 與 VS Code 環境搭建開始，逐步演示如何利用 CLAUDE.md 備忘錄與 Skills 技能包來擴展 AI 的功能，使其能處理跨檔案的邏輯並執行如製作簡報或生成圖片等複雜任務。此外，文中探討了進階的 Subagents 分身協作與 MCP 外部工具串接，讓 AI 能與 Notion 等第三方軟體連動。最後，作者以開發具備文字辨識與翻譯功能的 Chrome 擴充功能為實戰範例，展示了從初期規劃、錯誤偵錯到版本管理的完整開發流程。這份指南旨在幫助初學者透過 AI 的輔助，輕鬆將創意轉化為實用的應用程式。本集影片詳細介紹了 Claude Code 這款強大的 AI 程式開發助手，強調使用者即使不具備程式語言基礎，也能透過自然語言對話實現所謂的「Vibe Coding」來打造個人工具。教學從基礎的 Git 與 VS Code 環境搭建開始，逐步演示如何利用 CLAUDE.md 備忘錄與 Skills 技能包來擴展 AI 的功能，使其能處理跨檔案的邏輯並執行如製作簡報或生成圖片等複雜任務。此外，文中探討了進階的 Subagents 分身協作與 MCP 外部工具串接，讓 AI 能與 Notion 等第三方軟體連動。最後，作者以開發具備文字辨識與翻譯功能的 Chrome 擴充功能為實戰範例，展示了從初期規劃、錯誤偵錯到版本管理的完整開發流程。這份指南旨在幫助初學者透過 AI 的輔助，輕鬆將創意轉化為實用的應用程式。

🔹 內容綱要

00:00 Claude Code 安裝

03:31 Claude Code 基本操作簡介

07:39 建立 CLAUDE.md 文件 0

9:41 還原對話或檔案

10:25 Skills 簡介

16:09 Hooks 簡介

16:57 Subagents 簡介

19:15 MCP 簡介

20:42 壓縮對話和用量檢查

21:30 Vibe Coding 實作範例

更多科技工作請上科技專區：https://techplus.1111.com.tw/

🔹 網站連結

Claude Code 安裝 https://code.claude.com/docs/en/overview

GitHub Anthropics 官方 Skills https://github.com/anthropics/skills

Nano Banana 2 Skill https://github.com/kingbootoshi/nano-...

Google AI Studio https://aistudio.google.com/

Notion MCP https://developers.notion.com/guides/...

🔹 請 Papaya 喝咖啡 ☕️ https://buymeacoffee.com/papayaclass

🔹 頻道會員影片目錄 https://bit.ly/3PaC4Jj

#教學 #ClaudeCode #Claude #VibeCoding #AI #程式開發

這篇文章 PAPAYA 電腦教室 |別再羨慕別人用 AI！Claude Code 全攻略！手把手教你 Vibe Coding 動嘴就成真 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

開課日期：2026-04-21上課地點：新竹市東區光復路二段295號3樓之2(新竹恆逸教育訓練中心)上課費用： …

開課日期：2026-04-21
上課地點：新竹市東區光復路二段295號3樓之2(新竹恆逸教育訓練中心)
上課費用：線上洽詢

課程介紹：

特色一、以自然語言驅動的資料分析流程（Vibe Coding × AI）
學員無需撰寫程式碼，即可透過自然語言描述分析需求，結合 Vibe Coding 與 AI 輔助工具，完成資料整理、分析與視覺化。有效降低技術門檻，讓非工程背景者也能快速產出具備實務價值的分析成果。

特色二、實作導向的完整分析體驗，強調「可落地」成果
課程不以理論為主，而是從實際情境出發，涵蓋環境建置、問題定義、分析流程到成果展示，逐步帶領學員完成可實際應用的資料分析專案，培養即學即用、能直接應用於工作或學習場域的能力。

報名此課程

課程內容：

師資介紹：

 陳講師

• 現任：台灣人工智能產業協會講師、實踐大學推廣中心講師等。
• 專長：機器學習、影像識別、大型語言模型、生成式AI、數位電路與嵌入式系統、程式設計。
• 經歷：中原大學電子所博士、中央研究院資訊科學所博士後研究員，曾任資深工程師與資料科學家，並擁有豐富授課經驗，擔任公協會講師多年。

報名此課程

備註：
詳細內容及報名需知，請點選報名後見協會網站內容

[elementor-template id="128291"]

這篇文章 【4/21新竹場】AI 驅動的資料分析實務（使用Vibe Coding） -【工研院】 產業學院 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

身為一名大學講師，我知道很多研究生每天都在與時間賽跑。諸如論文進度、文獻閱讀、實驗數據以及與指導教授開會的會議記錄⋯⋯這些資訊，散落在不同的應用程式中：待辦事項用 Notion，筆記用 Heptabase，文獻管理用 Zotero，時間追蹤用番茄鐘 App。我看到很多人，每天光是在這些工具之間切換，就耗費了大量的認知負荷。作者：鄭緯筌（專欄作家，「臺灣電子商務暨創業聯誼會」共同創辦人，前「APP01」網站總監、《風傳媒》產品總監和《數位時代》雜誌主編）

Debug 之旅：當測試成為最好的老師

環境變數的隱形殺手

在本地測試時，一切運作正常。但當用戶回報「新增筆記失敗」時，我陷入了困惑。後端日誌顯示沒有收到任何 POST 請求，前端卻顯示「保存失敗，請稍後再試」。老實說，這種「幽靈錯誤」最難除錯，因為你不知道問題出在哪一個環節？

經過 Claude Code 仔細地檢查，發現前端開啟了兩個 Vite 開發伺服器實例，而且它們使用的環境變數可能不一致。問題的根源在於我在不同的終端視窗中多次執行 npm run dev，而 Vite 的熱重載機制讓我誤以為服務已經更新。

經過與 Claude Code 的討論，解決方法很直接：關閉所有 Vite 進程，重新啟動單一實例。但這個經驗讓我學會了使用 ps aux | grep vite 來檢查執行中的進程，以及在啟動服務前先確認沒有殘留的進程。更重要的是，我在專案中加入了 .env.example 檔案，明確記錄所有需要的環境變數，避免團隊成員（或未來的自己）踩到同樣的坑。

資料庫初始化的暗黑時刻

在準備部署時，我發現一個更嚴重的問題：本地測試用的 SQLite 資料庫檔案是 0 位元組。這意味著資料庫從未真正初始化成功，我一直在測試的是某個未知位置的資料庫檔案。

原來，Flask 的資料庫初始化邏輯預設會在 instance 目錄下創建資料庫檔案，而我的 app.py 中使用了相對路徑 sqlite:///gradpilot.db，這導致 Flask 在預期的位置找不到資料庫。更糟的是，我在 app.py 中實作了一個簡單的初始化機制：只有在第一次請求時才創建資料表。如果這個機制失敗，所有後續的請求都會失敗，但錯誤訊息卻不明確。

修復這個問題，需要手動執行資料庫初始化：進入 Python shell，匯入 app 和 db，然後執行 db.create_all()。從那之後，我學會了在專案的 README.md 中明確記錄初始化步驟，並在部署腳本中加入資料庫初始化指令。這個教訓告訴我，部署前的環境驗證絕對不能省略。

測試驅動的品質保證

當所有功能都實作完成後，我面臨一個問題：如何確保所有功能都能正常運作？手動測試既耗時，又容易遺漏細節。於是，我請 Claude Code 創建了一份詳盡的測試清單 TESTING_CHECKLIST.md，涵蓋 12 個主要功能模組、超過 300 個測試項目。

這份清單不僅僅是一個核取清單，它更像是一份互動式的測試指南。每個測試項目都包含明確的操作步驟和預期結果，讓任何人都能按圖索驥地完成測試。在測試過程中，我發現了前面提到的所有 bug，也驗證了修復的正確性。

在測試的過程中，也讓我重新審視了使用者體驗。例如，我發現番茄鐘的提示文字寫著「保持專注 25 分鐘」，但這個數字應該根據使用者設定動態改變。這種細節很容易在開發過程中被忽略，但對使用者體驗卻有顯著影響。

部署的最後一哩路

在本地端的程式順利執行之後，接下來會遇到另一個問題，就是不知要部署到哪個主機？得花多少錢？

經過 Claude Code 的建議，最後選擇了 Render 作為部署平臺。相比於 Heroku（已取消免費方案）和 AWS（對新手不友善），Render 提供了簡單易用的介面和慷慨的免費額度。更重要的是，它原生支援從 Git 倉庫自動部署，這讓 CI/CD 流程變得極其簡單。

此外，部署配置檔 render.yaml 很重要，它定義了整個應用的架構：PostgreSQL 資料庫、Python 後端服務與靜態前端網站。Render 會自動讀取這個檔案，創建所有必要的資源，並設定正確的環境變數。唯一需要手動處理的是敏感資訊如 SECRET_KEY 和 JWT_SECRET_KEY，Render 提供了自動生成功能，確保每個部署環境都有獨立的密鑰。

第一次部署時，我遇到了 CORS 錯誤。前端部署在 gradpilot-frontend.onrender.com，後端部署在 gradpilot-backend.onrender.com，瀏覽器的同源政策阻止了跨域請求。解決方法是在後端配置 CORS 白名單，允許來自前端域名的請求。這個問題提醒我，本地開發環境和生產環境的差異永遠存在，必須在實際部署後進行完整測試。

效能優化：在免費方案的限制中求生存

值得注意的是，Render 的免費方案有一個顯著的限制：服務閒置 15 分鐘後會進入休眠狀態，下次訪問時需要 30-60 秒的喚醒時間。這對使用者體驗是個挑戰，但也促使我思考如何在前端層面進行優化。

在 Claude Code 的協助之下，我實作了一個簡單但有效的載入狀態管理系統。當使用者首次訪問時，如果後端還在喚醒，前端會顯示友善的載入動畫和提示訊息，而不是讓使用者面對一片空白。這個小小的改變大幅提升了使用者的容忍度。

另一個優化是實作資料快取。用戶的基本資訊在登入後會存放在 localStorage，避免每次頁面刷新都需要重新從後端獲取。這不僅加快了載入速度，也減少了後端的負擔。當然，敏感資訊如 JWT token 需要謹慎處理，我設定了合理的過期時間，並在登出時清除所有快取資料。

從 MVP 到產品：使用者回饋的力量

當 GradPilot 2.0 上線後，我邀請了幾位研究生朋友試用。他們的回饋既有鼓勵也有批評，但都極具價值。有人反映番茄鐘的預設時間太長，有人希望能在筆記中插入圖片，有人建議增加資料匯出功能以防資料遺失。

這些回饋，促使我重新思考產品的定位。GradPilot 不應該是一個功能完整的工具，而應該是一個恰到好處的工具。畢竟，研究生已經有太多複雜的工具需要學習，他們需要的是一個簡單、直覺又能專注於核心需求的平臺。

基於這個認知，我實作了資料匯出功能，支援 JSON、CSV 與 Markdown 等多種格式。這不僅解決了資料備份的需求，也讓使用者能自由地將資料遷移到其他工具。這種不鎖定使用者的設計哲學，反而增加了使用者的信任和忠誠度。

技術債與重構的永恆輪迴

隨著功能的增加，技術債也在累積。有些程式碼寫得匆忙，有些設計不夠優雅，有些測試覆蓋不足。但作為一個新手開發者，我必須在完美和完成之間取得平衡。

Claude Code 教會我採用漸進式重構的策略，也就是每次新增功能時，順帶重構相關的舊程式碼。例如，在實作文獻管理功能時，我發現待辦事項和筆記的標籤處理邏輯幾乎相同，於是我抽取了一個共用的 formatTags 函數。這種遇到問題就修改的策略，讓程式碼品質在不知不覺中持續提升。

當然，有些技術債必須專門騰出時間來處理。例如，前端的狀態管理一度變得非常混亂，有些狀態存在 Context，有些存在組件內部，有些存在 localStorage。我花了一個晚上梳理問題，統一了狀態管理的模式，大幅降低 bug 的發生率。

開源與社群：站在巨人的肩膀上

這個專案能取得初步的成功，很大程度上歸功於開源社群。Flask、React、Vite、TailwindCSS⋯⋯每一個工具都凝聚了無數開發者的心血。當我遇到問題時，往往能在 Stack Overflow、GitHub Issues 或官方文件中找到答案。

作為回饋，我選擇將 GradPilot 2.0 的完整原始碼開源在 GitHub 上，並撰寫了詳盡的文件和部署指南。我希望這個專案能幫助其他有類似需求的研究生，也希望它能成為初學者學習全端開發的參考案例。

開源不僅僅是分享程式碼，更是分享知識和經驗。在撰寫文件的過程中，我重新審視了自己的設計決策，發現了許多可以改進的地方。教學相長，這個過程本身就是一種學習。

展望未來：永不停歇的迭代

GradPilot 2.0 目前已經滿足了我的基本需求，但這只是開始。我已經在規劃 3.0 版本，計劃加入更多進階功能：與文獻資料庫的 API 整合、基於機器學習的文獻推薦或多人協作的研究筆記等。

但在追求新功能之前，我會先確保現有功能的穩定性和使用者體驗。這是我在這次開發中學到的最重要的一課：好的產品不是功能最多的產品，而是最能解決使用者問題的產品。

回顧這 30 個小時的開發旅程，在 Claude Code 的協助之下，我不僅建立了一個實用的工具，更重要的是培養了一種系統化的思考方式。面對複雜的問題，如何拆解成可管理的小任務？遇到 bug 時，如何有條理地排查？在資源有限的情況下，如何做出明智的技術選擇？

我覺得，這些能力遠比寫出漂亮的程式碼更重要。技術會過時，工具會更迭，但解決問題的思維方式是永恆的。GradPilot 2.0 對我來說不只是一個專案，它是一次完整的學習歷程，一次從想法到產品的實踐，一次對自己能力的挑戰和證明。

無論你是一位上班族或研究生，如果你也有想要解決的問題，我鼓勵你動手去做。不要被技術的複雜性嚇倒，不要等到準備好了才開始。正如我的經驗所示，最好的學習往往發生在實作的過程中，最大的成長往往來自於克服困難的時刻。

現在，就開始和 AI 共創你的第一行程式碼吧。你的作品正在呼喚你！

這篇文章 Vibe Coding 從零到部署： 30 個小時寫出一套學習儀表板（下）｜專家論點【鄭緯筌Vista】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

身為一名大學講師，我知道很多研究生每天都在與時間賽跑。諸如論文進度、文獻閱讀、實驗數據以及與指導教授開會的會議記錄⋯⋯這些資訊，散落在不同的應用程式中：待辦事項用 Notion，筆記用 Heptabase，文獻管理用 Zotero，時間追蹤用番茄鐘 App。我看到很多人，每天光是在這些工具之間切換，就耗費了大量的認知負荷。作者：鄭緯筌（專欄作家，「臺灣電子商務暨創業聯誼會」共同創辦人，前「APP01」網站總監、《風傳媒》產品總監和《數位時代》雜誌主編）

當理想遇上現實：從研究生的數位焦慮談起

身為一名大學講師，我知道很多研究生每天都在與時間賽跑。諸如論文進度、文獻閱讀、實驗數據以及與指導教授開會的會議記錄⋯⋯這些資訊，散落在不同的應用程式中：待辦事項用 Notion，筆記用 Heptabase，文獻管理用 Zotero，時間追蹤用番茄鐘 App。我看到很多人，每天光是在這些工具之間切換，就耗費了大量的認知負荷。

「為什麼沒有一個專為研究生設計的整合平臺？」這個念頭在我腦海中盤旋許久。直到某個深夜，當我再次因為找不到某篇文獻筆記而焦慮時，我決定親手打造一個解決方案。這就是 GradPilot 2.0 （https://vista.im/gradpilot）的誕生契機——一個專為研究生設計的全方位學習儀表板。

技術選型：在理想與務實之間取得平衡

作為一個不諳程式設計的新手，之前只有少數使用 Lovable 和 Gemini 寫程式的經驗。這回，我改用 Claude Code 來開發。原本很擔心看不懂它的文字介面，但實際操作之後發現自己多慮了。遇到問題是很正常的事情，多跟 AI 討教就是了！不過，當然 tokens 也燒得很快。

在 Claude Code 的建議之下，我選擇了 Flask 作為後端框架。倒不是因為它最新潮，而是因為它夠簡單、文件完整，讓我能夠快速上手。前端則選擇 React 搭配 Vite，這個組合在 2024 年時已經非常成熟，社群資源豐富，遇到問題時能快速找到解決方案。

資料庫方面，開發環境使用 SQLite 讓我能快速迭代，生產環境則切換到 PostgreSQL。這種彈性得益於 SQLAlchemy 的抽象層，讓我不需要為了資料庫切換而重寫大量代碼。最重要的是，所有這些技術都能在 Render 的免費方案上運行，這對預算有限的開發者來說非常重要。

架構設計：從混亂到清晰的演進

老實說，因為自己不是資訊背景出身，所以最初的架構設計其實相當簡陋。我只是想著先讓它跑起來再說，結果就是一個巨大的 app.py 檔案，所有路由、邏輯和資料庫操作全部擠在一起。當檔案超過 500 行時，我開始感受到維護的痛苦。

重構的契機，來自於新增文獻管理功能。我意識到如果繼續這樣下去，專案很快就會變成無法維護的龐大代碼。於是我花了半天光景，請 Claude Code 將專案重構成清晰的模組化架構：

後端採用藍圖（Blueprint）模式，將認證、待辦事項、筆記、番茄鐘與文獻管理等功能分離成獨立的模組。每個模組都有自己的路由檔案和業務邏輯，資料庫模型則統一放在 models 目錄下。這樣的架構讓我能夠專注於單一功能的開發，而不會被其他部分干擾。

前端的組件化，也遵循類似的思路。每個功能都有自己的組件目錄，包含相關的子組件。例如待辦事項功能包含 TodoList、TodoItem、TodoForm 等組件，每個組件職責單一，易於測試和維護。

功能實現：細節中的魔鬼

番茄鐘的時間魔法

番茄鐘功能看似簡單，實際上充滿了細節考量。最初的實現中，我直接在組件內硬寫入 25 分鐘的專注時間和 5 分鐘的休息時間。這在開發階段沒有問題，但當用戶回饋希望能自訂時長時，問題就來了。

第一個挑戰，是如何在組件中讀取用戶設定。我使用 React Context 來管理全域的用戶狀態，但番茄鐘組件卻忘記從 Context 中讀取 pomodoro_duration 和 break_duration。這導致了一個有趣的 bug：用戶在設定頁面修改時長後，回到 Dashboard 卻發現番茄鐘仍然顯示 25:00。

若想修復這個問題，就需要在多個地方調整，好比：初始化狀態時使用用戶設定、重置時使用用戶設定、模式切換時使用用戶設定以及進度計算時使用用戶設定。每一個地方，都需要將硬編碼的數字替換成從 Context 讀取的動態值。這個看似簡單的改動，實際上觸及了組件的每個角落。

文獻管理的格式化陷阱

文獻管理功能，則是整個專案中最複雜的部分。學術引用有多種格式標準（APA、MLA、Chicago、Harvard等），每種格式都有嚴格的規範。Claude Code 幫我實作了一個 formatter.py 模組來處理不同的引用格式，每種格式都有對應的類別和格式化方法。

然而，一個看似無害的設計決策差點毀了整個功能：在格式化期刊名稱時，我使用了 Markdown 的斜體語法 *Journal Name*，希望在顯示時能呈現斜體效果。問題是，當用戶複製引用格式到 Word 或其他編輯器時，這些星號也被一併複製了，導致引用格式不符合標準。

這個 bug 的修復看似簡單——移除星號即可。但實際上我需要在六個不同的格式化方法中找出所有使用星號的地方，確保期刊名稱、書名與網站名稱等都使用純文字而非 Markdown 格式。這提醒了我一個重要的原則：資料的儲存格式應該與顯示格式分離。Markdown 應該只用於顯示層，而不應該滲透到資料層。

標籤系統的陣列與字串之爭

在待辦事項和筆記中，都有使用標籤功能。後端資料庫將標籤儲存為逗號分隔的字串（例如 "研究,論文,實驗"），但為了方便前端處理，我在 to_dict() 方法中將其轉換為陣列（例如 ["研究", "論文", "實驗"]）。

這個設計在大多數情況下運作良好，直到用戶嘗試編輯筆記。編輯表單期望 tags 是一個字串（因為 input 欄位只能接受字串），但從 API 獲取的筆記物件中 tags 是一個陣列。當我直接將陣列賦值給表單的 tags 欄位時，JavaScript 會隱式地將陣列轉換成字串，結果變成了 "研究,論文,實驗"——看起來沒問題，但當有空格時就會出現意外的行為。

最終的解決方案，是在 handleEdit 函數中明確地進行轉換：tags: Array.isArray(note.tags) ? note.tags.join(',') : (note.tags || '')。這行代碼確保無論後端返回的是陣列還是字串，都能正確地轉換成表單需要的格式。這個經驗告訴我，資料類型的一致性非常重要，在資料流轉的每個環節都需要明確定義期望的類型。

這篇文章 Vibe Coding 從零到部署： 30 個小時寫出一套學習儀表板（上）｜專家論點【鄭緯筌Vista】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

微軟正式為Office 365推出全新的「Agent模式」，將Anthropic的AI技術深度整合到Word、Excel、PowerPoint等大家常用的辦公軟體中，未來只需下簡單指令，這些工具就能像一位專業助理，自動幫你完成高難度的報告、試算表，甚至精美簡報，讓AI成為提升工作效率的得力幫手。記者鄧天心／綜合報導

微軟正式為Office 365推出全新的「Agent模式」，將Anthropic的AI技術深度整合到Word、Excel、PowerPoint等大家常用的辦公軟體中，未來只需下簡單指令，這些工具就能像一位專業助理，自動幫你完成高難度的報告、試算表，甚至精美簡報，讓AI成為提升工作效率的得力幫手。

現在，你用Word或Excel時，只要在Copilot聊天框輸入需求（例如「幫我做一份上季業績分析報表」），AI就能自動產生內容、整理格式，甚至一步步告訴你它怎麼做到的，就像有一位同事在旁邊帶著你完成任務。

PowerPoint也加入這項功能，只要你說出簡報主題，AI會自動上網找資料、設計版型，快速產出符合公司風格的投影片，解決過去AI簡報「美感不足」的痛點。

[caption id="attachment_193741" align="aligncenter" width="846"] 微軟正式為Office 365推出全新的「Agent模式」，將Anthropic的AI技術深度整合到Word、Excel、PowerPoint等大家常用的辦公軟體中。（圖／微軟YouTube）[/caption]

延伸閱讀：

OpenAI攻進電商大本營！推「即時下單功能」 劍指Amazon、Google

微軟這次不只是用自家的AI，還特別引進Anthropic的Claude模型，與原本的OpenAI技術並行運作。根據內部測試，Anthropic的模型在Excel複雜計算、簡報排版美感上表現甚至超越現有AI，用戶可以一次體驗不同AI的優勢，也能降低對單一技術的依賴。

傳統AI助手大多只能回答問題或產生文字，但「Agent模式」的AI更像「數位同事」，能主動拆解複雜任務、整合多來源資料，一步步完成你交代的工作。例如要寫一份董事會報告，AI會自動分階段產出內容、分析數據、設計簡報，大幅減少重複性操作，讓你有更多時間專注於決策和創意。

AI Agent就是能夠「獨立完成流程」的智慧助手。它不像ChatGPT只會聊天，而是能理解上下文、主動規劃步驟，甚至協調多個任務，像真人一樣為你分憂解勞。微軟加速導入這類技術，預估未來行政、財務、法律等重複性高的工作，都將逐漸由AI接手，「數位同事」時代已經來臨。

目前「Agent模式」已可在Word、Excel網頁版試用，PowerPoint版本也即將推出。實測顯示，AI在Excel的進階函數應用已達到一定水準，雖然準確率還不及人類專家，但已能幫助一般使用者跨越技術門檻，輕鬆完成專業等級的報表與簡報。當然，AI產出的品質仍需人工把關，但這種「人機協作」的新模式，確實讓辦公室生產力進入全新階段。

資料來源：The Verge、Microsoft 365 Blog

這篇文章 微軟讓你也能在Excel、PPT裡「Vibe Coding」 程度不輸大學實習生 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

AI程式輔助工具帶來效率，但也讓許多資深工程師直呼自己成了「AI保母」，Vibe Coding的新潮流，似乎正重新定義開發者的工作方式，《Fastly》的調查，800位受訪工程師中，95%表示會花額外時間修正AI程式碼，而這份工作主要落在資深工程師身上。記者鄧天心／綜合報導

Vibe Coding的新潮流，似乎正重新定義開發者的工作方式，AI程式輔助工具雖然提升效率，但也讓許多資深工程師直呼自己成了「AI保母」，《Fastly》的調查，800位受訪工程師中，95%表示會花額外時間修正AI程式碼，而這份工作主要落在資深工程師身上。

有15年從業經驗的網頁工程師Carla Rover曾因一次Vibe Coding有過不好的經驗，「我把它當成員工交辦，結果發現根本不是。」Rover形容，Vibe Coding就像是一張「無限延伸的餐巾紙」，方便不斷塗寫構想，但同時也可能帶來無預警的混亂，甚至比「照顧小孩更麻煩」，Rover曾發現AI模型在數據不符時，寧可生成看似合理的解釋，也不承認錯誤，一位資深工程主管Austin Spires，則形容Vibe Coding常為了快而忽略正確性，反而製造出初階漏洞。

[caption id="attachment_191917" align="aligncenter" width="1024"] Vibe Coding的新潮流，似乎正重新定義開發者的工作方式，AI程式輔助工具雖然提升效率，但也讓許多資深工程師直呼自己成了「AI保母」。（圖／AI生成）[/caption]

延伸閱讀：

超越Photoshop！Google靠Nano Banana衝上App Store冠軍

另一位擁有逾20年經驗的工程師Feridoon Malekzadeh則更直白，把Vibe Coding比喻成「雇用一個叛逆的青少年」，他估計自己50%的時間花在寫需求，只有10%到20%真正用在Vibe Coding，卻要再花30%到40%在「Vibe Fixing」，修復AI程式帶來的錯誤與冗餘代碼。

科技業並非完全否定Vibe Coding，資安公司NinjaOne技術長Mike Arrowsmith指出，他們推動「安全Vibe Coding」，包括限制AI工具存取權限、強制同儕審查與安全掃描，以降低風險。

對於許多工程師而言，AI工具仍在原型設計、快速搭建測試環境或減少重複工作上提供巨大幫助，讓開發流程更有效率，Rover表示，這使她能更快打造使用者介面；Malekzadeh也承認，即便修復時間增加，整體產能依舊優於沒有AI協助時。

接受《Fastly》工程師Elvis Kimara更將之視為未來常態，他認為工程師的角色將轉變為「AI系統導師」，在審查與修正中承擔責任，同時加速學習，一方面，Vibe Coding成為快速實驗與創業加速的利器；另一方面，它也推高了「人工審查成本」，甚至改變了團隊文化與新手工程師的學習方式。

Vibe Coding讓工程師花更多時間審查與修補AI程式碼，但在效率與風險之間，似乎更多人選擇繼續花這個時間。

資料來源：Techcrunch

這篇文章 Vibe Coding正夯！但工程師們卻說：我們都在幫AI擦屁股 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

住在松山區的林雅惠，是一間 50 人規模的設計公司的行政主管。那是一個平凡的週一早晨，她如往常般整理著員工的出勤記錄。桌上散落著各種請假條、遲到說明單，還有幾張手寫的加班申請。她需要把這些紙本資料一一輸入 Excel，計算工時，核對薪資。這個看似簡單的過程，卻要花費她整個上午的時間。作者：鄭緯筌（專欄作家，「臺灣電子商務暨創業聯誼會」共同創辦人，前「APP01」網站總監、《風傳媒》產品總監和《數位時代》雜誌主編）

延續 vibe coding 的教學，接下來讓我用一個實際案例來說明：

住在松山區的林雅惠，是一間 50 人規模的設計公司的行政主管。那是一個平凡的週一早晨，她如往常般整理著員工的出勤記錄。桌上散落著各種請假條、遲到說明單，還有幾張手寫的加班申請。她需要把這些紙本資料一一輸入 Excel，計算工時，核對薪資。這個看似簡單的過程，卻要花費她整個上午的時間。

就在她第五次重新計算張設計師的加班時數時，鄰座的 IT 維護同事文德隨口說了一句話改變了一切。「現在很多公司都用線上打卡系統了，聽說有些工具可以不用寫程式就能做出來。」林雅惠停下手中的計算機，第一次認真思考：是呀，為什麼我們不能有一個更現代化的解決方案？

文德無心的一句話，讓這個念頭在她心中發酵。她開始觀察公司的實際需求：設計師們經常需要外出拜訪客戶，傳統的實體打卡機根本不適用；創意工作者的時間彈性很大，需要更靈活的考勤制度；主管們希望能即時掌握專案人力配置；財務部門需要準確的工時數據來計算薪資。這些需求交織在一起，形成了一幅清晰的藍圖。

經過一週的猶豫，林雅惠終於鼓起勇氣造訪了 Lovable 平臺。她的第一印象是困惑：這個看起來像聊天室的介面，真的能幫她建立一套完整的系統嗎？抱著試試看的心態，她開始用最直白的語言描述自己的想法。

她在對話框中輸入：「我想要做一個員工打卡系統。我們公司有設計師、業務、行政人員，大家的工作模式都不太一樣。設計師可能在家工作或外出見客戶，需要用手機打卡。業務也常常在外面跑，也需要手機打卡。行政人員大部分時間在辦公室，但有時候也會外出採購或開會。我希望系統能知道大家在哪裡打卡，也能讓主管看到團隊的出勤狀況。」

Lovable的回應，讓她大吃一驚。平臺不僅理解了她的需求，還進一步詢問了許多她沒想到的細節：「您希望系統支援不同的工作時段嗎？比如有些員工是彈性工時？」「需要整合GPS定位來確認打卡地點嗎？」「您希望主管能即時收到異常狀況的通知嗎？」這些問題讓林雅惠意識到，一個好的系統需要考慮的層面比她想像的還要複雜。

[caption id="attachment_190987" align="aligncenter" width="1062"] 一個好的系統需要考慮的層面比想像的還要複雜。（圖／鄭緯筌提供）[/caption]

讓我們詳細看看林雅惠與Lovable的具體對話過程。她輸入第一個明確的需求：

「我想做一個手機打卡的 App。員工打開後可以看到大大的『上班打卡』和『下班打卡』按鈕。按下去後要記錄時間、地點，還要能拍照證明在現場。主管要能看到所有人的打卡記錄。」

Lovable 立即回應：「我理解您的需求。讓我為您建立一個打卡系統，包含以下功能：員工打卡介面、GPS定位記錄、相片上傳、主管查看後臺。請問您希望設定固定的上下班時間嗎？比如早上 9 點上班，下午 6 點下班嗎？」

林雅惠想了想：「我們公司比較彈性，設計師可能 10 點才到，業務可能很早就出門拜訪客戶。但我希望系統能知道誰遲到了，可以設定每個人不同的標準時間嗎？」

「當然可以！」Lovable回答，「我會設計一個個人化時間表功能。您可以為每位員工設定不同的標準工時。現在讓我先建立基礎版本給您測試。」

幾分鐘後，螢幕上出現了一個簡潔的打卡介面。主畫面有兩個大按鈕：「上班打卡」和「下班打卡」，下方顯示當前時間和位置資訊。林雅惠點擊「上班打卡」，系統立即要求定位權限，並開啟相機讓她拍照。

測試後，林雅惠發現了一個問題：「這樣員工不是在哪裡都能打卡嗎？我希望只有在公司附近才能打卡，或者在客戶那邊打卡時要特別註明。」

她繼續與Lovable對話：「我想要加入地理圍欄功能。公司地址是臺北市信義區忠孝東路五段XX號，半徑兩百公尺內算正常打卡。如果在其他地方打卡，要讓員工選擇原因：客戶拜訪、外部會議，或是居家辦公等等。」

Lovable很快理解了需求：「我會建立地理圍欄系統。當員工在公司範圍內打卡時，會顯示『公司打卡』；在範圍外時，會跳出選項讓他們選擇打卡類型。同時我會記錄 GPS 座標，主管可以在地圖上看到打卡位置。」

[caption id="attachment_190989" align="aligncenter" width="1061"] Lovable很快理解了需求。（圖／鄭緯筌提供）[/caption]

更新後的系統，變得更加聰明了。林雅惠在辦公室測試時，系統顯示「公司內打卡」並且是綠色標示；當她走到樓下三百公尺遠的咖啡廳測試時，螢幕跳出選項：「客戶拜訪」、「外部會議」、「居家辦公」或「其他」，選擇後還能填寫詳細說明。

接下來，林雅惠需要建立主管查看的介面。她對 Lovable 說：「現在我需要一個主管用的後臺。要能看到今天誰已經打卡、誰還沒到、誰在外面工作。最好有一個即時的儀表板，可以快速掌握團隊狀況。」

「我會設計三個主要頁面，」Lovable 回應：「即時狀態頁面顯示所有員工當前狀況，出勤記錄頁面可以查看歷史資料，異常情況頁面會特別標示遲到、早退、異地打卡等需要注意的情況。您希望有推播通知功能嗎？」

林雅惠興奮地說：「太好了！推播通知很重要。如果有人遲到超過 30 分鐘，或者在奇怪的地點打卡，希望能立即通知相關主管。」

實現後的主管介面，讓林雅惠感到驚豔。首頁是一個清晰的儀表板，用不同顏色顯示員工狀態：綠色表示正常上班，藍色表示外勤，紅色表示遲到，灰色表示尚未打卡。點擊任何一個員工頭像，就能看到詳細的打卡記錄、GPS 位置和照片。

使用了一週後，設計總監提出了新需求。林雅惠將這個回饋帶給 Lovable：「我們發現打卡系統很好用，但希望能進一步追蹤專案時間。當員工打卡時，可以選擇正在進行的專案，這樣我們就能知道每個專案花了多少人力。」

[caption id="attachment_191026" align="aligncenter" width="1062"] 當員工打卡時，可以選擇正在進行的專案，這樣我們就能知道每個專案花了多少人力。（圖／鄭緯筌提供）[/caption]

「嗯，這是個很好的建議！」Lovable 回應，「我可以在打卡流程中加入專案選擇功能。您需要先建立專案清單，然後員工打卡時就能選擇。系統會自動計算每個專案的工時分配。」

林雅惠繼續細化需求：「我們通常同時進行 5-8 個專案。希望員工可以在上班打卡時選擇今天主要做哪個專案，如果中途換專案，可以隨時切換。系統要能顯示，每個專案今天投入了多少人時？」

更新後的系統，在打卡頁面增加了專案選單。員工上班打卡後，會看到目前進行中的專案列表，可以選擇今天的主要工作。如果需要切換專案，只要點選「切換專案」按鈕，選擇新專案即可。系統會自動計算每段時間分配給不同專案的工時。

實際使用中，林雅惠發現還需要處理各種特殊情況。她對 Lovable 解釋：「有時候員工會忘記打卡，或者手機沒電，或者系統當機。我們需要補打卡機制，但要有主管核准流程，避免濫用。」

「我理解，」Lovable回應，「我會增加補打卡申請功能。員工可以申請補打卡，說明原因，上傳相關證明（如會議擷圖、客戶合照等），然後送交主管審核。審核通過後，系統會自動補上打卡記錄。」

此外，林雅惠還想到其他需求：「有些員工是部分工時，有些是專案約聘，工時計算方式不一樣。系統能處理這些不同的雇用型態嗎？」

Lovable提供了完整的解決方案：「我會建立員工類型管理功能。您可以設定不同的工時規則：全職員工、部分工時、專案約聘、實習生等等。每種類型都有不同的工時計算方式、加班規則和假期制度。」

系統執行一個月後，老闆想要看數據報告。林雅惠詢問 Lovable：「我需要產生各種報表：每日出勤統計、每週工時報告、專案時間分配和異常狀況彙總。最好能自動產生，定期 E-mail 給相關主管。」

「沒問題！」Lovable 回應，「我會建立完整的報表系統。包含即時儀表板、自定義報表生成器、自動排程寄送功能。您可以設定每日、每週、每月的固定報表，系統會自動生成並寄給指定收件人。」

實現後的報表功能，讓林雅惠非常滿意。這套系統提供了豐富的圖表：出勤率趨勢圖、專案工時分配圓餅圖、部門加班統計長條圖、異常打卡地點分布地圖等等。更重要的是，所有報表都能匯出 Excel 或 PDF 格式，方便後續分析和存檔。

有了成功的基礎系統，林雅惠開始更深入地思考公司的實際需求。她花了一週時間訪談各部門同事，發現了許多隱藏的痛點。好比設計總監希望能追蹤專案時間，業務經理想要了解客戶拜訪頻率，財務主管需要準確的加班統計，甚至連清潔阿姨都希望能有彈性的工時安排。

基於這些洞察，林雅惠回到 Lovable 平臺，開始了系統的深度擴展。她學會了更精確地表達想法：「我想要在現有打卡系統的基礎上，整合請假管理、加班申請與專案排程等功能。希望員工可以在同一個平臺上處理所有人事相關事務，主管可以在統一的儀表板上掌握團隊狀況。」

Lovable 對這個複雜需求的回應，讓林雅惠再次震驚。平臺不只是簡單地堆疊功能，而是設計了一個有機的生態系統。各個模組之間的數據流動自然順暢，使用者介面保持一致性，權限管理涵蓋所有功能，報表系統提供跨模組的深度分析。

更令人印象深刻的是，Lovable 還主動建議了一些她沒想到的功能，像是：員工滿意度追蹤、智能排班建議、成本預警系統以及自動化工作流程等等。這些建議都基於對現有數據的分析，展現了 AI 在系統設計上的深度思考能力。

隨著系統功能愈來愈豐富，林雅惠面臨一個新的挑戰：如何讓所有同事都能順利使用這套系統？特別是一些年紀較大或對科技較不熟悉的同事，她擔心他們會抗拒改變。

她決定採用循序漸進的推廣策略。首先，她請 Lovable 協助製作了一系列教學影片，用最簡單的語言解釋每個功能的操作方式。接著，她在公司內部舉辦了數位午餐會，在輕鬆的氛圍中讓同事們體驗新系統。最重要的是，她建立了內部種子用戶群組，由技術接受度較高的同事協助解答其他人的問題。

這個推廣的過程，讓林雅惠學到了技術推廣的重要一課：再好的系統，如果沒有考慮使用者的接受度和學習曲線，都可能面臨失敗。她開始更加重視使用者體驗，不只是功能的完整性，更關注操作的直觀性和學習的容易度。

經過三個月的努力，公司的數位轉型成果超出了所有人的預期。不只是工作效率的提升，更重要的是團隊文化的改變。同事們開始主動提出改進建議，跨部門協作變得更加順暢，數據驅動的決策成為新常態。

系統上線半年後，林雅惠協助公司數位轉型的故事在業界傳開了。其他公司開始邀請她分享 vibe coding 的經驗，她也受邀參加各種科技論壇和管理研習會。更令她驚訝的是，公司決定提拔她，專責公司的科技創新和流程優化。

這個轉變讓林雅惠深深感受到 vibe coding 的力量。她沒有學會複雜的程式語言，沒有花費大量時間研讀技術文件，但她學會了最重要的技能：如何將業務需求轉化為技術解決方案，如何與 AI 工具協作創造價值，如何推動組織的數位轉型。

現在，林雅惠經常對其他想要嘗試 vibe coding 的朋友說：「技術只是工具，重要的是你對問題的理解和解決問題的決心。當你開始用創造者的心態面對工作中的挑戰時，你會發現自己擁有比想像中更強大的力量。」

林雅惠的成功不只在於功能的實現，更在於她對系統落地部署的深度思考。在正式推廣前，她與 Lovable 深入討論了許多技術細節，雖然她不需要親自處理這些技術問題，但她需要理解這些決策對公司營運的影響。

資訊安全，可以說是她最關心的議題。像是公司的出勤資料、薪資資訊與專案數據都是敏感資訊，必須確保系統有足夠的安全防護。Lovable 為她解釋了資料加密、權限控制與備份機制等安全措施，並協助她制定了資料使用政策和緊急應變流程。

系統的可擴展性，則是另一個重要考量。隨著公司成長，員工人數可能增加，業務複雜度可能提升，系統必須能夠應對這些變化。Lovable 設計的架構具有良好的擴展能力，可以在不影響現有功能的前提下，持續增加新的模組和功能。

最關鍵的是系統的穩定性和維護。林雅惠了解到，再好的系統如果經常當機或出現錯誤，都會嚴重影響公司營運。Lovable 提供了完整的監控和維護服務，確保系統 7x24 小時穩定運行，並在出現問題時能夠快速響應和修復。

回顧整個旅程，林雅惠最深的感悟是 vibe coding 帶來的不只是技術能力，更是思維方式的根本轉變。她從一個被動的問題承受者，變成了主動的解決方案創造者。這種轉變的影響遠遠超出了工作範疇，延伸到她生活的各個層面。

當她面對任何挑戰時，她會自然地思考：這個問題可以用什麼工具來解決？有沒有更自動化的方式？能不能設計一個系統來優化這個流程？這種「系統思維」讓她在處理複雜問題時變得更加有條理和高效。

更重要的是，她學會了與 AI 協作的藝術。不是被動地接受 AI 的建議，而是主動地引導 AI 理解自己的需求，將 AI 當作一個智能的合作夥伴，而不是單純的工具。這種合作模式讓她能夠實現遠超個人能力的成果。

透過林雅惠的案例，我想對其他想要嘗試 vibe coding 的職場人士提出幾點建議：

1. 從真實痛點開始。不要為了學技術而學技術，而要從工作中的實際問題出發。當你有了明確的目標，學習的動力和方向都會更清晰。
2. 勇敢開始，不怕犯錯。最大的障礙往往是心理上的恐懼。記住，現代的 AI 工具已經大幅降低技術門檻，你不需要成為程式設計專家也能創造有價值的解決方案。
3. 重視使用者體驗。技術只是手段，真正的目標是解決人的問題。在設計任何系統時，都要優先考慮使用者的感受和需求。
4. 持續學習和迭代。第一版系統一定不會完美，重要的是保持開放的心態，根據使用者回饋持續改進。
5. 分享和交流。加入相關的社群，與其他同好交流經驗。你會發現，每個人都有獨特的見解和解決方案，這些交流將會豐富你的視野。

林雅惠的故事告訴我們，在 AI 時代，每個職場人士都有可能成為數位創新者。關鍵不在於你有多少技術背景，而在於你是否願意擁抱變化，用創造者的心態面對挑戰。當技術門檻被 AI 工具大幅降低時，創意和問題解決能力成為了最寶貴的資產。

這個完整的旅程，展現了 vibe coding 的真正力量：它不只是一種學習方式，更是一種思維模式的轉變。它讓每個人都能用自己的語言與機器對話，用自己的創意改變世界。而這，正是數位時代最激動人心的可能性。

這篇文章 重新定義程式設計：職場人士的 Vibe Coding 自學指南（下）｜專家論點【鄭緯筌Vista】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

當夕陽西下，你坐在咖啡廳裡，手指在鍵盤上輕盈跳躍，螢幕上的程式碼如詩句般地流淌。儘管你不是資工系畢業的工程師，也沒有十年的技術背景，但此刻，你正在創造屬於自己的數位作品。這就是 vibe coding 的魅力——它不要求你成為技術專家，只需要你跟隨內心的直覺，就可以讓程式設計成為表達創意的媒介。作者：鄭緯筌（專欄作家，「臺灣電子商務暨創業聯誼會」共同創辦人，前「APP01」網站總監、《風傳媒》產品總監和《數位時代》雜誌主編）

當夕陽西下，你坐在咖啡廳裡，手指在鍵盤上輕盈跳躍，螢幕上的程式碼如詩句般地流淌。儘管你不是資工系畢業的工程師，也沒有十年的技術背景，但此刻，你正在創造屬於自己的數位作品。這就是 vibe coding 的魅力——它不要求你成為技術專家，只需要你跟隨內心的直覺，就可以讓程式設計成為表達創意的媒介。

傳統的程式設計教育需要花費不少時間，總是強調嚴謹的邏輯、複雜的演算法，以及看似深不可測的技術理論。然而，vibe coding 打破了這些框架，它相信程式設計可以像寫作、繪畫一樣，成為一種直觀的創作形式。這種方法特別適合那些在職場中需要解決實際問題，但沒有時間深入學習傳統程式設計的專業人士。

[caption id="attachment_190913" align="aligncenter" width="1063"] vibe coding定義。（圖／鄭緯筌提供）[/caption]

想像一下，你是一位行銷專員，每天需要處理大量的數據分析工作。與其依賴複雜的 Excel 公式或等待 IT 部門的支援，如果你可以用幾行簡單的程式碼，自動化這些重複性的工作，那不是很棒嗎？或者你是一位設計師，希望創造一個互動性的作品集網站，現在不需要學習複雜的框架，只需要跟隨你的美學直覺，就可以一步步建構出令人驚豔的作品！

vibe coding 的核心理念，在於直覺驅動和做中學。它不要求你預先掌握所有的理論知識，而是鼓勵你在實作過程中，透過試錯和探索來學習。這種方法特別符合成年人的學習特性，因為我們更傾向於解決具體問題，而非抽象的概念學習。

許多職場人士對程式設計抱持著敬而遠之的態度，認為那是天才或理工科系背景的人才能掌握的技能。這種心理障礙，往往是學習路上最大的絆腳石。vibe coding 的第一課，就是要幫助你重新定義與程式設計的關係。

延伸閱讀：把AI變成你的第二大腦：打造亮眼的個人品牌｜專家論點【鄭緯筌Vista】

老實說，程式設計並不是數學考試，沒有標準答案，也不需要完美的邏輯推理。它更像是一種對話：當你向電腦描述你想要完成的任務，電腦則透過執行程式碼來回應你的想法。在這個過程中，發生錯誤是很正常的，甚至是必要的。要知道，每一個bug都是學習的機會，而每一次除錯都是技能的累積。

當你開始將程式設計視為一種創作工具，而非技術考驗時，學習的焦慮自然會轉化為探索的好奇。你會赫然發現，寫程式時的那種專注狀態，與你在進行其他創作活動時的心流體驗非常相似。時間彷彿靜止，思緒清晰，每一個功能的實現都帶來成就感。

當然，這種心理轉換需要時間和練習。建議你從最小的專案開始，比如製作一個簡單的個人網頁，或者寫一個自動整理檔案的小程式。不要追求完美，而是享受過程中的每一個小發現。當你看到自己的程式碼第一次成功執行時，那種喜悅會深深地印在腦海的記憶中，成為繼續學習的動力。

選擇適合的工具，對於 vibe coding 的成功來說很重要。與傳統程式設計教育強調從底層開始學習不同，vibe coding 鼓勵使用那些能夠快速看到成果的工具和語言。這些工具的共同特點是學習曲線平緩、即時回饋明顯，以及擁有豐富的社群資源。

對於想要創建網站或網頁應用的學習者，HTML、CSS 和 JavaScript 是最理想的起點。這個組合被稱為前端開發的「黃金三角」，但在 vibe coding 的框架下，你不需要深入理解它們的技術細節。HTML 就像是房屋的骨架，CSS 是房屋的裝潢，JavaScript 則是賦予房屋生命力的電器系統。你可以從模仿優秀的設計開始，逐漸理解每個元素的作用。

如果你更傾向於數據處理和自動化，Python 是不二選擇。它的語法接近自然語言，即使是初學者也能快速上手。想像你需要處理每月的銷售報告，傳統方法可能需要花費數小時在 Excel 中手動操作，但用 Python 寫一個簡單的腳本，幾分鐘就能完成相同的工作，而且可以重複使用。

開發環境的選擇，也同樣重要。Visual Studio Code 是目前最受歡迎的程式編輯器，它免費、輕量，且擁有豐富的插件生態。對於初學者來說，它的智能提示功能就像是一位耐心的導師，會在你輸入程式碼時提供建議和修正。另外，像是 CodePen、Repl.it 或 Glitch 等線上程式設計平臺也是絕佳的選擇，它們讓你可以直接在瀏覽器中設計程式，無需複雜的環境配置。

[caption id="attachment_190914" align="aligncenter" width="1056"] 推薦工具快速導覽。（圖／鄭緯筌提供）[/caption]

請謹記，工具只是媒介，真正的魔法在於你的創意和想像力。不要被工具的複雜性嚇倒，也不要過分糾結於選擇。先選一個順眼的工具開始動手，在實作過程中你自然會找到最適合自己的工具組合。

vibe coding 的一個重要原則，是從模仿開始。這與許多人對創新的理解可能相衝突，但實際上，模仿是所有創作領域的基礎學習方法。畫家臨摹大師的作品，作家研讀經典的文本，音樂家演奏前人的曲目。在程式設計領域，閱讀和修改優秀的程式碼同樣是快速進步的途徑。

坊間的某些開源社群，為 vibe coding 學習者提供了豐富的學習資源。舉例來說，GitHub 上有成千上萬的專案，從簡單的個人網站到複雜的應用程式，你都可以自由下載、研究和修改。選擇一個你感興趣且複雜度適中的專案，嘗試理解它的結構和邏輯，然後根據自己的需求進行修改。

這個過程就像是拆解一個精美的鐘錶，然後重新組裝。你不需要理解每個零件的製造工藝，但你會逐漸明白它們是如何協同工作的。在修改的過程中，你會學到新的程式設計技巧，理解不同的解決方案，更重要的是，培養出對程式碼結構和設計模式的直覺。

隨著經驗的累積，你會慢慢發現自己不再滿足於純粹的模仿。你開始有了自己的想法，想要實現一些與眾不同的功能。這就是從模仿走向創新的轉折點。也許你在原有的相片展示網站基礎上，加入了地圖顯示功能，讓訪客可以看到每張照片的拍攝地點。或者你在數據處理腳本中，加入了視覺化圖表，讓分析結果更加直觀。

這些小的創新看似微不足道，但它們代表著你已經從被動的學習者，轉變為主動的創作者。你開始用程式設計來解決實際問題，表達個人想法，這正是 vibe coding 的最終目標。

這篇文章 重新定義程式設計：職場人士的 Vibe Coding 自學指南（上）｜專家論點【鄭緯筌Vista】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

談到心電感應科技（FlyiDEA）的創立，創辦人洪璿岳笑稱這承襲了上一間以「知識轉譯與系統化」公司讓狂人飛的血統。記者孫敬／台北報導

談到心電感應科技（FlyiDEA）的創立過程，創辦人洪璿岳笑稱這承襲了上一間以「知識轉譯與系統化」公司讓狂人飛的血統，隨後踏入貝殼放大、緯創又跳出來創業的他，對這些工作經歷言語中充滿感謝，因為這段時間的歷練，不僅僅幫助心電感應科技找到商業模式，也發現了AI技術、免程式碼開發工具No Code商業化的機會。隨著AI時代的來臨，微型創業與小團隊作戰的結構越趨多元，新時代的創業家一樣得走募資、上市、收購的老路，還是以小步快跑，吃下市場被忽略的隱性需求，成為一方獨霸？

延伸閱讀：AI論壇／數發部黃雅萍：算力、人才、資金支持已逐步上線

[caption id="attachment_175090" align="aligncenter" width="1477"] 洪璿岳Bubble開發介面，沒有複雜的程式碼。（圖／洪璿岳提供）[/caption]

Vibe Coding與No Code：開發革命的加速器

細細拆解心電感應科技的結構，洪璿岳分享，在歷經品牌重塑與服務方向的蛻變後，現在公司重新誕生為聚焦於MVP開發、No Code工具導入與AI解決方案的新創公司。從心電感應科技近期上線的線上會議預約工具「Timeet喬時通」，以及業務交流專用的「RiiCH人脈通」Beta版App，會發現其共同點為「直觀且簡單易用」，沒有花俏難懂的設計，第一次操作便能滿足使用者需求，而這背後蘊含著深厚的Vibe Coding與No Code開發精神。

當我們進一步好奇這些工具是如何誕生時，洪璿岳先是喊出類似「開蓋即用」，還有「兩週挑戰MVP」的開發精神，並點出Vibe Coding與No Code工具正逐漸改變軟體開發的門檻與方式。以往想創業做SaaS或AI應用，總得先找到一位技術強悍的合作夥伴、募資燒一波錢、再花上幾個月才能做出第一版產品，但現在的情況改變了，透過Bubble、Retool等No Code工具，搭配ChatGPT等AI coding助手，開發流程可以大幅簡化、加速。

[caption id="attachment_175093" align="aligncenter" width="2048"] 洪璿岳Bubble開發介面，沒有複雜的程式碼。（圖／洪璿岳提供）[/caption]

從對話中難掩自信的洪璿岳提到，目前已有不少非工程背景的創業者，透過這些工具構築自動化流程、設計出可運作的產品，甚至形成SaaS模式販售。No Code的可視化邏輯，讓不懂程式的人也能理解與掌握自己的產品架構，進而學習與維運，大幅降低創業門檻。

但這代表專精技術開發的工程師就失去價值了嗎？如果是對於需要處理百萬級使用者的大型系統來說，AI輔助與No Code的架構目前尚未完全取代傳統開發的穩定性與擴充彈性。反觀若產品目標是穩定變現、精準服務特定族群，No Code則成為極具性價比的開發方式。

小型AI解決方案公司：精準擊中需求的未來模式

雖然有很好的想法跟應用工具，但沒有適合的情境跟商業模式，究竟難維持一間公司的營運，「我發現如會計師、地政士這類小眾族群，因為市場不夠大，以致於他們在AI時代下，成為被忽略的族群。」洪璿岳點出了他不打傳統AI解決方案的大眾紅海市場，而是走向「中小型且有特定專業需求」的新藍海，並以自身經驗觀察，未來的商業模式將朝向「小型化」、「模組化」、「即時服務」。

「未來的軟體創業，可能不是打造一間一百億的公司，而是一百間一億的公司。」為特定族群解決實際問題的小公司，洪璿岳表示，這些被大公司忽略的潛在需求，反而因為利基明確，在AI時代下更能成為高客製化與高價值解決方案的新天地。

此外，這類結合AI跟No Code精神的小公司，因為運作精實、開發成本低、服務彈性大，更能夠迅速迭代、貼近使用者需求。洪璿岳以心電感應科技的「外包CTO」模式為例，提供從MVP到產品上線、甚至持續維運與更新的全方位技術合作，大幅降低合作夥伴的開發與技術負擔，並讓這些非工程背景的創業者也能有效啟動自己的數位產品。

[caption id="attachment_175092" align="aligncenter" width="1920"] Timeet喬時通可讓使用者在個人的Line完成會議預約，串接至Google行事曆。（圖／洪璿岳提供）[/caption]

這篇文章 不募資、沒有上市壓力 洪璿岳如何從No Code開啟微型創業藍海市場？ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。