Manim制作尺规作图正65537边形动画的数学与实现原理

看到有人用 Manim 去表现“尺规作图正 65537 边形完整过程”，我第一反应不是去看热闹，而是意识到这个选题背后藏着几件非常值得拆开讲的事：为什么一个边数如此夸张的正多边形，会成为尺规作图上被反复提起的极限问题？要把这条构造路径真的做成动画，数学上需要准备到什么程度？以及 Manim 在表达这种极高复杂度对象时，它的能力边界到底在哪里。

标题里用了“全网首个”和“癫疯”这种偏视频平台传播风格的词，很容易把注意力带偏。我更关心的反而是后半句：一是“完整过程”，二是“Manim 动画”。前者指向一个长期被当成理论难题的数学对象，后者指向一种非常具体的内容生产方式：用代码控制每一个几何对象，让抽象证明变成可见的时间轴。

所以这篇文章不会去论证“是不是全网第一”，也不打算把 65537 边形吹成什么不可触及的神迹。我想做的是把一个真实存在的数学构造问题，和一个常用的数学动画工具放在一起，拆清楚三件事：这个问题难点在哪，用 Manim 做它的正确思路是什么，以及如果你也想复现类似项目，会踩到哪些实际的坑。

1. 先搞明白：为什么正 65537 边形的尺规作图会被称为“极限难度”

1.1 尺规作图不是“画得出来”，而是“有限次可构造”

很多人第一次听到“尺规作图正 65537 边形”，会本能地想到一个画面：用圆规不断取等分，然后在圆周上数出 65537 个点，最后连起来。如果只是这么理解，那问题确实不难，电脑一秒钟就能算出每个点的坐标，绘图软件也能直接画出来。

但数学里说的尺规作图，规则严格得多。它只允许两种操作：

• 用未刻度的直尺过两个已知点画一条直线。
• 用圆规以已知点为圆心、过另一个已知点画一个圆。

每一步产生的新点，只能是直线与直线、直线与圆、圆与圆的交点。整个过程必须有限步完成，不能依靠目测，不能用量角器，不能直接读取刻度，更不能先用电脑算出坐标再“照着画”。

所以难点从来不是“画 65537 条边”，而是“怎么用有限次直线和圆的交点，构造出那些最终落在圆周上的顶点”。这是完全不同的两件事。

1.2 高斯-旺策尔定理、费马质数与 65537 的特殊位置

关于正多边形能不能尺规作图，数学上有一套明确的判定条件。高斯在青年时期证明了正十七边形的尺规作图方法，后来旺策尔给出了更完整的可作图性判定定理。简单说：一个正 n 边形可以尺规作图，当且仅当 n 可以写成

n = 2^a × p1 × p2 × ... × pk

的形式，其中 p1、p2、…、pk 是互不相同的费马质数。

费马数是一类形如 2^(2^m) + 1 的数。比较著名的几个：

• F0 = 2^(1) + 1 = 3
• F1 = 2^(2) + 1 = 5
• F2 = 2^(4) + 1 = 17
• F3 = 2^(8) + 1 = 257
• F4 = 2^(16) + 1 = 65537

前五个都是质数，也是历史上用来构造正多边形的主要对象。为什么 65537 显得特殊？一方面它已经是目前这些常见费马数里最大的一个质数；另一方面，在 Hermes 的工作之后，它成为一个经典符号：一个在理论上有完整构造方案、但实际手工作图几乎不可能完成的对象。

这里要澄清一个常见误区：正 65536 边形反而相对“容易”，因为 65536 = 2^16，是 2 的幂。这种边数可以通过不断平分角度来构造。而 65537 是质数，它不能靠单纯等分角度得到，必须用多条辅助线、多个圆和交点的链条去构造出对应角度的余弦值。这才是它成为尺规作图难题的原因。

1.3 所谓“完整过程”，到底指什么

关于 65537 边形的尺规作图，有一个很出名的历史故事：德国数学家 Johann Gustav Hermes 在 1894 年前后曾花了很多年时间，整理出正 65537 边形的完整尺规作图步骤，手稿后来存放在哥廷根大学，据称有一百多页甚至更多。

