文章

Mac Vibe Coding 04：把 AI 编程过程沉淀成博客教程

#425 · 2026-05-17 · Mac Vibe Coding 工作站
MacVibe CodingJupyterLabOBS博客教程

Vibe Coding 最大的浪费，不是模型写错代码，而是你明明解决了一个问题，却没有把过程沉淀下来。

下一次遇到类似问题，又重新问一遍、试一遍、踩一遍坑。

所以我现在更愿意把 Mac 工作流和博客系统连起来：AI 帮我做事，本地验证结果，Git 保留差异，最后把有价值的过程写成教程。

这篇讲具体方法。

目标

每次完成一个有价值的 AI 编程任务后，沉淀出一篇能复用的文章。

文章不应该只是“我今天做了什么”，而应该回答：

  • 问题是什么。
  • 为什么值得解决。
  • 项目原来是什么状态。
  • AI 怎么参与。
  • 关键修改在哪里。
  • 用什么命令验证。
  • 哪些坑值得下次避免。
  • 最终如何提交和发布。

1. 任务开始前先记录目标

不要等任务结束再回忆。开始前就创建一个笔记。

示例：

# Mac Vibe Coding 04：把 AI 编程过程沉淀成博客教程

## Goal

优化博客首页 Archive，减少重复自动稿刷屏。

## Constraints

- 不删除历史文章源文件。
- 首页可见列表去重。
- 完整归档仍可搜索。
- 修改后必须构建 Hugo。

## Verification

- bash scripts/build_blog.sh
- rg "重复标题" blog/index.html
- git diff --stat

这个笔记可以是临时文件，也可以放进项目的 notes/ 目录。

AI 代理也可以读取这份任务说明，减少上下文丢失。

2. 让 AI 输出“可执行计划”

好的计划不是空话，应该包含文件和命令。

提示模板：

请先不要修改文件。阅读项目后给出计划：
1. 要改哪些文件。
2. 每个文件改什么。
3. 如何验证。
4. 哪些文件不应该碰。

如果 AI 的计划里没有验证命令，要求它补。

如果它说“优化布局”“提升质量”这种泛词太多，要求它改成可检查动作。

3. 修改过程保留关键命令

不要把所有终端输出都贴进文章，但关键命令要保留。

例如：

rg "Archive|post-excerpt" blog-src/layouts
bash scripts/build_blog.sh
rg "本期关注" blog/index.html | head
git diff --stat

这些命令会让文章从“经验描述”变成“可复现教程”。

读者看到命令，就知道怎么验证，而不是只能相信你的结论。

4. 用轻量文本工具整理草稿

AI 生成过程里会产生很多临时材料：命令、错误、截图说明、diff 摘要、待办项。不要都塞进聊天窗口。

我会保留两个轻量文本入口：

  • Typora：适合写 Markdown 长文，所见即所得，适合教程初稿。
  • Sublime Text：适合快速打开大文本、批量替换、多光标编辑。

安装：

brew install --cask typora
brew install --cask sublime-text

验证 Sublime 命令：

which subl

如果 subl 不存在，可以手动建立软链接，具体路径按本机安装位置调整：

ln -s "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" /opt/homebrew/bin/subl

常用方式：

typora notes/task.md
subl blog-src/content/posts
subl /tmp/error.log

Typora 适合写最终文章，Sublime 适合处理中间材料。VS Code 当然也能做这些，但我不想每次整理一段文字都打开完整工程环境。

5. 用 JupyterLab 写“可执行教程”

如果教程涉及 Python、数据处理、表格、公式或 API 实验，我会优先用 JupyterLab 验证。

安装桌面版：

brew install --cask jupyterlab

如果你更喜欢命令行环境：

uv venv .venv
source .venv/bin/activate
uv pip install jupyterlab ipykernel
jupyter lab

建议在项目里建：

mkdir -p notebooks

然后把实验放进：

notebooks/2026-05-17-blog-quality-check.ipynb

写教程前，先在 Notebook 里确认：

  • 代码真的能跑。
  • 输入输出可见。
  • 中间结果可解释。
  • 关键参数没有写错。

导出 Markdown：

jupyter nbconvert --to markdown notebooks/your-notebook.ipynb

这一步能把“我觉得能跑”变成“我跑过”。技术教程最怕的就是代码只在文章里正确。

6. 用 OBS 录制关键过程

OBS 不只是直播工具，也适合录制本地操作过程。

安装：

brew install --cask obs

首次打开后，macOS 可能需要给权限：

System Settings -> Privacy & Security -> Screen Recording -> OBS
System Settings -> Privacy & Security -> Microphone -> OBS

