2024 AI 前端：回首展望，光芒未至，破晓之前！

前言

回望 2023 年，ChatGPT 的突然爆火，让 AI 无疑成为最为值得注目的新兴领域之一，我们也一起见证了生成式 AI 的寒武纪大爆发。这一年来，国内外的生成式 AI 、大模型和相关产品以令人眼花缭乱的速度更新迭代，新的创业浪潮风起云涌。在这 AI 浪潮下，也让我们有了新的开发思考，探索着在各个环节中“前端 & AI”的应用场景。勇于探索的前端开发者们已经开始挥舞着 AI 的“魔法棒”，譬如代码生成、辅助 CR、低代码、测试、业务提效等各类开发环节都被赋予了新的活力和可能性。

在经历长时间与复杂项目“搏斗” 的你，是否对不断重复的工作感到厌倦？

当你面对上万行的代码的 Code Review 时，是否也曾让你感到力不从心？

业务遇到发展瓶颈，是否你也会把希望寄托于 AI 相关应用为其注入活力？

当面对种种类似问题时，你是否也曾幻想过有这样一个神器帮你胜任琐碎的语法检验、代码梳理、模块测试甚至是整体搭建呢？

AI 技术的不断成熟，让这些梦想开始变得触手可及。AI 工具如同瑞士军刀般，其功能与用途变得越来越多样，它们正在帮助我们更有效地解决问题、提高效率，将想象中的可能变为现实。在本次大盘点中，我们会聚焦近一年 AI 相关技术在前端领域的趋势与未来展望，将一一回答上述疑问，帮助读者挖掘从业者的新机会，迎接 AI 的挑战与机遇。

如果你对 AI & 前端感兴趣，请一定要阅读下去，相信我们的精心准备一定不会让你失望～

“勇敢实践 AI 的人，将最先享受世界”

AI & 代码生成

一切故事开始来自于 ChatGPT 的横空出世，让世界看到了 AI 写代码的能力。大语言模型能写算法题、能写游戏、能写网站，不仅写的又快又好，还能直接运行，AI 的表现让人惊讶，人们开始感叹：“程序员的职业恐将不复存在！”

不过只是在 ChatGPT 的对话框里和 AI 交流代码技术还是不够方便，于是，已经默默存在了一段时间的 AI 代码生成辅助工具们乘势而起，成为了爆火产品。代表有 Github Copilot，Tabnine，CodeWhisperer，Cursor，Codeium，Safurai 等，其中有自研模型工具，也有套用模型服务主打产品交互和 prompt 的工具。

AI 代码生成可以细分为很多场景，比如 自然语言生成代码，单元测试，代码重构，代码续写，代码解释，代码评审，问答助手。AI 代码生成工具的出现颠覆了程序员的工作方式，影视作品中对着机器人说两句话就完成编程的时代仿佛就在眼前了。

生态现状及使用体验

但我们抛开博人眼球的新闻，AI代码生成效果如何？程序员真的要失业了吗？

以下是 AI 生成的代码在日常开发过程中的一些亲身体会：

对于单元测试：AI 考虑了非常全面的分支条件，但是运行就报错，因为一些基础依赖、mock 方法、API 的使用不够准确；
对于代码生成：第一次生成效果最好，在后续的讨论修改中逐渐变得上文不接下文，直到所有代码变得不可用；
对于代码补全： Copilot 虽然很惊艳，但是在企业的业务开发过程中由于存在内部代码泄露风险，并不能随心所欲的使用；
对于代码助手： 向它寻求帮助时，它编造不存在工具和 API 推荐给我；

总的来说，AI 代码生成这件事经过了一年时间的考验，仿佛变成了食之无味弃之可惜的鸡肋骨，程序员战战兢兢使用 AI 生成着代码，却惊喜地发现这东西一时半会还替代不了自己。

退而求其次，让 AI 打打下手吧，AI 生成的代码，修改一下，可以使用吗？

在日常开发中，AI 已被业界许多工具证明可以提高开发效率。但如果代码量快速膨胀，人类还改的过来吗？如果随着 AI 生产力进一步提升，当代码检查成为效率的瓶颈时，大量未经人类把关的 AI 代码直接用在生产环境，人类真的敢用吗？

