零基础用AI对话开发网页，免费部署上线的完整复盘

说实话，我到现在写 HTML 还是得靠 AI 帮我把标签补全、把样式调对。但这完全不妨碍我真的把一个网页从零做出来，并且成功部署上线，让朋友用手机就能访问。这篇文章想认真聊聊的，就是作为一个几乎零代码基础的人，我是怎么靠 AI 对话工具完成一个网页开发，再通过 GitHub 免费托管上线的完整过程。它不是什么高深的技术教程，更像是一次真实经历的复盘，里面包含了我的每一步对话、每一次翻车，以及那些踩过之后才明白的坑。

这件事适合谁？两类人。第一，跟之前的我一样，心里有个小需求，想做个网页或小工具，但一看到代码教程就犯怵的人。第二，已经开始用 AI 对话工具，但只拿它写文案、查资料，还没试过让它写代码的人。我会尽量把过程讲得足够具体，具体到你照着走一遍，也能在几天之内拥有一个属于自己的在线网页。至于"不会代码"这个说法，我也会在最后给出一个诚实的结论——哪些环节确实不用会代码，哪些环节，依然绕不开你脑子里的逻辑。

1. 一个零基础的人，为什么突然想自己做网页

1.1 从"需求冲动"到"被现实劝退"

事情的起因特别朴素。我家里养了几盆植物，绿萝、龟背竹、仙人掌，加起来七八盆。我总记不住每盆什么时候该浇水。有的要两天一次，有的要一周一次，还有的多肉一个月不浇也没事。手机上装过几个植物养护类的 App，要么广告多得烦人，要么功能太重，得给每盆植物拍照建档。我想要的其实特别简单——打开一个页面，能看到每盆植物离下次浇水还有几天，浇完水之后点一下按钮，日期自动重置。

就这么个小需求，我一开始也想过去找教程。结果打开前端入门内容一看，HTML、CSS、JavaScript、框架、构建工具、版本管理……名词一个接一个。我当时的反应是：算了，不如直接拿个日历本记着。这是大多数非技术人最常见的心理——不是没有需求，而是被"学习曲线"吓退。毕竟我本来要的只是提醒浇水，不是转行当程序员。

1.2 转折点：发现 AI 对话真的能"代写代码"

真正让我改变想法的是一次闲聊。当时我在跟一个做开发的朋友吐槽这个需求，他说了一句让我印象很深的话："你直接用 AI 对话工具让它写啊，现在这些大模型写前端小页面基本没问题，你负责提需求，剩下的交给它。"我半信半疑。在我的认知里，写代码是需要系统学习的技能，怎么可能靠"聊天"就写出来。但当天晚上我试了一下，让 AI"写一个简单的网页，标题是欢迎页"，它几秒钟就给我返回了一段代码。我把代码复制下来，存成 html 文件双击打开，浏览器里真的出现了一个页面。

那一刻的感觉有点像第一次用微波炉热菜——明明按钮很简单，却总觉得会出问题，结果一试发现真的能转。接下来我的思路就彻底打开了：既然 AI 能写出比我预期更完整的代码，那我是不是可以把我原本放弃的那个"植物浇水提醒页"需求发给它试试？这个念头直接催生了后来一周的折腾，也让我第一次完整走完了"提需求 → AI 写代码 → 本地跑起来 → 部署到线上 → 分享给别人用"的全流程。回头看，这次经历带给我的不只是一个小网页，而是对"编程"这件事祛了魅。

1.3 为什么选择"AI 对话开发"而不是"先学编程再开发"

后来也有人问我：你为什么不先花两三个月学点基础？说实话，我的需求很明确，就是一个单页面的小工具。如果走传统学习路径，我得先分辨哪些知识是为了应付考试、哪些是实际开发需要的，光这个筛选过程就得耗费不少精力。而 AI 对话开发的最大优势，是我可以直接用"自然语言"跟一个什么都会的助手沟通，并且随叫随到。我不需要提前知道答案，只需要不停地提出要求、反馈问题，它会基于我的反馈调整代码。

但这里有一个诚信问题要说明白：所谓"不会代码也能开发"，并不是说完全不需要动脑。你至少得知道自己想要的页面长什么样，功能跑起来是什么逻辑。换句话说，代码语法可以不会，产品逻辑必须会。这就好比你可以不会开车，但你必须知道自己想去哪、走高速还是走省道。AI 是那个司机，你依然是导航。这个定位想清楚之后，后面的事情就顺理成章了。

