3/14 參加了一場 AI 開發者社群聚會，先謝謝 Natalie Lin 的籌辦，讓大家有這個交流的機會。兩場分享都蠻有料的，整理一下重點和自己的想法。
第一場：Claude Code 從新手到進階 — 你的 claude.md 是不是太肥了？
講者 David 開場就丟出一個很多人踩過的坑：把所有規則塞進 claude.md，然後期待 AI 全部記住。
現實是，當 claude.md 超過 50 行、規則超過 150 條，模型的注意力就開始衰退，規則會被忽略。這跟我在前端開發上的經驗很像——一個 component 塞太多邏輯，到最後誰都維護不動。
David 提出的解法是 Context Engineering，把規則從 claude.md 剝離到三種工具：
Hooks：pre/post/stop 三種掛鉤。最關鍵的是 stop-hook，可以在任務結束前用另一個 LLM 當驗證器，不合格直接擋下重寫。這概念其實就是把 code review 自動化成一道品質閘門。
Skills：適合可預測、目標固定的標準化流程。但要注意不能建太多功能相似的 Skills，模型檢索時會搞混。
Custom Agents：適合需要角色扮演、任務動態的情境，多個 Agent 之間可以透過 Teams 的訊息傳遞來串聯。
我自己聽完最有感的是 stop-hook 的概念。與其讓 AI 自己檢查自己，不如用另一個 LLM 或傳統的測試流程來當守門員。信任，但要驗證。
第二場：從零到一建立 Agentic Team — AI 不能幫你外包學習
第二位講者 Jeffrey 的背景很有意思——他是從程式初學者一路走到打造 SaaS 產品的。他的核心心法很直白：
"AI 可以幫你外包任務，但不能幫你外包學習。"
這句話打中我了。市面上太多人急著用 AI 工具跳過基本功，結果產出一堆自己看不懂的 code。工具會變，但理解系統運作的能力不會過時。
Jeffrey 把 AI 導入分成四個階段：探索期（複製貼上）→ 問答期（把 AI 當導師）→ 痛點期（工具導入但基建不佳）→ 自動化期（Context Engineering + 放權給 Agent）。
他提出的三層式 Agent 架構我覺得很值得參考：
指揮層：負責調度，可以是票務系統（如 Linear）、高階 AI，或開發者本人
數據與上下文層：提供決策依據，把用戶數據、DB、文件、codebase 透過 API 串接
執行層：實際動手的單位，CI/CD 流程或寫 code 的 AI Agent
他的實戰 demo 也很有說服力：一個 Agent（Jimmy）負責監控日誌和發 PR，另一個 Agent（Bruce）當 QA，PR 部署到測試環境後自動跑 E2E test，過了才能合併。防範 AI 幻覺的方式不是讓 AI 自我檢查，而是直接套用傳統軟體工程的驗證標準。
我的想法：這跟 Data Flow 的邏輯是相通的
聽完兩場，我一直在想一件事——這些 Agent 架構的設計思維，本質上跟我一直在做的 data flow 思考很像。
不管是 stop-hook 的品質閘門、三層式架構的資料串接，還是 Agent 之間的訊息傳遞，核心問題都是：資料從哪裡來、經過什麼處理、到哪裡去、在哪個節點該被驗證？ 這跟設計前端架構時思考 state 怎麼流動、side effect 在哪裡發生，邏輯是相通的。
而說到前端架構和 data flow，這九年來每間公司的經驗其實都在強化同一件事——功能開發成不成功，溝通很重要，而 UI/UX 就是溝通的最前線。
九年五間公司，我對 UI/UX 的理解是這樣長出來的
回頭看自己的職涯，每一站對 UI/UX 的體會都不一樣，但串起來有一條清晰的脈絡。
Botpartner — 使用者不在螢幕前面
我的第一份工作是做 Chatbot 結合 IoT 的整合平台，串接 LINE、Facebook Messenger 跟 Raspberry Pi。這個階段讓我體會到一件事：UI 不一定是畫面，對話流程本身就是介面。 使用者透過聊天機器人操控硬體設備，你要思考的不是按鈕放哪裡，而是對話的每一步回應是否符合使用者的預期。後來在 Computex 和 MWC 西班牙做技術演講，也在 MakerPRO 培訓過 200 多位開發者，這些經歷讓我開始理解：把技術翻譯成使用者能理解的語言，本身就是 UI/UX 的一環。
天樞健康 — 醫療介面零容錯
第二站是做醫院管理系統。一個月內快速上手 Angular，接手離職團隊維護線上系統。醫療場景的 UI/UX 跟一般產品完全不同——不是好不好用的問題，是錯了會出事的問題。 我用 Angular 搭配 Kendo UI 建立可重用元件庫，重點不是美觀，而是每個表單欄位的驗證邏輯都必須確保資料正確性。在這裡我學到的是：UI/UX 在某些場景下，品質保證比使用者體驗更優先。
Nidin — 從第一位前端到建立設計合約
到了 Nidin，我是團隊裡第一位、也是唯一的前端工程師，後來帶到四個人。120 萬用戶、午餐尖峰一萬人同時在線的外送平台，前端的壓力不只是效能，還有跟設計師的溝通。
當時沒有 Design System，設計師出完 Figma 稿之後，前端做出來的跟設計稿常常有落差。我的做法是建立一個 Component Showcase 頁面——類似手動版的 Storybook，把每個元件的各種狀態都展示出來，設計師可以直接在這個頁面驗收。這個做法建立了我們之間的設計合約：Figma spec 是輸入，Component Showcase 是輸出，中間的落差可以被具體看見和討論。
技術上，POS 系統的菜單品項非常多且結構複雜。我用 Virtual Scroll 只渲染 viewport 可見範圍，搭配 HashMap 快取加版本號比對——菜單資料沒變就不重新渲染。高併發時也做了 Vue watch 取代 ref 監聽來減少不必要的 re-render。這些優化加起來效能提升了 40%。但讓我印象最深的不是技術細節，而是這個過程讓我理解到：前端效能優化的目的不是數字好看，是讓使用者在尖峰時段點餐時不會卡住。UI/UX 的最後一哩路，是效能。
Atgenomix — 白牌產品的 UI/UX 挑戰
亞大基因是做醫療級基因分析平台，產品要部署到多間醫療院所。這代表同一個產品要用白牌（White Label）的方式去適配不同院所的風格。
我進去的第一件事是 refactor：把既有雜亂的 CSS 架構重整為 SASS，建立有系統的樣式結構，讓風格切換不再是到處改 hard-code 的顏色。同時也提升元件的可用性，讓後端工程師也能直接使用前端元件。在這裡 UI/UX 的挑戰不是「設計好不好看」，而是如何讓同一套元件系統在不同品牌風格下都能穩定運作。
另外因為是醫療軟體，需要遵循 IEC 62304 標準。我在本地端建立 OWASP 弱掃檢查，上 CI/CD 前先自行排除安全問題。品質和安全在醫療場景是標配，不是加分。
Cooler Master — 跨三層的溝通斷裂
最近一份是在酷碼科技做 MasterCTRL，一個 PC 硬體生態系統的控制平台。我是接手外包階段結束後進場優化的角色，進去的時候發現最關鍵的問題不是程式碼本身，而是前端、後端、韌體三方之間缺乏統一的資料合約（Data Contract）。
韌體端因為 IC 限制，回傳的資料常常是 null 或 undefined；後端沒有做攔截就直接丟給前端；前端畫面顯示的硬體狀態跟實際不符——使用者看到的溫度、轉速可能是錯的。這不只是 Bug，是使用者信任的崩壞。
我的做法是跟 PM 和 UIUX 透過 Figma 重新對齊需求，同時建立結構化日誌系統（Log System）搭配 Data Validation——前端攔截異常資料、三方統一日誌格式、出問題時根據日誌快速定位。客服排查時間從兩週降到兩天。後來也把 Log 延伸到 Integration Test，用測試預防問題復發。
這段經歷讓我深刻體會到：UI/UX 的品質不只取決於設計稿畫得好不好，更取決於資料流的每一層是否可靠。使用者在畫面上看到的每一個數字，背後都是一條從硬體到韌體到後端到前端的資料管線，任何一層出問題，體驗就崩了。
把這些經驗串在一起看
從 Botpartner 的對話式介面、天樞的醫療零容錯、Nidin 的設計合約和效能優化、Atgenomix 的白牌系統和安全合規，到 Cooler Master 的跨層資料品質——每一站都在教我同一件事：
UI/UX 不只是設計師的事，更是工程師的事。好的使用者體驗需要穩定的資料流、可靠的元件系統、和跨角色的溝通合約。
這也是為什麼我現在用 data flow 的角度來看待所有問題。不管是 Agent 架構的資料流動、前端 state 的管理、還是 UI/UX 背後的資料品質，核心邏輯都是一樣的。
近期的狀態
近期剛好遇到一間蠻有興趣的公司，花了不少時間深入研究他們的產品——不只是表面使用，而是開 DevTools 去分析 API 架構、觀察新舊版 UI 的遷移痕跡、試用產品後整理具體的改善建議。跟對方的交流切磋讓我收穫很多，也讓我更清楚自己的價值在哪裡。
然後很巧的是，就在聽 meetup 的當下，收到對方通知進入下一階段、要跟團隊碰面聊天——那個瞬間真的超興奮，一邊聽著 Agent 架構的分享，一邊想著自己可能即將加入一個很棒的團隊，整場聚會的體驗直接拉滿。
回頭看這段時間，不管是研究公司產品、跟對方切磋技術、還是參加這類社群聚會，都讓我在技能佈局上有了不少新的延伸。尤其是這次挑戰 Data Engineer 方向的過程，受到前輩們不少啟發——從資料管線的設計思維、到怎麼用工程的角度去看待數據品質和系統可靠性，這些都是過去純做前端時比較少接觸到的視角。從 data flow 的系統思維、前端架構的深化，到現在對 Agentic 工作流的理解，這些經歷拼在一起，讓我的職涯視野比以前開闊了很多——不只是技術上的成長，更是對「工程師能創造什麼價值」這件事有了不同的見識。
也因此更清楚自己想要的是什麼——加入一個已經在賺錢、持續成長的產品，用 data flow 的思維去預測問題、優化系統，同時在前端架構的規劃、開發到 refactor 上持續發揮。
目前仍在積極尋找新機會。如果你的團隊在做的事情跟上面提到的方向有交集，歡迎聊聊。
