关于AI开发，有个💩山工程：一个好消息一个坏消息你想听哪个？

引言

如题，作为一个公司牛马，再上个月刚接触小龙虾 (OpenClaw)的时候，觉得挺厉害，tokens相对于codeX（openai）的便宜很多，毕竟公司大佬也在用codex来干活（openai综合一个月几百刀不在话下）。公司一个玩的不错的java全栈大佬（月薪4W以上的P8）告诉我，这玩意玩玩可以，别认真。

所以在缓慢的对话测试环境中，利用小龙虾成功开发了一个小玩具：frp-cms透传管理工具（有兴趣的可以看文章底部链接）。

如果不出意外，意外毕竟不期而至，那套FRP代码，已经开始走向不归路~，体积是越来越大~

第一版三四十兆

从第一版，已经跟走到了二十几版本，如下图：

只要能跑，千万别动

众所周知，只要代码能跑起来，别管里面有啥~，所以从原有的几M大小，发展到100M的巨物，如下图：

不是我吹，这玩意只是实现了frp（透传）网页版本配置，如此臃肿归功于文件包里的依赖，在通知AI减吧减吧一阵对话之后，增加修改端口功能后，文件更大了270MB：

一瞬间有点茫然，这都干了撒？再看一下README.md书如下：

再看下结构：

木有毛病啊，功能就如此简单，咋负优化呢？再看下FRP文件：

从github的FRP源服务端19MB，客户端16MB，没毛病啊，咋就负优化了？

原始FRP的程序34mb，剩余200多MB是优化产物。醉了，越整越大，不得已从新单开一个项目，把之前项目废弃。

原有跟单开后的区别如下：明显少了很多。

文件内的对比如下（spec文件不算，那个是生成的上个版本文件）：

奇怪的反向优化，我估计是历史文件叠加到文件里了，代码估计跟屎山一样了没细看。毕竟，原来的frp文件+配置文件，两个搞定，我这一堆都揉成快300m的大项目了。

好了，升成的FRP如下：链接，实在是不敢恭维

最后

完全依赖AI搭建的frp管理工具，实在是有待商榷，但是思路和以后的发展方向是没问题的，依托于小龙虾的java+Node.js开发Python，着实为难AI了（增加算力），截止目前，已经花了几千万的Tokens，不打算继续优化frp了，毕竟这玩意已经很成熟了，再怎么优化都是更臃肿，也徒增烦恼呢。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～