AI 的第一批无聊工程，从 TikZ 开始

凌晨两点，论文截稿前最后六小时。你盯着第三张插图——神经网络架构图——第无数次微调 \draw 的坐标。从 (4.5,3.2) 改成 (4.6,3.1)，编译，看 PDF，不对，改回来，再编译。你想起导师说「图要画得好看，reviewer 才愿意仔细读」，于是你继续调，指针指向三点。

每个写过 LaTeX 论文的人都经历过这个场景。TikZ 是 LaTeX 生态中绘制学术图形的事实标准，但它是一种「图形语言」而非「图形工具」——作者 Till Tantau 甚至在文档里特意说明：TikZ ist kein Zeichenprogramm（TikZ 不是画图程序）。你用代码画图，每次微调坐标都要重新编译整个文档。学术界几十年来就这么扛着。

2026年6月，一个叫 Dominik Peters 的开发者在 HN 上发布了一个项目：TikZ Editor——一个所见即所得的 TikZ 图形编辑器，你可以像用 Figma 一样拖拽节点，源码同步更新。293分，58条评论。真正让这个项目值得讨论的是它是怎么被造出来的。

「人类不会想做的事」

Dominik Peters 在 Show HN 的帖子中有一句话相当于直接给出了这个项目的核心论点：

This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.

这句话翻译成更直白的表述：为了做一个拖拽式 TikZ 编辑器，你需要重新实现 TikZ 的大部分底层机制——解析器、渲染器、布局系统、颜色处理。这是一项 ROI 低到荒谬的工程任务，正常人不会接。

但 Codex 接了。整个项目，包括前端界面、Tauri 桌面应用、TikZ 语法解析器、基于 JavaScript 的 SVG 渲染管线、多种格式转换器（SVG/PPTX/IPE → TikZ）、以及那几个堪称疯狂的「支线任务」，几乎全部由 Codex 生成。Dominik 从 2026 年 2 月开始推进这个项目，消耗了约 7 亿 token，按 API 价格折算约 1.5 万美元——他实际只付了约 500 美元的 ChatGPT 订阅费。

逻辑链很清晰：当开发成本趋近于零时，原本「不值得做」的项目突然变得值得做了。 这个命题本身并不新鲜。但 TikZ Editor 提供了一个精确度足够的案例，让笔者可以拆开来看 AI 编码工具到底接管了什么样的工程劳动——以及它到底没有接管什么。

两类被外包的工程工作

TikZ Editor 的实现涉及的工作可以分成两个类别，笔者在这里做一个区分。

第一类：机械性的格式转换。 这包括 SVG 到 TikZ、PPTX 到 TikZ、IPE 到 TikZ 等转换器。这些转换器的逻辑复杂度不低——SVG 的路径命令映射到 TikZ 的 \draw 语法、PowerPoint 的形状模型翻译为 TikZ 的节点和路径——但本质上是映射规则和边界条件的工程。规则可以穷举，边界可以用例覆盖。你可以想象一个有经验的工程师花三周时间做完，并且做完之后不会觉得自己获得了什么深刻的洞察。这类工作，AI 编码工具处理起来相对可靠，因为验证是二元的：转换后的 TikZ 编译通过了吗？渲染结果和原始格式一致吗？

第二类：在陌生领域重新实现经典算法。 这是更有趣的类别。Dominik 在帖子中提到几个「支线任务」，其中两个值得展开：

1. 重新实现 LaTeX 的断行算法（Knuth-Plass）。为了支持多行文本节点，TikZ Editor 需要在浏览器端（JavaScript 环境）实现正确的换行和断词。这意味着要复现 Donald Knuth 和 Michael Plass 在 1981 年发表的动态规划断行算法——这个算法以全局优化段落的「不良度」为目标，不是简单的 greedy 行填充。浏览器端的 CSS text-align: justify 只做单个行的贪心断行，效果粗糙；TeX 的算法计算全局最优，需要处理词间胶水（glue）的拉伸和收缩、连字符惩罚、以及整段的美学评分函数。

