作品簡報

返回網站

作品簡報8–10 分鐘工程作品簡報

01 · Executive Summary

邱璽睿|Software Automation Engineer

現職研華 Software Engineer;以 Golang/Python 開發伺服器壓力測試、熱控制、設備監控與 QA 工具,AI 僅在可驗證規則與人工閘門內協助。

流程自動化以 Golang/Python 串接設備、排程、API 與工程作業。
可觀測平台將 IPMI/SNMP 與執行狀態整理成 metrics、logs 與告警。
受控 AI 應用讓模型產生候選內容,由 deterministic rules 與人員決定寫入。

主軸|Software Automation/Platform 副軸|AI Applications 基礎|DSP/Firmware

邱璽睿的個人照片

02 · Career & Ownership

從訊號分析,走到工程流程與平台自動化

責任範圍由研究演算法與產品韌體,逐步延伸到跨設備、跨服務的軟體系統。

  1. 研華 AdvantechSoftware Engineer

    負責 Golang/Python 自動化、伺服器控制、IPMI/SNMP 整合,以及 Prometheus/Grafana 與 AI-assisted QA。

  2. SentonsDSP / Firmware Engineer

    負責 MATLAB 訊號分析、C# WPF 校正工具與通過驗證後的 C++ 韌體功能。

  3. 國立成功大學Biomedical Engineering M.S.

    提出超音波影像處理方法,以 SVD、背景抑制與結構增強完成研究驗證。

求職定位:Software Automation/Platform 為主,AI application 次之;DSP/Firmware 是處理裝置與實體訊號邊界的基礎。

03 · Engineering Method

Sense → Model / Contract → Automate → Observe / Verify

主線是把工程流程做成軟體;AI 與 DSP 在需要理解非結構資料或實體訊號時提供支援。

  1. 01Sense

    取得 BMC、SNMP、波形、issue 與 workflow state。

  2. 02Model / Contract

    定義功耗反應、熱特徵、測試真相與資料語意。

  3. 03Automate

    以 controller、agent、collector 與 pipeline 執行。

  4. 04Observe / Verify

    保存 metrics、logs、assertions 與人工閘門。

主線|Software Automation:Adapters → Orchestration → Observability → Gated Action

支援|AI:候選內容與脈絡協助 · DSP/Firmware:訊號、裝置與產品邊界

04 · Automation Case

目標功耗壓力測試:單一 Controller 協調多台伺服器

Situation|情境

固定 burn-in 比例可以製造高負載,卻不保證接近指定 system wattage;多台 SUT 的狀態與長時間 log 也分散。

Task / Ownership|責任

我設計 Golang controller/agent 流程、pre-test 功耗反應建模與 telemetry 回顧路徑;成功條件是可重跑排程、回收狀態並留下工程師可檢查的資料。

  1. Operator
  2. Go Controller
  3. Go Agents / SUT
  4. Telemetry & Logs
  5. Grafana

Action|三個工程決定

  1. 依元件反應建模

    前測顯示 CPU 可近似線性、Memory/Ethernet 呈飽和;因此不把所有 workload 設成相同比例。

  2. Agent 本地緩衝 logs

    短暫斷線時先保留執行紀錄,再回傳 controller,降低長時間測試的資料缺口。

  3. AI 不做診斷結論

    模型只產生待工程師確認的圖表 observation;功率、溫度、風扇與 throttling telemetry 才是回顧來源。

Result|交付

完成一對多排程、狀態回傳、目標功耗 workload 估算,以及長時間遙測保存。

Evidence|驗證與觀測

以實際 Grafana dashboard 檢查功率、溫度、風扇、頻率與 throttling 時序。

Boundary|邊界 公開資料未提供 target-power MAE 或 recovery test,因此不宣稱精準命中。

案例與揭露範圍 (在新分頁開啟)
壓力測試的 Grafana 功率、溫度、風扇、頻率與 throttling 儀表板

05 · Automation Case

伺服器熱控:把數週人工 PID 調校縮短為數小時流程

Situation|情境

