Atelier · 造物间

把真实域名写进代码

Fri, 13 Nov 2026 00:00:00 GMT

从「清单」到「默认值」

上一轮我把 M7 需要的东西列成了一张待提供清单，每一项都写清「怎么获取」。这一轮用户一次性补齐：子域名前缀和 Pages 项目名都用 website、Cal.com 预约链接、 Cloudflare Pages 已按推荐 A 方案连通 GitHub 仓库、本机代理端口 3067。清单上的 ⬜ 该变成代码里的默认值了。

一处改动，五个地方生效

astro.config.mjs 的 site 改成读 process.env.PUBLIC_SITE_URL，默认 https://website.85138175.xyz。这一处同时决定 canonical、sitemap、OG、RSS、JSON Feed 的绝对地址——所以改完不用到处找硬编码。顺手把 Seo.astro、privacy.astro、 robots.txt、作品 url、.env.example 里的占位域名 atelier.example.com 全清掉。

这里有个不显眼的坑：vite 在项目根不可解析（pnpm 严格隔离），所以不能用 loadEnv；而且 config 在 Vite 加载 .env 之前执行，本来也读不到 import.meta.env。用 process.env 是唯一正确的选择。

三个「看起来没问题」的地方

微信号不是 URL。 contact_channels 原本强制 {label, url}，组件渲染成 <a href>。把 dianfeng1998 塞进去会造出一条死链。改成支持 value 纯文本字段、用 <code> 展示；也刻意不加「一键复制」按钮——那需要客户端 JS，会破坏首屏零脚本 (E7) 这个从 M1 守到现在的约束。取舍要明说，不是偷懒。

CSP 的「首方」必须和 site 同源。 csp-check.mjs 的 originOf() 原来拿占位域名当 base 解析绝对 URL。产物里一旦出现指向真实域名的链接，就会被误判成外域、写进 form-action / script-src 白名单——一个静默放宽的策略。给两个 CSP 脚本加 SELF_ORIGIN，和 site 用同一个环境变量，首方相对/绝对 URL 才都归类正确。

冒烟测试要能发现「域名没换」。 给 deploy-smoke.mjs 加一条 robots.txt 断言，检查它指向 website.85138175.xyz 的 sitemap。否则这类回归只能靠人眼。

首推前的全链复验

pnpm run quality（build + CSP + check 61 files 0/0/0 + E4 三条 + 24 单测 + CI 自检 23 项）、pnpm run quality:browser（LCP 1004ms / Lighthouse 100×4 / axe 0 / Playwright 7 / 拔动态层 5 页可读）、pnpm deploy:smoke（11 页 + feed + sitemap + robots + 真 CSP 头）全绿。产物审计确认 canonical/OG/RSS/Feed/sitemap 都是真实域名、无占位残留，/contact 有真实邮箱、微信、预约链接且微信无死链。

清单文档与近况页也同步成 ✅。接下来就是把它推到远端、触发 GitHub Actions 与 Cloudflare Pages 的首次真实构建——那是另一个「纸上通过」与「真跑过」的差距，等它真的绿了再说。

第一次上线与回滚演练

Fri, 13 Nov 2026 00:00:00 GMT

今天做到了哪一步

站点终于真的上线了，不是「CI 全绿」意义上的绿，而是自定义域名 https://website.85138175.xyz 打开就是完整的 11 个页面、RSS、JSON Feed、 sitemap 和站内搜索。这一步之前有一道坎：Cloudflare Pages 没配构建命令时，会把整个仓库源码当静态站发布却照样报 “Deploy successful”，是远端冒烟 deploy:smoke:remote 把它揪出来的。配好 pnpm build + dist + PNPM_VERSION=11.28.5、重新触发构建后，线上冒烟才转成 PASS / failed:0。

为什么专门发一条日志

「发布→回滚→再发布」演练需要一个人眼能分辨的信号来证明平台确实切了产物，而不是又一轮「按钮变绿」。所以这条日志本身就是那枚哨兵：

它出现在日志页 /log/、RSS <item>、JSON Feed items、sitemap 和 Pagefind 索引里；
回滚到上一份部署后，它应当全部消失（回到发布前的产物）；
再发布后，它应当全部回来。

每一步都用同一条 deploy:smoke:remote 加一次「这条日志在不在」的定点检查做裁判。如果回滚后它还在，说明回滚没生效，演练不算通过。

演练里让我踏实的一点

回滚之所以可以是「指一下上一份静态产物」这么轻，是因为整个 R1 的读路径是全静态的：没有数据库、没有会话、没有服务端渲染。表单、预约、分析这些动态层就算短暂抖动，首页、作品、日志、能力页仍然完整可读——M5 的 test:nodynamic 早就把第三方域名全指向不可达地址验证过一次了。架构上少一个耦合，运维上就少一个要一起回滚的东西。

