2个月月活突破1亿，增速碾压抖音，出道即封神的ChatGPT，现在怎么样了？ChatGPT它会干掉测试？
Posted 美团程序员
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2个月月活突破1亿，增速碾压抖音，出道即封神的ChatGPT，现在怎么样了？ChatGPT它会干掉测试？相关的知识，希望对你有一定的参考价值。
从互联网的普及到智能手机，都让广袤的世界触手而及，如今身在浪潮中的我们，已深知其力。
前阵子爆火的ChatGPT，不少人保持观望态度。现如今，国内关于ChatGPT的各大社群讨论，似乎沉寂了不少，现在怎么样了？
我们先来复盘，ChatGPT是一款人工智能聊天程序，去年11月底仓促推出，今年2月风靡全球，亮相即封神。ChatGPT系统代码总量超350G，只要跟ChatGPT概念沾点边，搭上点关系，股价全都在飙升。最初的访客是程序员、工程师、AI从业者，很快吸引了各路投资人，从早高峰写字楼电梯里讨论声到村里大爷们的饭后谈资。
使用感丝滑，但开始失控
ChatGPT能通过年薪18万美元工程师招聘考试，可以写论文，可以写代码并且直接用，一小时工作量，5秒完成。对文字工作者的冲击最为强烈，它能探讨哲学，拆解历史，证明数学定理，并不限语言和格式。它的能力取决于我们的想象力，它所展示的新世界已足够令人疯狂。
与ChatGPT的一问一答，已非提问和搜索，更像是一场跨物种的对话。最初是专业学术问题，后来变成菜谱、攻略，使用感非常丝滑，但是渐渐，故事开始失控，ChatGPT说“nineteen”中有12个字母、旗鱼是哺乳动物，数学上会出错，也无法给出最基础的烹饪建议......
一场资金与技术的持久战
ChatGPT瞬间爆火，监管上也并非“一棒子打死”，而且在政策上给予了积极的支持。《2022年北京人工智能产业发展白皮书》文件提出支持头部企业打造对标 ChatGPT的大模型，着力构建开源框架和通用大模型的应用生型。
以人工智能训练为例，它不仅需要消耗大量的算力，还需要投入顶级研究人员薪资等人力成本。百度、阿里、腾讯、京东、字节跳动等大企业纷纷展开深入研究，且获得了很多成果。毕竟，AI技术研发需要真正有实力的专家，创业公司显然更难一些，但他们只要脚踏实地做好ChatGPT相关的一个细分板块，也依然有机会跑出来。
世界终究要按照我们的规则
ChatGPT风尘仆仆从远东辗转而来，国内新一轮AI风潮涌动，所有大厂都称要推出自己的 ChatGPT。人们热衷讨论它的神奇，但没人注意这款超级工具背后的弊端。
微软时任总裁称：
“世界终究要按照我们的规则”。
ChatGPT基于全网的一些数据，很多数据来源于开源。ChatGPT首先肯定是一个效率提升，也会在各行各业很快开花结果，但如果要开拓一些新兴行业，它的数据非常少，初期可能泛化性比较差一些。所以我觉得这一块还是另外一个风口——车载测试更胜一筹。
GPT真的会取代测试？
我觉得不太可能，从我多年游戏测试的经验来讲，就更不可能了。游戏的功能，相比软件的功能，更加的复杂，不是说用一套统一的行业标准就能够确定的。下面从几个方面来分析人工测试要强于GPT的地方：
一、游戏战斗测试
战斗系统是整个游戏里面最复杂的功能了，战斗系统的最终形态并不会在设计之初就被完整的确定。它的研发过程相当于开发--体验--迭代这样一个反复的过程，直到大家拿在手上体验的时候，都觉得很nice的时候，才算大体完成。为什么没有说全部完成，因为等到玩家接触体验后，肯定会继续优化的。
二、模拟真实用户使用场景
一千个人的心中，有一千个哈姆雷特；一万个玩家中，就有几十个奇葩玩家，他们总是不按常理出牌，不按你设计引导去完成任务，所以游戏中出现的问题，也总是千奇百怪。游戏测试要根据不同玩家的类型和行为模式，不断去模拟玩家真实的场景，这些场景相当于未知的未知情况，针对未知的情况，貌似GPT也给不了你答案。
三、复杂的问题
一些复杂的问题，例如游戏玩法交互问题，游戏策略问题等。这些问题需要测试人员具有专业技能、创造力和判断力，而这些也是GPT不能马上响应和覆盖的。
四、项目的串联性
一名好的测试，是可以很好串联起整个研发线的，游戏开发很多都是走的敏捷模式，需求在研发第一版的时候，可能只是一个简单的初版，这就需要测试在理解需求的过程中，不断提出自己的疑问，不断跟策划进行激情碰撞，完了之后还要不断去提醒技术，在这些微妙的化学变化中，才可能顺利并且完整实现功能研发。这种主动性，创造性去解决问题的能力，也是GPT这种被动接受调教目前所完成不了的。
革命的前夜，永远哀声与圣歌并存
浪潮开启，博弈都遍布每个角落，ChatGPT月活用户破1亿人，人们惶恐因为它饭碗不保。ChatGPT可以替代咨询行业，替换传统客服，颠覆代码创作，ChatGPT可完美完成格式固定的公文写作、套路重复的公关写作，以及有迹可循的新闻写作，小说、剧作、漫画和动画脚本......
但全球最大广告集团WPP首席执行官说：
抢走你工作的从不是AI，而是其他掌握AI工具的人。
对此，你怎么看呢？我的老伙计
学点前沿AI不会的
测试行业新风口！
速领软件测试测试资料大合集！
抖音 iOS 工程架构演进
前言介绍
2016.09.26，抖音版本 1.0.0 上线，随后不断迭代优化和丰富产品，截止目前，抖音日活跃用户突破 6 亿，短短 4 年间，抖音从零爆发性增长。
快速的业务发展也对技术支撑提出了更高的要求，为了保障敏捷的业务开发，提升跨团队的协同合作效率，提高本地研发和 CI/CD 效率，抖音 iOS App 工程架构在不同的阶段进行了不同的技术方案的改进，满足合理的架构演化，同时又不影响正常的业务迭代速度。
抖音工程架构演进
架构演进的本质是为了提高研发效率，提高代码稳定性和保证代码质量。架构要解决的问题是如何组织代码。
合理的架构设计可以解决大型项目跨团队协作分工和多业务线并行开发的效率问题。抖音工程代码从一开始就采用了组件化思路，依赖管理工具是定制版的 Cocoapods。
以下动画介绍了抖音工程架构经历的四个阶段的演进过程：
图1：抖音项目工程架构演进
组件化在大型项目快速发展的过程中，要保证敏捷开发迭代的最大障碍就是快速膨胀的代码体积导致的编译效率问题，依赖关系复杂化问题，以及业务线代码冲突问题。
移动端项目可以类比后端项目中采用的微服务架构，要解决多业务线并行开发、并行测试问题，采用流水线式迭代开发，提高发版、集成、交付、提审、发布效率，结合分治思想技术选型上可以采用组件化的方案。
大部分小型项目，组件化仅仅做到代码分仓，使用 Cocoapods 的来管理组件依赖，就像抖音项目最初的工程形态。
但是对于几百号人、几十个业务线规模的大型项目，需要设计一套合理的组件分层架构，理清组件间依赖关系，需要 CI/CD 工具链支撑组件发版与集成，需要本地研发工具支撑本地代码同步、工程配置、依赖管理和效率优化。
流水线式迭代开发流水线（pipeline）技术是指在程序执行时多条指令重叠进行操作的一种准并行实现技术，该技术可以充分提高资源的利用率，同时缩短产品的研发周期。对于客户端项目，流水线技术能很大程度满足敏捷开发迭代的节奏。
抖音工程架构演进
阶段一：抖音原始工程架构（Original architecture of project）
抖音项目一开始是单体架构+Cocoapods，业务代码、工程配置、资源文件全部放在一个大业务仓库。由 Podfile 文件描述第三方仓库的依赖版本。
Podfile 拆分出版本依赖管理文件 Podfile.seer，由依赖管理平台进行各个版本的容器化管理，业务仓跟随宿主集成发版，打平依赖，解决版本依赖决议耗时问题。
大业务仓中的代码和资源被拆分到各个业务线的仓库下，由 podspec 文件描述内外依赖。业务线仓库增加 ModuleInterface subspec，存放对外接口，采用依赖注入方式实现接口隔离，初步建立接口层。
业务仓库之间规定只能依赖其他业务仓库的 ModuleInterface subspec，通过 lint 进行编译检查。
部分基础能力代码被拆分成基础仓库，跟第三方仓库一样独立发版。本地研发工具支持单仓开发和多仓开发，不参与代码修改的仓库通过二进制的方式进行链接。同时 CI 流程上也支持通过二进制打测试包，提高打包效率。
为了满足一个工程同时支持多个项目、部分业务线功能复用、部分业务线中台化发展的需求，我们把所有业务线抽象成独立的 Pod，所有业务 Pod 必须通过宿主的壳工程进行集成发版。
壳工程包含了项目依赖的 Pod 信息描述，同时还包括工程的配置、部分系统级别的资源文件、工程主入口代码。基于多份宿主壳工程，一份代码可以打包出抖音、抖音极速版等项目。
同时，基于宿主壳工程，一些业务线可以通过自动化同步生成自己的子壳工程，实现业务线自己的 Example 工程，进行独立开发，比如有语音通话的 Example 工程，有工具的 Example 工程，有直播的 Example 工程等等。
接口层顾名思义，只提供依赖的抽象接口，所有接口都是 protocol 协议声明。
接口层限制了所有其他依赖，类、枚举、 外部协议都采用前向声明，podspec 上只允许声明对 DI（依赖注入）框架的依赖。接口层满足封装、隔离和组合的原则。
采用 Cocoapods 本身自带的版本依赖决议进行版本分析会消耗大量的时间；
Podfile.lock 过于繁琐，可读性很差，难以解决 Podfile.lock 的冲突；
隐式依赖被动/不符合预期地升级，难以确定性地声明所有依赖，防止隐式依赖被升级；
依赖版本在 Podfile/Podfile.lock 重复声明，增加了解决冲突的成本；
Podfile.lock 参与依赖版本决议流程比较复杂，会出现不符合预期的情况。
采用单仓多组件后，每个业务线仓库支持添加 podspec 增加组件，实现更小粒度的二进制依赖。业务线仓库内划分业务实现层、业务接口层、服务层和基础层，都是通过集成方式发版。
新增的服务层主要存放公共的业务逻辑和通用服务，限制 UI，一是满足业务逻辑复用，二是满足子壳工程最小化二进制依赖。同时服务层的服务接口也达到隔离依赖传递的目的，在不同的宿主上，支持通过改变服务层实现替换后台能力或者底层能力。建立分层间的依赖准入规则，完善 lint 编译链接检查。
以下动画展示了业务实现层和服务实现允许依赖的分层：
每个业务仓从宿主同步工程配置构建子壳工程。增加 AWELaunchKit 为子壳工程提供运行时的基础能力。通过服务层提供业务间运行时共享的服务能力，满足代码复用和更小二进制依赖。
AWELaunchKit 框架为宿主和其他子壳工程提供了基础服务的依赖和初始化配置。同时提供了一套启动加载的 BootTasks 管理框架，部分业务涉及启动相关的逻辑可以在业务仓对应的服务层中实现，并通过 BootTasks 管理框架注册到启动加载器里面。
同时框架还提供了一套宿主 UI 入口和自定义入口框架。为了方便测试和调试，也整合了整套测试调试框架。
二进制污染
组件之间的依赖除了显式的依赖，还存在很多隐式依赖，代码层面，除了普通的接口依赖，还有宏依赖、枚举依赖、全局变量依赖以及内联函数等的依赖。单仓 lint 进行编译链接完备性检查并不能解决依赖变动对其他二进制的影响。
因此需要借助源码层面的依赖分析，判断当前组件的变更对其他依赖当前组件的二进制是否有影响，在 CI 流程中及时发现并拦截。否则错误的二进制发版，会直接导致整个 CI 研发流程和本地研发都受到影响。
编译优化
编译优化最高效的方式就是提高缓存的利用率。对于本地研发和 CI 流程，都涉及分布式编译缓存同步。同时通过编译参数优化、依赖优化、hmap 优化也能不同程度的提高编译效率
主干分支稳定性问题
对于多业务线并行开发，几百号人的业务开发团队，如果主干分支一旦出现问题，那么解决问题的时间就需要乘上几百倍。因此，需要从编译层面和运行层面都要有足够的机制去保证一个稳定的主干分支，才能保证业务侧的长期稳定性。
业务层的依赖耦合问题
大型项目动则千万行的代码，代码间的依赖关系是复杂的网状关系。需要基于代码的语法树模型，从语义中去分析不合理的依赖，并输出治理的方案。
我们内部自研了源码依赖关系分析平台用于依赖关系分析监控和代码治理，长期监控组件间的依赖度。同时，需要建立依赖健康度模型，从长期演进的角度去监控防止代码的劣化。
总结
大型项目的组件化工作是一个系统性工程。涉及工程架构的改造、CI/CD 研发工具链的支撑、本地研发工具链的支撑，业务架构的设计优化，需要从各个方面综合考虑成本和收益。
没有最好的架构，只有更好的架构，在架构演进的过程中，我们需要充分考虑架构的改动对业务的影响以及能给业务带来的收益。好的架构一定是能帮助业务节省时间，保证质量的。与此同时，我们在架构改进的过程中，要保证不能影响业务的正常迭代，所以向前兼容且避免大面积冲突也是很重要的事情。
组件化里面处处都有惊喜，比如一个小小的 hmap 优化，可以很大程度的减少编译耗时，比如一个二进制的压缩和解压的优化，可以很大程度减少 pod install 的整体耗时。
当然这里面也会有很多很棘手的问题，需要通过一些特殊的方案解决，比如针对分布式开发，由于阻塞式发版必然会导致一些不同分支存在冲突的代码发版后影响主干的稳定性。
由于文章篇幅有限，只能点到即止地介绍当前一些工作成果和思考，各个 Topic 还有一些新的方向在探索，如果你对 iOS 底层原理、架构设计、构建系统、自动化测试有深入了解，快来加入我们吧！
加入我们
我们是负责抖音客户端基础能力研发和新技术探索的团队。我们在工程/业务架构，研发工具，编译系统等方向深耕，支撑业务快速迭代的同时，保证超大规模团队的研发效能和工程质量。在性能/稳定性等方面不断探索，努力为全球数亿用户提供最极致的基础体验。
如果你对技术充满热情，欢迎加入抖音基础技术团队，让我们共建亿级全球化 App。目前我们在深圳、上海、北京、杭州、均有招聘需求。
内推可以联系邮箱：tech@bytedance.com，邮件标题：姓名-工作年限-抖音-基础技术-iOS/Android。或直接点击阅读原文查看部门所需岗位！
点击阅读原文，快来加入我们吧！
以上是关于2个月月活突破1亿，增速碾压抖音，出道即封神的ChatGPT，现在怎么样了？ChatGPT它会干掉测试？的主要内容，如果未能解决你的问题，请参考以下文章
出道即封神的ChatGPT，现在怎么样了？ChatGPT想干掉测试人员，做梦去吧