我能帶來什麼

直接與握有問題的人一起工作 —— 營運人員、創辦人、客戶自己的工程師 —— 把一份不完整的需求，變成有明確範圍、有報價、並且對「完成」有共識的方案。這件事我從兩邊都做過：在企業內部擔任業務流程專員，把沒有文件的財務與物流流程畫出來；也以外部工程師的身分，為從沒買過 AI 系統的中小企業做專案評估。

支撐

需求探索 · As-Is / To-Be 流程梳理 · 含成本的建置估算 · 開工前書面確認 · 利害關係人工作坊

已在此證明 案例 02 · 案例 04

必須在真實營運裡跑起來的 AI 系統：單據擷取，並且在寫入之前有一道人工覆核；客服 AI 的知識結構、工具呼叫、對話管理與轉真人；以及橫跨財務與物流、原本靠手動輸入的 RPA 流程。

支撐

OpenAI / Claude APIs · RAG · 檢索調校 · prompt 版本管理 · tool calling · OCR（PyTesseract）· Power Automate · Datagrand RPA · Selenium · LangChain / LangGraph（評估過）· Ragas（概念驗證）· n8n · Dify

已在此證明 案例 02 · 案例 03

把本來沒打算被連起來的系統連起來 —— 客戶的舊 ERP、完全沒有 API 的來源系統、第三方電商與支付平台、訊息佇列，以及夾在中間的人工步驟。反覆出現的決定是自建還是採購，而我兩邊都做過夠多次，知道真正有意思的問題是：哪一個限制會讓「買來的元件」失效。

支撐

REST API 設計 · OpenAPI / Swagger · webhooks · OAuth 2.0 / JWT · RabbitMQ · Redis · PostgreSQL / MySQL · Shopify API · Stripe · PayPal · 非侵入式整合

已在此證明 案例 01 · 案例 02

系統上線之後仍然由我負責。長任務從斷點續跑，而不是從頭再來。失敗要在人還能退回手動流程的時間點浮現出來。以佇列處理，讓一個慢請求不會擋住下一位客戶。提交要具冪等性，重新整理頁面不會重複觸發。閒置的資源要被釋放，而不是一直被佔著。

支撐

queue workers · 非同步處理 · 檢查點續跑 · 冪等提交 · 快取策略 · Docker · NGINX · CI/CD · AWS / GCP / Azure · 監控與告警

已在此證明 案例 03 · 案例 05

我帶的是交付與技術決策，不是人數：聽完團隊意見之後的最終架構與選型拍板、一個團隊照著走的 code review 規矩，以及把工程師從真正卡住他們的地方帶出來 —— 以我的經驗，那幾乎永遠是介面契約，而不是程式碼。

支撐

技術領導 · code review 實務 · 帶人 · 衝刺規劃與工作拆解 · 三語交付（English · 華語 · Bahasa Malaysia）

已在此證明 案例 01 · 案例 05