1. 为什么我选择用AI生成一个纯前端导航页第一次冒出自己搭一个聚合入口这个念头是因为我受够了浏览器里那排越堆越长的书签栏。收藏夹里躺着几百个链接真正每天用的就那么十来个剩下的要么失效要么早就忘了当初为什么收藏。更麻烦的是换一台设备、换一个浏览器书签同步就成了玄学有时候同步过来一堆重复项有时候干脆丢一半。后来我试过各种在线导航站用着用着发现问题更多要么强制注册登录要么首页塞满广告和推广位要么加载一堆用不上的脚本拖慢速度。我真正想要的其实很简单——一个打开就能用、不需要账号、不依赖后端、所有数据都在自己手里的导航页。这就是免登录聚合入口这个需求的核心零门槛访问、纯前端运行、数据本地可控。那为什么标题里还带了个AI快速生成因为从零手写一个导航页哪怕功能再简单也绕不开 HTML 结构、CSS 布局、响应式适配、数据存储这几块。对前端熟手来说可能半小时的事但对大多数人来说光是调一个卡片网格的对齐就能耗掉一晚上。而现在的 AI 编程工具恰好擅长处理这种结构清晰、需求明确、有大量现成范式的任务。你把需求描述清楚它能把骨架、样式、交互一次性给你搭出来你只需要做微调和内容填充。这篇文章要讲的就是这套完整流程怎么把我要一个免登录的纯前端导航页这个模糊想法拆成 AI 能听懂的精确需求怎么让它生成真正能跑、不依赖任何后端服务的代码生成之后哪些地方必须自己动手改以及部署上线时那些文档里不会写的坑。适合两类人看一类是想要个干净导航页但不想学前端框架的普通用户另一类是刚接触 AI 编程、想找个真实小项目练手的开发者。全程不需要服务器不需要数据库一个 HTML 文件加一个 JSON 就能跑起来。2. 把模糊需求翻译成AI能执行的精确指令2.1 先想清楚纯前端到底意味着什么很多人对纯前端的理解停留在不用后端语言但真正的纯前端导航页约束比这严格得多。它意味着所有数据要么硬编码在文件里要么存在浏览器的 localStorage 或 IndexedDB 中所有逻辑都在浏览器里跑没有接口请求没有服务端渲染部署的时候只需要把静态文件丢到任意静态托管上甚至直接用file://协议打开本地文件也能用。这个约束直接决定了几个设计选择。第一导航数据不能放在数据库里最合理的方案是一个独立的 JSON 文件页面加载时用fetch读进来或者干脆内联在 JS 里。第二用户的个性化配置比如自定义了哪些链接、调整了排序只能存在本地换设备就没了——这是纯前端的天然代价得提前接受。第三搜索、筛选、分类这些功能全部在前端完成数据量大了会有性能问题所以导航项控制在几百条以内比较合适。我在给 AI 写提示词的时候会把这些约束明确写进去比如这是一个纯静态页面不允许出现任何 fetch 外部 API 的代码数据从同目录下的 links.json 读取用户配置存 localStorage。 你越是把边界说清楚AI 越不容易给你生成一堆用不上的后端代码或者引入奇怪的依赖。2.2 提示词里必须交代的六个要素我踩过的坑是一开始只跟 AI 说帮我做个导航页结果它给我生成了一个带登录框、带后台管理、还引用了三个 CDN 库的庞然大物。后来我总结出一套提示词模板每次至少交代清楚这六件事技术栈明确说单个 HTML 文件内联 CSS 和 JS不引入任何框架和外部库。如果你能接受 Tailwind 这类工具也可以指定但纯手写 CSS 对导航页来说完全够用还能避免 CDN 挂掉导致页面崩掉。数据来源说清楚导航数据从哪来。我一般让它生成一个links.json结构是分类数组每个分类下有若干{name, url, desc, icon}对象。核心功能清单搜索框按名称和描述模糊匹配、分类切换、卡片网格布局、点击新标签页打开。就这四样别贪多。视觉风格给个具体参照比如类似 macOS 的毛玻璃卡片风格深色模式优先圆角 12px卡片悬停有轻微上浮。响应式要求明确手机端单列平板两列桌面三到四列自适应。禁止项明确说不要登录、不要后端、不要统计脚本、不要任何形式的用户追踪。把这六点写进提示词生成质量会有质的提升。下面是我实际用的一段提示词可以直接参考请生成一个纯前端导航页要求 1. 单个 index.html 文件内联 CSS 和 JS不引入任何外部库 2. 导航数据从同目录 links.json 读取格式为分类数组 3. 功能顶部搜索框实时过滤、分类标签切换、卡片网格、点击新标签打开 4. 风格深色背景毛玻璃卡片圆角悬停上浮 5. 响应式手机1列平板2列桌面3-4列 6. 禁止登录、后端请求、统计脚本、追踪代码2.3 为什么我坚持让数据独立成JSON有人会问既然纯前端为什么不直接把数据写死在 HTML 里答案是可维护性。导航页这种东西链接是会变的今天加一个明天删一个很正常。如果数据内联在 HTML 里每次改都要在几百行代码里找位置容易改错。独立成links.json之后你打开这个文件看到的就是干干净净的结构化数据增删改一目了然。而且 JSON 有个额外好处你可以用 AI 帮你批量整理。比如你从浏览器导出了一堆书签格式乱七八糟直接丢给 AI 说把这些书签整理成分类清晰的 JSON每个链接补一句简短描述它几分钟就能给你整理好。这比手动一条条录入快太多了。我现在的做法是维护一个links.json作为唯一数据源页面只负责渲染数据和展示彻底分离。3. 生成之后必须自己动手改的几处地方3.1 AI生成的搜索逻辑往往不够聪明AI 默认生成的搜索通常是简单的name.includes(keyword)也就是只匹配名称。但实际用起来你搜文档的时候希望所有描述里带文档的链接都能出来你搜git的时候希望大小写不敏感。这些细节 AI 不一定会主动做。我一般会把搜索逻辑改成对name、desc、url三个字段同时做小写匹配并且支持空格分词——比如输入在线 图片能匹配到名称或描述里同时包含这两个词的项。改起来不难核心就是把关键词按空格拆开然后对每个词做some判断。另外记得给搜索加个防抖输入的时候不要每敲一个字符就重渲染整个列表200ms 延迟体验会顺滑很多。还有一个容易被忽略的点搜索框的焦点管理。页面加载后自动聚焦到搜索框用户打开就能直接打字这个体验提升非常明显。AI 生成的代码里经常没有这一行自己补上input.focus()就行。3.2 图标方案别依赖外部图标库AI 很喜欢用 Font Awesome 或者各种图标 CDN理由是方便。但导航页这种追求极致加载速度的场景为了几个图标去加载一整个图标库实在不划算。而且一旦 CDN 抽风你的页面就会出现一堆空白方块。我的方案是用文字首字母 背景色代替图标。每个链接取名称的第一个字符根据名称哈希出一个固定的背景色渲染成一个圆形色块。这样零依赖、零请求视觉上也挺清爽。如果确实想要真图标可以用 favicon 的方式https://域名/favicon.ico但要注意有些站点没有 favicon 会显示裂图得加onerror兜底。下面是我常用的首字母色块逻辑简单几行function getColor(str) { let hash 0; for (let i 0; i str.length; i) { hash str.charCodeAt(i) ((hash 5) - hash); } const hue Math.abs(hash) % 360; return hsl(${hue}, 60%, 45%); }这段代码的好处是同一个名称永远得到同一个颜色不会每次刷新都变视觉上稳定。3.3 响应式断点要按内容调不是照抄AI 生成的响应式代码断点通常是 768px 和 1024px 这种教科书数值。但导航页的卡片宽度是固定的真正决定几列的是容器宽度除以卡片最小宽度。所以更合理的做法是用grid-template-columns: repeat(auto-fill, minmax(220px, 1fr))让浏览器自己算能放几列。这样无论屏幕多宽卡片都不会被压得太窄或者拉得太宽。我实测下来卡片最小宽度设在 200 到 240px 之间比较舒服小于 200 文字会挤大于 260 一屏放不下几个。用auto-fill配合minmax一行 CSS 就搞定了所有断点比写一堆媒体查询干净得多。这个技巧 AI 有时候会用有时候不会你可以在提示词里直接指定。4. 部署上线时那些文档不会告诉你的细节4.1 本地直接打开和部署后行为不一样这是最经典的坑。你在本地双击index.html用file://协议打开一切正常部署到静态托管后页面空白。原因通常是fetch(links.json)在file://协议下会被浏览器的同源策略拦截而部署后又能用了——反过来有些写法在本地能用部署后因为路径问题又挂了。我的建议是开发阶段就用一个本地静态服务器比如python -m http.server 8000这样和线上环境一致能提前发现路径问题。另外links.json的引用路径要用相对路径./links.json不要用/links.json因为后者在子目录部署时会 404。还有一个隐蔽的坑JSON 文件里如果有多余的逗号或者中文引号fetch解析会直接抛错页面一片空白且控制台报错不明显。我养成的习惯是每次改完 JSON先用在线 JSON 校验工具过一遍或者直接在浏览器控制台JSON.parse试一下。4.2 缓存问题会让你的更新看不见静态托管通常会给文件加缓存。你辛辛苦苦更新了links.json刷新页面发现还是旧的别慌多半是缓存。解决办法有两个一是给 JSON 请求加时间戳参数比如fetch(./links.json?v Date.now())强制每次拉最新的二是在托管平台配置缓存策略把 HTML 和 JSON 设成不缓存或短缓存。我一般用第一种简单粗暴有效。代价是每次加载都要重新拉 JSON但对于几 KB 的文件来说这点开销可以忽略。如果你追求极致可以用版本号代替时间戳改数据的时候手动升个版本。4.3 数据备份这件事纯前端用户尤其要上心纯前端最大的风险就是数据只存在一个地方。localStorage 清一下、浏览器重装一下你精心整理的导航就没了。所以我的做法是links.json 永远保留一份在本地磁盘或者自己的笔记软件里页面上的增删改如果支持导出功能就定期导出一次覆盖备份。如果让 AI 生成一个导出为 JSON的按钮实现起来很简单把当前数据JSON.stringify之后用 Blob 下载。这个功能强烈建议加上它相当于给你的数据上了个保险。导入功能同理用FileReader读本地文件即可。有了导入导出你的导航页就变成了一个可以随身携带的数据文件换任何设备都能一键恢复。5. 让导航页真正好用的几个进阶思路5.1 用键盘快捷键把效率拉满导航页的核心用户是每天要打开很多链接的人鼠标点击其实挺慢的。我给它加了两个快捷键按/直接聚焦搜索框按Esc清空搜索。就这两个日常使用效率提升一大截。实现也简单监听keydown事件判断e.key就行。再进阶一点可以给每个分类绑定数字键按1切到第一个分类按2切到第二个。分类多的时候特别顺手。这些交互 AI 不一定主动生成但你在提示词里加一句支持 / 聚焦搜索、Esc 清空、数字键切换分类它就能给你写出来。5.2 深色模式和浅色模式的取舍我一开始做的是纯深色后来发现白天在强光下看深色背景反而费眼。于是加了个主题切换默认跟随系统prefers-color-scheme用户手动切换后存 localStorage。实现上用 CSS 变量最干净定义--bg、--card、--text几个变量切换主题就是换一组变量值。这里有个细节切换主题时如果直接改body的 class会有闪烁。更好的做法是在head里放一段内联脚本在页面渲染前就把主题 class 打到html上避免白屏闪一下。这段脚本很短但体验差别很大。5.3 数据量大了之后怎么保持流畅导航项超过两三百条之后每次搜索都全量重渲染 DOM 会开始卡。这时候有两个优化方向一是搜索时只更新变化的卡片而不是清空重建二是用DocumentFragment批量插入。对于导航页这种规模其实还有个更简单的办法——给渲染加个节流搜索输入 200ms 内不重复渲染。我实测过五百条数据用全量重渲染在普通笔记本上大概有 100ms 左右的卡顿感加了防抖之后基本感知不到。所以除非你要做上千条的导航否则不用上虚拟列表这种重武器防抖加合理的数据结构就够了。6. 我在这套流程里踩过的真实坑说几个具体的。第一个是中文编码问题。有次 AI 生成的 HTML 没写meta charsetUTF-8本地看着正常部署后所有中文变乱码。这个坑很隐蔽因为本地编辑器默认 UTF-8 会掩盖问题。现在我的模板里这行是必带的。第二个是JSON 里的特殊字符。有个链接的描述里带了英文双引号直接写进 JSON 就解析失败了。正确做法是转义成\或者干脆在描述里避免用双引号。AI 整理数据的时候不一定会帮你转义导入前自己检查一遍。第三个是移动端的点击延迟。早期版本在手机上点卡片总感觉慢半拍。后来加了meta nameviewport contentwidthdevice-width, initial-scale1并且给可点击元素设了touch-action: manipulation延迟就消失了。这个细节对移动端体验影响很大但很容易被忽略。第四个是搜索框在 iOS 上的自动大写和自动纠正。手机上搜网址的时候输入法老是把首字母大写导致匹配不到。给搜索框加上autocapitalizeoff autocorrectoff spellcheckfalse三个属性就解决了。这种移动端专属的坑不实际在手机上用一遍根本发现不了。7. 关于AI生成这件事我的一点真实看法用 AI 生成导航页这类项目最大的价值不是省了多少行代码而是它帮你跳过了从零搭骨架的心理门槛。很多人不是不会写而是面对一个空白文件不知道从哪下手。AI 给你一个能跑的初版你在这个基础上改心态完全不一样——从创造变成了修改后者对大多数人来说轻松得多。但也别指望 AI 一次生成就能直接用。我自己的经验是AI 生成的代码大概能覆盖 70% 的需求剩下 30% 是搜索逻辑的细节、响应式的微调、移动端的适配、还有各种边界情况的处理。这 30% 恰恰是最能体现你个人需求的部分也是这个导航页真正属于你的原因。把它当成一个起点而不是终点你会用得很舒服。最后分享一个我一直在用的小习惯每次给导航页加了新功能或者改了样式我都会在links.json旁边放一个CHANGELOG.md用一两句话记下这次改了什么。时间久了回头看能清楚看到这个小工具是怎么一点点长成现在这样的。这种自己养一个工具的感觉比用任何现成的导航站都踏实。