Pycon 2025 & WebCon 2025 記錄與心得

發表於 所需閱讀時間 ≈ 9 分鐘

  今年參加了兩場 conference，性質真的很不同，我個人的感覺是：PyCon 專注於開源，以及用什麼技術完成某件事情；WebConf 則是結合技術與產品。兩者共同點是大部分場次都和 AI 有關，趨勢非常明顯。

  想參加 PyCon 是因為現職使用 Python 的場景不外乎寫 API、做簡單的資料分析、使用各種 LLM 工具，想看看業界還有哪些不同的使用情境。現場給我的感覺是，與會者的英文程度普遍很好，自己雖然聽講座不是問題，但口說明顯是需要努力的方向。鼓勵開源的氣氛也不只是掛在嘴上，除了分享開源心得外，現場真的有 Sprints，當天就直接對 CPython 發 PR。

  參加 WebConf 則是因為主題多元，包含前後端、資安，以及近期想培養的產品思維，預期可以從中獲得不少 insight。

  兩場活動的內容雖然有差異，但有些概念我認為是類似的。 每個議程都是很有價值的分享，以下整理幾場個人印象比較深刻的講座，以摘要加上反思的方式記錄。


LLM 開發相關

AI Guardrails：以 Python 構建企業級 LLM 安全防護策略 - Nero Un (Pycon)

  1. 認識到 guardrail 的重要性
    • 北捷 AI 客服被大家拿來寫 code，就是一個沒做好 guardrail 的例子。
    • 應用場景很多，例如輸入檢查、政策檢查、schema 檢查等等。
    • 使用時機可以是在輸入、檢索、輸出 (schema check)、生成內容等階段。
    • 這已經是趨勢，三大雲端服務也都有自己的 guardrails 服務。
  2. 開源模型在特定任務表現不一定最差，參數大的模型也不一定好，例如在講者自己的「幻覺偵測」任務中：
    • 使用 gpt-4.1-nano 和 gpt-4o 成效差不多，但是成本卻差了 25 倍
    • 使用 GLM-4-32b (開源模型) 比起 llama-3-70b，latency 短且成效更好

實戰 AI Agents 應用開發：從 Web 後端到前端的整合 - ihower (Webcon)

講者使用 OpenAI SDK 展示了實作一個 AI Agent 的整個流程，這裡就不細講一些基礎 API 的調用，以下是一些我自己有學習到的部分

  1. 如何減少 TTFT (Time to first token)
    • 使用 streaming，盡快讓使用者看到第一個字。
    • 使用 preamble，在工具呼叫時先說明：「讓我幫你查詢目前 XXX 的最新資訊」，避免使用者乾等。
    • 簡單任務丟給小模型，可以得到比較快的 TPS (Token Per Second)，可搭配 Router Agent 先分類問題，再指派給適合的模型。
    • Multi-agent 的使用若想提升效率，可以採取一些手段，例如：
      • 如果有 guardrail agent，可以在 guardrail 跑的時候先偷跑主要任務，如果最後 guardrail 沒過再放棄結果，trade-off 是會額外燒 token。
      • 不相依的任務可以並行跑。
    • 明確引導工具使用時機，避免不必要的工具呼叫拖垮速度又增加成本。
  2. Prompt caching 的重要性：被 append 後的 message 花的 token 甚至可能比 append 前還少，但要注意幾點。
    • 盡量保持 prefix 固定，例如避免動態的 system prompt，需要動態的部分盡量放在 suffix。
    • 也避免動態變動工具定義。
    • 避免將前一個步驟的輸出結果「整段」直接當成下一步的輸入（例如某些工作流工具像 n8n 容易有這種情境，這是 trade-off）。
  3. Resumable stream：在 LLM 產生 response 的過程中重整也不影響產生的結果。其中一個做法可以參考這篇文章，主要是動態將產生的結果 stream 進 Redis，而 Redis 在每次有新的 chunk 時會通知 stream consumer，使用者重整時都是從 stream consumer 拿資料。

反思：
  在現職開發內部 LLM 相關應用時，比較著重在 prompt 的設計、tool 與 MCP 使用，對於怎麼省 token、優化速度以及使用者體驗的涉略還不夠深。 這兩場議程確實拓展了我的開發視野，讓我意識到在 agent 開發上不只是「把任務完成」而已，還有很多可以優化的細節。

  很巧的是，兩位講者都提到不同模型適合不同任務，也再次印證了「根據業務場景設計對應的 benchmark 來挑選模型」是必然要做的事。 在能力相近的前提下，不同模型的成本差異可能也非常大。

  UX 體驗方面，前後端開發時透過 cache、UI 來強化使用者體驗這點本來就很常見。 至於 streaming，雖然在 React 的 HTML、RSC payload 上有被動體驗過它帶來的好處，以前也有串接過 SSE，但實作時還是不一定能第一時間想到它的重要性，這次算是很好的 take-away。