AI & 代码重构的探索

为什么做重构？

在 AI 代码生成的众多细分场景中，代码重构是相对来说是一次生成代码量最大的场景之一，同时又因为有原代码逻辑可对照，它生成的代码的评判标准又相对明确。于是代码重构场景成为了很好的观察对象。

在没有AI 工具的时代，程序员们也在持续做代码重构，工程在迭代过程中逐渐腐坏，需要不同程度的重构去保证迭代效率。同时重构的项目总不会是刚写没多久就开始重构的，所以重构总是伴随着大量的、难以追溯的业务逻辑。在这个过程中，陈年逻辑是不是理解到位？再次实现是否能保证没有 bug？这些问题都折磨着每个做重构项目的程序员。

AI 随着时代的洪流登场了。大家都知道代码重构是麻烦又危险的操作，如果 AI 能代劳，既保持了代码的可维护性，又没有程序员因为实施重构而失去头发。在实践中，我们的业务刚好有代码重构的需求：陈年的 Vue 代码希望重构成React版本，目标通过重构使团队技术栈保持统一，同时完成一些针对老项目的性能优化动作。

重构前

AI 重构后

AI 的表现如何？

考虑到 AI 已经被鼓吹可以替代人类，那么人类程序员能做到的代码重构效果，AI 也一定能做到，所以一开始在提示词中希望它在重构的过程中优化文件结构，移除冗余代码，同时保持原始逻辑不变。这是一个非常“普通且自信”的想法：既要、又要、还要。

于是沟通遇到的第一个问题出现了，即使将复杂的任务拆分，人类也很难用自然语言明确告知模型，怎么样算优化文件结构，什么样的逻辑是冗余逻辑，毕竟人类程序员还要经过反复的需求讨论才能逐渐确认需求的全部细节。于是一步到位的提示词方案被否定。

接下来对 AI 的要求是：文件对文件，逻辑对逻辑进行代码转换，不必做过程中的优化和调整。这样任务就简单了许多，降低了沟通成本，指令的下达变得明确而高效。

随着项目的推进，又遇到了类似的问题：对于混杂在多任务中的简单小任务，AI 无法做到，无论是明确定义、增加示例、反复强调、给予鼓励。 比如特定第三方组件库的使用参数，JSX 条件渲染的实现等。这时问题可能出现在这些小任务合集触碰到了 AI 能力的上限，除非针对特定任务精调，去提升它在任务中的表现。

去评判 AI 的表现，总的来说还是沟通和能力边界的问题。对于业务中使用的某个具体模型，它的能力边界不完全确定，由于模型内部逻辑原理的不可解释性，提示词工程师（Prompt Engineer，PE）们只能不断猜测、试验，而在这其中投入多少精力的度，是不确定的。另外考虑到 AI 的幻觉问题，如何评判“胜任”，如何确保 AI 每一次任务都“胜任”也是一个挑战。所以这充满不确定的沟通调试过程，影响了 AI 代码生成的效果，较低的代码产物质量让它们暂时无法被信任地直接用在生产环境。

总结

和人之间的信任一样，AI 的信任是逐渐建立的，从简单的任务到复杂的任务如果都能逐一胜任，那么人类对 AI 的信任就会增加。对于 AI 出现的失误，并不是不被允许，只是这些失误需要是可解释的，并且有规律可规避的。 对 AI 更进一步的期待是，其内部的运行逻辑是可解释的，其行为是可控的。

我们期待这一天的到来，期待AI 成为人类更加可信任的工作伙伴。

AI & 测试

你可能会觉得“啊，既然 AI代码生成问题那么多，那么退一步让 AI 来测试吧”，但是，实际上 AI 测试当前也有着数不尽的问题。本小节将会详细拆解这些问题来逐一分析。

AI 与测试相关的问题

