起因

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

8 个专家是谁

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

跑了 12 轮之后发生了什么

说实话，有点尴尬。

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

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

用迭代报告里的话说：

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

4 个 P0 问题

其实都是小事：

1. lang="en" — 中文站写着英文语言标签，改一个单词的事
2. metadata 默认值 — 标题还是 “Create Next App”，搜索引擎看到会很困惑
3. dangerouslySetInnerHTML — 用客户端 innerHTML 注入版本数据，在 React 19 时代属于反模式，还有 XSS 风险
4. 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 小时的一个交代。