这个故事的细节在不同材料里有些出入，但核心事实是清楚的：这确实是一个在历史上被认真研究过的构造问题，不是空想出来的作业题。

所以当有人做“完整过程”动画时，他至少面对两种选择。

第一种，严格按 Hermes 的构造路径，把每一条辅助线、每一个圆、每一个交点都画出来。这样做理论上最“正宗”，但会带来一个视觉灾难：因为中间环节太多，画面会变成一张巨型蛛网，观众很难跟上重点。

第二种，在保留“尺规作图”约束的前提下，先利用数学推导算出每一步关键点的位置和关系，然后用动画展示出一条可验证的构造链。这种更像“面向视频的简化呈现”。它展示的是构造思路，而不是逐页复刻手稿。

从内容传播角度看，我猜测多数人会选择第二条路，同时把其中某几个关键步骤挑出来放大。这不是偷懒，而是视频内容本身的认知负载限制。真实的 Hermes 手稿如果逐像素动画化，观众在第一分钟就会失去耐心。

想理解这个项目有多“极限”，你先得接受一个设定：所谓完整过程，更接近一个被压缩过的、可观看的构造逻辑，而不是人类手工逐动作的直播式复刻。

2. 为什么选择 Manim：这个工具真正解决的问题，是“把证明变成时间轴”

2.1 代码化几何对象：每一步都是一种可逆、可复用的组件

Manim 是 Math Animation Engine 的缩写，最早是 3Blue1Brown 做数学动画时使用的引擎，后来分出了社区维护版 Manim Community。它和一般绘图软件最大的差异是：所有内容都是代码对象。

比如你用Circle画一个圆，它不是一个像素阵列，而是一个包含圆心、半径、坐标系位置、描边颜色和粗细的数学对象。你可以对这个圆做shift、scale、rotate，也可以让它在某个时间片内慢慢出现或消失。

对尺规作图动画来说，这个特性几乎是量身定做的。因为尺规作图的每一步，本质上就是一个几何对象在空间里被“构造”出来的动作。放大、平移、变换透明度、保留痕迹、擦除辅助线，这些都可以通过操作对象属性来完成，而不是在渲染软件里逐帧手调。

代码化的另一个好处是：可复用。同一个构造步骤，稍微改一下参数，就能用在正十七边形、正二百五十七边形、正六万五千五百三十七边形上。你不需要为每个多边形重画一遍图，只需要让同一套逻辑处理不同的顶点数和不同的中间步骤。

2.2 LaTeX 与几何图元无缝配合

数学类动画最大的痛点之一，是怎么把数学公式塞进画面。普通剪辑软件里放公式很麻烦，要么用图片，要么用特殊插件。Manim 直接支持基于 LaTeX 的数学文本对象，比如MathTex、Tex。你可以在一个画面上同时放一个圆、一条辅助线、一个交点、一段坐标公式和一个证明注释，并且让它们保持同一个坐标系下的相对位置。

这里最核心的一个视频优点：你能把“构造动作”和“解释文本”绑定在同一个时间轴上。比如画面先画出一个圆，然后文字说明“这是此构造的主圆”，随后画面继续出现一条弦，文字自动切换成“接下来利用该弦的次数来求特定角的余弦”。观众可以不脱离画面就获得解释，体验比字幕、画外音、分屏截图都要完整。

对我来说，这件事是选择 Manim 的关键理由：它让数学视频从“事后配音解说”变成“把推导过程本身可视化”。

2.3 别把 Manim 当成万能动画机：它的边界也在这里

但是，Manim 不是万能的。尤其在 65537 边形这种高复杂度对象面前，它的边界会被拉得非常明显。

首先，Manim 本质上是矢量动画引擎。矢量图的优势是画大圆、小圆、细线都不会失真，但代价是每个对象在渲染时都有独立的树状结构。当你一次性加入几十万个几何对象，内存占用和渲染时间会急剧上升。

其次，Manim 的动画编辑模型适合“把某几步讲清楚”。它强调的是时间轴、运动、变化。如果你更想要一个可以自由拖动、探索、交互的几何画板，那 GeoGebra、几何画板这类专业互动几何软件会更合适。Manim 适合被用来做“成品”，而不是做“探索工具”。

