企业官网建设流程全解析

最近在持续整理 mss-boot-io 这个开源组织。它的核心不是“又一个 CRUD 后台”，而是尝试把一个 Go + React 的后台工程，按开源项目的方式治理起来：需求公开、PR 可审、CI 可复现、发布有环境边界，AI Agent 的记忆也要落盘。

这轮主要做了几件事。

一、让 PR 先过流水线，而不是靠感觉合并

这次把几个仓库里的未合并 PR 做了一轮清理：

mss-boot：补 release workflow 幂等、阻止新增 golangci-lint 问题、补测试/术语文档、补 config env fallback 测试。

mss-boot-admin：补本地 make test 前置条件、RBAC 术语表、language middleware fallback 单测。

mss-boot-admin-antd：收敛前端安全依赖、补前端环境矩阵、保持 Cloudflare 发布低频。

mss-boot-docs：收敛文档站依赖安全问题，并把剩余 dumi/Umi 迁移放进 RFC 轨道。

每个 PR 都先交给 GitHub Actions、CodeQL、govulncheck、docs-drift、PR Guard、OpenSSF Scorecard 等检查。检查没过就修，过了再合并。

二、让 AI Agent 记住项目约束，而不是每次从零开始

这个 workspace 是多 Git 仓库，如果只把上下文放在对话里，很容易丢。现在每个仓库有自己的 aigc 目录，组织级记忆统一落到 mss-boot-docs/aigc。

这次合并完成后，也把“哪些 PR 合并了、为什么可以合、哪些 Dependabot 失败不是主分支失败、哪些问题必须走 RFC”都写进了文档项目的记忆文件。

这对个人开发者很重要：AI 可以跑得很快，但项目边界、发布策略、社区语境必须可追溯。

三、依赖升级不等于盲目升级

有些安全告警可以通过 override、补丁或小版本升级收敛；有些则卡在框架链路上，比如 Vite / Umi / dumi / router 这类主链路迁移。

这类问题不能为了“清零告警”直接硬升。更好的做法是开 RFC issue，写清楚目标版本、迁移路径、构建兼容性、回滚策略、测试范围，以及是否影响 Cloudflare beta/prod 发布。

开源项目要对使用者负责，技术方向一致性比“表面更新”更重要。

四、前端发布要克制

后端 beta 环境可以频繁验证，但前端 Cloudflare 发布有次数和展示稳定性约束。现在的原则是：

本地开发先对接 alpha 后端。

beta/prod Cloudflare 走手动发布。

只有功能完整、冒烟通过、适合对外展示时才发布。

这也是开源项目面向外部用户时必须有的边界感。

五、欢迎社区一起 review

如果你对 Go 后台、React 管理端、GitHub Actions、开源治理或 AI Agent 协作感兴趣，欢迎参与 review。

目前更希望社区参与的不是“随手提个大功能”，而是这些更容易落地的方向：

review 现有 PR 和文档
补充可复现的 issue
拆分小范围测试
参与 RFC 讨论，比如迁移、通知 provider、手机号登录、统计能力等
帮忙找出文档里不清楚、上手困难、术语不统一的地方

项目地址：

GitHub 组织：https://github.com/mss-boot-io
后端基础库：https://github.com/mss-boot-io/mss-boot
Go 后台服务：https://github.com/mss-boot-io/mss-boot-admin
React 管理端：https://github.com/mss-boot-io/mss-boot-admin-antd
文档项目：https://github.com/mss-boot-io/mss-boot-docs

个人开发者做开源，最难的不是写代码，而是持续把项目变成别人愿意理解、愿意 review、愿意贡献的状态。AI 可以承担很多重复劳动，但判断、边界和社区信任，还是要一点点建设。