AI工程实践Code Review 约 11 分钟

AI Code Review 到底靠不靠谱？我拿自己的网站试了一下

AI Code Review 到底靠不靠谱？我拿自己的网站试了一下

一个不怎么写前端的 Java 老兵，用 AI 一小时给自己的个人网站做了 Code Review + 自动化测试 + 暗黑模式。结果如何？

作为一个写了十几年 Java 的人，我对 AI 编程工具一直保持着”关注但不迷信”的态度。每天看各种 AI 编程的文章和讨论，但真正动手用 AI 辅助开发的次数屈指可数。

直到最近，我决定拿自己的个人网站做个实验：如果完全信任 AI，让它帮我审查代码、加测试、做功能优化，效果到底怎么样？

先说结论：比我预期的好很多，但也有一些值得思考的地方。

实验对象

我的个人网站（lesongmade.com）是一个用 Astro 搭建的纯静态博客，4 篇文章，21 个源文件。功能不算复杂：Markdown 文章渲染、RSS 订阅、SEO 元数据、阅读进度条、目录导航。

说实话，我对前端不算精通。写 Java 我能自信地说”闭着眼睛都能写”，但前端对我来说更像是”能用就行”的状态。这也意味着——代码里一定有我看不到的问题。

这正是我想验证的：AI 能不能帮一个”不熟悉这个领域”的开发者发现盲区。

实验一：AI Code Review — 16 个问题，3 个让我服了

我用的工具是 Claude Code，直接打开项目根目录，给它一个明确的审查指令：

“请对这个 Astro 个人网站项目做一次完整的 Code Review。重点关注：代码质量、性能隐患、SEO 改进、安全问题、可以加测试的地方。按严重程度排序。”

大概等了 15 分钟，它给出了一份结构化的审查报告。说实话，看完第一反应是——有点东西。

让我服了的三个发现

1. GitHub 链接指向首页

我的首页和关于页面都有一个 GitHub 图标链接，我写了 href="https://github.com"。

对，就是 GitHub 首页。不是我的主页，不是任何有意义的页面。这个链接在我的网站上挂了不知道多久，我自己从来没点过，也从来没发现。

AI 发现了。

2. 导航栏高亮逻辑有 Bug

我的导航栏用 currentPath.startsWith(item.href) 来判断当前页面是否激活。AI 指出：如果未来新增一个 /about-me 页面，用户在 /about-me 时，/about 也会被错误高亮。

这是一个典型的**“现在没触发但早晚要踩”的坑**。我写的时候觉得 startsWith 够用了，没有考虑路径前缀匹配的问题。

AI 给出的修复方案也很简洁：

// 修复前
const isActive = currentPath.startsWith(item.href);

// 修复后
const isActive =
  currentPath === item.href ||
  (item.href !== '/' && currentPath.startsWith(item.href + '/'));

3. 社交分享 OG 图片指向不存在的文件

我的 SEO 组件里，默认 OG 图片写的是 /images/og-default.png，但这个文件根本不存在。意味着所有没有显式传图片的页面，在微信、Twitter 分享时都会显示裂图。

我自己从来没分享过自己的网站到社交平台，所以从来没发现这个问题。

其他的发现

除了上面三个，AI 还指出了：

  • 邮箱地址明文暴露在 HTML 中（爬虫可以抓取）
  • Hero 组件用了 set:html 但没做 XSS 防护文档说明
  • Tailwind 配置里扫描了 vue、svelte 等项目中根本不用的文件类型
  • 缺少 robots.txt 文件
  • 多个页面有大量重复的 inline SVG 代码

总共 11 个代码质量问题 + 5 个 SEO/安全问题，按严重程度分级排列，每个都有具体的修复建议。

我的判断

这份报告的质量超出了我的预期。它不是泛泛地说”代码质量一般”，而是精确定位到文件和行号，给出可执行的修复方案。更重要的是，它发现了一些功能层面的 Bug（GitHub 链接、OG 图片），而不仅仅是代码风格问题。

