舊稿能編譯，修改稿也能編譯；可是 latexdiff 產生的檔案，卻在表格、公式、自訂命令或很長的前言區裡失敗。
這通常不代表修改內容壞了。紅線稿本身就是第三個 LaTeX 程式，帶著自動插入的命令與自己的失敗方式。應該像建置另外兩份稿件一樣，明確地建置它。
Table of Contents
先固定兩份能獨立建置的版本
準備兩個完整快照，而不是從不同時間隨手複製兩份 main.tex：
revision-package/
├── old/
│ ├── main.tex
│ ├── sections/
│ ├── figures/
│ └── references.bib
└── new/
├── main.tex
├── sections/
├── figures/
└── references.bib記下編譯引擎與命令，再分別建置：
cd old
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
cd ../new
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex只要其中一份不能獨立編譯，就先不要做 diff。否則出了錯，很難分辨問題原本就在稿件裡、來自環境，還是由紅線標記引入。
同時把實際工具版本留下來：
pdflatex --version
latexmk -v
latexdiff --version「在 Overleaf 可以跑」是有用的線索，卻不是版本號。套件順序與間接載入的套件，都可能讓看似相同的原始碼產生不同結果。
多檔案稿件先展開再比較
單一檔案的稿件可以直接比較：
latexdiff old/main.tex new/main.tex > new/redline.tex實際論文通常還有 input、include、subfile、圖片和書目。latexdiff 手冊所記載的 --flatten，會遞迴展開正文中包含的檔案：
latexdiff --flatten old/main.tex new/main.tex > new/redline.tex
cd new
latexmk -pdf -interaction=nonstopmode -halt-on-error redline.tex紅線稿確認完成之前，保留完整的 old/ 與 new/。展開後的檔案方便比較，卻不再反映原本的目錄結構；它應該是可重現的產物，而不是新的主要稿件。
如果論文已經使用 Git，也可以用 latexdiff-vc 比較指定修訂。原則不變：固定兩個版本，保存產生 PDF 的完整命令。
先產生，再編譯
Overleaf 的 latexdiff 指南介紹了 latexmkrc 與 ShellEscape 兩條路徑。小範例很方便；遇到複雜投稿，我更偏好先明確產生 redline.tex，再單獨編譯。
這樣會留下兩個清楚的問題：
latexdiff是否成功產生合理的 TeX？- 產生的 TeX 是否能在修改稿所用的同一環境裡編譯？
也能避免一般稿件建置時，因輸入檔已改變而悄悄重做出另一份紅線稿。
若必須在 Overleaf 內產生，保持官方 latexmkrc 或 shellesc 設定簡短，確認哪一份檔案是主文件，並下載編輯要求所依據的新舊快照。Overleaf 的歷史功能可以下載指定版本；它比「上星期那份檔案」可靠得多。
看第一個真正的錯誤，不要看最後五十個
紅線命令很容易引發連鎖錯誤。真正有用的通常是 redline.tex 開始編譯後的第一個錯誤。
逐項確認：
- 失敗命令存在於舊稿、新稿，還是只存在於紅線稿？
- 它位於數學環境、移動參數、表格儲存格、圖說或引文嗎？
DIFadd或DIFdel是否跨過了命令邊界？- 修改稿成功的同一環境，是否也能重現這個錯誤？
不要一開始就從修改稿刪套件。這可能讓紅線稿通過，卻也改變了編輯真正需要審閱的論文。
如果自訂命令只是包住文字，可以告訴 latexdiff 應如何處理。手冊提供 --append-safecmd、--exclude-textcmd 等命令清單。把設定保存在檔案或建置腳本裡，讓修補可以重做。不要把所有陌生命令一律列為安全；會改變計數器、寫檔或需要脆弱參數的命令仍應個別檢查。
公式與表格則一次縮小一個失敗區域。每次調整後重新產生、重新編譯，再把那一頁與兩份乾淨 PDF 對照。能編譯卻藏掉負號、列、圖說或引用變更的紅線稿，仍然沒有完成。
把編輯用紅線稿與日常修改紀錄分開
Overleaf 原生的追蹤修訂適合共同編輯。期刊紅線稿回答的是另一個問題：兩個已接受的稿件狀態之間，究竟改了什麼？
因此應保存三份成品：
- 基線 PDF；
- 乾淨的修改稿 PDF；
- 由對應原始碼產生的紅線 PDF。
再加一份短清單，記錄原始碼雜湊、引擎、命令、日期與尚未解決的警告。若回覆信寫著「修改於第三節」，最後位置應從目前的乾淨 PDF 確認。紅線稿用來看改動，不應是頁碼與章節位置的唯一依據。
一次小型稽核，可以省掉很長的修復
我用公開的 PaperAgentDemo 做了這項檢查。目前的 main.tex 可以由 latexmk 可重現地建置成兩頁 A4 PDF；最後一輪已解析公式、演算法與表格引用。但此儲存庫沒有另一份明確的稿件基線，受檢工具鏈也沒有 latexdiff。因此它能證明乾淨建置，還不能證明紅線流程。
這條界線很重要。在承諾能交付期刊紅線稿之前，先證明三次建置都成立，保留基線，並把每項人工例外寫入腳本或稽核紀錄。
公開的合成紅線範例把舊版原始碼、修改稿、三份 PDF、產生的 redline.tex、乾淨的最後一輪紀錄與雜湊清單放在一起。它刻意只有一頁：足以重現三次建置，但不拿來代表複雜的客戶稿件。
我維護了一套公開的計畫先行論文修訂流程，把穩定的稿件檔名、具名基線、產生式紅線稿、以 PDF 核對的回覆位置，以及未解決問題放在同一條流程裡。即使不直接使用這套工具，守住這五條界線，也會讓困難的 latexdiff 修復清楚許多。
如果你想請另一雙眼睛檢查一篇範圍明確的論文，我也提供 USD 250 的論文建置與紅線稿 sprint。免費 fit check 只問原始碼結構、目標模板與期限；在雙方確認範圍和處理方式之前，不必傳送稿件。