跳到主要內容

2016 - 2019 LINE DEV DAY 技術發展

從 2016 年 LINE 開始舉辦 DEV Day 活動至今,已經進入到第四個年頭,每一年都有不同的重頭戲,也讓我們第一次看到了 LINE 這樣亞洲公司在亞洲地區打造出屬於亞太地區專屬於自己品牌的技術形象。

簡易年度記錄

2016 年,LINE 發表了 Chatbot 以及 Open 技術的策略,從那時候開始發表了 armeria 開源技術框架,持續發展至今。
同時當年每個會眾可以拿到一組 LINE Beacon 官方版本,開始了初步 IoT 的佈局。
2017 年,發表了 Clova 項目,以及更多關於 Iot 相關的展示,關於物的連結上,以及對於 Data 上架構的展示,也算是開始進如 Messenge API 調整的一年。
2018 年,建立 LAE 制度,深度開始與開發者進行合作,進行 DevRel 相關,這年 FinTech 大戰開始,同時發表對於 AI 實現於應用上的展示,更值得一提的是 LIFF 的開發與發表。
2019 年,可以說是 AI 年,基本上所有的項目圍繞於 AI 打轉,秉持著原有架構,服務,產品多樣性之餘,已經在這幾年默默的深入到台灣的生活中,大家默默的用著 Chat, 看著 Line News, 用著 Line pay付款買貼圖等。
關於 LINE Dev Day 2019 有更多深入討論。

轉變

2019 年,對於自己來說,是個感覺很深的一年,彷彿經過了再次世代的更替。
從 2012 時所討論的 Cloud System, 當時的討論更多的是在於當地自建機房,還是直接使用雲端服務,從 AWS 服務獨大,到 GCP 深入開發者心中,Azure 當初最不被看好,居然真的擁抱 Open source 在 dotNet core 組合下打下一片天。
2015 年開始,雲端不再是口號,Data 才是王道,到處喊著使用 hadoop ,衝著分散式運算大資料量儲存分析,每個新創都是喊著 Cloud x Data 廝殺著。
2017 年進入 Iot 年代,物物都要聯網,事事都要上網,當時看似傻傻的連冰箱都要上網,到現在似乎已經變成顯學,甚至當年喊著 IPv4 即將用盡,到了 2019 這件事情居然成真。

2019 的新星 AI

LINE Dev Day 2019 從表象上幾乎看不出來新的亮點,沒有太過於全新的產品發表,更多的是著重在於 AI 的發表,和資安的發佈。
從這幾點上,回頭看 2016, 2017 年就已經為了 2019, 2020 結果而佈局,更多的資料,更深入人民的行為結合,更完整的資訊保護,隱私保障。
2017 年正式對外發佈的 Beacon 硬體及 API 的發表,到了現在 2019 有了更多項目的結合,以及 Clova Chip 與不同硬體項目的整合,更多嘗試性的應用,例如台北捷運, LINE NOW 等服務都是 Iot 的展示。
AI 發佈的亮點,從架構面來看反而是產品結構的累積,從開放的角度,擁抱開源的態度,到貼近使用者。
歷經多次資料儲存結構調整,系統優化,架構再次翻新,進而累積出可供 AI Team 參考的使用者回饋,才有辦法打造出真正貼近於實際商品層級的 AI 應用。
從表象上,我們看到的是談論著 AI,背後上是從 4 年前就累積下來的精華, 2019 年的 LINE Dev Day 至少從各種角度和年度累積來說,是玩真的。

AI 與人民生活的距離

很多人都會覺得 AI 離他很遠,可能對於之前的變更來說, Cloud / Data / Infar / 都會是一種很遠距離的感覺,之餘 AI ,他更是改變人們生活的結果。
從 LINE App 裡面的 Smart Channel,到 Line Shopping 裡面的推薦,關聯商品, Line Travel 的資訊給予, LINE Today 的新聞資訊提供,裡面涵蓋著許多 AI 的演算過程,讓結果越來越貼近使用者偏好,讓使用者的黏着度提升。
技術,從某個角度來看就像是空氣,看似很簡單的改變,實際上經過很多不簡單的過程。
當技術存在於生活中,生活就充滿著便利,當它越是便利的時候,人們與技術就越難以分離。

