前言

每年的 COSCUP，都是台灣開源社群重要的年度盛會，也是一個讓不同領域的開發者交流技術、分享實作經驗的舞台。

今年，LINE 的工程師也再次站上 COSCUP 2026 的講台，從 AI × Web3 資安，到 Coding Agent × 開源貢獻，帶著平時工作與技術探索中累積的經驗，和社群分享真實的實作過程。

而一場技術分享的收穫，往往不只發生在台上的幾十分鐘。從準備題目、重新梳理技術，到現場交流與會後反思，每一次登台，也都是重新理解自己所做之事的機會。

這次，我們邀請兩位講者 Aaron 與 Dong，從各自的視角記錄這次 COSCUP 的分享與心得，一起來看看他們在這趟旅程中有哪些收穫與新的思考。

Aaron- 

【講者心得】當 AI 學會當白帽駭客：COSCUP 2026 登台回顧與反思

作為今年的 COSCUP 講者，能夠站上這個開源界的年度盛會，與眾多熱愛技術的開發者分享在 Web3 資安與 AI 結合的探索，對我而言是一趟充滿挑戰與感動的旅程。這次我的講題是「當 AI 學會當白帽駭客 – 從鏈上漏洞掃描到資金救援的全自動 Pipeline！」，深入探討如何利用 AI Agent 打通從發現漏洞到實際行動的防禦流程。

在準備這場演講的過程中，我們反覆梳理了智慧合約安全防禦的痛點。過去，業界多半依賴週期性的靜態審計，但在瞬息萬變的區塊鏈世界中，「找到一個漏洞」往往不等於「能阻止損失」。因此，我決定將重點放在系統架構中最困難的一環：如何讓 Agent 從潛在漏洞推進到可利用的 PoC（概念驗證），並進一步將其轉換成真正可部署的救援合約。為了讓聽眾容易理解，講座中挑選了可能造成資金損失的具體漏洞（如：重入攻擊）作為案例，深入剖析 Harness Engineering 的實作細節，探討 Agent 如何推理漏洞的可利用性、獲取鏈上狀態，並透過模擬驗證攻擊是否成立。

演講當天，看著台下專注的眼神，我深刻感受到大家對自動化防禦技術的期待。當我展示 Agent 如何自動評估真實經濟影響，並產出資金救援執行計劃以降低損失時，台下熱烈的迴響給予了極大肯定。這證明了這個願景：「讓智慧合約安全從週期性的審計，走向持續、端到端的防禦營運」，正是當前 Web3 領域迫切需要解答的難題，也是社群關注的焦點。

最讓我驚喜的是會後的交流時間，會眾針對 Model Access、救援合約的安全邊界提出了非常犀利且專業的問題。這些來自不同技術領域的觀點，是 COSCUP 最迷人的地方，展現無私分享、跨界碰撞的開源精神。

回顧這次登台，我不僅是一位知識的傳遞者，更是受益良多的學習者。感謝 COSCUP 2026 提供這個舞台，也感謝每一位參與這場議程的朋友。

期望有機會繼續在 AI 與 Web3 資安的交界處深耕，帶著更成熟的系統，於未來再次與社群分享！

Cheers,
Aaron Yeh

Dong- 

今年的 COSCUP，相較於去年的技術分享，我選擇嘗試一種對我來說全新的演講型態，也就是 live coding。

我帶上台的不是一段專門為展示準備的範例，而是 Zed 裡一個真實存在，而且我也希望它能被實作出來的 issue。

相較於大型的架構重構，或牽涉底層 shader 的 rendering bug，這個 issue 很小。它要解決的問題，是讓 project panel 裡的資料夾同時顯示 folder icon 和表示展開狀態的箭頭。這樣的題目正好很適合這次的議程，因為它夠具體，也夠直觀，只要用過 project panel，大概都能立刻理解它想解決什麼，以及完成後預期會長什麼樣子。

不過，看懂一個 issue，和知道怎麼把它實作成一份可以送出的 PR，還是兩件不同的事。這中間的距離，或許也是它在 issue list 裡停留兩年多的原因之一。

