前言 近期的開發圈，圍繞著「Vibe Coding」的討論不絕於耳，其中 Claude Code 的出現更是將這個概念推向了高峰。這是一種全新的開發典範，開發者透過對話與描述「感覺」來讓 AI 生成程式碼。在這波浪潮中，Google 也推出了自家的殺手級應用：Gemini CLI。 本篇文章將分享我如何透過 Gemini CLI，從零開始打造一個個人化的健身日誌 Web App。你會發現，導入這種與 AI 協作的終端機工具後，開發流程不僅僅是加速，更是從根本上改變了我們與程式碼互動的方式。 本次的程式碼與成果 本次實作的專案是一個簡單的訓練日誌，最終成果如上圖所示。 專案 Repo: Gym Daily with Gemini: https://github.com/kkdai/gym-daily-gemini 快速複習 Vibe Coding 在深入 Gemini CLI 之前，我們先快速摘要一下「Vibe Coding」這個概念。傳統開發模式中，我們需要逐行撰寫精確的指令來建構應用程式。然而，Vibe Coding 讓我們能用更自然、更貼近人類思維的方式與 AI 協作。 開發者不再需要專注於每一行語法的細節，而是可以描述更高層次的目標，例如： 我需要一個深色主題、看起來專業的儀表板 或是 幫我建立一個 API 端點來記錄數據 AI 會理解這些意圖，並將其轉換為具體的程式碼與架構。Gemini CLI 正是實現這種開發模式的強大工具。 導入 Gemini CLI 實戰 Gemini CLI: https://github.com/google-gemini/gemini-cli Google 官方文章: https://blog.google/technology/developers/introducing-gemini-cli-open-source-ai-agent/ 接下來，我們將拆解如何利用 Gemini CLI 來完成這個健身日誌專案。 第一部分：從 UI 概念到前端程式碼 一個專案的起點，往往是介面設計。在這個階段，我並沒有自己動手畫圖或寫 CSS，而是採用了以下的流程： 利用 AI Studio 產生 UI Layout：我先到 AI Studio，向它描述我想要的介面風格——簡潔、專注於資訊呈現、易於操作。AI 很快地提供了幾個視覺佈局供我參考。 生成 Tailwind CSS：在確定了喜歡的風格後，我請 AI Studio 將這個設計轉換成 Tailwind CSS 的格式。這是一個現代化的 CSS 框架，能讓我快速建構出美觀且響應式的介面，而我甚至不需要深入了解其語法細節。 可以看得出來，在專案初期，Gemini 生態系內的工具已經能幫助我們快速將模糊的想法具體化為可用的前端程式碼。 第二部分：了解 Gemini CLI 的運作大腦 有了前端的基礎後，接下來就是 Gemini CLI 大展身手的時刻。它不僅僅是一個程式碼生成器，更像是一個常駐在你終端機裡的資深開發夥伴。 它的強大之處在於： 專案上下文理解：你只需要在專案目錄下啟動它，它就能夠掃描並理解整個專案的檔案結構與既有程式碼。 整合開發工具鏈：它可以直接幫你執行 git 指令來進行版本控制，甚至能透過 gcloud 指令，將你的應用程式一鍵部署到 Cloud Run。 建立自動化工作流：你可以和它建立「默契」。例如，我曾對它下達指令： 以後改完程式碼，都幫我 push 到 GitHub，然後直接跑一次本地端伺服器給我驗證。 從此，這個開發、測試、提交的循環就變得完全自動化且極其順暢。 Gemini CLI 的核心是將 Gemini 1.5 Pro 強大的模型能力與開發者熟悉的 CLI 環境深度整合，讓它能理解你的指令，並調用對應的工具來完成任務。 第三部分：根據實戰結果，來分析一下差異 導入 Gemini CLI 後，與傳統開發流程相比，最顯著的差異有兩點： 開發流程的無縫整合與自動化 以往，寫碼、測試、版本控制、部署是幾個獨立的步驟，需要手動切換工具與執行指令。但在 Gemini CLI 的輔助下，這些流程可以被串連成一個單一的對話指令。就像前面提到的，一個「改完就推送到 GitHub 並本地運行」的指令，就取代了過去繁瑣的手動操作，大幅提升了開發效率。 從抽象指令到具體成果的轉譯能力 傳統開發需要我們將需求拆解成非常具體的技術任務。但使用 Gemini CLI，我可以下達更為抽象的指令，例如「幫我把這個列表功能做出來」，它會自己分析現有程式碼，生成對應的邏輯並整合進去。它彌補了從「想法」到「程式碼」之間的巨大鴻溝。 超佛心的免費方案！ 看到這裡，你可能會好奇這樣強大的服務是否所費不貲。Google 這次提供了極具誠意的免費方案！ 只需使用個人 Google 帳戶登入，即可獲得免費的 Gemini Code Assist 授權。此授權包含： 存取強大的 Gemini 1.5...

