推荐语
借助Cursor实现全栈开发，AI辅助下高效完成红包签到页功能迭代，探索AI coding的实践边界。核心内容： 1. 需求拆解与AI生成方案的全流程实践 2. 前端动画与交互实现的关键技术点 3. AI辅助开发中的问题排查与经验总结
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
本文记录了借助Cursor完成红包签到页“单品返子”前端功能全栈交付的实践过程，涵盖需求拆解、AI生成方案与代码、弹窗动画（Lottie衔接+飞入效果）、Feeds插卡与去重、问题排查（预加载失效、回退刷新、状态管理等），强调AI辅助下需人工把控逻辑、样式和交互细节，并总结了日志定位、知识补缺等关键经验。
伴随着AI模型和工具能力的快速发展，AI coding正在不断的改变着我们日常的研发模式，同时也拓展了我们的技术边界。借助AI工具，可以快速的去了解一个代码库的业务逻辑和使用的技术栈，甚至基于此做迭代研发。本文主要从一个服务端的视角出发，使用AI工具（cursor）完成一次实际业务需求AI coding 的全栈交付实践，主要包含前端的交互逻辑、样式、动画等内容，服务端部分忽略。 主要目的是对AI coding过程中遇到的问题记录、总结和尝试，当然目前对前端的知识了解还比较浅薄，过程中如果有理解和使用上的偏差欢迎指正～核心功能：在红包签到首页对单品返子玩法作引导强化。
- 首页展示单品返子玩法商品POP，包括：弹窗前置动画、动画与POP过度、关闭弹窗收入二排动画等；
- 首页Feeds展示单品返子玩法商品卡片，包括：单商品卡片和多商品卡片两种样式。
AI coding，关键流程和日常研发流程类似，只是更多的是让AI去做具体的执行，而我们做好过程管理、决策和CR部分。一般我们会遵循以下流程：▐ STEP 1: 确定需求点、修改范围，编写需求描述
首页根据PRD和设计稿的要求，进行需求澄清，提炼需求点。再结合对工程了解程度，确定大致的方案和修改点，如果对需要修改的工程结构比较陌生，也可以借助cursor帮忙总结。
- 首页新增一个Pop（需要回调疲劳度、动画、Pop上需要展示商品）-只在老版本；
- 首页Feeds增加单品返商品插卡（可复用首页渠道插卡） - 新老版本都需要；
- 首页Feeds和单品返插卡商品双向去重 - 新老版本都需要。
涉及的前端工程：hbqd5（老版本主页）、qd（新版本主页）、order-withdraw-feeds（子玩法）。
分仓库建迭代、拉变更（不同业务的前端发布平台可能不同，具体可咨询对应前端同学），编写需求描述- task.md▐ STEP 2: 使用AI工具编写实现方案，并review方案
使用Cursor的plan模式，引用编写好的需求澄清文档，生成执行计划，并review，持续和AI交互迭代cursor会根据编写的执行计划中不确定的点给出待确认的问题，问题一般预设好了答案/是在不确定的会让你自己给答案，对预设答案的问题，还会标识推荐选项。按序号回复即可。
对编写的执行计划进行review，有任何觉得不可行的实现都可以进行修改（这里还没输出到solution.md....生成执行计划之后，若还有其他问题，可以继续确认再修改执行计划，直到方案满足要求前两步已完成执行方案生成，这里可以按照方案，让AI工具一次性完成前端需求的大体框架和内容▐ STEP 4: 自测并完善样式、动画、交互等功能
本地调试观察实现和交互稿的差异，直接通过视觉稿截图和AI交互，让其修改(这里可以使用D2C插件，生成样式，但当时比较头铁....经验手调：结合视觉交互稿中的布局、字体、尺寸，调整样式文件
动效和视觉确认后，拆分成两个部分，Pop前使用lottie动画播放，Pop后入口引导手搓一下。lottie动画简单来说，就是播一段素材就行，代码库中有现成的组件，比较难的点是，动画和静态素材之间的过渡。需要但前置动画播放完之后，正好衔接POP弹窗，动画的结束位置在POP弹窗的顶部。那这里就需要拆成两步，基础实现+微调。基础的功能实现交给AI：
pop弹窗和lottie动画的衔接处理：增加弹窗状态，通过lottie动画组件回调控制弹窗的隐藏和可见。
在onLoad中设置sleep，大致在动画播放完成时正好让弹窗可见，达到视觉效果。
动画结束位置、阴影表达：通过布局样式定位。
最外层样式itemsPop设置position：relative；动画和pop主体平级，动画样式设置position：absolute。
使用relative为子组件提供一个“锚点”
通过过程中和AI的不断交互，补充知识盲区，最终实现效果。
2. 飞入动画实现
原始诉求：点击或者关闭时，Pop需要缩放收入二排的单品返坑位。
具体实现：计算飞入动画的开始和结束位置，调用飞入动画函数，给定动画时间，复用已有的飞入动画组件。
AI实现过程遇到的问题（谁写的Bug谁修 
...AI修）：
Feeds商品插卡-签到首页Feeds和渠道卡片商品去重
Feeds去重服务端处理，但需要前端请求Feeds接口时带上已曝光的商品列表
签到首页：携带单品返现渠道卡片曝光商品
单品返渠道卡片：携带首页Feeds曝光商品
实现过程中遇到的问题与优化：
1. 预期的预加载的逻辑和实际不符
签到首页Feeds有预加载逻辑，在首次进入页面或者下拉刷新时，请求Feeds第一页时，会预加载第二页请求，通过Feeds插件配置实现，但实际表现是：当用户在首页加载完成后，滑动页面，加载完第二页后，才会加载单品返现插卡商品。
写让cursor确认下逻辑
看起来链路上一切都没问题，那就继续找吧
说是状态判断的问题：
修复了之后依旧有问题，继续找
重复请求的问题fix了，没解决滑动加载的问题
给出了修复方案，但依旧未解决，甚至罢工了。。。。
AI解决不了，那就“开发”看看...
看组件的实现逻辑，FeedsList -> hudong-common-feeds中的InfiniteList -> coinhub-react-infinite-list中waterfallList
hudong-common-feeds:
coinhub-react-infinite-list包：
找到Feeds初始化逻辑
让cursor帮忙确认这里逻辑：
到这里，大概明确了问题原因，CSR链路下，在预发环境下，受Feeds接口请求耗时的影响，预加载会失效，只有等待用户翻页，才会继续请求，SSR链路下，没问题。总结：组件的代码，首次请求和预加载的执行是同步的，但请求feeds接口是异步的，会存在预加载失败的问题，应该等待首次请求结束后，再执行预加载。
2. 首页Feeds直通车回退插卡，导致单品返插卡商品刷新
问题表现是：直通车回退时，商品卡片商品刷新。先和cursor交互，先定位问题，梳理逻辑，再解决问题。
再确认逻辑，确认其他优化：
数据请求失败，不清空数据，只清楚标识，允许重试
updateFeedsData事件：清空数据
问题总结：
3. 页面加载状态优化
因为首页需要商品去重，首页单品返渠道卡片Feeds的请求和主页Feeds存在时序，cursor一开始实现时，采用双状态：page1Loaded、page2Loaded来分别记录页面的加载状态，但综合来开，最后对状态的使用时机，单个状态即可满足要求，让AI帮忙优化。
加载单品返Feeds判断
紧急撤回...
给我急得...
都这么说了，蒜了蒜了
4. 单品渠道卡片区分单商品和多商品，组件优化
AI在实现时，是根据不同的渠道卡片不同的biztype，使用不同的css样式，来完成不同卡片样式的渲染，但服务端的经验告诉我们，应该抽出可复用的组件。让cursor抽取组件相同的样式文件、公共参数等，使得结构更加清晰。
验收过程，测试阶段，通过截图或者让视觉体验，发现问题，根据要求修改。
埋点，让PD梳理好埋点相关信息，让AI执行，去埋点平台验证。
总结
AI coding充满想象力，也不断拓展着技术的边界。从这个具体的业务需求实践去看，虽然遇到了各种各样的问题，但借助AI去梳理逻辑、定位问题，在不需要完备的知识体系背景下，也能最终解决问题，达到预期效果，但还是会走不少弯路。所以全栈交付的过程中，还是建议去多了解技术栈的基础知识，再搭配AI工具，会更加的游刃有余。
还有一个AI coding问题排查的心得：描述问题，让AI去增加日志埋点，然后直接把控制台的输出丢给他。
本文作者凌由，来自淘天集团-用户互动团队。团队支撑数亿级用户的互动业务（淘金币、芭芭农场、红包签到）的产品能力建设及演进，支持双十一、春节大促互动玩法的架构和开发，保障数亿权益的精准发放，通过多种互动形式提升用户规模和订单增长。我们正承担着捍卫电商主板块增长的重要使命，是阿里核心电商战场的参与者，用持续的技术创新来驱动阿里电商引擎的稳步前行。
粤ICP备14082021号
免费POC，
零成本试错
