Portfolio · 作品集

從需求到落地,
每一步都看得見。

作品分為兩部分:職場專案是我在金融科技公司擔任資深專員(軟體 PM)時負責的系統功能;個人專案則是我運用 AI 工具獨立打造的產品。每個案例都整理了問題、做法、介面示意與我的收穫。

🔒 本作品集所有介面圖與架構圖皆為自製示意,不含任何公司內部資料或真實個人資料。
PART A · 職場專案

金融科技 APP 產品功能

2026 年在金融科技公司擔任資深專員、負責 APP 開發部門軟體 PM 工作時經手的功能。以下介面皆為重新繪製的示意圖,已去除所有公司內部資料、案件與客戶資訊。

WORK 01

客戶自主補錄影 新增功能2026.08 上線

問題:數位進件需要客戶錄影,若錄影不符規範,案件就會被審查單位退回待補。過去只能請客戶重新進件,流程長、客戶也得從頭來過。

我的做法:規劃「客戶自主補錄影」新流程:業務在 APP 上對待補案件發送補錄影連結,客戶點開後完成 OTP 身分驗證 → 檢視合約與補件說明 → 上傳影片,結果自動回寫到案件歷程。

新增功能效益評估跨部門流程梳理mWebAxure 原型
角色
資深專員(軟體 PM)
我負責的事
效益評估 · 作業流程梳理 · 待決問題整理與追蹤 · 原型與規格 · 上線追蹤
合作單位
業務端 · 審查單位 · RD
狀態
2026.08 上線

作業流程(示意)

串起審查單位、業務 APP 與客戶端三方的動線
審查案件標示待補/附條件,
原因含錄影不符規範
→
業務 APP點選「補錄影」,
以簡訊或連結發送給客戶
→
客戶 mWeb驗證身分、確認合約,
重新錄影上傳
→
回寫系統補件紀錄寫入案件歷程,
審查單位接續審核
補錄影 · 身分驗證
A1•••••789
09••-•••-123
4820
驗證並繼續
① OTP 驗證,確認是本人操作
補錄影 · 確認內容
案件狀態:待補件
原因:錄影內容不符規範,請重新錄製
合約摘要
申辦商品示意商品
分期金額$••,•••
期數24 期
我已確認,開始錄影
② 檢視合約與補件說明
補錄影 · 錄影上傳
● REC 00:12
✓ 臉部完整入鏡
✓ 清楚念出確認聲明
✓ 光線充足、無遮擋
上傳影片
③ 依提示錄影並上傳
📊

效益評估

統計一段期間內因錄影問題被退回的案件,逐案檢視退件原因,評估補錄影實際能幫助多少案件,作為規劃依據。

🧭

流程梳理

畫出審查、業務 APP、客戶端三方動線,讓 RD 與業務端對流程有一致理解。

❓

待決問題清單

整理例外情境(例如同時需要補保人與補錄影),逐項與業務端討論並記錄決議。

💡 我從這個專案學到的

新功能開發前先用實際案件做效益評估,能讓討論聚焦在「值不值得做、做了能解決多少問題」。把各方動線畫在同一張圖上,也讓跨部門會議更快達成共識。

WORK 02

數位進件暫存區 · 客戶姓名備註 系統優化2026.08 上線

問題:業務在 APP 送出數位進件後,客戶尚未填完資料的案件會留在「暫存區」。原本只顯示通路商、商品、金額與訂單編號,業務很難分辨哪一筆是哪位客戶。

我的做法:在進件畫面新增非必填的「客戶姓名備註」(上限 20 字),只顯示在暫存區供業務識別,不寫入核心系統、也不帶入客戶填寫欄位,避免輸入錯誤影響後續作業;同時把訂單編號改為送出時間,更容易對照。

系統優化使用者回饋方案比較版本迭代
角色
資深專員(軟體 PM)
我負責的事
V3 規格細調 · 欄位與顯示規則確認 · 原型調整 · 上線追蹤
需求來源
業務端回饋
狀態
2026.08 上線
調整前
數位進件暫存區
範例通路商 A
保養品 · $50,000
訂單 #A10•••21
範例通路商 A
保養品 · $50,000
訂單 #A10•••37
範例通路商 B
課程 · $36,000
訂單 #B20•••05
同一通路、同金額的兩筆案件無法分辨
調整後
數位進件暫存區
範例通路商 A
保養品 · $50,000
王小明
2026.06.22 19:32
範例通路商 A
保養品 · $50,000
陳美美
2026.06.22 20:05
範例通路商 B
課程 · $36,000
2026.06.23 10:14
多了姓名備註與送出時間;未填備註則略過不顯示
新增欄位
數位進件
保養品
$50,000
*僅供暫存區識別用,上限 20 字元*
送出
備註欄位以提示文字說明用途

