《以模型为积木、以工程为骨架、以用户价值为终点》

课程文稿

下午好，各位，我是来自阿里千问AI硬件事业事业部的志坤。今天，我将分享一个与他人不同的主题——超级个体的探索。我的分享颇为独特，因为它与我的本职工作关联不大。这是因为我利用过去两个月的业余时间，基于个人兴趣开发的一个项目，它纯粹是一个探索。但同时，我认为这个兴趣项目与我们技术大会的主题紧密相关。因为它已经发展成为一个拥有170万行代码的系统，涉及100多个技术栈和30多个大型模型，实现了Dobby、Monos及Open Cloud 90%以上的功能。因此，我今天想探讨的是，当一个人与AI的界限在哪里。

我将分享的内容分为两部分：首先，我会介绍一部分功能的实践，并分享在这个过程中积累的经验和教训。自1995年网景公司发明JavaScript以来，前端开发已经经历了三十多年的发展。随着AI技术的崛起，有声音提出未来的设计需要面向agent进行，要CLI化。那么，在这个AI时代，前端还能做些什么呢？我认为，前端的角色可以概括为“翻译官”三个字，为什么呢？

请大家关注现状。用户若想修改图片的某个区域，只能尝试通过prompt进行修改；若想对视频中的某个对象进行编辑，只能重新生成整个视频。大模型输出的内容仅限纯文本，其可视化能力较弱。用户的空间直觉与大模型的语义理解之间存在显著差异，而前端正是负责填补这一差异的“翻译官”。现在，让我们探讨第一个问题。

功能演示。我上传了一张需要修改的图片，并用画笔精准圈选了需要修改的区域。通过语音输入我的要求，然后点击提交。接下来，大家可以看到系统如何精准地识别并修改指定区域。这是最终修改的效果。实践的核心思路是将用户的手势涂鸦转化为像素级别的编辑。用户上传图片后，用画笔描绘想要修改的区域，并输入文字描述。前端采集笔触信息，并连同原始图片涂鸦截图以及用户要求，一并提交给服务端。

实际上，这一过程中涉及多个难点。首要难点是“双画布分离”，即用户的涂鸦和原始图片必须分开存储且互不干扰。其次为位置信息的转化，画布上的图片是经过缩放的，但为了清晰地提供给大模型，最终用户图片的位置坐标需要精确映射和转化。第三个难点是涂鸦处理，用户可能使用不同颜色的画笔进行绘制，而大模型对输入图片的格式有特定要求，需要进行颜色转换和洪水填充。第四个难点是尺寸对齐，提供给大模型的两张图片必须尺寸一致，需要进行裁剪和缩放。

此外，我们还面临一个关键的设计决策：生成的结果是一次性向用户呈现多张图片让用户选择，还是首先快速提供一张图片让用户作为审核员，若不满意则可不断修改prompt。我选择了一条中间道路，即引入一个质量评估闭环。生成图片后，系统会根据用户的输入信息，包括图片等，进行自动化检测，判断最终生成的图片是否满足用户需求。如果不达标，系统会自动优化prompt并重新生成图片，直至满足用户需求。虽然这个过程可能会耗时较长，但最终呈现给用户的图片是能够满足他的要求且可编辑的。

视频能否进行编辑呢？答案是肯定的。请看，我上传了一段视频，当视频播放到需要修改的画面时，我选择暂停，涂抹指定区域，并输入我的要求。最终，视频的其他部分保持不变，而用户圈选的特定部分则按照用户需求进行修改。

实际上，该功能的开发思路沿袭了之前的图片编辑功能。用户在视频播放时暂停在所需编辑的画面，然后用画笔涂抹目标区域，并输入文字描述进行提交。难点主要体现在三个方面：首先是在视频上层叠加一个手绘风格的画布，我选择了卡布斯的方案来实现视频帧上叠加蒙版进行涂抹；第二是分辨率的映射，前端涂抹的位置需要准确地转化到原始视频分辨率，否则无法一一对应；第三是格式的适配，对于这类视频编辑的大模型，它们的输入都有特定要求，都需要转换成模型能够支持的格式，因此这需要工程介入。

好的，我们再讨论第三个话题，即输出的语音大模型。默认的大模型输出是文本。大模型生成的文本，用户阅读效率极低，用户更偏好图文并茂且具有交互性的内容。请参考我所展示的输出维度升维的例子。

在数学领域，有一个相当抽象的概念，通常难以用文字清晰表述。我采用了可视化的方法来解释。图像不仅直观，还支持手动交互，这有助于用户更好地理解导数的概念。大模型能够实现文本到图像和视频的生成，但处理精确的数学公式则较为困难，更不用说创建一个可交互的大模型了。然而，利用前端技术，我们可以轻松实现这种可交互性，并确保用户能够理解。这就是实现的关键。