这里面涉及到很多很虚无缥缈的东西，你可能还会说“废话少说，直接告诉我最佳实践”。然而事实是，别说最佳实践，以至于截止到 2023 年，前端 + 大语言模型 + 测试的实践几乎为 0。如果你在 Github 搜索，仓库不超过 10 个，合计的 Star 数加起来 5 个都不到。

为什么？为什么感觉这么“前途无量”的场景连 Github 仓库都没几个？

这个问题很难用一句来解释清楚，但是我向你保证，看完本节，你一定会得到答案。

单元测试

先说实施起来最简单的单元测试。单元测试非常的直白，就是使用一段纯 JS 代码来测试另一段纯 JS 代码，比较结果，一样就成功不一样的就失败。这么简单的任务，强如 GPT-4，不会做不到吧？

能做到，但是不能完全做到。

其实在 AI + 单元测试，在 LLM 出现之前，业界就已经有很多很多的实践了，而在 LLM 后，又崛起了一批 LLM + 单元测试的试验品。但是我打赌读者一个也没听说过对不对？没听说过就对了，因为哪怕有了 LLM 的助力，效果依旧一言难尽，根本拿不出手。

接受率

在这里引入一个接受率的概念。简单来说就是 AI 生成了 100 个用例，哪些是可以直接使用的。假如有 80 个可以不经修改的直接使用，那么接受率就是 80 / 100 = 80%。

但是这里有个非常尴尬事情——并不是说接受率 > 0% 那么就可以用，因为你依旧需要花精力在那些“不可用的用例”。

假如接受率是 40%，AI 生成了 100 个用例，你其实并不知道这 100 个用例中哪 40 个是正确的，而为了使用这 40 个正确的用例，你需要：

想办法将可用的用例挑出来，并逐一验证
将剩下不可用的用例一个一个改好
重新整体检查，手动填补用例遗漏

假如接受率真的是 40%，这个过程将会是地狱，将远远超越你自己写 100 个用例的时间。

好了，那么读者不妨在此猜测一下，那么在 LLM 之前和之后，AI 单元测试的接受率是多少？

单元测试的进一步分析

通过接受率小节，我们了解的接受率必须高到一定阈值才有意义，否则就是单纯的把“写用例”变成了“调用例+改用例”。据我们的估计，接受率至少要达到 80% 以上，否则就完全是在帮倒忙。

而目前LLM+ 单元测试普遍的接受率仅为 50% 不到，而如果是用 NLP 来代替 LLM，接受率将低到 30% 以下：

Pass@10[%] 代表 AI 拿到错误信息再次迭代，尝试了 10 次

这就好比有个实习生，写了 10 个页面，其中：

2 个页面看上去正常，实际上交互有各种问题和巧妙的 Bug
4 个页面运行正常，但是和上面这种页面混在一起了，你需要测试后才能找到他们
2 个页面打开就白屏，你简单修改几次它还是白屏，你也不知道具体为啥，需要慢慢调
2 个页面忘做了

这种实习生你要吗？因此，AI & 单元测试依旧要求程序员拥有极强的单测完善能力，它不能代替你来直接完成单元测试。

其他测试

单元测试包含了太多的细节和边界情况，那么我们把视野拉远，比如 E2E 测试，是不是会好一点呢？正好前端单测用的也不多。

别说，你还真别说，当我们聚焦于 E2E 而不是单测后，各种问题确实是迎刃......增加了~！

当你想使用 AI + E2E 后，第一件事就是——怎么让 AI 和浏览器交互。目前在这方面，业界没有任何的实践，所有的胶水代码都必须由你来开发。

目前 GPT 确实有检索和理解网页的能力，但是仅限于内容的理解。无法做到对于前端页面交互的理解，比如在选择框来选择某项

在单元测试中，我们可以很容易的“报错后直接发给 AI，让 AI 多试几次”，但是这个交互流程在 E2E 情景下是没有相关实践的，其中伴随很多的开发工作。

同样的，AI 对于一个网页的理解是非常有限的，他并不知道一个用户交互是错误的还是正确的，你可能还需要传递给 AI 一些背景资料，比如产品文档、测试用例、交互图、代码。这部分的序列化工作也是一个全新的领域，所有的胶水代码都必须由你来开发。

