前情提要 AI 時代下，連我自己都會將大部分得程式碼優化或是寫作的部分都會麻煩 AI 代勞。但是因為模型訓練的資料因素，有太多的寫作方式都太老舊了。這樣造成寫出來的程式無法應用到最新版本 Go 的一些功能，這樣相當的可惜。 還好， JetBrains 出了 go-modern-guidelines 這個很好用的 plugin 。可以讓你的 AI Agent 變得更加的聰明，並且知道該如何使用最新的程式語法來優化你的 Golang 程式碼。 什麼是 go-modern-guidelines？ 它想解決的問題：模型的知識有截止日，Go 沒有 這個專案的定位寫得很直白：為 AI agent 提供當代的 Go 撰寫規範，讓它們不會因為知識截止日而寫出過時的 Go。 問題有兩層。第一層很好理解：模型訓練資料有截止時間，截止之後才進標準庫的東西，它沒看過就不會用。專案自己舉的例子是 errors.AsType[T]（Go 1.26），模型沒見過，自然不會寫。 第二層比較微妙，專案稱之為 frequency bias：就算模型「知道」新寫法，訓練資料裡舊寫法出現的次數還是壓倒性地多。網路上十年份的 Go 程式碼裡，interface{} 的出現次數遠遠多於 any，sort.Slice 遠多於 slices.SortFunc。模型是在做機率預測，多數決贏的往往是舊的那個。 這第二點我在這次重構裡真的看到了。原本專案裡有這麼一段： // The oauth2 library can return an error containing "invalid_grant" // when the refresh token is expired, revoked, or otherwise invalid. if err != nil { errorStr := err.Error() // Basic substring check to avoid importing "strings" for i := 0; i <= len(errorStr)-13; i++ { if errorStr[i:i+13] == "invalid_grant" { return true } } } 一段手刻的字串搜尋，註解還特地解釋「為了避免 import strings」。strings 是標準庫，import 它的成本是零。這段程式碼要的其實就是一行 strings.Contains(err.Error(), "invalid_grant")。 它怎麼運作：兩個指令，一份隨 Go 版本增長的清單 工具本體是一支 CLI，只有兩個子指令： list [--go-version <version> | --file-path <path>] 回傳這個 Go 版本支援的規範清單，由新到舊排序。 explain <id>... 回傳特定規範的詳細說明與 before/after 範例。 list 的設計重點在於它會依 Go 版本回答不同的答案。你可以直接丟一個檔案路徑給它，它會自己往上找 go.mod、go.work，或退而求其次看本機的 Go toolchain： $ go-modern-guidelines list --file-path ~/Documents/linebot-file/main.go 我這個專案的 go.mod 寫 go 1.24.0，所以它回了 45 條。換個版本號，數字就跟著變： Go 版本 規範數 1.21 32 1.22...

