企业官网建设流程全解析

这次我们来看一个比较特别的 AI 应用实验：Ethan Mollick 用 Fable 生成了一款“十四阶段最烦人 CAPTCHA”小游戏。它没有明显的模型权重、没有本地部署参数，更不需要靠显卡跑推理。这个案例真正有意思的地方在于，CAPTCHA 验证码本身就是一套到处可见、规则明确、却经常让用户烦躁的交互流程。把这种“烦人体验”拆成 14 个递进阶段，再交给生成式 AI 去实现，本质上是在测试一件事：AI 能不能理解产品级交互的挫败感，并把挫败感翻译成可运行的小游戏。

先给结论：这个案例对 CSDN 读者来说，值得关注的价值不在于“一个教授玩了一个生成工具”，而在于它演示了一条很典型的生成式游戏工作流——从痛点出发，把体验拆成关卡，用 AI 写交互，再人工验收。整个链路不涉及复杂的服务端架构，复现成本很低。如果你关心 AI Agent、AI 生成内容、游戏化产品，或者只是想知道“用自然语言到底能不能做出一个完整的可交互网页”，这篇文章可以作为一条参考路线。

文章不会集中讲 Fable 的私有操作界面，因为这类平台迭代快、不同版本能力差异很大。我会把 Fable 当成一个通过自然语言生成场景、关卡和交互的创作平台，然后把重点放在方法本身。后面会给出一套可以在任意对话式编码模型中复现的“14 阶段小游戏”需求模板，以及一段可直接保存为 HTML 运行的中文吐槽版演示代码。想亲手验证的读者，可以直接跳到第 5 节。

1. 案例速览：AI 生成的“最烦人 CAPTCHA”实验

1.1 用一张表看清这个实验

反直觉的 AI 游戏生成案例往往要先快速说清场景，再进入细节。下表是本文从公开信息中可以提炼的基本盘：

这张表传达的核心信息是：这个实验不属于“显卡 + 大模型 + 本地权重”的技术栈，而属于“自然语言描述 + AI 生成交互 + 快速试玩”的轻量产品原型流水线。

1.2 为什么这个案例值得 CSDN 技术读者关注

第一，它证明“生成一个可玩的交互游戏”现在已经成为未必需要写复杂代码的普通任务。过去做一个 14 阶段小游戏，至少要处理页面结构、按钮事件、状态切换、关卡顺序和文案系统。现在，创作者需要做的是把需求描述得足够清楚，让生成工具拆分并输出完整结构。即便最后仍需要人工修改，初稿质量也已经具备很低的启动成本。

第二，阶段式结构非常适合用来量化 AI 生成质量。AI 输出经常出现一个毛病：单看一段很漂亮，拼起来逻辑错乱。CAPTCHA 的 14 个阶段天然要求状态顺序、失败反馈和进度跳转，模型如果只懂文字不懂状态，产物会很快露馅。因此，这种项目可以成为一个评测提示词稳定性的试验台。

第三，从题材边界看，CAPTCHA 是一种讽刺型产品去重。真正的技术难点其实是：如何让生成器准确区分“展示烦人验证码”和“真正接入验证码系统”。这看起来像文字游戏，但实际上是对 AI 理解安全边界的一次校验。合法又稳妥的做法，是把它做成纯粹的演示、教学或艺术向材料，不进入任何真实网站业务流程。本文后面所有示例都遵循这一前提。

2. CAPTCHA 痛点拆解：14 个阶段可以怎么设计

2.1 大多数人反感的验证码类型

要做一款“最烦人 CAPTCHA”小游戏，前提是先搞清楚验证码常见的烦人来源。这个话题不需要深入攻击性技术，它讨论的是产品体验层面的问题。通常可以被归为这六类：

• 字符严重扭曲，背景加噪点，连人都分不清。
• 图片选择歧义，比如九宫格里出现半个物体，很难判断是否算作目标物。
• 出现“我不是机器人”复选框，点完又弹出一个二级验证面板。
• 滑块没有吸附边界，拖到接近正确位置时又自动弹回。
• 文案突然切换语言，或者报错信息永远是“请重试”。
• 验证条件突然更换，用户刚习惯一种输入方式，又被切到另一种。

其中有一类很妙的细节：当网站提示captcha must be filled out.时，用户可能根本没有看到验证码输入框在哪儿。这种“信息不完整 + 报错先于引导”的产品设计，本身就是绝佳的讽刺素材。很多人看到这串英文时，第一反应不是自己操作错误，而是产品设计没有覆盖用户的真实视野。

2.2 14 阶段游戏的合理成长曲线