还没闭环的

回滚按钮在 Cloudflare 后台，只能由账号本人在 Deployments → All deployments → 目标部署的三点菜单 → Rollback to this deployment 里点：本项目走 Git 集成、刻意不放 API Token 给自动化。演练完成后，这条日志会留在站上，算 M8 首批真实内容的第一条。邮件送达（需要真实表单端点）、5 人 3 秒测试都还等真人来做。

绿灯不等于上线

Fri, 13 Nov 2026 00:00:00 GMT

今天做到了哪一步

把代码首推到 zjc99999/website 之后，第一次在 GitHub 托管 runner 上把整套门禁真跑了一遍。第一次 4 个 job 里红了 1 个：audit 的「确认没有密钥被提交」。查下来不是站点漏了密钥，而是 sk_live_ 这条规则太宽，把一篇创作日志里「提到这条正则」的正文也扫成了密钥。更麻烦的是本地 pnpm verify:ci 当时却是全绿——不是因为干净，而是 Windows 下 git 默认 core.quotepath，中文文件名被八进制转义，existsSync 找不到就静默跳过，等于什么都没测。

一处假红、一处假绿，方向相反，病根相同：规则和执行各写了两份，谁也不保证对方在测什么。所以没有给两边各打补丁，而是收敛成 scripts/secret-scan.mjs 一个引擎：规则收紧到 sk_live_ 后面必须跟 20 个以上字母数字（这样规则文本自己不会匹配自己，也就不需要白名单）， git ls-files -z 配 core.quotepath=false 拿真实文件名，再断言「确实扫到了文件」「没有静默跳过」「ci.yml 引用了同一个脚本」。故意把一条真密钥探针塞进 tracked 的 README，它红了；拿出来，它绿了。第二次 push run 43395389553 4/4 全绿。

但绿灯没把站点送上线

Cloudflare Pages 的 check-run 也是绿的：「✅ Deploy successful!」。直到跑 deploy:smoke:remote https://website-1tq.pages.dev 才看见另一幅景象： 11 个核心页全部 404，/package.json 却返回 200，/index.html 404，RSS、JSON Feed、 sitemap、Pagefind 全 404，连 /robots.txt 都是 Cloudflare 自己的默认文案。

也就是说：平台把整个 Git 仓库根目录当静态站发布了。根因在项目没配构建命令/输出目录—— CF 的规则是「没有 build command 就把仓库根当静态资源上传，退出码 0 即成功」，所以一个没跑过 pnpm build 的部署照样能报绿。顺带还纠正了一个推断：平台分配域是 website-1tq.pages.dev（带随机后缀），不是清单里写的 website.pages.dev，后者实测 522 不存在。

记下来的三条

CI 全绿 ≠ 线上产物正确。 CI 只能保证 dist/ 造得对；平台按什么目录发布、用哪个 pnpm 版本，是另一层配置。消费端冒烟才是唯一裁判，平台按钮的绿不能当验收签字。
假测试往往成对出现。 一边把说明文字当密钥（假红），一边因文件名转义啥也没扫（假绿）。与其修两个现象，不如问「这个断言到底测到了什么」——然后让它自己证明扫过文件、规则不自匹配。
默认值要按平台文档来，不按本机来。 CF Build image v3 默认 pnpm 10.11.1，不认 packageManager 字段，要在后台显式设 PNPM_VERSION=11.28.5；Node 22.23.4 恰好够 astro 用，不用另设。这些都不是能从本机 pnpm run quality 里推出来的。

还没闭环的

CF 后台的 Build command / 输出目录 / PNPM_VERSION 要用户本人去配，配完重新部署，远端冒烟才会从 FAIL 转 PASS；之后才是自定义域名 CNAME、HTTPS、发布→回滚→再发布演练、国内与第三方实测、作者真实收到通知、5 人 3 秒测试。今天先把「绿灯不等于上线」这件事写进演练文档和近况里，等远端冒烟真的全绿了，再回头把这句话划掉。

给首屏定了一条硬性预算

Thu, 12 Nov 2026 00:00:00 GMT

「简洁、一目了然」不能只当形容词，得变成能验收的数字。

首屏（不滚动）只允许：身份一句话、价值主张一句话、最多 3 张作品卡、1 个主 CTA、1 个次 CTA、导航不超过 5 项。禁止长段落、技能标签云、全量日志列表、动效轮播、第三方聊天挂件、cookie 横幅。