2. 动手前，先把"我要什么"想明白

2.1 把模糊想法变成 AI 能听懂的需求

很多人第一次让 AI 写代码，给的描述往往是"帮我做一个好看的网页"。AI 回了一大段通用代码，结果页面出来了，但完全不是自己想要的东西。问题不在 AI，而在"好看"这个词太模糊。我自己在第一版需求上也吃过亏。我最初的描述是"做个页面记录植物浇水"，AI 返回了一个非常简陋的表格，只有一个标题和一行示例数据。我当时有点失望，但冷静下来之后意识到：是我自己都没想清楚功能细节，凭什么要求 AI 替我把产品设计做了？

于是我开始把需求一条一条写下来，参考的是互联网产品经理写需求文档的路子。不是我懂产品，而是我发现，分条列点是最容易让 AI 理解的信息结构。我来回花了 20 多分钟，最终把需求细化成了下面这样：

• 页面顶部显示标题"我的植物养护记录"
• 有一个表单，可以输入植物名字和浇水间隔天数（几天浇一次）
• 所有植物以卡片形式展示在页面上，每张卡片包含：植物名、上次浇水日期、距离下次浇水还剩多少天
• 每张卡片上有一个"已浇水"按钮，点击之后把该植物的上次浇水日期更新为当天
• 数据要保存在浏览器本地，刷新页面后不丢失
• 界面要简洁、清爽，可以不用太花哨

写完之后我自己都觉得惊讶——这些需求每一条都是大白话，没有任何术语，但它的结构非常清晰。把这段需求发给 AI，我特意加了一句话"你是一个有经验的前端开发者，请按照我下面的需求写一个完整的单页网页"。这回 AI 返回的东西完全不一样了，有表单、有卡片区域、有按钮，还有处理数据存储的脚本。所以我想给所有零基础朋友一个建议：你花在思考需求上的时间，永远不会浪费。需求越具体，AI 给出的代码越接近你要的东西。

2.2 跟 AI 沟通的三个小技巧：身份、限定、追问

我把这次实践里最有用的沟通技巧总结成三句话。

第一，给 AI 设定身份。开头加一句"你是一个资深的前端工程师"或者"你是一个有五年经验的全栈开发者"，它返回代码的完整度和规范程度会有肉眼可见的提升。这不算玄学，更像是一种聚焦机制——它会把回复的语气和内容自觉地调整到专业人士的水准。

第二，限定范围和格式。如果你希望代码分成 html、css、js 三个文件，就明确告诉它"请分成三个文件，index.html、style.css、script.js，并在 HTML 里正确引用这两个文件"。不说的话，AI 往往图省事，把样式和脚本全塞进一个 HTML 文件里，虽然也能跑，但后面想改某个细节时，你会在一个几百行的文件里找得头晕眼花。

第三，追问不解的细节。AI 返回代码之后，你不懂某个英文单词、某一行逻辑，可以直接让它解释。比如我那时候问过它"localStorage 是什么？为什么数据能刷新后还在？"它用一段大白话解释给我听：浏览器给每个网站分配了一块小仓库，网站可以往里面放数据，下次打开网页时再取出来。这种随时追问的能力，是传统教程根本给不了的体验，也是 AI 对话开发最被低估的价值。

2.3 需要用到的三样东西，缺一不可

在正式动手之前，我把工具准备了一遍，其实只需要三样。

第一，AI 对话工具。这个不用多说，选一个你现在用着顺手的就行。第二，一个能写代码的编辑器。如果你是零基础，我不建议一开始就去折腾本地环境，更推荐直接用在线代码编辑器——打开网页就能写，还能实时预览，省去安装配置的折腾。我当时就直接在浏览器里新建了三个文件，把 AI 生成的代码分别粘贴进去，右边窗口马上能看到页面效果。等你确定这套流程能跑通，再考虑要不要装本地的专业编辑器。第三，一个 GitHub 账号。它是全球最大的代码托管平台，我们要用它提供的免费静态网页托管来上线网站。注册流程很简单，只需要邮箱和设置密码，没有额外的门槛。

需要说明的是，这三样东西里，前两样是开发阶段用的，第三样是部署阶段用的，全程没有花一分钱。这也是我后来愿意把这套流程推荐给身边朋友的重要原因——工具的门槛和资金的门槛都被压到了最低。

