laradoc-trans 0.3 是經過大幅修改的版本
主要異動
- 改用 langchain 實作 , 捨棄外部
gemini cli命令 - 翻譯時分割原文翻譯
- 加入 validate 功能，能夠產生報告，驗證程式碼區塊，行內代碼，章節結構完整性。
為什麼要進行大幅修改 ?
最重要的理由是，google 似乎改了輸出 token 限制，變小了，最大 64K ，我就發現似乎翻譯時內容被截斷，而且使用 gemini cli 會被 google 綁死，所以既然要大改，就一次改完善點。
這次改版的過程，特別注重 validate 的功能，該功能會驗證譯文的完整性產生報告，因為 LLM 是不能相信的。
例如: 我寫的提示詞明明有說不能動程式碼內的內容，偏偏偶爾會把註解改成中文，或把字串改成中文，或加了甚麼怪異指令，更慘的是章節對不起來，所以為此我跟 GEMINI 奮鬥好久，因為也是請 GEMINI 來寫的，哈哈。
總體而言，這次的大規模改版，也加入好幾種技術堆疊，如
- langchain : 通用的 LLM 框架
- p-limit: 用於併發同時翻譯不同章節
- cli-progress : 用於顯示併發任務
- remark :用於分割章節，必須要能頗析 markdown 結構
這次的經驗我歸納幾個心得 :
- 每次跟 AI 進行新的會話，AI 一定不理解專案的細節，所以不管有沒有事先準備規格，或者邊寫邊修訂規格，反正最終還是要有規格，這樣每次新會話才不用多作解釋。
- AI 會混亂，最好一次修改一個小功能，就結束會話，然後開始新的會話，不然可能會整天跟 AI 對罵。
- 免費 Token 不夠用，基本上我是用 gemini cli + gemini-2.5-pro 進行 AI 輔助開發的，窮人有窮人的作法，我有幾年前申請的免費
Google workspace，可以開好多帳號來用，只要超過 token , 就切換帳號來用。 - AI 修改檔案時會不經意刪掉原本沒問題的內容，這個最頭痛了，我常常在罵 AI，請他還原，但有一次無法還原，很慘，只能從 git 還原重作，所以若重要功能很複雜，可能 AI 會進行大規模修改導致失敗率很高時，最好每一個階段最好先存成另外一個檔案，光靠 git 恐怕不夠。
目前我自己測試翻譯好的檔案，以及轉換成 epub 都更新了，有興趣的可由以下連結找尋
