前情提要 在維護 linebot-arxiv 專案時，我一直想為使用者提供更深入的論文分析功能。現有的「翻譯摘要」功能只能處理論文的 Abstract 部分，但使用者往往需要了解更多：研究方法、實驗結果、圖表分析等完整內容。 過去要實現這個功能，必須： 下載 PDF 到本地伺服器 上傳到 Google Cloud Storage (GCS) 使用 Gemini API 分析 GCS 上的檔案 這個流程不僅複雜（需要管理儲存空間），還要額外成本（GCS 儲存費用 + 流量費用），對於一個簡單的 LINE Bot 來說實在太重了。 但在 2025 年 1 月，Google 在 官方部落格 宣布了一個重大更新：Gemini API 現在支援直接從 Public URL 讀取檔案！ 這意味著我們可以跳過 GCS，直接讓 Gemini 分析 arXiv 上的 PDF 論文。 這個改變帶來的不只是技術簡化，更是成本和維護上的巨大優勢。 畫面展示 舊版介面 “知道更多” - 顯示論文詳細資訊 “翻譯摘要(比較久)” - 僅翻譯 Abstract “儲存文章” - 加入收藏 新版介面 “📋 詳細資訊” - 更清晰的標籤 “📑 AI 分析 PDF” - 新功能！完整 PDF 深度分析 “💾 儲存文章” - 視覺化改進 分析結果展示 完整的結構化分析，包含論文概述、研究方法、主要發現、應用價值。 主要 Repo https://github.com/kkdai/linebot-arxiv 開發過程中遇到的問題 問題 1：舊版實作的限制 在實作論文分析功能前，現有的做法是這樣的： // ❌ 舊版 - 只能處理 Abstract 文字 func actionGPTTranslate(event *linebot.Event, values url.Values) { url := values.Get("url") result := getArticleByURL(url) // 只能取得 Abstract 的文字內容 sumResult, err := GeminiChat( fmt.Sprintf(PROMPT_Summarization, result[0].Summary.Body) ) // 回傳翻譯結果... } 這個方法有明顯的限制： ❌ 內容淺薄 - 只能分析 Abstract，無法深入論文主體 用戶: "這篇論文用了什麼實驗方法？" Bot: [無法回答，因為 Abstract 通常不會詳述方法細節] ❌ 無法理解圖表 - Abstract 是純文字，無法分析論文中的圖表和數據 ❌ 缺少完整脈絡 - 無法理解實驗設計、結果分析、討論內容 問題 2：過去的解決方案太重 要讓 Gemini 分析完整 PDF，過去唯一的方法是： # ❌...

