
这篇文章将详细分享我是如何借助 AI 辅助开发工具和 DevBox,在三周业余时间内,从一个编程经验有限的运维,成功捣鼓出一个 WAF 防火墙 Demo 的完整历程和心得体会。希望能给像我一样,懂些技术概念但编程实践不足的朋友们一点启发。
最初的火花:一个 WAF 的需求
我是一个小运维,日常在各个群里巡逻,到处看看有没有啥 “火情” 需要救。
某天有个同学问我,“咱 Sealos 上面有没有 Web 防火墙 (WAF) 可以用啊?”

我打开一看还真没有,于是想开发一个 Web 防火墙 (WAF) 的想法就冒出来了,作为一个运维,接触的技术名词和知识还真不少,平时跟人聊技术,什么 K8s、Docker、微服务,名词一套一套的,听起来好像挺唬人。可真要撸起袖子写代码,那水平……基本上就是 “Hello World” 专业户,顶多再写个自动化脚本。
开发一个正儿八经的 “产品”?这步子迈得也太大了,刚冒出的想法又缩进去了。不过这事没完。
AI 的“诱惑”:点燃 WAF 开发的火花
搁置的那几天里,我的朋友圈、技术群、各种资讯 App,简直被各种关于 AI 的文章刷屏了!什么 “卧槽!程序员要完蛋了,饭碗要被 AI 抢了!”、“从零开始 AI 全部搞定!”、“我一行代码没写,全靠 AI 生成!”……
一开始看吧,心里还挺焦虑的:“我去,AI 真这么神了?程序员是不是真要下岗了?”
但转念一想,如果 AI 真的这么牛,能搞定这么多事儿……那它能不能……帮我写个 WAF 呢?这个想法让我对 AI 编程 产生了浓厚的兴趣。
于是我开始搜索了解各种如何使用 AI 写代码相关的知识,通过一顿搜索发现借助 AI 开发一个 WAF 防火墙似乎也不是很难。
首先我问 AI 开源的热门 WAF 检测引擎有哪些,下面是 AI 的回答(这里我使用的是类似 ChatGPT 的大语言模型):

后面我又让 AI 根据维护频率,难易程度,好不好用等对他们进行一一的总结,同时我去这些项目把他们的 README 丢给 AI,让 AI 给出总结和使用 demo,最后发现 Coraza 这个是最简单的,文档也全,是 Go 写的,使用 demo 也简单,于是就选它了。
后面我继续与 AI 交流得出了一个技术路线,写一个 WAF 需要一个前端,一个后端,一个检测引擎。
因为检测引擎是 Go 写的,所以后端也使用了 Go 的 Gin 框架 (AI 给的建议),技术路线确认了,又有了 AI 加持,再加上之前看了一堆洗脑文章,我感觉我信心爆棚。
中间有一个小插曲,AI 给出 demo 代码时,我需要一个运行环境来跑他,但是有时候 AI 给出的 demo 跑不起来,需要把报错丢给 AI 进一步调试,这期间 AI 有时候会给一堆命令,我不是专业的开发,所以 AI 给什么我先把他给的命令跑一遍再说,出了问题再丢回给 AI。
这样就有一个问题了,这样一来二去我电脑的环境就乱七八糟,装了一堆我也不知道有什么具体作用的工具。
这个时候我想到了我公司的产品 DevBox。
DevBox:我的“无限试错”秘密武器与 AI 开发的完美搭档
Devbox 是啥?简单说,它就是一个远程的、云端的开发环境。就像给你一个云上的、专属的、干净的“虚拟电脑”来写代码、跑程序。这对于进行 AI 辅助编程 时的环境管理至关重要。

现在写这篇文章回头看来,当时选择 DevBox 真是太正确的选择了,用 Devbox 来配合 AI 干活,简直完美解决了我的痛点:
- 需要跑 AI 给的 Demo 了? 没问题,秒开一个全新的 Devbox 环境。里面干干净净,啥也没有。
- AI 给的命令需要在特定环境跑? 好说,在 Devbox 里随便折腾!装包、改配置,想怎么来怎么来。
- 跑了几十次 AI 修订的 Demo,环境又被搞乱了? 小事,直接把这个 Devbox 删掉! 对,你没听错,就是删掉!
- 需要继续尝试? 再秒开一个新的、干净的 Devbox!又是干干净净啥也没有!
整个过程,就像是你有了一个无限次使用的、用完即弃的“草稿箱”!再也不用担心把自己的本地电脑搞得乱七八糟,再也不用花大把时间去清理那些“历史遗留问题”。
有了它,我可以毫无顾忌地让 AI 放飞自我,大胆地尝试各种可能性,反正搞砸了,删掉重来就好,试错成本几乎降到了零! 这对于学习和实践 AI 驱动开发 来说是革命性的。
就这样我用三周业余时间写了一个 Demo 版的 WAF 防火墙,下面是成果。
再来点截图:




