过去两周，我做了一个实验：不手写一行游戏代码，完全依靠 AI 编程助手（主要是 Claude Code）生成 7 个可交互的 HTML5 小游戏，并将它们嵌入到 WordPress 博客中 playable。这篇文章不是游戏推荐，而是对整个 workflow 的完整复盘——包括 prompt 技巧、代码调优、WordPress 嵌入踩坑，以及这个过程中我对”AI 辅助创意编程”的观察。
实验背景：为什么要做这个事？
我的博客 iluyou.cn 定位是 AI 编程实践，但一直面临一个问题：文章是静态的，读者看完就走了。我想找到一种低成本的方式，让博客里有可交互的内容——小游戏、可视化 demo、在线计算器——但又不想为此维护一个后端服务器。
另一个动机是测试 Claude Code 的创意生成边界：它是否真的能把一个模糊的需求（”做一个俄罗斯方块”）转化为可直接运行的代码？过程中需要多少次人工干预？
实验成果：7 个游戏一览
| 游戏 | AI 生成耗时 | 人工调优点 | 技术亮点 |
|---|---|---|---|
| 走迷宫 | ~8 分钟 | 放大/缩小按钮、Canvas 尺寸从 500→700 | 递归回溯算法生成迷宫 + BFS 求解最短路径 |
| 贪吃蛇 | ~6 分钟 | 移动端适配、速度曲线优化 | 队列数据结构、碰撞检测 |
| Emoji 翻牌配对 | ~5 分钟 | 翻转动画 CSS、胜利特效 | 状态管理、 Fisher-Yates 洗牌 |
| 井字棋 AI | ~10 分钟 | Minimax 算法优化、难度分级 | 博弈树搜索、剪枝 |
| 俄罗斯方块 | ~12 分钟 | 旋转碰撞预判、等级速度递增曲线 | 矩阵旋转、动态定时器 |
| 2048 | ~7 分钟 | 撤销功能、概率随机生成 | 数组压缩算法、状态回溯 |
| 打砖块 | ~9 分钟 | 鼠标/触摸/键盘三模控制、角度反弹物理 | AABB 碰撞、requestAnimationFrame |
所有游戏均满足以下约束：零后端依赖、纯前端 HTML/CSS/JS、支持缩放、可直接嵌入 WordPress 文章。
核心发现 1：AI 生成的代码有”骨架”，但”手感”需要人调
Claude Code 在”把需求变成可运行代码”这件事上表现惊人。比如我说”做一个俄罗斯方块，支持旋转和消行”，它能立刻给出包含 7 种标准形状、碰撞检测、消行逻辑的完整实现。
但”能玩”和”好玩”之间，有一道 AI 目前跨不过去的鸿沟：
- 手感调优：俄罗斯方块的旋转点应该在哪里？靠近边界时是否允许”踢墙”？这些细节 AI 会给出默认实现，但默认实现往往”手感僵硬”。
- 难度曲线：AI 通常用线性递增（每 10 行减 50ms），但好的游戏需要指数型曲线配合微妙的加速渐变。
- 视觉反馈：消行时的闪烁、方块落地时的微弹动、游戏结束的渐隐——这些”情绪设计” AI 几乎不会主动做。
我的结论：AI 是顶级的”原型生成器”，但”用户体验设计师”的角色仍然需要人。两者结合的效率，比单独用 AI 或单独手写高得多。
核心发现 2：WordPress 嵌入是最大的隐性成本
如果你以为 AI 生成代码后就结束了，Too naive。将 HTML5 游戏嵌入 WordPress 的过程，我踩了三个大坑：
坑 1：wpautop 过滤器会污染 JavaScript
WordPress 的 wpautop 会自动把换行转成 <br />，甚至把 && 转义成 &&。这意味着直接把 <script> 标签塞进文章，游戏几乎必然跑不起来。
坑 2：Gutenberg 的 Custom HTML block 也不安全
我试过用 <!-- wp:html --> 包裹游戏代码，但 REST API 在保存时仍然会跑过滤。即使加了 context=edit 参数，&& 依然会被转义。
最终解法：Base64 Data URI
我最终采用的方案是：
- 将完整的游戏 HTML（含 CSS 和 JS）打成一个字符串；
- 用 Python 的
base64.b64encode()编码； - 嵌入 iframe：
<iframe src="data:text/html;base64,ENCODED">。
为什么这个方案可靠？因为 base64 字符集（A-Z, a-z, 0-9, +, /, =）里没有任何字符会被 WordPress 转义。数据在传输过程中完全免疫过滤。
核心发现 3：Prompt 工程比想象中重要
我对比了两种 prompt 策略的效率差异：
| 策略 | 示例 | 结果 |
|---|---|---|
| 模糊需求 | “帮我做一个 2048 游戏” | 基础版本，缺少撤销、最高分记录、缩放功能 |
| 结构化需求 | “做一个 2048，要求：1) 4×4 网格；2) 方向键+WASD；3) 支持撤销一次；4) 概率 90%出2、10%出4；5) 所有计算在浏览器完成” | 一次到位，几乎不需要返工 |
同样的模型，不同的 prompt，产出质量差距巨大。这个实验让我更加确信：AI 时代，写 prompt 的能力就是写”软架构文档”的能力。
数据复盘
整个实验的技术栈和时间成本：
- AI 工具：Claude Code（对话生成）+ Python（发布自动化）
- 代码量：7 个游戏合计约 2500 行 HTML/CSS/JS，几乎全部由 AI 生成
- 人工代码量：约 200 行（主要是 zoom 控制、移动端事件兼容、发布脚本）
- 总耗时：约 6 小时（含踩坑、调试、写发布脚本）
- 单个游戏平均：AI 生成 5-10 分钟 + 人工调优 15-30 分钟 + 发布 5 分钟
这个实验的延伸价值
这件事的价值不止于”我博客里有 7 个游戏”。它验证了一套更通用的方法论：
- 内容创作者：不需要会写游戏代码，也能在自己的博客里嵌入互动内容；
- 教育工作者：可以用同样的方式生成算法可视化、数学模拟器、编程练习；
- 营销人员：活动页上的抽奖转盘、问卷、计算器，都可以零成本自研。
AI 把”创意→代码→可运行产物”的循环从数天压缩到了数分钟。这个效率跃迁本身，就是一个值得持续关注的趋势。
下一步
这个系列我会继续更新。接下来的方向包括：
- 对比 Claude Code vs Cursor 在生成交互内容时的差异
- 用 AI 生成算法可视化（排序、图遍历、动态规划）
- 探索将互动内容嵌入公众号、Notion、飞书等平台的方法
如果你也在用 AI 生成创意内容，或者对某个技术细节感兴趣，欢迎在评论区留言。