前提 好像是在 Threads 看到有人貼出的貼文，這明明是一個 25 分鐘的短篇演講。 但是我卻花了兩三個小時仔細的看他，並且不斷勾起我以前的回憶。 這是一篇 LeadDev 研討會的演講，主要內容探討到軟體開發人員最害怕的「技術債」（Technology Debt)。 Netflix的Bruce Wang分享技術負債管理經驗：技術負債是創新的自然產物，需建立共通語言與明確定義，公開討論並主動處理。技術負債管理得當可促進業務創新，推動公司成長。 相關內容分享 以下內容大多是針對某幾張投影片，做一些註解並且寫上自己的想法。 以下哪些不是 Tech Debt? 商業決策（老闆不做的) - 沒有資源 不同 model 間缺乏溝通 Bug. (很常～～懶得解就說是技術債) Bad Code (寫的爛～也不會是技術債) - 效能問題 (效能問題絕對不是技術債) 你對這些程式碼不熟…. (好像超多人講這個，好像重寫就沒有技術債一樣 XD) 如何定義與描述「技術債」的準則: 定義上： 最重要需要去研究你所謂的「技術債」究竟是什麼？ 不能只是說一句，這是某個舊的框架，所以是個技術債。 要「明確」，「可視化」並且「主動」去將技術債都找出並且明確的定義出來。 對於「技術債」的處理方式： 精確的找到它，給它取個名字。 某個 Tunnel 資訊流通上的限制 -> Tunnel X Project 不可以遇到事情，就說這是「技術債」。 需要清楚的講出來是哪個技術債，不要把技術債當作是不想修復與不想處理上的籠統(suitcase)名詞。 「Maintain/Improve 還是 Migrate?」 軟體開發流程上，許多軟體開發工程師往往接手舊的系統，到了要維護（或是優化）的狀況下，比較沒有經驗的人經常會選擇直接 migrate 到新的系統。 這往往是最有風險的事情，有太多危險可能發生： 主管變動（忽然不想改） 人員變動（又換了一組人） 外在環境變動（生意忽然沒了？ Covid 造成生意大好？） 技術變動（AI 忽然跑出來) 最大的風險是： 你根本不知道 Migrate 過去。 你所謂的技術債就會消失。 或許根本不會…. 你只會有一堆商業邏輯忘記搬過來。 破解技術債的迷思 Legacy 不是 技術債，只是你沒花時間去搞懂他。 技術債不需要全部清完，而是在必要時候去清除最重要的。 技術債因為牽扯重要商業邏輯與更底層的技術，讓專業（資深）的來。 技術債發生在任何產品中，新創產品其實更多。 導入新的程式語言，新的框架，只會引來更多技術債。 面對技術債，每一間公司都是有辦法來面對的。 處理好技術債，面對更多商業挑戰 如果我們可以更有智慧，有積極的面對這些技術債，而不是天天將技術債作為不想維護的藉口。這樣我們才是認真面對這個商業服務，也才能更有信心的對接下來的商業需求說 “YES” 。 後話 雖然是一個 25 分鐘的演講，但是我卻花了兩三個小時慢慢地欣賞跟品味每一段文字。 許多內容也呼應了身為軟體開發的心路歷程與以前的血淚（？）。 蠻推薦大家要好好思考這些相關的內容。

