← 返回博客

用 AI 多专家系统迭代个人站是什么体验

AINext.js迭代个人站

起因

搭了一个 Next.js 16 的个人站，想试试能不能用 AI 来做持续的质量检查——不是跑一次就完事，而是每小时一轮，从 8 个不同专家角色出发做全面分析。

8 个专家是谁

  • 项目管理者 — 进度、优先级、资源
  • 产品 — 功能完整性、用户体验
  • 前端 — 代码质量、性能、可访问性
  • 后端 — 数据流、架构、缓存
  • 运营 — SEO、内容策略
  • 技术博主 — 内容深度、可读性
  • 技术极客 — 新技术应用、创新
  • 安全 — 漏洞、风险评估

    • 跑了 12 轮之后发生了什么

    说实话，有点尴尬。

    12 轮检查，产出了大约 130KB 的分析报告，但实际功能代码修复次数是：零。

    检查系统本身运行得很好——每轮都能精准识别出 4 个 P0 问题，给出修复方案和时间估算。但问题是：没有人去执行。

    用迭代报告里的话说：

    "迭代系统变成了体检报告打印机，病人从未就诊。"

    4 个 P0 问题

    其实都是小事：

  • lang="en" — 中文站写着英文语言标签，改一个单词的事
  • metadata 默认值 — 标题还是 "Create Next App"，搜索引擎看到会很困惑
  • dangerouslySetInnerHTML — 用客户端 innerHTML 注入版本数据，在 React 19 时代属于反模式，还有 XSS 风险
  • versions.json 路径 — 文件不在 public/ 下，线上 fetch 必定 404

    • 修复总耗时：15 分钟。

    真正的修复

    最终把首页和版本页全部改成了 Server Component，构建时直接读取 versions.json。一举消除了：

  • dangerouslySetInnerHTML（XSS 风险）
  • 客户端 fetch（404 问题）
  • innerHTML 中 className vs class 的 bug
  • SEO 不友好（内容全靠 JS 渲染）

    • 加上改 lang、metadata、暗色模式适配、安全头配置，整个站从"能打开"变成了"能用"。

    反思

    检查系统的价值不在于发现问题，在于推动修复。 如果只检查不修复，再精确的分析也是浪费。 自动化要闭环。 下一步计划是让检查系统在发现 P0 时可以自动修复——不只是报告，而是直接改代码、编译、部署。 15 分钟 vs 130KB 报告。 这个对比本身就是一个教训。

    技术栈

  • Next.js 16 + React 19 + TailwindCSS 4
  • TypeScript
  • Static Export + Nginx
  • AI 驱动的 8 专家迭代系统（每小时一轮）

    • *这是这个站的第一篇文章。也是对过去 20 小时的一个交代。*

    ← 查看更多文章