👾 Hi, 我是 Bevis 👾

不久前，一位朋友得知我具備程式開發能力，便詢問能否協助建置一個簡易的會員系統以簡化內部流程。基於其需求，我以 Python 開發後端、Google Sheet 作為資料庫，並搭配 Streamlit 建構前端介面，打造了一套輕量化且可免費部署的會員管理系統，作為內部工具使用已相當足夠。 目錄 相關連結 需求確認 技術選型 資料庫 資料表 系統功能 服務部署 結語 相關連結 GitHub Streamlit（試用） 專案起因 甫結束轉職培訓班的課程不久，一位經營獨立健身工作室的朋友得知我在學習程式開發，便詢問是否能協助開發一套內部使用的會員管理系統。在評估過對方的需求與我目前的能力後，認為這是一個不錯的實戰機會，於是便開啟了這個輕量化會員管理系統的專案。 需求確認 本專案屬於客製化委託，因此所有的技術選擇與開發方向皆需緊扣客戶（對方）的需求。以下為客戶的背景與具體需求： 無技術背景：團隊內無技術開發人員，原先僅使用 Excel 或雲端試算表進行紀錄。 內部使用：系統僅供員工內部紀錄，不對外開放給會員使用。 核心功能：需包含會員登記、交易行為記錄、金額結算等基本功能。 低維運成本：屬於試驗性質的專案，維運方面並無多餘預算。 技術選型 基於上述需求，我為專案規劃了以下的基本架構： 後端：Python 我目前最熟悉的程式語言，擁有豐富的套件支援。 資料庫：Excel 或 Google Sheet 這是客戶團隊最熟悉的工具。即便系統發生意外，他們仍能直接開啟檔案進行編輯與修正。 操作彈性：即使因操作失誤導致系統報錯，客戶也能手動修正資料，保持營運彈性。 合適優於完美：作為資料工程人員，我深知試算表並非正規的資料庫。但考量客戶缺乏 SQL 操作能力，選擇正規資料庫反而可能因技術門檻造成額外困擾。在此情境下，選擇合適的工具比追求技術上的完美更為恰當。 前端：Streamlit 目前最輕量、易於開發與部署的 Python 前端框架。作為內部工具，其功能與介面質感已相當足夠。 部署：地端或低價（免費）雲端平台 考量客戶幾無維運預算，且應用場景多為上班時間的辦公室環境，將系統建置於地端或免費的雲端服務（PaaS）是較合理的選擇。 資料庫 雖然透過 Python 程式能靈活地調整功能，但資料庫作為系統的核心，承載了客戶最重要的資產。因此，資料庫的建置與規劃應在初期就定案，避免後續修改牽一髮而動全身，增加維護成本。 地端資料庫 由於客戶習慣使用 Excel 記錄，開發初期我優先採用地端檔案作為資料庫。針對此專案性質，地端部署有其合理性： 使用時間固定：僅在營業時間使用，無需 24 小時運作。 安全性考量：因無專職人員維護，非使用時間關閉資料庫，反而能物理性地避免未授權的修改。 我採用以下邏輯建立資料庫連線： 在專案目錄中建立 Excel 檔，並設定檔名。 將檔名設為全域常數，透過函式在專案目錄中搜尋，進行路徑定位。 取得絕對路徑後讀取檔案。 Fitness-Studio-Member-System/ ├── codes/ # 集中存放程式碼 │ ├── mod/ # 存放模組化程式 │ └── main.py # 測試用主程式 ├── database.xlsx # 地端資料庫 (Excel 檔案) ├── streamlit_app.py # Streamlit 主程式入口 ├── requirements.txt # 專案依賴套件清單 └── README.md # 專案說明文件 此設計的考量點在於：

