我的本机 AI 工作台：Mac、Chrome、脚本、Cloudflare 和 GitHub 怎么串起来

如果说「万象片场」是一座正在搭建的 AI 内容片场，那么本机 AI 工作台就是片场的中控台：Mac 负责文件和命令，Chrome 负责真实网页环境，脚本负责可重复执行，Cloudflare 负责上线，GitHub 负责版本记录。

很多人谈 AI Agent 时，容易把重点放在“模型有多聪明”。但我这段时间的实测越来越清楚：真正决定 Agent 能不能稳定做事的，不只是模型能力，而是它身边有没有一套清楚、可验证、可回滚的工作台。

这篇文章就把我的本机 AI 工作台拆开讲一遍：它不是昂贵复杂的企业系统，而是一套普通创作者也能逐步搭起来的数字员工基础设施。

一、为什么我更重视本机工作台，而不是单个 AI 工具

单个 AI 工具通常只能完成一个局部动作：写一段文案、生成一张图、总结一篇文章、回答一个问题。但“数字员工”要完成的是连续任务，例如：

1. 读取内容计划；
2. 检查已有文章，避免重复；
3. 写入正确的 Markdown 文件；
4. 启动本地预览；
5. 检查首页、归档页、文章页和图片；
6. 构建项目；
7. 部署到 Cloudflare Pages；
8. 验证线上页面；
9. 提交并推送 GitHub。

这不是一次聊天能解决的问题，而是一条生产线。生产线最怕的不是某一步慢一点，而是没有状态、没有检查、没有日志、没有回滚。

所以我给万象片场设计本机 AI 工作台时，优先考虑的不是“看起来智能”，而是四个关键词：文件可控、动作可查、结果可验证、错误可恢复。

二、Mac：把所有资产放在可管理的位置

Mac 在这套系统里不是普通电脑，而是内容资产和自动化任务的主工作区。

博客项目固定在：

/Users/william/projects/cloudflare-blog

内容计划固定在：

/Users/william/.hermes/blog-plans/cloudflare-blog-daily-3-plan.md

统一内容体系固定在：

/Users/william/.hermes/content-system/blog-xhs-wechat-system-2026-05-04.md

这些路径看起来只是文件夹，但对 Agent 来说非常重要。因为路径固定以后，任务就不再依赖临时记忆，而是可以按 SOP 执行：先读计划，再读已有文章，再选择未发布主题，再写到 src/content/posts/。

这也是我不建议一开始就把自动化做成“到处找文件”的原因。数字员工越稳定，越需要明确工位。人有办公桌，Agent 也应该有自己的项目路径、计划文件和输出目录。

三、Chrome：保留真实网页环境，而不是幻想所有事都走 API

很多线上操作并没有稳定开放的 API，或者 API 权限设置比网页操作更复杂。这个时候，Chrome 就变成 AI 工作台里非常关键的一层。

浏览器的价值不只是“打开网页”，而是提供真实用户看到的环境：

• 页面标题是否正常；
• 图片是否真的加载；
• 文章排版是否断裂；
• 部署后的站点是否还是旧缓存；
• 是否遇到登录、验证码或权限提示。

对博客发布来说，构建通过只能说明代码层面没错；浏览器看到正常，才说明用户体验层面基本过关。

万象片场的发布流程里，我会让 Agent 检查首页、归档页和具体文章页，不只看命令行输出。尤其是封面图，最好在浏览器里确认 complete、naturalWidth、naturalHeight，避免出现“构建成功但页面空图”的情况。

四、脚本和命令：把重复动作变成固定按钮

AI Agent 最适合接管的，不是高风险决策，而是低风险、重复、可验证的动作。脚本和命令就是这些动作的按钮。

比如博客项目里，核心命令非常固定：

npm run dev -- --host 127.0.0.1 --port 4321
npm run build
npm run deploy
git status --short
git add <file>
git commit -m "Add post about <topic>"
git push

这些命令的好处是结果清楚：成功就是成功，失败会给出日志。Agent 不需要猜测，只需要按顺序执行，并在失败时停止修复。

这里有一个关键原则：不要让 Agent 在没检查的情况下连续执行高影响动作。

比如正确流程应该是：

写文章
  ↓
本地预览检查
  ↓
构建通过
  ↓
部署
  ↓
线上验证
  ↓
Git 提交推送

而不是：

写文章
  ↓
直接部署
  ↓
希望一切正常

数字员工要像一个可靠助理，而不是一个冲动脚本。

五、Cloudflare：把内容资产快速发布到公开网络

Cloudflare Pages 在这套工作台里的角色，是把本地内容资产变成公开页面。

对个人内容系统来说，发布速度很重要。因为一篇文章如果长期停留在本地，就只是草稿；上线以后，才会进入搜索、链接、复用和跨平台分发的循环。

但部署也不能变成盲目上传。所以我给发布流程设置了两个门槛：

1. npm run build 必须通过；
2. 部署后必须验证生产 URL。

对于万象片场来说，博客不是一次性展示页，而是长期主资产库。每一篇文章上线后，都可能被后续小红书切片、公众号周报、资源包、服务页引用。因此 Cloudflare 的价值不只是托管网页，而是让内容系统有一个稳定公开的“仓库入口”。

六、GitHub：让每次自动化都有历史记录

如果没有 GitHub，自动发布很容易变成一堆不可追踪的本地修改。哪天文章顺序错了、字段写坏了、样式被改坏了，就很难知道是哪一次任务造成的。

所以 GitHub 在我的工作台里承担三件事：

• 记录每次新增或修改了哪些文件；
• 给自动化任务留下提交信息；
• 必要时可以回滚到稳定版本。

我更倾向于让每篇文章都有明确提交，例如：

Add post about local AI workbench

这样半年后回看仓库历史，也能看出内容系统是如何一步步搭起来的。

七、普通人搭建本机 AI 工作台的最小清单

如果你也想搭一套类似的系统，不需要一开始追求全自动。我建议先准备这个最小版本：

• 一个固定项目目录：放博客、脚本或内容资产；
• 一个固定计划文件：写清楚栏目、主题、发布节奏；
• 一个本地预览命令：能在浏览器里检查结果；
• 一个构建命令：确保上线前不破坏项目；
• 一个部署目标：Cloudflare Pages、Vercel 或其他静态托管；
• 一个 Git 仓库：记录每次自动化的改动；
• 一条权限边界：遇到登录、验证码、付款、删除、改资料必须停下来。

这套清单不华丽，但很实用。它能把 AI 从“聊天助手”变成“有工位、有流程、有交付标准的数字员工”。

结尾：工作台越清楚，Agent 越像员工

我现在越来越觉得，AI 自动化的核心不是让模型替人做所有判断，而是给它一个足够清楚的工作环境：知道文件在哪里，知道命令怎么跑，知道什么结果算通过，知道哪些边界不能碰。

这就是万象片场继续建设博客自动发布系统的原因。每一篇文章既是内容资产，也是一次工作流测试：Mac、Chrome、脚本、Cloudflare 和 GitHub 是否能稳定协作，决定了数字员工能不能长期上岗。

下一步，我会继续把这套工作台拆成更具体的 SOP：如何设计一个可靠的 AI 定时任务，让它在检查、执行、验证和复盘之间形成闭环。