背景：一个后端想搭博客

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

第一次用 AI 编程助手的感觉，只能说太爽了。这种即时反馈、想法快速落地的编码方式很上瘾，经常晚饭后一坐十几个小时，一抬头天已经亮了。就是额度消耗太猛，一天就能把一周的额度用完。

好在项目初期 TRAE 有每日免费额度，够用（cc 和 codex 自带的模型太贵，只有遇到复杂任务才用；本着能省则省的想法，用国内模型做个基础博客足够了）。后来腾讯 Hy3 发布有免费体验期，就转战了 Code Buddy。

最近几年 AI 大事件一个接一个：ChatGPT 问世、DeepSeek 刷屏、文生图、文生视频轮番上阵，各行各业都在被重构。

自己以前也有很多没落地的想法，加上对 AI 抱有很高的兴趣，就这么从古法编程转向了 Vibe Coding。从技术选型到功能取舍，AI 全程辅助我完成了这个项目。

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

我在对话框里大概说了这么个意思：想搭个个人博客，能用 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，一个虽然简陋但确实能跑的博客出现在眼前。有首页、有关于页、有文章列表，点文章能进详情，右上角还有个切亮色和暗色主题的按钮。

从零到一个能跑的博客，十几分钟。让我自己去啃前端那套框架，花很长时间都未必能做出个完整页面，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 十几分钟能搭好博客，别人也能。如果 AI 能替我写代码，那我这些年攒下的东西还有什么用？

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

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