背景：一个后端想搭博客

还记得刚开始用 Spring 的时候，框架直接生成了项目骨架，那种”点几下鼠标就出来完整工程结构”的体验让我觉得很神奇。在那之前，每个新项目都要手动建目录、写 pom.xml、加各种 filter 和 listener。

第一次用 AI 编程助手的感觉，只能说太爽了！这种AI马上给出即时反馈，让想法快速落地的编码方式很上瘾，经常晚饭后一坐十几个小时一抬头天已经亮了，就是额度消耗太猛，一天就直接把一周的额度限制用完，好在项目初期TRAE有每日免费额度（cc和codex自带模型太贵了，当遇到一些复杂任务才会使用，本着能省则省的想法用国内模型做个基础的博客足够了），再之后腾讯Hy3的发布有免费体验期转战了CodeBuddy。最近几年 AI 大事件一个接一个：ChatGPT 问世、DeepSeek 刷屏、文生图、文生视频轮番上阵，各行各业都被冲击了一遍，当今整个社会正在被 AI 重构。

自己以前也有很多未落地的想法，基于对AI抱有很高的兴趣，从古法编程转向Vibe Coding，从技术选型到功能取舍 AI 全程辅助我完成该项目。

经过：30分钟，从零到一个能跑的博客

我在对话框里大概说了这么个意思：想搭个个人博客，能用 Markdown 写文章，支持暗色模式。

当时并不清楚博客一般有哪些框架、该怎么选，所以没指定技术栈，直接让 AI 根据我觉得好看的几个博客为例子作为数据源分析，列几个可行方案，讲各自的优缺点。它给了两三个方向，我看完利弊，自己选了一个，确认了才开始。整个过程更像问答式的计划确认，而不是像之前的聊天式甩一句话就等结果。

AI 给出了一套完整的项目结构：package.json、astro.config.mjs、几个 .astro 页面文件，还带了一个基础的主题切换逻辑。它顺带解释了一句：Astro 是静态站点生成器，支持 Islands 架构，可以类比成每个 .astro 文件类似一个 JSP 页面，但编译成静态 HTML。

作为一个后端，“类似于 JSP”这个类比让我一下就懂了。我甚至不需要知道 Astro 到底是什么，就知道它在架构里处在什么位置。

我照着 AI 给的步骤，复制粘贴了几段命令：

npm create astro@latest
npm install
npm run dev

浏览器打开 localhost:4321，一个虽然简陋但确实能跑的博客出现在眼前。有首页、有关于页、有文章列表，点文章能进详情，右上角还有个切亮色和暗色主题的按钮。

从零到一个能跑的博客，30分钟。作为一个后端，基础 HTML 我懂，但要是让我自己去学前端那套框架，花很长时间都不一定知道能捣鼓出个什么页面来。AI 把这步直接跳过去了。

隐患：代码能跑，但我并不真正理解它

跑起来之后，看着代码有点懵。

AI 生成的前端代码能跑，但很多写法不认识也不熟悉，但我并不细看前端代码，通常是看着界面效果，哪里不对就让 AI 改，改完翻一眼它动了哪几行，靠英文单词大概猜出在干什么。像 filter 这类公共词我能猜到是过滤器，但再深的前端细节，比如某个样式为什么这么写、某个效果靠哪段代码实现，我不去死磕，交给 AI 就好。

好比用 Spring Boot 的自动配置：项目一下跑起来了，但一旦出问题，要是没去搞懂它背后那些默认配置，连该去哪改都不清楚，只能干瞪眼。好在可以直接问模型，虽然它有时候在瞎掰。至少不用像以前怕别人笑话，也没有很高的学习成本。

区别在于，Spring Boot 的自动配置是确定的、能调试的、有官方文档的。AI 生成的代码不一样，它本质上是概率生成的，没法像查文档那样解释清楚为什么是这样。

事故一：暗色模式代码块看不清

  • 现象：博客跑起来的第二天，文章页面的代码块在暗色模式下看不清。
  • 处理：让 AI 帮我修一下。AI 在 global.css 里加了几行样式，问题解决了。
  • 看似：闭环。

事故二：三天后，相册图片变色

  • 现象：博客跑起来的第三天，相册页面的图片在暗色模式下颜色变得很怪。
  • 处理：把现象丢给 AI 让它分析，最后定位到就是 AI 三天前加的那几行 CSS 导致的。
  • 根因：它用了一个全局选择器去改所有图片的滤镜，我当时根本没意识到这会影响到别的页面。

根因分析

AI 给的修复是局部最优：它改了 A 的图片滤镜，不知道（也不管）这会带崩 B 的相册页。

类比后端，就像改了一个共用 Service 的方法签名，却没检查所有调用方。在 Java 里 IDE 会立刻标红编译错误，前端 AI 编程里没有任何静态检查会提醒你。

再深一层：AI 是概率生成，它给出的”修复”没有对错的概念，只有像不像。它自己也不知道那几行全局选择器会波及相册，因为它不”看”自己改完的页面。

修复

把相册变色的案例给 AI，让它顺着现象查引用，回退掉那个全局滤镜选择器，只保留针对代码块的选择器，问题解决。后来养成一个习惯每次让 AI 改代码前先圈定影响范围（可以通过智能体自带选择器或熟悉项目结构，快速定位属于哪个代码文件），改完用 git diff 看它到底动了什么。

教训

  1. 让 AI 改代码，先圈定影响范围，改完 git diff 审查它动了什么。
  2. AI 的修复默认是”局部最优”，全局副作用要自己查。
  3. 前端没有编译期检查，验证只能靠肉眼 + 多页面回归。

一个更深层的焦虑

如果 AI 30分钟能搭好博客，别人也能。如果 AI 能替我写代码，那我这些年攒下的东西还有什么用？

这个问题我到后面才慢慢想清楚。AI 能帮你写代码，但它不知道你的业务是什么、用户是谁、系统边界在哪。这些它不知道的地方，恰好是有经验的工程师价值所在的地方。

就像给新人一个 Spring Boot 脚手架，他能跑起来，但不知道为什么要分层、什么时候该上缓存、怎么设计 API 的错误码。AI 能给你代码，给不了你判断力。