从材料看，完整的小游戏内部到底是不是按照“字符识别、图片选择、滑轨、复选”顺序排列，目前没有统一公开说明。不过如果要设计一款能体现“最烦人”递进的 14 阶段游戏，通常会采用一个从“略烦”到“崩溃”的曲线：

这个模型在生成游戏时非常重要的价值是：AI 不能只堆文案，还要理解阶段之间的递进关系。第 1 关和第 14 关的“烦人方式”不同，前者偏识别困难，后者偏系统级拖延。如果 AI 在生成时把每一段都写成“字符不清”，那这款游戏就不具备“递进式”产品逻辑。

3. Fable 与同类 AI 创作工具的角色定位

3.1 Fable 在这个实验中充当什么角色

按标题来看，Ethan Mollick 用 Fable 生成这款游戏，重点不在提示词模型，而在把游戏创建变成一种高层的交互设计过程。Fable 这类平台的卖点通常集中在以下几个方面：

• 允许创作者用自然语言描述场景、角色、事件流程。
• 平台内部会对生成内容做结构化处理，形成关卡或事件节点。
• 最终产物可以提供在线试玩，适合快速传播和测试。
• 创作者不需要从零写复杂的碰撞检测、状态机或渲染逻辑。

这些能力与“做一个十四阶段 CAPTCHA 小游戏”高度匹配，因为 CAPTCHA 游戏没有复杂的美术资源需求，核心是状态切换和文案反馈。把它做成阶段化文本，模型只要理解“第几关、要玩家干什么、失败后怎么反馈”，基本就能形成一个可玩版本。

3.2 不是所有生成游戏任务都适合同一类工具

选择 AI 生成工具之前，先判断交付形态。不同工具的对比如下：

这个案例中的 CAPTCHA 体验游戏，本质上是一个低美术、高交互逻辑、多状态的网页内容。用 Fable 这类平台做轻量展示很不错，因为能够快速得到在线可点版本。但如果你希望彻底掌控样式、把关卡数据写到自己的配置表里，用通用对话式编码模型生成一个纯静态 HTML 再改，也是很稳的路径。

3.3 使用平台前的判断清单

建议在实际操作前先确认三件事：

• 确认平台的创作产物是否可以导出。有的平台适合在线演示，但导出成本不低。
• 确认生成内容的稳定性。让平台产出 14 个独立页面和生成 1 个带stageIndex的页面，是两种不同难度。
• 确认平台的素材归属和内容合规条款。AI 平台对生成内容的权利约定各不相同，尤其涉及商用和分发时需要仔细查看。

如果决定使用 Fable，实际生成文案和发布按钮可能与本文描述不同，以官方最新文档为准。这里提供的拆解模板，在任何一种 AI 生成工具里都适用：先告诉模型“输出结构化数据”，再让模型补全表现层细节。

4. 通用复现流程：从“一句话想法”到“可玩 14 阶段”

4.1 先写需求，再写提示词

很多创作实验失败的根源是提示词停留在“帮我做一个验证码游戏”这种层级。生成器如果要做出 14 阶段，必须知道每一阶段的具体目标、玩家操作、失败条件和整体风格。所以，推荐把需求先整理成一个 JSON 结构或一个 Markdown 文档，再提交给生成器。

如果目标平台是 Fable，下面的 JSON 可以作为需求描述；如果目标是对话式编码模型，可以让模型按这段 JSON 生成 HTML。以“吐槽 CAPTCHA”为例，可以定义：

{ "project": "CAPTCHA 吐槽体验小游戏", "goal": "把验证码常见的烦躁体验拆成多个递进阶段，做成纯展示型网页游戏，不接入任何真实验证系统", "style": "简洁、轻量、中文界面，强调氛围而不是复杂美术", "outputFormat": "单个 HTML 文件", "stageCount": 14, "stageSchema": { "id": "Number", "title": "String", "instruction": "String", "scene": "challenge | joke | result", "interaction": "text | image | slider | checkbox | noop", "failMessage": "String" }, "constraint": "不要真正发起网络请求，不要使用任何真实网站的品牌元素" }

这个模板的价值在于：把“烦”这种主观感受转化成结构化数据。interaction: slider对应滑块；interaction: noop则代表一个“没有任何实际控件但仍要求用户点击”的讽刺环节。如果生成器支持根据字段展开，那么 14 个阶段只是数组长度的变化而已。

4.2 一条可修改的提示词模板

下面这条提示词模板可以直接复制给大多数对话式编码模型。如果你使用的是 Fable 或类似平台，可能需要把生成单文件 HTML换成平台支持的交互节点描述：