如果你不是在一个大型 IT 公司，开发胶水代码成本是难以接受的。它可能要花费一年的时间，并且过程中没有任何阶段性产出，且部分功能随时可能被新一代的 LLM 所代替。

总结

通过单元测试和 E2E 测试的分析，相信读者已经明白了的当前 AI & 测试面临的主要挑战：

如何序列化让 AI 理解现状上下文
过低接受率导致的额外人工介入的成本

但是我们相信这些这些问题都是有解的。可能是更加聪明的 LLM 提高了接受率，可能是规范的合作方合作流程，比如测试用例写的足够可读，并能直接导出为表格发送给 LLM，也可能是某个公司大笔一挥，决定花一年来开发一个 AI E2E 测试框架。

现在，软件测试的世界在等待一位英雄，他手持 LLM 的利剑，彻底斩除软件开发的质量痛点。而那位英雄，会不会是正在阅读本文的你呢？

AI & 辅助CR

除了开发与测试，换个角度看问题，如果让 AI 来当我们的CR助手呢？

代码审查（CodeReview）是软件开发过程中的重要环节，Code Review 是指开发人员对彼此的代码进行审查和评估的过程。通过 Code Review，团队成员可以相互检查代码的正确性、可读性、可维护性以及是否符合编码规范等方面的问题。可以帮助开发者发现并修复代码中的错误和缺陷，提高代码质量，减少技术债务。

传统的代码审查由人工完成，团队在 Code Review 上花费了大量时间，且容易出现疏漏。随着大型语言模型（LLM）的发展，LLM 在代码审查领域得到了越来越多的关注。LLM 可以通过对代码的语义理解，快速识别代码中的错误和缺陷，从而提高代码审查的效率和准确性，以下是 AI Code Review 的几个好处：

自动化和效率：与传统的人工 Code Review 相比，AI Code Review 具有更高的自动化程度，可以大大提高审查的效率。
捕捉更多问题：AI Code Review 工具可以检测出更多的代码问题，包括潜在的性能问题、代码重复、安全漏洞等，帮助开发人员更全面地改进代码。
减少人为偏差：由于人为因素，传统的 Code Review 可能存在一些主观偏差。而 AI Code Review 可以基于大量的事实和规则进行评估，减少主观因素的影响，提供更客观的评价结果。
持续集成与部署：AI Code Review 工具可以与CI/CD相结合，实现自动的代码审查和反馈，帮助开发团队更好地管理代码质量。

AI 在 Code Review 的场景

LLM 在代码审查领域的应用主要有以下几个方面：

补充CR信息：根据 CR 的 Diff 内容，生成 CR 的表述、标题、CR 总结，方便人工短时间了解代码变更关键信息。
基本代码问题：变量名、函数名的语义化、可读性、可维护性、可扩展性等。通过分析代码的结构、语法和语义特征，工具可以自动判断代码的质量等级，为开发团队提供改进建议。
代码性能问题：AI 代码评审工具可以分析代码的执行效率，发现潜在的性能瓶颈和优化点。例如，工具可以识别循环嵌套、冗余计算等问题，并提供优化建议，提高代码的执行效率。
逻辑问题：比如边界问题、条件判断、循环控制的合理性。
代码安全问题：AI 代码评审工具可以用于识别潜在的安全漏洞和风险。例如，工具可以分析代码中的敏感数据处理、输入验证、权限控制、SQL 注入，XSS 等方面，发现可能存在的安全问题，并提供修复建议。

当前应用

当前业界有不少 AI Code Review 的能力应用，除了大家熟知的 Github Copilot ，开发者对其进行提问可以帮助完成 Code Review 的动作，我们再看一下还有哪些成熟的应用。

ChatGPT-CodeReview

通过调用 Chagpt 的 Open API 以 GIthub Action 的形式集成到 Github 里面，机器人会自动进行代码审查，审查信息将显示在 pr timeline / file changes 部分。在git push更新 PR 之后，CR bot 将重新审查更改的文件：

CodiumAI PR-Agent

