Skip to content

[心得] WebConf Taiwan 2025 簡短筆記與心得

· 39 min

前言#

這篇簡短記錄上週參加 WebConf Taiwan 2025 的一些零散筆記和心得，因為主辦方有提供共筆，大會的筆記超人們都記得很詳盡，也蠻多講者有提供簡報，因此這裡就片段零散地記一些有印象的～

這兩天很多精彩的議程，沒有每一場都參與到，但我之後有去看共筆和講者簡報，其實蠻多講者要傳達的概念很類似。因此預計這篇的敘述脈絡是，以我有實際參加的議程為主，若該議程提到的與其他議程相關，會一起提出引用，但因為有些是只看共筆&簡報理解的，如果有任何敘述錯誤的，歡迎大家回覆告訴我～

最後可能會簡單列一下喜歡的佳句們🧐！

WebConf Taiwan 2025 主視覺

B2B 服務的 AI Agent 產品設計原則 — 李昆謀#

講者分享了四個公司內部與 AI 有關的故事，四個故事都很精彩！詳細內容可以參考共筆。

其中一個故事是原本希望能用 「AI 後台幫手」協助客戶填寫複雜的行銷活動表單，客戶只要用自然語言描述：「我想要xx活動，優惠是XX…」，AI 助手就會自動填入表單內容，但後來發現在填寫表單時需要考慮很多 context，例如：活動是否符合品牌規範、活動是否重複、商品成本價等，AI 自動填入後還是需要人工檢查各種折扣規範，才能送出，對客戶來說，建立活動還好，但是要檢核各種折價更麻煩。與其讓 AI 生成表單內容，不如讓 AI 協助人們檢核，這是一個從 enhance 到 replace 的轉變，本來是想用 AI enhance 表單填寫，結果是 replace 檢核的工作。

如果你想解決的問題，客戶不認為那是問題，那你就是那個問題。 — Happy Lee

這點可以在後續議程看到類似概念，關鍵不是產品能提供的功能，而是產品能解決的問題是否是客戶的問題。

另一個故事是與 AI 協作開發 PRP (Product Requirement Prototype)，除了共筆還可參考 產品經理到底在忙什麼？AI 時代的新路徑 這篇。過去 PM 所寫的 PRD (Product Requirement Document) 是一個對最終產品的想像投射，PRD 文件透過文字傳達，無法百分之百描述最終的實體樣貌，因此最後團隊的產出常讓 PM 覺得「這不是我要的」。在過去可能要實際產出後才發現哪裡要修改，或是功能不如預期要修改，但現在有 AI 後，PM 可以做出 PRP (Product Requirement Prototype)，利用 AI 快速產出 prototype，在開發初期就驗證需求是否正確，縮短產品驗證週期。

關於 PM 常有「這不是我要的」的感受，除了利用PRP (Product Requirement Prototype)的方式，我第二天有參加小賴老師的「給網站工程師的需求訪談工作坊」，其中也有討論如何溝通與釐清需求。

不寫 JS 也有行雲流水的前端體驗，AI 時代後端工程師的心流開發禪境 — 蘇泰安 taiansu#

講者主要介紹三大點：Tidewave.ai、Phoenix LiveView、實用的函數式編程。

Tidewave.ai 由兩組 MCP 和一個 web app 構成，一組 MCP 是框架組，會告訴模型此專案的各種資訊，例如怎麼找 package、檔案放置位置、如何取得資料庫結構等；一組 MCP 是介面組，做完功能後會自動操作瀏覽器，並驗證功能是否能順利操作，反覆修改直到他認為成功為主。實際使用時，可以一邊和 AI 用自然語言描述需求，AI 一邊在介面上呈現目前修改後的 web 樣貌。它支援 Rails、React、Django、Next.js 等語言，講者當下有 demo 利用 Tidewave.ai 做一個多人打字競賽遊戲，核心功能和畫面都蠻完整的～！有機會想試用看看。

