对于 ChatGPT 如今大家应该都不陌生，经过这么长时间的「调戏」，相信大家应该都感受用 ChatGPT 「代替」搜索引擎的魅力，例如写周报、定位 Bug、翻译文档等等，而其中不乏一些玩的很「花」的场景
Android应用采用Java或Kotlin编写，iOS应用采用Objective-C和Swift编写，但当我们要去开发支持多端的应用，每一端都需要独立研发、测试，直到上线。为了解决多端独立开发的问题，跨端技术的方案备受青睐。 两轮跨端技术的尝试要追溯到2019年，当时整个互联网行业都在提效的大背景推动下开始各种跨端方案的尝试，而前身还是两轮助力车团队的两轮大前端也开始了跨端技术方案的探索。 当时可供选择的跨端方案有React Native方案、Weex方案，H5离线化方案以及当时较火的Flutter技术方案，而我们的目标是希望能够找到稳定、适合我们业务特性，并且可以继续进行深耕的技术方案进行调研和尝试。
在定点还车的模式下，用户还车需要在一些指定的区域里。此时用户停好车后在APP或小程序内点击“我要还车”，手机会将位置信息传输给后端，系统会判断是否在站点内，如在站点内会提示用户点击“确认关锁”，用户手动关闭车锁完成还车。
应急预案，是指在系统出现故障时，为了保障核心业务能够持续可用，而提前准备的指导手册。这个手册可以用来告诉我们：在遇到什么样的问题后，做什么样的操作能最大化地降低对业务的影响，将被动响应变为主动防御。
在组件化的浪潮下，公司引入多仓开发对工程架构进行解耦、跨业务技术能力复用，并辅以组件(混合)二进制化进行编译提速。不过随着工程规模增长、业务复杂度提升，多仓二进制的弊端日益凸显： 合码效率低下：多仓的引入使开发流程变复杂，最有代表性的合码环节一次合码涉及到主仓和多个组件，每个组件要跑 Pipeline 流程进行版本发布。因涉及到组件发布，从而引入了 MR 锁，进而导致吞吐量有限。如果某个组件失败，那么 MR 需要重新跑一遍流程。这种模式提升了 CI 复杂度，降低了合码效率（封板排队时间可达 6h+） 依赖管理衍生问题：稳定性差，多仓使环境依赖度变高，稳定性变成多个仓库稳定性的乘积。即使每个仓库成功率是 99.9%，每次 install 成功的概率也仅有 74%；版本溯源性差，项目通过依赖动态决议生成，无法做到 single source of truth。 代码的可视性和可控性降低：跨组件重构困难，全量静态检测无从入手，并且很难统一架构规范；本地开发体验差，工程代码可信度低，无法直接对代码进行开发调试，本地开发需要更多的工具和流程来保证代码的可视性和可控性。