Open-loop 控制可能長期 over-cooling;PID 若靠反覆試調,流程可能耗時數週且難以重現。

Task / Ownership|責任

我負責 Golang host controller、steady-state profile 方法、參數推導,以及 load dump 的 non-zero integral reset 設計;參數須可重算且經工程驗證後才能交付 BMC。

  1. Environmental Chamber
  2. Host Controller
  3. SUT / BMC
  4. Workload / Fan

Action|三個工程決定

  1. 以平衡點建立 profile

    用 dT/dt ≈ 0 定義 steady state,再由 profile slope 與 system gain 推導可解釋參數。

  2. 離線推導不直接控制產品

    候選參數必須經工程驗證才交付 BMC,避免模型輸出跨過產品控制邊界。

  3. Load dump 後非零重置

    將積分項重置到動態計算的安全基準,而不是清零,以降低 RPM 下探與震盪風險。

Result|交付

在原特定內部流程中,將可能耗時數週的人工調校縮短為數小時,形成參數 handoff 程序,並累積伺服器熱控制相關專利申請經驗。

Evidence|驗證與觀測

平衡點偵測與資料記錄流程可重跑;交付前仍由工程人員檢查 profile 與候選參數。

Boundary|邊界 「數週到數小時」是特定流程結果,不是跨機種 benchmark。

方法與安全邊界 (在新分頁開啟)
伺服器熱特徵平衡點偵測與資料記錄流程

06 · Platform Case

Rack Observability:在 Collector 邊界統一 IPMI/SNMP

Situation|情境

Server、switch 與 PDU 使用不同協定、MIB 與欄位,工程師必須分別查看設備介面。

Task / Ownership|責任

我依 Netgear、Cisco、Raritan MIB 實作採集邏輯,並把 BMC/IPMI 與 SNMP 資料正規化為 Prometheus metrics。

  1. BMC / IPMI
  2. Vendor SNMP Adapters
  3. Collectors
  4. Prometheus
  5. Grafana / Alerts

Action|三個工程決定

  1. 保留來源語意

    metric 保留 device class 與 source,不假設不同設備的同名欄位具有相同語意。

  2. 遙測與控制分離

    唯讀 telemetry 走觀測管線;PDU power control 需要獨立授權與稽核。

  3. Adapter 隔離 vendor 差異

    新增 vendor 時修改邊界 collector,而不重寫 dashboard 的核心資料模型。

Result|交付

形成跨 server、switch 與 PDU 的單一 Prometheus/Grafana 觀測路徑,並支援 threshold alerts。

Evidence|驗證與觀測

以 collector → Prometheus → Grafana 架構與實際設備類別逐項核對資料來源。

Boundary|邊界 不宣稱未公開的 polling SLA、部署規模或全型號相容性。

採集實作與限制 (在新分頁開啟)
IPMI 與 SNMP adapter 經 collectors 進入 Prometheus 與 Grafana 的架構

07 · AI Application Case

AI Quality Pilot:規則引擎掌握 PASS 與寫入權

Situation|情境

LLM 若同時負責執行、判定 PASS 和修改 tracker,容易把合理敘述誤當成已驗證結果。

Task / Ownership|責任

我設計公開系統 contract,實作 Python engine、case/evidence pipeline、四軸 truth model、Task/Knowledge Graph 與 issue/Wiki/PR gate。

  1. Hermes / LLM
  2. Candidate Content
  3. Deterministic Engine
  4. Evidence
  5. Write Gate / Human

Action|三個工程決定

  1. 分開四種真相

    workflow_status、test_outcome、gate_status、health_status 各自演進,避免單一 done 掩蓋失敗。

  2. 驗證 evidence,而非只看 exit code

    保存 structured assertions、stdout/stderr、duration、contract hash 與 freshness。

  3. 不可逆操作保留 human gate

    命令採 allowlist 與 shell=False;issue、Wiki、PR 等遠端寫入需 deterministic gate。

Result|交付

交付 MIT 授權、repository-agnostic 的 QA toolkit;可追蹤狀態、證據、local gates 與遠端寫入 request artifacts。

Evidence|驗證與觀測