Issue 可以告訴我們使用者看見了什麼，哪裡不太對勁，或哪個功能還不完整，但它不會告訴我們對應的程式碼在哪裡、既有行為背後有什麼設計考量，也不會告訴我們一個看似簡單的 feature request，該怎麼融入專案原本的架構與設計。這也是我想在 COSCUP 上和大家一起處理這個 issue 的原因。

這次議程裡，我不想展示一個已經知道標準解答的 perfect example，而是想和大家一起走過，當一個真實問題被帶進陌生 codebase 時，這段過程實際上會是什麼樣子。

我想示範的不是 prompt 變成 PR

這次議程的題目，我選了〈帶上你的 Coding Agent，我們現場替 Zed Editor 送一個 PR 吧〉。光看題目，可能會以為這是一場 vibe coding 的 showcase，把 issue 丟給 agent，讓它自生自滅，最後產生一份 PR。

但我想做的，其實從來都不是這樣。

在 coding agent 成為日常工具以前，一份 PR 出現之前，往往得先經過很多不會被記錄下來的工作。我們得先讀 issue、翻文件、在 codebase 裡找入口、比對相似的實作，慢慢建立對專案的理解。這些所花時間不會寫進 PR description，也很少能從最後的 commit 看出來，但它們往往決定了一個改動是否真的建立在對專案的理解之上。

這才是我想在這場議程裡帶給大家看的部分。

當我對一個 issue 有興趣，卻還不熟悉這個專案時，coding agent 能不能幫我從零開始建立這些脈絡，讓「我不知道該從哪裡看起」慢慢變成幾個更具體的問題。這也是為什麼即使我事前已經大致知道這個 issue 可能的修改方向，現場我仍然沒有一開始就要求 coding agent 直接動手實作，而是先讓它協助搜尋可能相關的程式碼，梳理目前程式碼中的行為，然後沿著它找到的線索繼續追問。

在這個過程中，agent 不會直接給出一份可以照單全收的正確答案。有時它提出的方向還需要再確認，有時它會把問題帶到我原本沒有注意到的地方。原本看起來只是 project panel 的一個小調整，往下追之後，卻還需要確認設定與既有行為之間的關係，也得思考使用者是否能在 Settings UI 中找到對應的選項。這些事情未必複雜，卻也不是我們可以在看到 issue 的第一眼就發現的。

我想展示的不是 prompt 如何變成 PR，而是帶著 agent 在 issue 和 codebase 之間來回，如何讓一個原本只有需求描述的問題，慢慢變成一個自己能理解，也能繼續往下處理的改動。

沒有在台上送出的 PR

俗話說的好，原本的 outline 預計是要在議程中完成並送出一份 PR。

為了確認這個題目適合 live coding，我在上台前其實已經完整走過一次實作，也大致知道它可能會往哪個方向修改。不過，我不想把事前得到的答案直接搬到台上，再讓 agent 照著重播一次。對我來說，live coding 的意義正是要把平常容易被藏在準備過程裡的探索、判斷與不確定性，留在現場。

因此，實際進行時，現場把不少時間花在實作以前的事情上。我們從 issue 出發，找到相關程式碼，確認目前的行為，再針對 agent 提出的方向反覆追問。我想讓大家看見的，正是這樣的過程。一個看似很小的 issue 被帶進陌生 codebase 後，不會立刻變成一段需要修改的 code，而是會逐漸長出更多需要確認的問題。

等到開始動手實作時，演講時間已經接近尾聲，所以這場 live coding 最後停在剛開始實作的地方，沒有真正送出 PR。我不想為了替演講留下一個完整的結尾，就把還沒完成、也還沒有驗證的改動直接送出去。演講結束後，我沿著現場整理出的脈絡繼續完成實作與確認，最後才把 PR 送出。

演講之外的工作，並不只是把台上未完成的 demo 補完而已。台上花的時間，讓我逐步看見這個 issue 背後有哪些既有行為、哪些假設還需要確認，而演講之後的實作與驗證，則是把這些線索逐一落實成具體的改動。它們其實是同一段過程的不同階段。

