小伙伴们新年好啊，颓废的 2023 年总算是过去了，过去这一年因为自己的状态不太好，一直也没怎么更新，2024 年是时候重新拾起行囊再出发啦！
前言 去年年底我写过一篇《大模型小助手，Mac 工程师如何拥有自己的人工智能》，在那篇文章里我介绍了如何利用自己手头的计算资源（Mac 电脑）快速拥有一个人工智能助手，然而大多数人手头的算力是很孱弱的，以至于大家千方百计搭桥建梯想要拿到 OpenAI 这艘大船的船票。这无可厚非，但我们知道，在我们这个伟大的国家，科技一定是要讲究自主研发的，不然谈何遥遥领先。因此在去年 8 月，随着《生成式人工智能服务管理暂行办法》的正式实施， 中国自人己的生成式人工智能之路，终于从政策上给出了要求和肯定，让 AIGC 行业发展不再迷茫。
现如今经历了一年多的发展，国产 AI 已经慢慢地走向成熟，其智能体的效果已经具备了产业应用场景落地的基本条件。因此今天我准备从自己的实际需求入手，抛弃 OpenAI，使用我们国内的 AI 平台，展示一下如何使用 LlamaIndex 框架和智谱 AI 结合起来处理常见的应用场景——知识库检索。
大炼钢铁——国产大模型间的军备竞赛 ChatGPT 及其背后的 GPT4 大火之后，国内迅速刮起一阵自主研发大模型的风，先不管开源与否，目前市面上叫得上名号的就不止以下这些（排名不分先后）：
机构/公司 模型名称 百度 文心大模型 抖音 云雀大模型 智谱 GLM 大模型 中国科学院 紫东太初大模型 百川智能 百川大模型 商汤 日日新大模型 MiniMax ABAB 大模型 上海人工智能实验室 书生通用大模型 科大讯飞 星火认知大模型 腾讯 混元大模型 阿里巴巴 通义千问大模型 吕布之后，人人皆有吕布之勇。 国产大模型亦是如此，GPT4 与大国政策双向奔赴后，这些 AI 厂商都想在国内大模型这场军备竞赛中占得一席之地。...
前言 历史的车轮滚滚向前，大模型的发展让 AI 离每个人都更近了一步。今年 3 月的时候简单聊了一下 AIGC，现如今半年多过去了，ChatGPT 依旧大放异彩。无论是百度的文心一言还是阿里的通义千问，在 GPTs 面前都变成了拙劣的模仿。
现如今每隔几天就有新鲜的技术出炉，让人目不暇接，同时具备可玩性和想象空间的各种应用和开源库，仿佛让自己回到了第一次设置 JAVA_HOME 的日子，于是我便蹦出了一个对自己的工作和生活可能有帮助的想法——“拥有自己的人工智能”。
目标是搭建出一个不依赖云端服务，可以在本地运行，且效果可以接受的类 ChatGPT 服务。为什么要在本地搭建而不是直接采用现成的云服务呢？从数据安全的角度看，一些数据还是不太方便随意上传至云端的，而且云端的问题回答也会经过各个服务商审核，不可避免的会出现降智的情况。另一方面，这些在线的云服务成本较高，chatGPT plus 每个月 20 美元，还要熟练掌握各种上网技巧，虽然能力很强大，但是再没有一个完美的变现渠道的情况下，对于我的荷包来说还是有很大负担。最后对于一个工程师来说，能自己搭建一个完整的方案，使用一个自己调教出来的 AI，也是出于对技术探索的本能使然。
方案概述 由于是在本地运行的，选择一个好的设备则是第一步要考虑的事情了。笔者家中刚好有一台 2020 年 M1 芯片的 Mac Mini，一直作为家里的 homelab 长期运行。除了平时在家里用他编译代码、还会用它来设置苹果的内容缓存，提高局域网内苹果服务的连通性。如今廉颇尚未老矣，还是可以再战 AI 的。
由于 M1 芯片的统一内存架构和开源社区对 Apple 芯片在 AI 方面的支持， 如今用它作为一个本地运行大模型的载体再合适不过了。
我的方案如下图所示 👇。
在这套方案中，我采用实力排上游、并且在使用上对学术和商业都友好的国产大模型 ChatGLM3-6B 对话模型，同时使用 chatglm.cpp 对 ChatGLM3-6B 进行量化加速以及 API 协议的兼容；通过 Cloudflare 的 Tunnels 将运行在家中 HomeLab 的 service 映射至公网；使用 ChatGPT Next Web 作为 UI 层并通过 Vercel 托管网页（当然这里也可以选择下载 ChatGPT Next Web 的 desktop App 直接使用）。最后的效果如下图所示。...
前言 笔者最近在主导一个项目的架构迁移工作，由于迁移项目的历史包袱较重，人员合作较多，在迁移过程中免不了进行多分支、多次 commit 的情况，时间一长，git 的提交记录便混乱不堪，随便截一个图形化的 git 提交历史给大家感受一下。
各种分支疯狂打架宛如后宫争宠的妃子们，之所以会出现这种情况，主要还是因为滥用 git merge 命令并且不考虑后续的理解成本导致的。如今在大厂工作的程序员们，频繁接受变更的需求，一旦一开始考虑不周到，就一定会出现了大量无意义的 commit log，加上“敏捷”理念的推广，产品的快速迭代上线变成了核心指标，这些无意义的 commit log 便被“下次再处理”，久而久之就混乱不堪了。
而我们在看一些开源仓库时，会发现他们的 commit 记录十分整洁，其实这并不是社区的程序员能力更强，而是因为他们没有 KPI 大棒的鞭笞，在提交代码前会花时间整理自己的 commit log。而这就是本文的主角了——“Git Rebase”。
git rebase 和 git merge git rebase，中文翻译为“变基”，通常用于分支合并。既然提到了分支合并，那就一定离不开git merge这个命令。
相信每个新手程序员刚进入职场的时候，都会听到“xxx 你把这个分支 merge 一下”这样的话。那么问题来了，假如你有 6 个程序员一起工作， 你就会有 6 个程序员的分支， 如果你使用 merge, 你的代码历史树就会有六个 branch 跟这个主的 branch 交织在一起。
上图是 git merge 操作的流程示意图，Merge 命令会保留所有 commit 的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是 merge 的命令初衷就是为了保留这些时间不被修改。于是也就形成了以 merge 时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录，主分支上只保留 merge 的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge 某 branch 到某 branch 上了。这个历史记录描述基本上是没有意义的。
而 git rebase 中文翻译为“变基”，变得这个基指的是基准。如何理解这个基准呢？我们看一下下图。...
如今的内容型产品，不管提供的是什么类型的内容，在其主功能之外，不可避免的会有另一个十分重要的功能——消息中心。
而无论是信息流、论坛、信箱，还是私聊、群聊、通知，推拉模型是内容型（包括：社交型）产品架构的核心。做出正确选择的关键在于对产品形态和系统组件清晰的认识。
今天我们将重心放在消息中心上，聊一聊如何设计一个消息中心。
需求分析 消息中心通常会有两个功能（如下图所示）：
用户通知（点赞、评论、关注、@等） 官方通知 接下来我们将会对这两类通知进行一个简单的抽象。
首先，可以确定的是，对于用户通知，每个用户都不一样（我的点赞列表和你的点赞列表肯定是不一样的），因此对于每个人我们都需要维护一个「收件箱」。
当 A 点赞了 B 的内容，后端系统在收到了这一个点赞消息后，会将点赞信息写入 B 的 「收件箱」，并标明这是 A 在 xxx 时点赞的 xxx 内容。这是一个系统将消息 推送 给 B 的过程。
而对于官方通知，每个人（几乎）都是一样的（用户有可能设置了屏蔽，系统也可能指定了发送人群），并且官方通知是由系统自然下发的，因此对于系统来说需要维护一个系统**「发件箱」**。
发件箱维护了官方想给用户的通知，每次打开消息中心时，用户都会主动来系统**「拉取」官方最新的消息，并和用户自己的「收件箱」里的官方通知进行比较，以确认是否已读该条通知。这是一个用户主动从系统「拉取」**通知的过程。
推拉模型 其实到这里就已经点出了这两个场景背后的一套模型——推拉模型。而之所以在这两种场景选择不同的运行机制，其实背后牵扯到的是读写扩散的问题。
推模型 先看推模型，对于任何一个内容创作者来说，最开心的事情莫过于打开软件会有一堆点赞/评论的小红点。对于大 V 来说，打开 App 查看点赞消息的频率根本比不过别人给你点赞的频率，这是一个很典型的读少写多的场景。每当有一个用户点赞该大 V 时，都会将索引信息（一般为内容 ID、类型、发表时间等索引数据）写到用户的收件箱中。
优点：读很轻。仅需要读取消息列表即可。 缺点：写很重。一旦用户的内容质量很高，可能会收到大量的点赞/评论，会有大量的写入操作。 拉模型 再看拉模型，以官方通知为例，一般官方通知是由运营人员发布的，一个月可能也不会有几条，但是每次用户进入 App 时都会看看是否有新的官方通知进来，这是一个很典型的读多写少的场景。
优点：写很轻，节省空间。系统只需维护一个属于自己的消息列表即可。 缺点：读很重，计算量大。假设可以发送官方通知的生产者较多（例如淘宝里的一系列官方业务），则每次都需要从这些消息生产者里拉取最新的内容。 流程设计 用户通知 对于用户通知，流程设计如下：
对于该流程，有几点需要注意的：
异步发送 当用户出发了点赞/关注/评论行为时，被点赞/评论/关注的用户，其实不需要立即感知，因此也不需要立即将互动信息写入该用户的收件箱中，因此可以考虑以消息队列的方式通知出去，缓解系统压力。
缓存前置 写入消息时，如果直接写入用户收件箱，可能会导致用户在请求消息列表时，将请求全部打到 DB，造成系统故障，因此通常会在更新用户收件箱时双写用户缓存。
官方通知 相较于用户通知，官方通知由于引入官方运营这一角色，操作上会稍微复杂一些（如上图所示），因此整个系统的设计也会稍微复杂一些。...
前言 对于云端编程，我想大多数人的第一想法应该是微软推出的 VSCode Remote，这个功能基于开源的 VSCode，通过 SSH 远程连接到服务器，开发者可以通过端口转发、SCP 等一系列实用功能快速实现远程开发。我曾体验过这种编程方式，极大减轻了电脑性能的压力，但我认为这并不是云端编程的最终形态，因为我仍然需要在自己的电脑上安装 VSCode 才可以使用这个功能。
最近 2021 款的 iPad Pro 上市了，这次搭载的是和 Mac 同款的 M1 芯片，性能强大到甚至有让人利用 iPad 编程的想法，只是迫于各大厂商没有推出适配 iPad 的 IDE，便也只能沦为“买钱生产力，买后爱奇艺”的工具了。那么有没有什么办法可以在不安装 IDE 的情况下使用 iPad 编程吗？自然是有的，JetBrains 公司提出了一种新的解决方案：把 IDE 搬进浏览器里。这便是本文的主角——JetBrains Projector。
发展 提起 JetBrains，你会想到什么？各路强大的 IDE，比如 Android Studio、IDEA、WebStorm……这些对于开发者来说耳熟能详的产品都出自这家公司，这些 IDE 的功能强大，但同时也只能运行在用户自己的电脑上，其“内存黑洞”的称号更是让开发者们又爱又恨。
事实上，目前所有的 JetBrains IDE 都使用 Java Swing 绘制 UI，其他基于 IntelliJ 的 IDE 也是如此，比如 Android Studio。鉴于 Swing 是 Java GUI 的一个库，而 Java 本身就是一门很吃内存的编程语言，虽然可以充分利用 Java 跨平台的特性，这也是这些 IDE 在 macOS、Windows 和 Linux 上 UI 几乎一致的原因。但现在，Swing 跨桌面平台的特性却也成为阻碍其发展的一个原因了，在一些瘦客户端的情况下，“内存黑洞”屡屡被人诟病，Swing 也无法发挥其优势，于是 Projector 便应运而生了。...
事先说明，该篇文章中的代码是我无意中发现的，这里仅做一个分享，文末会给出参考文章，不喜勿喷。
完整源码和预训练模型可在公众号：「01 二进制」后台回复：「AI 换脸」获取
前言 作为一个经常逛 b 站的肥宅，前段时间无意中看到了一个名为"换脸哥"做的换脸视频，让杨幂“穿越”到了 1994 年版的《射雕英雄传》里，“代替”了朱茵，“出演”了黄蓉这个角色。视频如下（b 站视频已经被删了，只能转载知乎的视频了，原地址是杨幂“换脸”，AI 换脸究竟有多可怕 - 科技富能量的文章 - 知乎）：
看完我便虎躯一震，这也太厉害了吧，这种技术一旦流行起来，ab 不用去片场就能拍戏了啊，真的是躺着赚钱啊。这要是运用到 H 片上，岂不是 😅😅😅
言归正传，作为一个 coder，在看到这个视频之后我就很想知道这究竟是怎么做出来的，在查阅了一些资料后，我才发现最悲伤的事情莫过于，好不容易把源码找到了，数据集下载好了，结果显卡带不起来…
Tips：这里给出我之前找到的两个有关视频换脸的仓库，有兴趣的自己去了解下：
deepfakes_faceswap
FaceIt
既然条件不允许，那我们只能降低成本，既然视频里的脸不好换，那就退而求其次，换一下图片里面的脸，果然在我的苦苦寻觅后，我找到了一个低配版的 Python 换脸大法：
《Switching Eds: Face swapping with Python, dlib, and OpenCV》
以下内容均参考上述所标注的文章，在这感谢原作者。
接下来我将会介绍如何通过一段简短的 Python 脚本（200 行左右）将一张图片中面部特征自动替换为另外一张图片中的面部特征。
具体过程分为四个步骤：
检测面部标志； 旋转、缩放和平移图 2 以适应图 1； 调整图 2 的白平衡以匹配图 1； 将图 2 的特征融合到图 1 中； 实验环境 MacOS 10....
上一篇介绍了图像风格迁移的一个最基本实现，虽然在控制台实现了功能，但是想要实际使用，应用到一个app或者网页上光靠上一节的内容肯定是不行的。那怎么样才可以将风格迁移这个功能变成一个可以实际使用的小程序呢？不着急，在实现上述功能前，我们先来介绍一个小东西，也就是这篇文章的主角，我把他称为"毕业设计大杀器“的Flask框架。
前后端分离 在介绍Flask之前，我们先介绍下什么是前后端分离。因为如果不介绍前后端分离就不会理解为啥要选择Flask了。前后端分离是目前互联网项目开发的标准使用方式，其核心思想简单理解为是前端页面（或者app等多端）通过ajax（或者其他请求方式）调用后端的restuful api接口并使用json数据进行交互。其目的是为了将项目解耦合，达到**“术业有专攻”**的效果。因为在以往的web项目中，后端人员的工作量非常大，用过jsp的人都知道，那真的是又当爹又当妈，既要会写后台逻辑还要会弄样式。但是采用了前后端分离的架构之后，前后端人员就可以各司其职了。
前端人的追求 前端追求的是：页面表现，速度流畅，兼容性，用户体验等等。
把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，设计模式，浏览器兼容性，性能优化等等。
后端人的追求 后端追求的是：三高（高并发，高可用，高性能），安全，存储，业务等等。
把精力放在语言基础，设计模式，底层原理，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构，弹性计算架构，微服务架构，性能优化，以及相关的项目管理等等。
应用服务器、Web服务器、Restful 应用服务器：一般指像tomcat，jetty这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。
Web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。
静态资源就是类似于html、js、图片这些多次访问也不会变化的资源
一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。
RESTful REST的全称是representational state transfer，即表征状态转移。在理解这个名词之前我们先来看几个名词（感觉需要知道的前置知识好多啊）。
资源(resources) 所谓的资源就是网络上的一个实体，它可以使一个图片，一个文本，一个服务，你可以用一个URI指向它，每种资源对应一个特定的URI，要获取这个资源访问它的URI就行了，所谓的上网，其实就是与网络上的资源进行一系列的互动就是了。
表征(representation) 怎么把资源表现出来就是表征的意义，比如一段文本是txt、html还是json，图片是jpg还是png，以http协议为例，就是Accept和content-type中的内容，说明了资源的类型。
状态转移(state tranfer) 访问一个网站，就是客户端和服务端的一个交互过程，客户端想要操作服务端，就必须通过某种手段让服务端的状态发生变化，具体到http协议中就是http的几种方法：GET用来获取资源，POST用来新建资源，PUT用来更新资源，DELETE用来删除资源。
理解RESTful 使用URI来表示每一个资源 为每一个资源确定它的表现形式 使用4个方法来操作这些资源 什么是Flask？ 介绍完前后端分离后，我们就开始介绍下Flask是什么吧。
Flask是一个使用 Python 编写的轻量级 Web 应用框架。其 WSGI 工具箱采用 Werkzeug ，模板引擎则使用 Jinja2。Flask也被称为 “microframework” ，即**“微框架”**，因为它使用简单的核心，用 extension 增加其他功能。Flask没有默认使用的数据库、窗体验证工具。
理解下"微” “微"框架中的“微”(micro) 并不表示你需要把整个 Web 应用塞进单个 Python 文件（虽然确实可以 ），也不意味着 Flask 在功能上有所欠缺。微框架中的“微”意味着 Flask 旨在保持核心简单而易于扩展。Flask 不会替你做出太多决策——比如使用何种数据库。而那些 Flask 所选择的——比如使用何种模板引擎——则很容易替换。除此之外的一切都由可由你掌握。默认情况下，Flask 不包含数据库抽象层、表单验证，或是其它任何已有多种库可以胜任的功能。然而，Flask 支持用扩展来给应用添加这些功能，如同是 Flask 本身实现的一样。众多的扩展提供了数据库集成、表单验证、上传处理、各种各样的开放认证技术等功能。Flask 也许是“微小”的，但它已准备好在需求繁杂的生产环境中投入使用。...
上一篇文章中我们已经利用 Flask 制作了一个 RESTful API，然而文中末尾我们我们将代码运行起来的时候确发现是 localhost:xxxx，这也就意味着我们没法通过外网访问我们提供的 API，所以这样做出来的程序即使部署到服务器上也没有任何用处。这一篇我们就来详细的说下怎么部署到服务器上然后实现外网访问吧。
环境准备 工欲善其事，必先利其器。还是老样子，既然要选择部署到服务器上，我们首先肯定得要有一个服务器，这里我选择 XX 云的学生机（别问为什么，问就是便宜）。系统选择 Ubuntu18.04，需要安装的东西有：
Python 3.6 Nginx pyenv pipenv Flask + Gunicorn 这里我们用 pyenv 管理不同的 python 版本，这里可能就有人要问了，Ubuntu 不是自带 python2 和 python3 吗，为什么还要用 pyenv 来管理，之前的文章我们也说过，用 pyenv 管理 python 会非常的方便，方便到只需要一行代码就可以安装切换系统的 Python 版本，废话不多说，接下来就开始我们的操作吧。
连接到远程服务器 如何购买 XX 云的云主机我就不多说了，当你买好之后我们在后台查看到我们购买的云主机的外网 IP，比如我的服务器的外网 IP 地址就是94.191.9.43（希望各位大佬手下留情，别弄他）：
接下来就是连接到服务器了，工具有很多，xshell、putty 或者 terminal 都可以，这里我推荐一个工具Termius，推荐他的原因有两个：颜值，作为一个颜控，Termius 是我见过的最好看的 SSH 客户端，没有之一。同时还是跨平台的，win/mac/linux/android/ios 都支持，这点不知道比 xshell 高到哪里去了。
连接也很简单，我们在 termius 中添加需要连接的 host，然后输入用户名和密码即可登录了，出现如下字样说明登录成功。
利用 pyenv 安装制定版本的 python 之前的文章介绍过如何在 mac 下安装 pyenv，虽然 linux 下的安装方法类似，但毕竟本文的题目是是从 0 到 1 部署，还是再详细说一下吧。...
Photo by Tim Gouw from Pexels
正如文章标题所言，本文是我的**《AI画家》**系列的终章，从4月16号开始的第一篇文章《介绍一下我的毕业设计》到今天已经过了将近2个月了（2个月就更新7篇文章我也是服了我自己了😂），其实这个系列就是我的毕业设计，如今我的毕设做完了，论文也定稿了，想着也该给这个系列画个句号了。
在公众号上发系列文章是我的一次尝试，因为知道自己的文笔不好，写不好什么感悟感想，只能水水技术文了，然而即使要写技术文也得找个切入点，可事实上哪会有那么多切入点，无奈只能靠弄个技术文系列，吸引下路人的眼球，勉强度日了。
既然是终章，那就对整个系列做个简单的总结吧，希望这篇不会是烂尾文。
开题 在《介绍一下我的毕业设计》一文中我提到，刚开始我单纯因为觉得好玩才开始研究图像风格迁移，后来认为名字逼格够高，足够唬住老师才把这个课题作为我的毕设，现在回过头来结合最后的答辩觉得自己选这个题目的毕设是真的傻X，不是因为这个选题不好，而是把这个选题作为毕业设计的题目真的傻X，说到这就想起一些在答辩现场不好的事情了，溜了溜了。
过程 作者自认为在这个系列中思路还是比较清晰的。
首先是第一弹，想要做深度学习有关的东西，刚开始肯定是要搭建好一个深度学习的环境的。在这篇文章中，详细的介绍了在我的游戏本上利用GPU搭建深度学习环境的过程，包括安装nvidia drive、CUDA、cuDNN和TensorFlow的GPU版本，以及简单介绍了如何利用Pyenv和Pipenv管理自己电脑上的Python虚拟环境。
然后是第二弹，介绍了什么是图像风格迁移，以及如何用TensorFlow实现了一个基本的图像风格迁移的程序，在这篇文章中我只是简单的介绍了图像风格迁移的原理，一方面是因为公式实在是有点多，公众号对于公式的支持不是很好，另一方面作为一个入门介绍，放太多的数学公式的话估计本来人数不多的公众号又要取关一批人了。
第三弹介绍了一个目前非常流行的Python web框架Flask，介绍他的原因不仅仅是因为我的毕业设计就是用这玩意做的，而且在开题的时候我也提到了最后要将这个深度学习算法落地，能够做出一个可用的RESTful API，而相较于其他Web框架，Flask有着得天独厚的优势：首先TensorFlow的首选语言是Python，Flask也是用Python写的，调用起来非常方便；相对于Django，Flask非常轻便，使用起来也非常的灵活。然而在用Flask之前，必须要有些基础知识，因此在这篇文章开篇，我又介绍了前后端分离，介绍了什么是RESTful API，如果对这些概念没有理解的话就算把代码写出来了也很难知道是干嘛的。
既然在第三弹介绍了一个用来编写RESTful API的工具，那第四弹自然就是如何编写这个RESTful API了。其实在第二弹中就指出了那个算法的不足之处——“慢”，所以在这篇文章中就使用了第二个算法训练出来的模型，之所以不介绍新的风格迁移算法，主要是因为这个算法有点难度，我理解的时候也花了好长时间，等到基本上理解了，第四弹都已经写完了😂。所以在这篇文章中我干脆直接用别人训练好的现成的模型了。其中介绍了如何利用蓝图（BluePrint）进行模块化开发，并给出了我自己认为的比较好的分层方法，然后利用七牛云存储为服务器减压，最后利用Postman请求该API完成测试。
第五弹的主要内容就是介绍如何将第四弹中已经在本地测试成功的项目发布到服务器上实现公网访问，介绍了如何使用了XX云主机，并在上面安装配置了项目所需要使用到的环境的过程，介绍了Termius、FileZilla等工具。在这篇文章中我希望会有些和别的文章不一样的东西，因此我不仅把实现过程展现了出来，还分享了一些我在实际使用过程中产生的疑问，踩到的坑以及我个人在部署过程中总结的一些经验。
最后 总的来说，这个系列不仅仅是我在做毕业设计时的一个缩影，也是我自己对于公众号运营的一个探索。期间也收到了很多读者的支持与鼓励，感谢你们的一路陪伴🙏
推荐阅读
《介绍一下我的毕业设计》 《AI 绘画第一弹——用GPU为你的训练过程加速》 《AI绘画第二弹——图像风格迁移》 《AI画家第三弹——毕业设计大杀器之Flask》 《AI画家第四弹——利用Flask发布风格迁移API》 《AI画家第五弹——从0到1部署你的RESTful API》
上篇文章介绍了python web开发中经常使用到的一个框架flask，如果有遗忘的，可以点此回顾👉AI画家第三弹——毕业设计大杀器之Flask，本文的主要任务就是完成上篇文章末尾的要求，利用Flask发布你自己的风格迁移API。
本文源码可在微信公众号「01二进制」后台回复「风格迁移API」获得
需求分析 我们知道软件工程的第一步就是需求分析，放在这里就是要知道我们需要实现的功能是什么样的。我画了一张简陋的图来描述这次的需求：
真的是很简陋的一张图啊，其实理解起来很容易，就是用户上传一张图片，Flask获取到这张图片，调用风格迁移的模型，然后生成结果图，在传递回前端即可。
环境准备 既然明白了需求，那么接下来要做的事情自然是环境搭建了，老样子，这里我们仍然使用Pipenv来创建虚拟环境，如何搭建pipenv环境我就不说了，在微信公众号「01二进制」后台回复「风格迁移API」获得源码之后直接在终端输入pipenv install即可。
开始 hello world 我们首先在项目根目录创建一个main.py的文件作为整个项目的启动文件，上文我们说过，为了简化大型应用并为扩展提供集中的注册入口，我们并不会将所有的视图函数直接写在main.py，而是采用蓝图的方式分模块开发，因此我们需要在项目根目录新建app/文件夹，在其中的__init__.py中编写如下代码：
from flask import Flask def create_app(): app = Flask(__name__) return app 这样我们就可以通过在main.py中编写如下代码实现一个hello world应用了。
from app import create_app app = create_app() @app.route('/') def hello(): return 'hello,world' if __name__ == '__main__': app.run(port=8080, debug=True) 启动main.py即可发现项目启动了，在浏览器输入localhost:8080即可看到hello,world字样。
蓝图编写 我们肯定是不能满足于小小的hello world的，既然说到了模块化开发，那怎么个模块法？
这里每个人的想法都是不一样的，其实也没有一个统一的标准，这里我就说下我自己的分级方法吧。
stylize是项目根路径 app是项目 app/api是项目的api部分，一个项目肯定不只有api，还可能会有web等页面内容 app/api/v1表明该api的版本是v1，当然日后也有可能会有v2、v3等等 app/api/v1/img表明这里存放的都是和img有关的api app/api/v1/img/stylize.py表明这个文件存放的是风格迁移的视图函数 认识完结构的划分之后，就来编写我们的蓝图吧。
首先我们需要在app/api/v1/img/__init__.py中编写如下代码：
from flask import Blueprint # 定义一个蓝图 img = Blueprint('img', __name__) from app....