架构师视角：GPTs Demo搭建后的思考（下）

由安德鲁小镇GPTs的PoC实录

引发的资深架构师的思考

实践之后，AI到底会对软件开发带来什么样的变化？

微软AI技术栈的观察 & 高级架构师的思考

03 Microsoft的AI技术布局

回到开头讲的 2016 那一篇文章吧，当时 .NET 开发人员 (越资深的体会越深刻，就是一路跟着 Microsoft 的技术路线走过来的那群人)，从一切都是 Microsoft 生态的环境 ( Windows, .NET Framework, COM+, SQL server, IIS server, Visual Studio, Office, Active Directory .. ), 突然间 .NET Core 横跨 Linux ( 而且效能还比 windows 好 ), Container ( 完全是 Linux 生态系的技术 ) 也突然席捲软件部署的方式, Microsoft 突然之间从 Steve Ballmer 年代的抨击 Open Source 是毒瘤, 到 Satya 开始讲 Microsoft Love Linux / Open Source ..

回顾历史，我长期都是走 Microsoft 技术路线讨生活的，我自己看到这样改变的时刻也不少，每隔 5 ~ 8 年都会碰到一波。例如:

• 2000, .com 年代:

Microsoft 追上了这波趋势, 当年的 ASP / IIS / COM / ASP.NET 技术跟工具就是那年代发展出来的)

• 2008, cloud / mobile 年代:

Microsoft 当时在这两个领域只是有跟上, 并不算领导厂商。Azure 表现中规中矩, mobile 则 …

• 2014, cloud first, mobile first 年代:

container 当道, 世界快速的往 cloud, open source, linux, container 发展, Microsoft 换了 CEO 后跟上了这股潮流, Azure 也开始走出自己的路线, .NET Core 也带领开发人员跳出传统的 Windows 体系, 开发工具除了 VS 之外也发展出 VS code, GitHub 也被 Microsoft 收编.. 从此 C# 开始跨入非 Windows 的领域, 直到今年 (2024) 就要超越 Java 了 ..

• 2023: GenAI 横空出世的年代:

Microsoft 投资 Open AI 有押对宝, Azure Open AI service 领先, Bing / Copilot 等服务都快速地推出, Semantic Kernel 开发框架也推出, Microsoft 瞬间在 AI 的技术，服务，工具，开发框架，生态系都跑在前面..

现在 (2024)，看来又是那样的时刻了，带来这些改变的是 AI 已经成熟到跨入主流技术了，看过去 2023 一年的发展就知道，这趋势不可逆。突然之间，我开始也能体会，Microsoft 在布一个什么样的局。如果你理解我在第二段阐述的变革，应该就能理解 Microsoft (以及其他公司) 到底做了什么准备来面对这种变革了:

一路以来，表面上看来 Microsoft 就是压对 Open AI 赚了一轮，不过事情没那么简单。有好长一段时间，作业系统 (OS) 的进步越来越无感了，我从 Windows 8 之后就开始没那么期待 OS 升级，Windows Server 也是如此 (最后有感升级是 2016, 当年为了部署 windows container)。其实手机 OS 也有类似的状况。

但是现在我开始期待 Windows 12 了 (如果真的叫这名字的话)，因为我期待会有更多的 AI 基础建设被放进 OS 内，我相信这会是非常重要的改变。我看懂 Microsoft AI 布局的三个关键是:

1. Azure Open AI Service

部署于云端的 AI 服务, 背后的关键就是各种模型，在云端上就是计算能力的表现，部署到 Edge 端就是模型优化技术能力的表现。两者都需要 AI 的模型发展与训练能力。

2. Copilot

部署于 OS ( 使用者端 ) 的使用者入口, 会演变成整个 OS / Device 的 controller。Copilot 的成功与否关键在是否由 OS 来主导，LLM 的运算资源是否充足 (不论用云端或是本地端) 以及背后的软硬体整合是否到位。

3. Semantic Kernel

会发展成未来 Application 主要的开发框架，决定了生态系，也决定了 LLM 能够协作的范围有多广。市场上另一个发展中的框架: LangChain，也是常被摆在一起比较的热门专案

这三者的关系则是紧密相连，互相发展加成。