我的 AI 辅助 WAF 开发实战全流程
接下来我就给大家拆解一下,我是怎么利用 DevBox 跟 AI “结伴”把这个 WAF Demo 一点点“磨”出来的。希望能帮助到像我这种对技术名词了解很多,但不是很会编程的同学完成自己的产品开发,特别是那些想尝试用 AI 开发 Web 应用的朋友们。
1. 阶段一:AI 辅助攻克 Coraza 检测引擎
在技术路线确认了使用 coraza-spoe
作为检测引擎后,我做了下面两件事:
步骤一:让 AI 给我读代码,告诉我这个玩意是干什么的,并以我容易理解的方式给出结论,这里我是把 coraza-spoe
仓库的代码 (coraza-spoe GitHub) 丢给 AI,因为这个仓库的代码量不大。
如果仓库代码量很大,可以分模块丢给 AI,让 AI 分别总结,比如有三个模块 a/b/c,把 a 模块代码询问 AI 得出结论,如果 b 模块依赖了 a 模块的话,就把 b 模块和刚刚 a 模块的结论一起丢给 AI,然后又会得到 b 模块的结论,这样循环下去就行。
AI 的联想能力非常非常的强,下面是我的提示词和 AI 给出的结论 (这里我主要与类似 Cursor AI 编辑器 的工具进行交互,它可以很好地结合代码上下文):
提示词 (Prompt for AI Code Analysis):
AI 给出的结论 (coraza-spoe agent 代码分析摘要):
在 AI 给出清晰的流程后,我很快就知道 coraza-spoe
是干什么的,定位到了处理请求(HandleRequest)和响应(HandleResponse)的关键函数。
步骤二:让 AI 在 coraza-spoe
的这两个函数里写一个日志处理逻辑,日志的表结构设计,字段设计也是 AI 给的,提示词也没什么特殊的就是让 AI 基于这个项目结构,在 HandleRequest
和 HandleResponse
函数中添加日志存储逻辑,同时使用 MongoDB 作为存储数据库,字段设计由你来决定,要求符合程序设计,核心需求修改完后程序能运行,给出运行步骤。
很快 AI 就给了一个版本,并且成功运行起来了,同时他设计的表中有些我不需要的字段也让他删除了,然后后面就是不断的新一轮的对话,大致就是不断让 AI 改需求,同时我也下手改一点点,工作流程变成读代码,让 AI 给下一版本,继续读代码,给下一版本,直到满意为止。
整个流程总结一下就是:截图,拖,COPY,问,教育 AI,骂,露出满意的微笑,然后 Commit。这正是 AI 辅助编程的魅力所在。

2. 阶段二:AI 助力 Go Gin 后端框架搭建
检测引擎的目录和相关代码写好后,就开始了后端开发了。目标是使用 AI 开发 Go Gin 应用。
因为检测引擎是 Go 写的代码,所以后端在 AI 的建议下选择使用 Go 的 Gin 框架。在确认框架后,AI 还给出后端框架有两个功能:
- 一个是 CRUD 需求,也就是我提的各种业务需求;
- 另一个就是后台任务管理,负责启动检测引擎,HAproxy,以及生成 HAproxy 的配置。
得到这些信息后我就让 AI 首先给出一个 Gin 框架的常规目录结构,给出一个最小能运行的 demo。
这期间我也去搜索了解 Gin 框架的手把手教程,看一些文章,看看别人的 Gin 框架的目录结构是什么样的,多一些知识储备,这样我好接下来以更专业一点的视角去问 AI。
我把一个 Gin 的最佳示例项目丢了 AI,然后让他初始化项目,很快 AI 给了一个能跑的 demo 项目,这个项目没有任何业务实现,就是一个可以跑起来的 hello world 后端 Web。
接下来我就一步一步让他给我完成我的需求,我记得我最先是让他给我加了一个中间件记录日志,然后又在他给的中间件基础的目录基础上,让他基于现有格式完成了鉴权中间件,并且这个过程 AI 创造性的给我添加了 controller router service repository 这几个目录,和一大堆代码,在我询问下得知原来这是 MVC 模式的 Web 后端模型,意外的学习到新知识。
后面我就让他基于该模式给我添加业务实现,同时我发现了 Cursor 一个很好用的功能就是可以用 @
来将项目文件和目录发给 AI,并且我发现有一个上下文文件来记录项目结构,那么 AI 就会完全按照你的要求去填充代码。
而且由于我不断的与 AI 谈话,学习到的专业知识越来越多,后面的提问也越来越专业,我最开始的提问就是给我一个能跑的程序,后面我的提问会附加上下文文件,会清晰的描述清楚我要的需求。
下面是我的一些提示词,和 AI 补充的上下文文件,没错这个上下文文件也是 AI 补充完整的,我要求 AI 每实现一个需求,就把这个需求填充到上下文中。
上下文文件 @context
(后端 Go Gin 项目结构节选):
一些后端开发的 AI 提示词示例
证书管理功能实现:
服务状态管理功能实现:
其他功能的实现基本和上面一样,不断把需求给 AI,在和 AI 的来回对话中,不断试错,这期间也不断增加我的专业水平,同时代码阶段性保存到 GitHub,和 DevBox 随时重置环境给了我试错的勇气,重来的时间成本大大降低。
3. 阶段三:AI 协同完成 React 前端界面
有了后端开发时和 AI 大战三百回合的经历,Web 开发时我与 AI 的交互就炉火纯青了,目标是使用 AI 开发 React 应用。也是一样的流程,从网上搜了一个 React 最佳 demo 项目丢给 AI,然后让 AI 一步一步完成我的需求,同时也有一个上下文文件进行记录,同时还有 DevBox 给我随时重置环境的便利。
有一点需要注意,在 Web 开发时一定要把 Swagger OpenAPI 文件发给 AI,这样 AI 定义的类型,以及 axios 请求的业务代码会非常的准确。
上下文文件 @context
(前端 React 项目结构节选):
一些前端开发的 AI 提示词示例
证书管理功能实现:
登录认证功能实现:
锦上添花:AI 辅助 UI 设计与调整
在 UI 调整上初期没必要花太多时间,我曾经学了一阵子用 Penpot 画图,画了好多时间画出来的很丑,虽说大部分是拖拖拽拽,用公共的组件库拼接。