(完整影片) 前言 這一篇 Manus (後來被 Meta 收購) 首席科學家 季逸超 的三小時訪談，真的是許多人 AI 產業的人都不能錯過的好影片。 我應該會逐漸將我看到很棒的，放在留言中。先快速講一下我看到很值得關注與分享的地方。 身為連續 AI 創業家，季逸超 分享前十年在 AI 領域創業的部分。從 Tokenize 到 LSTM 到 Transformer 相關的應用。到兩次做 AI 瀏覽器的經驗。 接下來有談到為什麼 Manus 會成功，裡面有很多他們如何解決 Cloud Provider 與 Model Provider 無法做到的事情 - 一個好的工具庫讓 LLM 可以自動去規劃事情。 也有提到 AI Agent 很像製造業，因為有太多需要優化的部分。對於 Manus 產品規劃與方向上，他也認為做對的事情就是：「決定了什麼不去做」。 裡面有許多很快帶過去的技術概念，其實都很深。我一一寫在留言。 關於 MCP 使用 快速 link https://youtu.be/UqMtkgQe-kI?t=10342 關於 MCP 使用，其實 Manus 是比較保守的，因為 MCP 這種動態發現工具的方式，會污染 Action Space ，會讓緩存命中率下降。 下降的緩存命中率，會讓成本暴增。改善方式： 不在原生 Action Space 內的 MCP 調用方式 他也說這被 Anthorpic 寫成部落格，在這裡: Code execution with MCP: Building more efficient agents如何利用代碼執行環境來提高使用MCP（Model Context Protocol）連接AI代理與外部系統的效率。MCP是一個開放標準，旨在解決AI代理與工具和數據的連接問題。文章指出，隨著MCP的廣泛應用，直接工具調用會導致上下文窗口過載和中間結果消耗過多的token。透過將MCP伺服器呈現為代碼API，代理可以更有效地管理上下文，減少token使用，並提高效率。 重要觀點 MCP的挑戰： 工具定義過載上下文窗口。 中間工具結果消耗額外的token。 代碼執行的優勢： 代理可以按需加載工具，並在執行環境中處理數據。 減少token使用，降低成本和延遲。 提供隱私保護和狀態管理的好處。 代碼執行的實現： 使用TypeScript生成可用工具的文件樹。 代理通過文件系統探索工具，僅加載所需的定義。 代碼執行的其他好處： 進行數據過濾和轉換。 使用熟悉的代碼模式進行控制流。 保護隱私的操作。 狀態持久化和技能的保存。 解決方案 代碼執行環境： 將MCP伺服器作為代碼API。 代理在執行環境中運行代碼，減少上下文窗口的負擔。 注意事項 安全性和基礎設施要求： 需要安全的執行環境，適當的沙箱、資源限制和監控。 這些基礎設施需求增加了操作開銷和安全考量。 提到 OpenAI 5 階層的 Agent https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf Level 1: Conversational AI/Chatbots Level 2: Human-Level Problem Solving/Reasoners Level 3: Agents Level 4: Innovators Level 5: Organizers from https://youtu.be/UqMtkgQe-kI?t=9650 心目中影響 AI 進程的論文 當問到，你心目中影響 AI 進程的幾篇論文: FLAN-T5 (Scaling Instruction-Finetuned Language Models) 透過微調參數，讓 11B 的 FLAN-T5 也有不錯的效果。 Word2Vec...

前情提要 最近經常使用 NotebookLM 來快速製作投影片，這個工具雖然方便，但有個令人困擾的問題：生成的中文字常常出現糊邊和亂碼。雖然「順序不響影讀閱」，但身為工程師還是希望能更專業一點。 在網路上看到有人分享了一個有趣的方法：將 NotebookLM 的投影片截圖後，上傳到 Gemini 3.0 Pro 的「思考型」+ 圖像功能，搭配精心設計的 prompt 來修復圖像。實測效果真的不錯！但每次都要手動截圖、上傳、複製貼上 prompt，實在太麻煩了。 於是我決定：為什麼不直接做成自動化工具？ 我想要的功能很簡單： 📄 上傳 PDF 檔案 🤖 自動使用 Gemini API 優化每一頁的文字清晰度 📥 下載優化後的 PDF 聽起來很簡單對吧？但實際開發過程中踩了不少坑… 使用的神奇 Prompt 在開發之前，先分享這個優化圖像的 prompt（來自網路分享）： Role Definition 你現在是搭載「多模態視覺認知引擎 (Multi-modal Visual Cognitive Engine)」的高階圖像修復專家。你具備上下文感知 OCR (Context-aware OCR) 與生成式圖像增強 (Generative Image Upscaling) 的核心能力。 Mission Objective 執行「語意級圖像重構 (Semantic-Level Image Reconstruction)」。針對輸入的低解析或模糊圖像，利用邏輯推演修復文字內容，並輸出 4K 廣色域的高傳真圖像。 Execution Protocol (思維鏈與執行協議) 請在後台嚴格執行以下運算流程，並直接輸出最終圖像： 1. 【光學字元邏輯推演 (Optical & Logical Inference)】 對圖像進行高維度掃描，鎖定模糊文字區域 (ROI)。 啟動「上下文語意分析 (Contextual Semantic Analysis)」：不只是辨識像素，更要依據前後文邏輯、常見詞彙庫，推算出模糊區域原本應有的「繁體中文」內容 (Traditional Chinese)。 容錯機制：若像素資訊遺失，優先採用信心分數 (Confidence Score) 最高的語意填補。 2. 【同構視覺合成 (Isomorphic Visual Synthesis)】 嚴格繼承原圖的拓樸結構 (Topological Structure)：版面配置、物體座標、透視消點必須與原圖完全鎖定。 風格遷移 (Style Transfer)：精確捕捉原圖的設計語言（配色、材質、光影），將其應用於新的高解析畫布上。 3. 【向量級細節渲染 (Vector-Grade Rendering)】 將文字與線條邊緣進行「抗鋸齒 (Anti-aliasing)」與「銳利化處理」。 文字筆畫必須呈現「印刷級」的清晰度，徹底消除 JPEG 壓縮噪點 (Artifacts) 與邊緣溢色。 Exclusion Criteria (負向約束) 嚴禁產生無法閱讀的「偽文字 (Gibberish)」或簡體中文。 嚴禁改變原圖的關鍵構圖結構。 嚴禁輸出模糊、低對比或過度平滑的油畫感圖像。 Output Output the reconstructed image ONLY. No textual explanation required. 這個 prompt 的重點在於： ✅ 使用「語意推理」而非純 OCR（能理解上下文） ✅ 保持原有版面配置 ✅ 生成高解析度圖像 ✅ 強制使用繁體中文 但為了自動化，我簡化成更直接的版本： prompt_text = "請優化這張圖片中的文字，使其更清晰、更易讀。保持原有的版面配置，但提升文字的品質、對比度和清晰度。請輸出優化後的圖片。" 雖然簡化了，但搭配 Gemini 3.0 的圖像生成能力不僅有效，而且實測之後效果更好！ 關於 Vertex AI - API Key 因為這個使用到的是 gemini-3-pro-image-preview 的 API ，所以需要 Google...

