亞瑟 ASK - 職涯隨筆與生活漫談

去年我曾經寫過一篇文章，介紹自己第一次用 AI 幫忙做出來的小工具： AI 語音轉文字格式太亂？獨創免安裝小工具「Remove Text Extra Spaces」幫你一鍵搞定！ 。 現在回頭看，那篇文章對我來說其實很有紀念價值。因為那幾乎就是我第一次真的把「我腦中的想法」，透過 AI 協助，一步一步做成一個可以用的程式。 但老實說，如果用今天的眼光回頭看，當時那種做法，其實還是很早期的 Vibe Coding。 那個時候大多還是靠線上的 AI LLM，例如 ChatGPT。你想到一個功能，就先跟 AI 描述需求。AI 回你一段程式碼。接著你再自己複製、貼上、回到本機、執行、報錯、貼錯誤訊息、再回去問 AI。很多時間不是花在做功能，而是花在來回搬運資訊，還有自己亂試、亂猜 bug 到底在哪。 講白話就是，那時候 AI 比較像是一個「很會給建議的遠端顧問」。它可以幫你想，幫你寫一段 code，可是它看不到你電腦上實際發生了什麼事。很多最後的苦工，還是得你自己扛。因為線上的 AI 就會出一張嘴。 一年後再回頭看，整個協作方式真的差很多 到了現在，我自己最有感的變化，其實不只是模型更強，而是 AI 協作的形式已經不一樣了。 現在很多工具已經不是單純的聊天型 AI，而是更接近本地 AI Agent。它不是只會跟你對話，而是真的可以進到你的工作現場，直接看專案、看檔案、看錯誤、幫你修改、幫你驗證。 我自己覺得目前很值得關注、也很值得實際試用的 AI Agent，包含像是： OpenAI 的 Codex Anthropic 的 Claude Code Google 的 Gemini 或 Antigravity 開源的 OpenClaw 這些工具的共同特點就是，它們不只是「回答問題」，而是可以直接參與工作流程。 這個差別其實非常大。 以前你要花很多時間跟 AI 解釋： 我現在資料夾裡有哪些檔案 哪個版本才是最新的 錯誤訊息長什麼樣 GUI 到底跳出了什麼畫面 哪裡改了之後又壞掉了 現在如果是本地 AI Agent，它很多時候可以自己直接去看。 它可以直接讀你的程式。 它可以直接修改程式。 它可以直接跑測試。 它可以直接幫你整理 README。 它甚至可以一路幫你把 GitHub repo、Release、打包執行檔都處理...