前情提要 「網址擷取失敗，幫我看一下 log。」 這種回報我大概一兩週會收到一次，通常都是某個網站又加了一層防爬蟲，查一下讓爬取多一種備援方式繞過去就結束了。這次也是這樣開始的：使用者傳一個 acm.org 的網址進來，摘要功能吐了一個錯誤。 查下去才發現不是這麼一回事。網址擷取這個功能已經默默壞了三天，而且問題不在對方網站，是我自己的 Docker image 裡一個沒鎖版本的 npm 套件，某天悄悄升級到一個需要更新版 Node.js 才跑得動的新版本，容器裡的 Node.js 卻還停在半年前裝的那個。 先看 log： gcloud logging read 'resource.type="cloud_run_revision" AND \ resource.labels.service_name="linebot-helper-python" AND \ textPayload:"acm.org"' --limit=50 --freshness=2d \ --format="table(timestamp,severity,textPayload)" ERROR:loader.url:All methods failed for URL: https://www.acm.org/articles/people-of-acm/2026/russ-cox WARNING:loader.url:cloudscraper failed ...: 403 Client Error: Forbidden for url: ... WARNING:loader.url:httpx failed ...: Client error '403 Forbidden' for url: ... WARNING:loader.url:singlefile failed ...: SingleFile exited with code 1 ERROR:loader.singlefile:SingleFile loading failed ...: SingleFile exited with code 1 這個 Bot 抓網頁內容有個 fallback chain：先試 singlefile（headless Chromium 完整渲染），失敗換 httpx，再失敗換 cloudscraper（專門繞 Cloudflare 的工具），三種都失敗才報錯給使用者。httpx 跟 cloudscraper 拿 403 情有可原，acm.org 本來就有防護。但 singlefile 不該失敗，它是設計來繞過這種防護的最後一道防線。 往下翻，找到 singlefile 真正的錯誤： Error: WebSocket is not available, Node.js 22.4.0 or later is required at file:///usr/local/lib/node_modules/single-file-cli/lib/deno-polyfill.js:132:8 Node.js v18.20.4 容器裡是 Node 18，single-file-cli 卻要求 22.4 以上。查了一下這個錯誤第一次出現的時間是三天前，不是今天才發生。這代表過去三天，只要一個網址前面三種方法有任何一種被擋下來，就會全滅，使用者只會收到一句「無法從網址讀取內容」，完全看不出背後是這個原因。 為什麼要跑三次 Cloud Build，而不是改完就上線 這篇文章接下來會出現三次「改 Dockerfile → 用 Cloud Build 建置 → 實際跑起來看看」的循環。一開始我沒打算這麼做，覺得改個版本號、看 build 過了就能上線。後來發現這個假設每次都錯。 原因是 npm install -g single-file-cli 這種指令，build 成功只代表「npm 找得到這個套件、裝得進去」，不代表「這個套件跑起來的時候能動」。npm 對 engines 欄位的檢查預設只是警告，不會讓 build 失敗；而套件真正會不會 crash，要等它實際去啟動一個 headless Chromium、建一條 WebSocket...

前情提要 我的 LINE Bot 一直有個摘要功能：丟一個網址進去，它爬完內容、產一段摘要，附上社群貼文草稿跟儲存書籤的按鈕。這個功能從 2024 年就在了，但它解決的始終是「這篇在講什麼」，而我常常想知道的是另外三件事： 這篇文章講的東西，背景脈絡是什麼？它的說法有沒有其他人反駁過？裡面那些數字，是有出處的還是作者自己講的？ 摘要回答不了這些，因為摘要的輸入就只有那篇文章本身。模型手上沒有其他材料，你叫它「批判性分析」，它只能在原文裡繞圈圈，或者開始編。 Google Search Grounding 剛好補的就是這一塊。我在 之前那篇文章 裡用它做過搜尋助手，那時候用途是回答問題；這次我想試的是另一種用法：把一篇既有的文章丟給模型，讓它自己去搜尋文章外的資訊，然後回頭審視這篇文章。 成果是摘要卡片上多了一顆「📄 詳細研究報告」按鈕，按下去大約一到兩分鐘後，Bot 會推一個網頁連結給你。 主要 Repo：https://github.com/kkdai/linebot-helper-python 為什麼是 Grounding，而不是自己串搜尋 在 Grounding 之前，要讓模型讀到網路上的即時資訊，得自己搭一條管線：先請模型從文章裡抽出關鍵字，拿關鍵字去打搜尋 API，把搜尋結果的網頁一個個爬回來，塞進 prompt，再請模型總結。三次以上的 API 呼叫，每一段都可能斷，而且關鍵字抽得好不好，直接決定後面撈到的東西有沒有用。 Grounding 把這整段收進模型內部。你在 GenerateContentConfig 裡掛一個 google_search 工具，剩下的模型自己處理：它自己決定要不要搜、搜什麼、搜幾次，搜完自己判斷哪些結果值得用。 對「研究報告」這個題目來說，模型自己決定搜什麼這件事特別有價值。我在寫 prompt 的時候並不知道使用者會丟什麼文章進來，自然也寫不出該搜哪些關鍵字。但模型讀完文章之後知道，它會去找這個主題的來龍去脈，也會去找有沒有人持相反意見。 另一個我很在意的優點是引用來源會跟著回來。模型回應的 grounding_metadata 裡帶著它實際參考過的網頁，標題跟網址都有。這代表報告裡「根據其他報導」那幾句話，不是模型憑印象講的，而是有對應網頁可以點過去查。做資訊類的產品，這個差別很大。 抽來源的程式碼在 loader/langtools.py，寫得防禦一點，因為沒有觸發搜尋時這些欄位整串都不存在： def _extract_grounding_sources(response) -> list: """從 grounding metadata 抽引用來源（同 chat_session 的作法）。""" sources = [] try: if getattr(response, 'candidates', None): candidate = response.candidates[0] metadata = getattr(candidate, 'grounding_metadata', None) chunks = getattr(metadata, 'grounding_chunks', None) if metadata else None for chunk in chunks or []: web = getattr(chunk, 'web', None) if web: sources.append({ 'title': getattr(web, 'title', '') or '', 'uri': getattr(web, 'uri', '') or '', }) except Exception as e: logging.warning(f"Failed to extract grounding sources: {e}") return sources 系統架構 整條流程從摘要卡片上的按鈕開始，中間經過一次重新爬取跟一次 grounding 呼叫，最後以臨時網頁收尾。 graph TD A[使用者傳送網址] -->|摘要 Flex Bubble| B[📄 詳細研究報告 按鈕] B -->|Postback 帶 bookmark doc id| C[驗證書籤所有權] C -->|立即 Reply 研究中| D[LINE 聊天室] C -->|背景任務| E[load_url 重新爬取原文] E --> F[Gemini...