2. 实现 red!20!black 颜色混合系统。在 LaTeX 论文中，颜色经常以 {颜色1}!{比例}!{颜色2} 的语法混合，比如 red!20!black 表示 20% 红色混 80% 黑色。在浏览器端实现一个拾色器支持这种语法，意味着要从 xcolor 包中逆向出精确的混合模型，处理 RGB/CMYK 的转换、透明度计算，以及 ! 操作符的嵌套（比如 red!20!blue!50!green）。

笔者把这两项归为同一类，是因为它们共享一个性质：你不做，功能就不完整；你做了，核心能力并不会因此变得更清晰。 这是典型的「无聊工程」——不是不重要，是 ROI 太低。人类工程师看到这种任务的第一反应是「有没有现成的库能绕过去」。如果没有，这个功能常常就被标记为 WONTFIX。

而 AI 编码工具在这种场景下的表现颇为耐人寻味。Dominik 在 HN 评论中分享了具体的工作流程：他先用 LaTeX 引擎（dvisvgm）和 JavaScript 渲染器分别处理同一批 TikZ 图，然后人工比对差异，把不对的地方告诉 Codex，让它回去修。他试过让多模态模型自动比对，效果不好——模型「仍然有点瞎，即便是两幅明显不同的图也认为它们一样」。

这里有一个微妙的细节：人类在 loop 中的作用是做判断。 判断哪个渲染差异是 bug、哪个是字体渲染的正常偏差、哪个可以接受。人类没有消失，只是从实现者变成了质量裁判。

Armin Ronacher 的后半句

TikZ Editor 发表前一天，Flask 和 Jinja2 的作者 Armin Ronacher 在他的博客「The Coming Loop」中写了一段与此事形成精确对话的判断：

I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

然后他话锋一转：

On the other hand using that same looping methodology to write lasting code does not yet sit well with me.

Ronacher 的核心忧虑在于：当 harness loop 持续运转、每次迭代追加一个局部防御、代码在不见人的情况下自我生长时，最终产物会变成一个需要它自己来维护的有机体。 他管这叫「软件从确定性机器变成了有机体」——你监测它、稳定它，但不理解它。

但他的另一句话可能更关键：

Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.

Ronacher 认为 loop 在两种场景下已经 work 得很好：代码变换（code transformation，包括 porting、benchmark、安全扫描）和不需要长寿的代码（proof-of-concept、实验探索）。

这里出现了一个有趣的对应关系，笔者试着把它画出来：

类别	代表任务	AI 是否擅长	原因
机械变换	移植代码、格式转换	擅长	映射可穷举、验证二值化
无聊工程	Knuth-Plass 重实现、颜色混合	擅长	逻辑确定、接口明确、ROI 使人类不愿投入
架构决策	项目结构、抽象层次	不确定	涉及价值观权衡
设计决策	画什么图、如何排版	不能替代	需要意图和审美判断

TikZ Editor 恰好横跨了前两行。格式转换在第一行，算法重实现在第二行。而项目的架构——Dominik 说他「先用一个最简单的解析器→SVG渲染器+基础拖拽来验证架构可行性」——这个决策是他自己做的。Codex 只在 plan mode 中以选择题的方式征求他的意见。

画出什么图，是用户的决策。 编辑器提供的是工具，不是审美。

« loop 需要清晰 »——这句判断接在 TikZ Editor 上正好

Ronacher 在文章末尾写了一句让笔者来回读了三遍的话：

Adopting the idea of harness loops means that the harness decides when work is finished.

在 TikZ Editor 的开发中，「什么时候算修好了」始终是 Dominik 在判断。他把两个渲染器的输出放在一起，盯着差异，告诉 Codex 哪里还不对。loop 的停止条件由一个知道正确输出长什么样的人来定义。 这就是 Ronacher 所说的「loop 的前提是清晰」——你得先经历足够多的破烂版本，才知道你要什么东西是对的。Agent 可以帮你缩短试错过程中的无聊部分，但它不能替你定义「对」是什么。

