AI驱动全端开发：淘宝信息流效率提升的探索

前言

为了避免滑动卡顿，购后信息流技术栈的选型原则是跟随宿主页面的技术栈，保持一致。

这就导致了许多问题，其中三个尤为明显：

1. 模板多做：因为首猜（首页猜你喜欢）流量比较大，信息流业务的新版卡片会在首猜先验证，效果好的话可以很快迁移到同样是DX实现的购后Native场景，但是购后Weex场景需要重新用React代码实现一遍；

2. 需求多做：购后信息流在多个端（Android/iOS/Weex/HarmonyOS/H5）都有实现，意味着一个需求至少3波人做4次；

3. 部署多次：为了性能和稳定性，Weex信息流目前以npm包的形式接入业务，所以每次上线新改动，都要给每个业务更新信息流组件版本，并且部署、监控。

上述问题中的“多”字，意味着繁琐的重复性工作，耗费了我们大量时间。尽管我们尝试了各种常规手段来提升效率，但效果有限。这时，AI的优势显现，它能够高效处理重复性任务，并7天24小时不间断运行。因此，我们转向AI，希望它能帮助我们大幅提升效率，解放我们的时间和精力。

我们从解决实际业务问题出发，经过长时间摸索实践，最终借助AI的能力提升了我们的工作效率。下面这张整体大图，结合了外部智库（甲子光年）对于研发效率的思考以及我们在购后信息流实践，后续将分为三个章节详细展开。

事务性工作替代：以代码生成解决模版多做为例

DX：全称DinamicX，目前是在淘宝乃至整个阿里集团内广泛使用的Native动态化方案，属于企业内部领域特定语言。

信息流内的商品卡片是信息流迭代最多的部分，其中又有很多都是样式层面的修改，比如推荐理由、标题、价格颜色和字体的调整。

因为首猜和订单列表都是使用Native开发的滚动容器加上DX渲染的卡片，所以DX开发的卡片模板可以迅速从首猜迁移到订单列表。但是想迁移到Weex就不行了，完全不一样的实现，需要自己一行一行从DX翻译成前端代码。

当时从DX迁移Weex的时候，我们要按照以下的规则进行迁移，主要是一些重复性的工作。信息流平均每个月都有来自商品和广告的新卡片，如果一个一个转换将会耗费大量的精力。

▐  如何利用AI进行转换

ChatGPT的交互范式大概是上下文 + Prompt = 输出，我们现在手上有上下文（结构化的DX代码），也有Prompt（DX转换的规则），那我们是不是就能很快获得输出呢？

▐  DX2Weex整体流程

于是我们自己总结了一份转换Prompt，并且针对生成结果不断调优，并结合RAG、快速预览、代码Copilot等方式来提高转换准确率和开发效率。

DX2Weex整体流程视频（如果时间不足，请看这个视频）：

（1）Prompt准备：按照DX到Weex代码规则编写Prompt提示词，这里包含布局、样式、各种设备适配等各类规则，并要求对生成的代码优化。Prompt提示词中的规则主要依靠内部开发者的开发经验总结，其他特定领域编程语言的转换同理（DSL），后续以文本形式的提示词输入至大模型中；

（2）RAG检索：对DX和Weex语言的内部文档及业务文档（目前主要是DX文档）进行数据处理，并存储至相关知识库中；在代码转换过程中，系统会利用矢量搜索技术对存储的数据进行挖掘，并为大模型提供上下文，解决step（1）中编写的Prompt提示词规则可能不全面、生成式AI“幻觉”等问题；

（3）代码生成：我们输入DX代码及Prompt，调用大模型API进行代码生成，最终大模型会按照转换规则和RAG检索的知识生成对应的目标编程语言，在此场景是Weex相关代码；在这里我们使用了VisualStudio Code编辑器自研插件——OneDay Copilot进行生成，在插件内置好Prompt，输入DX代码，调用大模型API，然后生成代码并复制，避免多个平台进行切换；（实测用claude模型更准确）

（4）预览：生成的代码在编辑器中直接预览效果，可以人工对其快速调试；因为Weex有个特性是一份代码既可以产出Weex二进制产物，也可以产出Web/H5产物，而我们对信息流做过H5适配（Weex/H5样式基本保持一致），所以我们可以直接在PC预览效果，避免每次改动都要扫码的问题（开发Weex的同学都懂）。

▐  代码实现规则工具 VS AI生成

与传统的自开发的代码转换工具相比，AI生成有以下优点：

在购后信息流效率提升度

1. 已通过DX2Weex生成8个以上模板（包含所有新增的卡片）;

2. 在模板开发中，布局、样式、大屏适配都是可以利用AI来协助优化，目前版本已经支持准确的布局和样式，可以帮助研发减少大半工作量，如一张新卡片的开发排期已由原先的4d缩减到2d以下。

