开发方式 · 2026-09-06

当前开发方案

目标不是让所有网站使用同一个厂商，而是让每一层只做自己擅长的事：GitHub 保存源码，云端 CI 做验收，Preview 只在需要时花资源，Production 保持简单，MacBook 留给 Remote Desktop、SSH 和日常工作。

四条共同规则

GitHub = 源码 SSOT

代码、配置、PR 和可审计历史都从 GitHub 出发。

CI ≠ 部署

测试通过不等于网站已经上线；部署成功也不能替代测试。

Cloud first, Mac quiet

普通 CI 不再把 MacBook 当常驻计算服务器，也不把科研 GPU 当通用 CI fallback。

Exact head + post-merge

合并前验证当前候选，合并后再验证真正进入 main 的版本。

三个活跃网站怎么分工

BaseModel

重浏览器验收放 CircleCI

GitHub：mykcs/basemodel。CircleCI 跑 deterministic 与两个独立 Playwright shard，风险规划器决定 skip / focused / full；Vercel 负责 Preview / Production。Mac/OrbStack 只保留手动恢复。

打开 Production →

fuhuo

静态工作入口保持极轻

GitHub：mykcs/fuhuo_20260419。仓库 contract + Astro build 负责正确性；Vercel Preview exact-head opt-in，main 只有真实站点输入变化才花 Production build。Cloudflare 非 canonical。

打开 Production →

mykcs.github.io

GitHub 做稳定入口，Cloudflare 提供当前主页

源码现在保存在私有仓库 mykcs/personal-homepage。mykcs.github.io 是独立的公开兼容入口，只负责把旧链接稳定转到当前主页；现在真正提供内容并作为 canonical 的是 wangrui92.pages.dev。普通 Preview 继续用 Wrangler Direct Upload，并保持 noindex。

返回本站首页 →

一次普通改动怎么走

  1. 先判断是哪一层。 源码、CI、Preview、Production、监控是不同 failure domain。
  2. 一个 coherent branch / PR 做完。 尽量一次原子更新，减少 provider-triggering micro-commit。
  3. 先跑便宜、确定的 Gate。 结构 / 单测 / build 先于完整浏览器。
  4. 浏览器按影响范围升级。 局部改动只测局部；shared/global/CI planner 变化 fail-closed 到 full。
  5. 只有要看真实网页时才 Preview。
  6. merge 后单独确认 Production。 main CI、provider 部署状态和公开 URL 分开核。

这套方案明确不做什么

  • 不把 MacBook 做成 24×7 CI farm。
  • 不把科研 GPU 服务器当普通 CI fallback。
  • 不为了“统一”强迫三个网站使用同一个 provider。
  • 不把部署额度和 CI compute 混成一个数字。
  • 不靠删掉最终验收语义来换速度。

这是一张人类可读的开发方案投影。required checks、provider trigger、Build Watch 和额度等会变化的事实，以各仓库当前配置和 provider live state 为准。