feat: 新增博客文章「从 Vibe 到 Spec」及 GitHub Alerts 支持

- 新增博客文章：从 Vibe 到 Spec：我的 AI Coding 工作流
- 添加 remark-github-blockquote-alert 插件支持 GitHub 风格提示框
- 添加 GitHub Alerts 样式（支持亮色/暗色主题）
- 调整封面图 object-fit 为 contain 避免裁切
- 更新 .gitignore 忽略图片资源目录

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: xkcoding

.gitignore

@@ -43,4 +43,6 @@ scripts/migrate-images/reports/
 # ossutil output
 ossutil_output/
 
+cover-image/
 xhs-images/
+illustrations/

astro.config.ts

@@ -3,6 +3,7 @@ import tailwindcss from "@tailwindcss/vite";
 import sitemap from "@astrojs/sitemap";
 import remarkToc from "remark-toc";
 import remarkCollapse from "remark-collapse";
+import remarkGithubBlockquoteAlert from "remark-github-blockquote-alert";
 import {
   transformerNotationDiff,
   transformerNotationHighlight,
@@ -26,7 +27,11 @@ export default defineConfig({
     }),
   ],
   markdown: {
-    remarkPlugins: [remarkToc, [remarkCollapse, { test: "Table of contents" }]],
+    remarkPlugins: [
+      remarkToc,
+      [remarkCollapse, { test: "Table of contents" }],
+      remarkGithubBlockquoteAlert,
+    ],
     shikiConfig: {
       // For more themes, visit https://shiki.style/themes
       themes: { light: "min-light", dark: "night-owl" },

package.json

@@ -22,6 +22,7 @@
     "dayjs": "^1.11.19",
     "lodash.kebabcase": "^4.1.1",
     "remark-collapse": "^0.1.2",
+    "remark-github-blockquote-alert": "^2.0.1",
     "remark-toc": "^9.0.0",
     "satori": "^0.18.3",
     "sharp": "^0.34.5",

pnpm-lock.yaml

@@ -5,7 +5,7 @@ pubDatetime: 2026-01-17T00:00:00.000Z
 slug: extend-claude-code-with-slash-command
 featured: true
 draft: false
-ogImage: https://cdn.xkcoding.com/blog/2026-01-19-cover.png?x-oss-process=style/tag_compress
+ogImage: https://cdn.xkcoding.com/blog/2026-01-22-2026-01-19-cover.webp?x-oss-process=style/tag_compress
 tags:
   - ai
   - claude-code

src/data/blog/2026-01-17.extend-claude-code-with-slash-command.md

@@ -0,0 +1,311 @@
+---
+title: "从 Vibe 到 Spec：我的 AI Coding 工作流"
+author: xkcoding
+pubDatetime: 2026-01-22T00:00:00.000Z
+ogImage: https://cdn.xkcoding.com/blog/2026-01-22-cover-sketch-16x9.webp?x-oss-process=style/tag_compress
+slug: vibe-to-spec-ai-coding-workflow
+featured: true
+draft: false
+tags:
+  - ai-coding
+  - vibe-coding
+  - sdd
+  - openspec
+  - methodology
+description: "Vibe Coding 快速验证想法确实爽，做复杂功能就翻车——AI 总爱过度设计，简单需求给你整复杂，方向错了代码写再多也白搭。这篇分享我摸索出的工作流：用 Gemini 探讨方向出 Deep Research 报告，再用 OpenSpec 管理 SDD 流程，proposal → review → apply → archive 四步循环。Vibe 负责发散，Spec 负责落地，两阶段配合避免返工。"
+---
+
+## 写在前面
+
+2025 年初，Andrej Karpathy 在 [X 上提出了 "Vibe Coding"](https://x.com/karpathy/status/1886192184808149383) 这个概念：
+
+> "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
+>
+> "I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment."
+
+说白了就是：完全信任 AI，不看代码，不读 diff，报错就贴，能跑就行。
+
+用这种方式快速验证想法确实爽。但做稍微复杂点的东西，问题很快就来了：
+
+- 对话长了，AI 开始"失忆"，之前的需求细节全忘了
+- AI 自信地写出根本不存在的 API
+- 改了 A 功能，B 功能莫名其妙挂了
+
+这些是业内公认的问题。
+
+但让我更头疼的是另一类情况——**方向错了**：
+
+- 让 AI 做消息通知，它设计了 Kafka + ZooKeeper + 死信队列。我日活 100 人，一张表 + 轮询就够了
+- 让 AI 做数据导出，它造了异步任务 + 5 张表。我只想导个 Excel
+
+代码能跑，但方向错了，写得再多也是白写。
+
+有了 AI 能力之后，我的时间不该花在反复调教、改 BUG 上。我想要的很简单：**快速完成满意的功能**。
+
+折腾了一段时间后，我摸索出一套工作流。用 Vibe 的方式探索方向，用 Spec 的方式保证质量。
+
+这篇文章分享一下我的做法。
+
+---
+
+## 整体思路
+
+我的做法分两个阶段：**Vibe 发散** 和 **SDD 落地**。
+
+![Vibe to Spec 工作流](https://cdn.xkcoding.com/blog/2026-01-22-illustration-workflow-overview-sketch.webp?x-oss-process=style/tag_compress)
+
+> [!IMPORTANT]
+> 核心逻辑：**先用 Vibe 的方式把方向聊对，再用 Spec 的方式把代码写对**。
+>
+> Vibe 阶段产出的研究报告，就是 SDD 阶段的输入。报告里定好了做什么、用什么技术、大致怎么拆分，后面写代码就不容易跑偏。
+
+**Vibe 阶段**用来探索方向。idea 还不清晰的时候，跟 AI 聊，找可行性，定技术栈。这个阶段不写代码，只输出一份研究报告。
+
+**SDD 阶段**用来保证质量。拿着研究报告进入 Coding Agent，用 OpenSpec 管理开发流程。先出 proposal，review 通过再写代码。
+
+两个阶段的分工：**Vibe 负责方向，SDD 负责执行**。
+
+### 用什么工具
+
+这套流程可复制，工具可以换。
+
+**Vibe 阶段**，我用 Gemini。你也可以用 ChatGPT、Claude 或其他擅长探讨的模型。
+
+**SDD 阶段**，工具有几个选择：
+
+- [OpenSpec](https://github.com/Fission-AI/OpenSpec)：我在用的，轻量、流程清晰
+- [Spec-Kit](https://github.com/github/spec-kit)：GitHub 出的，64k stars，支持的 Coding Agent 更多
+- 还有 Kiro、Tessl 等，可以参考 [Martin Fowler 的对比文章](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+
+这些工具思路差不多，选一个顺手的就行。
+
+**Coding Agent 层面**，Cursor、Claude Code、Codex、Gemini CLI 都能配合 SDD 工具用。
+
+> [!WARNING]
+> 有一点要说清楚：**基座模型的质量直接决定产出质量**。同样的流程，用 Claude 和用一个普通模型，效果差很多。我选 Claude Code 不是因为工具好用，而是因为 Claude 的代码能力目前最强。工具可以换，模型质量不能妥协。
+
+---
+
+## 先聊方向
+
+这个阶段要做的是把模糊的 idea 变成一份清晰的研究报告。不写代码，只聊方向。
+
+### 两种聊法
+
+跟 AI 探讨的时候，我发现自己有两种状态：
+
+**探路者模式**。脑子里就一个模糊的想法，能不能做、怎么做都不知道。这时候主要是让 AI 帮我找可行性、选技术栈。聊着聊着，某个方案让我眼前一亮，差不多就可以往下走了。
+
+**细化者模式**。方向大概有了，但细节还没想清楚。这时候主要是让 AI 帮我细化方案、确认技术点。关键技术点都聊到了、实现路径也大致清晰了，就可以进入下一步。
+
+![两种聊法](https://cdn.xkcoding.com/blog/2026-01-22-illustration-two-modes.webp?x-oss-process=style/tag_compress)
+
+两种模式的结束信号不一样，但目标一样：**输出一份足够清晰的研究报告**。
+
+### 为什么用 Gemini
+
+Vibe 阶段，我用 Gemini。
+
+选它的原因是：Gemini 是 Google 家的，搜索能力原生集成。聊技术方案的时候，给的信息更贴近最新潮流，不容易查到过时的东西。
+
+模型的选择也有讲究。我的优先级是 **2.5 Pro > 2.5 Flash Thinking > 2.5 Flash**。Pro 的推理能力最强，探讨复杂方案的时候更靠谱。Flash 系列速度快，简单问题用它就够了。
+
+这个阶段不写代码，只需要聊清楚"做什么"和"怎么做"。信息检索能力比代码能力更重要。
+
+### 聊完怎么出报告
+
+探讨到位之后，别急着写代码。先让 Gemini 输出一份深度研究报告。
+
+我的做法：
+
+1. 让 Gemini 总结一下讨论结果
+2. 自己过一遍，确认没遗漏重要的点
+3. 让 Gemini 生成一个 Deep Research 的提示词
+4. 新开一个 Gemini Deep Research 会话，把提示词贴进去
+5. 拿到深度研究报告
+
+这份报告就是进入 SDD 阶段的输入。我一般保存成 `idea.md` 和 `report.md`，后面初始化 proposal 的时候会用到。
+
+如果你发现报告里有明显遗漏或者方向偏了，多半是前面探讨阶段聊得不够透。回去补几轮再出报告，别硬往下走。
+
+---
+
+## 再动手做
+
+拿到研究报告之后，就进入 SDD 阶段了。这个阶段要做的是把报告变成可运行的代码，而且要保证质量。
+
+### SDD 是什么
+
+SDD 是 Spec-Driven Development，核心思想是：**先写规范，再写代码**。
+
+不是拿到需求就让 AI 开干，而是先让 AI 出一份 proposal，描述要做什么、怎么做、分几步。人 review 通过之后，再按 proposal 写代码。
+
+> [!TIP]
+> 好处很直接：问题在 review 阶段发现成本低，代码写完之后发现成本高。
+
+市面上 SDD 工具不少，我选 [OpenSpec](https://github.com/Fission-AI/OpenSpec)。选它的原因：
+
+- **轻量**：就是一套目录结构 + 几个命令，没有复杂的配置
+- **工具无关**：支持 Cursor、Claude Code、Codex、Gemini CLI 等主流 Coding Agent
+- **流程清晰**：proposal → review → apply → archive，四步循环
+
+跑一下 `openspec init` 就能用，不需要学很多东西。
+
+### 怎么跑起来
+
+拿着 Vibe 阶段产出的 `idea.md` 和 `report.md`，开始 SDD 流程。
+
+**第一步：初始化项目**
+
+```bash
+mkdir my-project && cd my-project
+openspec init
+```
+
+初始化之后，项目里会多一个 `openspec/` 目录：
+
+```
+openspec/
+├── specs/       # 当前规范（系统的"记忆"）
+├── changes/     # 进行中的变更（proposal + tasks）
+└── archive/     # 已完成的变更（可追溯）
+```
+
+**第二步：初始化 proposal**
+
+打开 Coding Agent（我用 Claude Code），执行：
+
+```
+/openspec:proposal 帮我初始化一个 proposal 用于实现原始想法 @idea.md 的功能，具体可以参考 @report.md ultrathink
+```
+
+这条命令做了三件事：
+
+- 引用 `idea.md` 和 `report.md`，把 Vibe 阶段的产出带进来
+- 让 AI 生成 proposal.md + design.md + tasks.md
+- `ultrathink` 触发深度思考模式，确保方案考虑周全
+
+**第三步：review**
+
+AI 生成完之后，别急着往下走。打开 proposal.md、design.md、tasks.md，逐个过一遍：
+
+- 方案是不是你想要的？
+- 技术选型对不对？
+- 任务拆解合理吗？
+
+有问题就让 AI 改，改到满意为止。这一步多花点时间，后面能省很多事。
+
+**第四步：apply**
+
+review 通过之后，让 AI 按 tasks.md 逐步实现：
+
+```
+/openspec:apply
+```
+
+AI 会边做边更新 task 进度。做完一个 task，就标记一个完成。
+
+**第五步：archive**
+
+全部完成之后，归档这次变更：
+
+```
+/openspec:archive
+```
+
+归档会把 proposal 移到 `archive/` 目录，保持 `changes/` 干净。下次新功能，再起一个新的 proposal。
+
+这就是一轮完整的 SDD 循环。
+
+![SDD 开发循环](https://cdn.xkcoding.com/blog/2026-01-22-illustration-sdd-cycle.webp?x-oss-process=style/tag_compress)
+
+---
+
+## 一些经验
+
+SDD 流程跑起来之后，踩了一些坑，下面有几个实践经验值得分享一下。
+
+### 一个 spec 做一件事
+
+一个项目不可能一个 proposal 就做完。我的做法是：**渐进式堆砌**。
+
+两种情况：
+
+**主动规划**。一开始就知道功能很大，拆成多个 spec。先做 MVP 核心功能，跑通了再加其他的。比如做一个内容管理系统，第一个 spec 只做"文章增删改查"，第二个 spec 再加"分类标签"，第三个 spec 加"搜索"。
+
+**做着发现**。做的过程中发现"如果加个这个功能体验会更好"。这时候别直接改当前 spec，新开一个 spec 来做。保持每个 spec 边界清晰。
+
+不管哪种情况，核心原则是：**一个 spec 只做一件事**。
+
+### 出错了怎么办
+
+用这套流程，错误会少很多。但也会出错。出错的时候，处理方式分两种：
+
+**需求或设计不匹配**。比如做着做着发现，当初设计的方案根本行不通，或者需求理解有偏差。这种情况别硬撑，直接回溯。回到 proposal 阶段重新来，该改设计改设计，该补探讨补探讨。
+
+**设计正确但实现出错**。方向没问题，就是代码写错了。这种情况不用推翻重来。把报错信息和对应的 task 引用告诉 AI，让它定点修复。比如：
+
+```
+task 3.2 的实现有问题，报错信息如下：xxx。请修复。
+```
+
+AI 有了上下文，纠错效果会好很多。
+
+### 什么时候让 AI 慢下来
+
+前面提到 `ultrathink` 可以触发深度思考模式。不是每次都要用，但有几个场景建议用：
+
+**奠基的时候**。初始化 proposal 是整个项目的基础，方案想不清楚后面全是坑。这时候主动触发深度思考。
+
+**卡壳的时候**。AI 来回修改同一个问题，改了几轮还是不对。这时候让它慢下来想想，别一直快速试错。
+
+**失焦的时候**。你说了好几遍需求，AI 还是理解不对。这时候触发深度思考，让它重新梳理一遍上下文。
+
+判断标准很简单：**如果你觉得 AI 在瞎忙，就让它慢下来**。
+
+---
+
+## 什么时候用
+
+这套流程不是万能的，也不是所有场景都要走全套。
+
+我按变更规模分三层：
+
+![什么时候用](https://cdn.xkcoding.com/blog/2026-01-22-illustration-when-to-use.webp?x-oss-process=style/tag_compress)
+
+**大重构 / 大 feature / 探索性功能**。走完整流程：Vibe 阶段探讨 + Deep Research，SDD 阶段 proposal → review → apply → archive。初始化 proposal 的时候触发深度思考。
+
+**小体验优化**。不需要回 Gemini 探讨，直接在 Coding Agent 里起一个轻量 spec。proposal 简单写写，task 列几条，review 一下就开干。
+
+**很小的改动**。改个文案、调个样式、修个明显的 bug。直接改，不用起 spec。
+
+判断原则：**流程是为了控制复杂度，不是为了增加仪式感**。
+
+如果一个改动你闭着眼睛都知道怎么做，就没必要走流程。
+
+---
+
+## 最后
+
+总结一下这套工作流的核心：
+
+- **Vibe 阶段**：跟 Gemini 探讨方向，输出 Deep Research 报告
+- **SDD 阶段**：用 OpenSpec 管理开发，proposal → review → apply → archive
+
+Vibe 负责"做什么"，SDD 负责"做对"。两个阶段配合，既保留了 AI Coding 的发散探索能力，又避免了方向跑偏和反复返工。
+
+这套流程我在 0→1 的新项目和老项目迭代新功能上都验证过，效果不错。不敢说是最优解，但至少比纯 Vibe Coding 可控很多。
+
+工具会不断迭代，模型会越来越强。但"先想清楚再动手"这个道理，应该不会过时。
+
+希望对你有帮助。
+
+---
+
+## 参考资料
+
+- [GitHub - Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)
+- [OpenSpec Deep Dive - redreamality](https://redreamality.com/garden/notes/openspec-guide/)
+- [The End of Vibe Coding - DEV Community](https://dev.to/gara501/the-end-of-vibe-coding-why-spec-driven-development-is-the-future-3hpa)
+- [Spec-driven development with AI - GitHub Blog](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/)
+- [Martin Fowler - Understanding SDD](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)

src/data/blog/2026-01-22.vibe-to-spec-ai-coding-workflow.md

@@ -110,7 +110,7 @@ const nextPost =
             <img
               src={coverImageUrl}
               alt={title}
-              class="h-auto max-h-[250px] w-full object-cover transition-transform duration-300 group-hover/cover:scale-[1.02] sm:max-h-[400px]"
+              class="h-auto max-h-[250px] w-full object-contain transition-transform duration-300 group-hover/cover:scale-[1.02] sm:max-h-[500px]"
               loading="lazy"
               decoding="async"
             />