能力增强：以AI辅助跨端开发解决需求多做为例

Weex 是一个可以使用现代化 Web 技术栈开发高性能跨端应用的框架。

Native 指使用特定平台的官方语言和工具（如 Objective-C 用于 iOS，Java 用于 Android）独立为每个平台编写应用，从而获得最佳的性能和用户体验。

前文提到了解决卡片样式重复开发的问题，但是信息流中的基础功能（请求、数据处理、性能优化等）同样存在重复开发的挑战。

跨端多做问题通常如何解决？业界惯用方法是利用React Native、Flutter、Weex等跨平台开发框架，让开发者可以编写一套代码，同时在iOS和安卓设备上运行。但是高效的同时会带来部分体验的损耗，所以这并不是万金油方法。

那最简单直接的方法是——同时开发Native代码，并利用AI助力跨端开发。

▐  如何利用AI进行跨端开发

随着生成式AI技术能力的提升，很多开发者开始尝试利用AI提升自身的效率及技能水平。有了LLM（大型语言模型）的加持，大大降低了Native开发的入门门槛。

• 智能搜索：很多以前不知道如何搜索的问题都能用自然语言描述出来并给出详细的解答。另外之前看文档只要有一步看不懂就要卡很久，而在LLM我们可以根据上下文进行追问。

• 代码补全：在实际编码过程中，还能借助Copilot工具进行代码生成和补全，减少编码的手动输入以及输入过程导致的错误。

因为当时安卓缺人，而且我也有一些基础，所以决定先从安卓入手。当然想要跨端开发不能仅靠AI，以下表格讲述了跨端开发的各个阶段及实践方法。

另外采访了一下组内同学（一年内从Android开发转为iOS开发）

以下是一些具体的经验和体会：

1. 用AI替代官方文档和Stack Overflow：在过去，频繁翻阅官方文档和 Stack Overflow 是一种常态。但是借助AI，你可以快速检索到自己想要的那部分知识，ChatGPT 能够针对你的疑惑，定制解答。

2. 用AI关联Android 和 iOS两个知识体系：面对Android和iOS两个不同的客户端框架，你很难找到一个同时精通 Android 和 iOS 的前辈为你答疑。但借助 ChatGPT，你可以这样问：“iOS 中是否有类似 Android SharedPreferences 的工具”。

3. 用AI生成代码：例如我经常这样提问题：“请将以下 Android 代码转换为 iOS 代码”或者“为代码中某个变量的读写操作添加读写锁”。 

4. 让AI 来做 CR 和 Debug：例如我经常这样提问题：“请帮我审查下面的 Objective-C 代码”或者“请规范以下代码的格式，但不要增加或删除注释”。

▐  三端开发代码量

在这几个月内，除了常规的Weex开发，我还开发了2000行以上的JAVA代码，以及50行以上OC代码，双端完成了8+需求和代码修复，具备能承接安卓端需求的能力。不过在客户端大佬面前这点代码量微不足道，只能说是入门。

期间做的一个安卓订单列表切Tab首屏性能优化的视频：

▐  跨端开发后的感想及收获

结论放在前面，实际编码的人日跟之前少不了多少，一个需求该写三遍还是得写三遍（iOS/Android/Weex），那么对于我来说有什么用呢，不就是把工作量转移到我身上，反而增加了我的工作量...

如果只谈代码量是片面的，因为其他层面的收获还是很大：

• 沟通成本：产品测试服务端与端开发的沟通成本减少了，由我这边总结路由，跨端后一个需求的工作量不能从3人日变成做1人日，但或许可以变成做2人日；

• 实现成本：客户端开发作为稀缺资源，像茅台酒开一瓶少一瓶，目前可以作为backup；另外有些功能互相参考从而得到最佳实现，例如Weex从客户端得到启发使用二刷来优化首屏体验以及风向标的插入逻辑，Native参考Weex的曝光实现逻辑来减少计算逻辑；

• 个人能力：对于Native开发和性能分析有更多的理解，增强前端与客户端结合的能力。性能分析和优化过程中能综合Native和前端的知识，如安卓/iOS/Weex的trace分析，通过Native能力帮助Weex预热和提前布局提高首屏性能，通过SurfaceView和TextureView切换提升Weex页面帧率性能等。

后续会更加深入安卓开发并开始iOS的学习开发，也希望能总结一些方法让其他同学参与，纸上得来终觉浅，绝知此事要躬行。

打造超级个体：以AI Agent解决部署多次为例

Weex开发构建产物可以远程下发，所以相比于Native有更高的动态性。在利用Weex高效迭代的同时，如何保证业务的稳定性至关重要。

为了能在灰度过程中，发现尚未达到阈值触发报警的新问题，避免进一步扩大影响。我们会在每一次业务更新信息流版本的灰度过程中进行监控，并在发布群内进行播报。每周需要投入1人日进行监控，避免业务因为信息流自身的变更受到影响。