请根据以下 JSON 生成一个单文件 HTML 页面，用于演示 CAPTCHA 验证码的“烦躁感”。 要求： 1. 每阶段有一个标题、一段操作提示、按钮和一个反馈区域。 2. 玩家每次都以为能完成验证，但当前阶段会返回一段“令人烦躁”的失败提示。 3. 点击按钮后，经过短暂延迟再进入下一阶段；下一阶段的标题和正文要同步更新。 4. 阶段数量由 JS 里的 stages 数组控制，最大可扩展到 14。 5. 全部完成后显示“你已经证明自己是人类”的结束语。 6. 页面中不要出现真实网站的验证码字样挂接，不发起任何网络请求，不做真实校验。 JSON: { "project": "CAPTCHA 吐槽演示", "stageCount": 14, "language": "zh-CN" }

这里的关键是把需求拆成三个层面：结构要求、交互要求、边界要求。“交互要求”规定点击按钮后有反馈；“边界要求”规定必须是无网络请求的纯展示。没有边界要求，AI 可能自行加一些看起来像真实验证的输入框，带来不必要的误解。

4.3 批量生成阶段内容时要统一状态

使用 AI 生成带多个阶段的游戏时，最容易遇到的问题是：模型把标题生成得很精彩，但缺乏统一的状态管理。解决方法是要求模型将所有阶段内容放进一个数组，而不是分多次对话生成多个分散片段。这样至少在数据层面保证顺序可控。

推荐的生成顺序是：

• 先生成阶段数据数组，每关只写标题、正文、失败提示。
• 生成器根据数组渲染页面。
• 每轮只修改一个阶段，避免整体推倒重来。
• 最后统一检查末尾阶段，确认能跳出循环。

5. 演示代码：一个可以本地直接运行的 CAPTCHA 吐槽游戏

为了验证“AI 生成 CAPTCHA 游戏”的基本逻辑，不需要先申请平台权限。可以用最简单的单文件方式做一个小型演示。下面这段代码是原创演示版，定位是“体验设计 + 前端状态切换”，不是真实验证码实现，不请求任何接口，也不存储任何输入。