3. 和 AI 对话写网页：从第一版到能用，我经历了什么

3.1 第一轮对话，让 AI 给我一个"能跑的骨架"

我当时的提问原文大概是这样：

"你是一名前端工程师。请帮我做一个植物浇水提醒网页，需求如下：页面标题'我的植物养护记录'；有一个表单可以添加植物，输入植物的名字和浇水间隔天数；已添加的植物以卡片列表展示，每张卡片显示植物名、上次浇水日期、距离下次浇水还剩几天；每张卡片上有'已浇水'按钮，点击后把该植物的上次浇水日期更新为今天；所有数据用 localStorage 保存，刷新页面不丢失。请用 index.html、style.css、script.js 三个文件实现。"

这条消息发出去，AI 很快就返回了三段代码。我做的第一件事不是去读代码，而是按它说的建了三个文件，把内容分别粘贴进去，然后在在线编辑器里打开预览。页面的骨架已经出来了：顶部是一个标题，下方有一个输入框和添加按钮，再往下是空空的卡片区域。那一刻我承认是有点兴奋的——虽然页面还很简陋，但我清楚地知道，一个会随我操作变化的东西已经诞生了。

接下来我试着添加了一条测试数据，在"植物名"里输入"绿萝"，在间隔天数里输入"3"，点击添加。卡片区域立刻出现了一张淡绿色的卡片，上面显示着绿萝、上次浇水的日期、距离下次浇水的天数。我刷新了一下浏览器，数据还在。第一轮验收，通过。

3.2 不懂代码，怎么判断 AI 写得对不对

页面跑起来了，但我心里还有一个隐忧：我完全看不懂代码，万一里面藏着问题怎么办？后来我慢慢摸索出三个"零基础验收"方法，非常管用。

第一个方法，把功能从头到尾点一遍，模拟真实使用。我连续添加了三四盆植物，修改间隔天数，点掉某些卡片，反复刷新页面确认数据还在。只要任何一个环节的表现跟我的预期不一致，就是一个 bug。第二个方法，打开浏览器的开发者工具看报错。在预览页面按 F12 或者右键选"检查"，切到"控制台"标签，如果代码有错误，这里会出现红色报错信息。我一开始看到满屏英文字母也懵，但学会了复制报错内容丢回给 AI 问"这是什么意思？怎么解决？"——这招帮我在后面一周里排掉了至少五个问题。第三个方法，改一个数字看变化。比如把浇水间隔从 3 改成 7，如果页面上的天数计算跟着变了，说明对应的逻辑是通的。这种"黑盒测试"的思路，不需要懂代码也能验证代码质量。

3.3 三次有代表性的修改：AI 是怎么配合我迭代的

第一版能跑之后，我进入了一个漫长的"调整 — 验收 — 再调整"的循环。这中间有三轮修改最有代表性，也最能体现 AI 对话开发的真实工作方式。

第一次修改是样式问题。我嫌卡片挨得太挤，而且逾期浇水的卡片没有任何提醒，容易看漏。我的原话是："卡片之间的间距太窄了，能不能大一点；距离下次浇水已经小于等于 0 天的植物，卡片背景变成浅红色并把文字加粗。"AI 很快改好了代码，更新之后页面效果立竿见影。这件事让我意识到，你不需要会说"我需要一个 margin 或 padding 调整"，你只需要说出你看到的效果不对、你期待什么效果，AI 会自动翻译成代码。

第二次修改是功能 bug。我发现一个问题：连续给同一盆植物点"已浇水"，第一次能正常更新日期，第二次再点却没有反应。我完全不知道怎么排查，只能把现象详细描述给 AI："卡片上的已浇水按钮，第一次点击后日期更新了，再点第二次没有任何反应，数据也没有变化。"它在一分钟之内定位到了问题——原来是我添加植物时，如果出现了同名的植物，代码里查询植物的 ID 逻辑写错，导致第二次点击找不到对象。它给出了修正后的代码，我替换进去，再试，正常了。整个过程我没看一行代码逻辑，只是负责把现象讲清楚。

第三次修改是加新功能。我想让卡片按"紧急程度"排序——最需要浇水的排在最前面。这个需求我自己都不知道该用什么词描述，就直接说"我想让卡片按剩余天数从少到多排序，剩余天数最少的在最前面"。AI 理解了，往渲染函数里加了一段排序逻辑。从那以后我才真正意识到，我跟 AI 之间最好的状态不是我命令它，而是我描述愿望、它实现功能，然后我验证结果。