AI Next?

如同當時 Data 與 Application 如何進行整合計畫,在 AI 演算法如火如荼發表的年代,那下一步應該就是 AI 如何與應用工程結合,讓應用的展現更適用於客戶心中。
明年可以預期的會是 AI & Application ,算法與應用落地的一年,會有更多應用及服務的發表,以前難以使用,難以瞭解的計算情境會更為清晰,很多資料與計算變動當中的產業,會越來越有清晰的輪廓,讓開發者有更多新領域的嘗試,再次透過『站在巨人的肩膀』觀看這個世界。

留言

這個網誌中的熱門文章

Vibe Coding:為什麼 Junior 更快上手?Senior 要如何追趕?

現象層面(市場觀察) 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變,非常熱門。 身為 Cympack 產品開發團隊 ,我們也一直關注這個議題,在閱讀這篇文章時觀察到一些有趣的現象,對我們來說,這正好反映出 AI 正在改變開發生態,junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位,其中有些啟發(insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding? 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」,反而 embrace 快速迭代、快速出成果 反觀 Senior: 熟悉大型系統設計 有豐富的「工程正統流程」知識(架構設計、測試策略、效能優化、設計模式) 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師,對 prompt engineering 沒那麼熟練,還在觀望 技能面(未來的關鍵能力) Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢? Prompt 撰寫 / AI 互動 Junior 較強(熟悉 chat-based 流程) 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強(能看出潛在問題) 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding,並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力,但若不主動練習 vibe coding,長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享,希望帶給各位的感受, 『與 AI 協...

Vibe Coding 協作到自建 Dev Agent?從 Claude / Codex 到 OpenHands

過去一年,越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題,到後來很多人愛上 Cursor,直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗,已經大大改變了我們寫程式的方式。 更現實的是,在很多企業內部、政府單位、或涉及機密資料的專案裡, 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理,萬一專案裡有未公開的技術、敏感客戶資料,或是受限於法規 (像金融、醫療、政府標案) ,直接用雲端 AI 工具就會踩 紅線 。  因此,許多團隊反而更希望 「自己架一套 Dev Agent」 ,可以在內網執行,資料完全掌握在自己手上,該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline,全部客製化、安全可控。 這時候,像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手,而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署,從 CLI 操作到瀏覽器查詢, 從多檔案編輯到自動測試,全部都能自己完成,甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說,這是一條 從 「AI 幫你寫一段程式」,走向「AI 幫你解決一整個任務」 的進化路徑。而且,還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」,能模仿人類工程師從建立程式、修改程式碼、執行指令,到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端(OpenHands Cloud)與本地 Docker 運行版本,用戶能配置 LLM(如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用,又或者如果自己本機有 docker 的話,可以自己Local 版本透過 Docker 自架環境。 ...

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例,讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天,大家都在問一個問題: 「我能不能不只問 AI 答案,而是讓它像一位助理一樣,有流程、有反思、還有出處,真正幫我完成一件事?」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ,正是為了解這個問題而誕生。 這套系統到底是什麼? 這個範例不是傳統 Chatbot,而是展示一個完整的 AI research agent : 它會根據使用者的提問,自動發想搜尋關鍵字、查資料、整合重點,最後給出答案還附上引用來源。背後的邏輯設計得非常扎實,不只是能跑,更是具備可讀性、可擴展性與可商用性。 它的流程大致如下:  1. 使用者輸入問題(例如:「抖音是否影響台灣選舉?」)  2. Gemini LLM 幫你想出關鍵字(不只是照抄問題)  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足,自動補查  5. 整合最終答案,並產生 citation(來源說明) 你可以想像這就像一位實習助理幫你寫報告, 不只輸出一段內容,而是會 去查、會判斷、會補資料,而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色? LangGraph 就是整個 Agent 背後的控制系統 。 用白話講,它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查,甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API,而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說,它提供了從 prompt 到流程控制的設計彈性;對產品設計來說,它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構,前後端都幫你整好了,技術選型也非常實用:   前端:Vite + React + TailwindCSS + Shadcn UI  後端:FastAPI + LangGraph...