标题我写的是“纯炫耀不卖课”。看到这句话你应该能猜到这不是一篇付费课程的营销文也不是所谓“三天让你变成AI开发专家”的速成指南而是最近我确实花了几个周末用AI做了一些帮助学习的小网页比如一个完全按自己习惯设计的单词复习页、一个随机抽题的错题练习页、还有一个代码片段速查页。它们都不复杂有些甚至只有一个单页文件但关键是——它们真的被我天天打开而不是做完就丢进收藏夹吃灰。这个体验让我重新理解了“AI辅助开发”这件事。以前我总觉得做网页是程序员的事要懂HTML、CSS、JavaScript还要处理部署、调试、兼容性一堆问题。但现在你只需要把需求描述清楚AI就能生成一个可以运行的骨架你再根据自己的需求去调整细节整个过程从“感觉很难”变成了“我可以试一试”。我甚至觉得这是AI目前最接地气的用法之一不追求做出多庞大的产品只为了把一个学习场景里的小痛点变成一个属于自己的、能坚持用下去的小工具。所以这篇文章的核心判断很简单用AI做学习小网页真正的价值不是省下多少开发时间而是它把“我有一个学习需求”和“我有一个能用的工具”之间的距离缩短到了几乎可以忽略的程度。至于怎么把这个距离走好接下来我会从选型、实现、部署、踩坑到长期使用一步一步拆开讲。1. 为什么“学习小网页”最值得用AI试一次1.1 学习场景天然适合小而具体的工具学习场景里有一个特别适合个人开发的特点需求通常非常具体范围非常小。比如“我想每次打开看到一个单词下面有四个选项我选择之后它告诉我对不对然后把结果记下来”。这个需求听起来很朴素但它逻辑清晰、边界明确没有复杂的权限体系没有多人协作没有高并发也不需要真正的后端服务。这类小工具的另一个好处是结果能即时验证。单词页显示是否正确、按钮能不能记录点击、刷新后数据还在不在、换一个浏览器打开是否正常每一步都是能立刻看到反馈的。这种即时验证对新手很友好你不用等“项目跑起来”再去调试因为你做的本来就是一个打开就能跑的页面。相比之下如果你一上来就想做一个“全功能学习平台”有用户注册、有后台管理、有数据统计图表那这件事的复杂度会指数级上升。AI虽然能帮你生成不少代码但架构设计和系统边界仍然需要人来把控。所以我的第一个建议是如果你的目标是解决自己的学习问题而不是训练自己做大型项目那就老老实实从小页面开始。1.2 AI让“从想到做”的路径变短了我身边有不少人脑子里其实有很多学习小点子比如“要是有一个工具能让我把错题粘贴进去然后每天随机抽几道让我做就好了”。放在以前这种想法通常活不过三秒因为做网页的成本实在太高了要么自己学前端要么找一个现成工具然后去适应它的操作习惯而不是让它适应我。AI出现以后这条路发生了变化。你可以把它当成一个“会写代码的同事”你把使用场景描述清楚它把骨架给你搭起来你再在骨架上做调整。以单词复习页为例你只需要告诉它“生成一个单页HTML文件能让我粘贴词库每次显示一个单词和四个中文选项点击后判断对错并记录”它就能给你一个能打开运行的版本。当你亲手做一个网页然后在浏览器里看到它亮起来的那一刻那种成就感确实很难形容。这件事更深层的意义在于它改变了普通人和“开发”之间的关系。以前开发是一个专业分工现在开发更像是一种表达能力。你不需要成为专家也能把自己的想法变成可运行的东西。这种能力的门槛下降才是AI真正带来的变化。1.3 适用边界这个路线适合谁不适合谁任何方案都有边界。这个路线适合以下两类人有明确学习需求但现有工具用起来不顺手的。遇到问题愿意看控制台报错、愿意尝试改一点代码的人。它不适合以下场景完全不想看任何代码细节遇到问题就希望AI“凭空”修好但自己完全没有排查思路的。一开始就想做带账号、数据库、多人协同的复杂系统然后问为什么AI生成的东西不能直接上线。想把这个学习工具做成商业产品、面向大量用户的。说清楚边界很重要因为只有知道自己适合哪条路才不会在错误的方向上浪费时间。如果你只是想解决自己的学习问题那一句话就够了“够用”比“完善”重要得多。2. 一个单词复习页的诞生从需求到可用版本2.1 需求描述用场景说话而不是用功能词我第一次让AI做单词页的时候给的描述很简单“帮我做一个背单词网页。”结果它给我的是一个非常基础的静态例子就是一个页面里写死几个单词和释义没有任何交互。这个版本当然不够用。后来我换了方式把需求改成描述使用场景“每次打开页面会看到一个单词和四个中文选项我点击其中一个选项后页面告诉我这个答案是对还是错并且把结果记录下来。下次打开时优先展示我经常记错的单词。”这一版的效果完全不一样。AI理解了“用户在什么时间、打开什么、看到什么、做什么动作、得到什么反馈”这条完整链路生成的代码就明显更有针对性。这里有一个很重要的经验AI即使理解能力再强也需要你把使用流程说清楚。你不需要懂技术术语但你要能把场景描述得足够具体。一个有效的描述至少应该包含三件事用户在什么情况下打开这个页面、页面展示什么信息、用户操作后会发生什么。2.2 最小可行版本先做一个能用的再想更好的做第一版的时候我一直在克制自己“加功能”的冲动。最终第一个能用的版本只有几个元素一个输入框用来粘贴自定义词库。一个大按钮点击后随机显示下一个单词。四个选项按钮。一个计算结果区域的文字提示。一个存储逻辑把每次答题结果保存到浏览器本地。这个版本大概不到一屏代码AI生成起来很快验证起来也很快。跑通之后我才开始考虑加功能比如按错误次数提高出现频率、显示连续打卡天数、一键导出学习记录。而且我给自己定了规则每次只加一个功能用满一周觉得确实需要再动手加下一个。这样避免了一开始就把项目做复杂也保证了每个功能都是真实需求驱动而不是“为了显得完整”而堆上去的。2.3 核心逻辑数据、间隔算法和交互反馈这种学习类小工具UI其实不是核心。真正决定工具有没有用的是三件事数据怎么存、复习间隔怎么算、用户每次操作后能得到什么反馈。存储方面我选的是浏览器自带的 localStorage。你不用架数据库不需要注册云服务一个键值对就能存下学习记录。复习间隔方面我用的是一个简化版策略单词答对了它的下次复习间隔就延长一点答错了就把它安排到明天再出现。这个策略本质上是一套简化版间隔重复思路不复杂但很实用。交互反馈方面每次答题后页面会明确显示“正确”或“错误”并且展示正确答案。这个反馈很重要因为如果答案错了却不知道正确答案是什么那么这次练习的收益会大打折扣。所以在让AI生成逻辑时我会特别强调“答错时一定要显示正确答案”。注意这一类网页应用的核心是“记录”不是“展示”。如果刷新页面后数据全部丢失那它顶多算一个随机展示器不能算学习工具。所以在做第一版时优先把数据持久化想清楚。2.4 代码示例一个常见的复习记录存储写法如果你也打算做一个类似工具下面这段代码是一个很典型的“答题记录”存储写法。它把每次结果写进 localStorage并更新这个单词的复习到期时间。function saveReviewResult(wordId, isCorrect) { const key review-data; const data JSON.parse(localStorage.getItem(key) || {}); if (!data[wordId]) { data[wordId] { correctCount: 0, wrongCount: 0, lastReviewAt: null, dueAt: Date.now() }; } data[wordId].correctCount isCorrect ? 1 : 0; data[wordId].wrongCount isCorrect ? 0 : 1; data[wordId].lastReviewAt Date.now(); // 简化版间隔策略正确则下次间隔延长错误则明天再复习 const intervalDays isCorrect ? Math.min(7, data[wordId].correctCount) : 1; data[wordId].dueAt Date.now() intervalDays * 24 * 60 * 60 * 1000; localStorage.setItem(key, JSON.stringify(data)); }这段代码不是唯一写法你也可以用更复杂的算法、更精细的数据结构。但核心思路是一样的把学习历史保存下来而不是页面一刷新就回到起点。如果你希望这些数据更安全可以顺手在页面上加一个“导出记录”按钮让用户把JSON数据下载到本地。这个功能AI实现起来很容易但对长期使用来说价值很大。3. 部署、数据与日常使用让它真的被打开3.1 部署最简单的方式先把网页挂到公网本地打开一个HTML文件自用当然没问题。但如果想手机也能访问甚至想发给朋友一起用就需要部署到公网。对于这类纯静态页面最简单的方案是用静态托管服务比如 GitHub Pages、Vercel、Netlify、Cloudflare Pages 等都支持免费部署纯前端项目。我在这里不会详细写某一家的注册流程因为各平台的界面和流程经常变化。更推荐的方式是选一个你自己顺手或听说过的平台按照官方引导把项目文件夹推上去或把HTML文件拖上去一般几分钟就能得到一个公网地址。部署时最需要注意的一个细节是路径。如果你的页面里引用了外部CSS或JS文件并且你写的是绝对路径部署后很可能会出现资源加载失败。更稳妥的做法是使用相对路径或者直接把所有代码都写在一个HTML文件里。对于小项目来说单文件是最省心的形态。3.2 让工具真正进入学习流程而不是收藏夹吃灰做完了网页最难的部分往往是你如何说服自己每天都打开它。一个学习工具如果只是躺在收藏夹里那它和不存在没有区别。为了让工具真正进入学习流程我做了三件事第一把页面放到浏览器书签栏手机端则添加到主屏幕。打开成本越低坚持使用的可能性越高。第二在页面上做一个很显眼的“今日复习”按钮一进来就直接进入今日任务不需要任何多余操作。用户不应该思考“我该点哪里”而是打开就进入状态。第三加一个最简单不过的统计连续打开天数。人对“连续记录”这件事有天然的好奇心哪怕只是一个小小的数字也会让坚持变得更有动力。这些改动背后没有复杂的技术但对长期使用影响很大。很多功能丰富的学习App让人坚持不下去不是因为功能少而是因为打开成本太高。自己做工具的优势就在于能把入口做得完全贴合自己的习惯。3.3 问题排查从页面打不开到数据丢失如果自己做的网页遇到问题按照什么顺序排查最有效我会按下面这条链路来如果页面空白先按F12打开开发者工具看 Console 标签页有没有报错。这是最直接的线索。如果按钮点了没反应先确认是 JavaScript 报错还是事件压根没绑定Console 会告诉你具体是哪一行出了问题。如果刷新后数据丢失先检查你是不是用了浏览器的隐私模式或者最近清过缓存。localStorage 数据在这些情况下会被清理。如果手机打开部署后的网页失败先确认地址是否正确、当前网络是否正常再检查部署平台是否整体可用。如果页面在电脑端正常、在手机端布局乱检查网页头部有没有 viewport 设置。AI 大部分时候会加但偶尔会漏掉。这个排查思路的核心原则是先看现象再看输入再看环境再看参数最后才考虑是不是工具本身的问题。不要一看到报错就归咎于“AI写得不行”很多问题其实出在浏览器环境和部署环节。4. 不是无脑爽AI参与开发时最容易踩的四个坑4.1 坑一只复制代码不看逻辑AI生成的代码能跑起来但如果你完全不知道它为什么这么做后续改需求时会非常痛苦。比如你想把“答对后直接显示下一题”改成“答对后先展示正确答案点击确认再进入下一题”这就必须知道当前逻辑在哪里、数据在哪里更新、界面在哪里渲染。如果你完全不懂就只能让AI反复改改了之后又怕改坏其他功能。我的做法是每次拿到AI代码后先让它给核心逻辑加注释或者单独问它“这段代码在做什么”。至少要做到自己能说出“数据从哪里来、存到哪里去、界面如何更新”三件事否则后续迭代很容易失去掌控。4.2 坑二不断打补丁却不保留旧版本AI很擅长生成新代码但它在一个文件上反复修改时有时候会把之前能用的功能改坏。而且AI的上下文窗口有限你在这个对话里改了几轮之后它可能已经忘了最开始加过什么功能。我踩过这个坑后来养成了一个习惯每跑通一个版本就把这个HTML文件复制一份按日期命名存到一个 backup 目录。一旦改坏了随时能打开上一个可用版本。如果项目结构变成了多文件更推荐用 git 做版本管理不需要推送到远程本地提交记录就足够让人安心。这个习惯在长期迭代里几乎是保命级别的。4.3 坑三把 localStorage 当数据库用localStorage 用起来很方便但它的限制也很明显单个域名下大约有 5MB 的存储上限对纯文本记录通常够用但存大量内容时会紧张。它不能跨设备同步手机和电脑的数据是隔离的。浏览器清理数据时会被一起清掉。它不是真正的数据库不适合做复杂查询和多人数据合并。如果你的学习记录真的很有价值比如积累了一年多的复习历史那至少应该提供一个导出功能定期把数据下载到本地。如果希望数据能在手机和电脑之间同步那就需要引入后端服务和云数据库复杂度会立刻上升。这时候你可以考虑做一个真正的轻量后端也可以使用现成的云数据服务。不过这套复杂度只有在你确实需要的时候再引入不要一开始就背上。4.4 坑四追求完美结构忘记学习工具的第一目标是“今天会用”我看到一些朋友让AI生成“学习平台”要有登录、后台、权限、统计面板结果开发了两周还没有上线。这个方向其实已经偏离了“做学习工具”的初衷。做一个学习工具第一目标不是“架构优雅”也不是“功能齐全”而是“今天我能打开它用十分钟并且明天还想再打开”。所以我强烈建议第一版先做一个人能用的最小页面放到手机首屏然后连续用一周。如果一周后你没有遇到特别想改进的痛点说明这个工具已经够用了如果遇到了再针对痛点让AI加功能。这样你的每一个迭代动作都是由真实使用触发而不是靠想象堆需求。5. 从“做一个网页”到“沉淀一套自己的开发方法”5.1 从一次经验到一套可复用的“小工具模板”做了几个学习网页之后我发现它们之间有不少重复结构一个输入区、一组按钮、一个结果展示区、一段存储逻辑。把这些共同点整理出来下次做新工具时就可以基于模板改不用每次从头描述需求。比如一个“随机抽题页”和一个“单词复习页”在数据存储、判分逻辑、统计展示上其实非常像唯一的区别只是题目来源和展示形式不同。如果你也想走这条路我建议你别急着去找现成的框架而是用自己的项目慢慢沉淀模板。先在纸面上画出页面结构再让AI生成一个基础壳子然后把你常用的数据存储逻辑、导出功能、统计功能先加进去。这样一个模板用几次之后会越来越像你自己的“私人脚手架”。5.2 给工具加上反馈闭环统计、回顾、调整一个学习工具如果只是“做完题就结束”那它和普通的练习册没什么区别。真正能帮助学习的工具应该像一个小伙伴一样为你提供反馈闭环。最简单的做法是给页面加上三样东西统计今天完成了多少、累计完成了多少、整体正确率多少。回顾每周自动展示一次本周错题只展示不测试让大脑重新连接一次。调整根据统计结果决定下一个版本要改什么而不是凭感觉加功能。有了这个闭环工具就从“记录结果”升级成了“辅助决策”。你每天打开它看到的不仅是一个成绩而是一个关于自己学习状态的数据画像。这种反馈不一定复杂有时候几行统计代码就能实现但它会让工具的使用体验完全不一样。5.3 长期维护的真实成本说句实话这类学习小网页的长期维护真正的难点不在技术上而在“你还在不在用”。如果三个月后你不再打开这个页面那它只是一个存档文件没有任何意义。但如果你还在每天用它那么每次改一个小功能你都需要重新打开代码、让AI修改、本地测试、部署上线。这个过程重复几次之后你会发现它本身也是一种学习你在不知不觉中理解了更多代码结构、数据流和部署细节。所以我的建议是第一次做的时候不要用复杂框架不要做大而全的设计按“一周内能上线”的标准来。保持工具够小、更新够快、使用成本够低它才有可能陪你走得久。回到标题我说这是“纯炫耀不卖课”。这份炫耀不是因为我写出了多漂亮的代码而是因为我找到了一种方式让学习中的那些小需求不再只能靠“将就”来解决。在AI出现之前我大概永远不会花一个下午去做一个背单词页面因为投入产出比太低现在从心里冒出一个想法到它变成一个能打开的网页中间只隔着一段很短的对话。如果你也有一个学习上的小需求一直找不到合适的工具那我建议你别等现成应用了。打开一个AI助手把你想要的使用场景写清楚做一个哪怕只有一个按钮的网页。先跑通再用再迭代。你会发现这比下载十个学习App更有可能让你真正坚持下去。 用AI做学习小网页：从想法到每天都在用的工具
标题我写的是“纯炫耀不卖课”。看到这句话你应该能猜到这不是一篇付费课程的营销文也不是所谓“三天让你变成AI开发专家”的速成指南而是最近我确实花了几个周末用AI做了一些帮助学习的小网页比如一个完全按自己习惯设计的单词复习页、一个随机抽题的错题练习页、还有一个代码片段速查页。它们都不复杂有些甚至只有一个单页文件但关键是——它们真的被我天天打开而不是做完就丢进收藏夹吃灰。这个体验让我重新理解了“AI辅助开发”这件事。以前我总觉得做网页是程序员的事要懂HTML、CSS、JavaScript还要处理部署、调试、兼容性一堆问题。但现在你只需要把需求描述清楚AI就能生成一个可以运行的骨架你再根据自己的需求去调整细节整个过程从“感觉很难”变成了“我可以试一试”。我甚至觉得这是AI目前最接地气的用法之一不追求做出多庞大的产品只为了把一个学习场景里的小痛点变成一个属于自己的、能坚持用下去的小工具。所以这篇文章的核心判断很简单用AI做学习小网页真正的价值不是省下多少开发时间而是它把“我有一个学习需求”和“我有一个能用的工具”之间的距离缩短到了几乎可以忽略的程度。至于怎么把这个距离走好接下来我会从选型、实现、部署、踩坑到长期使用一步一步拆开讲。1. 为什么“学习小网页”最值得用AI试一次1.1 学习场景天然适合小而具体的工具学习场景里有一个特别适合个人开发的特点需求通常非常具体范围非常小。比如“我想每次打开看到一个单词下面有四个选项我选择之后它告诉我对不对然后把结果记下来”。这个需求听起来很朴素但它逻辑清晰、边界明确没有复杂的权限体系没有多人协作没有高并发也不需要真正的后端服务。这类小工具的另一个好处是结果能即时验证。单词页显示是否正确、按钮能不能记录点击、刷新后数据还在不在、换一个浏览器打开是否正常每一步都是能立刻看到反馈的。这种即时验证对新手很友好你不用等“项目跑起来”再去调试因为你做的本来就是一个打开就能跑的页面。相比之下如果你一上来就想做一个“全功能学习平台”有用户注册、有后台管理、有数据统计图表那这件事的复杂度会指数级上升。AI虽然能帮你生成不少代码但架构设计和系统边界仍然需要人来把控。所以我的第一个建议是如果你的目标是解决自己的学习问题而不是训练自己做大型项目那就老老实实从小页面开始。1.2 AI让“从想到做”的路径变短了我身边有不少人脑子里其实有很多学习小点子比如“要是有一个工具能让我把错题粘贴进去然后每天随机抽几道让我做就好了”。放在以前这种想法通常活不过三秒因为做网页的成本实在太高了要么自己学前端要么找一个现成工具然后去适应它的操作习惯而不是让它适应我。AI出现以后这条路发生了变化。你可以把它当成一个“会写代码的同事”你把使用场景描述清楚它把骨架给你搭起来你再在骨架上做调整。以单词复习页为例你只需要告诉它“生成一个单页HTML文件能让我粘贴词库每次显示一个单词和四个中文选项点击后判断对错并记录”它就能给你一个能打开运行的版本。当你亲手做一个网页然后在浏览器里看到它亮起来的那一刻那种成就感确实很难形容。这件事更深层的意义在于它改变了普通人和“开发”之间的关系。以前开发是一个专业分工现在开发更像是一种表达能力。你不需要成为专家也能把自己的想法变成可运行的东西。这种能力的门槛下降才是AI真正带来的变化。1.3 适用边界这个路线适合谁不适合谁任何方案都有边界。这个路线适合以下两类人有明确学习需求但现有工具用起来不顺手的。遇到问题愿意看控制台报错、愿意尝试改一点代码的人。它不适合以下场景完全不想看任何代码细节遇到问题就希望AI“凭空”修好但自己完全没有排查思路的。一开始就想做带账号、数据库、多人协同的复杂系统然后问为什么AI生成的东西不能直接上线。想把这个学习工具做成商业产品、面向大量用户的。说清楚边界很重要因为只有知道自己适合哪条路才不会在错误的方向上浪费时间。如果你只是想解决自己的学习问题那一句话就够了“够用”比“完善”重要得多。2. 一个单词复习页的诞生从需求到可用版本2.1 需求描述用场景说话而不是用功能词我第一次让AI做单词页的时候给的描述很简单“帮我做一个背单词网页。”结果它给我的是一个非常基础的静态例子就是一个页面里写死几个单词和释义没有任何交互。这个版本当然不够用。后来我换了方式把需求改成描述使用场景“每次打开页面会看到一个单词和四个中文选项我点击其中一个选项后页面告诉我这个答案是对还是错并且把结果记录下来。下次打开时优先展示我经常记错的单词。”这一版的效果完全不一样。AI理解了“用户在什么时间、打开什么、看到什么、做什么动作、得到什么反馈”这条完整链路生成的代码就明显更有针对性。这里有一个很重要的经验AI即使理解能力再强也需要你把使用流程说清楚。你不需要懂技术术语但你要能把场景描述得足够具体。一个有效的描述至少应该包含三件事用户在什么情况下打开这个页面、页面展示什么信息、用户操作后会发生什么。2.2 最小可行版本先做一个能用的再想更好的做第一版的时候我一直在克制自己“加功能”的冲动。最终第一个能用的版本只有几个元素一个输入框用来粘贴自定义词库。一个大按钮点击后随机显示下一个单词。四个选项按钮。一个计算结果区域的文字提示。一个存储逻辑把每次答题结果保存到浏览器本地。这个版本大概不到一屏代码AI生成起来很快验证起来也很快。跑通之后我才开始考虑加功能比如按错误次数提高出现频率、显示连续打卡天数、一键导出学习记录。而且我给自己定了规则每次只加一个功能用满一周觉得确实需要再动手加下一个。这样避免了一开始就把项目做复杂也保证了每个功能都是真实需求驱动而不是“为了显得完整”而堆上去的。2.3 核心逻辑数据、间隔算法和交互反馈这种学习类小工具UI其实不是核心。真正决定工具有没有用的是三件事数据怎么存、复习间隔怎么算、用户每次操作后能得到什么反馈。存储方面我选的是浏览器自带的 localStorage。你不用架数据库不需要注册云服务一个键值对就能存下学习记录。复习间隔方面我用的是一个简化版策略单词答对了它的下次复习间隔就延长一点答错了就把它安排到明天再出现。这个策略本质上是一套简化版间隔重复思路不复杂但很实用。交互反馈方面每次答题后页面会明确显示“正确”或“错误”并且展示正确答案。这个反馈很重要因为如果答案错了却不知道正确答案是什么那么这次练习的收益会大打折扣。所以在让AI生成逻辑时我会特别强调“答错时一定要显示正确答案”。注意这一类网页应用的核心是“记录”不是“展示”。如果刷新页面后数据全部丢失那它顶多算一个随机展示器不能算学习工具。所以在做第一版时优先把数据持久化想清楚。2.4 代码示例一个常见的复习记录存储写法如果你也打算做一个类似工具下面这段代码是一个很典型的“答题记录”存储写法。它把每次结果写进 localStorage并更新这个单词的复习到期时间。function saveReviewResult(wordId, isCorrect) { const key review-data; const data JSON.parse(localStorage.getItem(key) || {}); if (!data[wordId]) { data[wordId] { correctCount: 0, wrongCount: 0, lastReviewAt: null, dueAt: Date.now() }; } data[wordId].correctCount isCorrect ? 1 : 0; data[wordId].wrongCount isCorrect ? 0 : 1; data[wordId].lastReviewAt Date.now(); // 简化版间隔策略正确则下次间隔延长错误则明天再复习 const intervalDays isCorrect ? Math.min(7, data[wordId].correctCount) : 1; data[wordId].dueAt Date.now() intervalDays * 24 * 60 * 60 * 1000; localStorage.setItem(key, JSON.stringify(data)); }这段代码不是唯一写法你也可以用更复杂的算法、更精细的数据结构。但核心思路是一样的把学习历史保存下来而不是页面一刷新就回到起点。如果你希望这些数据更安全可以顺手在页面上加一个“导出记录”按钮让用户把JSON数据下载到本地。这个功能AI实现起来很容易但对长期使用来说价值很大。3. 部署、数据与日常使用让它真的被打开3.1 部署最简单的方式先把网页挂到公网本地打开一个HTML文件自用当然没问题。但如果想手机也能访问甚至想发给朋友一起用就需要部署到公网。对于这类纯静态页面最简单的方案是用静态托管服务比如 GitHub Pages、Vercel、Netlify、Cloudflare Pages 等都支持免费部署纯前端项目。我在这里不会详细写某一家的注册流程因为各平台的界面和流程经常变化。更推荐的方式是选一个你自己顺手或听说过的平台按照官方引导把项目文件夹推上去或把HTML文件拖上去一般几分钟就能得到一个公网地址。部署时最需要注意的一个细节是路径。如果你的页面里引用了外部CSS或JS文件并且你写的是绝对路径部署后很可能会出现资源加载失败。更稳妥的做法是使用相对路径或者直接把所有代码都写在一个HTML文件里。对于小项目来说单文件是最省心的形态。3.2 让工具真正进入学习流程而不是收藏夹吃灰做完了网页最难的部分往往是你如何说服自己每天都打开它。一个学习工具如果只是躺在收藏夹里那它和不存在没有区别。为了让工具真正进入学习流程我做了三件事第一把页面放到浏览器书签栏手机端则添加到主屏幕。打开成本越低坚持使用的可能性越高。第二在页面上做一个很显眼的“今日复习”按钮一进来就直接进入今日任务不需要任何多余操作。用户不应该思考“我该点哪里”而是打开就进入状态。第三加一个最简单不过的统计连续打开天数。人对“连续记录”这件事有天然的好奇心哪怕只是一个小小的数字也会让坚持变得更有动力。这些改动背后没有复杂的技术但对长期使用影响很大。很多功能丰富的学习App让人坚持不下去不是因为功能少而是因为打开成本太高。自己做工具的优势就在于能把入口做得完全贴合自己的习惯。3.3 问题排查从页面打不开到数据丢失如果自己做的网页遇到问题按照什么顺序排查最有效我会按下面这条链路来如果页面空白先按F12打开开发者工具看 Console 标签页有没有报错。这是最直接的线索。如果按钮点了没反应先确认是 JavaScript 报错还是事件压根没绑定Console 会告诉你具体是哪一行出了问题。如果刷新后数据丢失先检查你是不是用了浏览器的隐私模式或者最近清过缓存。localStorage 数据在这些情况下会被清理。如果手机打开部署后的网页失败先确认地址是否正确、当前网络是否正常再检查部署平台是否整体可用。如果页面在电脑端正常、在手机端布局乱检查网页头部有没有 viewport 设置。AI 大部分时候会加但偶尔会漏掉。这个排查思路的核心原则是先看现象再看输入再看环境再看参数最后才考虑是不是工具本身的问题。不要一看到报错就归咎于“AI写得不行”很多问题其实出在浏览器环境和部署环节。4. 不是无脑爽AI参与开发时最容易踩的四个坑4.1 坑一只复制代码不看逻辑AI生成的代码能跑起来但如果你完全不知道它为什么这么做后续改需求时会非常痛苦。比如你想把“答对后直接显示下一题”改成“答对后先展示正确答案点击确认再进入下一题”这就必须知道当前逻辑在哪里、数据在哪里更新、界面在哪里渲染。如果你完全不懂就只能让AI反复改改了之后又怕改坏其他功能。我的做法是每次拿到AI代码后先让它给核心逻辑加注释或者单独问它“这段代码在做什么”。至少要做到自己能说出“数据从哪里来、存到哪里去、界面如何更新”三件事否则后续迭代很容易失去掌控。4.2 坑二不断打补丁却不保留旧版本AI很擅长生成新代码但它在一个文件上反复修改时有时候会把之前能用的功能改坏。而且AI的上下文窗口有限你在这个对话里改了几轮之后它可能已经忘了最开始加过什么功能。我踩过这个坑后来养成了一个习惯每跑通一个版本就把这个HTML文件复制一份按日期命名存到一个 backup 目录。一旦改坏了随时能打开上一个可用版本。如果项目结构变成了多文件更推荐用 git 做版本管理不需要推送到远程本地提交记录就足够让人安心。这个习惯在长期迭代里几乎是保命级别的。4.3 坑三把 localStorage 当数据库用localStorage 用起来很方便但它的限制也很明显单个域名下大约有 5MB 的存储上限对纯文本记录通常够用但存大量内容时会紧张。它不能跨设备同步手机和电脑的数据是隔离的。浏览器清理数据时会被一起清掉。它不是真正的数据库不适合做复杂查询和多人数据合并。如果你的学习记录真的很有价值比如积累了一年多的复习历史那至少应该提供一个导出功能定期把数据下载到本地。如果希望数据能在手机和电脑之间同步那就需要引入后端服务和云数据库复杂度会立刻上升。这时候你可以考虑做一个真正的轻量后端也可以使用现成的云数据服务。不过这套复杂度只有在你确实需要的时候再引入不要一开始就背上。4.4 坑四追求完美结构忘记学习工具的第一目标是“今天会用”我看到一些朋友让AI生成“学习平台”要有登录、后台、权限、统计面板结果开发了两周还没有上线。这个方向其实已经偏离了“做学习工具”的初衷。做一个学习工具第一目标不是“架构优雅”也不是“功能齐全”而是“今天我能打开它用十分钟并且明天还想再打开”。所以我强烈建议第一版先做一个人能用的最小页面放到手机首屏然后连续用一周。如果一周后你没有遇到特别想改进的痛点说明这个工具已经够用了如果遇到了再针对痛点让AI加功能。这样你的每一个迭代动作都是由真实使用触发而不是靠想象堆需求。5. 从“做一个网页”到“沉淀一套自己的开发方法”5.1 从一次经验到一套可复用的“小工具模板”做了几个学习网页之后我发现它们之间有不少重复结构一个输入区、一组按钮、一个结果展示区、一段存储逻辑。把这些共同点整理出来下次做新工具时就可以基于模板改不用每次从头描述需求。比如一个“随机抽题页”和一个“单词复习页”在数据存储、判分逻辑、统计展示上其实非常像唯一的区别只是题目来源和展示形式不同。如果你也想走这条路我建议你别急着去找现成的框架而是用自己的项目慢慢沉淀模板。先在纸面上画出页面结构再让AI生成一个基础壳子然后把你常用的数据存储逻辑、导出功能、统计功能先加进去。这样一个模板用几次之后会越来越像你自己的“私人脚手架”。5.2 给工具加上反馈闭环统计、回顾、调整一个学习工具如果只是“做完题就结束”那它和普通的练习册没什么区别。真正能帮助学习的工具应该像一个小伙伴一样为你提供反馈闭环。最简单的做法是给页面加上三样东西统计今天完成了多少、累计完成了多少、整体正确率多少。回顾每周自动展示一次本周错题只展示不测试让大脑重新连接一次。调整根据统计结果决定下一个版本要改什么而不是凭感觉加功能。有了这个闭环工具就从“记录结果”升级成了“辅助决策”。你每天打开它看到的不仅是一个成绩而是一个关于自己学习状态的数据画像。这种反馈不一定复杂有时候几行统计代码就能实现但它会让工具的使用体验完全不一样。5.3 长期维护的真实成本说句实话这类学习小网页的长期维护真正的难点不在技术上而在“你还在不在用”。如果三个月后你不再打开这个页面那它只是一个存档文件没有任何意义。但如果你还在每天用它那么每次改一个小功能你都需要重新打开代码、让AI修改、本地测试、部署上线。这个过程重复几次之后你会发现它本身也是一种学习你在不知不觉中理解了更多代码结构、数据流和部署细节。所以我的建议是第一次做的时候不要用复杂框架不要做大而全的设计按“一周内能上线”的标准来。保持工具够小、更新够快、使用成本够低它才有可能陪你走得久。回到标题我说这是“纯炫耀不卖课”。这份炫耀不是因为我写出了多漂亮的代码而是因为我找到了一种方式让学习中的那些小需求不再只能靠“将就”来解决。在AI出现之前我大概永远不会花一个下午去做一个背单词页面因为投入产出比太低现在从心里冒出一个想法到它变成一个能打开的网页中间只隔着一段很短的对话。如果你也有一个学习上的小需求一直找不到合适的工具那我建议你别等现成应用了。打开一个AI助手把你想要的使用场景写清楚做一个哪怕只有一个按钮的网页。先跑通再用再迭代。你会发现这比下载十个学习App更有可能让你真正坚持下去。