3.4 一个"不会代码"的人的 AI 开发心法

这段经历让我总结出一个心法：我不会写代码，但我可以做产品经理加测试工程师。产品经理负责定义需求和验收标准，测试工程师负责找 bug 提反馈，中间那一层具体的代码实现交给 AI。这三者并不要求你会写代码，但要求你思路清晰、表达准确、愿意测试。

有个细节特别关键：跟 AI 沟通 bug 时，一定要提供具体信息，包括你做了什么操作、看到了什么现象、期望是什么、有没有报错、报错内容是什么。我见过很多人只会丢一句"这个不对"，然后就没了。AI 当然很强，但它是靠上下文推理的，你给的线索越具体，它能做的判断越准确。我在整个过程里反复利用这个原则，几乎没有出现"AI 改了三轮还修不好"的情况。

4. 网页做好了，怎么免费上线到 GitHub

4.1 为什么我选了 GitHub 而不是别的方案

本地页面能跑，功能也符合预期，接下来就是最让人激动的一步：把它放到公网上，让朋友输个网址就能访问。我在朋友的推荐下了解了 GitHub，它在代码圈里几乎是"代码仓库"的代名词，但它同时还提供一项叫 GitHub Pages 的功能，专门用来托管静态网页。所谓静态网页，就是不需要服务器在背后跑程序、内容提前写好放在那里的页面。我的植物提醒页恰好就是一个静态网页——所有数据都存在访问者自己的浏览器里，没有后端数据库，也不需要服务器运算。

对比而言，我有几个方案可选。一是租一台服务器自己配环境，Docker、Nginx 这些名词一听就让我头大，直接放弃。二是买个域名加托管空间，能搞定但要花钱，我这个阶段不太想投入。三是 GitHub Pages，免费、稳定、流程相对简单，而且是开发者社区的主要阵地，出了问题网上一查到处都是答案。虽然它只支持静态页面，不支持动态后端，但对我来说完全够用。这个选择背后的逻辑其实也适用于所有零基础的人：先选最简单的路径，跑通全流程，再考虑升级。

4.2 不敲一行命令也能上线：GitHub 网页上传与 Pages 启用全流程

网上大量部署教程默认你已经会 Git 命令，动不动就让你在终端里敲 git init、git add、git commit。对我这种零基础来说，看到 command line 就想关网页，很容易卡在这一步就放弃了。所以我特别想说明：GitHub 官网提供了纯网页操作的方式，你完全可以不碰终端就上线一个静态网站。我当时就是一步步点鼠标完成的。

第一步，注册登录 GitHub 后，找到页面上的"New repository"按钮，创建一个新仓库。仓库名字我建议起一个跟你项目相关的英文名，比如 plant-care。这一步会问你是公开还是私有，公开的话任何人都能看到你的代码，对于分享型项目没问题；私有的话也可以，但 GitHub Pages 用起来不方便，建议先选公开。

第二步，在新仓库页面找到"uploading an existing file"这个入口，点进去之后把本地准备好的 index.html、style.css、script.js 三个文件直接拖进上传区域，然后点确认提交。这里不需要敲任何命令，跟往微信里传文件一样简单。我上传完成后在仓库里能看到三个文件静静躺在列表里，那一刻感觉特别奇妙——我"写"的代码，居然真的被托管到一个全球知名的代码平台上。

第三步，打开仓库的"Settings"页面，往下找到"Pages"这个菜单项，在"Source"下拉框里选择 main 分支，点击保存。页面会提示你正在构建，稍等一下。第一次我等了大概两分钟，刷新之后页面多了一行白色的网址提示：你的网站已经发布，地址格式是 https://你的用户名.github.io/仓库名/。我战战兢兢点了一下那个链接，加载了几秒钟，然后我亲手做的页面就出现在浏览器里了。于是我把这个网址发给家人朋友，让他们打开看看。一个完全属于我自己的网页，就这么上线了。

4.3 上线之后的第一课：响应式布局和真实设备测试

