> 底层码农的工作成果都是像泥瓦匠一样只能赚一次钱的吗？理论上一个软件完成之后后续赚到的钱都是应该给程序员持续分红的，一个明明可以持续赚钱的东西变成了一次性像搬砖一样

泥瓦匠盖的房子可以租出去赚几十年钱，这几十年不会给泥瓦匠分红，和码农一样。
泥瓦匠通过劳动创造价值，和码农一样。

@wqbsd8 如果这个是仅用于这个客户公司内部使用的，可以『开源』——因为 GPL/LGPL 只要求提供源代码给软件用户，内部工具只提供代码给公司内部人员就可以了。

我们是基本类型一般不要有 null ，这样客户端可以定义 int 而不是 Integer 。其他类型包括 String 都当作可能为 null 来处理。
尽管我们用了 Kotlin ，但序列化框架还是 gson ，所以一般还是把几乎所有字段定义成可空的。

有个叫 TEXT INFINITY 的，但是只有标准的输入框中可以出选项，就是说，收到的微信消息不行，自己输入的可以。不是很符合要求。

我一年前反馈过，他说“我们这边记录一下”。
他们喜欢说数据说话，砍了这功能得掉多少数据，少多少人的年终奖啊。

我昨天试了下配置环境和打包，可以理解 OP 了，Python 打包是真的难。
pyinstaller 打包后无法运行，nuitka 打包是将源码和所有依赖编译到 C 语言然后重新编译，生成的中间文件超过 2GB 。
主要是这个项目里很多重量级的依赖，jieba 、paddle 、pyqt 等。

@Alicewish 配好 Github Actions 是可以每个 Commit 自动出包，自动发布到 release 的。至于『不测试就发布』的问题其实不大，只要编译通过就传到 Release 中，不能帮你修 bug 的用户说不准可以帮你测试，遇到问题也可以快速修复让他装下一个包。

你完全可以说没有维护这种打包脚本的精力和意愿，欢迎 PR 。

你的 README 对于开发者来说是足够的，但对于用户来说学习成本是比较高的。当然，你可以不为不愿意学习的人服务，他们可能不能给你的项目提出有效的 issue 和 pr ，对你的项目帮助不大。

---
但就我个人而言，我确实不倾向使用需要自己编译的开源软件。
1. 编译安装可能需要投入很多精力去折腾，我不是这门语言的开发者，编译安装可能不是一帆风顺的。
2. 编译安装需要我安装很多依赖库和环境，他们可能把我的电脑环境搞乱，而我不是开发者，可能自己折腾不好。例如，很多 Linux 发行版的系统工具很多是 Python 实现的，安装了指定版本的依赖后可能导致系统的工具挂掉。这点不只是 Python ，很多 C++项目要 make install 的，我是尽量不用的。
3. Python 的依赖环境对于非开发者可能比较容易迷惑，比如我之前很不理解安装了 B 软件的依赖后 A 软件会挂掉的现象。

相对于类型规范，我认为需求技术评审中明确服务端接口文档才是你们最需要的。只要文档中明确，那么定义成 0/1 还是 true/false 都能处理，遇到"yes"/"no"或"on"/"off"的评审不要通过。

直接用 s3/r2 的存储桶就好了，用官方的 cli 工具，反正是电脑用

@muyiluop 我有个想法，插件用自定义 classloader 加载，是否可以破坏双亲委派，给 System 类搞个 proxy

理论上也并不好做。（如果它存在设置项中）直接修改系统设置需要设备管理员权限；直接跳转，目标页面可能没有导出；通过无障碍操作模拟那是个搬砖体力活，且使用体验不一定很好。

360 没热度了，发点暴论，哗众取宠

推荐一本《穿越计算机的迷雾》