CodiumAI PR-Agent：一款基于 Chatgpt 的开源工具，可帮助高效审查和处理拉取请求。它自动分析 pull request，并提供多种类型的命令：自动生成 PR 描述、可调整的反馈、问题解答、代码建议、更新 CHANGELOG.md 文件、查找相似问题、自动添加文档、生成自定义标签和自动分析 PR 变更。

总结

如果你决定开始使用 AI 能力作为团队 CR 助手，请注意：

由于 LLM 本身的 Token 上下文限制，当MR超出最大的 Context 上下文限制时，会造成信息丢失导致 Review 结果不全面。
由于 LLM 回答的随机性，同一份代码多次 Review 可能有不同的结果，以及 Review 的结论会偏啰嗦，不容易抓出重点问题，所以在提示词里面可以多强调关注重点问题，比如 Prompt 加入 “作为一名代码 review 专家、对 Gitlab 的 MR 进行代码 review. 只关注代码性能、代码安全问题、严重的逻辑错误”
如果要针对团队业务场景或基于团队研发规范进行 AI Review，可以将团队的业务背景信息规范等作为知识库对模型进行微调，对于担心代码泄漏的场景，还可以对开源的LLM进行私有化部署作为企业内的方案。

一言以蔽之，当前只是辅助人工 Review 帮助快速发现一些问题，减轻人工的简单重复的劳动，但无法完全取代人，最终还得由人作判断，但我们可以用节省下来的人力关注到更高优的事情上面。

AI & 低代码

前两年火爆的低代码概念，似乎和 AI 有不错的“缘分”，两者结合往往能达到一加一大于二的效果。

什么是低代码

低代码开发平台（英语：Low-Code Development Platform，简称 LCDP），是一种方便产生应用程序的平台软件，软件会让用户以图形化接口以及配置编写程序，而不是用传统的程序设计作法。此平台是针对某些种类的应用而设计开发的，例如数据库、业务过程、以及用户界面（例如网页应用程序）。这类平台一般可以产生完整且可运作的应用代码，但在一些特殊的情形下仍需要编写程序。

低代码概念最早出现在 1982 年《无程序员的应用程序开发》一书中，美国低代码产品的研究和实践过程较长，积累了较丰富的经验。中国最早出现低代码平台大概是在 2014 年，产品的形态从最初的数据库交付，到数据集结构搭建逐渐演变抽象出各种流程引擎、可视化界面等产品能力，应用能力也从 BPM 延伸到 ERP、CRM 等大型复杂应用，整个行业经历了 2017-2020 年的快速发展阶段，市场增速开始放缓，但相对于其他企业服务赛道仍处于高增长阶段，预计 2025 年中国低代码行业市场规模将达到 118.4 亿。

存在问题

但低代码自出现以来，一直还是饱受质疑，核心的点在于通过低代码的可视化搭建大大降低了建设成本，且使用群体从开发人员逐步向业务人员渗透，但低代码本身是存在一定的的上手门槛，包括各类物料的用法、如何实现与后端接口通信、物料之间如何配置交互等等，这使得业务人员无法快速上手完成页面搭建，而开发人员需要学习特定搭建规则和限制，可能不如实际开发来的快。

在不同类型的低代码产品的相关的限制又会有所差异，从应用场景上可以划分通用型和垂直型

对于垂直型低代码产品，深耕特定行业或特定的场景，提供当前垂类更具有专业性的解决方案和搭建能力，在具体的搭建场景中专业性贴合更深，会存在复杂搭建场景，如公式、模型、数据等，门槛更高，搭建依赖的前置输入也要更多。
而对于通用型，由于覆盖各行业各场景，沉淀了大量的行业模版和解决方案，虽然搭建门槛相对垂直型要更低，但内容覆盖面更广，大量的物料和模版不仅造成了用户选择压力，也提升了搭建的学习负担。

低代码产品本身的易用性有待进一步提升，包括底层技术框架和可视化界面的呈现，另外低代码相关的培训机制有待完善，培训不足导致用户对于低代码产品的接纳度低，用户本身对于繁重的产品使用学习的意愿不足，也会大大阻碍低代码产品的推广和应用。