配套性能预算：首屏 JS ≤50KB、LCP <1.5s、CLS <0.1、Lighthouse ≥95。

验收方式是找 5 个人做「3 秒测试」——看 3 秒后能不能说清我是谁、做什么、能帮他什么、下一步点哪，至少 4 个人说得出才算过。

前台 15 个页面落地了

Thu, 12 Nov 2026 00:00:00 GMT

今天把 M3 做完了：15 个静态页面、8 个组件、3 个 lib 模块，pnpm build / check / test:rules 全绿，全站 15 个页面都是零 <script>。

过程中有个值得记下的修正：规划书里原本假定 Astro 的 reference() 会校验「证据指向的条目是否真实存在」。写了个探针把 product_id 指向一个不存在的 id，astro build 居然照样通过——说明它只管类型，不管存在性。于是加了一层 src/lib/evidence.ts，在构建期逐条解析每条能力的 evidence_ids，目标不存在就直接抛错中断构建，并补了第三条自动化回归用例。

这件事的教训是：「看起来被框架保证了」和「真的被保证了」之间，差一次故意写错的探针。证据链是这个产品的立身之本，不能只靠约定。

脚手架跑通了

Thu, 12 Nov 2026 00:00:00 GMT

今天把最小工程立起来了：

pnpm install → 295 个包，零 peer 冲突；
pnpm build → output: "static"，dist/index.html 1554 B，零客户端 JS；
pnpm check → 0 errors / 0 warnings / 0 hints；
--frozen-lockfile → 可复现。

一个小坑：Astro 7 把 compressHTML 默认值从 true 改成了 'jsx'，会吞掉行内元素之间的空格。中文文案里行内链接多，显式设回 true 才稳。

另一个坑：TypeScript latest 已经到 7.0.2，但 @astrojs/check 的 peer 只接受 ^5 || ^6，所以锁死 6.0.3，不跟 latest。

为什么先做纯静态

Thu, 12 Nov 2026 00:00:00 GMT

独立开发者最怕的不是功能少，是运维把自己拖垮。

所以这次把系统切成两半：读路径全静态（Git 里的 MDX → 构建成 HTML → CDN），写路径才动态（订阅、联系表单）。这样一来：

没有数据库、没有会话、没有运行时依赖，部署就是传一堆 HTML；
第三方表单服务、邮件服务、分析服务即使全挂，访客照样能看完整个网站；
内容与代码同仓，git push 就是发布，版本史就是备份。

代价是「在线后台编辑」得等到真有第二个人要写内容时再做。这个代价现在完全付得起。

把手工验证变成一条命令

Thu, 12 Nov 2026 00:00:00 GMT

为什么做这一步

前几步的验证有一个共同问题：它们都是「我跑过一次，当时是绿的」。 E4 三条硬校验、Slow 4G 下的 LCP、Pagefind 能不能搜到、拔掉动态层后 5 个页面可读、表单字段有没有带来源——这些散落在十几个脚本里，靠人记得按顺序跑。一旦换了机器、或者有人改了 src/pages/search.astro 里那段内联脚本，之前的「绿」就悄悄失效了，而没人会知道。

M6 要解决的不是「再测一遍」，而是让「测过」这件事本身可复现、且断了会报警。

落地了什么

两条链：pnpm run quality（构建 + CSP 生成 + check + E4 三条 + 24 个单测 + 链自检）， pnpm run quality:browser（性能/搜索/线索/不变量 + Playwright + Lighthouse + axe）。本地和 .github/workflows/ci.yml 跑的是同一组脚本，CI 不另搞一套只在 CI 里绿的断言。
补上 M4 欠的账：之前只有 CDP 自测 LCP，不是 Lighthouse 分数。这一步用本机真实 Chrome 跑 Lighthouse 13，四类分数都是 100（门槛 95），G2 才算真的闭环。
严格 CSP 从产物反推：审计 18 个 HTML 后确认只有 /search 一个内联脚本，于是 script-src 只放行 'self' + 一个 sha256 + 'wasm-unsafe-eval'，不放 unsafe-inline。本地服务器和 Playwright 把 CSP 作为真实 HTTP 响应头发出，测的是与托管平台一致的行为。

又一次「假测试」的教训

这一步修掉的 bug 里，绝大多数不在站点代码，而在测试自己：

verify-ci.mjs 初版用字符串包含判断「回归脚本有没有进链」，把经 test 间接进入的 test:rules/test:unit 误报成孤立 → 改成 BFS 可达性。
Playwright 首跑 4 条红：主 CTA 在首屏和次级区各出现一次（设计如此）、 CSP 断言误伤了 style-src 里明确放开的 unsafe-inline、中文 slug 被浏览器百分号编码。
axe 首跑倒是真的抓到 2 处站点缺陷：作品/日志列表页 h1 下面直接是 h3，跳过了 h2。这是 M6 唯一改到生产代码的修复（卡片标题支持 headingLevel）。

