造物栈上线复盘：从本地内容站到正式上线

造物栈终于从本地项目变成了一个可以通过正式域名访问的网站。

但这篇文章不是为了炫耀“上线成功”，也不是想把过程包装成一套轻松复制的建站教程。对我来说，这次上线更像一次完整的项目收口：从定位、内容结构、本地开发，到仓库、部署、域名、DNS 和搜索引擎，每一个环节都需要做判断，也都可能在最后一步暴露问题。

我想记录的不是“用了哪些工具”，而是一个普通人怎样借助 AI 和开源工具，把一个想法逐步推进成可访问、可维护、能继续积累的个人内容站。

一、为什么要做造物栈

造物栈不是 AI 资讯站。我没有能力，也没有兴趣每天追踪模型发布、行业融资和工具更新。

它也不是工具导航站。工具列表很容易变长，却不一定能帮助人做出选择。今天推荐十个工具，明天可能就有五个失效，剩下的也未必适合真实项目。

造物栈同样不是提示词资源库。提示词可以解决局部问题，但很难替代项目定位、任务拆解、过程验证和长期维护。

我更愿意把造物栈理解为一个记录真实项目判断与取舍的地方。

这里真正值得留下来的，是我在真实项目里做过的判断：为什么选择一条技术路线，为什么暂缓一个功能，什么方法验证过有效，什么坑已经踩过，以及一个阶段怎样才算真正收口。

代码和页面只是这些判断的载体。造物栈想长期积累的，是判断、取舍、验证、踩坑和收口本身。

二、上线前真正难的不是代码

最初我以为，做一个内容站最难的部分应该是写代码。实际推进以后才发现，代码反而是相对明确的一环。

更难的是先回答一些没有标准答案的问题：

• 造物栈到底是什么，不是什么？
• 首页应该强调工具、内容，还是背后的判断方法？
• 栏目要分到多细，哪些入口现在必须做，哪些应该延后？
• 文章有没有真实项目背景，还是只是把常见观点重新整理了一遍？
• 一个页面“能打开”以后，还要检查到什么程度才算完成？

这些问题不解决，AI 生成代码越快，项目越容易朝多个方向同时生长。

AI 的确降低了执行门槛，但也放大了决策噪声。过去可能因为不会写代码而停住，现在则可能因为能快速实现太多想法，反而失去主线。

上线阶段也一样。域名、部署、Git 仓库、DNS、sitemap、robots、搜索引擎验证，每一个环节看起来都不大，却都需要明确状态、逐项验证。任何一个“小问题”没有收口，都可能让正式上线停在最后几步。

三、这次上线经历了哪些关键步骤

造物栈最初是一个本地 Astro 静态内容站。选择静态站点并不是为了追求某种技术潮流，而是因为当前内容以文章、方法、模板和项目记录为主，不需要数据库、会员系统或复杂后台。

本地页面稳定后，项目完成了 Git 初始化和首次提交，并同步到 GitHub 仓库。代码进入仓库以后，项目才真正有了可以追踪、回退和持续部署的版本基础。

接下来先后完成了 Vercel 和 Cloudflare Pages 部署。两个平台都成功构建了网站，但“部署成功”并不等于“适合作为主站”。我还需要从实际访问、域名接入和后续维护角度继续判断。

最终，正式域名 zaowuzhan.com 绑定到了 Cloudflare Pages，DNS 也统一接入 Cloudflare。网站能通过正式域名访问以后，又继续检查了 HTTPS、www 域名、sitemap 和 robots。

搜索引擎方面，Google Search Console 完成了站点所有权验证，sitemap 提交成功；Bing Webmaster Tools 也成功读取了 sitemap。两个平台都发现了 40 个网页或 URL。

百度搜索资源平台则暂缓处理。当前站点没有备案，主站又部署在 Cloudflare Pages，短期内没有必要为了追求“平台齐全”继续增加操作。先让 Google 和 Bing 的抓取通路稳定，比同时铺开更多平台更重要。

这些步骤并不是一次顺滑完成的流水线。真正有价值的是每一步都留下状态记录，知道为什么继续、为什么暂停，以及下一次应该从哪里接着做。

四、为什么最后选择 Cloudflare Pages 作为主站

Vercel 的部署是成功的，配置和构建过程也没有明显问题。但在实际访问中，国内网络环境下的稳定性并不理想。

Cloudflare Pages 部署完成后，国内可以直接访问，正式域名接入和 DNS 管理也能放在同一个平台处理。基于当前真实访问反馈，Cloudflare Pages 更适合作为造物栈的主站。

Vercel 没有因此失去价值，它被保留为备用预览平台。以后遇到部署排查或需要对比构建结果时，仍然可以提供参考。

这不是技术信仰，也不是要判断哪个平台绝对更好。选择主站平台的标准很简单：当前用户能否稳定访问，维护路径是否清楚，出现问题时能否定位。

