CloudMan6的博客

到这里，咱们这个AI应用开发的教程就该告一段落了。正如教程开头说的，CloudMan的目标是通过具体案例带大家体会一下AI应用的开发思路和过程，提升大家使用AI的信心。AI大模型大大降低了应用开发的门槛。只要有好的想法，稍微有些编程基础就能开发出优秀的应用。退一万步，即便对应用开发没兴趣，AI也能帮助我们探索新领域，发展自身潜能。以前学东西除了找到好的教程，更得有人指导。现在好了，AI就是那个能提供指导的人，它经验丰富、态度端正、而且24小时待命。

上一节我们已经用大模型从文本中识别提取出实体和关系，接下来要考虑存储的问题。R1最初给我们的方案是向量化存储。但后来讨论到实体的动态属性特性时又提到可以使用NoSQL数据库，如MongoDB。也就是说实体存储现在至少有两种方案：向量数据库和NoSQL数据库。具体怎么权衡，听听R1怎么说。这个解释我觉得非常到位。特别是最后这张表，针对不同数据类型采用不同的存储方案。经过进一步探索，我决定用MongoDB存储实体数据，用图数据库Neo4j存储关系数据。

当然，哪天AGI甚至强人工智能出现了，必要时咱再改变心态呗。公众号Cloudman6。

还好，证明这个方案是靠谱的，大家都是这么做的。比如实体“萧炎”类型“人物”属性有“身份-斗帝”，“功法-焚决”，“伴侣-彩鳞”，“职业”等。每个分块几百字，这种粒度是比较粗的。在跟R1的后续对话中，我了解到“实体”和“关系”是最重要的信息。知识图谱是一种结构化的信息表示方法，它将知识以节点和边的形式组织起来，节点表示实体，边表示实体之间的关系。也就是说，按照目前的技术能力，即便没有上下文窗口的限制，厂商的知识库也不是最优方案。知识库肯定是有用的，特别是对于问答系统，只是不适合网文校对的场景。

如标题所示，我们要开发的第二个AI应用是“网文校对系统”。如果开发“拍照查卡路里APP”的过程是风平浪静的话，那么开发这个“网文校对系统”则可谓一波三折。对我而言这是一个奇妙的旅程，我不但收获了新知更学会了如何跟AI沟通和协作，可能有些夸张，但我现在确实迫不及待地想把整个过程与大家分享。话不多说，下面正式开始。看网络小说是CloudMan的一大业余爱好。我特别佩服网络小说作者丰富的想象力和生产力。网络小说的篇幅一般都是以百万字为单位，而且基本都是日更4，5千。

技术方案已经确定，马上正式开发。说到开发手机APP，这可真是进入了CloudMan的知识盲区。20年前开发过Web应用，但对于移动端开发完全没有概念。前面AI推荐了React Native 或 Flutter。做了些调研，了解到它们的开发语言分别是 JavaScript 和 Dart。由于对JavaScript还算熟悉，所以我果断选择了Flutter。原因无他，就是想看看AI辅助编程的能力，看看能不能让我这样一个小白也能从零开发出像样的APP？

拍照查卡路里的教程到此就结束了，下面回顾一下要点。AI应用的能力主要取决于大模型的能力。大模型的飞速发展使得我们有能力实现前所未有的功能。即便有些功能现在无法实现，我们也可以乐观地期待大模型进步。替换后台模型非常简单。AI辅助编程非常强大。流程简单、直接：我们提需求，AI负责实现；我们提改进意见，AI负责优化；我们指出bug，AI负责修复。开发门槛大大降低，编码已不再是障碍。AI帮我完成了80%的具体编码工作。好的点子和洞察用户需求将更为重要。智能体（AI Agent）很可能会成为主流。

上一节调用“图像内容理解-提交请求”，API返回了一个task_id，本节需要调用“图像内容理解-获取结果”API获取最终结果。代码实现过程如下：result。

最近国外有一款APP在健身圈火了。功能很简单：自动识别照片中的食物并计算卡路里。团队开发加市场也就两三个人，主要用大模型实现。我就想可以把它当作教程案例，原因如下：功能单一，初学者容易上手。别人已经走通，现有大模型能实现。这里先介绍一下 CloudMan 的开发背景，便于大家对照。我工作头几年用Java开发过Web应用，不过已经是二十多年前的事了。后来一直做服务和实施，有时会编写一些Shell和Ansible脚本。总结起来就是：有一定开发经验，但欠缺最新的开发技术。

最近看了一下公众号后台，距离上一篇文章都快7年了。回看过去的几年，云计算已日趋成熟，容器技术也从互联网大厂落地到主流企业。希望 OpenStack、Docker 和 Kubernetes 这几个教程也为技术普及和推广发挥了或多或少的作用。这几年虽然没更新公众号，CloudMan 也没闲着，始终保持着对新技术的好奇心。众所周知，人工智能是近几年最引人注目的新技术。2022年底 chatGPT 和 Midjourney 刚出来的时候，大部分人（包括我自己）还只是把 AI 当作新颖的聊天或画画工具。