.png%3Ftable%3Dblock%26id%3D295fe6fa-8992-8056-ba0a-e1004e2da609%26cache%3Dv2&w=3840&q=75){kind=logo}
Intro
在研華實習這七個月，我學到了很多，作為紀錄也分享給你們。在這段日子裡要感謝我的實習經理 Jack、主管 Paul 、Mentor Joe，還有很照顧我們大家的技術大神Ryan。
這次的實習分享，會涵蓋三個面向：工作內容、文化、整體心得，希望可以幫助到你。
Tech Stack in this internship
在這七個月的實習中，需要的技能主要是 Multi-Agent 、推薦演算法及模型訓練流程的設計
雖然進來前完全沒碰過，不過其實也是做中學，但研華有很成熟的Mentorship，所以蠻鼓勵實習生跟Mentor討論，甚至可以選擇自己有興趣的專案，只要能夠負荷，想要own專案的數量也不會被限制。
此外，每週都會跟主管匯報目前專案的進行方向、完成的進度，以及未來的Action Item。
主要工作內容
我會在這段簡單回顧我在研華的主要工作內容。但因為不同部門、團隊與主管的工作方式差異很大，以下分享僅代表我的個人經驗，提供給對研華工作樣貌好奇的人作為參考。
競品分析 Agent
應該大家都知道研華是工業電腦的龍頭，客戶多半也是走 B2B。就算很多客戶本來就傾向選研華，業務跟 PM 在前期還是得花很多時間做功課：去查競品的規格、價格、產品特色，然後一項一項跟自家產品對照。比到最後還得拉相關部門一起開會確認細節，才能整理出一份真的能說服客戶的報告。這整套流程很重要，但也真的很花時間跟精力
所以我們想做的「競品分析 Agent」，希望透過 Deep Search 及 Deep Research 這兩個模組讓 Multi-Agent 能盡可能加深加廣搜索維度，並針對特定需求進行深度研究，讓業務不用每次都從頭查到尾，而是能快速看懂競品強在哪、弱在哪，以及自家產品哪個點最有機會打中客戶需求。除了確保資訊來源的正確性外，我也學習到 SWOT 與五力分析能讓整份報告更有「結構」與「論證力」：前者把零散資料收斂成研華的優先策略與主打訊息，後者則用產業規則解釋客戶為何會在特定條件下被說服。這樣輸出的內容不只是列出比較結果，而是能清楚回答「哪些差異為何重要、如何將搜索到的資訊論述、下一步怎麼做」，讓對內決策與對外溝通都更具說服力。
在 2025 年初，Multi-Agent 架構的工具與框架選項明顯變多。除了當時剛出的 Manus（沒想到後續會被 Meta 收購），剛出不久也引起 Github上開源出的 OpenManus，我也研究了不少像是 AutoGen、Amazon Bedrock Agent、Open Deep Research 等架構。起初我選擇以 CrewAI 作為主要實作框架，並投入時間理解它的設計理念與工作流。
然而在與其他實習生及前輩討論後，我發現 LangGraph 在目前的需求下更符合「可控流程編排」與「狀態管理清晰」的特性，因此我改以 LangGraph 來實作競品分析 Agent。雖然在 CrewAI 上的探索成本不低，但也因此更完整地建立了 Multi-Agent 選型與設計的判斷基準。
Recommendation System 設計與開發
這個專案的目標是提升銷售與產品部門的客戶選購體驗，進而帶動銷售成效。
主要工作包含：
- 從資料清洗、訓練到推薦系統落地的流程設計與開發
- Multi-Agent 架構設計與實作
開發上整合超過 30 個零碎 API，彙整三大資料源、4,000+ 筆資料，建置三階段訓練的推薦系統，參與設計單一推薦 Agent 與混合情境推薦 Agent，並將整體推薦模型的訓練效率提升 80% 以上。
推薦系統（Recommendation System）其實離我們生活很近。平常滑社群平台（像 Facebook、Instagram、Pinterest），你看到的內容很多都是被推薦出來的；逛電商（像蝦皮、Amazon）也是一樣，推薦常常會直接影響你下一步想點什麼、買什麼。
但把同樣的概念放回研華的 B2B 市場，情況就不太一樣。工業電腦的產品週期不像快消品那麼短，升級成本也高，而且「升級後的效益」很多時候不一定划算。再加上不少客戶本來就很黏、習慣固定採購，所以不管他們是從研華官網還是電商平台下單，常見情境其實是「繼續買同一個型號」——有點像你在蝦皮按「再買一次」。
也因為這樣，我們要做的推薦不只是找「產品和產品的關聯」，更重要的是從過去的銷售資料去整理出客戶可能的購買路徑：他們通常什麼時候會回購？什麼情況下會考慮升級？什麼類型的客戶比較容易接受新品？目標除了讓客戶選購更順、資訊更清楚，也希望能在整個購買旅程中，找到合適的時機把新版產品推上去，慢慢提高客戶的購買意願。
在設計上，我整合了三個不同來源的銷售資料，加上客戶在網站上的互動行為，並且跟不同產品部門、銷售部門一起對齊需求。因為各部門的產品特性差很多：有些產品很獨特，如果推薦到不相關的東西，反而會讓客戶更困惑，所以這種情境就比較適合做「水平推薦」（只推薦同類、相關產品）；但也有些產品需要垂直整合，客戶必須一套一套買齊、才能真正完成應用場景，這時候推薦邏輯就要能支持「一條龍」的選購流程。
在技術上，我是接手前一位實習生留下來的專案。先說真的很感謝他，程式碼寫得很乾淨、結構也很清楚，所以交接起來算順。但即使如此，我還是花了將近七個工作天，才把整套流程摸熟——從各種 API 的使用方式、資料怎麼清理與對齊、到最後怎麼產出推薦結果，中間每一步都需要自己跑過、確認過，才敢改動
在模型訓練與推論方面，我們採用 AWS Personalize 來做整個流程的部署與運行。不過實作過程中也遇到不少挑戰（例如：資料格式不一致、欄位缺漏、不同來源的 ID 對不上、推論延遲或成本控制、prompt/參數調整造成結果波動、需要為特定推薦去設計新算法、batch 處理與重試機制等）我後來是透過逐步拆解流程、把每個環節的輸入輸出都記錄下來，才慢慢把問題收斂，讓整體 pipeline 變得更穩定。
底層模型訓練架構
Recommendation User 需求整合與未來規劃
不過做著做著我也發現，推薦系統不是單純從工程角度「看資料、算分數」就能解決的。為了讓系統真的符合第一線的使用情境，我和 Mentor 一起跟好幾個部門的 PM、Sales、MKT 開會，把他們遇到的痛點、實際想要的輸出形式、以及使用流程一一整理出來。
在原本的推薦 Agent 基礎上，我們也進一步設計了能根據不同情境與 context 做「混合推薦」的 Agent，讓推薦不只是固定規則或單一路徑，而是能依照客戶當下的需求、產品線特性、以及購買階段，給出更貼近現場的推薦。
這段討論的過程對我幫助很大。我不只練習了怎麼把工程問題用其他部門聽得懂的方式講清楚、怎麼把技術限制轉成可落地的方向；也從行銷主管那邊更深入理解 B2B 和 B2C 產品在決策流程、購買週期、以及溝通方式上的差異，另外也補上了我對行銷／銷售漏斗（funnel）的概念，讓我在設計推薦邏輯時更能對齊商務端真正關心的指標與流程。
我學到的三件事
1. 從一次性訓練到可長期迭代的流程
由於推薦系統需要定期重新訓練與部署，在建立整體訓練架構的過程中，我學到的不只是把模型「訓練出來」，而是把它做成一條能長期運作的流程：包含整合多個資料來源與 API、用 MLflow 進行模型與資料集的版本控制，並且在不打亂訓練節奏的前提下，設計出能穩定處理例外狀況的機制（例如資料缺漏、格式變動、API 失敗或延遲），讓整個 pipeline 可以持續更新、可追溯、也更容易維護與迭代。這對我來說是蠻大的挑戰，很多看似瑣碎的細節，會是決定模型能否被團隊長期信任與使用
- 資料來源與 API 整合：把產品主檔、客戶屬性、互動/交易紀錄等資料串成同一套 key 與欄位定義，並把資料取得方式（DB / API / 檔案）流程化，避免每次重訓都要重新對資料與規格。
- 可重跑的資料處理 pipeline：把清洗、去重、欄位標準化、類別映射、缺值處理固定成可重複執行的步驟，確保每次重訓用到的資料邏輯一致，減少「這次跟上次怎麼不一樣」的狀況。
- 特徵產製與一致性：把原始資料轉成模型用得到、且能穩定產出的 feature（例如相似品/替代品關係、常見搭配、客群偏好等），並確保訓練與推論使用同一套轉換邏輯。
- MLflow 版本控管（模型 + 資料集）：用 MLflow 記錄每次訓練的模型版本、參數、指標，以及對應的資料版本/切分方式，讓結果可追溯、可比較，也能在需要時快速回到某個穩定版本。
- 不打亂訓練節奏的例外處理：在 pipeline 中針對常見問題先做好防護（例如資料缺漏、欄位格式變動、API timeout/失敗），用重試、降級策略或跳過不影響主流程的異常，讓重訓可以穩定完成，而不是因為單一來源出問題就整個中斷。
2. 行銷 / 銷售漏斗（funnel）
你可以把銷售漏斗想成「顧客從第一次看到你，到最後付錢」的路徑地圖。它之所以叫漏斗，是因為上層的人很多（大量曝光/流量），但會隨著每一步篩選而逐漸變少，最後只剩一部分人成交。
簡單來說，銷售漏斗可以被視為用來描述「潛在客戶從初次接觸到成交」所經過的分階段旅程。
銷售漏斗常見 5 階段 → 以常見的 AIDA model 為例
- Awareness 曝光/認知：看到你、知道你是誰
- Interest 興趣：願意多看一點、點進官網/內容
- Consideration 評估：開始比較、想知道方案/案例/價格區間
- Decision 決策：約 demo、詢價、內部提案、談條款
- Purchase & Loyalty 成交/留存：成交、續約、回購、轉介紹
透過銷售漏斗，公司可以知道哪些事情
- 問題到底卡在哪一關？
例如曝光很高但真正購買率很低，問題可能是訊息不對、CTA(Call To Action) 太弱。
- 該先投資哪個環節最有效？
不是每次都要拼更多流量；有時只要把中段「評估/比較」內容做扎實，轉換就提升。
- 跨部門可以對齊同一套語言
行銷、業務、產品常常各講各的，漏斗能把大家拉回同一張地圖看數據與下一步。
3. 技術選型及團隊協作
講到技術選型，我覺得比較有效的方法，是先對當前流行的工具和框架有基本認識，再帶著「明確的需求與假設」去跟前輩或同事討論，畢竟工作不是讀書會，大家不見得有必要花時間一起研究一個新工具。這樣討論的焦點會更清楚，也比較不會變成單純追新。對我來說，選型不是在比誰最強，而是在確認工具能不能支撐我們的流程、能不能被團隊維護。像是2025年中出現的 MCP 就被許多人採用（包括我們），當時在了解的過程中也記錄了一些筆記（像是Note: MCP Ep.1, Note: MCP Ep.2）。
此外，工作上也少不了協作，不管是開會對齊、方案討論，或是跨部門請求支援。我自己在實習過程中養成以下幾個還蠻受用的習慣：
- 約開會前先把資訊準備好：因為每個人的時間都很寶貴，所以需要找人開會時，我會先用 Teams / Slack / Google Calendar 等工具確認對方空檔，整理出三個可能時段供對方挑選；接著用一封簡短的信或訊息說明「會議目的、希望解決的問題、我目前的想法」，能附上相關資料就先附上，讓與會者可以提前看過，會議也更容易直接進重點。
- 求助時給選項，不只丟問題：遇到困難需要請人協助、或期待對方採取行動時，我會避免只說「我卡住了」，雙手一攤。比較有效的做法是把需求講清楚，並附上我目前想到的 1–2 個方案或判斷，讓對方可以更快給方向，或直接幫我確認哪條路比較可行。
- 好用的「三明治」溝通法，但不要太客套：我會用比較溫和的三明治結構去溝通，例如：先交代背景與感謝、再清楚提出需求與限制、最後補上下一步與我願意配合的方式。重點不是多有禮貌，而是讓對方一眼就知道「你要我做什麼、我該怎麼回」。
- 把討論結果寫成可追蹤的結論：開完會或討論完方案後，我會用一小段文字整理出，決定了什麼、誰負責什麼、下一個 checkpoint 是什麼。當然也可以交給AI 會議記錄軟體來做。這對跨部門協作特別有用，因為可以避免大家各自記憶不同，也能降低重複溝通的成本。
- 回覆速度也盡量明確：畢竟工作不是在跟別人曖昧，所以只要是跟工作相關的訊息或 email，我覺得如果短時間內沒辦法給出明確回覆，也要盡量先回一個「收到＋預計何時給完整回覆」。即使當下還沒辦法立刻處理，先讓對方知道你有接到、事情沒有被放著，能大幅降低誤會與來回追問。
Culture
雖然我只是實習生，但我會從實習生的視角分享我看到的研華。整體氛圍比我原本想像更開放、友善；以 Data Intelligence Team 來說，實習生和正職互動很活絡。我覺得這是一段很理想的實習體驗，像是實習生能主動和跨部門開會、跟 mentor 討論並提案專案架構與方向，更重要的是專案真的會落地，而不是只做表面或試驗性的專案。
期中、期末實習發表
- 研華很重視他們的實習計畫，會有高層來看實習生各個主題的發表。對於主題的多元性、實際效益很要求。最後有拿了 Best Practice Award 🎉
職涯分享
除了原本各領域（UI/UX, RD等）的職涯分享會及期末結業式的分享之外，也謝謝 HR 主管 邀請 Team上的主管及前輩撥空分享職涯心得，蠻受用的。
點數換食物
每個月大概會有價值新台幣九百元的點數，可以拿去換公司內部咖啡廳的餐點或是一些不錯的餐卷，因為有待滿一段時間，所以我除了拿來吃早餐（Knock Knock Coffee的bagel很好吃）、買咖啡，還換了兩張假日旭集/饗饗的晚餐餐卷。另外，在我實習的時候每週會有一天可以遠距，並且每天3:30-4:00是彈性休息時間，可以繼續工作或做別的事，轉換一下腦袋。
Reflection
當初想實習的初衷是想體驗以大學生身份在企業工作，還曾經焦慮找不到實習，進來之後確實也體會到真正大企業工作的生態，像是文化、工作協作習慣等等。總之，雖然實習能賺點錢，但我覺得有沒有實習都很好，重要的是知道如何精進自己的實力吧！