公開 repository 與 architecture 文件可檢查;能力表明示 Supported、Partial、Planned。

Boundary|邊界 Supported:contract/evidence/local gates;Partial:MCP 與 repair handoff;Planned:更完整遠端整合。

公開架構與 capability matrix (在新分頁開啟)
AI Quality Pilot 將 LLM 與 deterministic engine、evidence 和寫入閘門分離的架構

08 · Supporting DSP / Firmware

DSP 產品化:從量測波形到 C++ 韌體交付

Situation|情境

超音波觸控參數會隨材料、硬體與環境改變;直接編輯 config 難以把手勢、波形與參數放在同一脈絡檢查。

Task / Ownership|責任

我負責 MATLAB 訊號分析、C# WPF 裝置與校正工具,以及把通過驗證的參數或需求功能實作到 C++ 韌體。

  1. Measured Waveform
  2. MATLAB Analysis
  3. C# WPF Calibration
  4. Engineer Validation
  5. C++ Firmware

Action|三個工程決定

  1. 先保留時頻脈絡

    用 MATLAB 進行時域/頻域、模擬及線性/非線性濾波,避免只看單一數值。

  2. 工具提出候選頻段

    WPF GUI 整合手勢引導、裝置通訊與波形顯示,讓候選參數可在同一介面複核。

  3. 驗證後才進韌體

    候選參數經產品流程確認後才由 C++ 交付,不宣稱跨材料的一鍵最佳值。

Result|交付

建立 signal-to-firmware 的可複核 handoff,支援產品驗證與量產問題處理。

Evidence|驗證與觀測

波形脈絡、候選參數與韌體交付點均保留人工檢查;產品成果屬團隊協作。

Boundary|邊界 客戶、型號、良率與未公開量化結果不進簡報。

DSP/韌體案例 (在新分頁開啟)
從超音波量測波形、分析與校正到 C++ 韌體的流程

10 · Skills × Project Evidence

技能樹與專案證據對照

依工作層次整理技術,並將每一組能力連回實際交付物。

Backend / AutomationGolang · Python · FastAPI · REST

壓力測試 controller/agent;熱控 host controller;Redmine local service

Infrastructure / DataIPMI · SNMP · Prometheus · Grafana · Linux

Rack collectors;壓測 telemetry;Lightnews self-hosted workflow

AI / QAPytest · BDD · MCP · Ollama · n8n

AI Quality Pilot contracts/evidence/gates;Lightnews reviewable drafts

DSP / FirmwareMATLAB · C# WPF · C++ · SVD

Sentons calibration-to-firmware;高頻超音波影像研究

11 · Role Fit

Software Automation/Platform|我能承接的問題

我適合承接設備、API、資料與驗證仍分散在人工流程中的問題。

  • 實驗室或工程工作流仰賴人工執行、抄錄與回顧。
  • 團隊需要串接裝置協定、服務 API、排程與 observability。
  • AI 功能必須有 truth source、validation 與安全寫入邊界。

合作方式|先與 domain expert 定義成功條件與不可跨越的控制邊界,再用小步可觀測交付迭代。

我能完整承接|Adapters → Orchestration → Observability → Gated Action

如果這正是團隊要解決的問題,我希望進一步討論。

前往邱璽睿作品集網站的 QR code

A1 · Lightnews STAR+

Lightnews:本地 LLM 技術內容草稿管線

Situation|情境

技術內容整理需要反覆切換 RSS、網頁清理、翻譯、摘要、圖片與 CMS。

Task / Ownership|責任

我設計 Linux-hosted 工作流,目標是產生格式一致、可人工審查的繁體中文草稿。

  1. RSS
  2. n8n Extraction
  3. Ollama
  4. Image Candidate
  5. WordPress Draft
  6. Editor

Action|三個工程決定

  1. n8n 負責 orchestration

    集中 RSS watching、extraction、HTML cleaning、branches 與 CMS handoff,讓每一步可檢查。

  2. 文字推論留在自管 host

    以 Ollama 產生摘要、翻譯、分類與圖片關鍵字,減少文字送往第三方 LLM API。

  3. WordPress 預設為 draft

    來源語意、翻譯、圖片授權與發布由編輯決定;模型沒有 publish authority。