后面我改变了策略,我们只需要画草稿就行,现在 AI 越来越强,对图片的理解和对需求的理解比我脑子里想象的都强,我后面就是把草稿发给 AI(例如使用支持图片输入的 AI 模型),让 AI 渲染一个好看的画面出来。

AI 出图后,再结合提示词和图片交给 Cursor,让 AI 对齐就行,告诉 AI 用什么组件库(比如 Shadcn/UI)实现这个效果,或者进行进一步微调。这极大地提升了 AI 辅助 UI 设计 的效率。
AI 编程时代的反思与感悟:我的三大核心体会
在深度使用 AI 三周后,我完全相信了前面说的 “程序员完蛋了,被 AI 替代了”,“从零开始 AI 全部搞定”,“一行代码没写,全是 AI 写的”,这些文章。
但我现在不担心了,因为这是利好我这种写代码能力差的同学,最后我想对AI、Cursor 和 DevBox 做一个使用总结:
-
AI 大模型 (如 ChatGPT/Claude):你的 24/7 专属技术导师
- 多问!多问!多问! 重要的事情说三遍!遇到 AI 给的答案不理解?别怕丢人,刨根问底地追问,直到你彻底搞懂为止。这是提升 AI 辅助学习 效果的关键。
- 学会提问: 提问是个技术活。一开始可能只会说“给我个 xxx”,慢慢地,你要学会提供上下文(比如我那个
@context.txt
文件)、明确需求、甚至告诉 AI 你期望的格式和风格。你越“懂行”,AI 给你的答案质量就越高。这个能力,就是在不断对话中练出来的。有效的 AI 提示工程 (Prompt Engineering) 是核心。
-
Cursor AI 代码编辑器:强大的智能副驾,但方向盘在你手中
- Agent 模式 vs Ask 模式: Agent 模式(就是让 AI 自动干活)特别适合那种有固定框架、重复性的工作。比如我让它给整个项目做国际化翻译,它对着现成的目录和文件结构,干得又快又好。但如果是需要创造性、或者改动比较大的任务,Agent 模式有时候容易“用力过猛”,把项目改得乱七八糟,然后陷入“越改越错”的死循环。
- Ask 模式是我的最爱: 这更像是“智能辅助驾驶”,AI 给你建议和代码片段,但最终决策权在你手里。你可以随时审查、修改、拒绝 AI 的提议。这样虽然慢一点,但可控性强得多,不容易翻车。记住,AI 是工具,你才是那个最终负责任的“司机”。
-
DevBox 云端开发环境:终极“大杀器”,赋予无限试错的勇气
- 环境隔离,不怕搞乱电脑! 这点真的太重要了!有了 Devbox,我可以毫无心理负担地让 AI 去尝试各种骚操作,哪怕是重构这样的大改动。代码提交到 Git,然后在 Devbox 里让 AI 放飞自我,能跑就行!环境乱了?删掉重开一个,前后不过几分钟的事!这是 DevBox 在 AI 开发中的核心价值。
- 快速迭代的利器: 这种“用完即弃”的模式,极大地降低了试错成本,让我敢于不断尝试新的想法和 AI 给出的新方案,迭代速度快了好几倍。
- 测试无缝衔接: 还有一点特别爽,因为 Devbox 就在 Sealos 平台上,我测试起来超级方便。比如我在 Sealos 应用商店里随手启动一个 Nginx 或者其他 Web 应用,然后在我的 WAF Demo 环境里配置一下域名,立马就能测试防护效果。开发和测试无缝切换,体验极佳!
结语:拥抱 AI,人人皆可创造
这次经历对我最大的改变,可能就是心态上的。以前总觉得“开发”是离我很遥远的事情,是专业程序员才能干的活儿。但现在发现,有了 AI 编程工具 和 DevBox 云开发环境 这样的好帮手,想法和执行之间的鸿沟,正在被快速填平。如果你也有一个深藏心底的技术想法,不妨现在就借助 AI 和合适的工具,勇敢地迈出第一步吧!未来已来,我们都是参与者。