我建议准备三个场景：

  1. Screen + Mic：录屏和麦克风，用于完整讲解。
  2. Browser Demo：只捕获浏览器窗口，用于网页验证。
  3. Terminal Demo：只捕获 Terminal 或 VS Code，用于命令演示。

OBS 里添加来源：

Sources -> + -> Screen Capture / Window Capture
Sources -> + -> Audio Input Capture

录制 Vibe Coding 教程时，重点不是把全过程都录下来，而是录这几段：

  • 原始问题长什么样。
  • AI 修改后怎么验证。
  • 关键命令怎么跑。
  • 最终页面或功能是否正常。

注意两个坑：

  • 录制时避免把密钥、token、后台账号露出来。
  • 如果出现回音，检查系统声音和麦克风输入，不要让扬声器声音再次进麦克风。

一段 2-5 分钟的操作录屏，后面可以反过来辅助写教程，比纯回忆可靠。

7. Git diff 是最好的复盘材料

任务完成后先看：

git diff --stat

它能告诉你这次改动的实际范围。

再看具体 diff：

git diff

写博客时可以按 diff 组织内容：

  • 新增了什么文件。
  • 修改了什么模板。
  • 删除了什么旧逻辑。
  • 生成了哪些静态产物。

这比凭记忆写更准确。

8. 截图和页面验证要保存结论

前端任务尤其需要截图。

可以用 Playwright：

pnpm exec playwright screenshot http://127.0.0.1:8081/blog/ /tmp/blog-home.png

也可以用浏览器手动检查，但文章里要记录检查点：

## 验证结果

- 首页 Archive 不再显示重复标题。
- 科技快报摘要显示具体条目。
- 完整归档搜索仍能检索标题和摘要。
- Hugo build 通过。

不要只写“验证通过”。通过什么，要具体。

9. 教程文章结构模板

我建议把工程教程固定成这个结构：

+++
title = "..."
date = "..."
summary = "..."
tags = [...]
+++

## 背景

说明为什么要做。

## 目标

列出可验证目标。

## 原始问题

截图、现象、错误日志或坏体验。

## 实现步骤

一步一步写命令和文件变化。

## 验证

列出执行命令和结果。

## 踩坑

记录错误路径。

## 可复用结论

抽象成下次能用的规则。

有了模板，写文章会快很多。

10. 用 AI 辅助写文章，但不要让它编

可以让 AI 根据任务笔记、diff、命令输出生成初稿。

提示：

根据以下材料写一篇中文技术教程：
- 任务目标
- git diff 摘要
- 验证命令
- 关键问题

要求：
- 不要编造没有执行过的命令。
- 不要夸大效果。
- 每一步都能复现。
- 最后给出可复用结论。

然后人工改。

重点是：AI 可以帮你整理，但事实来源必须来自本地执行结果。

11. 发布前检查

博客发布前跑：

bash scripts/build_blog.sh

检查新文章是否出现在首页或归档：

rg "文章标题" blog/index.html blog/posts/index.html

检查文章页是否生成：

test -f blog/posts/your-slug/index.html

看 Git 状态：

git status --short
git diff --stat

提交：

git add blog-src/content/posts/your-post.md blog/posts/your-slug blog/index.html blog/index.xml blog/posts/index.html blog/posts/index.xml
git commit -m "Add tutorial about ..."
git push origin main

12. 什么内容值得写成博客

不是每次 AI 生成都值得写。

值得沉淀的是：

  • 修复了一个会反复出现的问题。
  • 找到了一套可复用配置。
  • 形成了验证流程。
  • 发现了某类 AI 容易犯的错。
  • 对工具选择有了明确判断。
  • 能帮助未来的自己少踩坑。

不值得写的是：

  • 单次复制粘贴。
  • 没有验证的试验。
  • 只是模型输出摘要。
  • 没有项目上下文的工具新闻。

13. 把博客变成项目资产

长期看，博客不是内容展示页，而是项目记忆。

它应该记录：

  • 为什么这样设计。
  • 哪些自动化被修过。
  • 哪些质量门槛被加过。
  • 哪些工具后来被淘汰。
  • 哪些流程真正提高了效率。

这也是为什么“Mac 使用经验”要转向 Vibe Coding。因为现在的个人电脑经验，已经不只是“我怎么用 App”，而是“我如何组织人、AI、代码、验证和发布之间的关系”。

我的结论

Vibe Coding 的终点不应该是一堆生成文件，而应该是一套越来越清晰的个人工程方法。

Mac 是执行环境，AI 是协作者，Git 是记忆，测试和截图是事实，博客是沉淀。

这几件事串起来，才是真正有价值的个人工作站。