记录一下用trae实现word和pdf互转的过程

最近做了个word-pdf转换器，原因就是太多的收费pdf转word工具无法让我白嫖。

一开始我不知道能否实现，就直接问deepseek如何实现word和pdf互转，

deepseek给了一些方案，让我心里有底。

为什么选deepseek确认需求是否能落地呢？

自然是trae并不怎么靠谱。

那么为什么不用cursor呢？

自然是不想付钱上班，trae因为免费也就变得可爱起来。

况且，你只要花点心思，trae也没有很多人口中那么难用。

确定完可以实现后，就让trae用python写一个转换脚本，关键词也不需要描述太多，

让trae建立python虚拟环境以及直接说做一个word和pdf转换的脚本即可。

10分钟后就出货了。

之后就是漫长的测试，让trae写的程序变成相对好用。

一开始，脚本转换效果并不好，中文都是乱码，我让trae自己分析该问题，

trae得出的结论是当前的库不支持中文，要不就是告诉程序中文字体在哪，

要不就是切换到别的库，同时还只能在装了microsoft word

或者wps的windows系统上使用。

权衡一番后决定使用第二个方案。

新的方案效果不错。

接着，我要实现批量转换的功能。

这个过程遭遇的最大问题是，程序确实实现了批量转换，

生成的文件也没有问题，但是就是报错了。

而trae自然而然就糊弄过去，说什么日志显示成功转换了，

可以忽略这个问题。

我直接跟它说不能忽略，请检查代码是否有问题。

后续，trae也找出原因。

就是word com接口转换完一个文件后，程序以为转换结束直接关闭接口，实际上需要等待一会儿才会真正结束。

当然这些都是trae告诉我的，它什么都能做，就是不愿意做。

后续脚本增加一小段等待时间，也就解决这个问题了。

最后，就是实现打包成exe可执行程序的功能了。

一连好几次打包后的程序都出错，trae也只是遇到问题解决问题，然后诞生下一个问题。

后面我烦了，直接上手一顿分析，发现是没有把库都打包进来，

原因是代码里面有部分库是在方法执行的时候动态引入的，打包就不会自动引进来。

不知道是学了谁的习惯，怎么不把引入这个动作全放在文件顶部呢？

遇到这种情况也只能依靠自己的牛马开发经验了。

总的来说，整个开发过程还算顺利，我之前没有ai辅助，也基本上是这个开发套路，

只不过ai可以省却我排查错误的解决方案的时间。

不过，目前还谈不上真正的vibe coding，

我也不敢在大项目里面完全交由ai开发，

最多就是遇到问题问一下deepseek，不过做点提升效率的小工具我倒是挺放心交给ai的。

有一些朋友找我帮忙做个什么文件处理工具，基本都是我写好框架，教他们用trae去改进。

这些场景下ai确实能发挥不错的作用。