當 Kotlin 遇上 AI — 打造新聞摘要自動化的實作實錄（背後祕辛）

JCConf 2025

JCConf 投影片：https://docs.google.com/presentation/d/1gIRtPtTauOj-L2TkuEC6Ln8Gz_9hLYFtSkO9gW3_xNw/edit?usp=sharing

這是今年在 JCConf 分享的主題，在本篇文章中，我將介紹跟大家述說為什麼會想要打造一款自動化摘要的工具，並且是如何實作的。

時間回到 2020，我正在從 Java 切換至 Kotlin，因為在那時，Kotlin 成為 Android 的官方語言（拜 Android 與 Oracle 的官司所賜XD）。為了能更快、更有效率的學習 Kotlin，於是找到了 Kotlin 讀書會，而我真的很想要趕快學好，加上秉持著為民服務的精神，就搶著當了幾次的讀書會導讀（當導讀可以學的更快，因為會需要先把該章節的內容搞清楚，導讀時才比較有底氣，不怕被問倒）

也就是在這樣子的機緣下，我認識了聖佑，而在認識多年之後，這次受到聖佑的邀請，與他一起搭檔主講這次的 JCConf，我們因為讀書會而認識，這次的分享也是希望可以對讀書會有些貢獻。

還記得那時候在咖啡廳一番討論後，我們注意到現在讀書會因為沒有持續進行讀書會，大家在上面的討論都是有一搭沒一搭的，除了偶爾會有人轉貼新資訊外，其他時間就是自己去各大網站學習。

所以這次主題的來由：由於 AI 興起，我們希望可以在後讀書會時期，開發一款提供讀書會的朋友能快速取的資訊的服務，有了共識之後，我們便在那天下午快速的在咖啡廳裡面實作一個簡單的功能。

我還記得聖佑負責的是文章摘要的部分，而我是建立一個爬蟲網頁，並將文章放在網頁上。

決定好主題後，因為我們最近真的很忙，可能抽不出太多時間開發，再加上當時 Claude Code/ Gemini CLI 類的 AI 產品推出，讓我想說是否可以使用這些 AI 工具來作為本次開發的主要工具。 不得不說，那天下午的成果就是使用這類的 AI 工具開發出來的 Demo，我們也對這種開發方式充滿了信心與好奇，不知道能夠帶領我們到達什麼樣的境界。

在開始開發之前

在開始動手之前，需要動的是腦跟嘴來定義一個 MVP 產品的架構與待辦事項，而這個 MVP 產品的功能不需要太多，所有花俏的功能都不需要，最重要的是最核心的功能（摘要）打造出來即可。

MVP 規劃

一個專門提供摘要的網頁，最重要的就是資料源，而我們盤點所有抓資料的方式：RSS、爬蟲、API…，於是我們決定先將 RSS 列入第一階段實作的部分，因為 RSS 本身就是提供給外部人員訂閱，所以對於我們用來抓取該網頁的資料是超級方便的。有了資料源後，扣回我們主要做的核心項目 — 摘要，而在一開始我們就打算採用 AI 的方式進行摘要。這部份因為 Spring AI 有提供簡單使用的方式，我們只需要填入模型、API Key 即可使用 Spring AI 提供的方式來使用 AI。除了摘要外，我們同時也使用 AI 協助翻譯，為什麼會需要翻譯呢？因為許多文章來源都是國外網站，為了方便讀者快速閱讀，更容易掌握核心概念，於是也透過 AI 進行翻譯（反正也是在一次查詢就可以得到所有的內容，何樂而不為呢？）

有了文章、摘要、翻譯之後，MVP 的最後一塊拼圖就是將摘要文章發出去，我們思考了幾種作法：設定電子報、推播 LINE 群組，發送 eMail … 因為我們的讀書群是在 LINE 中，於是我們就決定第一種推播的方式是推到 LINE 群組內，再加上推到 Telegram 群組內（因為 Telegram 的推播是免費的，建立推播又很簡單）

設定好 MVP 的目標後，下一件事就是任務的展開以及分配。我們只使用一份 Google 文件，而 Google 文件最大的好處是：免費、可共用，雙方可直接在文件上編輯，不需要任何額外學習的時間。當然啦，用慣 Markdown 的我，有時候使用 Google 文件會有點不太順，但是這都是可以克服的（或是有其他外掛？）

技術棧選擇

我們選擇 Spring Boot 作為框架，因 Spring Boot 在 JVM 是用來開發網頁服務擁有最多資源的框架，而同時 Kotlin 也可以 100% 在 Spring Boot 開發。因我們這次採用 AI 開發工具，Spring Boot 比起其他框架有更多的訓練資料，我們藉此能得到更好的結果。 當然囉，使用 Spring Boot 絕對不是只有 AI 模型已經有大量訓練的好處，除此之外，還有快速開發（開箱即用）、龐大的生態系，搭配 Kotlin 的語言特性，更是可以用更安全（空安全）、簡潔的方式來開發。 以下提供我們使用 Spring Boot 開發的技術選型：

- Language & Runtime: Kotlin 2.1.x + Java 21
- Build Tool: Gradle 9.x
- Framework: Spring Boot 3.5.x
- DB: MySQL 8.1 + JPA/Hibernate + Flyway
- Queue: JobRunr 8.0.x
- AI: Spring AI + OpenAI GPT-4o
- Frontend: Thymeleaf templates