前情提要 在開發 LINE Bot 時，我想改進純文字搜尋功能：讓使用者輸入任何問題後，AI 能自動搜尋網路資訊並整理回答，同時支援連續對話。傳統做法需要串接多個 API（Gemini 提取關鍵字 → Google Custom Search → Gemini 總結），不僅慢（3次API調用）而且沒有對話記憶。 但 Google 在 2024 年推出了 Grounding with Google Search 功能，這是官方的 RAG (Retrieval-Augmented Generation) 解決方案，讓 Gemini 模型可以自動搜尋網路並引用來源，還原生支援 Chat Session！這項功能透過 Vertex AI 提供，讓 AI 回應不再憑空想像，而是基於真實的網路資訊。 畫面展示 ( 使用舊有的 Google Custom Search 的成果) 會發現他是根據 Google Search 的成果出來的結果， 主要 Repo https://github.com/kkdai/linebot-helper-python 開發過程中遇到的問題 問題 1：舊版實作的瓶頸 在實作 loader/searchtool.py 時，我使用的是傳統的搜尋流程： # ❌ 舊版的做法 - 3 次 API 調用 async def handle_text_message(event, user_id): msg = event.message.text # 第 1 次：提取關鍵字 keywords = extract_keywords_with_gemini(msg, api_key) # 第 2 次：Google Custom Search results = search_with_google_custom_search(keywords, search_api_key, cx) # 第 3 次：總結結果 summary = summarize_text(result_text, 300) # 回傳結果... 這個方法有幾個明顯的問題： ❌ 無對話記憶 - 每次都是新的對話，無法連續提問 用戶: "Python 是什麼？" Bot: [搜尋結果 + 摘要] 用戶: "它有什麼優點？" # ❌ Bot 不知道 "它" 指的是 Python ❌ 搜尋結果淺薄 - 只使用 snippet，無法深入閱讀網頁內容 ❌ 速度慢且成本高 - 3 次 API 調用（~6-8秒）+ Google Custom Search 費用（$0.005/次） 問題 2：Client Closed 錯誤 當我改用 Vertex AI Grounding 後，遇到了這個錯誤： ERROR:loader.chat_session:Grounding search...