还有一个不大但会咬人的发现：pnpm ci 是 pnpm 内建的 clean-install 命令，会静默遮蔽 package.json 里的同名脚本。所以门禁改叫 quality，不叫 ci。

故意写坏一次

CI 的 DoD 要求「故意破坏一条 schema 时 CI 必须红」。我没有只写一个断言，而是真的往 src/content/capabilities/ 塞了一条 evidence_ids: [] 的内容： pnpm build 退出码 1、错误可读；删掉后退出码 0。因为 quality 链里包含真实 build，把违规内容提交进仓库时 CI 也必然红。

「测试通过了」和「测试真的测了」之间，差的往往是一次故意写坏的探针。这句话 M3 写过一次，M5 又写过一次，M6 再写一次——它值得重复。

把动态层拔掉，站还站得住吗

Thu, 12 Nov 2026 00:00:00 GMT

为什么要做这一步

概要设计里写了一条不变量：即使动态层全部宕机，网站（读）仍完整可用。这句话很容易写成口号——因为默认情况下我们根本没配表单端点、没配统计脚本，页面当然能打开，但那只是「碰巧没依赖」，不是「被验证过没有依赖」。

M5 的做法是反过来的：构建时故意把在线表单、预约外链、Umami 脚本全部指向一个不可达域名 （offline-dynamic.invalid），再用 Chrome 的 Network.setBlockedURLs 真正拦掉它们，然后依次打开首页、作品列表、日志列表、作品详情、一条中文 slug 的日志详情。

实测结果

5 个页面全部有标题、有正文、有导航、图片没坏；首方资源零失败；第三方脚本被拦了 7 次（blockedReason: "inspector"）。也就是说：表单/预约/统计全断，读者依然能完整认识我、读到作品和创作记录。

一个比站点 bug 更值得记的教训

这个回归脚本第一次跑是 FAIL，但站点一行代码都不用改——坏的是测试自己：

探针环境变量漏了 PUBLIC_ 前缀，Vite 根本没把它们内联进产物，动态层压根没启用，测试却准备宣称「拔掉动态层后一切正常」。这是最危险的一种假通过。
本地静态服务器没有模拟托管平台的 clean URL，详情页 404。
中文 slug 在 location.href 里被百分号编码，而传入的 URL 是 Unicode，等待条件永远不成立。
把「正文 > 200 字」当可读性下限，结果把本来就很短的作品列表页（162 字）判成坏页。

修完这 6 处，脚本才真正测到了它想测的东西。 「测试通过了」和「测试真的测了」之间，差的往往就是一次故意写坏的探针。 这与 M3 那次 reference() 探针是同一个道理，只是这次翻车的是测试代码本身。

还有一件没闭环的事

pnpm test:lead 证明了：订阅和联系表单会带着邮箱、同意、来源留痕被完整 POST 到端点，浏览器能拿到回执，而且即使端点打不开，页面上仍留着邮件兜底链接。但「作者真的收到邮件/通知」属于外部送达，得等部署时配上真实端点、人工提交一次才算数。脚本不冒充这一步，规划书里也把它单列成了待办。

让搜索引擎和阅读器读懂这个站

Thu, 12 Nov 2026 00:00:00 GMT

前台 16 个页面已经能看，但一个只给人看的站还不够。这一步把它接到机器能消费的通道上：RSS 2.0（带全文 content:encoded）、JSON Feed 1.1、canonical / OG / JSON-LD、sitemap，以及一个完全静态的站内搜索。

几个没有想当然的地方：

先读源码再写端点。@astrojs/rss 的 site 会经 createCanonicalURL 补尾斜杠， pubDate 必须传 Date；Astro 的内容条目自带 rendered.html，所以 RSS 能给全文，不必自己重渲染。JSON Feed 官网取不到，就按 1.1 结构手写，不赌记忆。
搜索不引入服务端。Pagefind 在 astro:build:done 钩子里扫 dist/ 生成静态索引，搜索页按需懒加载 UI 脚本——首页依然是 0 KB 可执行 JS。UI 的构造参数是从压缩产物里反推出来的，所以又写了一个真实浏览器回归：输入「静态」返回 8 条结果。
性能不靠感觉。用 Chrome DevTools Protocol 模拟 Slow 4G + CPU×4 实测： LCP 972ms、CLS 0、TBT 0、首屏 JS 0KB。脚本明确写了「这不是 Lighthouse」，分数留到 M6 的 CI 固化。

