夜雨聆风缘起：为什么要再做一遍轮子？
2026 年了，市面上的 AI 导航站少说也有几十个。但我认真试用了一圈，发现几个共同的痛点：
太重了。 很多导航站用了 React/Vue + SSR 框架，首屏加载动辄 3-5MB JS，FCP（首次内容绘制）要两三秒。我就想找个工具，结果先等它加载完半本「前端工程化百科全书」。
太吵了。 广告位、弹窗、推广软文……真正有价值的信息反而是陪衬。
搜索太弱。 大部分搜索只能匹配标题，搜个「视频生成」出来的结果相关性还不如随手 Google。
没有国际化。 作为一个收录全球 AI 工具的站点，竟然只有中文 UI。国外的朋友打开一看，直接劝退。
所以我想：不如自己做一个。要轻、要快、要干净、要为 SEO 而生。
第一行代码：先定几条铁律
开工之前，我给自己定了五条原则，贯穿整个开发过程：
零框架。 不用 React、Vue，纯原生 JavaScript。反正数据量不大，不需要虚拟 DOM 那一套。好处是 Bundle size 约等于零，首屏秒开。
服务端渲染要真。 不只是首页 SSR，每个工具详情页都要预生成静态 HTML，让搜索引擎能爬到完整的结构化数据。
移动端优先。 响应式布局、触控优化从一开始就考虑，不做事后补救。
所有数据自己掌控。 用 SQLite，不依赖云数据库。一个
.db文件就能备份整个网站。能省则省，该花就花。 favicon 直接用国内代理源，不做海外请求；但 Schema.org 结构化数据一个不落地全加上。
技术选型：极简主义的胜利
后端：Node.js + Express（约 1900 行 server.js）数据库：SQLite（via sql.js，纯 JS 实现，无需编译）前端：原生 JS + 内联 Critical CSS（零框架依赖）模板：服务端字符串替换（轻量 SSR）没有 Webpack/Vite，没有 React Router，没有状态管理库。
整个项目依赖只有 5 个 npm 包：express、compression、multer、sql.js、node-html-parser。
每次 npm install 都在 3 秒内完成。部署就是 node server.js。
功能全景：麻雀虽小，五脏俱全
前台
| 分类导航 | |
| 多维搜索 | |
| Hero 粒子动画 | |
| 工具详情页 | |
| 7 语言国际化 | |
| 用户提交 |
后台
| 链接 CRUD | |
| AI 帮写详情 | |
| 静态页生成 | public/tools/{slug}.html |
| 图标缓存系统 | |
| 站点设置有讲究 | |
| Sitemap 管理 |
SEO 细节
✅ 每个详情页 → Schema.org SoftwareApplication 结构化数据✅ 首页 → ItemList + SearchAction✅ 面包屑 → BreadcrumbList✅ Open Graph + Twitter Card 标签✅ Canonical URL 防重复索引✅ HTML Sitemap + XML Sitemap 双格式✅ 百度统计 + 服务端注入（不依赖 JS 执行）✅ 所有静态页内联 Critical CSS，FCP < 1s
几个有意思的工程决策
1. 为什么不用 React？
不是不会，是不需要。
这个网站的核心交互就是「筛选分类 → 点击卡片 → 打开外链」。没有复杂表单、没有实时协作、没有嵌套状态管理。一个 fetch + innerHTML 就搞定了，上 React 反而是「用牛刀杀鸡」。
而且不用框架意味着：
首屏 JS 体积 ≈ 0（只有 15KB 的业务逻辑） 不需要 Hydration，不存在「SSR 内容和客户端内容不匹配」的告警 部署就是 node server.js，不需要npm run build
2. 为什么要做骨架屏？
网速慢的时候，用户看到的是这样的：
空白白 → 突然跳出一堆卡片 → 布局抖一下 → 正常
这就是 FOUC（Flash of Unstyled Content）+ CLS（Cumulative Layout Shift）。
我的解法：在 HTML 里预置骨架屏占位符，CSS 动画做出微光扫描效果，等 JS 数据加载完成后无感替换。 用户看到的永远是稳定的布局，只是内容从「骨架」变成了「真实卡片」。
3. favicon 代理这个坑
国内访问 google.com/s2/favicons 基本等于自残。我一开始没注意到这个问题，结果慢网速下图标区域全是空白破图。
解决方案：写了 /api/favicon 代理接口，优先使用 favicon.im、iowen.cn 等国内可用源，按优先级竞速请求、带 24 小时内存缓存、失败降级为文字首字母。性能从「看运气」变成了「几乎不感知」。
4. 静态详情页的双保险
每个 AI 工具都有一个独立详情页，这些页面同时走了两条路径：
- 动态路由
GET /tool/:slug— 服务端实时渲染，支持?lang=切换语言 - 静态文件
public/tools/{slug}.html— 提前预生成，nginx/CDN 零开销直接返回
好处是：即使 Node 服务挂了，CDN 上的静态页还能正常访问。而且静态 HTML 搜索引擎抓取成功率远高于动态页面。
数据驱动：18 个分类是怎么定出来的
我没拍脑袋定分类。做之前先把市面上主流 AI 导航站的分类抄下来做了一个并集，然后根据实际收录情况做合并和拆分：
去掉「AI 应用」这种太笼统的分类拆出「AI 提示词」作为独立分类（太重要了）新增「龙虾与Agent」—— Agent 和安全是 2026 新趋势保留「AI 办公」「AI 翻译」等垂直场景分类最终 18 个分类、295 个工具，都是手工筛选、逐个验证过可用性的。
开源与部署
源码：完全开源，MIT 协议 部署：一台轻量云服务器，Node.js 直接跑 域名：AI.txdd.cn 数据库：单个 SQLite 文件，scp 就能备份
下一步计划
- 用户系统
— 收藏夹、个性化首页 - 工具评分和评论
— 社区共建内容 - AI 工具对比功能
— 同类工具并排对比 - API 开放
— 让其他开发者能调用数据 - 更多语言
— 阿拉伯语、俄语等
写在最后
这个项目不是什么「改变世界」的产品，它就是一个干净、快速、好用的 AI 工具导航站。
但我觉得这个世界需要更多这样的东西：小而美，不臃肿，不打扰。
如果你也在做类似的项目，或者有什么建议，欢迎来后台提交工具链接，或者直接提 issue。
AI 的世界日新月异，我们一起把它变得更有序一点。
AI龙虾导航 — ai.txdd.cn 295 个 AI 工具 · 18 个分类 · 7 种语言 · 零框架 · 秒开