其他还有些空缺，我猜应该会有对应的计划，只是现在还没看到。应用开发，一直都是 Microsoft 擅长的领域。从单一应用开发框架 Semantic Kernel 开始 ( SDK )，我相信一路往上，都会有对应的架构或是基础建设的.. 我的想法是:

1. AI Application Develop Framework (SDK):

Semantic Kernel, 已经 release 1.0 了

2. OS Support for AI Application (OS):

还没看到, 我猜 windows 12 会看得到端倪, 动作快的话今年应该就看得到了

3.Cloud AI Application Infrastructure (PaaS):

还没看到, 也没有预期时间, 我猜 Azure 之后应该会有一整套的 PaaS 可以使用

4. Cloud AI Service (SaaS):

已经看到类似的服务了 - Microsoft Copilot for Service

3.1 大语言模型服务

Microsoft 身为 Open AI 的大股东, 对 GPT 模型有最优先的掌握权。你想使用 GPT4 的模型，只有两个渠道，一个是买 Open AI 的 API 服务，另一个就是买 Azure AI Service … 这资源让 Microsoft 能优先于其他对手推出 AI 相关的应用 ( 就看 Microsoft 各种 Copilot, 在 2023 通通都出现了一样 )。

这些 LLM 的体量迟早会不断的缩小，小到足以在终端设备 (手机或是 PC) 端就能离线执行，同时终端设备的计算能力也能追上 LLM 的执行需要的话 (我就假定这发展 Microsoft 也会领先好了)，那么 Windows 应该又会开始变成所有人的首选了。回到前面我的 Demo, 最让我觉得惊喜的改革，是软件开始有能力了解使用者的 “意图” 了。想看看如果 LLM 已经能跑在本机端，应该不可能每个 APP 都装一套，而是整个作业系统会开始提供这样的服务。

从这个方向想，开始就能理解过去 Wintel 组合的模式又要出现了，只是组合可能会不同，但是 OS 有 LLM 的能力，而 PC 有对应的 NPU 也势在必行。未来的 Wintel 是否还是 Intel 我就不知道了，会是 AMD / Nvidia / 高通也都说不准。但是现在市场上开始喊 AI PC, 大概就是这走向了。

作业系统的发展，向来都是需要应用互相搭配的，接下来就来聊聊下一个: Copilot

3.2 辅助工具/引导工具（Copilot）

前面我做的 Demo, 是在 Chat GPT 的平台下，用 Custom GPT 能力，搭配上我自己开发的 API 组合出来的 Application. 使用者操作的应用，不是直接用我的 API 或是我的 APP，而是 Open AI 的 Chat GPT, 而 Microsoft 在发展的 Microsoft Copilot, 或是 GitHub Copilot, 其实都是走同样的路线。

如同现在没人在记网址了，要找网站就直接开 Search Engine… 当你对 Copilot 上瘾之后，你也开始会懒得自己去开 APP 来用了。你会用各种方式去告诉 Copilot 你想做什么，然后由 Copilot 替你决定要上网搜寻，或是转发 API，或是替你用某个 APP，或是给你什么资讯或建议.. Copilot 将会扮演整个设备的中控中心，代替你调度所有你设备本身的资源，应用，或是连上网使用云端的服务。

想象一下，如果像我 Demo 这样的应用，未来主流的服务都用同样的方式整合在 Chat GPT 上，会是什么样的光景? 想想就觉得可怕，因为现在看来已经是完全可行的技术了，只差整合而已。只是我不觉得 Open AI 的 Chat GPT 会变成以后大家必定使用的 “入口”，够格扮演这角色的还是作业系统大厂 Microsoft (Windows) / Apple ( iOS / MacOS ) / Google ( Android / ChromeOS ) 比较有机会。而现在看来领先的就是 Microsoft Windows + Copilot 最被看好

3.3**AI应用开发框架**最后一个，开发框架。我虽然对这个 安德鲁小舖 GPTs 的 Demo 感到惊艳，但是我不觉得未来的平台会是 Chat GPT, 只是 Chat GPT 门槛最低，是拿来做 PoC 的首选而已。在做这个 side project 时，我体会到一件事:

过去是以 UI 操作驱动整个应用的发展，因此会发展出 MVC 的开发框架。V (View) 就是对应 UI 的操作部分，而 M (Model) 则是对应到 View 需要对应的资料结构，C (Controller) 则是回应 UI 运作的逻辑与背后的流程。不光是 Microsoft, 各个主流的 Web 开发框架大致上都不脱离这模式。