版本迭代

V1
初版方案,整理現況欄位與顯示邏輯
V2
依業務端回饋,確認採用方案一
V3
依主管意見細調顯示規則(由我負責),2026.08 上線

💡 我從這個專案學到的

小改動也要想清楚資料的邊界:備註只用於識別、不進核心系統,既解決業務的痛點,也避免新欄位帶來資料錯誤的風險。

WORK 03

提前結清試算 新增功能需求規劃與原型

問題:客戶想提前結清分期時,無法在 APP 上自行查詢結清金額與匯款方式。

我的做法:在 APP 繳款頁新增「結清查詢」分頁,讓客戶自行選擇合約與結清日期、即時試算金額,並依匯款方式(單筆/分次)與案件類型,提供對應的收款帳戶。每次試算都回寫到系統留存紀錄。

新增功能業務規則設計例外情境處理Axure 原型
角色
資深專員(軟體 PM)
我負責的事
規則梳理 · 原型設計 · 文案撰寫 · 跨部門確認與決議紀錄
合作單位
相關業務單位 · RD
狀態
需求規劃與原型階段
繳款 · 結清查詢
繳款結清查詢
C0••••••••21 ▾
11121314151617
每日查詢次數上限 5 次
確認查詢
① 選合約與日期,例假日與已過截止時間的日期不可選
試算結果
結清總金額
$38,500
繳款截止:結清日 15:30 前
超過期限請重新試算;逾時匯款可能因計息產生差額,需另行補繳。
前往繳費
② 顯示金額與繳款期限(示意金額)
請選擇匯款方式
單筆匯款一次繳足結清金額
多筆匯款受網銀上限等因素需分次匯款
收款銀行示意銀行
帳號••••-••••-1234
複製帳號
③ 依匯款方式顯示對應帳戶

我整理的業務規則(節錄)

原型中逐條標註,作為 RD 開發與測試的依據
項目規則
合約篩選排除已結清、已退購、呆帳、逾期等不適用的合約
可選日期最早為今日、最晚為下一次應繳日;例假日不可選
時間限制配合銀行入帳時間,當日超過截止時間後改為下一個可選日
查詢次數每日上限 5 次,每次試算紀錄回寫系統
帳戶分流依單筆/多筆匯款與特定案件類型,提供不同收款帳戶

💡 我從這個專案學到的

金融功能的難度在於例外情境:時間截止、假日、案件類型、匯款上限都會影響結果。把每條規則寫清楚、標在原型上,並記錄每次會議的決議,是讓開發與驗收不出錯的關鍵。

PART B · 個人專案

運用 AI 工具獨立開發

以 Claude Code 等 AI 工具為開發夥伴,從構想、規劃、架構到開發都由我獨立完成;這些是我接觸 Claude Code 不到兩個月內的成果。

CASE 01

對話式 AI 互動助理系統 已上線運作中

問題:想打造一個能「主動關心、即時回應、並持續陪伴」的對話式助理,而不只是被動等指令的機器人。

我的做法:以 LINE 為載體,設計一套結合語意回應、情緒分類、主動推播與輕量小程式的對話體驗;用 Cloudflare 的無伺服器架構讓它低成本、全天候運作,並用 AI 工具協助我完成開發與部署。

對話式 AIServerless情緒分類 主動推播使用者留存設計平台化複用
角色
產品構想 · 體驗設計 · 架構 · 開發 · 部署(獨立完成)
開發方式
以 AI 工具(Claude Code 等)為開發夥伴
技術棧
Cloudflare Worker · LIFF · R2 · LINE Messaging API
狀態
已上線,穩定運作中

系統架構(示意)

一個 Worker 統籌 webhook、排程、小程式與圖庫
使用者 LINE Cloudflare Worker 核心邏輯 · 全天候 語意回應 + 情緒分類 20+ 關鍵字 · 4 類安撫 Cron 排程推播 5 組定時主動訊息 LIFF Mini App 9 個功能子頁 R2 雲端圖庫 圖片儲存與存取
AI 智慧助理
⏰ 定時主動推播早安!今天也要好好的 🌞
今天有點累…
💛 情緒分類 → 安撫辛苦了,先深呼吸一下,我在這裡陪你 🫶
① 對話 · 情緒安撫(示意)
AI 智慧助理
需要什麼,點下面的選單就好 👇
📅今日問候
🎴集點卡
🏆成就
🎟️優惠券
🖼️相簿
⚙️設定
② 功能選單 Rich Menu(示意)
≡ Mini App
🎴 集點卡
已集 3 / 6 點
🏆 成就徽章
已解鎖 5 / 8
🎟️ 我的優惠券
可用 2 張
③ LIFF 小程式子頁(示意)
💬