我在 2025 年 4 月，曾經在  課程邀約好亂怎麼辦？教你一套職業講師必學的行程管理自動化流程   這篇文章介紹過當時還叫 Dola AI 的行程安排工具。它後來改名成 Toki AI ，核心概念其實很吸引人，就是把行程建立這件事，變得像在聊天。 你可以 直接丟文字、傳語音、貼截圖，讓它幫你辨識日期、時間、地點，然後直接建立到 Google Calendar 。對很多人來說，這種體驗真的很直觀，因為你就像在跟一個懂你意思的小幫手講話。 後來到了 2025 年 11 月，我又寫過另一篇文章， Toki（原 Dola AI）開始收費怎麼辦？教你用 Gemini 取代行程自動化功能 ，談 Toki AI 開始改為收費之後，如果你想找替代方案，其實可以考慮 用 Gemini 串接 Google Calendar ，做到類似效果。 不過，後來也有朋友跟我回饋，說 Gemini 雖然可以用，但它還是有幾個地方，很難完全取代 Toki。 因為 Toki 的整體使用感受很順暢： 第一，它的操作入口很固定。你平常本來就在 LINE 或其他訊息工具裡面，直接打開對話框就可以用了。 第二，它的使用節奏比較輕。你把訊息送出去之後，就可以去做別的事，不太需要一直停在同一個畫面等它。 第三，它的互動方式很直觀。你不太需要先想今天要不要切換到哪個 Gem，或是先找到某個固定對話。 不過如果我們把角度再拉高一點，問題其實就不只是「哪個工具比較像 Toki」了。 現在已經有很多 AI Agent 工具，真正值得想的事情反而是：我們可不可以不要只找替代品，而是直接做出一個更完整、更能配合自己工作流的 AI 助理？ 我最近實際把 OpenClaw 串接 Google 服務 後，我會說，這條路其實比單純找 Toki 替代品更值得投資。 原因很簡單。Toki 處理的是聊天式的排程功能，Gemini 處理的是原生 AI 加上 Google 生態系的特定能力，但 OpenClaw 加上 gog skill 之後，處裡的其實是另一個層次的問題。 它不只是能幫你建立 Google Calendar 行程而已，而是可以把 Google Calendar、Google Tasks、Gmail、Google Drive、Google Contacts、Google Doc...

  如果你有在接觸 AI 工具或簡報製作，這兩年來應該被很多 AI 製作簡報的工具疲勞轟炸。 從去年八月起至今，由於 Google 的 Nano Banana 圖像生成模型的誕生，很多人開始大量利用 NotebookLM、Gemini，或其他 AI 工具快速把內容整理出來，再搭配生圖，把一份簡報很快地做出一個「看起來很漂亮」的版本。 這條路當然有它的優點。 快，真的快。 畫面有時候也真的蠻好看。 可是你真的開始用，就會發現另外一個問題。 圖片也許漂亮，氣氛也許有了，但文字內容不一定那麼好改，很多時候會是內嵌圖片。 如果你後面想微調段落、重寫某一頁的標題、補一段說明，常常就沒有想像中那麼順，可能還要換平台轉檔或圖片OCR轉字或用遮罩覆蓋上字等方式。 更不用說，如果你希望它不是只有一張一張靜態頁面，而是比較像互動式、可部署、可公開分享的簡報頁，那條路又更繞。 另外，傳統 PowerPoint 也有一個很現實的問題。 如果你的簡報圖很多、檔案很大，事後不管是寄 Email、丟雲端，還是拿隨身碟複製，其實都沒有那麼輕鬆。 你做完是一回事，分享出去又是另一回事。可能還需要壓制轉換成沒有動畫效果的PDF檔才方便傳送。 但如果把簡報變成 HTML，就完全是另外一種感覺。 檔案通常小很多。 如果是公開頁面，甚至只要給一個超連結，大家就能直接看。 你不用擔心對方有沒有安裝 PowerPoint，也不用擔心版本跑掉。 對分享這件事來說，這其實方便很多。 我最近注意到的一個工具，剛好就是走這條路。 它叫做  frontend-slides 。 這個工具最有意思的地方，不是 AI 幫你先寫一份投影片講稿。 而是 AI 直接把內容做成一份可以在瀏覽器裡播放的 HTML 簡報。 講白話一點，這不是「AI 幫你列 bullet points」。 比較像是「AI 幫你把內容做成一個簡報型前端頁面」。 frontend-slides 是什麼 zarazhangrui/frontend-slides  本身是一個以 Claude Code 為主要使用場景設計的 skill / 專案工具。 它的核心能力簡單來說包含： 把一份主題內容轉成動畫感比較強的 web slide 輸出成單一 HTML 檔 CSS / JS 都能內嵌，不用另外拉一堆 build tool 可從零生成，也...