解决思路其实很直接，我搜集了网上几乎所有的知名前端可视化库，最终筛选出46个可视化库，并基于这46个库生成了286个示例，构建了一个可视化的前端知识库大模型。生成的页面不仅包含文字，返回的文字内容基于这个知识库，最终用户看到的页面是图文并茂、生动形象且具有交互性的。

此过程涉及三个主要难点：首先是筛选，从海量的潜能库中挑选出所需的库，并在生成过程中处理组件间的相同与冲突问题，这需要依赖于人的审美判断。第二个是上下文管理，由于没有一个大模型的上下文能一次性容纳所有知识库，因此必须采取渐进式的方式逐步提供给大模型。第三个是确保成功率。为达成此目标，我采用了两步生成的方式，结合自动检测、自动修复及自动验证机制，以确保最终生成的成功率。

好的，进行总结。在AI时代，前端工作已不仅限于关注页面展示，而是需要深入理解服务端和大型模型，成为用户的翻译官，架起用户与大模型之间的桥梁。

接下来，我们再讨论一个现象：现在大模型帮助程序员生成代码已经是一个常见的场景。然而，用户真正需要的并不仅仅是代码，而是可以直接使用的工具。

我让大模型根据一句话请求设计一个手势游戏。它可以根据一句话描述，自动生成一个网页游戏的HTML代码，自动部署并生成一个可访问的链接，用户点击即可开始游戏。同时，它还能继续生成适用于安卓和iOS的安装包。

另一个例子是人脸识别应用。用户仅需提出一个需求，系统便能自动生成前后端代码，并确保用户能够顺利部署应用，前后端接口正常调用，用户点击链接后即可直接使用。以前面提到的手势游戏为例，背后涉及多步骤处理：首先，系统需要理解用户对游戏的具体要求，并匹配相应手势；其次，它会基于知识库进行匹配，动态构建prompt；接着，根据这个prompt调用大型模型生成代码；最后，生成的代码会自动进行验证，并修复可能出现的bug。整个流程是全自动化的，用户仅需提出请求。

如果用户希望在电视上玩游戏，该如何处理？这是一个针对安卓手机的具体安装案例。安装完成后，它展示了另一个架子鼓的示例。同样地，这个应用不仅适用于手机，也适用于配备安卓系统的电视上。其核心是利用相关工具将HTML代码和相关素材重新打包成适用于安卓系统的APK格式。

主要难点包括：首先，将HTML代码和各种素材转化为APK文件中的内容形式，这涉及到多层目录，较为复杂。其次，权限的自动注入，例如一款手势识别游戏需要摄像头权限，需要在安装后提醒用户授权。第三是资源打包，因为游戏支持用户自定义玩法、背景、角色和道具等，所有这些素材都需要打包进APK中。

针对iOS和安卓平台，尽管思路相似——利用相关工具将应用打包成安装包，但iOS的实现复杂度更高。这涉及开发者账号、Xcode开发环境以及签名证书等一系列工程设置。

总结来说，我们已经实现了从一句话描述生成人脸应用，到生成体感游戏的H5页面，再到生成安卓APK和iOS IPA安装包的全链路闭环自动化交付。用户的需求不再需要等待软件公司的开发排期，可以在分钟级内直接交付。谷歌和苹果的APP商店生态，未来可能被这种自动生成的APP所影响和颠覆。从生成代码片段到直接交付可安装的产品，这才是用户真正需要的价值。

龙虾目前极为流行，但我观察到，这主要是一些互联网从业者在参与。为什么呢？因为安装过程相当复杂，普通用户难以自行完成，而且需要专门的电脑设备，并且需要持续运行。此外，前面的学员也提到了其中潜在的安全风险。因此，我开始思考，对于那些不具备安装环境、没有专门电脑的普通人来说，他们需要怎样的龙虾呢？我认为，他们需要一个可以在任何时间、任何设备、任何人使用下都能保持安全的在线版龙虾。

如果要增加一个在线版的龙虾功能，仅将其实例部署到云端服务器是不够的。我们需要解决三个核心矛盾。首先是简单易用与功能强大的矛盾。用户界面应尽可能简洁，让用户通过浏览器或APP即可直接使用，无需任何配置和门槛。然而，在功能上，需要AI的全面驱动，实现自动化功能，直接为用户提供所需结果。我的解决方案是利用AI的全自动驱动，理解用户需求并自动匹配工具。若缺少工具，用户可通过搜索获取多种工具，这些工具可以自动编排。通过组合几百种基础能力，我们的解决方案覆盖了用户的常见场景。

另一个挑战是云端执行与本地能力之间的矛盾。强大的本地工具通常依赖用户电脑的高权限。但当任务转移到云端执行时，如何提供超越本地电脑的能力呢？为解决这一问题，我们利用了阿里云无影agent的能力，它创建了一个本地环境沙箱，支持代码运行、浏览器操作、手机模拟和文件操作。同时，阿里云的网盘被用于文件存储和分享，阿里云的数据库解决了数据存储问题，阿里云的FC弹性计算提供了无限算力，ScheduleX实现了定时任务。此外，通过阿里云百炼，我们接入了上百种大模型，同时对接各种不同的MCP服务。简而言之，这个系统背后是整个阿里云的全力支持。