語意關鍵字回應

辨識 20+ 種情境關鍵字,對應不同回覆與動作。

💛

情緒分類安撫

將訊息分為 4 類情緒情境,給出對應的安撫式回應。

⏰

主動排程推播

5 組 Cron 定時任務,讓助理「主動關心」而非被動等待。

🧩

LIFF 小程式

內嵌 9 個功能子頁,把複雜互動收進輕量小程式。

🎮

遊戲化留存

集點、成就、優惠券機制,提升回訪與黏著度。

♻️

平台化複用

同一套架構複用、部署第二個帳號,並做到環境完全隔離。

9
Mini App 子頁
20+
語意回應情境
5
自動化排程
2
品牌帳號複用

💡 我從這個專案學到的

好的對話產品關鍵不在「能回答多少問題」,而在主動性與情緒體驗。把「被動等指令」翻轉成「主動關心」,是留存的分水嶺。同時我也驗證了:不會寫 code 的人,只要懂產品、會用 AI 工具,一樣能把完整系統 ship 上線。

CASE 02

多店雲端 POS 系統 封測中

問題:多分店的零售 / 餐飲場景,需要跨店即時同步的訂單、商品與庫存,傳統單機 POS 難以共享資料、也不易擴充。

我的做法:用 Cloudflare 的邊緣運算 + D1 資料庫打造雲端 POS,並以 Durable Objects 處理即時狀態同步讓多店資料一致。把整個專案拆成六個可驗收的里程碑,逐步開發與測試。

複雜系統規劃階段化開發即時同步 多租戶MVP → 迭代
角色
產品規劃 · 系統架構 · 開發
開發方式
以 AI 工具為開發夥伴
技術棧
Cloudflare Worker · D1 · Durable Objects
狀態
核心功能封測中,尚未正式上線

結帳介面(示意)

前台點選商品 → 即時帶入購物車 → 結帳
☕ 多店雲端 POS · 三重店
美式$60
拿鐵$80
手沖$120
蛋糕$90
餅乾$45
豆子$350
拿鐵 ×1$80
手沖 ×1$120
蛋糕 ×1$90
合計$290
結帳
介面示意圖(非真實資料)

系統架構(示意)

Worker 處理 API,D1 存資料,Durable Objects 負責即時同步
多店前台 店員裝置 Cloudflare Worker API 邏輯 D1 資料庫 訂單 · 商品 · 庫存 Durable Objects 多店即時同步

六階段里程碑

STEP 1
資料模型與基礎架構
STEP 2
商品與庫存管理
STEP 3
訂單與結帳流程
STEP 4
多店租戶與權限
STEP 5
即時同步(Durable Objects)
STEP 6
封測與正式上線

💡 我從這個專案學到的

面對龐大需求,「拆成可驗收的階段」比「一次做完」重要太多——每個里程碑都能獨立驗證、降低風險。我也學到先完成核心功能(MVP)進入封測、再依測試回饋逐步補強,遠勝於追求一次到位。

CASE 03

結構化知識庫與自動化推播

問題:有價值的資訊(咖啡店評鑑、AI 工具)散落各處、難以累積與再利用,也沒有主動觸及使用者的管道。

我的做法:把資料結構化進可持續累積的資料庫,設計清楚的欄位;再串接定時排程,把資料自動整理、主動推播到 LINE / Telegram。

資料結構化自動化工作流排程系統多渠道推播
角色
資料流設計 · 自動化
開發方式
以 AI 工具為開發夥伴
技術棧
試算表資料管線 · Cron 排程 · LINE / Telegram 推播
狀態
運作中

資料流程(示意)

從蒐集、結構化、排程處理到主動推播
資料蒐集 手動 / 整理 結構化資料庫 試算表 · 欄位設計 排程處理 Cron 自動執行 主動推播 LINE / Telegram

結構化欄位(示意)

以咖啡店評鑑資料庫為例
店名地區評分特色標籤筆記
範例咖啡 A大安區4.5手沖 · 安靜單品選擇多
範例咖啡 B中山區4.2不限時 · 插座適合工作
範例咖啡 C三重區4.8自家烘焙豆子值得買
示意資料,非真實內容

💡 我從這個專案學到的

資料的價值來自「結構」與「流動」:好的欄位設計讓資料可被累積與再利用;自動化排程則讓它不必靠人力就能主動送達。這也是數據型產品的底層思維——先把資料整理好,價值才長得出來。