一次真实的 Kimi Code 打包实践
Python 程序写完之后，打包往往才是另一场工作的开始。
Nuitka 的功能很强大，但面对 onefile、standalone、模块递归导入、Tcl/Tk 数据、Windows 运行库以及各种裁剪参数，想得到一个既能运行又尽量精简的产物，通常需要反复查资料、修改命令和验证。
这次，我把这个任务交给了 Kimi Code。
我没有逐条告诉它应该添加什么参数，只提出了目标：
随后，Kimi Code 在项目目录中完成了从分析到交付的整个过程。
Kimi Code 实际做了什么
Kimi Code 确认项目使用的是：
- tkinter 和 tkwebui 界面；
- pymem 内存读写；
- Nuitka 编译；
- Tcl/Tk 运行资源；
- 做一轮模块和数据裁剪。
并保留了适合当前项目的精简参数：
- 使用 LTO；
- 删除 docstrings 和 asserts；
- 排除未使用的 Python 模块；
- 裁剪 tkwebui 的模块和导入；
- 删除不需要的 Tcl/Tk 数据；
- Tcl 编码只保留 ASCII、CP1252、CP936 和 ISO-8859-1；
- 保留 Windows 所需运行库。
最后输出完整运行目录。
3. 真正执行构建，而不是只给一段命令
Kimi Code 不只是写出脚本，还实际运行了 Nuitka 构建。
构建成功后得到：
- standalone 目录总大小约 17.2 MiB；
- 主程序约 6996 KiB；
- onefile 版本约 5.8 MiB。
构建完成后，它还实际启动了 standalone 中的 EXE，确认进程没有提前退出，主窗口能够正常创建。
这一点很重要：AI 交付的不是一段“理论上可以”的命令，而是一个已经执行并做过启动验证的产物。
4. 继续回答“为什么这么大”
看到主 EXE 有 6996 KiB，我自然产生了疑问：一个界面并不复杂的程序，为什么需要这么大的 EXE？
Kimi Code 没有停留在“这是运行库开销”这种笼统解释，而是直接检查 PE 文件结构，得到：
| 区域 | 约合大小 | 主要内容 |
|---|---|---|
.text |
2.13 MiB | 编译后的机器码 |
.rdata |
4.61 MiB | 常量和只读数据 |
| 其他区域 | 几十 KiB | 可写数据、异常处理、资源和重定位信息 |
这说明体积大头不是机器码，而是 .rdata。
继续扫描后，又找到了 tkinter、encodings、difflib、trace、zipfile、sysconfig、subprocess、pymem、tkwebui 等模块的常量、名称、模板和错误文本。
于是一个模糊的“文件很大”变成了可以分析的具体问题：
standalone 递归纳入了多个 Python 模块，Nuitka 将这些模块的常量和元数据编译进主程序；onefile 更小，则主要因为它进行了压缩。
AI 改变的不只是写命令的速度
过去做精简打包，常见流程是：
- 搜索 Nuitka 参数；
- 复制一段命令；
- 构建失败后再搜索错误；
- 成功启动后再逐个删除文件；
- 发现某个功能异常，再恢复依赖；
- 反复比较文件大小。
Kimi Code 可以把这些步骤串起来：
- 阅读现有脚本；
- 理解项目依赖；
- 修改构建配置；
- 执行完整构建；
- 检查输出目录；
- 启动程序验证；
- 分析二进制体积；
- 将命令、结论和后续优化方向整理成文档。
也就是说，它承担的是一整条工程流程，而不只是一个“命令生成器”。
这个活以后可以交给 AI 了
对于这类目标明确、结果可以验证的任务，我已经可以放心地把它交给 AI：
把这个 Python 项目用 Nuitka 打成精简 standalone，保留原构建方式，完成后实际构建并验证启动，同时解释产物体积。
相比“帮我写一条 Nuitka 命令”，这种任务描述更完整，也更适合 Kimi Code 发挥。
AI 可以负责繁琐的分析和执行，人则负责提出目标与验收要求：
- 要 onefile 还是 standalone；
- 是否允许启动时自解压；
- 更重视体积还是启动方式；
- 是否必须兼容没有 Python 的电脑；
- 哪些功能必须逐项验证。
也需要保留的边界
“交给 AI”不等于省略所有验收。
尤其是精简打包，排除模块可能只影响某个较少使用的功能。程序能启动，并不代表所有功能都经过了验证。
因此，合理的分工是：
- AI 完成构建、裁剪、启动验证和体积分析；
- 开发者补充游戏内或业务场景的功能测试；
- 每次新增排除参数后，都重新验证相关功能。
结语
这次实践最让我满意的，不只是得到了一个约 17.2 MiB 的 standalone 目录和一个5.9MB onefile，而是整个问题终于有了完整的处理链条：
从构建脚本，到实际产物；从启动验证，到 PE 段分析；从体积疑问，到可以继续执行的优化方向。
Nuitka 精简打包这种需要查参数、改脚本、跑构建、看结果的活，以后确实可以交给 Kimi Code 了。
人只需要说清楚想要什么，并负责最后的业务验收。