rag flow 这些挺好的呀，改动一下调大语言模型的部分，其他无脑用就行了。文档解析，如果 ragflow 不是很好，可以用 omniparser，串个 api，分分钟就搞好了。对了，大语言模型的部分，建议国内就使用 deepseek2，感觉质量非常不错。我们的内部问答已经切换到 deepseek2;

不要尝试微调开源模型，这个对于数据质量要求非常高，都已经用 rag 了，还可以看看现在微软开源的 graphrag，这个和上面的思路已经不一样了，是用知识图谱的方式结构化存储数据；

大模型本身是概率模型，输出的结果一致性不会那么高，看趋势吧

我的意思出包应该是在持续集成之后，你自动加上截屏，只是你要想办法提升截屏的稳定性吧。

这个在代码层面应该就能做些事儿，比如看看查查编译的多语言的 xml 或者 plist 文件，是否有超长的字符串。也能提前发现一些问题，编译前，增加个自动化脚本做些拦截；

到 ui 层面基本是看 app 的实现是否和 ui 设计是否一致了，如果用的 figma 这些，其实在 ui 设计阶段就能介入做些自动化的拦截，比如查查 ui 设计稿切换分辨率的预期是否合理，现在用 figma 都是能自动导出 ui 相关的代码直接在移动端使用，开发在这块的投入工作量应该不大才对。他们更多的是应该关注逻辑交互。

最后才到编译后产出的包，这个时候，像你说的，用不用 ui 自动化做自动截图就是自己自动化脚本提效的事情了。如果能前置到编译完就能立马出增量的 ui 功能截图，应该就能更加
体现你的价值

testflight 账户是个人开发者账号就可以了吧，现在 testflight 已经可以通过短链邀请，不需要提前将 apple id 加入到分发列表中了。

企业签名证书，好像是 199 美金。

看起来，开发描述的是 debug 模式下，直接把 app install 到测试手机。

如果想分发应用测试，建议，可以通过 enterprise 模式下的编译证书，打出 inhouse 包，然后把 inhouse 包上传到蒲公英或者其他分发平台，测试同学可以通过短链安装；

或者更加推荐的办法是，打出 appstore 模式的包，通过上传到 testflight，通过 testflight 应用分发测试，我们当前是通过这种模式来实现让内测同学安装版本，通过 testflight 的好处是，一方面可以提前把版本推送到 appstore ，在正式发布前，苹果可以提前审核一次，能过滤掉些简单问题，后面正式提审，只是选择一个版本提审商店即可，另一方面，testflight 也提供了崩溃和反馈的收集机制，可以方便我们量测测试同学，遇到的崩溃和问题情况。

一年只有一次机会重置开发者设备列表。其他阶段，只能说 disable 掉某些设备，但是仍然无法添加新的开发者设备。

互联网和初创公司应该蛮多。