使用Qwen2.5-Max、DeepSeek、豆包等大模型独立开发社交软件靠谱？一手体验告诉你！及使用flutter独立开发ios社交软件app应用上线AppStores过程中一些思考的记录~

经历了几个月的开发时间，我的社交软件终于开发完毕了，但道阻且长，由于在国内要进行上线的话，icp edi这些都是必不可少的，我在开发之初没考虑这些问题，而对于这些资质的又是硬性要求，且公司的法人治理结构也很固定，注册资金也要百万以上，这些条件我都还没有协调好，所以什么时候能上线，我还没有准确的时间点，但是在整个应用的开发过程当中，还是有很多令我印象深刻的开发碎片，至令思来仍令我受益良多。

先说几个大语言模型时代大家都关心的问题，我有没有使用大模型？答案是肯定的，但是你如果我基于它们开发提速了吗？我觉得至少感觉不明显。

我说下我的想法，如果你单纯的让大语言模型，生成个规范组件的代码，它的确生成效率非常高，代码的可用性也很强，但是实际应用的开发，肯定不是单纯的组件堆叠就可以把灵活的app端功能或者后台功能开发出来，特别是当功能比较复杂，牵扯到的模拟，数据接口不只一个的时候，那么边界条件的调整需要你极其耐心的写大段的文字让大模型理解你表述的含义，甚至是配有例子更她，他可能才能勉强理解你的意思，特别是在国内对于上下文有严格限制的大背景下，基本上可以说国内没有一个大模型在编辑长代码的场景下是可用的，我整个开发过程中使用过国内的千问(Qwen2.5-Max)，那是二月份的时候，刚准备着手写app的时候，当时deepseek的惊艳表现使国内一众厂商看到模型训练方法的优化能取得比肩高算力的优异结果，尽管我一直怀疑deepseek的这种放卫星的方式在国内也见怪不怪了，肯定是有大量掺水的宣传在里面（后面几个月，我的这种认知的正确性也得到了验证，这里就不展开了），总之，当时试用了一下deepseek准备让它帮我为搭建一个小红书/抖音内容创作流程管理平台，在主干框架上它指明的方向我还是认可的，觉得确实颇有实战专家的味道在里面，但是用它解决过一个我写的golang爬虫的问题，数次喂问题给它，它都没有解决问题，导致我后面对于deepseek在编程的可靠性方面产生严重的怀疑，再加之我已经习惯了国内主流叙事水份过大的问题，后面我也很少使用deepseek了。由于对于deepseek编码层面的失望，加上当时阿里鼓吹的千问大模型不但借鉴了deepseek的训练方式，同时又有高算力平台及数据积累，当时宣传的推理能力超过deepseek R1吸引了我，于是当时把golang爬虫的一个问题丢给qwen，没想到它真的把问题解决了，马上对于qwen刮目相看并打算把它作为主力模型，但是明显我有点异想天开，虽然开始搭建flutter客户端，问题开始逐渐显现，首先是对于报错之类的文件，qwen会自动整合成文本文件进行上传，这种处理方式虽然让我感觉有点奇怪，但是如果能完整阅读报错日志，定位问题解决问题也无可厚非，但是基本上你用这种方式上报的日志，返回的答案基本上就是答非所问，加上qwen总是概括性的回答问题，应该是内部有算法或者规则限制，返回token的长度非常有限，所以，基本上如果你的问题复杂一点，它只会给你讲车轱辘话，对于解决问题没有丝毫的作用，加之，后面发版了新的，以为效果增强了，不想有的时候返回的结果掺杂了大量的不可读编码或者死循环输出结果，就是以非markdown的形式输出了视感非常差的死循环英文或者中文，导致电脑内存占用飙升，种种这些原因，最终我也放弃了qwen的使用。