如何赋能

随着 GPT 为代表大模型爆火，AIGC 也开始在各个行业渗透，借助大语言模型的能力精准识别用户需求，进而彻底改变当前低代码搭建工作流。通过自然语言交互替代原有选择、编辑、拖拽等操作，从而屏蔽了低代码平台本身的使用规则，这大大降低用户的学习上手成本，进而提升低代码的应用场景和搭建效率。未来 AI 能力将会成为低代码平台的标配，成为未来重要的发展方向。

当前阶段，各个低代码平台都在摩拳擦掌，跃跃欲试，很多平台已经逐步上线自己的 AI 融合能力，一些典型场景包括：

智能创建页面

通过自然语言完成页面创建，主要应用在通用型低代码平台中，来避免大量物料和模版的学习选择成本，钉钉宜搭、织信、易鲸云都上线了这部分能力，比如在宜搭平台上线了通过简要描述门户的基本信息，系统将智能化地按需生成门户的能力。

核心逻辑在于通过自然语言精准识别用户需求，匹配合适的物料、模版，完成内容生成，进一步组装形成 DSL 进行渲染。

局部场景智能生成

聚焦低代码平台搭建中的局部场景，如公式编辑器、流程编排、智能表格、辅助编程等，通过自然语言来替换原有搭建方式，进而降低整体搭建复杂度，这么做的优势在于将自然语言聚焦特定局部场景的优势，也可以使得需求识别更加精准，下图是易鲸云通过自然语言自动化完成流程编辑的效果。

易鲸云AI生成流程演示

智能问答

通过将低代码平台中沉淀的大量的文本、视频材料喂给大语言模型，来提升用户问题解决效率，节省运营成本。当然不仅仅是低代码，智能文档这一场景适用各类平台中。

总结

当然 AIGC 与低代码的融合还处于早期阶段，当前应用范围也主要还是在一些容错率较高的场景，通过大语言模型可能不能完全理解用户的真实需求，这需要庞大的上下文做支撑，虽然融合方向仍然有诸多问题亟需解决，但未来低代码平台必将会全面拥抱 AIGC，这也意味着我们需要重新去思考低代码平台的交互界面的设计，充分利用自然语言交互特点，提升用户体验。

另外数据安全风险也是在商业化产品中必须要考量的一点，因此多数企业都在尝试走自研大模型的路子，然而这并不是一件容易的事。它需要大量高质量数据的收集、清洗和标注，以及昂贵的计算资源来支持模型训练。这也意味着未来 AI 加持下的低代码平台的竞争成本会更高，会更加聚焦在有雄厚实力的头部企业。

除了 AIGC +低代码融合之外，还有一方观点认为既然 AIGC 能力越来越强，是否会完全替代低代码，直接生成原始应用？我们认为至少在可以预见很长范围内低代码不会被完全替换掉，就像上面几部分提到的，大模型通过语义直接生成代码并不能保证其完全的准确性，且代码可用性需要大量的人工校正。而低代码融合 AIGC 可以通过语义生成模型，加速需求分析工作进程，可以让 AI 更快的进入业务。

AI & 业务

说到业务，下面就用各大互联网企业中最为常见的审核业务作为例子来进行探讨：

思考

对于审核业务与 AI ，可能大家的第一反应就是，AI 是否能完全替代审核员对内容进行审核呢？

我们认为未来是可以的。 内容对于人类来说，无非也是来自声光电的刺激。而当这些声光电的刺激能被模型接受、理解、推理后，也就做到了和人类一样的事。而且，相比较人，它更容易管理，标准更统一，成本也会更低。

但现阶段，就像推测会被替代的所有工作类型一样，还有太多的问题要解决了。AI 会作为不同的工具形态，慢慢融入人们的工作；但距离完全替代，还有不小的距离。

所以业务上，我们也在思考，它能不能也辅助审核员，取得更好的审核质量和效率。也尝试了一些 demo 项目，想知道 AI 能做到什么地步，这样有助于我们探索业务场景上能做到的极限。

