在懒猫的应用中必然有可能会要用到打开文件，由于安全机制，应用能访问的只是自己容器下的内容，即挂载到/lzcapp/pkg/content下的项目本身以及/lzcapp/var等映射中，以及document目录，从中找文件读写的过程自然多半都要开发者自己解决。

但是官方提供了一个文件选择器，看上去是和懒猫网盘中用的一样，可以方便的选择网盘中的文件。于是我打算在研究完minidb之后开始玩一下这个插件。

上次说到**用AI一定要生成文档**，这次也是冲着文档去的。

……至少我本来是这么想的……

但是filepickers不像minidb那样简单，又关系到各种路由、磁盘映射、权限等问题，所以没想到折腾了我好久，与[《Vibe打金计划(5)：懒猫minidb插件》](https://lazycat.cloud/playground/guideline/822)里写的快餐式情况简直形成强烈对比。

因为我对输出要求比较高，所以不可能只是做让AI“根据插件说明总结成文档”这样简单的无用功。一定要做出Demo实测成功后才会输出文档。

所以在折腾了近两天之后才能输出文档，即使这样，Demo里也仍然存在一个没解决的小Bug。我实在和AI耗不起了，也不是什么影响主要功能的bug，估计后面也会很快解决。

---

延用历史记录并输入信息

我直接延用了之前研究minidb时的对话历史，提示是这样写的：

现在开始研究一个新的插件，懒猫文件选择器，请参考附件文档同样做一个全新的独立测试项目。项目名称可以叫filepickertest。由于同样是懒猫官方提供的插件，应该是同一个团队开发的，一些使用模式可能是相通的。但它要关联到懒猫设备中一个叫懒猫网盘的官方应用及懒猫设备的文件系统。

同时同样直接插入了项目的README。（[官方项目链接](https://www.npmjs.com/package/@lazycatcloud/lzc-file-pickers?activeTab=readme)）

---

漫长的调试

先感受一下我为这个插件与AI做了多少次交流吧……40多个节点平均9万Tokens/个，大约是用了3600000+Tokens……，想到这点我就又有点期盼无限token的算力舱了……

具体的调试内容，其实没什么好说的，基本上是小白的我只凭报错信息与AI互相磨，而且有大约四分之一的时候是AI好了这里又错那里的反复操作。

甚至其中包含了打包和路由相关的一些问题，我在前一篇里也都有写。

但总之，我以前也多次说过，与AI交流其实是自我学习的一种方式，相当于有一个不厌其烦的老师或助手在一起工作。

---

Demo界面

虽然过程比较反复，AI至少给我完成了一个基本可行（除了前面提到的一个小bug)的测试界面：

它可以判断插件的加载情况以及显示必须的环境变量：

可以在新的浮层中打开懒猫文件选择器，并选择其中的文件供预览（图片）

也可以测试上传功能。

---

压缩源码也可以喂AI

调试中途还是有一点有趣的事情，由于一个总是获取不到盒子名称的问题绕了很久，我打算去官方再找点什么资料，可是依然除了一个README没有别的文档。

但是我在[code](https://www.npmjs.com/package/@lazycatcloud/lzc-file-pickers?activeTab=code)的/dist中发现了打包压缩的文件源码，因为经过压缩，里面的变量名都是abcdxyz啥的，人类根本看不懂。

但是贴给AI后它一秒就找到了问题所在，原来只是一个变量名把BoxID写成了BoxName。

在之后的对话中它也经常参考和引用源码，说明AI对于语言的理解能力并不限于人类语言的语义，有逻辑的代码即使压缩混淆过，对它来说甚至反而更好理解。

Demo完成

总之，经过漫长的调试，这个Demo也基本上做完了。其实所谓遗留的BUG只是因为之前能获取到的用户名变量，不知怎么被AI在多次重构后遗忘了，导致找不到网盘中实际文件的地址。

我想稍后我有时间就可以再启动这个工作流，甚至自己研究一下搞定它。

目前生成的文档在这里：

《lzc-file-pickers 插件详细使用说明》

但是必须要注意：

**由于我和AI都还没有100%吃透这个插件，所以这篇网档的可参考性甚至低于以前生成的文档，使用时必须注意，仅供补充参考。**

—-

最后还是要感慨一下Refly的能力，其他的表达形式以人脑和人眼的能力根本无法处理这样的逻辑，以纯对话形式的话也早就玩不下去了，而Refly居然还能保持在这个交互量下AI给的结果基本不走样！

而且这张画布是我集中了三个项目，包括之前开发到一半的记忆闪卡应用、Minidb的研究、file-pickers的研究。几十个节点放在一起组成复杂交织的数据网络，居然渲染上也没有任何卡顿。