把代码保存为captcha-demo.html，用浏览器打开，全程本地运行。它的核心玩法是：无论点多少次按钮，都会收到一句让人烦躁的提示，然后进入下一阶段。如果你想扩展到完整的 14 阶段，直接往stages数组中添加对象即可。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>CAPTCHA 吐槽演示</title> <style> body { font-family: system-ui, "Microsoft YaHei", sans-serif; background: #eee; display: flex; justify-content: center; align-items: center; min-height: 100vh; margin: 0; } .box { width: 420px; max-width: calc(100vw - 32px); background: #fff; padding: 28px 24px; border-radius: 14px; box-shadow: 0 10px 30px rgba(0,0,0,0.12); } .info { font-size: 12px; color: #aaa; text-align: right; } h2 { font-size: 18px; color: #333; } p { font-size: 14px; color: #555; line-height: 1.8; } .msg { min-height: 22px; font-size: 13px; color: #c0392b; margin-bottom: 8px; } button { width: 100%; padding: 12px; border: 0; background: #222; color: #fff; font-size: 14px; border-radius: 6px; cursor: pointer; } button:hover { background: #444; } .shake { animation: shake 0.3s; } @keyframes shake { 0%, 100% { transform: translateX(0); } 25% { transform: translateX(-6px); } 75% { transform: translateX(6px); } } </style> </head> <body> <div class="box" id="card"> <div class="info" id="info">吐槽演示 · 第 1 / 5 阶段</div> <h2 id="title">第一步：加载验证模块</h2> <p id="prompt">请耐心等待验证模块加载完成。当前不会启用任何真实验证码服务。</p> <div class="msg" id="msg"></div> <button id="btn" onclick="onClick()">继续</button> </div> <script> const stages = [ { title: "第一步：加载验证模块", prompt: "请耐心等待验证模块加载完成。当前不会启用任何真实验证码服务。", msg: "加载完成，但还需要再验证一次。" }, { title: "第二步：确认你是人类", prompt: "请阅读下方提示并点击按钮。", msg: "系统无法确认，请再试一次。" }, { title: "第三步：错误提示", prompt: "本阶段只展示常见报错感，不需要填写任何内容。", msg: "captcha must be filled out. 这就是很多人的第一反应：填什么？" }, { title: "第四步：缺失的滑块", prompt: "请把滑块拖到最右侧，但这里并未提供滑块。", msg: "未检测到滑块，无法继续。" }, { title: "结束：你已通过演示", prompt: "如果这是真实网站，你可能会再遇到 9 个阶段。这里是演示，点击结束。", msg: "" } ]; let current = 0; const card = document.getElementById("card"); const info = document.getElementById("info"); const title = document.getElementById("title"); const prompt = document.getElementById("prompt"); const msg = document.getElementById("msg"); function update() { const s = stages[current]; info.textContent = "吐槽演示 · 第 " + (current + 1) + " / " + stages.length + " 阶段"; title.textContent = s.title; prompt.textContent = s.prompt; msg.textContent = ""; } function onClick() { if (current >= stages.length - 1) { msg.textContent = "演示结束：你已经在一个没有真实验证的页面里完成了一次纯展示。"; return; } const s = stages[current]; msg.textContent = s.msg || "验证失败，请重试。"; card.classList.remove("shake"); void card.offsetWidth; card.classList.add("shake"); current += 1; window.setTimeout(function () { info.textContent = "吐槽演示 · 第 " + (current + 1) + " / " + stages.length + " 阶段"; title.textContent = stages[current].title; prompt.textContent = stages[current].prompt; msg.textContent = ""; }, 500); } update(); </script> </body> </html>

上面这份代码的运行逻辑比较简单：点击按钮后，当前阶段显示失败提示，卡片震动，500 毫秒后切换到下一阶段。判断成功的标准是：阶段标题、正文、进度信息能同步更新，结束时给出结束提示。想扩展成 14 阶段，只需要把stages数组的msg改成更具讽刺感的文案，比如“图片不清晰，请重新选择”“操作超时，请刷新页面再试”“你已完成验证，请再次确认你已完成验证”。

在实际项目中，不要把这种纯演示版接到任何登录、注册、反滥用或内容保护流程里。它只是一个用于研究用户情绪和产品交互的实验片段。

6. 测试与效果验证：十四阶段小游戏怎么验收

一个 AI 生成的小游戏即使能跑，也不代表“可玩”。对这类项目，建议按下面几组维度进行验证。

6.1 功能完整性测试

CAPTCHA 吐槽游戏的核心是“状态推进”，所以首先要测以下场景：

任何生成器实现第 14 个阶段时，“能走到末尾并结束”是最基础的要求。很多 AI 生成的交互原型经常在最后一个阶段忽略current >= stages.length - 1的判断，导致玩家永远无法结束。这也是需要人工验收的主要原因之一。

6.2 可玩性和挫败感验证

这个项目叫“最烦人 CAPTCHA”，目标不是让用户通关顺畅，而是要让用户真的感受到 CAPTCHA 的烦躁。因此，测试要看的是“挫败感强度是否达到预期”。可以找几个用户试玩，观察他们在哪些阶段表情开始变化，在哪一关选择关闭页面。

推荐的验证指标包括：

• 每一阶段平均耗时。
• 玩家在第几阶段放弃。
• 是否出现玩家反复点击同一个按钮。
• 结束语出现后，玩家是笑还是愤怒。

如果从第 1 关到第 5 关全是同一个失败提示，说明生成器对“递进”理解不足。合理的做法是让失败提示从“偏中性”逐步升级为“明显无语”，最后甚至可以加入系统自嘲式文案。

6.3 多端兼容性验证

如果最终要发布到社交平台或团队内网，需要测试不同浏览器和移动端。一个只适合桌面网页的版本，分享给手机用户时可能因为按钮过小或文字折行而失败。建议至少检查 Chrome、Edge 和 Safari 的最新版本，以及一台窄屏设备上的表现。

如果要在 Fable 平台内发布，还需要检查平台内置分享链接对移动端的适配情况，以及加载速度。一般不建议把大量图片嵌入阶段表，文本与少量 CSS 构成的体验已经足够。

7. 版权、隐私与合规边界

任何“生成式 + 游戏化”项目，到了发布阶段都要考虑版权和安全合规问题。CAPTCHA 题材尤其如此，因为它的名字天然关联真实网站的安全验证系统。这里给出几条明确边界。

7.1 这个实验不触碰真实验证系统

全文的演示代码和思路都不应该被用来绕过、破解或干扰任何真实网站的验证码机制。生成 CAPTCHA 吐槽游戏，目标是展示交互体验和用户挫败感，而不是制作假冒登录框去诱导用户输入。这两条路径之间有一条不可逾越的红线：任何涉及真实服务、真实账号、真实业务流的接入，都必须由具备授权的开发团队在合规安全框架下完成。

7.2 避免仿冒品牌与真实界面

CAPTCHA 视觉风格通常带有明显识别度，有的来自特定服务商，有的来自操作系统风格。在游戏中使用这些素材时，不要直接使用真实网站的品牌标识、像素级界面样式或业务域名。更稳妥的做法是完全原创，只保留“用户很烦躁”的情绪内核。否则即使只是内部演示，一旦截图流传，也可能被误认为在仿冒真实