随着越来越多的业务接入信息流，这种重复性、大量的人力监控不可持续，这时我们又想着借助AI的力量了。

AI Agent（人工智能代理）是一种能够感知环境、进行决策和执行动作的智能实体。不同于传统的人工智能， AI Agent 具备通过独立思考、调用工具去逐步完成给定目标的能力。

基于此，我们想进一步利用LLM分析推理功能和集团内强大的完善的系统开放API来打造一个专用于购后信息流发布稳定性的AI助理。

▐  AI助理流程

这里兼职服务端开发，开发工具为midway+serverless，部署了一个后端应用（waterfall-ai-services），负责各个系统串联，给AI Agent提供调用的工具以及调用AI Studio的能力。

1. 感知阶段：利用O2 Space研发平台的开放体系能力，在各应用（如支付成功、订单详情等）进行HTML、Weex等产物部署、灰度时通知到后端应用；

2. 输入处理：后端应用过滤部署应用、灰度量、操作人等有效信息，并最终把数据和目标输入至AI Agent，如“目前支付成功灰度50%，请帮我分析和监控当前稳定性情况”；

3. 思考阶段：AI Agent将上述目标分解，并规划顺序：确认应用的相关参数，查询相关数据，分析数据（同比、环比的波动情况）；

4. 工具调用：后端应用给AI Agent提供查询数据的工具，主要包括两部分，一是JS Error、白屏等Weex页面基础数据，二是卡片点击、卡片曝光等业务成交数据；

5. 决策阶段：生成最后的内容，确认哪些指标有风险，哪些指标没有风险，并最终通知到钉钉群和操作人。

▐  提示词工程

提示词工程（Prompt Engineering）是在自然语言处理（NLP）领域中，特别是在与大型语言模型（如GPT-3、GPT-4等）交互时，精心设计和优化输入文本以产生期望输出的一种技术和实践。在上述流程中，Prompt就是告诉信息流AI助理需要做什么，怎么做，和输出什么。以下为我们使用的Prompt的简单示例。

你是一个高级系统可靠性工程师（SRE），负责我们系统可靠、稳定、高效运行，现在业务正在灰度中；请你将根据不同业务获取输入工具的参数，可以调用以下工具获取数据；你的目标是分析目前有无风险，能否继续扩大灰度；
## 调用获取页面稳定性数据工具获取JS Error、白屏、降级、Crash数据：其中支付成功参数为paySuccess其中订单详情参数为orderDetail其中查看物流参数为logistics（注：后续接入新场景，直接这里加参数即可）
## 调用获取页面点击数据工具获取信息流卡片点击数据：其中支付成功参数为paySuccess其中订单详情参数为orderDetail其中查看物流参数为logistics
## 返回的格式1.根据工具查询结果进行环比、同比分析，并把结果通知到不同的群内和@发布人；2.注明目前应用的中文名和灰度量，JS Error需标明是10.XX.XX版本以上；3.先显示总结，总分结构，请将有风险的行用红色字体显示，无风险的行用绿色字体显示。

▐  使用AI助理后的收益

AI助理最大的优势就是可以获取多平台的监控数据并自行进行分析给出建议，无需配置复杂的规则。使用AI助理后，我们从每周投入1人日的监控减少至0.1人日——当AI Agent提示有风险时我们才去进一步排查。工具调用次数达150次，已帮助业务发现多个线上问题，业务接入助理的成本为0。

但是我们还远远没达到完全自动化的程度，还不是所谓的AI Agent，目前AI只是辅助，我觉得自动化和智能化程度还可以进一步提升：

• 增加输入数据的维度：如性能数据，防止迭代导致的性能劣化，如线上舆情，及时发现真实用户问题；

• 增加自动化操作：出现问题时，能自动执行回滚操作，及时止血。

以上是近一年手淘购后信息流在AI方面的学习探索，从需求、模板、部署等实际问题出发，分别通过代码检索、代码生成、AI Agent等方法提升我们的开发和协同效率。

1997年输给IBM公司的计算机程序“深蓝”（DeeperBlue）的最年轻国际象棋冠军加里·卡斯帕罗夫曾说过，一个好人加上一台机器，才是最佳组合。（A good human plus a machine is the best combination.）在与AlphaGo人机大战后的两个月里，李世石赢得了他所参加的每场比赛。人工智能带来的不仅仅是挑战，也是推动我们不断学习和进化的动力。它促使我们以新的视角来看待问题，以更高效的方式解决复杂的需求。在这个过程中，我们不仅提升了技术效率，也拓展了创新的边界。

在我们的生产链路中，还有很多重复性工作，比如每次发布前的回归测试，线上问题的抓包排查等等，我们将致力于提高各个流程的AI含量，最终目标是能做到AI为主，人工为辅。