刚上线那个晚上，我很兴奋地拿手机打开这个链接，结果差点没被劝退。手机屏幕上，我精心调整的卡片挤成一条窄窄的竖线，字体小到要放大才能看清，整个页面看起来就像是拿台式机显示器硬塞进手机屏幕一样。我这才真实体会到，原来电脑上好看的页面，在手机上不一定好看。去问 AI 才知道，我原本的样式没有做响应式适配，也就是没有针对不同屏幕尺寸自动调整布局。

这个问题也暴露了我之前的一个盲区：我在在线编辑器里预览时，一直是在电脑的浏览器窗口里看的，从没试过用手机访问。于是我又多了一个习惯——每次改完代码，先发到线上测试地址，再拿手机打开看一遍。AI 帮我给页面的卡片加上了合理的百分比宽度、断点查询和字号适配，改完以后再从手机打开，终于是能正常阅读的布局了。这件事让我记下一个重要教训：网页不是写完就完了，必须在你目标用户可能用的设备上真实测试。而我作为零基础的人，恰恰拥有最好的测试条件——我本身就是一个普通用户，而不是一个被代码惯性影响的开发者。

4.4 后续更新到底怎么操作？我踩过的"覆盖上传"坑

上线后的第二天我想改一个功能，当时我完全不知道该点什么。我本想在仓库里直接改，但找半天没找到入口。后来发现，只需要在仓库页面再次进入"Add file"里的"Upload files"，把你本地的同名文件再拖一遍进去，就能覆盖掉原来的文件。当时我以为这就是全部了，却踩了一个坑：提交时没观察好提交信息的逻辑。实际上覆盖上传没问题，但如果你同时修改了两个文件，却只上传了其中一个，线上的页面就会出现错乱——比如样式丢失、功能报错。

后来我养成了一个习惯：每次更新本地三个文件之后，要么不嫌麻烦地三个一起重新上传，要么让 AI 在本地提前把所有改动合并好，我确认无误之后一次上传。GitHub Pages 从提交到线上的生效大概有一两分钟延迟，所以上传后我通常会等一会儿再刷新页面。千万不要连续重复提交，否则你自己都搞不清线上到底跑的是哪个版本。这个习惯帮我避免了好几次"线上怎么变坏了"的困惑。

5. 踩坑实录、常见问题和"零基础上 AI"的真心话

5.1 我踩过的坑和速查表：AI 开发最常见的六类问题一次说清

下面这个表格整理了我在整个过程中遇到的所有典型问题、排查思路和解决办法。如果你是照着这条路径走，碰到类似情况可以直接对照处理。

这里面，最频繁出现的是第二类问题。我想多说一句：浏览器的控制台对零基础用户来说，与其说是给开发者看的东西，不如说是一个"翻译通道"。那些红色报错看起来是英文乱码，但对 AI 来说就是最精准的线索。你只需要复制粘贴，再问一句"这是什么问题"，AI 就会告诉你原因和改法。这个过程我第一次用的时候感觉很神奇——我不认识的文字，AI 认识；我看不懂的逻辑，AI 看得懂；而我只需要扮演一个传话筒的角色。

5.2 零基础需要补的"不是代码"的三个能力

经过这次完整的开发体验，我想把"不会代码也能做网页"这个说法做一次修正：不会写代码确实可以完成开发，但有三种能力你必须有，它们都不属于编程知识，却直接决定你项目能不能成。

第一是描述需求的能力。AI 共情不了你脑子里的含糊想法。你说"做一个好看的页面"，它只能做它理解的好看；但你说"页面左侧显示项目列表，右侧显示详细信息，列表项用圆角卡片装"，它就完全知道该怎么做。描述得越具体、越分条，AI 的产出越可控。

第二是测试验收的能力。你得愿意把自己当成一个挑剔的用户，把按钮挨个点一遍，把各种奇怪的输入都试一遍，快速发现问题。说真的，这个能力很多从业多年的人都不一定做得好，我在过程中发现它其实很珍贵。

第三是追问到底的勇气。遇到不懂的名词不要跳过，直接问 AI 是什么意思、为什么这样写、换个方案行不行。这些当场追问比你看十篇教程都管用，因为它是紧密围绕你的项目和当前认知水平展开的。

5.3 AI 对话开发的边界：什么能做，什么别硬做

我做完这个网页之后，曾经很兴奋地想让 AI 再做一个带用户登录、能多人协作的记账网站。但问了一圈，得到的答案是那样需要后端服务器、数据库、用户鉴权等一系列工程，远不是三个静态文件就能解决的。这个例子很好地说明了 AI 对话开发的边界。