到了 AI 的时代，有了 LLM 的加持，UI 不再是唯一的操作方式，直接或间接透过自然语言开始是另一条可能的方式。而操作与逻辑的绑定关系，也变得更灵活 (相对的就是更不明确)。想看看，如果 Model 都已经变成一个一个的 Prompt, Controller 还能知道收到 Prompt 后该怎么回应吗? 该写档案? 还是该发出 email? 还是该执行交易?

因此，要发挥 LLM 的威力，充分整合到你的应用内，你需要一个能透过对话方式驱动整个应用的发展框架。我之前在这门线上课程，看到这张图，我觉得很贴切:

LLM 扮演了 Controller 的角色，或是讲得更精准一点，Orchestration 会更贴切。他接收各种来源的自然语言要求，了解之后会判断该如何回应。LLM 需要决定该转发什么样的要求给后端的服务 (不论是 search engine, 或是 api, 或是 access database) 等等。LLM 扮演了 “理解语言背后的意图”，翻译成精确的指令，转发 API 给其他系统。并且把得到的结果再度翻译成自然语言，或是需要再次转发成后续的指令。LLM 是 “精确运算” 与 “模糊的语意分析” 之间的桥梁，这是传统的应用最难突破的环节，也是融合 AI 应用的核心。

未来软件开发，会是围绕着 LLM 为核心，在外围搭建 UI, 服务, 靠 LLM 统控操作流程 (orchestration), 探究为何 LLM 做得到? 它就是专精在自然语言的处理，只是 Chat GPT 很巧妙地运用它来整合语言对谈与 API 而已。

我在设计 安德鲁小舖 GPT 的过程中，最关键的两件事:

• 开发能被 GPTs 使用的 API:

并非阿猫阿狗写的 API 都可以直接丢上来, 多少还是有些差别的。主要就是认证方式要标准化 ( APIKEY or OAuth)，并且提供 swagger 定义档, 喂给 GPTs 设定，让他知道我有哪些 API 任他使用

• 善用 Prompt:

告诉 GPTs 该怎么回应使用者的询问，而 API 本身也用自然语言告诉 GPTs 他是干嘛用的，让 LLM 能理解何时该呼叫他 (就是在 API swagger 的 description, 就是给 LLM 的 Prompt)

这两者打通之后，LLM 就摇身一变，变成控制中心了，也因此，未来的 APP 或是 Service, 应该都是为了成为 LLM 的助手而生的。所以，应用都会没落了吗? 不会的，他还是会存在，但是超大型的应用应该会越来越少，超复杂的多步骤流程也会逐渐消失，UX 的改善大部分都会落在 LLM 身上，而 APP 与各自的 UI 则会专注在更精确范围内的应用了，例如填表单，或是特定的触控操作等等。

