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

起因

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

项目管理者 — 进度、优先级、资源

产品 — 功能完整性、用户体验

前端 — 代码质量、性能、可访问性

后端 — 数据流、架构、缓存

运营 — SEO、内容策略

技术博主 — 内容深度、可读性

技术极客 — 新技术应用、创新

安全 — 漏洞、风险评估

说实话，有点尴尬。

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

检查系统本身运行得很好——每轮都能精准识别出 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 小时的一个交代。*