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 charset="UTF-8">，本地看着正常，部署后所有中文变乱码。这个坑很隐蔽，因为本地编辑器默认 UTF-8 会掩盖问题。现在我的模板里这行是必带的。
第二个是JSON 里的特殊字符。有个链接的描述里带了英文双引号，直接写进 JSON 就解析失败了。正确做法是转义成\"，或者干脆在描述里避免用双引号。AI 整理数据的时候不一定会帮你转义，导入前自己检查一遍。
第三个是移动端的点击延迟。早期版本在手机上点卡片，总感觉慢半拍。后来加了<meta name="viewport" content="width=device-width, initial-scale=1">并且给可点击元素设了touch-action: manipulation，延迟就消失了。这个细节对移动端体验影响很大，但很容易被忽略。
第四个是搜索框在 iOS 上的自动大写和自动纠正。手机上搜网址的时候，输入法老是把首字母大写，导致匹配不到。给搜索框加上autocapitalize="off" autocorrect="off" spellcheck="false"三个属性就解决了。这种移动端专属的坑，不实际在手机上用一遍根本发现不了。
7. 关于"AI生成"这件事我的一点真实看法
用 AI 生成导航页这类项目，最大的价值不是"省了多少行代码"，而是它帮你跳过了从零搭骨架的心理门槛。很多人不是不会写，而是面对一个空白文件不知道从哪下手。AI 给你一个能跑的初版，你在这个基础上改，心态完全不一样——从"创造"变成了"修改"，后者对大多数人来说轻松得多。
但也别指望 AI 一次生成就能直接用。我自己的经验是，AI 生成的代码大概能覆盖 70% 的需求，剩下 30% 是搜索逻辑的细节、响应式的微调、移动端的适配、还有各种边界情况的处理。这 30% 恰恰是最能体现你个人需求的部分，也是这个导航页真正属于你的原因。把它当成一个起点而不是终点，你会用得很舒服。
最后分享一个我一直在用的小习惯：每次给导航页加了新功能或者改了样式，我都会在links.json旁边放一个CHANGELOG.md，用一两句话记下这次改了什么。时间久了回头看，能清楚看到这个小工具是怎么一点点长成现在这样的。这种"自己养一个工具"的感觉，比用任何现成的导航站都踏实。