另外，Manim 对版本和渲染环境相当敏感。不同小版本之间 API 可能差异巨大，一个在旧版本脚本里正常运转的动画，升级后可能报错或画面错位。如果之后要接入复杂中文注释，还需要确保系统里有可用字体，否则渲染出来全是方框。

2.4 我的工具选型判断

回到这个项目，我的判断是：如果只是想让屏幕上出现一个看起来像圆的正 65537 边形，那根本不需要 Manim，用任意一个绘图库，几百毫秒就能画出来。但如果你想展示“尺规作图过程”，真正有价值的是构造链开始前的关键步骤、中间的辅助对象、逐步收敛到 65537 条边的过程，那 Manim 是比交互式几何软件更合适的选择。

它的价值不在“画得快”，而在“把每一步变成观众可以跟上的时间序列”。这正是教育类数学动画最需要的东西。

3. 制作“尺规作图动画”的完整思路：从数学建模到结构拆解

3.1 把几何构造翻译成可计算的复数与二次扩张

在做动画之前，你需要先在数学上准备好风控模型。这不是一句空话，而是实际操作的第一步。

尺规作图能构造的点，本质上对应复平面上可以用单位元出发、通过有限次四则运算和平方根得到的复数。正 n 边形的顶点恰好就是方程

z^n = 1

的 n 个复数根，也就是单位根。对于 n = 65537，因为它是费马质数，这些单位根可以分解成一串二次扩张的组合。翻译成人话：理论上，存在一串有限长度的尺规构造步骤，可以逐步生成这些顶点的坐标。

对动画来说，你需要这个理论保证，否则你只能靠程序随机生成一个“差不多”的多边形，那不是尺规作图，而是伪可视化。

常见的做法是，在动画脚本里先单独准备一个数学计算层：

• 计算 65537 次单位根的所有坐标；
• 用二次扩张的链条，把某些关键中间值表示成带平方根的表达式；
• 在此基础上决定，视频里的构造链要展示到第几层，哪些环节适合用动画表现，哪些环节只给文本说明。

这一步决定了动画内容是“真的在用尺规方式生成顶点”，还是“先把答案算出来再假装连线”。后者在视觉上可以很精致，但在数学上不够诚实。既然标题写的是“尺规作图”，构造过程的逻辑链条至少要站得住。

3.2 动画时间轴：不只要展示成品，还要展示“构造链”

我整理这类项目时，看到时间轴大体上会分成四层：

第一层是准备阶段。画布上先出现一个足够大的基准圆，标注圆心和某个初始点。这相当于所有构造步骤的起点。

第二层是关键构造阶段。这部分会展示若干次角度等分、圆与直线交点、圆与圆交点。它不是把 Hermes 的几百页手稿全画出来，而是抽取其中代表性的若干层，用一句话说明“这一步本质上是在干什么”。

第三层是收敛阶段。辅助线逐渐淡化，或者用一条新的连线把已经构造出来的顶点顺次连起来。因为 65537 个顶点过于密集，观众看到的会是一个逐渐填满的圆环边界。

第四层是成片展示。最终隐藏全部辅助线，只保留一个完整多边形。此时观众才真正理解，刚才那些看似杂乱的线，最终叠出来的是这样一个接近圆形的闭合图形。

这种时间轴设计的核心，不是把所有细节塞满屏幕，而是让观众经历一次“从混乱到有序”的认知过程。这也是 Manim 的优势所在：你可以自由控制每一步的显示时长、透明度、动画轨迹，而不是像播放一个静态图片那样一翻而过。

3.3 代码层面的抽象设计

真正写 Manim 代码时，不建议把所有步骤全部写在一个巨大的construct方法里。那样调试起来会非常痛苦。

一个相对好维护的方法是把代码拆成三层：