前提： 本來一直有想要去學習 n8n ，但是還沒想到要拿來做什麼。近期去參加了 gai 年會之後，看到不少有趣的應用。決定回來先架起來試試看，本篇快速整理與分享一下近期看到幾個很有用的資訊。 還有我自己拿來做了什麼，希望對大家有幫助。 為什麼需要架設 n8n? 先分享一下，就我自己的為什麼需要架設自己的 n8n ？ 還有他能幫助我什麼部分？ 老實說，要架設「自動化服務」，很重要就是在於「自身的需求性」。我原本就有花錢買一些自動化服務 (ifttt) 加上透過自己的 LINE Bot 來打造自己的知識流的架構。 大概是一個這樣的架構，其中 LINE Bot 工作還蠻 Heavy 的，需要爬下整個網頁內容，並且還要做 AI 摘要。 所以本來 IFTTT 經常會自動停掉。本來就有打算要移到 GCP，但是一個個寫成 CloudRun 又太費事，於是一直放著等待更好的解決方案的出現。 最近看到了 n8n ，決定來弄一下。 以下記錄一下我架設伺服器（免費），還有一些設定上需要注意的地方。 架設免費 n8n 伺服器 (HuggingFace + Supabase + Upstash) 這一篇可以看一下，對我幫助很大。總之先看看用量會不會不夠，再決定要不要放上 Google Cloud 。 比較需要注意的地方： 大概就是 Supabase 的網址有多一個空白 ，這個真的很雷啊。雖然影片作者有講，但是還是被雷到。 XD 比較需要注意的整合部分： 這邊列出幾個我覺得在 n8n Node 串接上需要注意的： 記得將 Space 打開 Private ，不然不能串接 LINE 跟 TG (等等 POST Services) 安裝好的時候，一開始覺得 WebHook “GET” 沒問題就完事。結果發現 LINE Bot 一直串接不起來，才發現跟 Space 是隱藏的還是公開的有很大的關係。 記得去 Space -> Setting 將它打開。 (這樣就可以接 TG 跟 LINE Bot) Google Sheet/Doc/Drive 串接 可以參考同一位作者分享的這段影片，原來影片三個小時，但是可以跳到這個部分看就好。 快速紀錄流程： 進入 “Google Auth Platform” 進入 “用戶端” 增加一個 OAuth 的 “用戶端” 需要注意的地方： OAuth2 要串接，因為是測試帳號可能會小心失效。 串接之前，務必要啟動 “Google Drive API”, “Googl Sheet API”, “Gmail API” 這幾個就平常架設 GCP 用戶比較少打開的。 JSON 檔案的處理 這部分算是 n8n 一個很重要的地方，很多時候你會需要使用 Edit Field(Set) Node 來處理。 沒有概念的，可以看這個部分影片。 一些好用的 n8n 相關樣板： N8n LINE Bot Webhook node n8n 好用的 workflow 整理 (shared by cympotek) 取代掉原本 IFTTT 上面的一些服務 架設完畢也設定完相關的服務之後，就可以開始來取代掉 IFTTT...