我想透過 live coding 呈現的，也是這件事。真實的開發很少是先得到一個完整答案，再把答案輸入 editor。更多時候，答案是在追查、實作、驗證，甚至回頭重新理解原始問題的過程中慢慢成形。Coding agent 可以幫助我更快開始這段探索，也能讓我在遇到不確定的地方繼續問下去，但它不會把這些過程從開源貢獻裡刪掉。

當 agent 參與了 PR

這半年來，我一直看到開源社群對 AI-assisted contribution 的擔憂，而我完全可以理解。當一份 PR 有 agent 參與時，maintainer 真正在意的通常不是其中有多少 code 來自模型，而是作者是否理解這份改動、是否驗證過它，以及是否願意在後續討論中繼續處理它。一份未經檢查、沒有驗證，連作者自己也說不清楚細節的 one-shot PR，不會因為它由哪個模型或工具產生，就變得更容易 review 或維護。它最後只會把原本屬於 PR 作者的理解與驗證責任，轉嫁給其他人。

不過，我不認為 coding agent 只能為開源社群帶來這種結果。它也可以在完全相反的方向上發揮價值，不是替作者跳過理解，而是幫忙找到相關程式碼、沿著 code graph 梳理現有設計，或指出實作中可能被忽略的地方。這些工作不一定會讓 PR 立刻出現，卻能讓想參與開源的人更清楚自己正在做什麼，也更能讓許許多多害怕自己實力不足的人更勇於跨入開源的世界。Zed 在〈[On Programming with Agents](https://zed.dev/blog/on-programming-with-agents)〉裡提到，`LLMs automate typing, not thinking.` 我很認同這句話，這次 live coding 也剛好把它擺上檯面。Agent 可以幫我搜尋、整理和撰寫草稿，但我仍然需要自己判斷一個改動是否合理，也仍然需要對自己產出的東西負責。

面對一個陌生的開源專案，一開始最困難的地方，往往不是寫下第一行 code，而是建立足夠的脈絡，知道自己正在改什麼、為什麼這樣改，以及還有哪些地方需要確認。Agent 的加入不會讓人瞬間理解整個專案，但它能讓我們從一個具體的問題出發，逐步找到相關的程式碼、設計與討論，並在不確定時繼續問下去。

我想帶給大家的，不是「有了 agent 以後，任何人都可以快速送出 PR」這種不切實際的幻想，而是當你遇到一個自己在意的問題時，它或許能讓你不必只停在 issue 頁面上。你可以試著理解它、嘗試修改它，並在願意對自己的改動負責時，把它帶進真正的開源協作。

結語

從 AI Agent 在 Web3 資安中的應用，到 Coding Agent 如何參與真實的開源貢獻，Aaron 與 Dong 帶來了兩種截然不同的技術實踐，也讓我們看見：一場分享的價值，不只在於把技術成果帶上舞台，更在於把過程中的探索、思考與經驗帶回社群交流。

而今年的 COSCUP，LINE Taiwan DevRel 也沒有缺席。

除了工程師們帶來第一線的技術分享之外，DevRel 也從不同的角度站上 COSCUP 舞台，分享一路走來的實作與經驗，以及如何透過一次次的嘗試，把原本陌生的技術真正變成自己能夠分享出去的內容。

如果你也好奇 DevRel 眼中的 COSCUP，以及這場分享背後的故事，歡迎延伸閱讀：

👉 延伸閱讀｜LINE DevRel @ COSCUP 2026
https://techblog.lycorp.co.jp/zh-hant/coscup-2026-zona

對我們來說，參與 COSCUP 從來不只是「站上台分享」。

從準備議題、實際動手實作，到與現場開發者交流，每一次參與都是一次重新整理經驗、交換觀點，也從社群帶回新想法的機會。

感謝 COSCUP 2026 提供這個讓技術與想法持續碰撞的舞台，也謝謝每一位來到現場、參與議程與交流的朋友。

期待下一次，我們再帶著新的技術、新的實踐與新的故事，回到社群與大家見面！