很明显的，MVC 不再适合处理这样特性的应用了，AI 相关的应用开发必须要有更合用的开发框架。如果把这张图，浓缩成单机版本，范围限定在单一 AI 相关的应用开发框架的话，那目前的最佳选择，就是我一直提到的 Microsoft Semantic Kernel 了。如果不是限定于 Microsoft Solution (C#), 也有另一套 Python 走向的套件: LangChain。挑哪套都没关系，重要的是要看懂框架的设计，是要引导开发人员正确地使用 LLM

同时，我也预期 (虽然现在还没看到)，就像 MVC ( Model / View / Controller ) 进化到 SK ( Semantic Kernel ) 一般，Windows 势必也会有作业系统层级的架构 (例如软件安装就会注册支援的行为到 Microsoft Copilot，类似当年的 COM+)，Azure 也会有分散式架构的版本出现 (能整合 LLM 的 API Management ?)。架构上的演化，势必会有 Application 开发框架层级, 作业系统层级, 开发者服务层级 (PaaS)，应用软件层级 (SaaS) 对应的 solution..

• 开发者层级: Semantic Kernel / Lang Chain
• 作业系统层级: 还没看到规范出现
• 服务基础建设 ( PaaS ): 还没看到规范，目前看到 Open AI API 已经有类似架构出现，但是还未成标准，也未见 PaaS 厂商出来整合
• 应用系统层级 ( SaaS ): 已有看到 Microsoft 推出接近定位的服务: Microsoft Copilot for Service .

这些服务的发展，我也不知道最终会长什么样子，不过看懂 AI 会带来什么改变后，很明显这边的缺口迟早会有对应的东西进来填补。如果你看清楚趋势，就可以预先构想 & 持续关注这些服务的发展，尽早做好准备来面对了。

3.4 整合三者的应用模式

几个月前，我在思考应用该怎么跟 LLM 有效的结合? 一个是要有明确的规格跟流程，另一个都是用很模糊的输入 (对 code 而言，prompt 只是 string, 所有 input 都是 string, 跟全部是 object 其实没两样)，那么两者的处理协作方式到底该是什么样貌? 研究了 GPTs, 刚好也看到 Microsoft Semantic Kernel, 我发现这就是以后的应用分层架构了..

看懂 Semantic Kernel 的这两张图就够了，这张讲的是 AI infrastructure / models 与 Plugins / Copilot 之间的协作，Semantic Kernel 就是扮演把这些全部串在一起的框架。如果 安德鲁小舖 GPTs 我用 Semantic Kernel 改写成单机版，那么我的 API 就是图上的 Plugins 了，我不管用什么技术刻出来的 UI，就是对等 Copilot 的位置了。而不论我是跑本机板的 LLM，或是使用 cloud 的 AI service, 我用 connector 串联它们，就是底下的 foundation models / AI infrastructure 了

从另一个角度来看，这张图更清楚。Model 只是按照 prompt 帮你算该回应什么内容，对话过程是 application 应该自己维护的，在 Semantic Kernel 架构中的 Memory 就是指能记住对话过程的 “记忆”，Semantic Kernel 会协调 Memory / Model / Plugins, 自己处理这些元件之间的协作。

目前 Semantic Kernel 只是为单一应用开发而设计的框架，但是事实上规模放大到分散式的高度来看，即使是 Open AI 的 Chat GPT， GPTs 的运作机制也类似，只是它们的范围是跨网络的。真正落实他们的技术跟协定可能不同，但是抽象化的观念应该都是一致的。

Semantic Kernal 再深入的技术细节，我就不在这多做介绍了，基本上他就是把能善用 LLM 的软件开发方式抽象化，变成一个能抽换扩充的机制。目前，Semantic Kernel 看到的还是在 Application 内的 AI 应用开发框架，作业系统层级的通讯协定还没看到，不过我猜也快了，如果真的有 windows 12, 应该可以看到一些蛛丝马迹。

接下来 (如果搞得定的话)，我打算把 安德鲁小舖 GPTs 的应用，用 Semantic Kernel 的架构改写一次，到时再来分享技术细节。这边各位先有概念就好，就像 MVC 架构一般，LLM 加持驱动的应用，他的基本架构就是 Semantic Kernel 描述的这样。你思考你的应用要包含 LLM 处理能力时，务必要先了解这开发框架背后的精神。

讲到这边，我开始能串起来了。应用只要用 Semantic Kernel 开发, 甚至变成 OS 内建的服务，安装软件会变成安装 Plugins / Planner, 而 AI OS / AI PC 则提供了足够的 LLM 运算能力，让你的 Application 能充分使用这些 AI 资源；最后 Copilot 变成作业系统的标准 (主要) 操作介面，统合起本地端与云端的各种资源…

04 架构师、资深开发该怎么看待AI？

架构师必须引领你的团队，将系统逐步改造成 AI Ready 的应用

回到个人，看懂了是一回事，那么你 (包含我) 自己该怎么面对? 该做什么准备? 我自己的看法是:

基本上躲不掉了，就去面对吧! 同样的以我这次的 Demo 来说，我看到了几点，尤其是越资深的人员，对软件的设计越有话语权掌控权的人越该注意.. 你必须好好地思考 LLM 该用在什么地方。

以我这次的 PoC 案例，我先有了构想之后，我的顺序是开发出 API，做出最基本可以动的模块，就尽快设定 GPTs 完成第一版上线测试了。过程中第一个难题就是 API 开发得不够好，不够直觉 (简单地说就是不符合标准或是商业模型)。当 API 无法让 LLM 望文生义，你就必须用更多的 Prompt 引导他怎么用 API。然而努力下来，最有效率的方式还是让你的 API 变得更合理点才是正途，最后调对 API 设计之后，我的这些 “修正用” 的 Prompt 都删掉了，运作的比原本的还好..

另一个角度，相较于开发人员写的程式码，执行成本 LLM 还是非常贵的。你应该用 AI 省开发时间，但是要把 AI 用在 run time, 就必须用在刀口上，不要什么都丢给 AI 来做，举例来说以后你不提供浏览商品加入购物车的网站，只提供对话方式交易就是个不明智的选择。

因此，我归纳成这几点我认为重要的观点:

4.1 分清楚LLM/API的边界

架构师必须搞清楚，哪些应用要用 “计算” 来解决，哪些应用要用 “意图” 来解决?

LLM 很有弹性，能理解语意，但运算成本很高；相对写 code 必须有明确规格，难以理解语意，运算成本相较 LLM 非常低。试想 你写一行 code 算 1 + 1 = ?, 可能是几个 CPU 指令就完成的事情，你问 Chat GPT 1+1=？ 不知道要砍掉多少棵树才算得出来..

以我的 demo 为例，请 GPTs 替我评估预算内该怎么买最好，过程中我就吃了不少苦头，即使用上 GPT4, 我仍然有一定的机率会碰到 GPTs 回给我的答案不是最好的答案，但是我跟他抱怨后他重算一次就对了 (传说中的 AI 也会偷懒?)，我明明只是抱怨，没有教他啊，可见他本来就会，只是没有做出我要的选择而已…

以这案例，如果预算评估，对你是很重要的任务，必须精准执行，无法忍受 LLM 有一定的出错机率的话，你就该考虑这部分不要依赖 AI，该自己写 API 让 AI 呼叫才对。这些判断，需要有经验的人来操刀，架构师是合适的角色，要能看懂这些分界与区别，你才能做出正确的判断。

以 “计算” 为主的任务，像是交易，必须精准有效率正确地进行，应该维持传统的方式测试开发。你只要顾好他能不能做到 AI Friendly 就够了。

以 “意图” 达成为主的任务，像是 Copilot，必须尽可能地找到各种解决方案，应该维持以 LLM 为核心尝试找出各种可能的建议，这种就需要 AI 来辅助。

而架构师，必须要有全局观，要有能力替你的公司或是团队，做出正确的判断与决定。

4.2 API的设计必须精准合理

架构师必须清楚，API 该如何对应领域的问题，用统一并且精准的设计开放服务介面，挂上 LLM 的扩充机制

有听过我 .NET Conf 2023 的演讲，我的主题就是这个。只是在做这个 demo 之前，我只能说好的 API 有很多好处，但是我还无法讲出有哪些状况下，这些是绝对必要的? 直到我做了这个 demo… 未来的 API 会越来越重要，服务不再是 UI first, 而是 API First…

因为，挂上 LLM 后的 API ( Plugins ), 呼叫你 API 的不再是其他开发者了, 会变成 AI 来呼叫你的 API。你已经无法 “预测” 或是 “约束” 对方该怎么呼叫。这时你只剩两条路可以选择，一个是把你的 API 设计的合情合理，完全符合现实世界的运作逻辑 (就是我常讲的 OOP 精神: 模拟世界 加以处理)，你只要用 Prompt 就足以交代 AI 该怎么使用 API。另一个就是把你的 API 做到逻辑无懈可击，滴水不漏。不论 AI 用什么顺序呼叫，传递什么参数给你，都不会发生意料之外的结果。这个非常考验严谨的设计，我曾在 API First 不断强调 “有限” 状态机的重要性，就是预防这种错误。因为状态机的变化是 “有限” 的，你才能在这范围内精准地控制各种行为，不会暴走，这样的 API 设计才是 AI Friend 的设计。

AI 会解决很多过去 UI / UX 难解的问题，这会有两个效应，一个是原本由 UI / BL（BusinessLogic） 负责的体验改善，会大幅往 LLM 靠拢偏移。而抽走这些流程的处理，你的 API 就只会剩下最核心最关键的 Domain API 了。就拿我这次示范的 “安德鲁小铺 GPTs” 当例子，我的 API 真的精简到不能再精简了，精简到你拿掉任何一个 API，就连最基本的成立订单都做不到。

有哪些是原本该提供的 API，但是因为有了 LLM 辅助可以不需要再提供的? 最明显的就是 BL 层，以案例来说如果需求有这么一条，要按照客户预算规划采购内容的话，一定会有一组 API 对应这些需求。但是在这示范案例中，LLM 的能力完全可以覆盖这部分。就眼前来看，已知的需求可以不需要再开发了，就未来来看，也许有更多你目前想象不到的需求，LLM 也可以有足够能力替你处理。唯独最关键的是: 你的核心购物 API 一定要能精准确实可靠得处理好结账的需求。

这就回到我一直在强调的 Domain API Design，API First，API 必须精准对应 Business Model 这些议题要探讨的: 要开发正确的 API。因此，API 不再是能动就好，而是要精确，可靠，合理，做到 AI Friendly，才是能在未来世界有竞争力的服务。OOP，DDD 等等领域相关的设计，以及开发的基础工程能力，会越来越重要。因为你没掌握这些设计原则，你几乎不可能设计出 AI Friendly 的 API 规格的。

4.3 UI应该以Task为单位拆解

架构师 / 产品负责人 必须清楚，UI 该如何对应领域的问题，拆解并且正确的描述，挂上 Copilot 的扩充机制

这次的 demo, 也让我体会到这件事。这个 side project 我花了三个礼拜，但是有两个礼拜都卡在 “我赌气不想做 OAuth…” XDDD

因为我原本的 API 就有做简单的认证机制，有 Login, 要给账号密码才会给你 Access Token, 然后其他 API 有必要参数，必须提供能通过验证的 Access Token 才能呼叫。结果我想，我就 Prompt 多做补充说明，让 GPTs 弄懂就好了…

结果全然不是这么回事，不合理的 UI 流程跟 API 设计，会大大阻碍 AI 的理解，认证授权这类行为，就是属于需要精确执行的，你让 LLM 来负责这环节就是不智之举，我花了两个礼拜尝试各种方案要搞定他 (很长的故事，以后有机会另外写文章来聊聊)，最后都是失败收场。

最后，我花了一天，自己刻了个符合 OAuth2 的介面出来，再修修补补一个晚上就搞定了。你看我的 安德鲁小舖 GPTs, 版本已经来到 v5.0.0, 大概就知道我经历多少失败了 XDD, 不过, 这些门槛都不是有多困难的技术要克服, 而是你要想清楚该怎么善用 AI 而已.. 想清楚 Copilot 或是 Chat GPT 掌控 LLM 的主要操作介面，充分配合发挥它的威力来设计你的软件服务跟 UI，将会是下个时代的重要课题。

4.4 挑选正确的软件开发框架

架构师必须挑选合适的开发框架，并且一一把系统的各个元件摆在框架上正确的位置上。

第四个，是搞懂 AI 时代的开发框架，目前我看到最具代表性的就是 Microsoft Semantic Kernel. 当然就像 MVC, 是抽象的架构, 而 ASP.NET Core MVC 是一套广为使用的开发框架，而你该掌握的是你的 Application 该有哪些 Model? 有哪些 View? Controller? 不是一开始就毫无设计，直接套用 ASP.NET Core MVC 硬干…

在 AI 的世界里, 我暂时找不到其他框架，就先拿 Semantic Kernel 当代表吧。Semantic Kernel 区分了 Kernel, Skill, Planner, Memory, Connector, 这些就是 AI 整合到应用内的标准结构，我在设计 安德鲁小舖 GPTs 时，严格的来说也是用这框架去设计的，只是 GPTs 给了我很低的门槛跟设定画面来做这件事 (连设定画面都有 GPTs 来帮助我，我用聊的他就会帮我设定好了)，我几乎只是靠 Skill (挂上我的 Custom Action) 跟 Planner (只靠 Prompt 描述) 就完成了，Memory GPT 内建我完全不用烦恼，Knowledge 也内建了，我只管上传档案就好。

身为架构师，亲手做一次是必要的，但是更重要的是你务必掌握这框架背后的精神，未来有需求你能够正确的对应，并且正确的把它们组装起来。你应该替你的服务或是产品，仔细思考长远的发展中，你该怎么样在这样的框架下，逐步累积你的元件，这才是 “架构” 师的主要职责。

本文由哈喽比特于9月以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/xvuOmU_ijfQEQVEZ0CsGTA