開發

技術架構圖

在這套系統中，可簡單分為兩部分，一邊是提供使用者閱覽的前端頁面，另一邊則是產出每日摘要的背景任務。

產出摘要可以粗略分為四個任務：

1. 抓取資料（Craw Job）
2. 摘要任務（Summarized Job）
3. 每日摘要產生任務（Daily Digest Job）
4. 推送任務（Push Notification Job）

抓取資料

在抓取資料任務中，我們是預先設定好要去抓的資料來源，將其設定在資料庫內，並在每天任務執行時，依照資料庫內的內容來去抓取資料。 這麼做的好處是，在未來任意的增加資料來源，而不會影響先前的任務。當我們處理資料時，會將每一筆資料分開處理，就算遇到抓取資料發生錯誤，也不會影響其他任務。而因為有多種不同的資料來源，所以我們需要在定義資料庫時，需要針對不同的資料來源設定其抓取資料的方式，如 RSS、API、爬蟲…，這方便我們之後再加上相同類型的資料時，可以沿用舊有的設定而不需要另外設定。 在將每個文章內容儲存下來後，為了後續能夠有不同的應用，也為了我們之後可以採用不同的方式來處理這些內容，所以我們會先將資料的原始內容儲存下來。

摘要任務

當原始內容儲存下來之後，接著會透過 AI 的魔力產生文章摘要，在這邊需要特別注意，為了產出固定的格式，我們需要給予嚴格的條件，讓產生摘要的 Prompt 能夠固定的產出每一天的摘要。 在這邊我們會需要在 Prompt 中給予其身分、並要求他將文章的內容作三點的重點，最後需要以 JSON 的格式產出（因為 JSON 格式是容易解析的一種格式），而我們可以在摘要的階段同時對文章作額外的翻譯。 於是，透過正確的 Prompt ，我們就可以每天都產出有相同格式、品質的摘要。

每日摘要產生任務

在前面的步驟中，我們所產生的文章都還是停留在 db 中。將每一個步驟都留存在資料庫的好處是，我們可以針對每一個步驟獨立重複作業，又或者是嘗試作不同的測試。當然囉，如果產品已經上線，而且文章內容很多，我們或許就要考慮是否需要每一個階段的內容都要留存（因為會太佔空間）。 回到每日摘要任務上，我們的目標是不需要重新編譯 Spring Boot，也就是說，我們希望可以設計一個機制，能夠讓有新的檔案產生時，系統就可以直接將內容讀出，而略過重新編譯。 在這邊我們透過將每天更新的檔案放在相同資料夾，並產生不同的名稱來區分，而在程式端我們只要一直監看這個資料夾，即可將新的文章摘要檔案顯示在畫面上。 所以，我們所要做的是，在每天完成摘要任務後，將所有當天產生的摘要，產生成一個 HTML 檔，並將其放到監控的資料夾內。

推送任務

最後一步，也是最重要的一步，當所有的菜色都準備好了之後，我們需要將每日的文章摘要發給所有群組的朋友手上。在這邊我們選擇使用 Telegram/LINE 來發送（因為 Kotlin 在兩個平台都有對應的讀書會群組） 推送到 Telegram 相對來說是比較容易的，不需要額外費用，我們只需要準備 API Key 就可以推送。 反觀，推送至 LINE 群組內則是有許多限制，除了機器人只允許在一般的群組內發送訊息，發送訊息會依照群組的人數來計算封數，而這麼一來我們就會花費大量的傳送費用在 LINE 的推播上。而這邊還不包含使用 LINE 社群無法使用機器人推送。 在發表之前，我們遇到 LINE 群組無法推送，經查是因為額度已滿，最後只好拿出魔法小卡來解決這回合的問題。 不過，我們必須要考慮，我們目前的推送方式是否會太頻繁，以及是否會太花錢。

部署

所有專案的內容都完成之後，我們最後需要將其部署至託管服務器上。而這邊我們選擇的是 Zeabur。Zeabur 是一款現代化的雲端託管服務，我們可以輕鬆的將服務託管在上面，我們只需要授權 github 的存取權，之後只需要在 pr merge 之後，就會自動的部屬。

而因為我們資料庫是分離的，我們需要使用 Docker File 來建立 DB ，在 Zeabur 上，我們也可以輕鬆的建立資料庫，並將所有的參數設定好，我們所需要做的只有將服務與 DB 連接在一起。

由於我們的目標是快速上線，減少人力成本的付出，所以這樣的解決方案令我很滿意。

上線至今

完成這個 MVP 作品之後。我們也在社群群組內推播了一段時間，期間也很感謝群組的朋友給予許多意見，他們對於這個產品都是相關樂觀的，並且表示對他們來說是相當有幫助的，而這也是我們當初要開發這款服務的宗旨。 但，我必須要說，沒有什麼服務是十全十美的，所以我們會持續改善，讓這個產品能夠自給自足，也能夠滿足讀者的期待，讓這款服務能夠讓大家能更快取得 Kotlin 的最新資訊。

最後還是要感謝聖佑，謝謝他與我一起完成這個專案，讓我們對於 Kotlin 社群更有貢獻。 也要感謝所有有使用的各位，你的建議會讓我們的產品更好。

若你對這個作品有想法，可以給予我們回饋意見，也歡迎填寫下方表單，當我們完成郵件通知功能時，會第一步發送給你。

[embed]