这个逻辑同样适用在 TikZ Editor 的用户端。一个学术工作者打开编辑器，他要画一个量子态的 Bloch 球表示，或者一个 Transformer 的自注意力机制图——这些图长什么样，是他脑子里先有的意图。 Agent 不能替你决定这篇论文的核心图示应该怎么布局、哪个流向是需要强调的、颜色该用绿的还是灰的。它只能让你在有了想法之后，不用手写 \draw[->] (-0.866,-0.5) -- (0.866,0.5) 这样的坐标。

换句话说：无聊工程可以外包给机器，意义判断必须留在人手里。 这是当前 AI 编码工具的能力边界在 TikZ Editor 这个具体案例上的精确投射。

乐观的部分，和不确定的部分

笔者不想把这篇分析写成一种廉价的中庸——「AI 有好的一面也有不好的一面」。TikZ Editor 是实打实的好东西。它把学术界几十年来一个长期无解的问题用代码填上了，填的方式是开放源码（MIT 协议）、支持多平台（Web + Linux/Windows/macOS 桌面端）、甚至可以打开整篇论文 .tex 文件直接编辑其中的 TikZ 图形。Hacker News 上最高赞的评论之一是一个德国研究生写的：「所有 STEM 学生和研究者都感谢你。」

不确定的部分在于：这种范式能走多远。

Dominik 消耗了 7 亿 token 做了这个项目。Ronacher 担心模型产出的代码质量在退步——防御性过强、局部推理、回避不变量。但在 TikZ Editor 这个案例上，一个 Github 上的观察者评价「代码结构看起来很不错」。这之间的落差在哪？

笔者的一个猜测是：任务边界的清晰程度决定了产出质量。 Knuth-Plass 算法的输入是文本和行宽，输出是断行位置——正确性可以在渲染结果中直观验证。颜色混合的输入是两个颜色和比例，输出是一个颜色——对错一眼能看出来。TikZ 解析器的输入是文本，输出是 AST——只要渲染不崩、坐标对得上，就是对的。

当验证标准可以视觉化时，loop 更可靠。当验证标准需要经验判断时，loop 需要人。

这不是一个要「信」或「不信」AI 的命题。它是一个工程命题：哪种任务可以自动验证？ 如果答案是「可以自动验证」，Agent 就适合接手。如果答案是「需要人工判断」，Agent 的价值就是加速循环的每一轮，但不替你画句号。

从「无聊工程」到「值得做的工程」

回到 Dominik 说的那句话——「这是人类不会想做的任务」。这句话最有意思的潜台词是：不是因为做不了，是因为不想做。

TeX 的断行算法从 1981 年就有了，公开文献中算法描述是完整的，JavaScript 实现也不止一个。red!20!black 的颜色混合模型在 xcolor 的源码里写得清清楚楚。问题不是「没人能实现」，问题是「没人愿意花四周时间去做这些而对最终产品的核心价值贡献只有 2%」。

AI 编码工具正在改变这个计算。当 2% 的边际价值所需的时间成本从四周降到四小时，甚至四分钟，它就从「不值得」变成了「顺手做了」。这并不意味着人类在软件开发中的角色消失了——它意味着人类可以更专注于决定做什么，而把怎么做中的无聊部分交给机器。

Ronacher 的最后一句话某种意义上说的是同一件事的负面：当「做什么」也被交给机器时，我们可能失去了理解系统的能力。 这两句话放在一起，比单独任何一句都更接近真相。

TikZ Editor 的 Github 页面还在更新。Dominik 说下一步可能引入 pgfplots 支持。笔者不会说「AI 编码正在重塑软件开发」——这种表述太笼统。但可以说的是：当一个人类不愿意重写的 TeX 换行算法，被 Agent 在几次对话中实现并能在浏览器端正确渲染多行节点时，某个阈值已经被跨过了。 接下来值得关注的不再是「AI 能编码吗」，而是「哪些工程决策人类不该外包，哪些无所谓」。

这个区分本身，可能是未来几年软件工程中最需要认真思考的问题。