🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正／微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付
前言
感謝您打開本文！
目前我正在利用 GitHub Copilot 進行業務效率化的 Web 應用程式開發。
本文將分享其中一個專案，利用 OCR 的報銷申請應用程式 的開發過程中的學習體會。
敬請參閱！
目錄
開發背景與所使用的技術
開發背景
- 輸入數字時出現錯誤導致資料被退回
- 西曆與和曆混淆
- 月底集中輸入 → 精神崩潰
我認為以上問題在報銷申請中是常見的。
想要解決「報銷申請的常見問題」！
如果收據資訊能夠自動讀取並完成輸入，
那麼報銷申請所需的時間將大大減少！
這就是我開始開發的動機。
結果不僅是寫了一個應用程式，我也在與前輩的互動中學到了很多關於 OCR 精度的挑戰。
本文將講述這個故事。
技術棧
- 前端: React 19 + Vite（快速重載增加試用次數）
- UI / 樣式: MUI + Tailwind（組件加微調間距）
- OCR: OCR.space API + 瀏覽器前處理（裁切/二值化）→ 用正規表達式抽取金額、日期和商店候選
- Docker: node:20 為基礎的開發容器
- GitHub Copilot: 實作輔助
應用程式概述
應用程式流程
- 拍攝收據並上傳
- OCR 讀取金額、日期和商店名稱
- 自動填入表單
- 用戶確認和修正後提交
輸入幾乎為零，人要做的只有最後的檢查而已！
OCR 精度的瓶頸與改善方法
期待著運行的結果…。
因為我手中握著的正是收據。
「收據完全亂七八糟根本讀不出來！」
「這個金額，1,000,000 日元根本不可能！（笑）」
老實說，當時我不免感到擔心，「這個真的能實用嗎…？」
在此期間和前輩的閒聊。
「這張收據，連人眼都無法讀取的程度吧？」
這句話讓我看到了改善的方向。
1. 圖像前處理
- 上傳時自動裁切空白邊緣
- 進行亮度修正以提高清晰度
👉 因為 OCR 經常因為圖像大小造成識別失敗，因此我們通過裁切等手段來確保修正。
2. 金額驗證
- 檢查「數值型」和「範圍（1～100 萬元）」
👉 讓￥1,234輸入為l234時能立即檢出。
3. 方便用戶修正的 UI
- 不鎖定輸入欄以便進行修正
- 提供單擊切換候選
👉 即使不是完全自動化，也能大大減少修正過程的壓力。
此外，我也得到了 GitHub Copilot 的幫助。
- 僅需撰寫註解，即可建議帶有正規表達式的驗證
- 自動生成 React 的表單更新邏輯
這種「人的智慧」以及能夠負責重複處理的「AI 支援」的結合，
大大推進了開發進度。
結果，成功減少了約 80% 的輸入量！
最後
結果
- 約需 30 秒即可完成輸入
- 如果 OCR 的精度穩定，退回的資料也將大幅減少
學習
- OCR 不完美，因此「如何落實到現實中」的思考至關重要
- AI 與人類的結合是最強的
- 「與周圍的人一起進行」是改善的捷徑
如果這篇文章能成為「我也想挑戰一下」的動機，我將非常高興！
雖然仍然有很多需要改進的地方，但
希望透過小小的努力積累，逐步接近實用的工具。
感謝您閱讀到最後！！
原文出處：https://qiita.com/ishikawa_slj/items/05dcae0d429dee8769aa
共有 0 則留言
文字內容提供幾種功能：
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
熱門文章
🏆 本月排行榜
評分標準：發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正／微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付