作為第一個經過完整開發流程的專案，我已經撰寫兩篇文章說明專案的特點與開發遇到的困難與挑戰。最後我想更細節的分享這個專案的各個環節，我們所做的決定和一些細節。我想這篇文章會更偏向「紀錄」，所以並未有太多的技術價值，但若你正好有需要可以作為參考。 目錄 相關連結 概述 專案選題 資料爬蟲 資料庫 資料表 ETL/ELT流程 自動化 雲端部署 資料分析與視覺化 相關連結 GitHub Tableau Dashboard 01 Tableau Dashboard 02 概述 本專案（相關閱讀：《六都寵物資源分析開發實錄》、困難與挑戰）旨在透過蒐集六都寵物店家資訊，分析資源分布與商業潛力，並以視覺化儀表板呈現。 作為一個 End-to-End 的資料工程專案，我們建立了一套自動化的 Data Pipeline，涵蓋爬蟲、ETL、資料倉儲、分析到視覺化。 技術棧 領域 工具/技術 用途 資料獲取 Python Script, Google Maps API 網站爬蟲與 API 串接 ETL/ELT Python (Pandas) 資料清洗、轉換與格式化 資料庫 MySQL (GCP Cloud SQL/VM) 關聯式資料庫儲存 自動化排程 Apache Airflow 工作流調度與監控 雲端 & DevOps GCP (Compute Engine), Docker 雲端基礎設施與容器化部署 CI/CD GitHub Actions 自動化部署 BI 視覺化 Tableau 互動式儀表板製作

在學習資料工程的過程中，雖然沒有特別區分，但從講師的敘述和某些技術中，隱隱可以察覺「大數據」和一般的資料工程是有區隔的，不單單只是「資料變多」而已。所以雖然不在課程內，但我另外又搜尋了一些與大數據有關的資料，包括大數據下的資料庫設計、大數據下的資料工程等。除了分享也作為筆記，讓自己可以重複複習關於大數據的相關知識。 目錄 簡介 資料庫設計模型 大數據的資料工程：反正規化與效能優化 大數據的資料檢驗工程 結語 簡介 在軟體工程的世界裡，資料庫往往是系統的瓶頸所在。當資料規模從 GB 成長至 TB 甚至 PB 等級，我們面臨的不僅是儲存空間的挑戰，更是計算能力的典範轉移 (Paradigm Shift)。 1. 大數據的特殊性 (Volume, Velocity, Variety) 傳統單機資料庫（RDBMS）依賴 Vertical Scaling (Scale-up)，透過升級 CPU 和記憶體來提升效能。然而，硬體升級有其物理極限。大數據架構的核心在於 Horizontal Scaling (Scale-out)，利用數百甚至數千台商用伺服器組成叢集，共同處理龐大的資料集。 2. 分散式架構的本質 在大數據領域（如 Hadoop 生態系、Spark、Cloud Data Warehouses），我們遵循 「分而治之 (Divide and Conquer)」 的哲學： 儲存與計算分離 (Storage-Compute Separation)：現代架構傾向將資料存在物件儲存（如 S3, GCS, HDFS），計算資源（如 Spark Executors）則是動態調配的。 移動計算而非移動數據：由於網路 I/O 是最大的效能瓶頸，我們盡可能將程式碼派發到存放資料的節點上執行，而非將資料拉回中心節點處理。 資料庫設計模型 理解資料模型的適用場景，是架構師進行技術選型（Tech Stack Selection）的第一步。 1. 一般資料庫模型 (General Purpose / OLTP) 這些模型通常應用於應用程式後端，強調交易的即時性與一致性。 Relational Model (RDBMS) 代表：MySQL, PostgreSQL, Oracle。 特性：嚴格 Schema、ACID 交易保證、使用 SQL。 適用：核心業務系統（Core Banking, ERP），資料一致性要求極高的場景。 Document Model 代表：MongoDB。 特性：Schema-less (BSON/JSON)、支援巢狀結構、開發迭代快。 適用：內容管理系統 (CMS)、產品目錄 (Catalog)、屬性高度動態的資料。 Key-Value Model 代表：Redis, DynamoDB。 特性：Hash Table 結構、O(1) 讀寫延遲。 適用：快取 (Cache)、Session Store、高併發計數器。 Graph Model 代表：Neo4j。 特性：以節點 (Node) 與邊 (Edge) 儲存關係，解決遞迴查詢效能問題。 適用：社交網絡分析、推薦引擎、路徑演算法。 2. 大數據與資料倉儲模型 (Analytical / OLAP) 當場景轉向數據分析時，寫入效能不再是首要考量，查詢吞吐量 (Throughput) 與 歷史資料整合 才是重點。

