让 AI 发一篇文章到网站：十分钟里它做了哪些判断

我的个人网站是 Astro 搭的（一个把 markdown 生成静态网页的工具），跑在 Cloudflare Pages 上。内容全是 git 仓库里的 markdown 文件。文章我自己写，AI 只管发布到网站。从建文件到线上能打开，十分钟。

这篇把这十分钟拆开，看它每一步在判断什么：先发到哪儿、怎么认准我的网站、构建没过先查什么、发完还要验什么，最后怎么写入记忆。

如果你也想做自己的网站，可以参考。中间它踩的那几个坑，我觉得最值得看。

一、第一次，它发错了地方

我打开平时干活用的 WorkBuddy，给它一句话：把我昨天写的文章发到网站上。

这句话里的「昨天」，得它自己去找。文章在 E 盘另一个目录里，和网站仓库不在同一个工作空间。

它先在 E 盘按修改时间筛出最近几天的 md，这一步是粗筛，node_modules 里的 readme 也会混进来，得看文件在哪个目录，把不相干的排掉。然后看目录名——我的生活目录都按「日期 + 一件事」命名，2026-10-30 给老婆的信、2026-11-01 照片、2026-11-02 心理学讲座，看一眼就知道哪个是昨天。最后打开文件读开头几行，看它是不是一篇文章的格式。

时间、目录名、格式，三条都对上了。

不到一分钟，workbuddy 给了一个链接，类似 xxx.app.workbuddy.host?sharecode=xxx 这种。页面能打开，是我写的那篇，排版也还可以。

只是这不是我想发的网站。

它不知道我的网站在哪，不知道我有域名、有仓库、有一整套自己的构建命令。用它干活就这样：优先调用手上现成的能力，直接替你做决定。你给的信息越少，它越依赖默认路径。实际上 AI 不缺能力，缺上下文。

相比个人，企业多人协作的场景更加复杂。如果想让 AI 接手一件事，要先把流程写下来。写不出来，AI 也帮不到你。

二、它怎么找到我的网站

我告诉它，不是这里，是我自己的网站。接着它做了两件事。

第一件，找记忆。 它的工具集里有一个 conversation_search，搜的是以前所有对话。它用「个人网站、域名、Astro、个人主页」这几个词去检索，翻出几条以前聊过的记录：网站大概在哪个盘、用什么搭的、文章放在哪一层。

这里有个细节值得说：Astro 这个词，它从我前一天的对话里找的。那次刚发过一篇文章，我提过网站用什么搭的。它把已经出现过的专有名词当检索词，比拿「网站」两个字去搜精准得多。要是我从没跟它提过 Astro，这一步估计也搜不到。

当然，单翻记忆也不一定能找到，因为检索出来的东西可能过期。比如我修改目录，换构建方式。

第二件，去硬盘上找。 它先列了一遍根目录：

