前言
作为一名计算机专业的学生，这两年的AI技术爆发给我的学习轨迹带来了近乎颠覆性的改变。记得2023年第一次用ChatGPT解释递归算法时，那种"如同获得私人助教"的震撼感至今难忘。而后AI的发展速度令人目不暇接：2024年DeepSeek在长上下文理解上的突破，Claude在代码生成时的严谨风格，国内豆包、Coze在本地化应用上的创新，还有最近爆火的Manus、能构建知识图谱的NoteBookLM......这些工具正在重塑我们学习编程的方式。
然而真正促使我动手实践的，是掘金推出的AI编程大赛。这个"人人都是AI编程家"的活动像一记直球，击碎了我"AI只能做辅助工具"的偏见。看着社区里其他参赛者用自然语言生成的完整项目，我突然意识到：是时候让LLM不再是作业题的参考答案，而要成为我的联合开发者了------于是，一场关于弹幕游戏开发的AI协同实验就此展开。
游戏内容一览&链接
链接如下：aicoding.juejin.cn/aicoding/wo...
请各位大佬给个赞吧 b(￣▽￣)d
AI协同开发：为何我选择从"弹幕游戏"开始
基于过去使用AI辅助开发的经验，我逐渐意识到一个关键点：AI适合快速原型开发，但对于复杂项目，开发者仍需具备足够的专业知识才能高效纠错和迭代。如果项目逻辑过于庞杂，AI生成的代码可能会隐藏难以察觉的Bug，甚至引入不合理的架构设计------尤其是在开发者自身对技术栈不够熟悉的情况下。
正因如此，在参加掘金AI编程大赛 时，我决定避开过于复杂的想法，转而选择一个轻量且直观的项目 ：一款基于HTML+CSS+JS的弹幕躲避游戏。这个选择的优势在于：
技术栈友好：前端三件套（HTML/CSS/JS）足够直观，便于快速验证AI生成的代码逻辑。
逻辑清晰：核心玩法（角色移动+弹幕生成+碰撞检测）容易定义，便于Prompt精准描述需求。
调试直观：浏览器开发者工具（Console调试、DOM检查）能让问题快速暴露，减少隐式错误。
快速迭代：即使AI生成代码有缺陷，也能手动调整，避免陷入复杂架构的泥潭。
最终，这个选择让我既能充分利用AI的高效生成能力，又能保持对代码质量的掌控------在"AI辅助"和"自主开发"之间找到了平衡点。
开发启动：如何让Prompt成为高效协作的"项目文档"
在正式敲下第一行代码之前，我做了两件关键准备：
- 系统学习Prompt工程
- 研读了吴恩达《ChatGPT Prompt Engineering for Developers》的核心方法论
- 分析了智谱AI发布的《高效Prompt设计指南》中的结构化模板
- 特别关注了"角色定义→任务分解→约束条件→输出规范"的递进式设计框架
- 建立可迭代的Prompt工作流
- 选择Cursor/Trae作为开发环境，利用其"对话式编程"特性
- 选择了Markdown格式来编写Prompt（Markdown格式更有利于LLM的理解）
根据我们的需求，开发所用的Prompt如下：
markdown
# 人设
你是一个利用HTML、CSS、JS开发趣味游戏的大师，接下来你将根据以下内容来开发一款弹幕躲避游戏。
# 「Bug逃生舱」------ 程序员的弹幕生存挑战
## 游戏背景
在数字世界的深处，一位程序员正在与代码的错误和异常进行着永恒的斗争。这些Bug、错误和异常像弹幕一样从四面八方袭来，试图摧毁程序员的工作成果。作为一名熟练的开发者，你必须灵活地躲避这些错误，同时收集技能点来解锁强大的编程技能，帮助你在这场与Bug的战斗中生存下来。
每个弹幕都代表着程序员日常工作中可能遇到的各种错误和吐槽，从语法错误到逻辑Bug，从内存泄漏到死锁问题。你的任务是尽可能长时间地生存，同时收集足够的技能点来解锁和使用各种编程技能。
## 游戏玩法
### 基本控制
- 使用 **WASD** 或 **方向键** 控制你的飞船移动
### 难度选择
游戏提供三种难度级别：
- **简单**：适合初学者，错误移动速度较慢，生成频率较低
- **普通**：标准难度，平衡的错误速度和生成频率
- **困难**：挑战性强，错误移动速度快，生成频率高
不同难度有不同的分数倍率，难度越高，获得的分数越多。
### 游戏目标
- 尽可能长时间地生存，躲避各种飞来的错误弹幕
- 收集技能点，解锁和使用各种编程技能
- 获得高分，挑战自己的最高记录
### 错误类型
游戏中有多种不同类型的错误弹幕：
1. **普通错误**：基本的错误弹幕，速度和大小适中
2. **大型错误**：体积较大的错误，移动速度较慢但更难躲避
3. **快速错误**：小型但高速移动的错误，需要快速反应
4. **阵列错误**：由多个小错误组成的阵列，难度较高通过这一段Prompt，大模型就生成了基本的文件内容。
错误的修改
在开发过程中，各种奇葩错误总是防不胜防。比如你让AI加个新功能，它可能偷偷把你原本跑得好好的代码给魔改一波；或者在实现新逻辑时，动不动就引用些根本不存在的变量，搞得控制台疯狂报错。
这时候就只能进入"人肉调试器"模式------把报错信息复制粘贴扔回给AI，还得像教小屁孩一样告诉它：
"只允许修改当前的逻辑内容，其他不相关的功能逻辑不要动。"
（但是吧，它有时还是不听话，改着改着又把别处搞崩了...于是陷入无限循环：报错→反馈→改错→出新错→再报错...）
那些大佬开发者估计直接看报错信息就能光速定位问题，而像我这样的前端萌新，只能卑微地把error日志当猫条，一遍遍投喂给AI，等它吐修正代码......
开发过程中最令人无语的事情莫过于：
AI：很好，我已经将这个问题解决了
你：报错仍然存在请继续修改
AI：让我来看看问题出现在哪里....
这大概就是人类和AI相爱相杀的开发日常吧呵呵呵呵 0x0
我个人在开发过程中遇见错误，主要就是描述出现错误后游戏的问题+控制台的报错，之后让它检查相关逻辑再修改，不知道我这一段操作够不够科学了，如果有更好的方法也希望各位大佬分享一下 Orz。
关于模型的选择
我个人感觉开发时模型的选择依然是Claude或者DeepSeek，DeepSeek的HTML生成能力很强，但确实比不上Claude这样专门用来开发的大模型，Claude在开发的时候非常强劲：生成符合需求的代码后它会寻找相矛盾的地方，自动修改逻辑，最后将结果呈现给你。
虽然利用Claude开发时，它也会抽风，有一个bug就死活修改不好，但是它确实已经比较强了，当我遇到它无法解决的问题时，我通常会换一个思路，比如将这个功能利用另一个功能替代，比如之前的for循环分裂弹幕，我现在使用了数组弹幕来替代了......
用过Claude的人都会说很香，建议去某宝淘一个用用，开发效率 +10倍~
对于开发的心得
这是我第一次正式利用Prompt工程进行开发，在此之前我对游戏开发说一窍不通，但是利用了AI后我却能写出这个游戏，这就是AI带来的便利，不禁让主播想起了前两天的六级考试：AI会对人类的创造性有负面的影响，我这不是纯反面例子吗，当时我确实写的促进了创造性，但是奈何功底不够，估计是GG了......
Prompt工程开发时，我们如果是遇到我们一点都不懂的项目进行开发，当我们和大模型同时卡死在这里时，我们可以有以下两种选择：
- 替换模型，将一个模型替换，让另一个LLM来解决，说不定有奇效
- 换一种思路，将要实现的功能换一种思路，或者找到替代它的方法
总之，卡住了我们不要死磕了，方法总比困难多嘛！
LLM在生产过程中难免会抽风，去修改一些不需要它来修改的逻辑，我个人建议，在彻底完成一个功能后就不要让LLM再次对其进行修改了，在之后的对话中给LLM加上限制，不让它修改与新添功能无关的逻辑，以免出现错误。
在开发一个项目的时候，我们尽量遵从先主体后枝干的原则，就是先把大体的框架勾勒出来，把最基本的先做出来，再去实现一个个有意思的功能。就像画画一样，先勾勒出人的大体框架，再去画鼻子画眼。
总结
这次参加掘金活动的经历给了我前所未有的技术启发。作为一个首次完全通过Prompt工程来开发完整项目的实践者，整个创作过程就像在跟一个既天才又蠢材的人合作------它有时会惊艳我，有时又会让我看傻在原地.....
最让我惊喜的是逐渐掌握的"与AI对话的艺术"。从最初生硬的指令到后来能精确描述业务逻辑，甚至预判AI可能产生的误解，这种技能的增长曲线比学习任何新框架都要陡峭。当看到那些由自然语言转化而来的代码片段最终组成可运行的游戏时，那种成就感完全不同于传统编程。
当然，这个过程也充满了AI特有的戏剧性时刻。比如某个功能明明用人类思维很简单，AI却会固执地给出匪夷所思的实现方案；又或者在调试陷入僵局时，突然灵光一现的提示词调整让整个问题迎刃而解。这些体验让我深刻意识到：未来的开发者可能既要懂机器逻辑，又要精通"人机翻译"。
现在回看这个用Prompt孕育出的游戏作品，真的感觉自己成长了一些，在这里我也期待更多开发者能体验到这种奇妙的共创模式，用AI解锁那些曾经难以想象的创作可能。毕竟，当代码可以用对话来编织时，编程的边界早已被重新定义。