• 第一层：几何对象生成层。用 Python 类封装“点”“线”“圆”“交点”“辅助线组”这些概念，每个类只负责生成对应的 Manim Mobject。
• 第二层：构造步骤层。每个步骤是一个独立方法，接收前一步产生的对象，输出这一步的新对象。比如construct_quadratic_equation、step_intersection、step_angle_bisect。
• 第三层：动画导演层。Scene负责调度步骤，决定什么阶段调用哪个构造方法，以及中间插入什么样的文本说明。

这样做的好处是：你可以在某一帧里快速定位到具体出错步骤，也可以把某个构造步骤抽出来单独测试，而不用把整个视频重新渲染一遍。尤其是处理 65537 边这种高复杂度对象时，代码的可拆分程度直接影响调试效率。

3.4 以正 17 边形为例的最小代码模型

正 17 边形和 65537 边形在数学结构上同源，都是费马质数对应的尺规可构造多边形。所以如果你想先跑通一个最小闭环，正 17 边形是最好的练习对象。

下面是一个很简单的 Manim Community 示例结构，仅用于演示基本写法，还不是完整的尺规构造：

import numpy as np from manim import * class RegularPolygonDemo(Scene): def construct(self): n = 17 vertices = [ np.array([np.cos(2 * np.pi * k / n), np.sin(2 * np.pi * k / n), 0]) for k in range(n) ] poly = Polygon(*vertices, color=YELLOW) dots = VGroup(*[Dot(v, radius=0.04, color=BLUE) for v in vertices]) self.play(Create(poly), run_time=2) self.play(FadeIn(dots)) self.wait(1)

这段代码没有涉及真正的尺规辅助线，但它展示了你在 Manim 里处理多边形顶点的基本思路：顶点坐标是计算出来的，多边形是一个可动画对象，点组是一个单独的对象。后续你要做的，其实就是把这些顶点坐标的计算过程，替换成“通过直线和圆的交点逐层构造出来”。

从正 17 边形扩展到正 65537 边形，代码逻辑本身不需要改变太多，真正变化的是数学构造链的层数，以及最终需要渲染的顶点数量。

4. 真正的深水区：图层、渲染、性能、排查

4.1 65537 个对象不是画不出来的问题，而是“要不要全画出来”

你可能会担心，Manim 真的能承载 65537 个点吗？答案是能，但前提是使用方式得当。

一个典型的场景类是这么运作的：它内部维护一棵对象树，每次add一个对象，渲染时都会遍历这棵树。当你为 65537 个顶点各创建一个Dot对象时，Manim 要管理的就不仅仅是 65537 个点，还包括每个点内部的样式、透明度、层级、变换状态。这种规模虽然不至于让程序直接崩溃，但会让动画产生大量不必要的中间计算，拖慢渲染。

更好的做法是：尽量用向量化方式合并同类对象。例如很多顶点可以用一个VGroup整体管理，甚至把多个点作为一个独立的几何系统进行处理；或者用PointCloudDot来处理大量协作点；再或者只在极少数需要强调的步骤里显示单个点，大部分时间让它们融合成一条连续的轮廓线。

对 65537 边形来说，最合理的视觉策略其实不是把每个顶点放大显示，而是用一条足够细、足够密集的多边形线框来表现“边”的存在感。观众根本无法在屏幕上分辨出相邻两个顶点的间隙，所以过度强调点的数量反而会失去意义。

4.2 渲染节奏与分层设计

做这种项目的过程中，我建议建立三层渲染层次：

• 低质量预览层：渲染时使用-ql参数，快速生成一个低分辨率版本，主要用于检查动画节奏、对象位置、文本是否重叠。
• 中等质量调整层：确认节奏没问题后，用-qm渲染，检查线条清晰度和整体观感。
• 成片质量层：发布前再用-qh甚至更高参数渲染最终版。

每一层的目的不同，不要一上来就直接用最高质量渲染。因为你很可能在检查过程中发现：

• 某条辅助线和文字重叠；
• 某个阶段的过渡太快，观众根本看不清；
• 某个步骤的坐标计算有微小误差，导致最终的封闭图形存在肉眼可见的缺口。

如果在最高质量下才发现这些问题，一次重新渲染就会消耗很长时间。先小分辨率验证，再大分辨率定稿，是所有视觉动画项目的通用经验。