目前我体感比较适合用 AI 对话从零做的项目，包括个人主页、作品集、工具型单页应用、数据展示面板、学习 Demo，以及各种内部小工具。这些项目的共同点是：以信息展示和轻交互为主，不需要高并发，不需要跨用户数据同步，不涉及支付等敏感操作。反过来说，如果一个项目是请你做一个电商平台、一个社交软件、一个即时通讯工具，甚至是一个带用户注册和数据库的完整系统，那"零基础 + AI"这套组合拳就力不从心了。不是说完全做不了，而是复杂度会指数级上升，出错之后你连问题都描述不清，AI 也无从下手。

我对零基础朋友的建议一向是：第一次做项目，选一个足够小的需求，小到它可以在一个页面内展示全部核心功能。植物提醒页就是这么个例子。做成之后，你对全流程有了体感，再逐步挑战带登录、带后端存储的方案。路要一步步走，第一次就选高难度目标，很容易在某个环节被不熟悉的概念卡住，最后连已经学会的东西都放弃了。

5.4 我的真心话：会逻辑，比会语法更值钱

做完这个网页半个月后，我回头审视整段经历，最大的体会是：AI 把"写代码"这件事的门槛砍掉了一大截，但"编程思维"的价值反而被放大了。所谓编程思维，拆开来看就是我前面反复提到的——把模糊想法拆成可执行步骤、定义验收标准、用最小步骤验证假设、在出错时精准描述问题。这些能力一点都不神秘，也不依赖数学天赋，它们是人人都可以通过做一个小项目训练出来的。

有一次我让 AI 添加一个"按浇水紧急程度排序"的功能，它第一次实现的效果是：所有数据每次刷新后重排，排序只生效一次。我发现后并没有直接说"你做得不对"，而是说"我重新打开页面之后，顺序应该还是保持着排序后的状态"。这句话里面其实包含了一种对"操作时间点"和"数据持久性"的理解，而这个理解来自我的生活直觉，不是编程知识。AI 收到这句话之后马上进行了修正。这让我意识到，哪怕我不会一行代码，只要我的逻辑表达清楚，AI 就能帮我把逻辑落成代码。反过来，如果我自己都迷迷糊糊，AI 给出的代码自然也歪到不知道哪里去了。

5.5 如果让我重新来一次，我会在第一天就做的事

回顾全程，我其实有些环节绕了远路。如果在第一天，有个人能告诉我下面这几句话，我的效率应该会高不少。现在我把它写在这里，送给准备尝试的你。

第一天就注册好 GitHub 账号，不要等到网页做完了才开始折腾部署，因为部署环节的问题需要提前暴露；第一天就养成按 F12 开控制台的肌肉记忆，哪怕看不懂，也要在遇到问题时先打开它，因为那是 AI 最需要的线索来源；第一天就把需求写成一个按条列举的文档，而不是直接开口说"帮我做个东西"；时刻记住，你在跟 AI 对话时不是在打字聊天，而是在"做产品评审"。

写在最后的几点经验

做完这个网页之后，我整个人的状态跟之前不太一样了。以前我刷到别人做的工具站，会觉得那是"技术圈的人"才能碰的东西，现在我会下意识地想：这个页面用了什么数据结构？数据存哪里？我自己能不能也做一个类似的？这种视角的转变，在我看来，比那个植物提醒页本身珍贵得多。

如果让我再分享一个亲测有效的细节，我想说：做第一个项目，一定要从中选一个你自己真正会天天用、或者愿意发给你朋友的功能。因为只有真实需求，才会驱动你在遇到困难时不轻易放弃。像我后来会真的打开那个网页看我的龟背竹是不是该浇水了，也会因为朋友反馈"手机上看字太小"而认真去调一次布局。这种正反馈循环，是坚持完成一个项目最重要的燃料。

下一步，我计划在这个植物提醒页上加一个"养护记录"功能，每次浇水时可以顺便写一句备注。我还是会用 AI 对话来实现它，同时这次我决定顺手把它背后的 JavaScript 基础语法稍微学一点。不是为了取代 AI，而是为了在 AI 偶尔犯错的时候，我能更快发现，而不是稀里糊涂地只知道说"不行，你再改改"。这条路上，AI 负责把技术落地，我负责把想法说清楚，两者配合起来，笨拙但真实，倒也有一种踏实的乐趣。