当然也有小瑕疵：性能部分，AI 自己承认”当前影响可忽略，不建议改”——说明它在权衡，不是无脑挑刺。

实验二：AI 加测试 — 52 个用例，一次全过

我的网站没有任何测试。零。一个都没有。

这也是我一直想加但没加的东西——“个人网站加什么测试”这个想法给了我足够的理由偷懒。但既然 AI 能写代码，那就让它来。

我给 Claude Code 的指令是：

“为这个项目搭建测试框架，用 Vitest。为以下文件生成单元测试：rss.xml.ts 的 RSS 生成逻辑、SEO 组件的渲染输出、博客文章的 frontmatter 校验。“

结果

测试文件用例数覆盖范围
tests/content.test.ts18Zod schema 校验、4 篇真实文章解析、draft/slug/非空校验
tests/rss.test.ts8草稿过滤、日期排序、必需字段、zh-CN 语言标签、空列表边界
tests/seo.test.ts26meta 标签、OG 标签、Twitter Card、RSS 发现链接、JSON-LD

52 个测试用例，npm test 一次全过。

关键感受

作为一个不熟悉前端测试的人，让我自己搭建 Vitest + 写测试，我估计至少需要：

  1. 花 2 小时看 Vitest 文档
  2. 花 1 小时研究怎么测试 Astro 组件
  3. 写测试、调 bug、再花 2-3 小时

AI 用了大约 30 分钟，从零到 52 个用例全部通过。

更关键的是：我一行代码都没改。 AI 生成的代码直接就能跑。这对一个前端新手来说，效率提升不是 2 倍 3 倍，而是从”做不了”到”做完了”。

实验三：AI 加暗黑模式 — 15 个文件联动修改

最后一个实验，我让 AI 给网站加暗黑模式切换功能。

选择这个功能有两个原因：一是技术博客没有暗黑模式确实不太方便；二是暗黑模式涉及 15 个文件的联动修改（所有组件都要加 dark: 变体），这种机械性工作正好是 AI 的强项。

实现：三个大模型流水线作业

暗黑模式的实现过程比前两个实验更有意思，因为我实际上用了三个不同的 AI 模型，形成了一个流水线：

第一步：Claude Code + DeepSeek V4 负责实现。

给完指令后，DeepSeek V4 通过 Claude Code 完成了所有改动：

改动说明
新增 DarkModeToggle.astro太阳/月亮切换按钮
tailwind.config.ts启用 darkMode: 'class'
Base.astro添加 anti-FOUC 脚本（防止页面闪烁）
Nav.astro集成切换按钮 + 暗黑配色
11 个组件/页面全部添加 dark: 变体适配

一次编译通过，功能完全正常。

但我不敢直接用。

第二步：Qoder + Kimi 2.6 负责审查。

出于对 AI 生成代码的本能不信任——毕竟我是一个不怎么写前端的人，万一它写的代码有坑我也看不出来——我又把生成的代码丢给了 Qoder，让 Kimi 2.6 模型做了一次 Code Review。

结果发现了大约 20 处问题，其中几个让我印象深刻：

Critical 级别（必须修）：

  • localStorage 操作没有 try-catch 防护——在 Safari 隐私模式下，localStorage 被禁用，直接抛异常会导致页面白屏。这个点我完全没想到，DeepSeek V4 也没想到。
  • twitter:card 的 content 被硬编码为 summary_large_image，但 SEO 组件之前已经改成了条件渲染（有图片时才输出 summary_large_image），暗黑模式的改动把这层逻辑覆盖掉了。
  • theme-color meta 标签只响应系统偏好，不响应手动切换——用户在浅色系统下切到暗黑模式，手机浏览器地址栏还是绿色。

Warning 级别（建议修）：

  • 全局 transition 动画与 FOUC 防护脚本目标矛盾——过渡动画在页面加载时会触发颜色渐变，反而加剧了闪烁
  • theme 这个 localStorage key 太通用，可能被第三方脚本覆盖，建议改为带前缀的 site-theme

说实话，这些问题如果让我自己看代码，我一个也发现不了——因为我不熟悉前端的安全模式、可访问性规范和浏览器兼容性问题。但 Kimi 2.6 精准地指出了这些隐患，而且分析得非常到位。

