编译 TeX 的提示模型

询问 LaTeX 的聊天模型，您通常会得到看起来正确但无法在文档中编译的代码。该模型不知道您使用哪个类、加载哪些包或定义了哪些宏，因此它会回答一些不属于您的通用文档。然后，在粘贴时，输出会因缺少包或定义冲突而消失。通过三个提示习惯和一个硬性规则，大多数情况都可以避免：在信任之前进行编译。

发送序言

你的序言是模型所缺乏的上下文。粘贴它，或者至少粘贴“\documentclass”行和“\usepackage”列表，并要求“在此序言下编译的片段”。这一习惯阻止了最常见的失败：答案默默地取决于“tikz”、“siunitx”或您从未加载过的其他包。它还将模型引导至您的设置实际提供的命令。如果您的项目定义了宏，也请包含这些宏，原因请参阅为模型提供符号表。

##询问答案取决于什么

添加一个长期请求：“如果您的代码需要我尚未加载的任何包，请在您的答案顶部明确列出它。”这将隐藏的依赖关系变成了可见的清单。当回复命名一个包时，您决定是否添加它，而不是在三个编译后发现依赖项为“未定义的控制序列”错误。该错误及其诊断包含在未定义的控制序列 中。

要求比较，而不是重写

当您想要更改现有文本时，请粘贴最小的相关片段，并要求模型仅更改请求所需的内容，并说明更改的内容。给定一个完整的文件，模型可以自由重写：它们重新格式化未触及的段落，重新排序序言行，有时还会把一些东西掉到地板上。真正的变化在流失中消失了。最小化的描述性编辑是您可以实际查看的编辑。在 Oleafly 内部，助手通过将每个编辑建议为您逐行批准的红/绿差异来为您强制执行此形状，如 Oleafly 内部助手 中所述。

在信任之前编译

永远不要发布你还没有编译过的 LaTeX，无论它看起来多么合理。将建议粘贴到文档中，编译并读取第一个错误（如果有）。将该错误消息连同有问题的代码片段一起反馈给模型，通常会产生第二次尝试。将项目保留在 Git 下，以便可以通过一个命令回滚任何模型辅助的更改，将论文放在 GitHub 上 中介绍了这一设置。该模型提出；编译器处置。