文章

Mac Vibe Coding 工作站：2026 版总纲

#421 · 2026-05-17 · Mac Vibe Coding 工作站
MacVibe CodingCodexAI 编程工作流

这组文章需要重新定调。

如果还把 Mac 使用经验写成 Alfred、BetterTouchTool、Typora、窗口快捷键，那就落后了。那些工具不是没价值，而是不再是 2026 年的主线。现在真正改变个人电脑使用方式的，是 Vibe Coding：你不再只是“打开编辑器写代码”，而是在 Mac 上组织一个能让 AI 代理读代码、改代码、跑命令、截图验证、写复盘、推送 GitHub 的工作站。

这不是“让 AI 随便生成一个项目”。真正能长期使用的 Vibe Coding 工作流，必须解决五件事：

  1. Mac 本地环境是否可恢复。
  2. AI 编码代理是否有清楚边界。
  3. 每次生成是否能被测试和截图验证。
  4. Git 是否能保留可回滚的提交。
  5. 产出的经验是否能沉淀成博客或文档。

这才是我现在更关心的 Mac 使用经验。

这台 Mac 应该承担什么角色

我不再把 Mac 看成“装很多软件的个人电脑”，而是把它看成一个本地生产节点。

它至少要承担这些角色：

  • 本地开发机：Node、Python、Git、包管理器、数据库、构建工具能正常跑。
  • AI 协作终端：Codex CLI、Claude Code、GitHub Copilot CLI 等工具可以在项目里工作。
  • 验证机器：能跑测试、构建、lint、Playwright 截图、curl 健康检查。
  • 内容工作台：把开发过程、踩坑、配置方法整理成博客。
  • 发布入口：本地改完、验证完、提交、推送 GitHub。

如果这几个角色没有串起来，所谓 Vibe Coding 就会变成“模型生成一堆东西，我看着很热闹，但不知道能不能用”。

2026 年的主线工具

截至 2026-05-17，我会把主线工具分成四层。

第一层是系统和命令行：

  • Terminal / iTerm2
  • zsh
  • Homebrew
  • Git
  • Node / pnpm / npm
  • Python / uv

第二层是编辑器和验证：

  • VS Code 或 Cursor
  • Typora / Sublime Text
  • JupyterLab
  • Playwright
  • 浏览器 DevTools
  • 本地 dev server
  • 项目自带测试命令

第三层是 AI 编码代理：

  • OpenAI Codex CLI / Codex App
  • Claude Code
  • GitHub Copilot CLI / Agent Mode
  • IDE 内联补全工具

第四层是沉淀和发布：

  • Markdown
  • Hugo / 静态博客
  • OBS 录屏
  • GitHub
  • 自动化脚本

旧工具怎么放？

Alfred 可以作为“启动器和剪贴板增强”；BetterTouchTool 可以作为“窗口管理补丁”。但它们不再是系列主角。真正的主角是：一个想法如何从自然语言任务变成可运行代码，再变成一篇有用的教程。

而 Terminal、Zsh、Finder 跳转、Typora、Sublime Text、JupyterLab、OBS 这几类工具，我会保留在主线里。它们不是怀旧工具，而是 Vibe Coding 的基础设施：命令行负责执行，轻量编辑器负责整理文本，JupyterLab 负责验证代码，OBS 负责记录过程。

Vibe Coding 不是无脑让 AI 写

很多人对 Vibe Coding 的误解是：给 AI 一个想法，然后一路回车。

这很危险。模型会写代码，但它也会：

  • 忽略项目已有风格。
  • 写出没跑过的命令。
  • 覆盖用户已有改动。
  • 生成看起来完整但没有验证的页面。
  • 把错误归因到不存在的问题。
  • 在复杂项目里越改越乱。

所以我的做法是把 AI 代理放进一个固定流程：

目标描述
-> 让 AI 先读代码
-> 让 AI 给计划
-> 小步修改
-> 本地构建/测试
-> 浏览器或截图验证
-> Git diff 审查
-> commit
-> 推送
-> 写复盘

这套流程的重点不是“慢”，而是避免在错误方向上快。

一台新 Mac 的 Vibe Coding 检查表

下面这张表是我现在更愿意保留的 Mac 装机检查表。

1. 系统基础

  • 系统语言建议英文，方便搜索报错。
  • 打开 Terminal，确认 shell 是 zsh。
  • 安装 Xcode Command Line Tools。
  • 安装 Homebrew。
  • 配置 Git 用户名和邮箱。
  • 设置 SSH Key 或 GitHub 登录。

验证命令：

zsh --version
xcode-select -p
brew --version
git --version
git config --global user.name
git config --global user.email

2. 开发基础

至少准备这些：

brew install git node pnpm python uv ripgrep jq

我会特别保留 ripgrep 和 jq。前者用于快速搜代码，后者用于看 JSON。AI 代理很强，但你自己也必须能快速定位事实。

验证：

node -v
pnpm -v
python3 --version
uv --version
rg --version
jq --version

3. AI 编码代理

Codex CLI 的官方安装口径通常是：

npm i -g @openai/codex

GitHub Copilot CLI 的官方入口是：

npm install -g @github/copilot

Claude Code 官方页面提供安装脚本：

curl -fsSL https://claude.ai/install.sh | bash

我不会建议所有人同时主力使用三套。更实际的做法是：

  • Codex 作为复杂仓库修改和多步任务主力。
  • Claude Code 作为长上下文阅读和方案讨论补充。
  • Copilot CLI 适合 GitHub 生态和云端 agent 协作。

工具多不是优势，能形成稳定流程才是优势。

4. 浏览器验证

前端项目不能只看“构建成功”。要能打开页面、截图、检查布局。

建议项目里保留：

pnpm add -D @playwright/test
pnpm exec playwright install

如果项目不是 Node 技术栈，也至少要能做到：

  • 本地启动服务。
  • curl 检查健康接口。
  • 浏览器打开页面。
  • 截图留证据。

5. 博客沉淀

Vibe Coding 最大的问题是过程很快，但经验消失也很快。

我现在更倾向于把每次有价值的过程沉淀成三类内容：

  • 操作教程：具体怎么装、怎么配、怎么验证。
  • 工程复盘：哪里错了，为什么错，怎么改。
  • 工作流模板：以后遇到类似任务怎么交给 AI。

这也是为什么 Mac 使用经验不应该停留在“我装了什么软件”。它应该变成“我如何把电脑变成可持续生产系统”。

这个系列会怎么写

接下来的四篇会按实战展开：

  1. 新 Mac 如何搭建 Vibe Coding 底座。
  2. 如何安装和使用 Codex / Claude Code / Copilot CLI。
  3. 如何把 VS Code、Terminal、Git、Playwright 串起来。
  4. 如何把 AI 生成过程沉淀成博客教程。

每篇都会尽量包含：

  • 目标。
  • 适用场景。
  • 安装命令。
  • 配置文件。
  • 操作步骤。
  • 验证方法。
  • 常见坑。
  • 我的取舍。

好的 Vibe Coding 教程不应该只是情绪表达，也不应该只是工具新闻。它应该让读者照着做完之后，真的多一个能工作的本地能力。