接著是 Phoenix LiveView，第一次聽到這個，先釐清一些相關名詞，相關詞彙有：Elixir、Phoenix 與 Phoenix LiveView。

首先 Elixir 是一個 functional 的程式語言，就像 JavaScript、Python 一樣都是程式語言；而 Phoenix 是一個用 Elixir 寫的 Web Framework，就像 Next.js 是 JavaScript 寫的框架，Django 是 Python 寫的框架，有趣的是我看到 Phoenix 官網說它雖然不是開發者使用率最高的框架，但它是過去三年（2023–2025）開發者滿意度最高的 web 框架！意思是用過的都很喜歡（？

Web frameworks and technologies(資料來源：https://survey.stackoverflow.co/2025/technology/#2-web-frameworks-and-technologies)

Phoenix LiveView 是 Phoenix 的一個套件 / 子框架，也就是這次講題重點，Phoenix LiveView 可以做到「不用寫 JavaScript 的即時互動 UI」，因為它的語言特性天生支援 websocket，web app 運作流程是：

有幾個優點/特性如：

講者表示，在 Phoenix LiveView 開發網頁程式會進入一種「禪淨」，網頁程式只是一個函式，參數是使用者的操作，回傳值是 HTML，透過這種方式，我們就不用自己寫一堆 JavaScript。

再來是以 elixir 介紹實用的函數式編程，elixir 沒有複雜抽象的functor、monad概念，很常用 map、filter、reduce 來開發，但相對難上手和冷門，可善用 AI 輔助，或在小團隊/個人專案時使用。

elixir 有個特色語法是 pattern matching，之前在讀 functional programming 相關文章時有讀過但不知道這是什麼，剛好趁這機會認識一下。pattern matching 是用 pattern 去「比對資料形狀」，同時做驗證 + 解構 + 綁定，ChatGPT 的一句話解釋是：「左邊描述我期待的資料長怎樣，右邊給我實際資料；能對上就把值綁定，對不上就失敗」。

elixir 還有「functional core, imperative shell」的撰寫風格，也就是真正進行計算的函數 + 流程型的函數（只關心順序），把只有副作用的函數抽離出來處理。

了解函數式編程的核心後，寫不同語言，對講者來說都是類似 functional 的語言，會去找該語言有實現 functional 相關的套件。在 AI 時代，若能讓技術棧變簡單，可以幫助 AI 開發，還有函數編程跟 AI 還有unit test(TDD/DDD) 是天作之合。(因為很好測試，奶綠茶似乎也有提到，要 AI 用 functional programming 開發，讓程式更好被測試)

AI 只懂 React？Vue.js 也能 Vibe Coding！- Kuro Hsu#

這場是延續 JSDC 2025 「讓 AI 寫前端，我們來寫未來」的題目，Kuro 大大介紹在 Vue 裡面，可用 <spec> Custom Block 來寫該元件的規格，以明確分區讓 AI 精準辨認這是規格，且 spec 可隨 git 進入版控，更好追蹤。

也有提到 SDD （spec driven development）開發閉環，當我們遇到需求迭代變更時，都要回去修改 spec，確保文件永遠是最新的，如果來不及回去改 spec 而是先改 code，之後也可請 AI 理解 code 再反向回寫 spec。

詳細可參考 Kuro 大大在這篇文章分享的簡報～

AI 時代的 Legacy Code 營救術 — 墨嗓 (陳佑竹)#

很多場講者都有從不同面向提到「重構」，例如「如何做到真正有效的技術領導：實用技巧篇」Jocelin Ho 有提到要勇敢重構以維護 code 品質，推動重構時要聚焦商業影響力；「軟體開發邪教的救贖：AI 時代更應掌握的 TDD 技能」Kuma 有提到重構的設計才是好的設計；「活在科技工作者最好的年代，用商業思維優化你的人生選擇」Gipi 院長也提到重構要聚焦商業影響力。

「AI 時代的 Legacy Code 營救術」這場是從講者的故事出發，介紹整個重構流程和可參考的重構框架，以及這框架對應 AI 時代該怎麼做。

重構框架可分四大步驟：

  1. 勘查與測量
    盡可能補測試、進行原始碼靜態分析、數據分析找出檔案變更率較高的

  2. 建立藍圖
    設定里程碑，重構不是一次到位而是一個一個里程碑的累積；取得利害關係人支持，對應其他講者提到的要用商業影響力、數據來說服主管

  3. 施工與打造
    一次一小步，測試以確保功能不變，追蹤各種指標

  4. 啟用與維護
    確保變革進入團隊文化，避免走回頭路，建立內部的知識庫並透過 code review 了解彼此

我覺得啟用與維護是長遠來看很關鍵的部分，讓「持續改進」融入團隊文化中，這也是 DevOps 的價值，關於 DevOps 可參考「寫​了​幾年​ Code，​然後​呢？​軟體​工程師​必須重新​認識​的​ DevOps」中陳正瑋（艦長）的簡報分享，最後墨嗓也引用了艦長的話：

讓每一次 commit 都是一次改善的機會。 — 陳正瑋（艦長）

這也提醒了平常開發的自己，在開發新需求時，同時也要思考這個 commit 能改進一些什麼。

最後墨嗓提到，在 AI 時代下的重構可以利用 AI 加快執行效率，但軟體開發的基礎原則還是沒變。

深入淺出 Playwright Agent 代理人模式 — 保哥 Will#

保哥介紹 playwright agent 三大核心代理人如何幫我們寫好測試，甚至在測試有問題時可以進一步調整程式碼，其中印象深刻的是無障礙網頁的重要性。因為 AI 是透過 aria 無障礙網頁來理解網頁結構的，所以網頁的無障礙標注越清楚，就越能夠讓 AI 做自動化測試。因此前端開發時要盡量語意化 HTML。

另外保哥也提到，要有堅實的技術背景，才能教 AI 寫 code，可見基礎技術能力仍然很重要。

AI 時間槓桿賦能之術 — 全端工程師獨自升級全記錄 — 馮元詰#

講者小馮是喜劇公司唯一的工程師，分享如何在喜劇公司把各種需求變魔術變出來（？

只有一個工程師，時間有限下，他會先分類每個需求的類型，各類型用對應的招數擊破。類型分為：

完全不知道怎麼做 ➡️ 用我會的做出我不會的#

以在電影院讓觀眾發彈幕到螢幕為例，應對招數是：用我會的做出我不會的，例如讓 AI 找現有的開源 github 專案，避免重工，並且用自己會的東西來產出，確保後續自己還能駕馭和維護。

知道怎麼做但很繁瑣 ➡️ 讓 AI 根據初版 PRD 問細節並優化#

以即時更新排行榜的遊戲為例，應對招數是：讓 AI 根據初版 PRD 問細節並優化，當需求複雜時，可利用 AI 釐清規格、架構、技術上的盲點，也可以讓整體脈絡更好理解和規劃。

可能知道問題出在哪 ➡️ 讓 AI 驗證或否定我的判斷#

以讓遊戲通過壓力測試為例，應對招數是：讓 AI 驗證或否定我的判斷，描述問題然後提出假設，再讓 AI 驗證，當內心已有一些猜測方向時，提出假設可以增加 AI hit 的機率，降低 context window 的消耗。

最後小馮也和保哥一樣有提到，紮實基礎的重要性，利用 AI 時還是要回歸程式的本質，了解架構，了解工具，才可以發揮彼此的最大值。

另外，小馮的演講真的很生動流暢，介紹脈絡很清晰、表達又有趣，真的很有在聽喜劇段子的感覺～

React 優化實戰分析 — 掌握 React 進階技術 x 底層思維 — ThisWeb (Kun)#

這是技術含金量滿滿的一場～內容很精彩且 ThisWeb 的簡報也很詳細，推薦大家去看簡報，主要介紹 React 效能優化方式＆React Compiler 。

React 效能優化方式包含：狀態下移、內容上移、狀態保留、useMemo 與 useCallback、React.memo，以及 Context 優化重渲染問題，其中狀態保留是演講當下沒有提到，但我後續有看簡報介紹，可用 <Activity /> 元件來保留狀態，是 React 19 的新功能，有興趣的可了解看看!

總之整場很精采收穫滿滿，追蹤 ThisWeb 很久，第一次見到本人，整體講述得非常清楚好懂👍

對微前端的美好想像 — Eric Lee#

Eric Lee 是前端輕鬆聊的主持人，這場介紹公司內部經歷微前端的過程，簡報和共筆蠻完整的，提幾個覺得有趣的點。

首先， iframe 原來是微前端的早期嘗試 XD，一個網站放不同頁面，那不就是 iframe 嗎？沒想過這看法但好像有道理，不過 iframe 實作上仍有缺點，例如通訊困難、樣式難題、整合度低等；後來是使用 webpack module federation，但中間又遇到依賴地域、CSS 污染與痛苦的除錯，Eric 說這是「分散式的自由帶來分散式的混亂」。後來因為換組有了新的機會(?，這次改用 Turborepo pnpm monorepo，一個 repo 包含多個獨立的 Next.js app，每個對應一個 route，可解決 webpack module federation 的一些問題，例如可以統一依賴升級，更方便取用共享邏輯等。

最後 Eric 說：

微前端往往不是單純的技術考量，而是「組職管理」的考量。 — Eric Lee

我覺得就像專案技術選型一樣，選用技術不單純要考慮技術本身，還要考慮團隊成員和後續維護管理的問題。因此總結時 Eric 才說，不一定要學微前端，微前端是解決特定規模/技術問題的手段，不是一個技術演進的終點。要先了解適合的場景、要解決的痛點、必須付出的代價，這樣會比單純學會技術更重要。

然後 Eric 講話真的很生動有趣，其中有講到換組後要面對 3 個 repo，有重複依賴問題，例如一個 Button 有 8 個 import 選項，因為不知道要用哪一個，只好自己再新增一個，變成 9 個 Button 🤣，很好笑，很像在聽 podcast😌期待下次可以聽到 Eric 用英文分享!

從冷知識到漏洞：你不懂的 Web，駭客懂 — Huli#

第一次見到 Huli 大大本人!超感動，Huli 以生動又輕鬆的方式介紹了五個資安漏洞案例。

案例一從忘記密碼的功能出發，發現 mySQL 判斷字元的規則，原來 a、A、å、Å 即使是不同的 unicode，但都可以當作同一個 a，結論是不同 context 的相等就是不相等（在 DB 相等不等於在 JS 裡是相等）。案例二是 JavaScript replace 我沒認識到的功能，在 replace 中可用 $` 或 $' 拿到 Regex 配對到的字串的前面部分或後面部分(ref)，攻擊者可利用 $ 符號的方式取得原本內容的 " 雙引號，進一步達成攻擊，結論是在 JavaScript 用 replace 處理跳脫字元時要謹慎，或做多重防護。

謝謝最好的語言 JavaScript (?

案例三是 go 語言的 filepath Clean不如想像中 clean，如果你要 clean 的東西 .. 在開頭，他不會理你，想用 clean 確保路徑安全性之前，記得先看好文件，結論是寫好測試，確保你的 output 在危險情境下也是對的。案例四是React 19 以前，在 div 這種 HTML tag 中若傳入有 is 這個 key 的物件，React 會視為 custom component，而 custom component 就可以跳過 React 對 on 開頭的屬性檢查，然後傳入 click function，進一步達成攻擊。但這有趣的功能在 React 19 被修掉了XD，結論是絕對不要把使用者的輸入照單全收。

案例五又是一個和 Regex 有關的故事，在 JavaScript 中我們可利用精心設計的字串如 <svg><<<<<< 導致配對的正則程式卡住，變成 DOS，而不同程式語言的配對引擎不同，會得到不同配對結果。Elixir 針對太長的字串配對，它沒有配對完，就會直接回傳 false，因為偵測回朔的時間到達上限了，這特性也可能被進一步利用來攻擊；php 如果配對的時間超過，會回 false 而不是 1 或 0，可明確辨別是超過配對時間，而不是配對失敗。結論是謹慎使用 /regex/，要檢查一下 pattern 會不會有效能問題或資安問題。

最後補充，能見到 Huli 本人超開心!會後還有找大大簽書和合照!追星成功😍小可惜的是太害羞了，見到大大都不知道要講什麼><

軟體開發邪教的救贖：AI 時代更應掌握的 TDD 技能 — Kuma Syu#

這場從中後段才進去聽，看了簡報很喜歡前面的觀點，一起整理下來!

用「模式」的概念來理解世界，我去看了簡報 reference 的文章 Form, context & misfits，這篇文章指出，設計的本質是在特定情境(context)中創造一個形式(form)，並讓兩者能夠適配(fits)；然而情境的範圍、形式與情境的邊界，以及「適配」本身都不是固定或可完全預測的，因此設計問題本質上就難以被完整定義。也因此，設計不應追求需求的完整性，而應專注在找出可能發生的「不適配（misfits）」，所謂「不適配（misfits）」是指形式與情境衝突或失效的具體情況。這些不適配大多來自實務經驗，而設計模式則用來保存這些經驗，幫助設計者避免重蹈覆轍。

因為之前寫過設計模式的文章，當時對設計問題沒有這麼透徹的理解，這篇寫得很好也很清楚！推薦大家讀讀看。對我來說，平常實際開發時，才會發現 PM 寫的需求有更多「不適配（misfits）」的情境，此時才回頭思考解法該如何調整，原因就是因為設計問題本身就難以被定義、需求是很難完整的。

回到 Kuma 所說的「用『模式』的概念來理解世界」，就如上文章所說，生活中遇到的不舒適就是 force，force 會有多個面向例如需求、限制、理想樣貌等，這些會構成問題，而有了問題我們就想解決。針對一種特定場景，不斷重複出現的問題，提出一個「已被證實有效」的解決方案，即為一個「模式」。

接著 Kuma 一步一步延伸 TDD (Test-driven development) 是什麼，遇到需求時，先將需求拆小，寫出可描述需求的測項再開始實作，且測項要能支持重構。TDD 會和重構有關是因為單元測試是一種功能性測試，如果因為非功能性的重構而影響功能測試是不合理的，此時也提到「重構時的設計才是好的設計，這時候已經更了解系統的全貌，已經知道需求的全貌」，當我們有測試保護時，就能放心的時不時重構，而不用擔心功能壞掉。

整體講得非常精彩，我只寫了大略，有興趣的可參考簡報或參考講者出的書《你就是不寫測試才會沒時間：Kuma 的 TDD 實戰 — TypeScript 篇》，之後有機會也想來讀這本書～

TDD 永遠只關注一件小事；在設計上，永遠關注正在發生的變化；情況有變，永遠可以改變計畫。 — Kuma Syu

願 Web API 原力與你同在 — MUKI#

MUKI 大大分享了實用的 Web API 們，從近幾年瀏覽器提供的豐富新功能開始，例如 2023 年 CSS 有 container queries，元件可根據「父容器寬度」來調整樣式，達到元件級別的響應式，還有實用的 :has() Selector，2024 年還有主流瀏覽器共同訂定的 Interop Project 計畫，一起討論無障礙、CSS 巢狀等，再到 2025 年主流瀏覽器定義了 Web Platform Baseline，可用 Baseline 來評估技術可用性，當 Web API 進入 Baseline，就可考慮移除npm套件，改用原生 Web API。

接著從 MUKI 工作上的故事認識到 Broadcast Channel API，提醒我們以後開發時可以「Platform First」，先看原生 Web API 能否實現功能，若真的不行再去找 npm 套件，後續介紹很多實用 Web API 如：Intl API、Web Workers、Intersection Observer 等。MUKI 還自己建了一個 Dev Advisor MCP，可自動掃描專案程式碼，看哪裡可改用 Web API，同時也評估該原生 API 的支援度和可行性，還可以串 github actions 自動檢查。

我覺得能用瀏覽器原生 Web API 真的會方便很多，如 MUKI 所說，Web API 經過標準化，壽命比第三方套件長，且選擇 Web API 也不用擔心之後還要管理套件依賴或套件升級，除了減少 JavaScript 傳輸，專案也會更好維護，不過要替換專案內舊套件也是需要逐步迭代的，剛好呼應前面提到的「重構」和「測試」XD

最後 MUKI 也提了和其他講者類似的觀點，要了解底層原理、辨識問題本質。

給網站工程師的需求訪談工作坊 — 小賴#

報名這工作坊是因為之前上了小賴老師的「給網站工程師的網路課」，很喜歡老師上課的風格也學到很多，原本打算寫一篇網路課的筆記文章，但現在那篇還在草稿中… :)。很期待這次的需求工作坊，一開賣就買票了，很怕搶不到 XD

小賴老師有提到一個觀念：「軟體工程師不是只有寫 code，而是解決問題的人」，寫程式只是解決問題的一種手段、不是解決問題的唯一方法，與其說是軟體工程師，不如說是程式設計/軟體設計師。比起「工程」，我也更喜歡「設計」這說法，就如同 Kuma 提到的設計模式，我們解決的是設計問題，不是工程問題，讓我回想以前研究所上的設計理論與方法的課，讀到 Design Thinking: Understanding How Designers Think and Work 這本書，有提到：「設計不是去尋求一個給定(特定)問題的最佳解法，而是以這個問題為起點，開始一連串探索性的過程，在旅程中發現新事物，且終點始終是未知的，不會抵達已知或熟知的任何事物。」，因為這是一個探索過程，可能探索解法的時候才漸漸定義出設計問題，問題、解法共同發展。另外，Ruddy 老師在「軟體工程不只是寫程式」提到濕技能，也是類似概念；還有 Gipi 院長在簡報提的：「評估狀況需要功能解，管理解，商業解甚至口頭解，解決問題不是只有添加功能解決。」，別把技術當成唯一的槌子(如果你手中有槌子，看什麼都是釘子)。

延伸太多了，回到工作坊，小賴老師讓我們透過小組活動來體驗溝通的困難，其中讓我反思幾點：平常我會用什麼方式和別人溝通? 我如何確保雙方的理解是一致的? 這些問題每個人都有不同的答案，也有自己適合的方式，小組任務過程中也發現大家有各自的溝通策略，但如果能講好依循固定流程，會讓後續溝通更流暢。

工作坊有個需求訪談的實戰演練，由助教扮演需求方，小組成員一起訪問助教以釐清需求，我覺得助教應該演得很開心🤣，看到其他組心得分享說，組內成員問助教：「XXX這樣的話，你的痛點是什麼?」，結果助教說：「痛點是什麼@@」，我們這組也有類似情況，組員問助教：「XXX 這樣的話，你是希望能有更好的UX嗎?」，結果助教問：「UX 是什麼?」，很好笑，但也真實地顯示出兩方的資訊落差。

在需求訪談的演練結束後，小賴老師有分享幾點她自己的經驗談，但不一定適用於大家，其中幾點我覺得和其他場講者提到的觀念類似，例如需求方不知道自己要什麼很正常，在「敏捷環境中的產品經理生存之道：以產品思維實現價值與成果」中 Jenson Lee 簡報有提到，「你該詢問人們的不是他們想要什麼，他們不會替你開發出突破性的產品，但他們的意見可以指引你，避免做出沒人想用的產品。」；溝通時寧可過度溝通，呼應「如何做到真正有效的技術領導：實用技巧篇」Jocelin Ho 所說的 Always over communicate；溝通時建立信任很重要，呼應「從設計到共識：悠識如何在每一次新專案裡，用溝通建立信任關係」、「掌握田野中的「人」：真實場域研究的人際溝通與信任建立」談到的信任基石等。

整體來說，你沒辦法在這場工作坊後就變成溝通專家，也沒辦法讓一個 I 人變成 E 人(?，最後的 takeaway 也可能是其他講者分享過的概念或理論，因此我覺得更重要的是體驗，畢竟是工作坊嘛，別人說溝通要怎麼做要遵循什麼方法，都不如自己實際體驗來得透徹，只有體會到溝通的混亂或挫折，才會開始反思如何調整，而自己反思(或和他人討論)得出的策略我覺得才是更印象深刻也更實際的，講者說溝通要同理、要拆解問題、避免預設立場…，道理我都懂但實際要怎麼做🫠，只有多練習、多在實戰中反思才會知道!

如果要說這場工作坊帶給我什麼，我覺得它讓我停下來，重新思考自己平常與別人溝通時，會遵循的模式或策略(e.g. 過度溝通、複述理解)。同時也觀察到其他同學的思考與表達方式，發現每個人都有各自慣用的溝通策略。溝通不只是找到自己習慣的方式，也要思考對方能否接受、是否適合。

下一步想慢慢練習，在和不同人溝通時，觀察自己使用了哪些策略，表達是否夠委婉、是否聚焦在事情本身；當出現溝通落差或誤會時，能用什麼方式澄清、找出誤會產生的原因；而在溝通受挫時，也要提醒自己盡量保持理性，不被負面或低落的情緒影響。剛好最近開始和平常沒合作過的同事合作，還在摸索和同事的溝通協作模式，喔對要記得，大家的目標是一致的，大家都想要 ——

解決問題，早點下班!

總之推推大家都去體驗看看工作坊~原本以為下午會想睡覺，但過程真的太緊湊充實了，沒有打瞌睡，只有時間不夠的問題…🤣。

以上是我有實際參與的議程和工作坊，再來想列一些我看共筆和簡報時，覺得不錯的佳句/概念們。

結語#

第二次參加 WebConf 還是收穫滿滿，看到平常追蹤的大大本人很開心，這次很多議題與AI有關，講者們和 JSDC 講者的想法類似，都還是有強調基礎的重要性，要思考本質的問題避免停留在表象等，這次的技術和產品/設計議程的重疊性概念很高，技術人要更懂產品與設計，產品/設計人要更懂技術或vibe coding，讓我又想回去讀以前研究所跟設計有關的書了 XD

小可惜的是這次大部分都選擇聽技術相關的議程，我看設計軌的共筆都好精彩，明年想多參加看看設計的議程，轉換一下思維和視角! 這次 WebConf 整體體驗也很好，控時很好、主持人很棒，我後知後覺發現原來 anna 是 M 棟主持人，想說這聲音感覺很熟悉，原來是學不動了 podcast 的 anna! 也是第一次見到本人🤩。

明年還要參加🚀希望明年參加可以再多和其他人互動，或是去旁聽別人都問講者什麼問題~

後記

這次 WebConf 結束後，有和 Tech Book Community 的夥伴一起去吃飯，還有見到量化求職的喬治本人，喬治非常 E，很會帶氣氛(?，帶著大家一起聊了最近的生活，短暫交流覺得蠻不錯的，帶著這些能量繼續努力💪

Reference：#

如有任何問題歡迎聯絡、不吝指教✍