Codex 的 latex 插件自带了一个编译器,但克制才是它真正的设计

Codex插件系列（八）

Codex 的 latex 插件自带了一个编译器，但克制才是它真正的设计

约 1788 字·阅读 5 分钟

打开 latex 插件的 bin 目录，里面躺着一个 tectonic.exe——一个现代化的 LaTeX 引擎，单一可执行文件，自动下载缺失的包。

插件自带编译器。这在我拆的 7 个插件里还是头一份。

但读完整个插件后我意识到，自带 tectonic.exe 只是表层。这个插件真正值得说的是它的克制哲学——在用户机器上跑工具时，怎么做到干净、不污染、不越界。

· · ·

渐进式工具链：轻的先上

compile_latex.py 的默认 auto 模式有一套清晰的决策逻辑。先正则扫描 .tex 源码，看项目用了什么包和命令。如果用了 biblatex、minted、glossaries 这些包，或者出现 \bibliography、\write18、\makeindex 等命令——判定为"复杂"项目，跳过 Tectonic 直接走 TeX Live。简单项目就先试 Tectonic，自带的，免安装，快。Tectonic 失败了再退到系统已有的 TeX Live 或 MacTeX。

这种"先看代码再选工具"的启发式非常聪明。避免了"先试 Tectonic、失败、再换 TeX Live"的浪费。当一个任务有多种工具能完成但各有适用场景时，先做一次轻量的特征扫描决定走哪条路，比无脑试错高效得多。

Tectonic 能覆盖 90% 的简单文档，用户什么都不用装就能用。复杂场景再走更重的方案。把能解决常见场景的工具直接打包进插件里，让默认场景零配置可用。

· · ·

latex-doctor：不只查命令在不在，要真跑一遍

编译之前或编译失败时，调 latex_doctor.py 给本机 LaTeX 环境做个体检。它返回四种状态——ready（至少一个 runtime 通过了冒烟编译）、existing-usable（检测到可用的现有 TeX，不要装托管版）、existing-partial（现有 TeX 但有缺件，不要自作主张装）、missing（啥都没有，可以提议装）。

关键是"冒烟编译"这个设计。latex_doctor.py 头部有一段最小可工作的 .tex：

python

SMOKE_TEX = r"""\documentclass{article}\usepackage{amsmath}\begin{document}Codex LaTeX smoke test. $E = mc^2$.\end{document}"""

它不是只检查"二进制存在不存在"，而是真的用这段 .tex 跑一遍编译。光有 pdflatex 这个命令不代表它能完整跑通——也许缺某个关键包，也许版本不兼容。检测工具可用性时，不要只检查命令存在，要做一次真实的冒烟测试，这是判断"真的能用"的唯一可靠方法。

· · ·

最克制的安装器

texlive-runtime-installer 是整个插件设计上最讲究的部分。

默认行为是"只检测，不安装"。即使加了 --install-managed-full 参数，也要用户明确确认后才装。安装位置放在 ~/.cache/codex-runtimes/codex-texlive/full——用户 cache 目录下，完全隔离于系统 TeX。

README 和 skill 里反复强调四个"不"：

The installer does not use sudo, does not write /Library/TeX, does not write /usr/local/texlive, and does not edit the user's shell startup files.

不用 sudo，不写 macOS MacTeX 标准位置，不写 Linux TeX Live 标准位置，不改 shell 启动文件。它绝不碰系统级别的任何东西。用户卸载这个插件等于删一个 cache 目录就干净了。

“在用户机器上安装运行时，遵守"最大隔离"原则——独立目录、不污染系统路径、不改 shell 配置、PATH 只在执行时临时生效。这是赢得用户信任的关键。

PATH 也不全局修改。编译命令执行的那一瞬间临时把 bin 目录 prepend 到 PATH 前面，执行完就恢复。不会影响用户终端里其他命令的行为。

· · ·

尊重社区约定

compile_latex.py 里有这么一段正则：

python

ROOT_DIRECTIVE_RE = re.compile(r"^%\s*!TEX\s+root\s*=\s*(?P<root>.+?)\s*$")

这是 TeX 社区的标准约定。在很多编辑器（TeXShop、VSCode LaTeX Workshop）里，子文件顶部会写一行注释指向主文件：% !TEX root = ../main.tex。编译时先读这个指令，自动找到真正的 root 文件，而不是死板地编译用户点的那一个。

_尊重领域约定_，而不是让用户适应 AI 的逻辑。类似的，它也支持 % !TEX program = xelatex 这种指定引擎的指令。这些细节体现了对用户工作流的理解——用户用了十几年的约定，AI 也得认。

· · ·

三个 skill 的协作链

插件目录下有三个 skill，各管一件事。latex-compile 负责编译，latex-doctor 负责体检，texlive-runtime-installer 负责安装。三者形成一个诊断 → 编译 → 兜底的协作链。

compile 找到工具就直接编译。没工具就引导到 doctor。doctor 体检后如果 ready 就回去编译，partial 就报告缺件，missing 就引导到 installer。installer 要用户确认后才装。

把诊断、执行、安装分成独立的 skill，但明确写出它们的衔接规则——"失败时路由到哪个 skill"，让 AI 知道怎么串起来。_单一职责_，能力互补靠组合。

· · ·

克制才是这个插件的核心

latex 插件没有发明什么新技术。它做的事情是——自带一个轻量编译器覆盖常见场景，系统已有的工具优先复用，实在没有才在用户明确同意后装一个完全隔离的版本。

默认不安装，不 sudo，不写系统路径，不改 shell，PATH 临时生效。每一处"不做"都是深思熟虑。

“在 AI 能力爆炸的时代，克制的 AI 产品反而更可信。

如果你在做需要在用户机器上跑外部工具的 AI 应用，这个插件的克制哲学是黄金参考。

你的 AI 应用在用户机器上跑工具时，怎么处理隔离和权限的？ 评论区聊聊。顺手转发给也在搞本地工具集成的朋友。

· · ·

「拆解 Codex 7 大插件」系列 · 第 8 篇 · 共 9 篇下一篇：拆完 Codex 7 个插件回头看，OpenAI 的工程哲学就三句话。

感谢关注