編譯 TeX 的提示模型

詢問 LaTeX 的聊天模型，您通常會得到看起來正確但無法在文件中編譯的程式碼。該模型不知道您使用哪個類別、載入哪些套件或定義了哪些宏，因此它會回答一些不屬於您的通用文件。然後，在貼上時，輸出會因缺少套件或定義衝突而消失。透過三個提示習慣和一個硬性規則，大多數情況都可以避免：在信任之前進行編譯。

發送序言

你的序言是模型所缺乏的脈絡。貼上它，或至少貼上“\documentclass”行和“\usepackage”列表，並要求“在此序言下編譯的片段”。這個習慣阻止了最常見的失敗：答案默默地取決於「tikz」、「siunitx」或您從未加載過的其他套件。它還將模型引導至您的設定實際提供的命令。如果您的專案定義了宏，也請包含這些宏，原因請參閱為模型提供符號表。

##詢問答案取決於什麼

添加長期請求：「如果您的程式碼需要我尚未加載的任何包，請在您的答案頂部明確列出它。」這將隱藏的依賴關係變成了可見的清單。當回應命名一個套件時，您決定是否要新增它，而不是在三個編譯後發現依賴項為「未定義的控制序列」錯誤。此錯誤及其診斷包含在未定義的控制序列 中。

要求比較，而不是重寫

當您想要變更現有文字時，請貼上最小的相關片段，並要求模型僅變更要求所需的內容，並說明變更的內容。給定一個完整的文件，模型可以自由重寫：它們重新格式化未觸及的段落，重新排序序言行，有時會把一些東西掉到地板上。真正的改變在流失中消失了。最小化的描述性編輯是您可以實際查看的編輯。在 Oleafly 內部，助手透過將每位編輯建議為您逐行批准的紅/綠差異來為您強制執行此形狀，如 Oleafly 內部助手 中所述。

在信任之前編譯

永遠不要發布你還沒有編譯過的 LaTeX，無論它看起來多麼合理。將建議貼到文件中，編譯並讀取第一個錯誤（如果有）。將該錯誤訊息連同有問題的程式碼片段一起回饋給模型，通常會產生第二次嘗試。將專案保留在 Git 下，以便可以透過一個指令回滾任何模型輔助的更改，將論文放在 GitHub 上 中介紹了這一設定。模型提出；​​編譯器處置。