4.3 常见问题排查链路

如果画面表现不符合预期，建议按下面这个顺序排查，不要看到哪乱就改哪。

第一步看现象。先区分是报错、卡死、无输出、输出内容不对，还是渲染速度极慢。报错多半和代码语法、版本兼容有关；卡死多半和对象数量、资源占用有关；无输出多半是场景没有被正确执行；速度慢多半是对象过多或特效过重。

第二步看数据。对正多边形来说，最值得怀疑的是坐标计算。比如角度取的是弧度还是角度，顶点顺序是连成一条折线还是按环形顺序连接，循环边界有没有出问题。先输出前 10 个顶点的坐标，和标准公式比对一遍，往往能发现问题。

第三步看环境。Manim 的版本、ffmpeg 是否安装、字体是否缺失、路径是否含中文、系统是否支持 OpenGL 后端，这些都会影响结果。换了一台机器就出问题，几乎都是环境差异导致的。

第四步看参数。运行时长、等待时间、缩放比例、坐标平面范围、点的半径、线的粗细，这些看起来不起眼的参数会显著影响视觉效果。点的半径太大，会把相邻点融合成一团；线的粗细太大，会让靠近圆心的结构变得浑浊。

第五步看工具边界。如果代码本身没问题，但渲染依然非常慢，那就要承认 Manim 的矢量渲染对几十万量级对象并不高效。此时可能要考虑引入后台计算、预生成顶点数组，或者接受“某些过程只能通过视频片段剪辑来表现”。

注意：Manim Community 对版本和依赖相当敏感，换版本后先跑一遍官方示例脚本，再启动自己的项目，可以省掉很多莫名其妙的调试时间。

5. 这个项目值得带走的，不只是一条动画，而是一套数学可视化的方法

5.1 从“演示”到“教学”，差的不只是进度条

只看成品动画，观众会觉得很神奇：一堆辅助线来回缠绕，最后突然变成一个完整的巨大多边形。但“演示”和“教学”之间有一道明显鸿沟。

演示只负责展示结果，不负责解释逻辑。教学则需要回答三个问题：为什么中间要引入某个圆？为什么这一步要这样连？这个步骤和前面哪一步发生了关联？

放到 65537 边形这个具体案例里，真正好的动画不应该只让人感叹“哇，这么密”，而是应该让人理解：

• 为什么 65537 这个数字来自费马质数；
• 为什么它能被拆解成一系列二次扩张；
• 为什么这些二次扩张能对应到尺规作图的两类基本操作；
• 为什么最后的顶点可以被有限步精确构造出来。

而不是把整个过程变成一场视觉盲盒。

5.2 一套数学动画的可复用判断清单

如果你以后想做类似高复杂度数学动画，可以套用下面这个框架先自检一遍：

• 数学上是否诚实：内容里是否掩盖了重要假设，是否把算好的答案伪装成构造过程？
• 结构上是否清晰：这一步在全局里的作用是什么，观众能看懂吗？
• 视觉上是否分层：是否把所有信息一股脑铺在屏幕上，还是用透明度、颜色、缩放来引导注意力？
• 节奏上是否合理：重要步骤是否给了足够停留时间，次要步骤是否一闪而过？
• 边界上是否说明：有没有告诉观众，这个动画只是构造思路的示意，而不是 Hermes 手稿的逐帧复刻？

这个清单不是要你每一条都做到完美，而是提醒你：高复杂度内容最大的风险不是做得不精致，而是做出来之后，观众得到了一个视觉印象，却没有得到一份准确的理解。

5.3 适用场景与不适用场景

适用场景包括：

• 把抽象代数或数论里的可构造性概念具象化；
• 作为教学辅助，帮助学生理解二次扩张和尺规作图之间的关系；
• 用于短视频科普，用视觉冲击引起观众对数学史的兴趣；
• 作为编程练习，考验开发者对 Manim 性能边界的把握。

不适合的场景包括：

• 需要严格展示 Hermes 手稿每一个步骤的学术场景；
• 需要交互式探索某个角度、某条辅助线作用的教学场景；
• 需要高精度几何证明的严肃数学论文附属材料。

