TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
日語句子拆解工具 Japanese Sentence Analyzer，逐詞給讀音與釋義
Japanese Sentence Analyzer 是給中文母語者的開源日語句子解析器，貼上句子就拆出分詞、假名、羅馬音、詞性與中文釋義，另有圖片識別與朗讀。實測官方 demo 不用金鑰就能跑，但朗讀預設把句子文字送到維護者的伺服器，自架不設密碼則 API 全開，用之前先把成本與資料流向看清楚。
用 AI 摘要這篇文章：
把「電車の中で、彼は窓の外を眺めていた。」這句再普通不過的日語送進 Japanese Sentence Analyzer 官方 demo 的解析端點，它回給我十六個詞：每個詞標了詞性、假名讀音和羅馬拼音，把十六個詞照順序接回去，與原句一字不差。整個過程不用註冊、不用填 API 金鑰，也沒有收費頁跳出來擋你。
接著我做了一個只差一個參數的對照：同一句、同一個解析端點，只把模型服務商從 DeepSeek 換成 Gemini，伺服器直接回了一個「未提供 API 密鑰」的錯誤。這個錯誤比任何說明文件都誠實：demo 站上跑的是維護者自己的 DeepSeek 金鑰，訪客按下的每次解析都在消耗他的額度；想在這個工具上用 Gemini，就得自己帶鑰匙來。
這是一款做給中文母語者的開源日語句子解析器（GitHub 專案 cokice/japanese-analyzer，MIT 授權，約 790 個星、被 fork 113 次）。它值得停下來看的原因是一個設計決定：分詞與詞性標註不是查辭典查出來的，是丟給大型語言模型當場判斷的。這個決定同時解釋了它的優點（讀音會跟著語境走）、它的風險（正確性沒有辭典保證），以及它不顯眼的成本結構（誰的金鑰在付錢、朗讀的文字送去哪）。
一句日語拆成十六個詞，逐字接回原文
先看成品。下表是那句測試句經官方 demo 的解析端點輸出的完整拆解，模型是 DeepSeek 的 deepseek-v4-flash：
| 詞 | 詞性 | 假名讀音 | 羅馬拼音 |
|---|---|---|---|
| 電車 | 名詞 | でんしゃ | densha |
| の | 助詞 | － | no |
| 中 | 名詞 | なか | naka |
| で | 助詞 | － | de |
| 、 | 記號 | － | － |
| 彼 | 代名詞 | かれ | kare |
| は | 助詞 | － | wa |
| 窓 | 名詞 | まど | mado |
| の | 助詞 | － | no |
| 外 | 名詞 | そと | soto |
| を | 助詞 | － | wo |
| 眺め | 動詞 | ながめ | nagame |
| て | 助詞 | － | te |
| い | 動詞 | － | i |
| た | 助動詞 | － | ta |
| 。 | 記號 | － | － |
幾個值得停下來看的細節。它用的是日本學校文法（學校文法／教育文法），也就是日本中學國語課教的那套品詞分類，詞性標籤是一組封閉集合（標籤是日文品詞名稱，以繁體對應字呈現）：名詞、代名詞、動詞、形容詞、形容動詞、副詞、連體詞、接續詞、感動詞、助詞、助動詞，外加記號與換行，共十三個。「眺めていた」被拆成「眺め＋て＋い＋た」四段，補助動詞與助動詞各自獨立，正是這套體系教科書等級的拆法。讀音面也吃得下語境：「電車の中」的「中」讀なか、不讀ちゅう；助詞「は」的羅馬拼音給 wa、不給字面上的 ha，照實際發音走。
圍繞這份拆解，網頁版把每個詞依詞性上色，點任何一個詞會再叫出單字詳解（讀音、中文釋義、字典形、語法角色與上下文解釋），另外有整句中文翻譯、圖片識別（上傳截圖抽出日文再解析）、朗讀，以及一個能針對當前句子發問的 AI 日語助手，官方文件還附了行動版助手介面的截圖。單字詳解是另一次獨立的模型呼叫，輸入的是那個詞加上整句語境，所以釋義會照句子裡的意思給，字典形與語法角色也一併列出；AI 助手則把當前解析的句子帶進對話，可以接著問「為什麼這裡用て形」或「這個助詞拿掉會怎樣」這類問題，把查一個詞延伸成問一個句。
這份單句成品能支持的是：拆解在學校文法的切分上可用、讀音判讀經得起核對。它不能延伸到長文的穩定度、圖片識別的品質，或與其他日語工具的系統比較。
拿掉一條規則，標點的詞性就變了
這個工具的解析 prompt 就寫在公開原始碼裡，一段純文字。把它原封不動放進對 demo 端點的請求，得到的就是上表那份輸出。然後我做了一個對照：同一句、同一個模型，只把「詞性只能從封閉集合裡選」這一條規則拿掉。結果頓號的詞性從「記號」變成「讀點」，句號從「記號」變成「句點」。
兩個新標籤都不在介面的詞性分組表裡，照原始碼的顏色對照會落進「其他」（灰色）那組，也不在圖例上。這個結果比任何功能介紹都值得記住，因為它直接點出這類工具的本質：詞性標籤是模型當場畫出來的，每一條規則都在防它亂畫。官方 prompt 用一整套約束把模型圈住，封閉標籤集只是其中一條，另外還有逐字重組條款（所有詞依序接起來必須與原文逐字相同，不得省略、改寫或增補）、補助動詞的拆分規則、標點的固定輸出格式。你在畫面上看到的整齊，是約束約出來的。
把分詞交給語言模型，換到的是語境敏感：同形異音詞靠整句判讀，固定詞典在這類案例上容易給最高頻讀音，這個傾向來自單句觀察，屬合理推論而非保證。但辭典等級的兜底也跟著沒了：模型出錯的方式，詞典不會；同一句在不同約束下標籤會漂，已經親眼看到了。把輸出拿去當唯一依據之前，值得抽查兩三個詞。
從漂移的標籤回看它怎麼運作
順著這個設計看原始碼，整個工具的骨架比想像中簡單：每個功能都是一次獨立的模型呼叫。解析要的是一份嚴格 JSON；單字詳解、整句翻譯、AI 助手對話各自再發一次請求；圖片識別在 DeepSeek 路線走一個獨立的視覺模型（deepseek-v4-flash-vision-exp，僅用於辨識圖片、固定關閉思考），Gemini 路線則直接用所選模型看圖。貼上長文時會先切段、最多三段併發送出，減少等待。
模型有兩家可選。預設是 DeepSeek（deepseek-v4-flash，可切 v4-pro），請求固定關閉思考模式；設定介面裡雖然留著思考模式的開關，原始碼在每次載入設定時都會把開啟值強制改回關閉，等於實際停用，重新整理後永遠是關的。切到 Gemini 則有 gemini-3.7-flash（低推理檔）與 gemini-3.5-flash-lite（最低檔）兩個選項。如果你先前看過把它寫成「基於 Gemini 2.5 Flash」的介紹，那已經是上一個版本的事：專案 2025 年 5 月建立，2026 年 6 月起密集改版，7 月 28 日的 v0.2.3 把預設服務商切到 DeepSeek 並強化了認證，最近一次提交落在 8 月 21 日，維護是活的。
順帶一個看原始碼才會注意到的細節：儲存庫掛在 cokice 名下，但 demo 網域、文件站、Docker 映像檔與朗讀端點都掛在 howen 這個名字底下（howen.ink 網域、howenhowen 的映像檔），開發分支也叫 howendev，README 的致謝則指向 LINUX DO 社群。兩個名字並存、東西是同一套，這對下載與部署沒有影響，只是追問題或回報時要知道去哪個入口。
認證強化指的是自架端的密碼閘，這點放在下面一起算帳。先講另一件事：這些模型呼叫的金鑰從哪裡來。這是理解「免費 demo」的關鍵，也是自架前最該看清楚的地方。
誰在付錢、文字去了哪
demo 白用的真相前面已經看到：站方設了一組 DeepSeek 金鑰在伺服器端，訪客不填任何東西就能解析，額度算維護者的；那組金鑰只涵蓋 DeepSeek，所以切 Gemini 會直接吃到「未提供 API 密鑰」。想在瀏覽器裡自帶金鑰也可以，設定彈窗分開讓你填 DeepSeek 與 Gemini 兩把，存在瀏覽器的 localStorage。資料路徑是另一回事：自帶的金鑰與句子都是先送到「跑這個網站的那台伺服器」，再由它轉發給模型供應商，這與「瀏覽器直連供應商、金鑰不出本機」的設計是兩回事。同樣在意這條邊界的話，AiNiee 把譯文送雲端或留本機做成明確選項，是同一族問題的另一種答案。
朗讀是資料流向最特別的一條。預設的 Edge TTS 在前端程式碼裡把端點寫死在 api.howen.ink，也就是維護者自己的伺服器：瀏覽器會把你正在朗讀的句子文字直接 POST 過去，換回一段音檔，我實測那個端點收文字就回 mp3。這條路與你用誰的部署無關，自己架一份也一樣送去，沒有任何設定可以改。要避開只有兩個辦法：不按朗讀，或切到需要金鑰的 Gemini TTS（那條走你自己的部署端）。平常就想用 Edge TTS 這類語音的，可以參考Text2Voice 整理的 Edge TTS 網頁入口與方案對比。
自架端還有一個容易漏掉的開口：環境變數 CODE 設了密碼，所有 API 才有登入閘（簽過章的 cookie，七天效期）；不設的話，解析、翻譯、朗讀這些端點對外完全開放，任何知道你網址的人都能用你機器上的金鑰跑句子。還有兩個小點：目前版本已經不讓使用者在瀏覽器裡自訂 API 端點，伺服器遇到這個參數會直接報錯，設定遷移還會主動清掉舊的端點儲存，要換上游只能自架改環境變數；統計方面內建了 Umami，但那是自架者自己決定開不開的（兩個環境變數都要設才載入），事件內容照原始碼只有供應商與模型代號之類的中繼資料，不含句子文字。
| 操作 | 文字去向 | 誰的金鑰 |
|---|---|---|
| 解析、翻譯、單字詳解 | 瀏覽器 → 部署端伺服器 → DeepSeek 或 Google | 站方或自帶 |
| 圖片識別 | 瀏覽器 → 部署端伺服器 → 視覺模型 | 站方或自帶 |
| 朗讀（預設 Edge TTS） | 瀏覽器 → 維護者的 api.howen.ink | 無需金鑰 |
| 朗讀（Gemini TTS） | 瀏覽器 → 部署端伺服器 → Google | 站方或自帶（官方 demo 僅能自帶） |
| 使用統計（若自架者啟用） | 瀏覽器 → 自架者設定的 Umami | － |
想自己跑一份
最快的方式是官方 demo，README 目前的連結是 nihongodemo.howen.ink，無密碼、開站即用，介面是簡體中文，讀起來通順、用語需要習慣一下。網路上流傳的另一個 vercel.app 舊網址也還活著，實測同樣回 deepseek-v4-flash 的拆解，官方文件現在只連 howen.ink 這個。要自己架，專案給了三條路：Node 開發環境（npm install 後 npm run dev）、Vercel（README 附了一鍵匯入連結，或在專案設定裡手動加環境變數）、Docker（howenhowen/japanese-analyzer 映像檔，amd64 與 arm64 都有，容器聽 3002 埠，倉庫附了 compose 檔與環境變數範本）。必填的只有 DeepSeek 金鑰；GEMINI_API_KEY 給需要 Gemini 文字、圖片識別或 Gemini TTS 的人；CODE 這個密碼變數，凡是放在公開網址上就強烈建議設。授權是 MIT，整套是 TypeScript 寫的 Next.js 專案，想改 prompt 或加功能都可以直接動。
它沒保證的事，與我的判斷
這些結論有邊界：單句的拆解背書不了圖片識別的品質，也背書不了長文的穩定度；兩家模型誰拆得準、跟 MeCab 這類辭典式分詞器比起來如何，沒有同一批句子的基準就沒有答案，看到任何「比誰準」的說法都先存疑。能確定的是模型輸出本質上會漂，約束拿掉就漂給你看過了，把它當閱讀輔助可以，當最終依據要自己抽查。
判斷是這樣的。如果你是中文母語、正在讀日文歌詞、台詞或教材，想快速知道某個詞怎麼讀、什麼意思、為什麼是這個形，它的拆解與釋義流程是順的，demo 直接用也沒有門檻。想組一條自己的複習線，可以搭配MuJing 把電影字幕變成有前後文的單字庫，朗讀功能可以搭配echo-flow 那種句子級跟讀練習。反過來說，如果句子內容敏感，商業文件或私人訊息這類，記得解析與翻譯會經過部署端與模型供應商、朗讀更會直接出站到維護者的伺服器，這種情境要嘛自架加上密碼、要嘛改用本機詞典式方案。
成功的樣貌很具體：貼一句、拿到拆解，抽查的兩三個詞性與讀音對字典是對得上的。如果讀音頻繁出錯、拆分在助動詞上反覆混亂，那就別跟它耗，把句子直接丟給通用 AI 助手逐詞問，或回到辭典式工具。它把分詞交給模型判斷，用好這個前提，它就是個順手的閱讀放大鏡。
