lstz

@demonkhh #11 可以的，OP 不客气。与 uTools 不太一样的地方，可能在于工具箱是完全开源，而且更偏编程向的

@ccc00 猜测你工作很累，以至于下班了一点精力也没有。

如果精力足够，且有上进心的话，是不会止于公司那些破烂代码的，你要有一颗真正热爱编程的心

@username9527 好哒大佬，lafting755 ，欢迎交流

记住一万小时定律，如果你不熟悉一项技术，那就下班之后继续钻研。

也许有人吐槽说前端技术日新月异，但须知功不唐捐，你学到的东西始终会对你有帮助的。(当然，我很反对将一些复制粘贴的苦力活叫做学习，我们学要学骨子里的，不要学皮毛)

技术栈的话，主攻 react+electron ，也会用到 go 语言(不过不是主要的)

目前开发计划是借助常见开源项目，集成进去，并且做一个深层次的定制化和功能互联

有一个开源项目，要做下一代跨设备的 uTools ，集成 CyberChef 、文档百科、API 联调联试，笔记等功能，最重要是它还会提供时下最热门的 AI 对话聊天和智能生成。

不知道你是否感兴趣，目前是非盈利开源项目，但后期会提供商业版，如果感兴趣的话可以继续合作交流，以后盈利可以按 contract 来分成。
https://github.com/work7z/LafTools

关于市场调研方面，我以前做过一个初期工具箱，用户付费意愿也很高，但奈何当时架构太草率，加上推广不力，半死不活。这次 LafTools 正在调整了，计划会弄成一个社区。

尝试写开源项目，模仿到超越

hackernews 也很复古

@975779964 我使用场景可能和你不太一样，我只需要对单个文件进行分析，可以参考

https://github.com/work7z/LafTools/blob/dev/devtools/assistant/src/main.test.tsx

我觉得你可以想下，你具体需要 gpt 为你做什么。比如说增加新 API 文件，你就把 types 、示例、要求发给它。整个文件都发过去，感觉一来效率低(处理时间要很久)，二来 token 消耗也非常离谱，三来也没什么必要(我们作为工程师，写代码也只需要知道必要的几个文件就可以了，至于是哪些文件我觉得需要人工定义)