被灵感突然袭击,于是我连夜做了一个游戏 -《完蛋!我被高考古诗词拿捏了》

好记性,不如 烂笔头,不如趁热记录下,给未来的自己。

前言

书接上文《千古绝句的意境,用AI来传承 | 通过 AIGC 作画,生成古诗名词的场景》,我们看到了AIGC作图和中华文化瑰宝古诗词结合所迸发出来的创意。其实围绕这个点,有很多有意思的点可以拓展:

  • 比如举办 AIGC 古诗作画大赛,让大家自己去创造那些千古名句的横空出世时的场景,投票选出自己心目中最合意境的图片;
  • 比如收集那些高票当选的图片,写一个游戏,让大家根据图片来答题猜测最符合图片意境的古诗词

等等,什么?根据图片猜古诗词?好像挺不错的:工作多年的打工人,即将中/高考的学生,教书育人的老师,为孩子学习操碎了心的家长,都可以在这个游戏里找到自己~

灵光乍现,说干就干

方案敲定

首先对这个游戏定了几个特性:

  1. 不用安装,不用注册,不用登录;
  2. PC/移动端,随时随地,有网就能玩;
  3. 有社交属性,便于分享;
  4. 快速实现,快速上线;

根据以上特性,技术选型的范围就很容易收窄了,

  1. 传统的 native 移动端APP开发:需要安装,只能移动端使用,iOS/Andorid 版本分别开发,工作量大,需要审批,无法快速实现,快速上线;
  2. H5开发:虽然不需要安装,也支持PC和移动端访问,但是前后端分离,需要分别写前/后端,需要硬件资源和网络资源部署,工作量大,无法快速实现,快速上线;
  3. 微信小程序:社交属性强,容易裂变,但是需要各种审批,无法快速上线;

常见的方案,都或多或少有不满足的地方,那怎么办呢?这里,其实可以用 Gradio 框架,用 python 语言来实现前后端一体的APP,快速开发,然后部署在可以托管 Gradio 应用的平台上。

Gradio 应用托管平台国内外还挺多的,比如国外最有名的是 huggingface (俨然是AI大模型时代的Github了),但是由于某些原因,在国内访问hf的体验并不是特别棒。。。国内也有类似的,这里我用的是 OpenXLab-应用中心,界面很清爽。

设计界面

脑子里有想法,但是具体编码的时候,怎么布局,怎么交互,其实都比较模糊。所以需要用工具去捋一捋思路。这里推荐给大家一个在线画图工具 Excalidraw(为啥选这个?简单好用,出图漂亮,不中规中矩,平时也都用这个画架构图)。

编码实现

技术选型:基于 python3.10 + gradio4.12 + redis。用 python 调用 gradio sdk,用 gradio 实现页面布局和业务逻辑实现,物料存放在 redis 里。存储方面,也考虑过其他组件,如mysql,sqlite等,但是考虑到快速实现的成本和物料更新的便捷性,这里还是用了 redis + hash存储。

那么接下来就是学习 Gradio 怎么开发,借助其文档,一步步实现产品经理(自己)提的需求(有一说一,为什么官方文档这么难读,知道的知识点写得很详细,想看的技术细节一笔带过orz...)。

csharp 复制代码
def add_student_info():
    #do biz 
   
    
with gr.Blocks() as iface:
    # layout
    gr.HTML("description here")
    with gr.Tab("挑战者报名"):
        with gr.Row():
            ...
        start_kaoshi_button = gr.Button("报名!")
    with gr.Tab("开始挑战"):
        with gr.Row():
            ...
    with gr.Tab("全国排名-TOP100") as global_rank_tab:
        ...
    ```
    start_kaoshi_button.click(
        fn=add_student_info,
        inputs=[obj1],
        outputs=[obj2]
    )

以上是框架代码。如果本文的阅读数超过 10k 或者点赞数超过 100,我将在评论区提供源代码地址:》

最终呈现

欢迎在线体验

心得

写这篇文章的同时,脑海里也同时在复盘这个项目,有几个心得,与大家分享

技术方面

  1. Gradio 这个框架的应用场景不会被限制在 AI 领域,在其他工程领域也有很大的应用空间;
  2. Gradio 框架的核心思想 = 函数 + 输入 + 输出(我的浅薄理解。。)
  3. 复杂的 Gradio 页面开发,用高度封装的 Interface 组件实现会比较困难,这里需要用到更底层的 Block 组件,可以更加灵活的组装页面。

非技术方面

  1. 找0:一个好的想法=成功了一半=决定了这件事的上限(纵观国内,执行力强的比比皆是,创作创新的寥寥无几)
  2. 快速0到1:有想法就立刻行动,快速rush一个mvp版本出来,降低试错周期(不做思想上巨人,要做行动上的强者)
  3. 持续1到100:快速出的东西,一定有为了速度而妥协的地方(比如代码鲁棒性,比如功能完整性),所以需要再去精雕细琢完善一下,才能更接近上限。

以上。

相关推荐
庸俗今天不摸鱼几秒前
【万字总结】前端全方位性能优化指南(十)——自适应优化系统、遗传算法调参、Service Worker智能降级方案
前端·性能优化·webassembly
Asthenia04126 分钟前
由浅入深解析Redis事务机制及其业务应用-电商场景解决超卖
后端
Asthenia04127 分钟前
Redis详解:从内存一致性到持久化策略的思维链条
后端
黄毛火烧雪下7 分钟前
React Context API 用于在组件树中共享全局状态
前端·javascript·react.js
Asthenia04127 分钟前
深入剖析 Redis 持久化:RDB 与 AOF 的全景解析
后端
Apifox18 分钟前
如何在 Apifox 中通过 CLI 运行包含云端数据库连接配置的测试场景
前端·后端·程序员
一张假钞20 分钟前
Firefox默认在新标签页打开收藏栏链接
前端·firefox
高达可以过山车不行21 分钟前
Firefox账号同步书签不一致(火狐浏览器书签同步不一致)
前端·firefox
m0_5937581022 分钟前
firefox 136.0.4版本离线安装MarkDown插件
前端·firefox
掘金一周25 分钟前
金石焕新程 >> 瓜分万元现金大奖征文活动即将回归 | 掘金一周 4.3
前端·人工智能·后端