產品思維

Behind the scenes of FastAPI and friends for developers and builders - Sebastián Ramírez (tiangolo) (Pycon)

  FastAPI 的作者 tiangolo 親自演講。乍看標題比較難聯想到會被我放在產品思維分類，但實際上這個主題比較少講細節技術，內容較多是開發 FastAPI 時的設計考量。 像是如何以使用者優先的角度開發好用的 API 框架，以及面對大型開源專案所遇到的現實問題等等。

  1. UX 相關
    • 如果想解決的問題已經有工具了，就要觀察那些工具還不夠的地方，例如現有工具抽象層太低，或學習曲線太陡等。
    • UX first，對 user 重要的問題優先於對產品開發者重要的問題。
    • 抓住聰明的 newbie，他們是最好的產品試用對象。
    • 除非有明確理由（效能、使用者友善等等），否則應該盡量減少對 user 複雜的前置作業。
    • 選擇正確的抽象層，讓 user 使用起來方便，是很關鍵的事。
  2. 開源專案衍生出的另一種開發思維：docs (code) driven development：先寫好 docs example，再照著 example 開發功能。
  3. 你的注意力是有價值的，犒賞它。
  4. 專案變大後，無聊的 hater 也會變多（例如有人因為文件裡放 emoji 就開噴），但那其實代表你成功了！

反思：

  講到 UX 很容易直接聯想到前端，因為前端最需要在意的是使用者操作網頁時的流暢度，像 Core Web Vitals 也是因此而生的指標，在公司討論產品內容時，也常聽到的開頭是「對於使用者來說⋯」。

  但事實上，不論是做產品、API 或開源專案，都需要考慮「使用者怎樣用起來比較方便」，因此 UX 基本上無所不在。 很難得能聽到開源專案的開發者分享對 UX 的看法，尤其是抽象層要做到什麼程度才剛好，讓我聯想到：有時自己也會在「明確告知使用者」和「這個就讓使用者自己探索」之間猶豫取捨，覺得是很棒的一場分享。


B2B 服務的 AI Agent 產品設計原則 - Happy Lee (Webcon)

講者分享了四個故事，記錄一個比較深刻的

從 PRD(product requirement document) 到 PRP (product requirement prototyping)

  • 以前： PM 腦中的一個產品從發想 → 寫 PRD 與 story 文件 → RD 寫 code 到產生 prototype ，整個過程可能就需要花費兩個月，結果可能還是跟 PM 腦中想的不太一樣。
  • 現在： PM 能 vibe coding 出 prototype，在第一步就能產出一個 PRP 能夠驗證 PM 自己腦中的想法，且可能只花不到一天，大幅縮短產品驗證週期。

反思：

  今年在公司有一部分時間在思考要如何讓 AI 落地到整個產品流程中，當時的思路是：除了加速 RD 開發以外，也要考量如何讓 PO 更快產出 PRD，以及如何加速 QA 自動化流程。 聽到 Happy 分享讓 PM 直接產 PRP，覺得有點跳脫自己原本比較線性的思考方式，蠻有啟發，也讓我多了一個新的視角。 同時也會好奇，實際執行上他們遇過哪些困難，如果有更多實例分享應該會更精彩。


Gipi 活在科技工作者最好的年代，用商業思維優化你的人生選擇 (Webcon)

紀錄我自己比較印象深刻的三個故事

如何說服公司要花時間還技術債：

  把工程師術語轉譯，再量化影響範圍，例如：技術債共影響了 620000 位用戶、產生 230000 件客訴、每個月約 330 萬損失，透過這種方式去溝通。

如何將 20 年歷史的老舊的系統翻新

  • 重新思考這個系統存在是為了解決什麼問題。
  • 判斷哪些部分是必要的核心功能。

困難的地方在於人多嘴雜，有些人覺得某些功能一定要留下來，但實際的解法是「讓數據說話」。

  • 實際用 log 追一個月，發現 80% 的功能幾乎沒人在用，藉此決定哪些是重要的部分。
  • 某些特定季節才會使用的功能，被視為新系統中的新 feature，藉此安排優先級。
  • 問題被拆解後，從小的部分開始處理會容易許多

建立一個加盟合約管理系統，但是每個加盟業者的合約與分潤規則都不同，完成需求需要一百條以上的規則，是系統的災難

  • 需求本身不一定重要，重新思考是為了解決什麼問題。
  • 問題的根本是「條件不一致」，與其用系統規則去適應不如重新思考規則

結果：提出一個大家能滿意的品牌分潤規則，系統設計從無限的樹狀分支改為單一直線