第三个议题是智能进化与安全可控性。我们希望AI模型尽可能智能，这意味着它不能仅调用几百种预设能力，而是在执行任务时能够发现并识别所需工具。例如，我演示了自动生成一个人脸识别全套应用程序，这正是AI创作的成果。此外，当AI在执行过程中出现错误时，它能够基于日志进行反思，并动态重新规划整个编排流程。

进化必须有边界。所有高风险操作需在云端沙箱内执行，并通过大量自检自测的质量阀门确保AI的进化始终符合安全边界。接下来，我展示了一个真实应用案例视频：让AI协助通过微信、微博和小红书搜索OpenCloud的信息，然后合并汇总这些信息并写入钉钉文档，再将文档分享至群组，并创建一个关于养龙虾的钉钉日程。AI能够自动理解需求、拆解任务，并能进行串行和并行操作，最终成功完成任务。

当系统变得复杂，用户可能会不清楚如何操作。因此，我们特意编写了一本使用指南，旨在指导用户如何有效使用该系统。当用户不清楚如何进行时，系统会推荐一些玩法来帮助用户。此外，我们提供了一系列一键执行的模块。用户在进行修改后，只需点击一下，系统就能执行相应的操作。目前，该平台已支持数百种功能，并且还在持续增加新功能。需要补充的是，前面提到的系统是完全自主开发的，没有使用opencloud的一行代码。

最近读到一篇文章指出，实现AGI不能仅依赖模型，而需要为AI提供一个适宜进化的环境，使AI能够感知人类社会的各种信息并执行人类社会操作。AI的产出具有持续性，能够修改AI本身的运行环境，实现AI的自我优化。在我的探索性项目中，每一次成功执行生成的结果都会自动沉淀为知识，而每次执行的过程都会被记录并支持编排模式。项目支持长短期记忆及语义检索，以辅助AI下次执行时的决策，并给予AI自我验证及修正错误的机会。最重要的是，它允许AI动态创建工具以扩展自身能力的界限。通过创造和使用工具，人类得以实现与动物最大的区别。我的探索项目能够调用联网设备的各种能力，其目标远不止于简单地利用这些能力来完成任务。这六个要素共同构成了一个进化的飞轮，我对未来AI的进化潜力感到好奇。

由于时间关系，关于功能的介绍就到此为止。接下来，我想分享一些自己在实践中的经验和教训。知识库是大模型的强大辅助工具，但其建设不能采用传统软件工程思维。质量应优先于数量。我曾试图一次性构建多个案例，导致效率低下，最终不得不推翻重来。其次，分类的重要性远大于堆砌，必须按照类型、机制、场景等多维度进行分类，否则会直接导致大模型上下文撑爆。再者，验证优于信任，每个案例在入库前必须能够成功运行并通过验证，否则无法提升生成的成功率。原始数据是示例，必须有准确的描述，否则大模型无法进行精确匹配。最后，迭代优于一次性录入，必须定期清理和更新。

虽然我们没有采用国外顶尖的大模型，而是全部使用阿里云的通义千问系列，但通过采用AI native的工程设计，我们成功地将模型调用的成功率大幅提升。根据我的经验，如果直接调用同一模型，其成功率是相当低的。然而，通过采用这六层工程架构设计，我们能够实现一个生产级可用的状态，显著提高成功率。我们不能仅仅依赖使用更强大的模型，因为模型是黑盒且不可控，其成本随着复杂性的增加而线性增长。而功能架构的每一层都是可调试、可量化的，其成本的边际递减由我们自己决定。

使用大型模型时，不可避免地会涉及prompt设计。我根据网络上的多种经验总结，并通过数百个场景的验证，创造了一个有效的prompt模板。其核心是结构化写作，遵循这一结构能显著提升大模型输出的稳定性和准确性。优秀的prompt实际上是在语义空间中为大模型铺设了一条明确的路径。

最后，让我们探讨一下开发范式的变化。基于这次实践，我认为超级个体需要具备技术深度、AI协作能力以及产品思维。有人可能认为，既然AI已经能够编写代码，就不需要再学习技术了。然而，我却认为，重复的编码工作确实可以不再耗费精力，但架构设计、技术选型以及系统全局优化的技术能力相较于以往更为重要。过去两个月，AI与我共同编写了超过170万行代码，实现了一个包含当前主流产品功能的系统。如果以前有人提到这样的时间和功能，我可能会觉得他在夸大其词。然而，如今这一切真的发生了，背后的原因正是开发范式的转变。我相信，每一个关注AI、愿意学习，并关注用户价值的开发者，都可以成为超级个体。谢谢大家。