前言 之前的文章曾經有分享過如何透過 Google ADK (Agent SDK) 來將你的 LINE 官方帳號 (俗稱： LINE Bot ) 打造成來。 但是其實在 LLM LINE Bot 上，我們有學過不少的 LLM 方式打造。本篇文章，將討論如何將 Function Calling 的 Agent 模式，直接改造成使用 Agent SDK 的方式。 你會發現這樣的修改，程式碼可以變得更精簡。而且由於導入了 Agent SDK ，整個對話也變得更加的靈活，更可以像是真人的對話。 本次的程式碼 本次將有兩個以往用過的程式碼： 使用 LangChain 的 Function Call 的股票機器人。 https://github.com/kkdai/linebot-langchain 轉換為： –> Agent SDK https://github.com/kkdai/linebot-adk-stock 快速複習 LangChain Function Call 各位可以參考一下本篇文章的詳細內容，這裡僅提供相關的快速摘要。 （這個是之前 LangChain Function Calling 的執行成果） 這篇文章介紹了如何利用 LangChain 和 OpenAI 的 Function Calling 來開發一個股價查詢的 LINE Bot，並分享了一個開源套件供大家學習。LangChain 是一個強大的工具，支援多種大型語言模型，讓開發概念驗證（POC）變得更加容易。文章中提到，透過 Flowise 這樣的視覺化工具，開發者可以快速測試架構和 Prompt，並且在不需要重新部署的情況下修改 Prompt。文章還詳細說明了如何在 Heroku 上快速部署 Python LINE Bot，並提供了使用 LangChain 的 ConversationBufferWindowMemory 來實現具有記憶功能的聊天機器人的方法。此外，文章深入探討了如何使用 OpenAI Functions 來查詢股價，包括如何定義和使用工具來實現這一功能。整體而言，這篇文章展示了 LangChain 在開發 LINE Bot 中的應用潛力，並鼓勵讀者利用這些技術打造出「專一」「好用」的聊天機器人。 導入 Agent SDK 接下來會來開始拆解，如何將 LangChain Function Calling 的程式碼，轉換到 Agent SDK 的方式： 第一部分： 講解 Tools 的轉換方式： 我們先來討論一下，如何將 LangChain funciont Calling 中將 Tools 的程式碼，轉換到 Agent 的部分。 def get_price_change_percent(symbol: str, days_ago: int) -> dict: """ Calculates the percentage change in a stock's price over a specified number of days. Args: symbol (str): The stock symbol (e.g., "AAPL"). days_ago (int): The number of days to...

將 PTT 資料爬蟲改用 Firecrawl API 的研究與實作 前提 photomgr 專案（https://github.com/kkdai/photomgr）一直以來都是爬取 PTT Beauty 板資料的得力工具，幫不少人抓取正妹板的文章和圖片。原本我們是用 Google Cloud Platform（GCP）直接連到 PTT 網站抓資料，簡單又順手。不過最近 PTT 把資料架到 Cloudflare 保護後，GCP 的連線常常被擋，可能是因為 Cloudflare 的防爬蟲機制（像是驗證碼或 IP 限制）太強大，導致原本的爬蟲程式完全 GG。為了讓 photomgr 繼續運作，我們研究了幾個替代方案，最後決定改用 Firecrawl API 來爬 PTT 的資料。這篇部落格會講解我們為什麼要做這個改變、怎麼改，以及改完後的程式碼和成果。 相關變動 PTT 最近開始用 Cloudflare 保護網站，加入了像是驗證碼、IP 限制等防爬蟲機制。這些措施讓我們原本用 GCP 直接送 HTTP 請求去抓資料的方式行不通，因為 Cloudflare 會把 GCP 的請求擋掉或限速，導致爬蟲常常失敗。經過一番研究，我們發現 Firecrawl 這個服務很適合解決這個問題。它不僅能繞過 Cloudflare 的防爬，還能把網頁內容轉成乾淨的 markdown 格式，方便我們解析。於是，我們決定把 photomgr 的爬蟲邏輯從原本的直接連線改成用 Firecrawl API 來抓 PTT Beauty 板的文章列表和內文。 什麼是 Firecrawl？ Firecrawl 是一個專為網頁爬蟲設計的 API 服務（https://www.firecrawl.dev/），可以幫你抓取網頁內容並轉成結構化的格式，比如 markdown 或 JSON。它最大的優勢是能處理像 Cloudflare 這種防爬蟲保護，還能模擬瀏覽器行為，抓到動態載入的內容。Firecrawl 的 /v1/scrape 端點讓我們可以送一個網址過去，它就會回傳網頁的主要內容，省去自己處理複雜 HTML 的麻煩。對我們來說，這是個超佛心的工具，因為它讓爬蟲變得更穩定，還能省下不少寫解析邏輯的時間。 要如何修改？ 為了讓 photomgr 用上 Firecrawl API，我們需要把原本 ptt.go 的爬蟲邏輯改成呼叫 Firecrawl 的 API。以下是改動的重點： 保留公開 API 不變：ptt.go 裡的公開函數（像是 GetPosts 和 GetPostDetails）已經被其他使用者依賴，所以我們不能改動這些函數的輸入輸出格式，只能改內部的實作邏輯。 使用 Firecrawl API：改用 Firecrawl 的 /v1/scrape 端點來抓 PTT Beauty 板的列表頁（https://www.ptt.cc/bbs/Beauty/index.html）和單篇文章頁（像是 https://www.ptt.cc/bbs/Beauty/M.1748080032.A.015.html）。 解析 markdown 資料：Firecrawl 回傳的資料是 markdown 格式，我們需要把它解析成結構化的 JSON，像是文章標題、網址、作者、日期、推文數（或「爆」標記）等。 環境變數管理 API Key：Firecrawl 的 API 需要一個 key，我們會從環境變數 FIRECRAWL_KEY 讀取，確保安全不硬寫在程式碼裡。 單元測試：新增單元測試來驗證爬蟲和解析邏輯，目標是至少 80% 的程式碼覆蓋率。 關於 over18=1 的 Cookie 寫法 PTT Beauty 板有年齡限制，瀏覽時需要設定 over18=1 的 Cookie 來通過檢查。在 Firecrawl API 的請求中，我們需要在 headers 裡加入這個 Cookie，這樣才能順利抓到頁面內容。具體寫法如下： { "url": "https://www.ptt.cc/bbs/Beauty/index.html", "headers": { "Cookie":...