反思：

  很有共鳴，在公司內部做產品開發時，常常可以看見主管提醒大家要從使用者角度思考，弄清楚什麼才是真正重要的需求，試著看到「問題背後的問題」，從第一性原理出發才能真正解決事情。 不過同時也代表，光靠技術是做不到這些的，跨部門之間的溝通、說服與協調這些軟實力也超級重要。


開發效率

AI 時間槓桿賦能之術 - 全端工程師獨自升級全記錄 - 馮元詰 (Webcon)

  講者是薩泰爾唯一的全端工程師，除了人力不足之外，還常常需要變出很多 feature XD。 這場主要分享在時間不足、需求又很雜的情況下，如何先把需求分類、梳理出脈絡，再搭配 AI 逐一擊破。

將需求脈絡化

  先依序從「敏感及風險程度、影響範圍、延續性、複雜度」等維度去分類需求。

最後真的落到自己頭上的需求再分類，分別利用 AI 處理

  • 完全不知道怎麼做的需求——例如讓觀眾在電影院發彈幕到螢幕上：
    • 先請 AI 找看有沒有現有的 repo，如果沒有就找類似的 script。
    • 接著用自己熟悉的技術 stack 重新實作，確保之後可維護性。
  • 知道怎麼做但很繁瑣的需求——例如 500 人即時更新排行榜的遊戲：
    • 先用自己已知的內容寫出初版 PRD，再請 AI review 看有哪些不足、盲點或沒想到的地方。
  • 大概知道問題出在哪的需求——例如遊戲同時 300 人壓力測試失敗：
    • 先提出自己的猜測，再丟給 AI 協助驗證，加快驗證過程，同時也省 token。

反思：

  講者重點不在於技術多難，而是非常精準地示範了「怎麼用 AI」這件事，並且很積極地從根本問題出發去完成需求。 自己聽的時候覺得非常有感。兩年前剛開始用 AI 的時候也只會拿來問一些簡單問題，隨著時間拉長，發現可以慢慢跟它進行比較深度的討論（模型變強也是關鍵）。 現在不只是用它來加快工作效率，也很常拿來拓展自己知識的邊界，最近在做 side project 時特別有感。

  另外，講者本身就是很會說故事的人，加上口條清楚、題材又豐富，在報告與表達這塊也是很值得學習的對象。


檢視自我

程式碼與尿布：媽媽工程師的生存指南 - Hannah Lin (Webcon)

  一開始是被標題吸引過去的，結果講者說現場男生聽眾的數量超過她預期 XD。 這裡先記一下講者的背景脈絡，方便之後回頭看的時候比較好連起來。

  1. 2018 舉家移民到美國矽谷，2023 又搬回台灣。
  2. 五年內搬家五次，其中一次是懷孕 36 週的時候。
  3. 非本科系，沒有任何美國學歷或經驗，在矽谷找工作。
  4. 兩個小孩都親自照顧超過兩年。
  5. 邊全職工作邊 24 小時照顧新生兒，持續快一年。

  因為想兼顧工作，又不想錯過小孩最早期的成長過程，所以選擇在 remote 的同時自己帶小孩，但相對也承受了非常大的壓力。

work & life balance 到 off balance on purpose

  • 接納「完美的 work & life balance 不存在」，將心態轉為「Off Balance on Purpose」，也就是短時間內有目的地失衡。
  • 轉為全職育兒，但也不是完全放棄技術，會利用瑣碎時間閱讀前端相關知識。
  • 小互動：利用 Wheel of Life 來評估生活核心價值。
    • 先用圓餅圖把生活面向（家庭、工作、關係、健康等等）畫出來，再針對每個面向依現況評分，反思近期想加強哪些部分。
    • 短期內生活會看起來失衡，但從長期來看整體仍然是往上的。

如何做到「不完美但剛好」

  • 接受「我就是我」——接受現況、不需要一直拿自己跟別人比較（實際上超難）。
  • 好好照顧自己——維持固定運動、學習轉念、放下手機、為生活留白。
  • 建立支援系統——在職場上勇敢溝通，在家庭中與伴侶分工，或尋求家人協助。

反思：

  原本以為會是比較多時間管理或如何有效利用時間的分享，結果更多是在談心態上的轉變。 在這兩天所有議程中，這場是自己印象最深的一場之一。「XXX 達成之後就多花點時間在 YYY 上吧」剛好也是自己最近常出現的想法，看到「Off Balance on Purpose」這個概念時還蠻認同的。 雖然說最好不要把自己逼得太緊，但還是很佩服講者能為了自己想要的生活堅持那麼久。


結語

  PyCon 的心得欠了一陣子，本來就想寫，乾脆趁 WebConf 一起整理。 這次 WebConf 給自己的目標是主動和講者交流，身為 I 人竟然也真的有做到，最後和兩位講者有講到話。不過不太會聊天這件事還是有待加強，也是之後要持續練習的方向。