文章概览
- 背景
- C端落地中遇到的难题
- 解决方法
- 总结
作者介绍：
赵苗，2019年7月加入去哪儿旅行，目前在大前端中心国内机票团队，主要负责机票后服务相关业务以及代码生成平台基建和日常维护工作。
杨翀，2023年加入去哪儿旅行，大前端中心FTC成员，目前在大前端国内机票团队，主要负责机票前端业务开发以及代码生成平台基建和日常维护工作。
一、背景
在前端开发领域，根据业务受众和交互逻辑的不同，通常划分为 B 端 与 C 端 两大领域。虽然两者都在追求研发效能的提升，但在 AI Coding 浪潮下，由于业务特性的鸿沟，其落地方案正走向截然不同的路径：
-
B 端开发：普遍依托成熟的 UI 组件库，UI 还原度较易得到保障，业务逻辑相对标准化，AI 仅需结合 “原型图 + 高级指令”，便能生成具备基础功能性的代码，研发流程相对顺畅；
-
C 端开发：一方面，UI 层面要求 100% 像素级还原，组件需由各业务线高度定制化开发，且要满足复杂布局设计与极端性能指标；另一方面，C 端直接面向海量用户，业务逻辑高度复杂，需应对多样化场景与频繁迭代，这些特性让 C 端成为 AI Coding 领域中极具攻克价值的 “深水区”。
我们的 C 端 AI 研发探索始于 UI 代码生成（D2C），先后开展两轮技术尝试，但均未实现理想效果：
-
过往纯 AI 模型尝试，“图片+提示词”直接给AI进行代码生成，生成的 UI 代码还原度差，无法满足像素级还原要求，与设计稿偏差明显，难以直接投入使用；
-
后续 “稿件解析 + 规则算法” 尝试，转而通过成熟的规则算法搭建基础体系，优先保障 UI 还原度。
两轮尝试后，C 端 AI 研发仍面临多重核心瓶颈：
-
代码可用性不足：规则算法生成的代码多为冗余 “div 海”，缺乏语义化标签，不符合组件化要求，需大量手动重构才能复用；
-
逻辑代码生成能力缺失：仅能覆盖 UI 代码生成，无法延伸至逻辑代码（交互、状态、路由等）生成，难以形成 “设计稿 + 需求文档” 到完整代码的闭环；
-
协同体验割裂：代码生成平台与 IDE 分离，开发人员需频繁切换，打断研发流程连贯性。
恰逢 LLM（大语言模型）技术持续成熟，我们针对性构建了一套覆盖 D2C 智能生成（聚焦 UI 代码生成还原度与可用性双重提升）、P2C 需求解析（聚焦逻辑代码生成效率与可执行性）、IDE 插件统一体验（聚焦全流程协同效率优化）的智能研发新模式，全面破解 C 端 AI 研发在 UI 生成、逻辑代码生成、协同流程三大环节的痛点，推动 C 端 AI 研发从 “单一功能实现” 向 “全链路高效协同 + 优质输出” 的升级。
二、C端落地中遇到的问题
1. D2C（设计到代码）核心问题：「像素级还原」与「代码语义化」的双重诉求难以兼顾
C 端对 D2C 的核心诉求是 “既要 100% 像素级还原设计细节，又要代码语义化、组件化可直接复用，可迭代性高”，但现有方案的短板恰好与这两个诉求形成对冲，导致难点突出：
-
像素级还原：要求精准复刻设计稿的尺寸、间距、颜色、层级等所有视觉细节，需极强的样式复刻稳定性，这只有规则算法能部分满足，但规则算法生成的代码无语义、无组件化结构，完全违背 “可直接复用” 诉求；
-
代码语义化：要求代码具备语义化标签、合理组件拆分、适配项目技术栈与规范，这是纯 AI 模型的优势方向，但纯 AI 模型缺乏精准的样式把控能力，无法达到 C 端要求的像素级还原标准；
D2C 的核心难点并非单一技术问题，而是 “视觉精准性” 与 “代码语义化” 的天然对冲：规则算法的优势是还原精准，却无复用价值；纯 AI 模型的优势是复用适配，却无还原精度。单一方案无法同时破解两个核心诉求，如何让 “像素级还原” 不牺牲代码规范，让 “高效复用” 不大幅降低还原标准，成为 D2C 落地的核心症结。
2. P2C （需求文档生成逻辑代码）的核心问题
在 D2C 已解决页面结构与 UI 还原后，我们继续推进将 PRD（需求文档）自动生成逻辑代码。在模型具备基础代码生成能力的前提下，这一阶段更大的挑战在于，如何持续地为其提供完整、稳定、可执行的需求输入。在真实业务环境中，PRD 往往分散在不同文档空间，由不同角色维护，存在访问范围受限、表达方式不统一等问题。当需求信息无法被完整获取与对齐时，逻辑生成天然会变得不稳定。
因此，需求文档生产逻辑代码遇到的核心问题，并不只是模型能不能生成代码，而是在现实组织约束下，如何把分散、不稳定的需求信息，整理成模型可以稳定执行的输入。
P2C 的关键难点
沿着需求 → 逻辑代码流程，主要存在三类核心阻塞：
-
PRD 既缺乏结构化表示，又受限于飞书文档权限体系
在实际环境中，PRD 内容分散在不同权限域的飞书文档中，且以自然语言与表格混合表达，模型在无法稳定获取和解析完整文档时，生成的逻辑代码容易出现条件、状态或依赖关系缺失。
-
PRD 体量和复杂度上升后，单次生成难以稳定覆盖全部逻辑
当页面数量、交互流程和业务规则增多时，模型容易出现理解偏差、上下文丢失或生成深度不一致的问题。
-
缺乏真实内部上下文，导致生成的 API 与 SDK 调用不可直接使用
在没有内部文档约束的情况下，模型往往依赖语义猜测生成接口和参数，代码表面合理但实际无法运行
3. 平台使用和代码编写流程割裂
-
原代码生成平台处于网页端，开发人员使用时会在平台与 IDE 之间进行切换，造成工作流程割裂。
三、解决方案
1. D2C ：规则算法与AI融合架构
基于 “规则算法强在精准、AI 模型强在意图” 的互补特性，我们摒弃了 “非此即彼” 的单一方案，探索出 “规则 + AI” 的融合架构：让规则算法发挥数据处理的精准优势，为 AI 提供标准化、高质量的输入；让 AI 模型承接意图理解的核心任务，生成语义化、组件化的优质代码，通过两者协同实现 “形神兼备” 的 D2C 落地效果。
1.1 高还原度保障：数据规则解析处理
Figma 原始 API 返回的 JSON 数据包含大量冗余字段（如混合模式、渲染边界等），结构复杂、嵌套层级深，直接输入 AI 会影响处理效率和生成质量。规则系统的核心任务就是对这些数据进行 “瘦身” 与 “优化”。
数据简化与清洗
-
冗余字段剔除：删除 Web 开发中极少使用的
blendMode、与核心信息重复的absoluteRenderBounds等约 60 个冗余字段，字段数量减少 75%； -
核心信息提炼：聚焦样式、结构、上下文等关键数据，将嵌套层级从最深 6 层精简至 3 层，大幅提升数据可读性。
关键信息转换与布局优化
将 Figma 专属数据格式转换为 AI 易理解、代码可直接使用的标准格式：
-
颜色值：从
{r: 0.22, g: 0.48, b: 1, a: 1}转换为十六进制#3878FF； -
样式属性：将
rectangleCornerRadii: [8,8,8,8]转化为 CSS 属性border-radius: 8px，阴影效果转化为标准box-shadow语法； -
布局信息：统一整合
padding、margin等布局属性，形成结构化的layout字段。
通过规则算法的精准数据处理，实现了 “原始数据 → 精简数据 → 标准化数据” 的转化：既保留了设计稿尺寸、间距、颜色、层级等所有核心视觉细节，又解决了原始数据格式不兼容、信息杂乱的问题，为后续 AI 生成代码提供了 “精准、干净、易解析” 的数据基础，直接保障了 UI 代码的像素级还原能力，同时提升了 AI 处理效率与生成代码的稳定性。
1.2 代码语义化保障：结合AI 模型进行代码生成
基于预处理后的高质量数据，我们通过以下五个环节，确保 AI 生成的代码 “好用、能用、符合规范”。
环节一：模板化提示词系统，标准化生成逻辑
-
预处理数据AI优化：基于我们第一步预处理后的数据使用AI进行进一步布局优化，结构调整，输出效果更好的FigmaJson，我们在进行规则算法计算的时候，有的因为设计稿设计的偏差、元素嵌套的问题，flex属性计算偏差的问题较多，比如一个模块设计，稍微左右间距不一致或者多套了一层壳子，就会flex属性处理为flex-start + padding，ai结合图片来优化就明显知道直接用flex：center 去掉padding就可以，还有定位元素的识别，也存在计算误差，包括说层级结构的多余不合理的地方，现在经过结合图片以及数据前置优化，这一类的问题就大大减少了。
-
分技术栈适配：覆盖 React、React Native、Taro、Shark 等框架，每个技术栈配置专属模板；
-
强约束规范：明确 95% 以上像素级还原要求，强制使用
<button>``<nav>等语义化标签，禁止 “div 海”； -
结构化设计：用 XML 标签定义角色、目标、工作流程，注入技术栈专属规则（如 React 用
className、RN用StyleSheet.create()）； -
质量保障：包含布局规范、单位转换（100px=1rem）、响应式适配、代码检查等强制要求。
环节二：全链路资源处理：实现代码直接复用
针对图片、Icon 等资源，构建从识别到引用的完整处理流程：
-
图片处理：自动识别设计稿图片→精准裁剪优化→CDN 上传→生成稳定访问链接；
-
Icon 处理：识别 Unicode 图标字符→生成专属字体文件→缓存去重→代码中自动注入
@font-face规则； -
资源引用替换：生成代码时直接替换为 CDN 链接，无需开发手动处理。
环节三：组件与 DesignToken 深度适配：让代码贴合设计系统规范
-
组件适配器：开发 Button、Checkbox、CustomAlert 等组件专属适配器，精准解析 Figma 组件的属性、状态（如禁用 / 悬停），映射为语义化组件代码；
-
Design Token 设计变量智能转化CSS属性：从 Figma 中同步颜色、字体、间距、圆角等设计变量，支持 DesignToken 版本管理与本地缓存。将这些设计变量自动转换为 CSS 变量，与基础样式智能合并（如边框宽度 + 颜色合并为
border属性），确保生成的代码完全遵循品牌设计规范，避免样式偏差。
环节四：工程化上下文注入：贴合项目实际需求
为避免生成的代码与项目规范脱节，我们支持注入工程化上下文信息：
-
项目技术栈配置：适配目标项目的框架版本、编码规范；
-
代码模板信息：同步 Git 仓库中的项目代码结构与命名约定；
-
组件库信息：识别项目依赖的组件库，确保生成的代码可直接对接现有组件资源。
通过这一机制，AI 生成的代码能够完全融入项目现有架构，无需额外调整即可落地使用。
环节五：AI 生成与后处理：提升代码质量与稳定性
-
模型选型：采用 Gemini Pro 2.5 模型，调用接口生成代码；
-
结果解析：提取 JSON 格式响应中的实际代码文件（realCodeFiles）与预览文件（previewCodeFiles）；
-
后处理优化：代码格式化、资源引用修正、Redis 缓存存储，同时提供 AI 生成失败的降级策略。
1.3 D2C 效果展示
生成效果展示
设计稿&生成效果
生成代码展示
代码按业务模块 + 复用性完成了组件拆分，符合前端组件化开发的最佳实践：
-
按功能边界拆分：将 “头部”“航班信息”“票价选项” 拆分为独立组件（
HeaderComponent/FlightInfoCard/FareOptionCard），既匹配设计稿的模块划分，也满足后续复用需求（比如FareOptionCard可复用于其他航班页）； -
数据与 UI 解耦：通过
fareOptionsData将票价数据与FareOptionCard组件分离，符合 “数据驱动视图” 的前端开发逻辑，后续修改票价规则只需调整数据，无需重构组件。 -
语义化结构清晰：用
FlightInfoCard等语义化组件名替代冗余标签，开发能直接理解模块功能； -
适配工程化流程：代码基于 React Native 规范编写，整合了
FlatList（列表渲染）、StyleSheet（样式管理）等框架原生能力，与实际研发流程无缝衔接，省去了 “规则生成→手动适配框架” 的中间环节。
总的来说，这段代码生成的核心价值是从 “规则翻译设计样式” 升级为 “理解设计意图并输出工程化代码”，既还原了设计稿的视觉表现，又契合前端开发的语义化、组件化需求，真正实现了 “形似 + 神似” 的落地效果。
Cursor体验对比
总结
通过 “规则 + AI” 的融合架构，我们的代码生成能力实现了根本性提升：
-
代码可用性飞跃： AI 模型能够综合分析节点的样式、层级、命名和周边上下文，更精准地推断出元素的语义角色，直接输出符合最佳实践的高质量、语义化的代码（如使用
<button>而非<div>），从冗余的 “div 海” 升级为语义化、结构清晰的组件化代码，可维护性大幅提升。 -
开发效率提升：生成的代码结构合理，减少 80% 以上的手动重构工作，同时覆盖多技术栈需求；
-
精确性与智能性的平衡： 规则系统确保数据提取的准确性，AI 模型提供意图理解和代码优化能力，两者协同实现了 “高还原度”与“优质代码” 的双重保障。
2. P2C：语义解析与知识增强的逻辑
在明确了阻塞 P2C 的核心矛盾后，我们并未尝试用单一策略一步解决所有问题，而是沿着难点拆解出的链路，从 输入 → 处理 → 生成 → 可执行 四个环节逐层补齐能力，使逻辑代码生成从能写真正走向能落地。
2.1 解决方案
2.1.1 前置文档解析：让 PRD 变成可被理解的输入
文档授权：由于飞书的文档有很多权限，不同的团队知识库有不同的权限，因此我们设计了一套飞书的权限授权系统。核心分为两个阶段：
-
阶段一：定时任务与通知 系统每周通过定时任务从PMO系统拉取数据，解析出文档链接和产品ID后，通过飞书机器人向相关产品发送按钮式交互提醒，等待授权确认。
-
阶段二：授权回调与数据处理 当产品点击同意授权后，触发回调函数启动流程，我们的飞书机器人将带着用户的权限去读取文档内容，提取并解析关键信息（背景、工时、详情等字段），最终将结构化数据持久化到数据库中。
表格序列化：在解析 PRD 时，我们不只是提取文本，而是针对“需求详情”等表格进行了 Key-Value 映射。
-
将表格的每一行视为一个对象。
-
将列名作为 Key，单元格内容作为 Value。
-
Map 格式的存储（存入数据库），完美保留了需求的结构化特征，为后续Agent 分析提供了高质量的上下文
格式与图片保留：除表格结构以外，其余内容也 保持完整信息。
-
文本格式（无序 / 有序列表、加粗、斜体、删除线等）会统一在解析阶段转换为 Markdown 语义结构存储，用于保留内容层次与语义关系，使模型能够基于原始格式推断逻辑。
-
图片会在解析阶段被下载并重新上传到内部服务，并在文档结构中以 Markdown 的格式展示。
最终效果：
{"title":"春运产品需求文档","background":"一、需求背景n为充分承接春运流量红利，提升各业务板块的销售与用户活跃度，特策划本次**平台级大促活动**,xxxxxxxxxxx","detail":[[["场景n **进入活动页-未登录**nn","demon n","说明n APP弹窗需更新背景图nn"],["场景n **网络异常/请求后端异常等活动兜底页面**nn","demon n","说明n 1. 【驾马闯关】主按钮显示“剩余？次”n 2. 点击【驾马闯关】、【我的奖品】、【次数+1】、【马上验证】按钮：n - 如果未登录弹窗登录弹窗。n - 如果网络异常或者请求后端接口失败提示"小驼开小差了，请稍后重试”nn"],["场景n **活动已结束**nn","demon nn","说明n xxxxxxxxxxx"]],[["状态n 初始nn","demon n","说明n 固定3个关卡，关卡奖励状态为待解锁nn"],["状态n 关卡进度nn","demon nn","说明n 1. 进度条计算逻辑：xxxxxxx 9. 关卡状态：待解锁、已解锁n其余为固定数据 - 点击【我知道了】关闭弹窗n"]]]}
2.1.2 智能分片与并发生成：解决长文档与复杂逻辑瓶颈
当面对长文档和复杂业务逻辑时，由于大模型的上下文窗口有限，如果直接将完整内容交给 AI 理解并输出，往往会丢失大量关键细节。尤其是在存在多种业务 case 的场景下，例如同一产品在不同条件下需要输出不同的文案，AI 在直接总结时很容易给出模糊、抽象的结论，比如简单地概括为“在不同情况下输出不同文案”，而无法保留具体差异和规则。
为了解决上下文受限和细节丢失的问题，我们引入了 多 Agent 并发架构，通过拆分、聚焦和协同处理复杂信息，确保关键规则和细节能够被完整理解和准确表达：
动态启动与语义分片：
系统根据 PRD 复杂度（如表格个数或字符数）动态决策是否启动多 Agent 模式。然后按语义（如“埋点”、“API”）或业务模块进行分片（Chunk）。
chunks示例：
{{"pages": [{{"page_name": "模块名称","page_description": "模块的简要描述","related_chunks": [1, 2],"main_functions": ["主要功能1", "主要功能2"]}}]}}
两阶段并发生成：
LLM 首先进行模块级路由，建立 Module -> Chunks 的映射。然后，系统并发启动多个 Sub Agent，每个 Agent 仅关注自己负责的页面数据，流式生成逻辑代码。
生成提示词示例：
相关内容：{page_content}**前端关注重点**：- 只关注前端交互和数据展示，业务逻辑由后端处理- 专注于该页面的用户交互、UI状态、页面跳转、数据展示- 所有数据来源统一表述为"后端返回"或"接口返回"**严格输出要求**：请严格按照以下结构输出，不要添加任何额外说明：# {page_name}## 用户交互操作[从用户进入该页面开始，描述完整的交互流程和操作]## 页面状态和UI更新[描述该页面的UI状态变化和更新逻辑]## 跳转和路由逻辑[描述从该页面的跳转逻辑和路由处理]## 埋点和实验（如有就展示，没有就不展示）[如有埋点或实验需求，描述该页面相关的实现]
2.1.3 知识库增强：解决 API 幻觉
背景：逻辑正确，但代码不可用
在未接入真实内部上下文之前，P2C 生成的逻辑代码普遍存在一个问题：看起来对，但用起来错。模型能够基于 PRD 描述生成基本合理的页面逻辑与交互流程，但在涉及内部 SDK 调用时，完全依赖语义猜测。例如在实现登录能力时，模型可能生成 auth.login()，而实际可用接口却是 user.login({...})。 这种偏差在参数层面更加明显：必填字段缺失、参数结构不符合规范，甚至引入只存在于公共 SDK 中的字段。最终结果是代码可读性尚可，但无法直接运行，开发仍需反复对照文档手动修正，严重拖慢了整体迭代效率。
为什么抛弃向量知识库RAG？
在尝试解决 API 幻觉问题时，我们抛弃了原有的向量知识库方式的RAG 方案，主要原因是向量知识库不适用于这一具体场景，主要原因包括：
-
PRD 的业务语义与 SDK 的技术结构关联度过低
PRD 中使用的是产品与业务语言，很难通过检索准确命中对应的 SDK 接口说明，容易产生误召回或召回不相关内容。
-
内部 SDK 体量有限，构建检索链路性价比不高
相比构建切片、向量化与召回流程，将完整 SDK 文档直接提供给模型的成本更低、实现更简单。
-
模型上下文能力已足以承载完整 SDK 文档
现代大模型在上下文管理与信息吸收能力上已显著提升，可以稳定理解整套 SDK 定义，而不会被信息量淹没。
在这一前提下，RAG 反而引入了额外复杂度，却无法从根本上解决 API 准确性问题。
最终方案：引入 MCP + 飞书知识库，提供真实可用上下文
针对模型SDK全靠猜的问题，我们最终选择引入 MCP + 飞书知识库，在代码生成前为模型提供真实、完整的内部 SDK 定义。 在实际实现中，我们根据不同语言和技术栈加载对应的内部文档，使模型在生成逻辑代码时，始终基于真实接口而非语义推断。
这样带来的变化非常直接：
-
模型调用的 API 源自真实文档，而非基于语料推断。
-
参数结构、字段命名与内部规范完全一致。
-
输出代码可直接运行，大幅降低人工校对成本。
2.2 生成代码效果
-
代码可执行性显著提升： 结合私有知识库后，模型使用的 API、参数结构、字段命名与内部文档完全一致，生成的代码可直接运行，大幅减少人工校对成本。
-
逻辑生成准确： AI 能基于我们提供的参数、使用示例及需求描述，生成正确的页面跳转函数以及使用内部 SDK 的埋点代码。
-
生成质量更稳定： 多 Agent 并发确保长文档也能逐块精细生成，输出深度保持一致。
生成效果示例：基于D2C生成的页面 再去结合需求文档的内容实现跳转功能：
3. 开发IDE插件，实现IDE内AI辅助和平台出码的无缝衔接
为了解决原平台和IDE开发之间的流程割裂问题，我们决定将平台放置在IDE中，以插件的形式提供服务，以实现流程的无缝衔接。
3.1 整体架构设计
在插件整体设计上，我们采取了如下架构：
-
物料层：准备出码所需的全部信息到本地，如UI设计稿解析成结构化信息、按模块拆分的需求文档。
-
规范层：自动匹配不同项目、不同框架所需的出码规范。
-
拓展能力层：下发的 MCP 能力，如图片内容读取、需求文档关键信息匹配、代码预览等等。
-
提示词编排层：针对不同框架匹配不同的代码出码模版，并进行物料和规范信息的注入。
-
交互层：用于选择设计稿及进行本地需求文档内容的二次修改，还支持用户进行自定义的规范配置，用户自定义的规范会被作为最高优先级的规范提示词来使用。
3.2 关键实现：流程化出码
实际的需求文档中，存在以下几个现象：
-
需求文档里常有不精确的 UI 描述（与设计稿冲突）。
-
部分需求逻辑依赖 UI 批注。
-
文档可能包含多个页面，而用户只需要生成其中一个页面，其他页面的内容其实并不需要。
为了避免UI信息和需求信息的相互干扰，不使用多余的需求信息占用上下文，实际在出码时，我们会分步完成，先生成UI代码，再在此基础上，匹配对应的需求内容，继续生成逻辑代码。
3.2.1 分步式出码流程控制：
我们使用初始prompt来进行流程控制，MCP来完成关键流程实现，处理方式大致如下：
这样，在初始的时候prompt中除了规范就只有流程以及UI相关的信息，在此基础上可以较好的生成UI代码，不受需求文档内容的干扰。
接着在后续的工具调用中，MCP读取需求文档，可在生成的UI代码产物基础上，通过文本和图片信息内容，找到最相近的需求内容进行逻辑代码的生成，避免有其余不必要的需求内容浪费我们宝贵的上下文。
那么IDE在调用MCP时，是如何得到本地插件中的需求文档内容的呢(初始的prompt中并没有描述到这些信息)。
3.2.2 IDE获取插件中的数据
为了让MCP tool能拿到插件中留存的信息，我们采用在插件中启动一个本地服务的方式，来处理MCP的调用。
这样，由于MCP服务为本地服务，本地服务运行在插件中，IDE便可以在调用MCP tool时，与插件共享同一上下文，获取并操作插件中的可用数据了。
3.2.3 插件向IDE chat框提交信息的trick
对于现存的一些IDE，大多数是不提供向chat聊天框设置信息的命令的。
但大多的IDE，一定会有fix the error的快捷指令：当IDE提示有错误时，选中目标错误，错误就会被发到chat聊天框：
fix the bug === {错误内容} ===
相应的，我们可以利用这一点，通过插件自行定义一个错误，并调用fix the error的快捷指令，那么被发送到chat聊天框的内容就可以变成这样：
fix the bug === Oh sorry, this is not an error. Here is the request： {你实际想给AI的prompt内容} ===
在完成信息的注入后，我们可以调用发送指令将需求发送给AI。依由这一点，插件与IDE整体的信息交互就完成了闭环。
四、总结
通过深度结合AI，我们解决了传统D2C在复杂UI布局还原上的难题，还完成了根据需求文档生成高质量逻辑代码的实践，开发人员coding的工作，从以往0到1的完整开发，变为了可基于ai生成产物，从0.7到1的部分开发，大大提升了开发效率。
展望未来，我们致力于建设具备“工程心智”的智能体，通过感知环境上下文，完成代码的效果审查、逻辑迭代以及问题修复，实现从0.7到1的coding自动化，让开发人员从coding中解放出来，在业务中发现可能的机会点，创造更多的业务价值。
本文转载自@去哪儿技术沙龙公众号
原文链接：https://mp.weixin.qq.com/s/W9U44p3-hwdl1FC5C4uAqw