背景

现有的 APP 中广告 SDK 由于某些原因又被封的风险，所以需要紧急切换一个平台，从 AppLovin 切换到 TopOn。按照经验，需要做的事情是：
找出现有项目中原 SDK 的使用，然后删除，然后替换为新 SDK，然后重新编译，然后测试SDK的功能。整个流程预估要 3、4 天不过分吧。但是通过 AI 半天解决了，下面分享一下是如何实现的。

实现

第一步

首先分析问题，目标是切换广告 SDK，AppLovin 切换到 TopOn；所以第一步我让 AI：

分析下项目中涉及到AppLovin的代码，分析下是如何使用的，如果要切换为其他 SDK，给出步骤和建议

由于项目中使用 AppLovin 的激励视频、横幅、插屏这三类，使用的地方也散落在项目中各个地方，所以AI会给出必须改动的具体文件和内容。

AI 回复中的广告层抽象，让我想起来之前看 Flutter 架构时，看到过的Service 层封装，对外暴露统一的Service，Service的内部可以是本地 Mock 数据、数据库、网络请求数据，这样做的好处就是，业务调用的地方统一，不需要每次都修改调用的地方，只需要封装好内部实现，然后在 Service 层对外暴露即可。

然后让 AI 抽象并封装，但是注意不要直接修改引用的地方，因为不确定封装后的效果，直接修改所有范围太大。所以先让 AI 封装，封装完成后，找出一处具体业务使用的地方，替换为封装后的 Service，然后测试效果，然后没有问题，说明封装的 Service 正常，就可以批量替换其他的地方。

请抽象并封装广告层，但是不要替换项目中使用
请先修改xxx的签到广告，改为使用封装的广告层；其他使用广告 SDK的地方先不要修改；
请替换项目中其他使用广告 SDK的地方，统一替换为封装的广告层

这一步之后测试一下其他地方广告是否正常，如果正常，就说明广告层抽象封装已经完成，可以继续下一步，替换或者接入新的 SDK。

第二步

开始替换广告 SDK 为 TopOn，这时突然需求变了，说两个 SDK 都要接入。所以需要在保留 AppLovin 的情况下，接入 TopOn。

这时候就庆幸第一步做的是抽象封装，只需要在额外提供一个数据源并暴露同样的 Service 的方法即可。

然后接下来我考虑的是，Pod 同时接入AppLovin和TopOn是否会有冲突？同时接入两个SDK包是否会变大，变大多少？

带着这些问题，开始尝试接入TopOn，好消息是AppLovin和TopOn集成的广告平台都一致，所以通过 Pod 接入后，Pod 依赖的SDK都基本一致，只是 TopOn 依赖的版本低，而 AppLovin 依赖的版本高，所以先移除 Podlock，然后再Pod install，两个 SDK 就都接入了，编译之后没有报错，成功。

然后打个包，发现包大小减小了？？哈哈哈，没看错，是减小了，因为广告平台都一致，而且又降级了，所以包大小减小了。所以问题就不存在了。

接下来就是 TopOn 的使用，这一步就让 AI 来发挥，告诉 AI：

新的 SDK 打算使用 TopOn，请查看（https://help.toponad.net/cn/docs/ji-cheng ）使用方法，并给出注意事项，结合项目给出接入的方法的建议

等生成一个文档，查看后，确认没问题，就再告诉AI：

请按照上面的分析，通过 Service 接入 TopOn

这一步完成后，TopOn 的广告源也已经封装完成了，接下来的问题就是，如何区分某个广告是哪个广告平台的？

现在两个广告 SDK 都需要使用到，最终要使用哪个，是在调用的地方传入广告 ID 时，服务端告知。请在广告 Service 层实现根据广告 ID 区分 SDK 的逻辑。

然后 AI 就会确认服务端是如何告知，如果是新字段，则在 extroInfo 中通过传值来处理；如果不是新字段而是在广告 ID 上加前缀或者后缀则直接通过解析广告 ID 区分。

总结

上面一整套执行完，一下午就完成了从 AppLovin 切换到 TopOn 的需求，体验就是：使用 AI 确实提升了效率，但是其中也有一些问题，比如：新接入的 SDK，对比原来的 SDK，缺失了很多埋点逻辑等，需要人工排查发现问题，然后再通过 AI 来修复。

总得来说，使用 AI 需要注意：

  1. 把需求明确的告诉 AI，让 AI 理解需求，而不是让 AI 猜需求
  2. AI 理解后，让 AI 先分析步骤，生成文档；不要着急执行，确认文档没有问题，再执行；
  3. 使用 AI 后，需要人工进行验证和测试，确保结果符合预期
  4. 针对出现问题，反思思考；比如是 Prompt 不够详细，还是 AI 理解有误，有没有什么办法，下次如何改进，一步步优化和 AI 沟通的习惯和方式。