一个诚实的坑：pnpm test 之前指向还没装的 vitest，一直是个哑弹；嵌套脚本里 npm_execpath 又不透传，硬校验回归会找不到 pnpm。最后改成直接调用 node_modules/astro/bin/astro.mjs，不依赖包管理器，回归才真正跑通。

教训和上次 reference() 那次是同一条：「配置写上了」不等于「真的生效了」，能写探针就写探针，能在浏览器里点一下就点一下。

让门禁在任何机器上都能跑

Thu, 12 Nov 2026 00:00:00 GMT

一条自己骗自己的 CI

M6 收尾时我列了四项诚实留白，其中最刺眼的是这条：.github/workflows/ci.yml 里写着 NODE: D:\Ai\dsh-data\...\node.exe、PNPM: ...\pnpm.mjs、 CHROME_PATH: C:\Program Files\Google\Chrome\Application\chrome.exe，注释还一本正经地说「Windows runner 因为本机 Chrome 和 DSH bundled Node 都在这里」。

这些路径只在这台开发机上存在。GitHub 托管 runner 上既没有 D:\Ai\dsh-data，也没有 C:\Program Files\Google\Chrome；& $env:NODE $env:PNPM ... 的 PowerShell 写法更是在 Linux 上直接不存在。本地两条链全绿、23 项 CI 自检全绿，但那检查的是「脚本链没断」，不是「这份 workflow 真的能在远端跑起来」。全绿 ≠ 真绿，和 M3 那次 reference() 探针是同一类问题，只是这次骗的是部署而不是证据链。

这轮做了什么

用户选了「先做不依赖账号的准备」，所以我没有碰任何域名或平台账号，只修工程：

把 16 处 Windows 硬编码 Chrome 收敛成 scripts/find-chrome.mjs 一个探测器：显式 CHROME_PATH/PW_CHROME 覆盖 → 三平台常见绝对路径 → PATH 扫描。关键是惰性：serve.mjs 会 import cdp-harness.mjs 却从不启动浏览器，顶层抛错会连本地预览都起不来。
.npmrc 里 storeDir=D:\.pnpm-store 删掉。Linux 上这会被当成一个字面目录名； pnpm v11 自己会选同卷 store，真要固定就用环境变量或 --store-dir，不写进仓库。
ci.yml 整篇重写：ubuntu-latest + pnpm/action-setup@v4 + actions/setup-node@v4， browser job 用 node scripts/find-chrome.mjs 把探测结果写进 $GITHUB_ENV。部署 job 刻意不加——没有账号时把它塞进 CI 只会制造第二种假绿。
新增 docs/部署与回滚演练.md 和 scripts/deploy-smoke.mjs：本地托管 dist/ 验 11 页 / feed / sitemap / Pagefind / 真 CSP 头，远端模式对线上 URL 跑同一套消费端检查，发布→回滚→再发布有签字表。

又踩到两次「假测试」

verify-ci.mjs 的密钥 hygiene 检查突然红了：M6 把 ci.yml 和脚本自身提交进仓库后，它们自己就含有 sk_live_|AKIA... 那条检测正则，被自己扫中。这不是站点有密钥，是检测器照到了镜子。修法是把两个检测器文件列入白名单、改检查项名， ci.yml 的 audit job 同步排除。

另一次是 YAML 自检：想用 pwsh -c/node -e 内联解析，分别被引号吞掉、 require('yaml') 在 pnpm 严格隔离下不可解析、Python 没有 yaml 模块。最后还是写独立 .mjs 引 node_modules/.pnpm/yaml@2.8.3 才通过。「复杂 JS 一律独立 .mjs」这条纪律，这轮又替我省了一次自我怀疑。

仍然没有做的事

没有真部署，没有 GitHub Actions 托管 runner 首跑——这两件都等 ⑤域名 / ⑥联系方式 / ⑧远端仓库 / ⑨平台账号。
没有验证表单外部送达、DNS 邮件记录、国内可访问性。deploy-smoke 在远端模式里连 CSP 响应头都只记录不判失败（不同平台对 _headers 的映射不一样），因为这些必须真人按演练文档核对，脚本不冒充。

M6 把手工验证变成一条命令；M7 准备则把那条命令从「只在我这台机器上成立」搬到了「任何装了 Node 24 和 Chrome 的机器上成立」。剩下的，就是等一个真实的域名。

Atelier / 造物间

Thu, 12 Nov 2026 00:00:00 GMT

一个先自用、以作品为证据、以创作过程建立信任的独立开发者主页