我记得很清楚第一次看到“Claude 一个 HTML 现场造出会断电自救的赛博城市”这个需求时我下意识觉得这只是一个前端练手项目难度不算高顶多是在 Canvas 上画一些霓虹建筑再放几个闪烁灯效。但真正按这个思路操作一遍之后我的判断变了。这个案例最有价值的不是 AI 把代码写得多完整而是它把“一个模糊想法”到“一套可运行系统”之间的距离压缩到了几分钟。Claude 在这个过程里不只是代码生成器更像一个能把需求转成可执行设计的搭档。这个例子里面藏着一个值得反复琢磨的问题当 AI 已经能生成一份带电网、备用电源、恢复流程的完整页面时我们该怎么验证它、迭代它并且把这种能力放进真实的工作流里。这篇文章我就用“会断电自救的赛博城市”作为主线索拆开 AI 生成 HTML 的前因后果、代码结构、验证方法和长期边界。1. 一个 HTML 文件里“会断电自救”意味着什么先说一个容易被忽略的常识让 AI 生成一个“好看的页面”不难难的是让 AI 生成一个“可运行、可验证、可扩展的小系统”。如果你直接对 Claude 说“帮我做一个赛博城市”它会给你一屏霓虹灯和高楼剪影但那个城市没有内在逻辑断电自救更无从谈起。1.1 一句话需求和一套运行规则的差距AI 生成代码时输入决定了输出的上限。这里不是拼提示词技巧而是拼“你把问题边界说清楚了没有”。我第一次尝试时给的需求颗粒度很粗Claude 返回的页面也确实很漂亮但我等了十分钟城市一直正常运行没有任何断电事件。后来我才意识到问题不在 Claude而在我没有给它描述“什么是断电”“什么时候断电”“断电之后系统要做什么”。于是我把需求改成了这样城市包含发电厂、配电网络、建筑群和路灯。系统正常运行一段时间后有一定概率出现断电。断电后城市灯光变暗警报灯亮起。备用电源自动启动优先维持医院、通讯站等关键设施。一段时间后电网修复系统自动切回主电源。页面顶部需要显示当前系统状态。这已经不是“帮我做一个城市”的需求而是一份运行规则说明书。Claude 拿到这些规则后输出的代码明显不一样它开始生成状态判断、事件触发和恢复流程而不是简单的动画循环。1.2 “自救”不是动画是一套状态机“断电自救”听起来像一种视觉效果但真正让系统自救的是一套状态机。如果你只是用 CSS 动画把灯光变暗那不叫自救自救意味着系统需要感知状态、做出判断、执行恢复流程。我通常建议把这类系统拆成四个状态状态触发条件页面表现退出方式normal城市启动电网稳定街道正常亮灯系统状态显示正常电网故障概率触发outage负载超限或电厂故障灯光变暗警报灯亮起备用电源启动成功backup主电网失效备用电源接入关键设施恢复供电非关键区域继续熄灭电网修复完成restoring主电源恢复切换回电网灯光分批恢复状态显示恢复中全部负载接入主网这是一个很典型的有限状态机模型。Claude 生成代码时最怕的是状态之间没有清晰转换条件。如果状态切换很混乱页面就会出现“电已经断了但所有灯还是亮着”的 bug。实际写代码时核心逻辑大致是const STATE { NORMAL: normal, OUTAGE: outage, BACKUP: backup, RESTORING: restoring }; let currentState STATE.NORMAL; let gridHealth 100; function updateState() { if (currentState STATE.NORMAL shouldOutageHappen()) { currentState STATE.OUTAGE; } else if (currentState STATE.OUTAGE backupAvailable()) { currentState STATE.BACKUP; } else if (currentState STATE.BACKUP isGridStable()) { currentState STATE.RESTORING; } else if (currentState STATE.RESTORING allLoadsRecovered()) { currentState STATE.NORMAL; } }这段代码只是示意但它体现了最重要的设计思路先定义状态再定义状态之间的转换条件。AI 生成单页应用时这种结构越清晰后续迭代就越容易。2. 让 Claude 现场生成赛博城市我建议先拆成四个结构做这类 AI 生成 HTML 的项目不要一上来就追求效果爆炸先拆结构。我的经验是四个结构足以撑起一个“会断电自救的赛博城市”页面骨架、城市渲染、电网与负载模拟、断电自救闭环。2.1 页面骨架一个 HTML 文件完成三件事单文件 HTML 的好处是方便分享、方便用浏览器直接打开也方便 Claude 一次输出完整结果。它的三个职责天然清楚HTML 负责结构城市区域、状态面板、按钮。CSS 负责视觉赛博朋克配色、霓虹光晕、暗夜氛围。JavaScript 负责行为电力系统模拟、状态切换、渲染循环。代码骨架不需要复杂类似这样的结构就可以!DOCTYPE html html langzh-cn head meta charsetutf-8 title赛博城市 - 断电自救模拟/title style /* 赛博朋克主题样式 */ /style /head body div idstatus-bar系统状态: 正常/div canvas idcity/canvas div idcontrols button idtrigger-outage模拟断电/button button idrepair-grid修复电网/button /div script // 城市渲染与电力系统逻辑 /script /body /html你可以让 Claude 直接输出这个文件。如果它输出的是多个文件也可以手动合并成一个浏览器可打开的 HTML。对于演示场景单文件一定是最顺滑的交付形式。2.2 城市渲染选 Canvas 还是 DOMClaude 生成视觉页面时通常会判断用 Canvas 还是 DOM 来渲染。两种方式各有偏好如果你的需求描述里没有指定AI 往往会按自己的习惯选择。维度CanvasDOM/CSS绘制复杂度适合大量建筑、粒子、网络线条适合少量卡片、布局元素动态更新每帧重绘控制力强依赖 CSS 类切换和样式变化代码可读性逻辑集中但调试较抽象元素结构清晰易检查性能建筑较多时更流畅节点过多时会卡顿AI 生成成功率需要更明确的坐标和绘制指令更容易快速出效果我的建议是如果你的赛博城市有大量动态建筑、发光线条、移动车辆Canvas 是更稳妥的选择。如果只是做静态背景和少量灯光闪烁DOM 反而更简单代码也更好维护。2.3 电网与负载让城市“活”起来只画城市不画电网城市就是一个背景图。要模拟“断电自救”必须让城市里的建筑有耗电、有负载、有供电关系。可以这样做每个建筑对象都包含一个基础属性和状态。const buildings [ { name: 医院, x: 120, y: 300, power: 80, critical: true }, { name: 通讯站, x: 400, y: 250, power: 50, critical: true }, { name: 商业楼, x: 650, y: 320, power: 30, critical: false }, { name: 住宅区, x: 220, y: 450, power: 20, critical: false } ]; let totalLoad buildings.reduce((sum, b) sum b.power, 0); let gridCapacity 180;当totalLoad超过gridCapacity或者某次随机事件让电厂输出下降系统就会进入断电状态。这个模拟不需要太精确但至少要让页面上的“亮度”和“供电状态”关联起来而不是各画各的。2.4 断电自救从检测到恢复的完整闭环这是整个页面最有技术含量的部分也是标题里“会断电自救”的关键所在。完整的自救闭环至少包括四个动作检测、响应、恢复、通知。function handleOutage() { setState(STATE.OUTAGE); dimNonCriticalBuildings(); activateAlarm(); tryStartBackupGenerator(); } function tryStartBackupGenerator() { if (backupFuel 0) { setState(STATE.BACKUP); powerCriticalBuildings(); showMessage(备用电源已启动); } } function restoreGrid() { setState(STATE.RESTORING); restoreBuildingsBatch(); setTimeout(() { setState(STATE.NORMAL); showMessage(电网已恢复); }, 3000); }很多人会忽略“通知”这一步。其实状态面板和文字消息非常重要它让观看者能立刻理解系统当前处于哪个阶段。Claude 生成这类交互逻辑时只要你的需求里明确写了“页面顶部显示当前系统状态”它通常会把状态栏一起做出来。3. 从零到跑通一次完整的生成与验证流程如果你也想复现这个效果不建议直接把标题复制给 Claude 就等结果那样成功率不高。更稳的路径是准备环境 - 写需求规则 - 生成原型 - 验证行为 - 迭代修改。3.1 生成前先确认环境这个项目是纯前端 HTML不依赖 Node 或构建工具但要先确认三件事你的浏览器能正常打开本地 HTML 文件。你的 Claude 使用渠道是畅通的网页版或桌面版都可以。如果你打算用 Claude Code 做后续迭代需要确认安装环境、依赖和权限是否正常。注意不要把 Claude 生成的 HTML 文件放在需要跨域限制严格的复杂项目目录里直接放到一个独立文件夹即可。单文件预览出现空白时优先检查是不是文件路径或浏览器缓存问题。3.2 给 Claude 的需求别写成“好看的画面”写成“可执行的规则”我常用的提示词结构是角色 目标 规则 界面 验证方式。下面是一个可以直接参考的提示词模板请用单个 HTML 文件实现一座赛博城市的动态模拟。 城市包含以下元素 - 发电厂 - 配电网络 - 建筑群 - 路灯 - 状态面板 页面需要模拟“断电自救” 1. 城市正常运行电网稳定所有建筑正常亮灯。 2. 运行一段时间后有一定概率发生断电。 3. 断电后非关键建筑灯光变暗警报灯亮起。 4. 备用电源自动启动优先维持医院、通讯站等关键设施。 5. 一段时间后电网修复系统自动切回主电源。 6. 页面顶部用状态文字显示当前系统状态。 视觉风格要求 - 赛博朋克风格 - 深色背景 - 青色和霓虹红色为主 - 使用 Canvas 渲染 请输出完整可运行的 HTML 文件。这样写的好处是Claude 不会把注意力放在“好不好看”上而是先处理“系统怎么运转”。视觉部分通过风格描述补充即可。3.3 拿到代码后按五个行为验证生成代码不等于完成。我会先做五步行为验证任何一步不通过就回去迭代打开 HTML看城市是否正常运行所有建筑和路灯是否亮起。等待随机断电事件或者点击“模拟断电”按钮确认灯光会变暗。检查备用电源是否在断电后自动启动状态面板是否出现“备用电源已启动”。等待电网修复确认系统能切回主电源灯光是否分批恢复。刷新页面确认城市能从头开始运行。这五步本质上是在验证状态机的五个转化正常到断电、断电到备用、备用到恢复、恢复到正常、以及初始状态。3.4 出问题时的排查链路用 AI 生成前端页面遇到问题很正常。我的排查顺序是从现象到输入再到环境再到代码逻辑。现象可能原因检查方式页面一直正常运行从不断电随机事件概率太低或没有模拟断电按钮查看代码里是否有定时器和随机事件断电后所有灯都灭了备用电源无效备用电源逻辑没有接入关键设施判断检查powerCriticalBuildings是否只恢复了关键建筑刷新后城市状态恢复但页面报错代码依赖了外部资源或未定义变量打开浏览器控制台查看报错信息HTML 文件无法预览文件扩展名不对或浏览器打开方式不对右键用浏览器打开确认文件路径没有特殊字符页面打开后黑屏Canvas 尺寸或绘制坐标异常查看浏览器控制台报错检查 Canvas 宽高是否设置如果是用 Claude Code 做迭代时出现安装类报错比如类似 “native binary not installed” 或者权限被禁用的提示处理思路也是一样先看错误信息发生在哪一层再检查依赖、重新安装、确认组织策略是否有访问限制。不要一上来就改代码那是错误的排查顺序。4. 从演示到工程化还差几块拼图很多人在看到 AI 生成的 HTML 效果后会产生一种“是不是可以拿它直接做产品”的错觉。但演示和工程系统之间还隔着好几块拼图。4.1 单文件演示的价值和边界单文件 HTML 有它不可替代的价值适合学习、适合快速原型、适合做概念验证。你只需要一个浏览器就能在城市里观察电力系统的连锁反应。但它的边界也很明显没有持久化刷新后数据全部清零。没有测试无法保证状态逻辑在复杂场景下不出错。没有构建体系代码一旦膨胀就难以维护。没有权限和日志放在真实项目里无法追踪问题。如果你只是想把“断电自救赛博城市”分享给朋友或者用它做教学演示单文件完全够用。如果你想把它做成一个长期维护的产品那还需要把这套逻辑拆成组件、补上数据层和测试再逐步引入构建流程。4.2 是否需要引入 Claude Code这里要区分一个场景如果只是想体验 AI 生成单个 HTML用网页版就够了不需要在本地安装 Claude Code。什么时候才需要考虑 Claude Code需要在一个项目目录内多次迭代多个文件。需要把生成的 HTML 和脚本一起维护。需要让 AI 读取现有文件、修改局部逻辑。需要把 AI 的修改纳入 git 管理。在这些场景下Claude Code 的优势才真正体现出来。你可以让 AI 打开现有文件定位“断电恢复”函数加一个“天气系统”或“日志面板”而不是每次重新生成一个完整页面。安装和配置 Claude Code 时常见问题通常集中在三处依赖安装不完整、环境变量没生效、权限或版本不匹配。如果你遇到报错先别急着怀疑代码逻辑按“环境 - 依赖 - 权限”的顺序排查一遍。4.3 把“生成体验”变成“可复用生成流程”我从这个项目里提炼出的不是一个城市而是一个可复用的 AI 生成流程三步先定规则把需求拆成状态、事件、条件。再生成原型让 AI 输出最小可运行版本。最后增量迭代每次只改一个属性或一个行为验证后再继续。这三步不仅适用于生成 HTML也适用于任何 AI 辅助开发任务。它的核心思想是AI 擅长生成大块代码但不擅长替你判断“这个需求是否正确”。规则越清楚生成结果越稳定。我整理成一张表阶段你要做的事验证标准失败时怎么办定规则用文字写清楚系统如何运行规则中没有明显冲突补全状态转换条件生成原型让 AI 输出一个可运行 HTML页面能在浏览器打开改为分步描述减少一次性需求增量迭代每次只改一个功能点新功能不破坏旧功能回退代码重新描述修改范围5. 这件事真正改变的是什么最后一个部分我想跳出“怎么让 Claude 写赛博城市”这个具体操作说说这件事对开发者意味着什么。5.1 开发者角色正在迁移过去我们写一个城市模拟器要先想架构、写渲染、写逻辑、测边界。现在 AI 已经把“从零到可用原型”的成本压得很低开发者的角色正在从“写代码的人”变成“定义规则的人”。你不需要告诉 Claude 每一行代码怎么写但你需要告诉它城市有哪些状态状态之间如何切换什么条件下触发断电备用电源要保护哪些建筑。这种能力不是提示词技巧而是系统设计能力。5.2 适合谁、不适合谁这个方案适合前端初学者通过一个完整项目理解状态、渲染、事件的关系。原型验证者快速验证“供电系统 多建筑 状态切换”的想法。内容创作者做一个可交互演示比录屏更有说服力。想学 AI 协作的人这是一个很合适的练习样本。不适合真实生产系统它没有持久化、备份、权限和日志体系。强交互复杂项目多人协作、接口联调、高并发场景还差很远。追求像素级还原的正式产品页这类需求还是应该走正规前端工程流程。5.3 长期看值得养成的三个习惯从这次“用一个 HTML 造赛博城市”里我收获最大的不是代码而是三个习惯第一个先定义“系统状态”再描述“页面效果”。这能让 AI 生成的代码更有逻辑也更可维护。第二个小步验证。每次只改一个变量刷新页面观察变化再继续下一步。不要一次性要求 AI 输出一个巨大子系统。第三个写清楚“不做什么”。如果某个区域不应该被备用电源供电一定要在白纸黑字里说明。AI 和协作一样边界越清晰结果越可控。我在写完这座城市的页面之后把浏览器关闭又打开城市从头开始运行。那一刻我意识到我们不再需要从第一行 HTML 学起才能拥有一个可运行的系统模型。真正值得关注的是你怎么把一个“会不会断电自救”的模糊念头变成一套可以验证、可以解释、可以迭代的规则集。哪怕你身边没有 Claude这个思路也完全成立。下一次当你手里有一个模糊想法时不妨先试着把它拆成状态、事件和恢复流程。剩下的事情工具会帮你完成。