我让 AI 帮我搭建并发布了这个博客

如果说「万象片场」是一座正在搭建的 AI 内容片场，那么这个博客就是片场里的资料库、发行台和复盘墙。它不是一个临时写日记的地方，而是用来长期记录：一个人如何把 AI Agent、内容生产、自动化发布和未来变现连接成系统。

这篇文章复盘一件很具体的事：我让 AI 帮我搭建并发布了这个博客。

这里的重点不是“AI 写了一篇文章”，而是 AI 作为数字员工，能不能从项目文件、内容计划、页面检查、构建部署到 GitHub 同步，完成一条真实的发布链路。对我来说，这比单次生成一段漂亮文字更重要，因为它验证的是一个可重复的内容资产生产系统。

一、为什么先搭博客，而不是先追平台流量

很多人开始做 AI 内容时，会本能地先冲向短视频平台、小红书、公众号或者 YouTube。它们当然重要，但如果一开始只有平台流量，没有自己的主资产库，内容很容易变成一次性消耗品。

我想要的系统不是“今天发一条，明天忘一条”，而是每次实操都能沉淀成资产：

• 一次 Agent 自动化尝试，可以变成一篇流程复盘；
• 一次 AI 图片或视频测试，可以变成一篇方法笔记；
• 一套发布流程，可以逐渐整理成 SOP；
• 多篇同主题文章，未来可以组合成资源页、模板或服务案例。

博客的价值在这里：它能把零散动作变成可搜索、可引用、可持续优化的长期内容。万象片场后续做 AI 影像、原创 IP、数字员工和内容系统实验，都需要一个地方把幕后过程完整记录下来。

二、这次让 AI 做的不是写作，而是一整条发布流水线

如果只是让 AI 写一篇文章，难度并不高。真正有价值的是让它进入真实项目环境，按照明确规则完成发布。

这次博客系统采用的是 Astro + Cloudflare Pages 的静态站点方案。AI Agent 需要处理的事情包括：

1. 读取内容计划，判断今天应该写哪个主题；
2. 检查 src/content/posts 下已有文章，避免重复标题；
3. 按博客现有 frontmatter 格式创建 Markdown；
4. 写出符合「万象片场」定位的正文，而不是泛泛 AI 新闻；
5. 启动本地预览，检查首页、归档页和文章页；
6. 确认封面图、标题、摘要、排版正常；
7. 运行 npm run build，确保 Astro 构建通过；
8. 执行 Cloudflare Pages 部署；
9. 打开线上页面验证真实访问效果；
10. 提交 GitHub，留下可追踪的版本记录。

这就是我对“数字员工”的基本定义：它不是神奇地替代所有判断，而是在一个边界清楚、步骤明确、结果可验证的工作流里，稳定完成重复任务。

三、AI Agent 在这条流程里真正承担了什么角色

过去我对 AI 的使用更像“外包一个脑力片段”：让它帮我想标题、写段落、改文案。现在用 Agent 之后，它更像一个能操作工具的执行角色。

在这条博客发布链路里，Agent 至少承担了四种角色。

1. 内容编辑

它要根据内容计划选择主题，判断哪些文章已经发布过，再把新的主题写成结构化文章。这一步不只是生成文字，还要保持栏目方向一致：AI 自动化、数字员工、Agent 实战、内容资产系统。

2. 项目助理

它要知道文章应该放在哪里，文件名怎么命名，frontmatter 需要哪些字段，日期格式是否正确，标签是否符合已有风格。对静态博客来说，一个 YAML 缩进错误都可能导致构建失败，所以项目规则很重要。

3. 质检员

它不能写完就算完成。必须本地预览，检查首页是否出现新文章，归档页排序是否正常，文章页标题和封面图是否显示。构建通过只是技术层面的检查，浏览器预览才是用户视角的检查。

4. 发布员

最后它要执行部署，把站点推到 Cloudflare Pages，再打开线上地址确认页面真的可访问。发布后还要同步 GitHub，让这次内容变更有版本记录。

这四个角色合在一起，才接近一个“小型内容运营数字员工”。

四、这套系统为什么必须强调“验证”

自动化最容易让人兴奋的地方，是它可以省时间。但我现在更关心的是：它会不会稳定，会不会出错，会不会把错误放大。

所以这套博客发布流程里，验证不是可选项，而是核心环节。

至少要验证这些内容：

• 标题是否和已有文章重复；
• Markdown frontmatter 是否完整；
• 本地首页是否能看到新文章；
• 归档页排序是否合理；
• 文章详情页是否能正常打开；
• heroImage 是否加载成功；
• npm run build 是否通过；
• Cloudflare Pages 部署是否成功；
• 线上文章 URL 是否真实可访问；
• GitHub 提交后工作区是否干净。

如果没有这些检查，AI 自动发布就只是“更快地制造不确定性”。而一个可以长期使用的数字员工，必须留下可复盘的证据链：做了什么、检查了什么、哪里通过、哪里失败。

五、这次博客给我的一个重要启发

这次让我更清楚地意识到：AI 自动化真正的难点，不是某个单点能力，而是把多个环节串起来。

写文章、改文件、启动服务器、打开浏览器、运行构建、部署上线、提交 Git，这些动作单独看都不神秘。但当它们串成一条链路以后，就会出现很多真实问题：路径是否正确、命令是否失败、浏览器看到的页面是否和构建结果一致、线上缓存是否更新、Git 是否包含了无关文件。

这也是为什么我不想把万象片场做成一个只聊 AI 概念的博客。真正值得记录的是这些具体链路：

• 一个数字员工如何接收任务；
• 它如何读取上下文；
• 它如何执行并验证；
• 它在哪些地方容易失败；
• 哪些步骤可以沉淀成 SOP。

这些内容短期看可能不如热点标题刺激，但长期看更有资产价值。因为它们能变成服务案例、咨询材料、模板产品，甚至是一套完整的个人内容系统方法论。

六、普通人可以怎么复用这条思路

如果你也想让 AI 帮你搭建类似系统，我不建议一开始就追求全自动。更稳的方式是先做一条小而完整的链路。

可以按这个顺序来：

1. 先选一个固定资产库：博客、知识库、Notion、GitHub 仓库都可以；
2. 定义一种固定内容格式：比如每篇文章必须有标题、摘要、标签、正文结构、下一步；
3. 列出手动发布流程：从写作到预览、检查、发布、归档；
4. 让 AI 接管其中一小段：先从生成草稿或整理清单开始；
5. 逐步增加执行权限：允许它改文件、跑构建、打开页面；
6. 每一步都加验证：不要只看它说“完成了”，要看页面、日志和结果；
7. 把失败写下来：失败记录本身就是下一次自动化优化的素材。

数字员工不是一次配置完就永远稳定的机器，更像一个需要培训的助理。你给它的流程越清楚，它能稳定完成的工作就越多。

七、下一步：把博客发布流程产品化

这篇文章记录的是第一层：AI 帮我搭建并发布博客。接下来我会继续把这条链路拆得更细。

后面值得继续写的方向包括：

• AI Agent 能帮我做哪些真实本机任务；
• 如何设计一个可靠的 AI 定时任务；
• 浏览器登录、人机验证和权限边界为什么是自动化难点；
• 如何把博客文章拆成小红书笔记和公众号周报；
• 如何把发布流程整理成可出售的 SOP 或模板。

对万象片场来说，这个博客不是终点，而是片场的第一台稳定机器。只要这台机器能持续运转，每一次 AI 自动化实验、每一次内容生产尝试、每一次失败复盘，都有机会沉淀成未来的资产。