ls -d E:/*/

然后在三层以内找所有带 .git 的目录：

find E:/ -maxdepth 3 -name ".git" -type d

找 .git 是因为网站用 git 管着，仓库根目录下一定有这个文件夹。限定三层，先不全盘搜，因为全盘搜一遍要几分钟，网站仓库层级大概率也不会很深。

只回来一个结果：E:/赚钱/site。

两条都对上，它才开始写文件。 记忆里说网站是 Astro，磁盘上那个目录里有 astro.config.mjs，两边都指到同一个路径，确定就是这儿了。

定位完之后它读了一轮文件，顺序是这样的：

astro.config.mjs                    网站是怎么配的
package.json                        构建脚本、依赖版本、部署命令
src/content.config.ts               文章字段的规则
src/lib/cats.ts                     分类有哪几个取值
src/pages/writing/[...slug].astro   文章页怎么生成

还有一步它做对了：没有直接套自己熟悉的模板，先打开一篇我以前发过的文章，照着那篇的 frontmatter 写（文章最开头那段，写着标题、日期、分类，给构建工具读的，不进正文）。照抄一份跑通的样本，没有自己从头写。

这跟人做事是一个道理，手上有个现成的样子，照着改就行。它见过的东西越多，能照着改的机会越多。

三、内容为什么放在仓库里

这个网站是给自己用的，当初只想要三样：内容要好改、不用运维、打开要快。跟内容相关的只有两处：

src/content/writing/     每篇文章一个 md
src/content.config.ts    用 zod 规定字段

加一篇新文章不用碰模板代码。astro build 每次把目录里所有 md 重新生成一遍，现在六篇，加上首页、列表页、栏目页，一共十一页，几秒钟跑完。页面地址取文件名。

没有数据库和后台，省掉备份、迁移、连接池、被拖库这些事
产物是纯静态文件，挂在 CDN 上，全球访问，不用管服务器
托管在免费额度内，一年只花域名的钱

代价是没有后台编辑器，改文章得会 git；表单提交、登录这类功能要单独接服务。它适合内容结构稳定、按周更新的网站，不适合每天几十篇的资讯网站。

数据库里的内容导出来是它自己的格式，换系统要重写一遍导入。markdown 换个编辑器照样能打开，十年后大概还行。内容要存很久，格式选错，过几年重写一遍。

页面是从 md 生成出来的，md 不在了，下次构建就没有这一页，部署上去线上也跟着消失。

构建这一步挡不住。文件都在 git 里，删错了能翻提交找回来；Cloudflare 也留着每次部署的版本，能退回去。麻烦的是改了没提交的那部分，仓库里没有，丢了没地方找。

文章涨到几百篇，全量构建会慢下来，到那时候再考虑怎么提速。现在几秒钟，不值得为它增加复杂度。

四、构建报错，AI 怎么办

命令敲下去，报错：

Node.js v22.22.2 is not supported by Astro!
Please upgrade Node.js to a supported version: ">=22.23.4"

22.22.2 不满足 22.23.4，怎么办？

它没有直接装一个新版本，先查是谁在管 Node 的版本，四步：

node -v                         当前是 22.22.2
ls ~/AppData/Roaming/nvm        有没有 nvm 在管版本，没有
which fnm                       有没有 fnm，也没有
find /c/Users/pc -maxdepth 5 -name "node.exe" -not -path "*/node_modules/*"

nvm 和 fnm 这两步是排除：都是切版本的工具，机器上有的话换一下版本就行，不用动系统。两个都没有，剩下的可能就是 PATH 上排着不止一个 node，谁靠前谁生效。

第四步把机器上所有 node.exe 列出来。C:\Program Files\nodejs 那个是 24.13.0，够用。

终端里生效的 22.22.2 排在它前面，于是改一次 PATH 顺序：

export PATH="/c/Program Files/nodejs:$PATH"

同一条构建命令再跑一遍，成功！

五、部署：只传六个文件

构建生成十一页，新的那篇放在 /writing/seven-years-of-photos/。文件名就是地址。

构建完它没有立刻发布，先在 dist 里翻那篇文章的 HTML，抠出标题、数了段落、再回列表页看收录没有。

部署前它先查了登录状态：

npx wrangler whoami

这类命令会卡在交互式登录上，先确认一遍，省得跑到一半停下来等输入。

然后一条命令发布：

npx wrangler pages deploy dist --project-name huangshuai-site

上传六个文件，另外十三个服务器上已经有了，没变，不到两秒传完。Cloudflare Pages 对比文件哈希，只传变更的部分。

以前用 FTP 覆盖，几十个文件全传一遍，传到一半断了还得重来。

传完还有一步：把这篇文章提交进仓库。部署用的是 dist，仓库里留的是 md 源文件，不提交，下次 clone 下来没有这一篇。

六、部署完，去线上验一遍

部署工具输出 Success，说的是文件传上去了，不保证域名解析、缓存、路由不出问题。

文件传上去之后它做了一件事：curl 请求那个网址，看返回码，再从返回的 HTML 里抠出标题核对。

curl -s -o /dev/null -w "%{http_code}" https://huangshuai.site/writing/seven-years-of-photos/

200。标题对得上。生活栏目列表里出现了这篇。

七、最后一步：把规则写入记忆

最后，我告诉 AI，以后我说的发布到网站，指的就是这个网站。

它把这句话写进了一个叫 MEMORY.md 的文件，用的是我的原话。后面跟着源码在哪个盘、文章放在 src/content/writing/、构建前要先把 Node 换到 24 那个、部署命令、验证方式等。

AI 是把这次发布的过程总结成了流程文档，这就是它越来越能用的原因。

AI 的上下文每轮对话重新开始。今天更正它一次，明天它照样会犯同样的错，因为新的对话里没有昨天。把更正写成文件，它下次读文件，不用再来一遍。

企业里同一回事：一个流程如果只存在某个人的脑子里，换一个人要重新教一遍。写下来，成本才降得下去。

八、花多少，适合谁

一篇文章从建文件到线上打开，十分钟。构建和部署加起来不到十秒，剩下的时间都在等对话、核字段、看结果。

钱只花在域名上，一年几十块，托管和 CDN 都在免费额度内。也不用专职运维，加文章不碰代码，改版式只动一处模板。

它适合企业官网、产品文档、个人品牌网站，长期要能打开、但不用天天改的那种。要是需要多人协作审核、细粒度权限、实时互动，它做不了，得上正经后台。

九、我在做的

我做小程序，也搭这类内容网站。上面这套是给自己搭的个人网站，不过这套流程跑通之后用到企业官网、文档网站、产品介绍页上一样可以。

如果你也想让 AI 接手一部分工作，或者发布自己的网站，可以交流一下。