第三步：Qwen 3.7 Max 负责修复。

最后我把 Kimi 的审查结果交给 Qwen 3.7 Max，让它按审查意见逐一修复。修复完成后，Build 0 错误，52 个测试依然全过。

这个流水线给了我什么启发

三个模型各有擅长：

模型角色擅长
DeepSeek V4实现者快速生成代码，一次编译通过
Kimi 2.6审查者发现设计问题和扩展性隐患
Qwen 3.7 Max修复者精准修复已知问题

一个模型写代码，另一个模型审代码，第三个模型改代码。 这不就是软件开发里”开发-Code Review-修复”的标准流程吗？只不过这次，三个角色都是 AI。

关键感受

如果让我自己来写暗黑模式：

  1. 我得先搞懂 Tailwind 的 darkMode: 'class' 策略
  2. 逐个文件加 dark: 前缀类名（15 个文件！）
  3. 处理 FOUC 闪烁问题（AI 自动加了解决方案，我自己可能都不知道这是个问题）
  4. 调配色，确保可读性

保守估计，我自己做至少要半天。三个 AI 模型接力完成大约 30 分钟，而且经过交叉审查的代码质量比单个模型生成的更高。

总结：AI Code Review 到底靠不靠谱？

三次实验做下来，我的结论是：作为辅助工具，非常靠谱；作为替代品，还差得远。

AI 做得好的地方

能力评价
发现盲区⭐⭐⭐⭐⭐ 找到了我自己从没注意到的 GitHub 链接 Bug
结构化输出⭐⭐⭐⭐⭐ 按严重程度分级，每个问题有具体修复方案
跨领域能力⭐⭐⭐⭐⭐ 不熟悉前端也能写出 52 个测试 + 暗黑模式
效率⭐⭐⭐⭐⭐ 1 小时完成原本可能需要 1-2 天的工作量

AI 的局限

局限说明
不了解业务上下文它不知道我的 GitHub 主页是什么，只能指出”指向首页”这个事实
无法做价值判断”邮箱明文暴露”是问题还是故意展示？AI 不知道
建议质量参差大部分建议靠谱，但也有”加了更好、不加也行”的填充项
单个模型不可靠暗黑模式实验证明：让另一个 AI 审查后才发现 20 处问题，交叉验证很有必要

一个意外收获：多模型流水线

暗黑模式实验最大的收获不是功能本身，而是验证了一个工作模式：让不同的 AI 模型各司其职。

一个模型写代码，另一个模型审代码，第三个模型改代码。这本质上就是软件开发里”开发-Review-修复”的标准流程，只不过执行者全换成了 AI。

不同模型确实有不同的”性格”：有的擅长快速生成，有的擅长挑刺，有的擅长精准修复。信任但不盲信任何一个模型，这才是 AI 辅助开发的正确姿势。

一句话总结

AI 最大的价值不是替你写代码，而是让你看到自己的盲区。而多个 AI 的组合使用，能让盲区进一步缩小。 Code Review 是这样，加测试是这样，做功能优化也是这样——它扩展了一个开发者的能力边界，但最终决定”什么该做、什么不该做”的，还是你自己。

我的后续计划

这次实验让我对 AI 辅助开发有了全新的认识。接下来我打算：

  1. 把 AI Code Review 集成到 CI 流程中 — 每次 PR 自动跑一遍，作为人工 Review 的补充
  2. 开始学习 Spring AI — 作为 Java 开发者，我想看看 AI 能力如何嵌入到日常的业务系统中
  3. 持续记录 — 这个系列的后续文章会记录我在 Java 项目中用 AI 的实战经验

如果你也是一个对 AI 编程持观望态度的资深开发者，我的建议是：找一个你熟悉但不精通的项目，让 AI 做一次完整的 Code Review。 结果可能会让你意外。

本文提到的所有改动已部署到 lesongmade.com，你可以点击右上角的月亮/太阳图标切换暗黑模式体验。

📑 本文目录