和合伙人开始了大河集团重构信息发布机制项目的建设，经历了0.1的阶段，发现在实际开发过程中因为要解决技术问题，可能背离当初设计的业务实现路径，所以我们商量后打算重构，开始v0.2的建设。进行开发之前，基本梳理了整个项目的业务架构。

1. 确定业务结构

1.1 内容类型：

Organizations：机构信息：集团、医院及机构基础资料

Articles：新闻、科普、动态

Pages：医院介绍、科室页面、专家简介、服务指南

统一内容管理与审核

机构授权 · 内容版本 · 审核确认 · 操作记录

Publications：渠道发布：官网 API · 微信公众号 · 其他平台

1.2 用户角色及权限

1.2.1 用户角色

角色简化为四类

角色	系统标识	核心职责
系统管理员	admin	机构、用户、权限及系统配置
机构投稿员	contributor	维护本机构资料、撰写本机构内容
内容管理员	editor	编辑、审核授权机构的内容
渠道发布员	publisher	选择审核通过的内容并发布到授权渠道

1.2.2 角色权限

操作	机构投稿员	内容管理员	发布员	系统管理员
查看本机构基本信息	✅	授权机构	—	✅
更新机构基本资料	✅ 本机构可维护字段	授权机构	❌	✅
修改机构编码、层级及启停状态	❌	❌	❌	✅
创建新闻、专家简介等内容	✅ 本机构	✅ 授权机构	❌	✅
编辑未审核内容	✅ 本机构	✅ 授权机构	❌	✅
审核确认内容	❌	✅	❌	✅
修改审核状态	❌	✅ 通过受控操作	❌	✅ 通过受控操作
查看审核通过内容	✅ 本机构	✅	✅ 授权范围	✅
创建及执行渠道发布任务	❌	❌	✅	✅
查看发布结果	本机构	授权机构	✅	✅

1.3 业务流程

投稿员编写内容、提交审核

内容管理员审核通过

确认内容版本，允许对外发布

Publisher 选择渠道

集团官网 · 集团公众号 · 医院公众号

系统生成对应发布内容

官网 API / 微信图文素材 / 渠道适配数据

Publications 记录结果

发布渠道、时间、状态、外部内容 ID、URL、异常信息

其中微信公众号能否实现全自动推送，需要根据集团公众号的账号类型、接口权限和平台规则另行确认。不能简单认为所有公众号都可以通过 API 自动群发。先实现内容生成与渠道适配，再根据实际授权能力确定自动发布还是人工确认发布。

1.4 业务模型

六个核心模块：

模块	职责
Organizations	机构信息及机构归属
Users	用户认证、角色和机构授权
Media	图片、文件及媒体权限
Articles	新闻、科普、动态文章
Pages	医院介绍、科室介绍、专家简介等长期页面
Publications	已审核内容的多渠道发布与记录

角色为 admin、contributor、editor、publisher。内容状态先保持 draft 与 approved 两类，发布状态单独管理。

2. 技术基线

项目	v0.2 方案
本地项目	~/projects/dahecms
GitHub	dahecms（Private）
Node.js	24 LTS
数据库	PostgreSQL 18
数据库部署	Docker Compose
CMS	Payload CMS 3
官网前端	Astro，后续建设
数据模型	Organizations、Users、Media、Articles、Pages、Publications

开发目录暂定为：

dahecms/
├── apps/
│   ├── cms/             # Payload CMS
│   └── web/             # Astro 官网，后续建设
├── infra/
│   └── docker/
│       └── compose.yaml
├── .gitignore
└── README.md

3. 项目建设路线

阶段	建设内容	目标
01	PostgreSQL + Payload CMS	建立稳定技术底座
02	Organizations + Users	机构管理与角色权限
03	Media + Articles + Pages	统一内容管理
04	内容审核与版本记录	编辑、审核、留痕
05	Publications	多渠道发布
06	Astro 官网	对外内容展示与 SEO