如果未来访问条件或项目需求改变，这个选择也可以重新评估。现在的取舍，只需要对当前阶段负责。

五、这次踩过的坑

1. Codex UI 显示目录不等于真实 shell 目录

界面里看到项目名称或工作区，不代表命令一定在预期目录执行。项目早期最容易出现的问题，就是相对路径命令落到了别的目录。

后来所有 PowerShell 命令都先显式执行：

Set-Location -LiteralPath "C:\ZaowuZhan"

再运行真正命令。这个动作看起来重复，却能避免很多目录误判。

2. GitHub push 需要终端代理

浏览器能打开 GitHub，不代表 PowerShell 中的 Git 就能正常连接。实际操作中，GitHub push 需要给终端设置本地代理 127.0.0.1:7897。

这个问题如果没有单独记录，下次很容易再次把网络失败误判成仓库或权限问题。

3. DNS 不是普通解析那么简单

域名接入不只是添加一条记录。根域名、www、代理状态、Pages 自定义域名和 Google TXT 验证记录之间都有关联。

尤其是验证成功以后，不能因为“看不懂”就删除 TXT 记录。DNS 的正确维护方式不是频繁尝试，而是明确每条记录的用途。

4. sitemap 提交成功不等于立刻收录

Google Search Console 和 Bing Webmaster Tools 都能成功读取 sitemap，也都发现了 40 个 URL 或网页。但这只说明搜索引擎已经知道这些地址，不代表它们会立刻全部进入索引。

新站需要等待抓取和评估。现在更合理的动作是按 3 天、7 天、30 天观察，而不是第二天就重写页面或反复提交。

5. 没备案时，百度先不要抱太高预期

百度不是永远不做，而是当前暂缓。没有备案、海外部署、国内访问链路等因素都会影响预期。

如果以后国内搜索流量成为明确目标，再把备案、百度站长平台、主动推送和国内访问优化作为一个独立阶段处理，会比现在匆忙接入更稳妥。

6. 页面视觉和文字宽度需要人工反复检查

构建通过只能说明代码能生成页面，不能说明页面读起来舒服。

首页标题、栏目页宽度、正文行长、卡片排列和移动端显示，都经历过多次人工检查。有些问题不是报错，而是页面看起来不协调；这类问题目前仍需要人直接打开页面判断。

六、这次真正沉淀下来的东西

这次并不只是上线了一个网站。

如果最终只留下一个能访问的页面，那么下次发布文章、修改部署或处理搜索引擎问题时，仍然要重新摸索一遍。真正有价值的是把过程变成可以复用的流程。

目前已经沉淀了几份内部文档：

• 手动发布文章 SOP：明确文章放在哪里、frontmatter 怎样填写、怎样 build、预览、生成 sitemap、提交和检查。
• 搜索引擎提交清单：记录 Google、Bing 和百度提交前需要检查的条件。
• 搜索收录 3 / 7 / 30 天观察清单：把新站收录从“每天焦虑查看”变成有时间节点的观察。
• 上线后日常维护 SOP：统一网站、GitHub、Cloudflare Pages、DNS 和搜索引擎的维护边界。

这些流程比一时的页面更重要。页面以后会修改，平台也可能更换，但判断问题、验证结果和阶段收口的方法可以继续复用。

七、接下来不急着做什么

造物栈已经上线，但这不意味着下一步要立刻增加更多功能。

当前不急着做：

• 不急着做会员。
• 不急着做后台。
• 不急着做评论。
• 不急着做 AI 客服。
• 不急着做百度。
• 不急着批量生产低质量 SEO 文章。
• 不为了搜索引擎把 URL 改成 .html。

这些功能并非永远不做，而是现在还没有足够需求证明它们值得进入主线。过早增加系统复杂度，只会提高维护成本，分散内容积累的注意力。

八、接下来真正要做什么

接下来最重要的事情，是按已经建立的 SOP 手动发布高质量文章。

内容应该继续来自真实项目复盘：做过什么判断，为什么这样选择，哪里出过问题，最后如何验证和收口。不是为了保持更新频率而更新，也不是看到某个关键词有流量就临时拼一篇文章。

与此同时，按计划观察 Google 和 Bing 的收录状态。搜索引擎数据可以提供反馈，但不应该反过来主导所有内容。

造物栈需要慢慢变成一个可复用的个人判断资产库。每一篇文章都应该让以后处理类似问题时少走一点弯路，而不是只增加一个页面数量。

九、结尾

造物栈上线不是结束，而是一个开始。

真正重要的不是网站终于能打开，而是以后每一次项目推进、每一次判断、每一次踩坑和收口，都能沉淀成以后还可以复用的资产。

当这些记录逐渐连成一套稳定的方法，造物栈才不只是一个网站，而会成为我在 AI 时代持续造物时可以依靠的个人系统。