🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 10月20日

[個人發展] 建立用於作家教育的「歧義表達檢查器」應用程式 [React × OpenAI × Supabase]

前言

在編輯醫療類 SEO 內容的過程中，與撰稿人之間的修正往返中，最耗時的部分就是「模糊表達的指摘」。

當表達中頻繁使用「〜吧」「有可能」等表述時，不僅會讓讀者難以理解內容，還會直接導致診所信任度降低。

若每次都依賴人力修正，根本無法兼顧文章結構或事實核查等本質性編輯工作。

因此，我此次開發了個人專案「模糊表達檢查器」，能夠一次性完成「檢測模糊表達」「提供理由」「給出重述建議」「歷史記錄可視化」等功能。

為何而作

作為編輯，在對撰稿人提供的文章內容進行校正時，頻繁使用的模糊表達例如「〜吧」「有可能」，經常導致修正指示的多次往返交流。

模糊表達的使用過多，對讀者、編輯和撰稿人來說，都會產生以下的缺點。

讀者

內容的解析度變低，給人「到底怎麼樣？」的印象
在醫療等對準確性要求較高的領域，可能成為損害診所信任度的因素

編輯

每個模糊的地方都需要逐一語言化，導致往返反饋的次數增加
本來應該集中精力的文章結構、事實核查和改善讀者體驗的時間被削減

撰稿人

模糊表達的標準不明確
難以進行量化的成長評估

特別是從撰稿人的角度來看，無法定量了解自己的模糊表達傾向及改善程度，使得將修正內容應用於後續寫作的動力不足。
易形成「被修正 -> 模糊地修正 -> 下一篇文章又被指摘同樣問題」的循環，難以獲得技能提升的實感。

因此，我們提出了一種「不讓模糊保持模糊」的機制，使撰稿人能夠自身實現「發現 -> 修正 -> 學習」的循環，同時打造本產品。

開發中工夫的要點

一鍵檢測和彩色顯示：在 Monaco Editor 上進行正則表達式檢測，根據類別×嚴重程度進行高亮，提供即時反饋
活用 OpenAI Responses API：選擇模糊表達後，通過 JSON Schema 獲取受限的重述建議，並提供敬體和斷定性的改寫
數據持久化的回退：即使 Supabase（PostgreSQL）連接中斷，也能自動切換到 Functions 中的內存實現，設置為 USE_IN_MEMORY_STORAGE=true
成長的可視化：通過歷史記錄及儀表板顯示改善趨勢、類別傾向及頻繁用語，將撰稿人的成長可視化 -> 便於編輯者評估

概念

本產品基於以下價值假設。

可視化：模糊的地方可以視覺上被發現（會注意到）
說服力：了解為何模糊，明白理由（有道理）
推進：獲得重述的提示（節省時間）
成長：修正的積累得以可視化（可以持續進行）

透過了解模糊的理由或可視化成長程度，不僅能提高外包撰稿人的動力，也能知曉模糊表達的理由，以減少同樣理由的反饋，避免編輯者與撰稿人之間的關係惡化。

因此，我們也期待能防止短期合約解除的效果。

編輯者：專注於真正有價值的指摘（結構・論據・讀者體驗）
讀者：能毫不迷惑地把握重點
撰寫者：察覺自我的癖好，感受到進步的環境

這三方同時受益的狀態，是本產品所追求的目標。

產品概述

模糊表達的檢測和高亮：在 Monaco Editor 上檢查文章，根據類別和嚴重程度進行裝飾，並顯示檢測結果列表及頻繁使用的用語
重述候選的提案：參考所選模糊表達前後的 120 字上下文，從 OpenAI 獲取一個建議及其理由
版本保存及歷史管理：保存時記錄 Firebase UID 和著者標籤至 Supabase，歷史畫面比較多個版本並顯示差異
統計儀表板：確認新版與上次之間的差異、模糊度分數的趨勢、類別別的數量及頻繁的模糊語

預期情景（撰稿人視角的流程）

在撰寫草稿時察覺模糊的地方
閱讀理由，轉換為適當的重述
反思積累，瞭解自己的癖好和變化

實際畫面

編輯器畫面

文章輸入與實時檢測（類別×嚴重程度進行高亮，懸停顯示理由）
檢測結果列表的操作（跳至對應部分、根據頻率排序、根據類別排序）
生成和替換重述候選（透過 OpenAI Responses API 獲取敬體・斷定性的建議和理由，並一鍵替換）
標題輸入與自動保存（將內容、標題、文章ID保存至 localStorage／清除）
檢查歷史簡易日誌（數量・字數・處理時間・頻繁用語前3名）
版本保存（以 Firebase Auth 的用戶保存至 Supabase。保存時也記錄測量值）