連結: 從石器時代到AI紀元 Nexus : A Brief History of Information Networks from the Stone Age to AI 作者： 哈拉瑞 原文作者： Yuval Noah Harari 譯者： 林俊宏 出版社：天下文化 出版日期： 2024/09/10 買書推薦網址： Readmoo: 由此去購買。 前言: 這是 2025 年第 2 本讀完的書。當初會看這本書只是因為是近期最暢銷的書籍，沒有想過裡面真的有蠻多部分是很值得思索的部分。 蠻建議有興趣的人可以來看看，裡面透過不少歷史故事與相關的說明分享，讓你更了解人類歷史，資訊流的連結關係。 內容摘要： 現在與未來，AI將會做什麼？ 哈拉瑞的新巨作《連結》，以激勵人心的方式， 講述了我們如何走到這一刻， 以及現在必須做出的、攸關生存與發展的急迫決擇。 《連結》透過人類大歷史的長鏡頭， 檢視資訊網路與資訊流，如何將我們帶到AI紀元。 哈拉瑞引導我們走過石器時代、經歷《聖經》正典化、 印刷術的發明、大眾媒體的興起、以及民粹主義的重燃…… 例舉了羅馬帝國、秦帝國、天主教會、蘇聯等體制 如何利用資訊技術來實現目標，無論是好是壞。 資訊，既不是真理真相的原料，也不只是權力與武器； 《連結》探索了許多極端之間、充滿希望的中間立場， 在鐵幕落下、矽幕升起之際，重新發現我們共有的人性。 封面 【開場白】前方的路滿布荊棘 第一部　人類形成的網路 第１章　資訊是什麼？ 第２章　故事──無限的連結 第３章　文件──紙老虎也會咬人 第４章　錯誤──絕對正確是一種幻想 第５章　決擇──民主與極權制度簡史 第二部　非生物的網路 第６章　新成員──電腦與印刷機不同之處 第７章　不停歇──網路監控無所不在 第８章　易出錯──存在於電腦間的現實 第三部　電腦政治學 第９章　民主制度──我們還能對話嗎？ 第10章　極權主義──權力歸於演算法？ 第11章　矽幕──全球帝國、或是全球分裂？ 【結　語】打造自我修正機制 心得: 這本書講解著資訊與知識本身，造成人類相互連結與對立的相關故事。作者在以下的採訪中有著相當清楚的解釋： 在許多文案中，可能會讓人以為他是在探討著 AI 與人類的關係，但是其實做作者探討著更深層的問題 — 人與人之間的 「連結」問題。 這本書首先從資訊交換開始說起來，然後透過故事的方式將資訊將以保存以及流傳。這邊一開始有提到大家都有聽說過「歷史是勝者寫的」，也就是一種資訊的連結的傳遞方式。 所有你以為的政治故事其實都是因為勝利的那一方寫下來的，而故事造成傳遞效果會更加的強大。 也有提到聖經上的許多故事也是值得反覆的思考，主要也因為當初的時間與政治背景的不同。 故事能創造出「第三層次的現實」：存在於主體間的現實，主觀現實 與 主體間的現實。 故事造就時事變革 所以希特勒之所以能贏得 1933 年的大選，因為德國經濟危機狀況下，許多人相信了他提出的故事。 回過頭人與人「連結」的方式，就談到了關於「書籍」。書籍是最原始將人與人連結傳遞下來的介質，從「聖經」到各種重大書籍為主。但是隨著人類歷史與各地區政治的變革，聖經的內容也有了不同教義與流派的解釋。甚至也有了不同流傳版本的差異。 書籍與宗教的變革 但是宗教是否有自我修正的機制？宗教的本體是人，人類會有許多的偏見與錯誤，自然也會有相關的修正機制。這也代表著人類彼此間的相互連結，也是存在著許多修復的方式。 連結的修復機制 科學也有自我修復的機制，書中提到謝赫特曼的「準晶體」理論，震驚了整個科學界，並且也受到許多學者的反抗與輿論的壓力。但是著隨著科學技術的進步，整個理論慢慢被澄清。理論本身的連結也因此被修復了起來。 政治上 - 民主 與 極權 產生的連結 回歸到政治上，民主自然也是一種人與人之間的一種連結。人民透過民主制度選舉出的政府單位。如果發生了問題，也代表著人民有機會可以退回自己決定。 這會讓人覺得「民主」是脆弱與妥協的產物？ 作者也提到，民主的本體就在於許多的選擇與討論與妥協下的變革，相比「極權」帶來的“容易二分法”，民主其實是相當的脆弱。所謂的民主，就是人民有著投票與反對的權利。而極權是沒有的： 相反複雜的民主，其實極權反而是簡單 史達林是大家都認為的蘇俄極權統治者，他建立了一個極端的極權組織與統治制度。到了現在許多的國家依舊是依照著相關的方式： 秘密警察： 針對資訊的統一管理，並且鼓勵檢舉。讓人與人之間的連結切斷，彼此不相信。（史達林大清洗） 剝奪人民的選舉與投票權： 鞏固著自己的政治權利。 但是卻因為自己過度的極權統治，讓自己在病倒的那一天沒有人敢靠近他給他足夠的醫治。 社群媒體造就的資訊不對稱與切斷連結 這邊有提出在社群媒體興盛的這個年代，人們越來越喜歡在社群媒體上「取得同溫層」的鼓勵。但是卻又更喜歡去「異溫層」層裡面爭吵與彼此對立。這其實也是因為 AI 計算出來這就是一個推薦系統上的問題。 使用去中心化的資訊，是否可以達成民主？ 這裡也有探討著最新的技術與民主的交互作用，是否可以用去中心化來保存資訊，達到真正的社群民主？但是作者也提出疑問，如果類似史達林的極權統治者，統治著 51% 的人民，是否就可以消除掉其他的聲音？ 我們應該如何小心 如同前面提出的：「民主是相當複雜且脆弱的」，相比之下民粹與極權都相對的簡單與易懂。 這也是民主本身需要解決的問題，但是在 SNS 上面我們會看到許多“簡單的暴力”的言論方式，來鼓勵許多對立的情緒。 你之所以會看到，其實並不一定代表那是大部分人的情緒，反而可能是推薦系統所造成的結果。 推薦系統會推薦著「你喜歡的」讓你有同感，但是更傾向推薦「你厭惡的」來讓你回覆文章。對於政治也是如此，如果你看到簡單的贊成與反對，應該要花一點時間去閱讀更多的書籍與資訊。來讓自己充分了解每一方的說法，而不是限於各種的反對與破壞「連結」的說法之中。 不論是你喜歡的資訊，或是你不喜歡的資訊。我們都希望每一個人要有主動研究資訊的能力。 就像是讀書一樣，要能夠取得資訊並且去思考真正的問題。 比較這些政治人物之前與現在的說法，是否只是因為某些政治取向的操作。 最後再次呼應著大家「民主是一個相對的概念」，並不存在的非黑即白的想法。「民主是複雜且脆弱的」，但是保有人民選舉與決定自我投票的權力才是真正的民主。