我的 AI 编程工作流：chezmoi + OMC + Astro + GitHub Actions

我的开发环境不是一天建成的，而是随着遇到的具体问题逐步演进的。每个工具解决一个真实痛点，而不是为了「自动化」而自动化。

chezmoi：跨设备的 dotfile 管理

最早的问题是：我在多台机器上工作，.claude/ 配置、shell 环境、Git 配置每次都要重新调整。手工同步不仅麻烦，还容易出错。

chezmoi 的核心思路是配置即代码：把 dotfile 放进一个 Git 仓库，用模板和变量管理不同机器的差异。比如 ~/.claude/settings.json 在不同机器上可能有不同的 API endpoint，但模板只写一份，构建时自动渲染。

这个方案解决了三个具体问题：一是版本控制，所有变更都有历史可查；二是多设备同步，拉取仓库就等于同步了环境；三是模板复用，避免了复制粘贴导致的配置漂移。

OMC：多 Agent 编排框架

光有配置管理还不够。在实际编程中，我发现同样的问题会在不同项目反复出现——TypeScript 类型错误、Tailwind CSS 的 FOUC 问题、Git 操作失误。每次都从头诊断效率很低。

OMC（oh-my-claude-code）是一个 Agent 编排框架，核心是三层系统：规则（强制执行的行为约束，如「禁止空道歉必须给方案」）、Skill（封装好的专业工作流，如 build-error-resolver）、记忆系统（项目级和全局级的知识积累）。

触发 Skill 不是靠猜测，而是基于任务类型匹配。比如遇到 build 报错就调用 build-error-resolver，它比通用推理更擅长定位编译问题的根因。规则系统则保证了即使不用 Skill，某些行为准则也被强制执行，比如任何修复前必须先验证症状消失而不是技术层通过就声称完成。

Astro：静态网站生成

网站是展示工作成果的窗口。Astro 的选择主要是两个原因：一是默认零 JavaScript 输出，性能好；二是组件模型对内容类网站很合适，.astro 文件里可以混用 Markdown 和自定义组件。

我的网站部署在 GitHub Pages，域名是 wangrui2025.github.io。内容放在 src/pages/blog/ 目录，每篇博客是一个 Markdown 文件，frontmatter 定义标题和日期。Astro 负责把 Markdown 编译成静态 HTML，同时处理 i18n 路由。

这个工作流的好处是：写博客就是写 Markdown，不需要登录 CMS，不需要打开编辑器，直接 git push 就能发布。

GitHub Actions：push 后自动构建发布

手动构建和部署太繁琐了。每次写完博客要跑 npm run build，然后把 dist/ 目录 push 到 gh-pages 分支。这个流程不仅累人，还容易因为忘记某个步骤导致发布失败或延迟。

GitHub Actions 把这个流程自动化了：检测到 main 分支有 push，就触发构建流程，运行 npm install && npm run build，然后把构建产物部署到 GitHub Pages。依赖会被缓存，下次构建会快很多。

整个链路是：本地 push → GitHub 接收 → Actions 自动构建 → GitHub Pages 发布。我只需要写内容和 push，剩下的全是自动化。

为什么串起来

每个工具解决一个具体问题，不是为了用而用。chezmoi 解决的是「多设备环境同步」，OMC 解决的是「重复问题的快速诊断和规则执行」，Astro 解决的是「内容网站的性能和开发体验」，GitHub Actions 解决的是「发布流程的自动化」。

四个工具的共同点是把人工操作变成代码/配置，从而减少手工操作带来的错误。最终效果是：从写完博客到发布上线，整个过程不需要人工干预，我只需要确保代码能通过 type check 和 build。