歷史畫面

獲取及選擇文章列表（每篇文章顯示最新和上次版本的摘要）
顯示版本列表（製作日期、分數、數量、字數等摘要）
使用 Monaco DiffEditor 比較兩個版本（可視化差異）
顯示趨勢（顯示最近兩次的數量・分數增減和增減率）
版本/文章的刪除

儀表板畫面

摘要（最新和上次的摘要：分數、數量、字數、製作日期）
差異（數量/分數的增減及增減率）
分數趨勢（最近最多20次檢查運行的折線圖）
類別趨勢（最近最多10個版本的類別別數量的時間變化）
頻繁用語前列（最近最多200次的檢測，按類別×匹配文本的出現次數、平均嚴重度、最後檢測時間的上位）

<details><summary>儀表板的計算邏輯</summary>

字數 charLength:
- 文章的字數
檢測件數 totalCount:
- 在該檢查中找到的模糊表達的件數
模糊度分數 aimaiScore:
- 正式值 = totalCount * 1000 / charLength（每字的件數以1000字為基準正規化）
- 顯示時小數第二位舍去
摘要差異:
- 件數差 countDiff = 最近件數 − 上次件數
- 件數增減率 countPercent = 上次件數大於0時 countDiff / 上次件數 * 100，否則不顯示
- 分數差 scoreDiff = 最近分數 − 上次分數
- 分數增減率 scorePercent = 上次分數不為0時 scoreDiff / 上次分數 * 100，否則不顯示
分數趨勢:
- 以新->舊的方式獲取用戶的檢查運行（最多20次），並按升序排列
類別別件數趨勢:
- 匯總各版本最新檢查運行的類別別件數（最多10個版本）
頻繁用語前列:
- 將最近200次的檢測按「類別＋一致文本」進行分組
- 指標: totalCount（出現次數）、severityAvg（平均嚴重度 = 總和/件數）、lastFoundAt（最後檢測的日期時間）
- 排序: 降序以出現次數排序，若相同則根據最後一次檢測的時間最新排序
  </details>

開發中的感想

此次真實開發產品的過程中，我深刻體會到，「模糊表達的檢測 -> 修正 -> 圖形化」這一看似簡單的功能，實際上需要考慮的 UI/UX、數據結構及運行流程等問題意外地繁多。

尤其是設計中不僅僅是「單純顯示檢測結果」，還要深入思考「哪些地方模糊」與「如何改善」，這些更加依賴於語言化和編輯的專業知識，而我過去的編輯經驗對此幫助頗大。

此外，對於 Prisma、Firebase Emulator Suite、OpenAI API、shadcn/ui 等不少從未接觸的技術，我也有了新的認識。

從小規模的東西開始著手
功能新增以 MVP 為界限逐步推進
遇到不明白的地方可隨時詢問 AI

這樣的進行方式奏效了，使我能在約1個月內將這些想法具體化。

與 ChatGPT 的差異及差異化要點

僅從「模糊表達的修正」來講，若將文本發給 ChatGPT，至少可以使其變得更為流暢，並學到什麼地方不夠好。

然而，這次開發的產品側重於「用於撰稿人教育」，並非單向的校正，而是「強調發現、學習及成長的過程」。

ChatGPT：語句被發送 -> 變成流暢的文字
└ 但自己的癖好和模糊的理由難以看清，無法進行成長的可視化
本產品：檢測、分類、歷史管理及可視化模糊的部分
└ 可視化撰稿人自我的成長，形成發現與改善的循環

這樣一來，「結果」與「過程」的支持是最大差異。

特別是對於外包撰稿人或內部撰稿團隊，個人成長及編輯者的反饋省力與公司收益直接相關，因此這個差異化帶來了很大的影響。

使用技術

層級	採用技術
前端	React 19 / Vite / TypeScript / Tailwind CSS (shadcn/ui) / Monaco Editor / Recharts
後端	Firebase Functions + Prisma
數據庫	Supabase (PostgreSQL)
CI / CD	GitHub Actions
認證	Firebase Authentication（Email/Password）
AI	OpenAI Responses API。預設為 `gpt-4.1-mini` <br>`OPENAI_REWRITE_MODEL` 可切換至 `gpt-4.1` / `gpt-4o` 等
基礎設施	Firebase Hosting + Functions、Firebase Emulator Suite
品質管理	ESLint / TypeScript / Jest + React Testing Library