用AI快速构建Discord机器人凭证分发系统的实战演示
AI Coding

用AI快速构建Discord机器人凭证分发系统的实战演示

M
Manuel (AI应用开发者) | 主持人: Zach
2026年5月5日YouTube
返回首页

金句精选

「我认为这不仅仅是错误的,它还有害。它给人们一种非常奇怪的认知——AI更像是一个人而不是工具。」

「使用AI进行氛围编码的有趣之处在于,挑战在于你到底想做什么?我们真正想让这些东西做什么?」

「我今天早上氛围编码了这个应用程序。我想要一个应用程序来为人们分发和创建机器人凭证,因为我知道如果你之前没做过,这很令人厌烦。」

「没有任何alpha测试人员,所以你们将体验所有这一切。我们看看它是否有效。」

「我用AI做了大部分工作。第一步是解释这个注册界面如何工作,然后第二部分是一旦你有了凭证,你就可以开始为自己编写机器人了。」

夜已深,房间的光线被屏幕照亮。Manuel坐在桌前,手边是一杯冷掉的咖啡,Discord的消息窗口和代码编辑器分列于显示器两侧。直播间人数不多,却气氛松弛。他一边和Kevin闲聊,一边开启了这场小型的「AI辅助编程」实验:现场用AI从零搭建一套多玩家文字冒险游戏的Discord机器人。

这并不是一次精心彩排的演示。Manuel坦言,连最基础的流程都没找人测试过,甚至框架的升级也是直播前五分钟刚刚推上去。观众们像是临时受邀的「小白鼠」,一头扎进了这套新鲜出炉的流程——先用他临时写的小工具,自动领取各自的Discord bot令牌,再跟着一份简单的教程Clone代码仓库。甚至,连发放令牌的流程都是半自动、半手工结合,Manuel笑称自己是「租来的人工验证码」。

细看这套工具的实现过程,满是AI生成代码的痕迹。从UI设计到后端逻辑,Manuel大部分都交给了GPT-4.5(“GPT55 low”)来完成。他描述得轻描淡写:早上心血来潮,prompt了一句「做个能帮大家一键申请Discord bot账号的前端UI」,然后把AI产出的图片丢进了自家基于Python的web框架。代码的底子由AI打好,他只补上了些Tailwind的细节和自己的常用技巧。这个小App用来发放bot凭据,没做太多复杂校验,也没追求什么极致安全,就是一个即插即用的「内部小工具」——正如他坦言,「只是为了把流程凑齐,能给大家发号」。

AI在这个场景下的角色,很像一个极高效、但尚未成年、需要时时盯着的实习生。它可以迅速产出可用的UI雏形,关键业务流程也能完成七八成,却多数时候需要有经验的人帮忙「擦边」,比如手动注册bot、补全配置、处理一些微妙的Discord权限问题。Manuel甚至把令牌发放的部分自动化脚本也交给AI生成,并用Playwright做了浏览器端的自动化,但执行时还常常卡在需要人工输入验证码、或Discord后台突发的小变动上。

整个实验的核心,其实不是「让AI独立造一个Discord bot」,而是如何让AI和人高效协作,把琐碎重复的低附加值环节全都自动化出去。比如,用户只要在前端填好信息,后端就能自动生成四项关键参数——Client ID、Secret、Token、Public Key——并存进数据库,再以一个「一键邀请」的链接发给用户。剩下的权限管理、服务器部署、bot邀请进群,都可以在几分钟内走完全部流程。这种效率,是以往手动注册、配置、发放bot时难以想象的。

Kevin在实验中扮演了「小白」和协作者的双重角色。他一边照着AI生成的文档走流程,一边提出自己的需求:比如,希望bot能支持用YAML来定义冒险场景,每个场景可以通过大语言模型动态生成内容。他甚至尝试让AI帮他脑暴bot的整体结构,比如如何把每个互动步骤写成独立的「对话节点」,让多名玩家可以各自选择行动分支。

这时,AI辅助编程的「边界」变得清晰起来。AI可以很快给出一个JavaScript或Go的基本bot模板,帮你搭好消息监听、事件回调、指令注册等底层框架。Manuel做的设计是用Go写底层通信、鉴权和沙箱环境,再把业务逻辑封装进一个可热加载的JavaScript沙箱里。这样一来,AI产出的代码无需关心底层协议,只要填好「定义bot」的函数和命令回调即可。甚至,沙箱环境默认连console.log都没有开启,安全性和扩展性都被人为收紧和控制。

但当Kevin想要让AI帮忙设计更复杂的「多玩家分支剧情引擎」时,AI给出的方案就变得偏向理想化:比如用YAML描述所有剧情节点,再自动解析成互动事件、按钮、分支。可惜Discord的消息与组件系统远比想象中复杂,场景状态存储、玩家同步、消息队列都不是一句prompt就能解决的。此时,AI的建议可能只是一个「八成正确」的雏形,剩下的二成,仍然要靠经验和细致调试来补全。

令人印象深刻的,是AI在细节层面展现出的「高容错性」。比如,AI在第一次生成bot代码时会漏掉一些必要的权限声明,或者搞错某些API入参,但只需稍加提示,它就能快速修正并补全。即便如此,这种「对话式编程」依然充满了反复验证和人机配合的时刻:每次改动都要重新部署,遇到沙箱权限问题要加装native模块,数据库存储、YAML解析、界面组件都要逐一试错。

最让人感到「AI味」的一个场面,是Kevin正试图让bot把程序分为「服务器底层Go处理、JS业务沙箱、AI动态生成剧情」三层协作时,AI在prompt中直接建议他怎么在Go侧暴露API、在JS侧注册命令,甚至连沙箱里能否开启文件系统、数据库、YAML解析模块都考虑进去了。而这些,其实都是Manuel预先设计好的安全沙箱,AI只是根据文档和代码上下文自动补全了这些「内部规则」,协作效率高得让人不禁反思:开发者和AI,究竟谁才是「需求的源头」?

直播的最终结果,是一套足够灵活但远未完善的多玩家文字冒险游戏bot雏形。参与者可以用AI一键生成机器人,快速拉进Discord服务器。业务逻辑部分则通过AI辅助生成的JavaScript代码来定义,遇到需要复杂交互时再人工补全。整个过程用时不过几小时,几乎没有人力在「低价值琐事」上反复浪费,更多的时间留给了产品想象、体验优化与新交互方式的探索。

这种人机协作的速度和效率,已然颠覆了传统「全栈开发」的边界。AI不是要取代开发者,而是成为他们手中那柄能随时变形的瑞士军刀。你只需描述场景、定义规则,AI就能把99%的重复劳动和出错环节接管过去。但当需求走到未知领域,或者必须打磨交互细节时,你又会发现那1%的「人类判断」和经验,依然不可或缺。

也许未来的开发者不再需要精通每一行代码,但却要像今天的Manuel一样,善于让AI成为自己的影子工匠和问题终结者。只是,这样的协作关系,会不会反过来改变我们对「创造」本身的定义?