Result|交付

交付可瀏覽的繁體中文科技新聞網站與 reviewable draft pipeline。

Evidence|驗證與觀測

公開網站畫面可檢查文章、分類與發布呈現。

Boundary|邊界 本地僅指文字推論;RSS、Unsplash 與 WordPress 仍是外部邊界。

完整案例 (在新分頁開啟)
Lightnews 網站文章與分類畫面

A2 · Redmine STAR+

Redmine Smart Companion:Plan → Track → Review → Log

Situation|情境

一筆工時在原情境可能涉及約十次點擊與頁面切換,也不容易檢查一週是否漏記。

Task / Ownership|責任

我重設 Plan → Track → Review → Log 流程,完成 React/Electron UI、本機 FastAPI service 與 Windows installer。

  1. React Planner
  2. Electron
  3. Local FastAPI
  4. Redmine API
  5. Review / Log

Action|三個工程決定

  1. 保留 Python backend

    沿用既有 Redmine 自動化資產,避免為桌面介面重寫整個 API 邏輯。

  2. 桌面生命週期與服務分離

    Electron 管 UI/process lifecycle;PyInstaller 封裝 backend,使用者不需另裝 Python。

  3. 本機整理與遠端寫入分狀態

    規劃、追蹤與 review 不等於已寫入 Redmine,介面明確保留提交邊界。

Result|交付

交付 Windows planner/calendar/dashboard 與 Redmine time-entry 工作流。

Evidence|驗證與觀測

實際 calendar UI 證明規劃與 review 介面;Windows packaging 有公開描述。

Boundary|邊界 不宣稱 macOS/Linux 發布、固定生產力提升或未公開的 remote-write 測試。

完整案例 (在新分頁開啟)
Redmine Smart Companion 的週曆規劃介面

A3 · Biomedical Imaging STAR+

HFUDCEI:微都卜勒血管結構增強

Situation|情境

小鼠器官與受傷手指肌腱的微血流,需要更強的組織 clutter 分離、背景抑制與曲線血管增強。

Task / Ownership|責任

我提出 HFUDCEI 影像演算法,並在動物與人體研究資料上評估方法。

  1. Ultrafast Ultrasound
  2. Block-wise SVD
  3. Background Suppression
  4. Vesselness
  5. Research Evaluation

Action|三個工程決定

  1. Block-wise SVD 分離訊號

    將 tissue/clutter components 與 flow information 分開,降低組織運動干擾。

  2. 先抑制背景再增強結構

    避免 Hessian/Frangi-style multiscale vesselness 同時放大殘餘雜訊。

  3. 同時比較與追蹤

    比較四個小鼠腎臟案例,並觀察人體追蹤案例中的肌腱新生血管呈現。

Result|交付

交付並發表微都卜勒方法,用於顯示血管樹與研究手指肌腱新生血管。

Evidence|驗證與觀測

公開比較影像與論文記錄 CNR 20.76 dB、SNR 71.98 dB;約 35 μm 僅指可見血管結構直徑。

Boundary|邊界 人體恢復關聯屬初步研究,不能解讀為診斷或因果證明。

研究案例與論文 (在新分頁開啟)
HFUDCEI 方法的影像品質與血管 profile 比較結果

A5 · Claim & Disclosure Notes

成果主張與揭露邊界

熱控流程從數週縮短到數小時
只適用於已描述的特定內部調校流程;不是跨機種 benchmark。
AI Quality Pilot close loop
公開版為 partial close loop;Supported/Partial/Planned 必須分開閱讀。
約 35 μm
指公開研究中約 35 μm 直徑血管結構的可見性,不是泛稱系統解析度。
企業專案成果
不揭露客戶、產品型號、hosts、帳號、拓樸、係數、門檻、原始測試資料或法務狀態。
未列公開 metric 的案例
只陳述已交付 artifact 與可觀測能力,不推估規模、準確率、節省或部署狀態。