這兩天我不經意打開 Google，輸入了「 亞瑟 ASK 」這個關鍵字。沒想到，竟然意外看到了我的 部落格首頁 出現在 Google 搜尋結果裡。 老實說，看到那個畫面的當下，我真的有點不敢相信自己的眼睛。因為這件事，我已經等了一年又四個月。 我的部落格是在 2024 年 12 月 23 日成立 的。剛成立那幾天，其實我很快就在 Google 搜尋裡看過自己的首頁。那時我還覺得這很正常。畢竟 Blogger 本來就是 Google 自家的平台，理論上應該不會有什麼問題。 但沒想到，大概過了一兩個月，到了 2025 年 2 月左右，我突然發現 Google 搜尋裡完全找不到我的部落格了。不是排名掉後面而已，而是不管輸入部落格名稱、網址名稱，甚至各種相關關鍵字，都完全看不到。 奇怪的是，其他搜尋引擎像 Bing 、 Yahoo ，反而一直都搜尋得到，而且收錄速度還很快。只要我發表新文章，通常隔一天左右就能被搜尋到，關鍵字排名也常常還不錯。 這就讓人更挫折了。 因為這代表網站本身大概不是壞掉，也不是內容根本沒人看，而是偏偏在最重要的 Google 搜尋裡，它就像不存在一樣。大家都知道，Google 長年掌握了絕大多數搜尋流量。某種程度上，如果你的網站沒有被 Google 收錄，幾乎就等於在網路上隱形。 所以從 2025 年 3 月初開始，一直到 5 月，我花了非常多時間在研究這件事。 那段時間，我幾乎把能查的方法都查過一輪。像是  Google Search Console 、Sitemap 提交、網址審查、robots.txt、重新導向錯誤、canonical 標記、行動版網址、SEO 設定，我都一路查下去。 網路上有人建議要改提行動版網址格式，也有人建議刪除原本的 sitemap 重新提交，或者更換 Blogger 版型。我也都試過。連 sitemap 也不只是送一種格式，標準 sitemap 跟 Atom sitemap 都有送。當時也查了 HTTP 狀態碼、redirect 狀況，甚至還看過是不是有哪裡不小心擋到爬蟲。 講白話，那兩個月我真的花了很多力氣再折騰如何被 Google 索引這件事。 但結果是，該試的都試了，Google 還是沒有把我的部落格帶回搜尋結果裡，根本就是不屑。 後來我印象很深的是，我看到一篇文...

  這兩天我剛好挖到一個滿有趣的小工具，叫做  pdf-presenter 。 它做的事情其實很單純，但很實用。講白話就是，讓 PDF 也能用接近 PowerPoint Presenter View 的方式來簡報。也就是說，觀眾看投影片，你自己則看到另一個簡報者畫面，上面有目前頁、下一頁、講稿備註、計時器，甚至還有一些額外控制功能。 我第一眼看到的時候，真的有一種「這個想法很聰明耶」的感覺。因為我們平常很多簡報，最後流通出去的格式其實都是 PDF。PDF 的好處大家都知道，分享方便，跨裝置也比較不容易跑版。可是它一進到簡報情境，體驗往往就掉一截。你可以把 PDF 打開來播，但通常就只是把投影片一頁一頁切過去而已。你沒有像 PowerPoint 那種成熟的簡報者檢視，也沒有那種「觀眾看一套、自己看另一套」的控制感。 所以這篇文章，我想做兩件事。 第一，我想介紹這個工具本身，因為它真的解決了一個很實際的痛點。 第二，我也想分享一下，我後來為什麼乾脆用 vibe coding 幫它包了一個更適合 Windows 一般使用者的入口，讓它從一個「很有趣的 CLI 工具」，變成一個我自己真的會繼續用，也比較敢推薦給別人的版本。 PDF 很常是最後交付格式，但簡報體驗常常卡住 這件事其實很常見。 很多簡報在製作階段也許是 PowerPoint，也可能是 Keynote，甚至有些是從其他工具匯出來的。但到了最後要寄給別人、要留存、要跨裝置分享時，大家通常還是會落到 PDF。因為 PDF 穩，格式固定，也比較不怕對方沒有原本那套軟體。（當然還有很多情況是 speaker 或主辦方就是不想給原始 PPT，例如很多醫學會議的簡報檔......） 問題是，PDF 雖然很適合「交付」，卻不見得很適合直接拿來「上台簡報」（當然這或許也就是提供方只想給你PDF 的原因....）。 最常見的卡點大概有幾個。 第一，它通常只有單一畫面。你如果直接用 PDF 閱讀器開，大多數情況下就是看到一頁投影片，然後翻下一頁。 第二，它不像 PowerPoint 那樣有現成的 Presenter View。你不太容易同時看到下一頁、講稿備註、時間控制。 第三，如果你想把 PDF 再轉回 PowerPoint 或其他簡報格式，往往又得靠另外的軟體，而且轉檔之後還不一定完全穩，版面、字型、圖片都可能...