前言: 起點是一個誤會。 我看到 Gemini API 文件多了一頁 Omni，介紹一個叫 Gemini Omni Flash 的模型，寫著「原生多模態，同時處理文字、圖片、聲音與影片」。我的第一個念頭很直接：那我把手機裡一整個資料夾的影片跟照片丟進去，讓它先看懂每個素材在拍什麼，再用一句話叫它剪成一支短影片，不就是一個剪片 App 了？ 翻完文件發現我理解錯了，而且錯的剛好是最關鍵的那一點。但繞過那個限制之後，剩下的部分是真的做得出來的，成品是 ReelCraft：一支 Python CLI，把一包影片照片丟進去，Gemini 3.7 Flash 逐個看懂素材、提出剪輯建議，我確認過剪輯清單之後，ffmpeg 剪成 9:16 直式短影片，配樂用 Lyria 3 生成，字幕自動燒上去。 中間有三個問題是 ffmpeg 跟 Gemini 都回報成功、輸出卻是錯的，那種只有真的把影片播出來看才會發現的類型。 TL;DR 本篇文章會依序介紹： Omni Flash 不是我以為的那個東西 繞過限制：逐檔理解，再用文字彙整 把 edl.yaml 當成人工確認點 換上 Gemini 3.7 Flash 之後差多少 配樂：Lyria 3 走的是另一套 API ffmpeg 會安靜地剪錯給你看 字幕：兩個只有真的燒出來才看得到的問題 其他幾個坑 結論 參考連結 Omni Flash 不是我以為的那個東西 Gemini Omni Flash（gemini-omni-flash-preview）是影片生成與編輯模型，走的是 Interactions API，可以用自然語言對一支影片做效果編輯，例如「當人碰到鏡子時，讓鏡子像液體一樣漂亮地波動」。它不是拿來「看懂一堆影片」的工具。 限制那一段寫得很明白： Referencing or reasoning across multiple videos is not supported. Attempting multi-video prompting may result in degraded model performance or unexpected outputs. 另外還有一條： Video references up to 3 seconds in duration are accepted by the API schema but are not correctly processed by the model at this time. 所以「丟一堆影片進去讓它自己看懂再剪」這條路，在 Omni Flash 上直接被堵死。真正能做多影片理解的是一般的 Gemini 模型：2.5 之後單次請求最多可以帶 10 支影片，1M context 在預設解析度下大約吃得下一小時的長度，而且可以逐秒 tokenize，輸出帶時間戳的場景描述。 這個誤會花掉的時間不算浪費。查證的過程剛好把「哪件事該由哪個模型做」分清楚了，架構也就跟著定了。 繞過限制：逐檔理解，再用文字彙整 整條 pipeline 拆成五個階段，狀態全部落在檔案上： [素材資料夾] │ poc ingest 掃描影片/照片 → catalog.json ▼ │ poc analyze 每個檔案各自呼叫 Gemini → analysis/*.json ▼ │ poc plan 彙整所有分析結果，一次呼叫產生剪輯建議 ▼ →...

痛點：每打一個指令，都要重新來一次 平常用 Claude Code 處理事情的時候，一直有兩個小摩擦一直在，只是還沒認真處理過。 第一個是 shell 本身太陽春：~/.zshrc 裡除了兩行 PATH 什麼都沒有，沒有自動完成、沒有指令記憶，翻歷史只能一路按上鍵慢慢找，找到類似指令還得手動改。第二個是跟 Claude Code 協作時，一些明明是唯讀、完全不會有副作用的指令（列檔案、查版本、curl 個 README），每次都要跳出來按一次允許，一來一回打斷節奏。 這篇記錄的就是一次把這兩件事一次盤點掉的過程：怎麼選工具、踩到什麼坑、以及最後怎麼跟 Claude Code 的權限系統對接起來。 解法一：先讓 zsh 自己記得你打過什麼 沒有裝 oh-my-zsh，也不想為了兩個功能扛一整套框架，所以直接挑最小夠用的兩個套件： zsh-autosuggestions：打字時用灰色文字提示之前打過的類似指令，按 Ctrl+空白鍵 或 → 接受 zsh-completions：補強 tab 自動完成的涵蓋範圍 brew install zsh-autosuggestions zsh-completions 再搭配歷史紀錄設定，讓上下鍵可以依照目前已輸入的內容去篩選歷史，而不是整批往前翻： # --- 指令歷史紀錄設定 --- HISTFILE=~/.zsh_history HISTSIZE=10000 SAVEHIST=10000 setopt SHARE_HISTORY # 多個終端機視窗共用歷史紀錄 setopt HIST_IGNORE_DUPS setopt HIST_IGNORE_ALL_DUPS setopt HIST_FIND_NO_DUPS setopt INC_APPEND_HISTORY # 指令一輸入就馬上寫入歷史檔 autoload -Uz up-line-or-beginning-search down-line-or-beginning-search zle -N up-line-or-beginning-search zle -N down-line-or-beginning-search bindkey "^[[A" up-line-or-beginning-search bindkey "^[[B" down-line-or-beginning-search 裝完套件、加完設定，理論上重開終端機就能用了——實際上沒有這麼順利。 解法二：補顏色，讓終端機看得更快 自動完成裝好之後，順手把顏色也一起補了： zsh-syntax-highlighting：打指令時即時上色，有效指令綠色、無效指令紅色 ls -G：資料夾、執行檔、連結各自不同顏色 grep --color=auto：比對到的關鍵字直接標紅 export CLICOLOR=1 export LSCOLORS=GxFxCxDxBxegedabagaced alias grep='grep --color=auto' source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh 字體也一起處理：Ghostty 的設定檔（~/Library/Application Support/com.mitchellh.ghostty/config.ghostty）原本沒指定字體大小，吃系統預設的 13，直接加一行 font-size = 16 解決。 解法三：把 ls、cat、cd 也換成更聰明的版本 顏色跟自動完成算是基礎建設，接著補了三個常用指令的現代化替代品，選擇標準只有一個：單一執行檔、沒有背景常駐程序，不會拖慢啟動速度。 指令 替代品 換來什麼 ls eza --icons 彩色、圖示、樹狀結構（lt） cat bat --paging=never 語法高亮、行號 cd（輔助） zoxide 記住常去的資料夾，z proj 直接跳過去 fzf 這次評估後沒有裝——目前的使用習慣還沒有到需要模糊搜尋歷史/檔案的程度，等真的有感覺卡再補。 解法四：讓 Claude Code 搜尋、比對檔案更快 前面幾項是「人用得爽」，這一項是「Claude Code 用得快」。Claude Code 內建的搜尋工具本身就是用 ripgrep（rg）在跑，jq 也已經裝了，所以缺的是這三個： fd：取代 find，語法簡單、速度快，列檔案清單特別有感 ast-grep：結構化程式碼搜尋，不是純文字比對，而是看語法樹（AST）。可以搜「所有呼叫某函式且第一個參數是字串的地方」，對大範圍重構或精準搜尋特定寫法比 regex 準確很多 difftastic（difft）：語法感知的 diff，函式搬位置也看得出來只是移動，不是整段被砍掉重寫 brew install fd ast-grep difftastic git-delta git-delta 主要是給人看 git diff...

前言: Feedly 改版之後，介面我一直不習慣，尤其是懷念舊版 Feedly Classic 那種一欄式、資訊密度高、不拖泥帶水的閱讀節奏。訂閱的來源裡有不少英文、日文、韓文的技術部落格，每次要嘛開分頁丟去翻譯、要嘛乾脆跳過，久而久之這些來源就變成已讀不回。 與其繼續將就，我花了一個週末，自己刻了一個 RSS 閱讀器：FeedFlow。手機瀏覽器優先、深色主題、多欄位檢視模式，這部分是在向 Feedly Classic 致敬；資料存在 Google Firestore，帳號綁 LINE Login；訂閱到的非中文文章，背景會自動用 Gemini 2.5 Flash 翻成繁體中文。目前已經部署在 Cloud Run 上面，自己每天在用。 這個 repo 會持續開發下去，這篇是系列文章的第一篇，先把整個專案的骨架、幾個關鍵決策的來龍去脈記錄下來。 TL;DR 本篇文章會依序介紹： 為什麼要自己刻一個 RSS 閱讀器 LINE Login 在這個專案裡代表的意義 RSS 閱讀器的開發過程：從單機 MVP 到多使用者雲端同步 為什麼選 Gemini 當翻譯引擎，中間踩了哪些坑 前端介面：四種檢視模式與行動裝置優先設計 意外的插曲：把洩漏的密鑰從 git 歷史裡挖乾淨 目前進度與下一篇的方向 結論 參考連結 為什麼要自己刻一個 RSS 閱讀器 市面上不缺 RSS 閱讀器，但我要的東西很具體：手機上開起來要快、介面資訊密度要高（不要每篇文章都用一張大圖佔掉整個螢幕）、然後外文來源要能就地翻譯，不用切換到別的分頁。這三個條件湊在一起，現成的服務沒有一個完全符合，尤其是「非中文文章自動翻譯」這件事，幾乎沒有閱讀器把它當一等公民做。 專案取名 FeedFlow，核心就三塊：後端一支 Express（server.js），負責抓 RSS、解析內容、呼叫 Gemini、讀寫 Firestore；前端是純 Vanilla JS 的 ES Modules（app.js、store.js、api.js、i18n.js），沒有套框架；資料庫用 Firestore，帳號則是 LINE Login。整個 MVP 第一版就把訂閱管理、資料夾分類、四種檢視模式、深色主題全部生出來了，後面的每一版都是在這個骨架上加東西。 LINE Login 在這個專案裡代表的意義 我之前寫過 如何透過 Golang 開發 OAuth2 的 PKCE，講的是 LINE Login 導入 PKCE 的實作細節。那時候是把 LINE Login 當研究對象在拆解協定；這次在 FeedFlow 裡，LINE Login 換了一個角色——它是整個多使用者架構能不能成立的關鍵。 FeedFlow 最早其實沒有帳號系統，資料就存在瀏覽器的 localStorage，換一台裝置訂閱就不見了。要做雲端同步，第一件事是要有一個穩定的使用者身份，而且這個身份要能在 Firestore 裡當 document 路徑的 key（users/{userId}/...）。比起自己刻一套帳號密碼系統，直接用 LINE Login 換來的 LINE User ID（sub claim）當這把 key，省掉了整套密碼、驗證信、忘記密碼流程，對一個個人專案來說划算很多。 這個決定也不是一次到位的。最早的版本其實是偷懶版：讓使用者自己貼一段 LINE UID 字串進去，後端只是拿去當 Firestore key，沒有做任何身份驗證——這樣的「登入」等於任何人都能冒充任何一個 UID。下一版才換成正規的 LINE OpenID Connect：標準的 OAuth 2.1 授權碼流程，拿到 id_token 之後用 LINE 的 /oauth2/v2.1/verify 驗證簽章，session 存在 HTTP-only cookie，而不是塞在網址參數裡到處跑。再之後又補上 state 跟 nonce 檢查，擋掉 CSRF。這個「先求有、再求對」的順序，某種程度上也反映了個人專案常見的節奏：先把功能兜起來確認方向對不對，安全性的坑等看得到需求了再回頭補。 因為主要使用情境是在 LINE 裡分享連結、在 LINE 內建瀏覽器打開，所以除了標準的 OAuth 重導向，也整合了 LIFF SDK，讓使用者如果是在 LINE App 裡開啟，可以直接用 LIFF 的 SSO...