适合谁
- 用 Markdown 驱动静态内容站的人
- 初期没有复杂后台的网站
- 普通人和小团队
- 造物栈这种“先内容、后系统”的项目
- 想把发布流程整理成可重复步骤的人
- 希望每次发布都有明确检查清单的人
Method
本地发布流程：从草稿到可公开资产的最后一步
普通人做 AI 内容站，不需要一开始就上复杂后台。先学会把 Markdown、frontmatter、构建检查和本地预览串起来，就能稳定发布高质量页面。
方法解决什么问题
很多人做内容站会卡在：文件放得乱、frontmatter 不规范、slug 和 tags 不统一、build 前不检查、页面本地不预览、以为“写完 Markdown”就等于“可以发布”、发布后才发现链接、SEO、结构、样式有问题。本地发布流程不是多此一举，而是把内容从“草稿”变成“可公开资产”的最后一道稳定环节。
不适合谁
- 已经有大型 CMS 团队后台的人
- 需要实时数据库发布的人
- 需要复杂多角色审核流的人
- 已经接入大规模自动化内容流水线的人
- 不关心发布质量、只想一键上线的人
本地发布的六个步骤
-
第 1 步：确认内容类型
先确认当前要发布的是正式文章、模板详情页、方法页还是避坑笔记，因为它们的路径、字段、关联方式不同。不同内容类型在 Astro 内容集合中的行为和构建结果也不同，必须先明确发布对象，再做后续操作。
-
第 2 步：整理文件与 frontmatter
确保标题 title、description、slug、tags、日期 date、分类等字段完整，命名规范统一。frontmatter 是静态站点最重要的元数据层，缺失字段会导致 SEO、sitemap、标签索引和页面间关联出现空白或断裂。
-
第 3 步：检查关联关系
确认新页面与模板库、方法页、文章页、标签页之间的跳转是否合理，避免出现孤立页面。同时检查相关模板链接、相关方法链接和相关内容链接是否都指向正确的已有页面。
-
第 4 步：本地 build 检查
运行 npm run build，确认没有报错、没有错误路径、没有无意暴露的页面、没有占位域名（如 example.com）残留。构建日志是发现隐藏问题的最快方式，不要跳过。
-
第 5 步：本地预览页面
至少检查页面可访问、标题描述正常、SEO 基础正常（title、description、canonical、og:image、twitter:image）、导航正常、相关链接正常。用浏览器打开本地构建产物逐个确认，而不是只依赖 dev 模式。
-
第 6 步：记录发布状态
把本次发布写入 PROJECT_STATUS 或项目进度记录，方便后续继续维护。好的发布记录会告诉未来的你和协作者：这次改了什么、新增了什么、构建结果如何、是否有遗留问题。
一个真实场景示例
以造物栈新增一个公开方法页为例，完整的本地发布流程是这样走通的：
- 确认这是公开方法页，路径应为 /methods/xxx/，使用 MethodDetailPage 组件；
- 检查 frontmatter 或组件 props：title、description、slug、canonicalPath、flowStep 等字段完整；
- 检查关联关系：相关模板链接、相关方法链接、标签跳转是否正常；
- 运行 npm run build，确认构建通过、页面数量正确、无误报；
- 本地打开构建产物，检查页面可访问、标题描述正常、SEO meta 输出正确；
- 在 PROJECT_STATUS.md 中追加本次发布记录。
走完这 6 步，新页面才能在确保不出错的情况下成为站点正式页面。
本地发布前最低检查清单
每次发布前，快速过一遍以下清单：
-
文件路径是否正确
页面文件是否放在了正确的目录（如 posts/、methods/、templates/），文件名和文件夹命名是否符合项目规范。
-
slug 是否正确
slug 是否与文件名一致、是否在站点中唯一、是否使用了规范的命名格式（小写英文连字符）。
-
tags 是否合理
tags 是否反映内容主题、是否与已有标签体系一致、是否避免了过于宽泛或无意义的标签。
-
title / description 是否完整
title 是否准确概括页面主题，description 是否简洁描述页面价值和覆盖范围，两者是否都适合在搜索结果中显示。
-
是否误改其它页面
检查 git diff 或改动范围，确认本次修改没有意外触碰禁止范围或影响其它正常页面。
-
build 是否通过
npm run build 是否无报错完成，构建日志中是否有 warning 或 error 需要处理。
-
sitemap 是否正常
sitemap URL 数量是否正确增加、是否仍使用正式域名、是否不包含 example.com 或占位文案。
-
本地页面是否可访问
新页面在本地构建产物中是否可通过预期路径访问，页面渲染是否正常。
-
是否有 test / 占位 / 残留内容
确认页面中没有 example.com、占位文案、测试内容、「待补充」标记等未完成的残留内容。
-
是否已写入 PROJECT_STATUS
是否已在 PROJECT_STATUS.md 中记录了本次发布的内容摘要、构建结果和关键检查项。
本地发布的基本发布对象
以下类型的内容在发布前都需要走本地发布流程：
公开页面
- 正式文章（posts）
- 模板详情页（templates）
- 方法页（methods）
- 避坑笔记（notes）
- 栏目页补充内容（cases、tools 等）
静态资源
- OG 分享图等静态资源
- favicon、robots.txt 等站点级文件
内部文档（仅内部记录，不公开）
- PROJECT_STATUS 项目进度记录
- 内部规划文档（docs/ 目录）
- Codex 协作记录
常见错误
跳过关键步骤
- 内容写完就直接算“完成”，不做任何检查
- 没有 frontmatter 或字段严重缺失
- slug 和文件名不一致
- tags 乱写或不加标签
构建与预览缺失
- 不跑 npm run build，依赖 dev 模式判断
- 不做本地预览，直接推上线
- 改了公开页面却不更新 PROJECT_STATUS
内容污染与边界不清
- 把内部文档误当公开页面发布
- 没有清理测试内容、备份页面、占位域名
- 把 AI 工具完整输出直接当作正式文章发布
常见错误
- 内容写完就直接算“完成”，不做检查
- 没有 frontmatter 或字段缺失
- slug 和文件名不一致，导致链接断裂
- tags 乱写或不加标签，导致索引页空白
- 不跑 npm run build，依赖 dev 模式判断
- 不做本地预览，直接推上线后发现页面异常
- 改了公开页面却不更新 PROJECT_STATUS
- 把内部文档误当公开页面发布
- 没有清理测试内容、备份页面或占位域名
可复制使用方式
- 确认当前要发布的内容类型（文章 / 模板 / 方法 / 笔记 / 栏目页）
- 整理文件路径和 frontmatter（title、description、slug、tags、date）
- 检查关联关系（模板链接、方法链接、标签跳转、栏目索引）
- 运行 npm run build，确认构建通过、页面数量正确、无 error
- 本地打开构建产物，逐一检查新页面 SEO、内容、链接
- 在 PROJECT_STATUS.md 中追加本次发布记录
相关模板
相关内容
使用路径 · 第 6 / 8 步
这套方法在流程中的位置
你现在看到的是造物栈 AI 项目实战流程的第 6 步： 本地发布流程。在本地完成文件整理、构建检查和发布前确认。
- 1 工具雷达四问
- 2 绿色 / 黄色 / 红色任务分级
- 3 Codex 协作流程
- 4 项目状态检查
- 5 内容生产流程
- 6 本地发布流程
- 7 GitHub 提交与部署准备流程
- 8 上线后检查流程
下一步怎么用
从确认内容类型开始，走完整理、关联检查、build、预览和状态记录，就是一个完整的本地发布闭环。先从一个页面开始完整走一遍，再考虑批量发布。不要一开始就追求自动化流水线。