最终我选择了grok，虽然grok也存在大量的问题，比如有的时候，非常简单的边界问题，你用文字表达的非常清楚，但是由于代码逻辑复杂，所以你丢给它，让它阅读的代码非常长，它会截断返回，或者是解决了一个问题，引入了新的问题，丢一长段日志给它，由于全是英文，导致它可能迅速遗忘你们沟通的上下文，它开始生成完全无关的代码等等，问题虽然很多，但是在你明确知道技术架构的前提下（你告诉grok第一步做什么，第二步做什么等等），它生成的代码还是相对可靠的，你只要review认真一点，把一些边界问题解决掉，代码能迅速达到可用状态，且它对于交互时你抛的日志的长度，不是十分敏感（不是十分敏感的意思就是没有超过它长度的上限，我没有查过grok的交互上限是多少，但是可以肯定至少要512k及以上的长度，你如果直接丢给它，它会直接告诉你太长，让你精简，如果你知道是多少，不妨在评论区告诉我），所以他确实可以帮你分析一些报错日志产生的原因，返回长度如果不超过2000行代码，在你非常强监督条件的设置之下，或者你教了它过长代码分次输出的方案以后，它能够有效输出，但是由于代码长度和模型输出上下文衔接的问题，有的时候你如果能给它参考代码，参考范式，它生成代码的可靠性会更高，但是如果没有明确的约束性文字或者参考模板，grok输出的代码会很蠢，比如说如果你用golang进行分层开发，那么api层和service要各司其职，如果你用flutter开发ios应用，不可避免要解决状态管理的问题，而状态管理，无非几套已经很成熟的实践方案，较基础的使用setState，再健壮一点的，使用provider，如果对于状态管理的敏感性要求更高，可能涉及到跨应用状态共享时provider的一些不必要的rebuild现象也会不断涌现，此时可以选用更健壮的RiverPod，它是完全独立于flutter之外的状态管理组件，支持你更深度的定制，这个方向（更精细更复杂的状态管理）继续往下挖的话，会得到BLoC(Business Logic Component),Redux(Store,Action,Reducer)等等方案，适合更庞大更复杂的应用。但是如果你不给它参考代码，它可能直接就在dart的screen或者page里面直接就调用后端接口了，而状态管理的东西就被它抛诸脑后了，所以，如果你想让大模型更好的服务于你的意志，按你的想法办法，你必须给出明确的参考，或者清晰的规则界定，但尽管如此，由于硅基文明的理解能力对于文本的思考可能与你的思考的共振性还有所出入，即使你界定的非常清晰，反而又可能会限制它发挥的空间，这里如果想大模型在编程领域能智慧如人，还有一些路途要走。

如果你问我真的让我开发提速的是哪个环节？我会告诉你，是一个非常完善的日志系统，非常重要，以我的视角来看，如果你开发一个应用，它没有复杂且健壮的后端做支持，那这个应用的复杂度应该是不高的（个人浅见），但凡涉及到复杂的app不可避免要涉及到多端交互（后端接口，消息中间件等），比如我现在的应用app交后接口的逻辑及社交用户推荐生成就是基于不同系统的，后端接口可能只是一个与app交互的行为，但是这个返回给app端的结果的生成可能是一个非常复杂参数运算的推荐系统来生成的，所以，日志的直观高效就显得尤其重要，如果还是用传统的nginx打日志，只记录个大概，对于请求响应没有高效的链路追踪，你是无法快速调试接口，无法快速验证想法的，因此，我的建议是如果你想提速自己的开发进度，一个强大且高效，直观且易用的日志系统是重中之重。

由于我的社交app除了社交软件线上常用功能之外，还涉及到大量的线下功能，并且线下功能还支持总部招商加盟，各级代理商分层入住，因此对于数据库的选型以及设计模式的巧妙应用，对于开发量的影响至关重要，同时，前后端的数据库使用规范，是做同步，还是做成接口，如果做同步是采用什么方式，做成接口，如果内部访问如何又做到高效，都有很多可以讨论的点，这些我都将在我的内部课程中进行分享，总之，整个过程中对于你的架构能力要求非常高。我前面搭建基础服务的过程比较快速，我后面之所以开发非常快，全依赖于我缺少什么，要搭一个什么样的服务出来，一个组件应该放在前台还是后台，怎么把服务集群串到一块，这些我都有非常长时间的技术积累，kubernetes那一套东西，docker那一套东西，正因为我对于它们太熟悉，所以我想搭个什么服务我都能迅速搭建起来并融入到现有系统中，我觉得我开发进展个人感觉相对较快的另外一个原因有在于此。

有时候，其实我也会有疑问？硅基文明如此强大，感觉自己积累的编程经验似乎都在迅速贬值，但是回头看一下，哪个行业又可以避免这种类似于科技革命般的冲击？几乎无一幸免，之前简单的重复性工作可以被取代，现在更多东西被取代，但是人类是有劣根性的，能用好工具的人自古至今似乎始终不多，特别是国人，别人开发出了火枪利炮，而作为华夏文明古国的我们，作为始作俑者，还囿于它狭隘的烟花使用功能之中，欣喜若狂，难以自拨！所以，先进工具出来的效果应该类十年前垃圾抖音没有出现之前，大家对于男女关系的认知处在低认知水平，但是由于这个垃圾平台出现之后，各种“老师”纷至沓来导致大家认知在集体提高，最终的效果就是大家阈值都提高了，大家都提高了，相对上来说，就是谁都没有提高，所以，能决定你走多远的，依然在于你本身是个什么样的人。绿玉杖在洪七公黄蓉手里就成了神兵力器，在普通人手里可能就是一根烧火棍，所以你想自己是谁？

说了这么多，还是想为团队招募些人的，由于我想把它做成婚恋的saas平台，对外提供全链路服务，而对于推荐系统的进一步完善是下一步的重点，如果你对此感兴趣，欢迎联系我,我的微信:cnguruyu。