如果你要的是严格证明，请输出文档或交互几何软件；如果你要的是帮观众建立直觉，Manim 动画是很好的媒介。

6. 如果你想复现一个简化版，请按这个路径走

6.1 环境准备

在开始写代码前，先安装好这些基础依赖：

安装完成后，先运行一个最简单的官方示例场景，确认环境是通的，再开始写自己的构造逻辑。

6.2 最小闭环：从正 17 边形开始

我的建议是，不要一上来就碰 65537。先用正 17 边形把整个流程跑通。流程包括：

1. 在 Manim 里画出基准圆；
2. 通过直尺和圆规的交点，展示正 17 边形的一个或两个关键顶点的构造；
3. 用Create把多条边依次连起来；
4. 加入文字说明，解释这一步的数学目标。

正 17 边形的优势是它的构造过程足够简洁，你能在几分钟内检查出代码问题。等你确认整个动画逻辑成立，再替换成正 257 边形、正 65537 边形，只需要修改顶点数量、构造链条深度和最终的视觉呈现策略。

6.3 替换为正 65537 边形的检查点

当你把顶点数量改成 65537，最容易遇到的问题有三个。

第一个是坐标精度。65537 个顶点均匀分布在圆周上，相邻两个顶点之间的距离非常小。如果计算用浮点类型精度不够，最终的闭合多边形会出现微小错位，导致最后一笔连不回起点。建议使用高精度计算或对坐标做统一归一化处理。

第二个是渲染密度。顶点数量一变，所有基于顶点数量的绘制操作都会变得更重。你需要重新评估哪些辅助线值得展示，哪些只作为背景淡入淡出。不要让屏幕同时出现几万条高亮辅助线，否则画面失去重点，观众的注意力会被彻底消耗。

第三个是视觉表达方式。一个准确的 65537 边形，在常规画布上和圆几乎没有区别。所以要设计一个更好的展示方式：局部放大某一个区域，让观众看到“它确实有大量边”，而不是一个完美圆形。

6.4 发布前检查内容清单

在最后定稿前，建议检查这几项：

• 数学公式是否正确，有没有把正弦和余弦弄反；
• 动画里是否明确说明“这是示意层级，中间步骤经过简化”；
• 文本是否和画面同在，不会出现先讲后画的割裂感；
• 镜头有没有在关键步骤放大，让观众看清构造关系；
• 最终输出的分辨率、帧率、字幕是否统一。

如果画面异常，不要急着加特效，先确认你计算的顶点坐标真的在同一个圆周上，而且连线顺序是沿圆周走的，而不是随机连接。

6.5 把一次演示变成长期可维护的内容库

这个项目如果只是做一次、发一个视频，价值其实有限。更值得做的，是把它沉淀成一套可复用的内容模板。

一旦你把“费马质数”、“可作图性条件”、“圆与直线交点生成顶点”这些模块写成了可参数化的 Manim 类，未来再做正十七边形、正二百五十七边形，或者跟学生解释“什么样的正多边形可以用尺规作图”，都可以复用同一套工具类。

和一个项目相比，一套能长期用的数学动画工具链，更能延续这次创作的实际价值。

回到最开始的问题：manim和manim学习这两个热词凑在一起，说明越来越多的人并不只是想看“一个动画”，而是想掌握“做出这类动画的方法”。这个正 65537 边形的尺规作图动画，确实是一个有视觉冲击力的选题，但它更大意义在于演示了一条路径：把历史上复杂到几乎没人手绘的数学构造，转译成普通观众也能跟随的视觉过程。

“全网首个”只是一个传播标签而已。真正值得记住的，是你怎样把一个看似遥远、抽象、复杂到近乎不可操作的数学对象，放进代码里，放进时间轴上，最终变成一段让人愿意停下来看两遍的内容。如果你也想做类似的数学可视化，不用从 65537 开始，先从随手就能画出的正五边形、正十七边形开始，把工具链、判断思路和复盘习惯建立起来，再逐步挑战更复杂的对象。

这也是我认为这一类项目最有价值的打开方式。