但即使我们只是想让他作为一个额外的信息来源，来辅助审核员来的判断，也存在非常多现阶段需要解决的问题：

成本问题：无论是使用外部的 LLM ，支付接口调用的费用，还是自己训练并使用内部的模型，基于现在每日发布内容的巨大量级，预估这都是一笔巨大的开支。在目前 AI 辅助审核的前进方向不明确的情况下，成本能否打平收益，还是一个需要进一步深究的问题。
合规问题：只能使用用户已经公开在平台发表可见的内容，公司内的数据，例如 Policy 、代码、培训材料等，都是不允许输入给外部大模型的。
人为限制：外部给用户使用的大模型需要满足世俗的道德和法律体系，因此模型训练和输出过程中做了对齐，但审核业务就是为了能让大模型正确分析以及反馈有害内容中的风险细节， LLM 往往因为对齐，而拒绝回答，给审核场景的探索带来了不少阻碍。
标准问题：各家大模型都有自己的 Policy ，特定业务中的 Policy 因为合规问题，无法输入给 LLM ，那 LLM 就无法给出符合我们审核标准的答案。
多模态问题：面对一个以音视频为主的内容社区，很多的风险是在画面、音频中的，甚至有的还要靠连续的画面或者多个模态的信息结合起来判断，这些都大大限制了目前以文字输入为主的大模型的在内容社区审核中的使用场景。

其中，合规和标准、人为限制可以通过使用私有的开源大模型解决，但也需要持续进行效果的调优。

但依然也可以看到，在过去的2023年，大模型业界，很多问题被研究，很多的方案被提出，也有很多的场景逐步落地，曙光变成了朝霞，荒野也被勇敢探索的人踏出了小路。

当然，除了审核本身，对于其他平台业务来说，什么是未来平台产品的范式：AI 在其中解决什么问题，扮演着什么样的角色。随着业界方案成熟和持续的思考，也可以有计划地集成到我们的平台里。

可能性

23年，AI 技术上也在不断的发展，这给了业务更多思考空间，如何合理的在业务中使用这些技术。

在模型和基建上，能看到下面这些现象：

而在应用层，我们可以参考一些现在实用程度较高的方案，思考它们如何在业务中结合：

当前其实可用的开源方案有不少，例如：

https://github.com/logspace-ai/langflow
https://github.com/langchain-ai/langchain
https://github.com/lobehub/lobe-chat
https://github.com/e2b-dev/E2B

最后的最后

随着 2023 年的日历缓缓翻至尾页，我们站在新的起点上，回首这一年 AI 技术尤其是生成式 AI 的巨大飞跃，ChatGPT 的崛起不只标志着技术的飞速进步，更是我们共同见证的历史性时刻。在过去的一年里，AI 的变革触及了从代码生成到业务优化的各个方面，前端开发者们大胆拥抱这场变革，将 AI 的巨大潜力转化为实际的生产力。

然而，正如我们所经历的，AI 并非全能。它在代码生成、测试和重构等领域虽有所进步，却也显露出一些局限。不尽完美的接受率、结果的随机性，以及对复杂任务处理的不足，都提醒着我们：AI 当前只是辅助工具，而非全能替代者。它能帮助我们，但最终的创新和决策仍需人类来掌握。

面对 AI 在代码审查和低代码开发等领域的实践应用，我们看到了潜力与挑战的共存。

AI 技术的发展，不仅仅是技术层面的进步，更是对我们工作方式的深刻挑战和重塑。我们热切期待在新的一年中 AI 技术带来的更多创新与变革，同时也清楚地认识到，在与 AI 携手共进的道路上，还有许多未知和挑战等待我们去克服和探索。

展望 2024 年，我们满怀期待地看向在 AI 的助力下，不仅在技术上实现更多突破，还能在业务层面实现新的飞跃。

带着这一年的收获和经验，让我们共同迈向全新的一年。我们坚信，凭借对技术的持续探索和对业务的深入理解，我们能够在 AI 的支持下，开拓更宽广的业务领域，创造更加卓越的未来。

迎着 2024 年，我们满载信心地向前行！