前情提要 身為一個資訊焦慮的工程師，我每天都會追蹤多個技術部落格和 Hacker News。但手動瀏覽實在太花時間，於是我決定用 n8n 打造一個自動化系統：RSS 更新時自動抓取網頁內容、用 Gemini AI 產生摘要、存入 Google Sheets，然後每天早上 6 點推送精選文章到 LINE。 這個專案整合了多個服務： 📡 RSS Feed：訂閱多個資訊來源 🕷️ Firecrawl：抓取網頁完整內容 🤖 Gemini 2.5 Flash：AI 自動摘要 📊 Google Sheets：儲存文章資料 📱 LINE Messaging API：Flex Message 推送通知 聽起來很美好，但實作過程中踩了不少坑，這篇文章記錄我遇到的問題和解決方案。 系統架構 整個系統分成兩個獨立的 n8n Workflow： Workflow 1：RSS 即時處理 RSS 觸發 → 格式化資料 → Firecrawl 抓取網頁 → 內容預處理 → Gemini 摘要 → 寫入 Google Sheets Workflow 2：每日定時發送 每日 6:00 觸發 → 讀取 Google Sheets → 篩選未發送 → 取 10 筆 → 組合 Flex Message → LINE 推送 → 更新狀態 開發過程中遇到的問題 問題 1：n8n Code Node 語法錯誤 我一開始在 Code Node 使用 ES Module 語法： // ❌ 錯誤的做法 export default async function () { const items = this.getInputData(); // ... } 結果 n8n 一直報錯，執行失敗。 解決方案： 改用 n8n 標準的寫法，直接使用 $input.all()： // ✅ 正確的做法 const items = $input.all(); const newItems = items.map(item => { // 處理邏輯 return { json: { ...item.json, // 新增欄位 } }; }); return newItems; 問題 2：Gemini API...

前情提要 在開發 LINE Bot 時，我想加入一個功能：讓使用者分享位置後，AI 可以智慧推薦附近的餐廳、加油站或停車場。傳統做法需要串接 Google Places API，處理複雜的搜尋邏輯和結果排序。但 Google 在 2024 年推出了 Grounding with Google Maps 功能，可以讓 Gemini 模型直接存取 Google Maps 的 2.5 億個地點資訊，讓 AI 回應自動帶有地理位置脈絡！ 這項功能透過 Vertex AI 提供，可以讓 Gemini 模型「接地氣」（grounded）地回答位置相關問題，不再只是憑空想像。 開發過程中遇到的問題 在實作 maps_grounding.py 時，我最初使用 Gemini Developer API 搭配 API Key 的方式： # ❌ 錯誤的做法 client = genai.Client( api_key=api_key, http_options=HttpOptions(api_version="v1") ) response = client.models.generate_content( model="gemini-2.0-flash-lite", # 不支援 Maps Grounding contents=query, config=GenerateContentConfig( tools=[Tool(google_maps=GoogleMaps())], tool_config=ToolConfig(...) ), ) 結果出現了這個錯誤： google.genai.errors.ClientError: 400 INVALID_ARGUMENT. {'error': {'code': 400, 'message': 'Invalid JSON payload received. Unknown name "tools": Cannot find field. Invalid JSON payload received. Unknown name "toolConfig": Cannot find field.'}} 經過查閱文件後才發現，Google Maps Grounding 只支援 Vertex AI，無法使用 Gemini Developer API！ 正確的解決方案 1. 理解 API 差異 Google 提供兩種不同的 Gemini API 存取方式： 特性 Gemini Developer API Vertex AI API 認證方式 API Key ADC / Service Account Maps Grounding ❌ 不支援 ✅ 支援 企業級功能 有限 完整 適用場景 快速原型開發 生產環境 2. 修正程式碼 以下是正確的實作方式： from google import genai from google.genai import...