PROJECT 03

Waterson 製造業 AI 專案:鉸鏈配對 PoC 與 AI Email 業務助理

笠源科技(Waterson)是水五金製造商,想用 AI 解兩個真實痛點:「鉸鏈產品與客戶需求的配對」與「業務信件量大到讀不完」。但客戶對 AI 成效存疑,方案又必須通過政府(數位發展部)補助案審查——等於同時面對「客戶要被說服、審查委員要被說服」的雙重壓力。我們以可運行的 PoC 對決競爭者的簡報;我負責售前、專案推進與前端開發。

AI PoCLLMPrompt Engineering前端開發政府補助審查AWSAzure OpenAI製造業

角色:售前顧問 兼 PM,並負責前端開發|與工程團隊協作交付

功能一:鉸鏈 AI 配對分析

業務收到的客戶需求是一段自然語言(「我要承重 XX、開展角度 XX、拉籃側裝的鉸鏈」)。系統的做法:AI 先把需求文字轉成規格化的商品規格描述,後端再以這組規格進資料庫查詢符合的產品;業務勾選要推薦的產品後,AI 直接產出回覆客戶的 email 草稿——從讀需求到回信一條龍。

整體流程(高階視角)
flowchart LR
  subgraph W1["業務"]
    A["貼上客戶需求文字"]
    E["勾選要推薦的產品"]
    G["確認後回覆客戶"]
  end
  subgraph W2["AI × 系統"]
    B["AI 把需求轉成
規格化商品描述"] C["後端以規格
查詢產品資料庫"] D["列出符合的產品"] F["AI 產出
回覆 email 草稿"] end A --> B --> C --> D --> E --> F --> G

Demo 影片:鉸鏈 AI 配對分析

實際 PoC 操作錄影:輸入需求條件 → AI 配對分析 → 輸出建議結果。

工程視角:技術時序圖(點開展開)
sequenceDiagram
  autonumber
  actor S as 業務人員
  participant FE as 前端介面(我開發)
  participant AI as AI 模型
  participant BE as 後端服務
  participant DB as 產品資料庫
  S->>FE: 貼上客戶需求文字
  FE->>BE: 送出需求
  BE->>AI: 需求文字 → 規格化商品規格描述
  AI-->>BE: 規格化參數
  BE->>DB: 依規格查詢符合產品
  DB-->>BE: 符合產品清單
  BE-->>FE: 呈現產品與規格對照
  S->>FE: 勾選欲推薦的產品
  FE->>BE: 送出勾選清單
  BE->>AI: 依勾選產品產出回覆 email
  AI-->>BE: email 草稿
  BE-->>FE: 呈現草稿
  FE-->>S: 業務確認後寄出

功能二:AI Email 業務助理(同案交付)

業務團隊每天面對大量往來信件,重要的問價、催單、客訴常被淹沒。同一專案中交付了 AI Email 助理,三大功能各有實際操作影片:

整體流程(高階視角)
flowchart LR
  A["信箱裡
上百封往來信件"] --> B["AI 助理
讀取信件"] B --> C["內容總結"] B --> D["關鍵字析出"] B --> E["未回覆清單
依重要度排序"] C --> F["業務先處理
最要緊的事"] D --> F E --> F

① 內容總結:長討論串一鍵摘要

② 關鍵字析出:從信件中析出關鍵資訊

③ 未回覆查詢+AI 重要度排序

查出尚未回覆的 email,並由 AI 依重要度排序——先回最要緊的。

工程視角:技術時序圖(點開展開)
sequenceDiagram
  autonumber
  actor U as 業務使用者
  participant FE as 前端介面(我開發)
  participant BE as 後端(EC2/SQS)
  participant AI as Azure OpenAI
  U->>FE: 選擇功能(總結/關鍵字/未回覆)
  FE->>BE: 任務請求
  BE->>BE: 取得對應信件資料
  BE->>AI: 分析請求(摘要/關鍵字析出/重要度評分)
  AI-->>BE: 分析結果
  BE-->>FE: 排序清單或摘要報告
  FE-->>U: 呈現結果,點擊可回到原信件
  Note over U,AI: 讀信變成讀結論——
重要的事不再被信海淹沒

正式專案的 AWS 架構

AWS 後台架構
正式專案 AWS 架構:Gmail 使用者流量經 CloudFront → ALB → Elastic Beanstalk(EC2 Auto Scaling);檔案走 S3 Pre-sign URL、信件經 SES、佇列用 SQS、資料庫 Aurora;AI 分析經 NAT Gateway 呼叫 Azure OpenAI

雙重壓力下的攻堅路線

1訪談收斂把「想用 AI」收斂成兩個明確場景:產品配對+Email 助理
2成功指標雙目標事前定義:配對準確率達標+補助審查委員過審
3PoC 開發與工程團隊協作——我負責前端與展示整合,把系統做到能現場操作
4實機對決競爭評比現場以可運行系統對決他廠投影片,客戶當場看見可行性
5審查與延續補助案文件與技術審查過關;PoC 成為正式專案基礎
本案完整文件鏈由我產出:AI 業務助理範疇書、產業 AI 落地簽約計畫書、數發部提案簡報、專案啟動與流程確認簡報。案例全文另刊載於貿易雜誌:「用一個看得見的 PoC,贏下別人用簡報搶不到的信任」(ieatpe.org.tw)

我的角色與成果

為什麼這個案子特別

  • 身兼三角色:售前(訪談與期待管理)、PM(時程與審查文件)、前端開發(配對與 Email 助理的操作介面)
  • 對手用簡報講願景,我們用能點的系統讓客戶自己操作——信任的來源不同
  • 政府補助審查的文件與答辯實戰:公部門的驗收語言從此是我的資產

成果

  • 在競爭評比中擊敗競品,拿下專案
  • 政府補助案審查通過
  • PoC 成為正式專案基礎,AI 配對+Email 助理雙功能交付