背景：比后端选型难下手得多

选技术栈这件事，在后端通常有清晰的决策树：“用 Spring Boot 还是 Spring Cloud”看单体还是微服务；“用 MySQL 还是 PostgreSQL”看团队技术栈和数据模型复杂度；“用 Redis 还是本地缓存”看并发量和一致性要求。每个选项的边界条件我都能说出来。

前端选型完全是另一个世界。我问 AI：“我想搭一个个人博客，用什么技术栈？”

AI 的回复大概是：

  1. Astro + Tailwind CSS：适合内容型站点，默认零 JS，按需激活 Islands，构建产物极小
  2. Next.js + React：适合交互密集型应用，支持 SSR/SSG/ISR，生态最丰富
  3. Nuxt + Vue：Vue 生态的 Next.js 等价物，适合 Vue 开发者
  4. Gatsby + GraphQL：老牌静态站点方案，插件丰富但构建速度较慢
  5. Hugo：Go 语言编写，构建极快，但模板语法学习曲线陡峭

我看完的反应：Islands 是什么？SSR、SSG、ISR 又是什么？一个博客为什么需要 GraphQL？Hugo 是 Go 写的，为什么我还得写 HTML？

每个选项背后都是一个陌生的概念，为避免后续返工，花了几乎一整天去熟悉前端的一些概念及博客技术路线。

转折：问对问题比知道答案更重要

我意识到，直接让 AI 推荐没用，它给的全是”标准答案”，放在我的场景里毫无意义。得换个问法。

我重新描述了自己的背景和需求：

“我是 Java 后端工程师，基础 HTML 懂一些，但让我自己写 Vue 那套前端框架和技术栈，花很久都不一定知道能做出什么页面。我需要：

  1. 能写 Markdown 博客文章，支持代码高亮
  2. 部署简单，最好一键
  3. 有现成的主题或模板可以改，不要从零写 UI
  4. 以后可能要加动态功能（评论、搜索等）
  5. 学习曲线要低，不想花一个月学一个新框架”

基于这个更精确的 prompt，AI 给了一个我能看懂的推荐：

Astro + Tailwind CSS + Netlify 部署。 Astro 的文件路由机制和 Spring MVC 的 Controller 映射类似，更容易理解；Tailwind 是工具类 CSS，不用单独写样式文件；Netlify 支持 Git 自动部署，push 即上线。

这就看懂了，用熟悉的一些概念做对比解释不懂的东西。

AI 不会主动了解你

这是学到的第二个重要教训：AI 不会根据你的背景调整回答，除非你明明白白把背景告诉它。

你问”推荐什么技术栈”时，AI 默认你是全栈工程师，给你一个面面俱到的答案。可你是后端转前端，它不知道；你是学生只想快速上手，它也不知道；你是设计师只关心视觉效果，它还是不知道。

这跟后端接口设计的概念一样。如果你定义了一个 GET /api 接口，却不要求调用方传入任何用户画像参数，那返回的就一个通用的、对谁都一样的结果。要让 AI 给你个性化答案，你得像传参数一样，把背景、限制条件、偏好都明确告诉它。

这就是后来的 System Prompt 和 Persona（人设）的雏形。

提示词进化史：从”帮我做个博客”到分步迭代

严格来说，我的第一条 prompt 是”帮我做个博客”。AI 回我：“好的！请告诉我你希望博客包含哪些功能？例如：文章列表和详情页、分类和标签系统、评论功能、搜索功能……”它没办法动手，因为它不知道我想要什么。这很合理，就像你不能跟一个外包团队说”帮我做个系统”然后指望他们直接交付。

之后的四级进化：

  1. 一句话需求：“帮我用 xx 搭一个博客”。结果：能跑，但丑得没法看，功能也极其基础。
  2. 详细需求：把功能列成 5 条（文章列表、Markdown 代码高亮、暗亮切换、关于页、响应式）。结果：功能对了，但还是一般。AI 只会做你明确提到的功能，不会主动帮你考虑更多。
  3. 带约束的详细需求：加技术约束（不要用 xx技术、CSS 要简单、Git push 自动上线）和代码规范（组件命名用后端能理解的类比、选最简单实现）。结果：好多了，AI 开始主动解释它为什么这样设计。
  4. 分步骤迭代：一次性把需求说清楚几乎不可能，因为你根本不知道有哪些东西需要说。改成先搭骨架（路由、布局、基础样式），确认没问题再加文章系统，然后主题切换，最后评论。每一步验证功能对不对、有没有破坏之前的代码。

对比后端：prompt 本质就是一个非结构化的”接口文档”。好的接口文档有三要素：请求参数、返回结果、异常处理。写得好，AI 就像调用了一个设计良好的 API；写得烂，AI 给的结果就像调用了一个没有文档的内部接口，完全靠猜。

prompt 工程的核心不是技巧是思维：你能在脑中先有一个清晰的目标，然后用 AI 能理解的方式把它表达出来。跟同事沟通可以用简略语言，因为你们有共享上下文；跟 AI 沟通必须把所有上下文都显式写出来，它不会”意会”，只会”言传”。

反面教材：播放器盖住了”旅行足迹”

有一次我想让 AI 帮我加一个音乐播放器，我说：“帮我在博客加一个音乐播放器，能在页面顶部播放背景音乐。”

AI 给我加了一个 audio 标签和播放控件，放在了页面顶部。能播放，功能正常。

但我没注意到的是，AI 把播放器放在了首页顶部，而首页顶部原来有一个”旅行足迹”的卡片区域，被完全覆盖掉了。直到几天后我自己验证其他功能浏览时发现该卡片无法点击且没有任何选中效果的样式。

回去问 AI：“我怎么点不了足迹卡片了？“它回答：“我在添加播放器时修改了页脚布局，这可能影响了原有的内容。非常抱歉没有提前告知。”

它知道它覆盖了，但它没说。

这就是 prompt 不够精确的后果：我只说了”加一个播放器”，没说”不要影响其他元素”。但问题是，作为不太碰前端的后端，我根本不知道加一个播放器会影响其他元素，所以我根本没办法在 prompt 里加上这个约束。类似的循环后面还会反复出现。

延伸：Decap CMS 的选型

博客中期想可视化写文章，选了 Decap CMS（原 Netlify CMS），没错也是AI推荐的，Git 驱动的零后端内容管理。配置驱动的任务 AI 表现不错，但通用方案遇到特殊约束照样失效：

  • git-gateway 早已废弃，得改用 github OAuth（backend.name: github + repo + branch: dev）
  • /admin 要用 <base href="/admin/"> 而不是 netlify.toml 301，否则无限重定向循环
  • MDX 必须 format: frontmatter，否则报 required property 'format'

CMS 本质是把 DB/后端/插件换成了 Git/YAML，理解这一点，配置就顺了。

教训

  1. 问 AI 前先把自己的背景、约束、目标写清楚，别指望它猜。不传参数就别怪接口返回通用结果。
  2. AI 给的方案列表是”标准答案”，只有结合你的约束才有意义，技术选型没有绝对好坏。
  3. prompt 分步迭代、每步验证，比一次性堆需求可靠。
  4. AI 只会做你明确提到的功能。没说”不要影响其他元素”，它就不保证。
  5. 第三方方案（CMS、认证、部署）必须查官方文档确认时效，AI给的结果可能会过时。