隨著Gemini 3 Pro及相關應用工具Google AI Studio和Antigravity發表，vibe coding似乎又突然火熱起來。強大的功能導致「工程師是否會被AI取代」的議題又再次熱絡起來，AI究竟是工具還是凶器？都能vibe coding還需要學寫code嗎？作為新進工程師，是怎麼看待AI工具呢？ 目錄 AI之於學習 AI之於開發 Vibe Coding 個人經驗 結語 AI之於學習 如果你決定開始學寫程式，我強烈推薦使用AI工具，但務必注意使用方式。 益處 AI在程式開發領域的優勢顯而易見且具備絕對性，從基礎的定義（語法撰寫、變數用法）、除錯（錯誤原因分析、調整建議）到設計（如何實現特定功能或效果）都能提供解決方案，且絕大多數是真實可行的。 這對學習者的助益不言而喻，相當於擁有一位隨時待命、任勞任怨且幾乎全才的導師。無論問題深淺，幾乎都能得到解答。這大幅降低了入門門檻，從零建立各種繁瑣概念與認知往往是最困難的，但有了AI工具，不怕找不到答案，只怕你不問。 反面效應 然而使用AI的潛在弊端也同樣明顯：知識取得若太容易、太過依賴AI，反而會抑制學習。如果每次遇到問題只是交給AI然後複製貼上，卻未曾深入瞭解背後的邏輯與解法，那僅是「解決問題」而非真正「學會」。 學習的過程若未曾投入心力、付出代價，是很難真正掌握一項技術或知識的。若在職場上是為了提升效率、減少重複性勞務，使用AI自然恰當；但作為學習者，重點在於「內化」，若沒有真正學會，即便作業或作品呈現得再完美，終究只是空泛的表象。 AI之於開發 延伸上述「沒有學會」的概念，這不僅是個人學習問題，更會導致程式碼缺乏彈性，造成後續維護困難。若是作業或考試，一次性的解決方案或許足夠；但程式開發的最終目標是為了實際運行，這必然涉及新需求或新錯誤的發生，進而需要修改調整。但若程式碼全由AI生成，而開發者並未真正理解，便無能力進行修改，只能繼續依賴AI。若撰寫Prompt（提示詞）的技巧不足，甚至會越改越混亂，引發更多問題。 我曾親身經歷這樣的災難。在培訓班進行小組專題開發時，我們將爬蟲程式與Airflow DAG的撰寫分工，其中一位組員幾乎全靠AI完成任務。起初他還輕鬆地說：「我也不知道怎麼寫，但叫AI寫一下就完成了。」然而，到了後期需要整合並部署至雲端時，各種問題接踵而至，他幾乎束手無策，最終只能求助其他組員，由其他人接手修正他的程式碼。 Vibe Coding 上述組員的例子，已涉及Vibe Coding的核心問題。我認為透過Vibe Coding開發的工具若僅為自用、非商業或非正式場合，並無大礙；但若涉及營利、導入企業或正式工作流，勢必會面臨上述挑戰。AI Agent雖能設計出工具，但使用者是否有能力部署、運行，並在出錯時持續維護，考驗的正是使用者的技術底蘊。 Vibe Coding或AI Agent終究只是工具。我常將「開發之於AI」比作「寫作之於Word」。Word（或任何文書軟體）的出現讓寫作變得便利，似乎人人皆可寫作，但這並未讓所有人都成為作家，也未讓作家就此消失。技術門檻的降低，反而更加考驗作家的本質：是否有獨到的創意構思、架構是否流暢、內容是否具備創新價值。 工程師亦然。寫程式的門檻降低了，看似人人都能開發，但這正是考驗工程師本質：能否挑選合適的框架與解決方案？能否順利部署並持續維護？能否在構思階段便預判各種可能性，並保留調整彈性？這才是目前工程師的核心價值，也是現階段AI仍無法完全取代工程師的原因。 個人經驗 談完我對AI工具的看法，接著分享我自己使用AI的方式。 學習 如前所述，在學習層面上，我認為使用AI必須格外謹慎。若在學習或練習階段需要AI協助，我會區分兩種情境： 我想學會某項技術或知識 我只想解決問題 若目標是「學會」，我絕不會單純將問題丟給AI請它「代為解決」，而是採用類似以下的句型進行「探索」： 我想要實現OOO的功能，有哪些做法可以達到目的？ OOO和XXX都能達到某效果，它們的差異為何？我該如何判斷適用情境？ 我想開發OOO功能，預想會碰到XXX問題，通常可以如何避免？ 在我的認知裡OOO是某某工具，應符合某某條件，請問我的認知是否正確？ 對我而言AI是探索工具。我想瞭解有哪些選項、選項間的差異以及決策依據；而最終的解決方案，仍由我自行決定，而非全權交給AI。或者，當我對某概念不確定時，我會用自己的語言描述，請AI檢驗是否正確。這種做法讓我在使用工具時，不僅解決了問題，更能擴展認知邊界。 開發 在開發實務上，我很少使用Vibe Coding來完成整個的專案或功能。我仍秉持「核心功能自己寫，遇問題才請AI協助」的原則。唯有一個部分，我目前幾乎完全依賴Vibe Coding完成：前端介面。 由於我目前所學專注於資料處理與後端開發，對前端HTML、CSS或UI/UX（如Streamlit、PyQt等）確實一竅不通。我並非抗拒學習，只是現階段應優先穩固後端基礎。但工具終究需要使用者介面，無論是自用或展示，此時我就會藉由Vibe Coding來開發。 一個實際案例就是這個blog網站。我一直希望架設一個功能簡單的網站來記錄學習心得，但既不想使用模板大同小異的現成平台，也不想負擔WordPress的架站費用，於是嘗試用Google Antigravity工具開發，並自行尋找合適的平台部署，最終成果也是意料之外的符合我的需求。 雖然看似輕描淡寫，但過程也踩了不少坑。起初我對網站架構不甚瞭解，僅向AI Agent簡單描述需求。雖然網站寫出來了也能運作，但當我想進一步追加功能（如SEO優化、GA4埋點等）時，發現AI嘗試將專案改寫成GO框架卻不成功，無論如何修改都衍生出無法解決的問題。最後索性咬牙砍掉重練，這次在一開始就指定使用GO框架建立網站，才解決了後續問題。 結語 這對我來說是一次寶貴的經驗，既體現了Vibe Coding的優點，也讓我經歷了它的限制。Vibe Coding讓我能專注於網站內容的發想，不受限於前端技術；對於像我這樣的個人使用者，又不涉及商業運作，我認為已非常足夠。 另一方面，這也驗證了Vibe Coding雖然方便，但真正的關鍵與價值仍在於使用的人。若對技術無知、指令模糊、無法精確理解/發現問題，即使AI Agent再強大也會遇到瓶頸，因為起點就錯了。 就像建築設計師與工程師，即使工程師技術再高超，若一開始的藍圖就畫錯或設計低劣，最終也只會蓋出一棟危樓。 最後編輯於 2025-12-11