使用 AI 构建一个本地文件预览服务

公司的文件预览服务使用的是 kkFileView，后面 kkFileView 开始走商业化路线，开源版本就停止更新了。

昨天给客户部署服务的时候，发现给客户部署的 kkFileView 无法启动。客户要求在 Arm 的机器中部署应用，所有的 Docker 镜像都是重新打包的。可是 kkFileView 提供的 Dockerfile 的下载 LibreOffice 的链接无法访问了，使用的 LibreOffice 版本也不支持 arm 架构，所以只能升级 LibreOffice。一开始只是照着原有的 Dockerfile 替换源和替换 LibreOffice 的版本，可能还是无法启动，测试发现是缺失了依赖。费了好大劲才发现说，制作 Docker 镜像的时候，其实不需要使用离线安装包，而应该用 apt-get 的在线安装的方式。

如果没有 AI 工具的话，事情可能就这么结束了。昨晚回家一想，既然我们已经全面使用了 Solon，那么为什么不用 AI 写一个 Solon 版本的文件预览服务呢？我们不需要像 kkFileView 那么支持那么多的文件预览，重点解决 Office 文档的预览，提供 Office 文档转 PDF 的功能就够了。

于是通过 Solon 的模板项目生成器，构建了一个初始化的版本。用户用Claude Code 的 /init 命令对项目进行初始化。因为看过 kkFileView 的一些源码，整体的方案是知道一些的，前端也不想使用分离模式。于是给Claude Code 的提示词是：

我要创建一个基于 Java 的文档转换和预览系统，使用 JODConverter 技术提供高质量的文档格式转换服务，并通过 Bootstrap 5 构建现代化的 Web 界面，先提供 UI 图，供我审核。先不要生成代码，把升级方案生成到 doc 目录。

于是他夸夸一顿操作给我生成了这些文档，比我自己写完整多了。

中间对界面做了些调整，要求它使用单独的预览页面而不是用预览区域。让它开始生成代码之后，也就是看看一屏一屏的滚动代码，自己选择 yes 和 apply 就行。

需要注意的是，虽然在 CLAUDE.md 里面已经识别了 Solon 框架，但 Spring 的资料就是比 Solon 全，在技术实现的方案里面，还是会引入 Spring 的依赖，生成的代码还是会包含 Spring 的注解。还碰到的问题是 一些 Solon 的包路径错误，所有这些错误，都需要自己手动调整（我不知道如果不自己调整，最后能不能通过）。

在修改编译通过，项目可以正常启动后，一定要注意签入 Git，这样后面生成的不满意也可以回滚。

接下来的调试和调整了，对于前端来说，我基本不会，所以我只提问题，让 Claude Code 进行修改。对于后端代码来说，我能看其中写的有问题的地方，自己做修改。这里和自己写代码没什么不同，发现错误，修改错误。

让 AI 修改问题时，如果能知道文件名最好直接写在提示词，如果确定代码的部分是一样的，这样修改会更高效些。比如在待上传列表中的标签文字一开始不是白色的，不容易看出来，我让它修改它修改了列表的标题，而不是标签。后面我自己找的标签的位置说，颜色看不清，他很快就把颜色换成白色了。

以下是功能截图：

上传文件

选择文件，出现待上传文件，点击上传按钮，文件显示在已上传列表，此时可以点击转换或者预览。

预览 docx 文件

预览 xlsx 文件

查看转换任务

已经转换好的文件可以直接点击下载按钮进行下载。

本次代码生成一个用的是 1000万 GLM-4.6资源包，生成的时候还没用一般，调试问题，修改问题，一会就给我干完了，然后充了个 GLM Coding Lite 才把后面的功能调完。问题处理、调试可能会发送比较多的上下文信息，而且需要经过多轮修改，所以Token 消耗会比多。

经过一天的调整，一个 MVP 算是出来了，主体的文件转换和预览功能都是正常使用的，后续还需要调整代码结构和完善功能。于是每次使用 AI 编程的时候，都感慨 AI 是真行，写代码的成本应该是会越来越低的，自己能做的事情应该是越来越多的。