434 lines
17 KiB
Markdown
434 lines
17 KiB
Markdown
# 慧愈科技官网｜需求审查与开发计划 V1.1
|
||
|
||
> 审查对象：`慧愈科技官网后台功能需求设计_V1.0.md`
|
||
> 审查日期：2026-08-10
|
||
> 目标：在不改变现有设计方向的前提下，补齐可开发、可上线、可回滚、可交接所需的产品与工程约束。
|
||
|
||
> 架构更新：一期已按单服务器、Vue/Nuxt、SQLite 和本地素材方案精简，实际开发以 `一期架构决策与精简开发计划_V1.2.md` 为准；本文保留完整风险审查记录。
|
||
|
||
## 1. 审查结论
|
||
|
||
V1.0 的产品方向、信息架构和前后台视觉目标基本正确，可以作为需求底稿；但目前**不建议直接进入完整功能开发**。
|
||
|
||
主要原因不是缺少页面，而是以下生产级闭环尚未定义完整：
|
||
|
||
- 草稿、审核稿和线上版本如何隔离；
|
||
- 谁可以审核、是否允许审核自己的内容；
|
||
- 一页式首页与文章/课程详情页的 URL 体系；
|
||
- 素材如何存储、生成衍生图、校验引用和回收；
|
||
- 预览、定时发布、缓存刷新和失败重试如何实现；
|
||
- 数据库、对象存储、部署、备份、回滚和监控如何验收。
|
||
|
||
这些问题需要在开发前完成补充，否则后期会集中返工数据库、权限和发布流程。
|
||
|
||
## 2. 做得正确、可以保留的部分
|
||
|
||
1. 官网定位明确：官方信息源，而不是复杂交易或课程学习平台。
|
||
2. 后台定位正确：固定模块的专用 CMS，不做通用低代码搭建器。
|
||
3. 核心数据强调单一来源，适合长期维护和 SEO。
|
||
4. 前台组件和后台预览组件复用，方向正确。
|
||
5. 草稿、审核、发布、版本和操作日志意识完整。
|
||
6. 素材引用保护、富文本安全和后端权限校验已经被列为要求。
|
||
7. 一期明确排除了支付、CRM、多租户、学习系统等高复杂度能力。
|
||
8. 前台动效克制、文字保留在 HTML、SSR/SSG 友好等要求合理。
|
||
|
||
## 3. 开工前必须修正的问题
|
||
|
||
### P0-1：项目边界和前台路由没有闭合
|
||
|
||
文档名称以“官网后台”为主，但内容实际包含前台官网、后台 CMS、API、素材服务、SEO 和发布系统。必须明确一期交付物是一个完整系统，而不只是后台页面。
|
||
|
||
建议一期前台路由：
|
||
|
||
```text
|
||
/
|
||
/luhui
|
||
/products
|
||
/products/:slug
|
||
/news
|
||
/news/:slug
|
||
/statements
|
||
/statements/:slug
|
||
/media
|
||
/team
|
||
/privacy
|
||
/terms
|
||
```
|
||
|
||
首页锚点可继续使用 `/#about`、`/#luhui` 等，但文章、课程和声明必须拥有独立、稳定、可分享、可收录的 URL。
|
||
|
||
### P0-2：发布状态模型不完整
|
||
|
||
目前的 `status` 字段无法同时表达编辑状态、审核状态和线上状态，也没有定时发布、发布失败、下线原因等信息。
|
||
|
||
建议拆分：
|
||
|
||
```text
|
||
workflow_status: draft | in_review | rejected | approved
|
||
publication_status: unpublished | scheduled | published | offline | failed
|
||
published_revision_id
|
||
scheduled_at
|
||
published_at
|
||
offline_at
|
||
reviewer_id
|
||
review_comment
|
||
```
|
||
|
||
线上页面始终读取 `published_revision_id`，编辑草稿不能直接污染线上内容。
|
||
|
||
### P0-3：审核权限需要职责分离
|
||
|
||
三种角色还不足以形成安全规则，至少补充：
|
||
|
||
- 内容管理员不能审核或发布自己提交的敏感内容；
|
||
- 审核员只能审核被授权模块；
|
||
- 发布、下线、恢复版本、修改权限属于独立权限点；
|
||
- 超级管理员操作同样记录日志；
|
||
- 首个超级管理员通过部署初始化，不开放前台注册。
|
||
|
||
必须形成“角色 × 模块 × 动作”的权限矩阵，并由 API 强制校验。
|
||
|
||
### P0-4：版本管理被错误地放在 P1
|
||
|
||
文档前面要求所有关键内容保留历史版本，后面却把版本管理列为 P1。版本数据结构会影响所有核心表，不能后补。
|
||
|
||
调整建议：
|
||
|
||
- 版本快照、发布版本指针、恢复为草稿：P0；
|
||
- 可视化字段级差异对比：P1。
|
||
|
||
### P0-5：实时预览需要定义安全边界
|
||
|
||
预览不能直接访问未发布 API，也不能复用管理员长期登录凭证。
|
||
|
||
建议：
|
||
|
||
- 前台与后台使用同一套展示组件；
|
||
- 后台生成短时、一次性或可撤销的预览令牌；
|
||
- 预览页面强制 `noindex`、禁止缓存并校验访问范围；
|
||
- PC、平板、手机预览是视口切换，不复制三套页面。
|
||
|
||
### P0-6：素材模型和存储方案不完整
|
||
|
||
`Media.url` 和 `reference_count` 不足以支持生产使用。需要补充：
|
||
|
||
- 原文件与 WebP/AVIF/缩略图等衍生文件；
|
||
- 对象存储 key，不把完整 URL 当作唯一标识；
|
||
- MIME 嗅探、扩展名白名单、文件头校验、大小与像素限制；
|
||
- SHA-256 去重；
|
||
- 图片宽高、焦点、版权来源、授权状态和 ALT；
|
||
- `media_reference` 关联表，引用次数由关系计算；
|
||
- 上传失败重试、孤儿文件清理和删除回收站；
|
||
- 对象存储和 CDN 的备份及缓存刷新策略。
|
||
|
||
### P0-7：登录错误提示存在账号枚举风险
|
||
|
||
“账号不存在”和“密码错误”分别提示会泄露账号是否存在。生产环境应对外统一提示“账号、密码或验证码错误”，详细原因仅写入安全日志。
|
||
|
||
同时补充：
|
||
|
||
- 密码使用 Argon2id 或 bcrypt；
|
||
- 管理端采用安全 Cookie 会话或明确的 Token 存储策略；
|
||
- Cookie 设置 `HttpOnly`、`Secure`、`SameSite`；
|
||
- 登录、验证码和找回密码接口限流；
|
||
- 连续失败采用指数退避或短时锁定；
|
||
- 管理员密码重置令牌短时有效且仅能使用一次；
|
||
- 二期可加入 TOTP 双因素认证。
|
||
|
||
### P0-8：部署、备份、回滚和监控缺失
|
||
|
||
文档只描述了业务功能，没有生产交付闭环。上线前必须定义：
|
||
|
||
- 开发、测试、预发布、生产环境隔离；
|
||
- 数据库迁移、上线前备份和迁移回滚方案；
|
||
- PostgreSQL 定时备份与恢复演练；
|
||
- 对象存储版本或跨区域备份策略；
|
||
- 前端、API、后台的健康检查；
|
||
- 结构化日志、错误告警、接口耗时和发布失败告警；
|
||
- 部署版本号、制品留存和一键回滚上一稳定版本；
|
||
- 密钥只通过环境变量或密钥服务注入，不进入代码仓库。
|
||
|
||
## 4. 建议在一期同时补齐的问题
|
||
|
||
### P1-1：SEO 需要稳定 URL、slug 与重定向
|
||
|
||
- Product、Article、TeamMember 增加唯一 `slug`；
|
||
- slug 修改时自动保留 301 重定向；
|
||
- 预览和后台页面禁止索引；
|
||
- Sitemap、Canonical、Open Graph、robots 和基础 JSON-LD 应属于上线 P0，而不是上线后再补；
|
||
- `Keywords` 可以保留兼容字段，但不应作为核心 SEO 工作量。
|
||
|
||
### P1-2：文章扩展字段没有进入数据模型
|
||
|
||
官方声明的编号、附件、盖章文件，以及媒体报道的媒体名称、原文 URL、媒体 Logo 等没有体现在 `Article` 模型中。
|
||
|
||
建议采用统一文章主表 + 类型扩展字段，或明确的 JSON schema；不能只写在页面需求中。
|
||
|
||
### P1-3：首页模块缺少正式数据模型
|
||
|
||
至少需要：
|
||
|
||
```text
|
||
Page
|
||
PageSection
|
||
PageRevision
|
||
Publication
|
||
Redirect
|
||
```
|
||
|
||
`PageSection` 保存模块类型、排序、显隐和结构化配置。模块配置必须按类型校验，不能存储不受约束的任意 JSON。
|
||
|
||
### P1-4：定时发布需要幂等和失败处理
|
||
|
||
必须明确：
|
||
|
||
- 同一版本重复触发不会重复发布；
|
||
- 发布任务具有唯一业务键；
|
||
- 失败后按策略重试；
|
||
- 超过阈值进入人工处理；
|
||
- 服务器统一保存 UTC，后台按 Asia/Shanghai 展示；
|
||
- 发布成功后再刷新页面缓存和 CDN。
|
||
|
||
### P1-5：富文本需要内容规范
|
||
|
||
建议选择受控块编辑器，而不是允许任意 HTML。定义允许的标题层级、图片、视频、表格、引用、按钮和 FAQ 块；服务端二次清洗，外链默认补充安全属性。
|
||
|
||
### P1-6：法律和隐私页面缺失
|
||
|
||
至少加入隐私政策、服务条款、版权说明和备案信息页面。如果“联系我们”要收集姓名、电话或微信，需要补充用户同意、数据保存期限、查看权限和删除机制。
|
||
|
||
### P1-7：前台性能指标需要可验收
|
||
|
||
将“首屏重点优化”改成明确目标：
|
||
|
||
- LCP ≤ 2.5s；
|
||
- INP ≤ 200ms；
|
||
- CLS ≤ 0.1；
|
||
- 首屏主图按设备输出合适尺寸；
|
||
- 动效支持 `prefers-reduced-motion`；
|
||
- 常见桌面和移动浏览器无横向滚动。
|
||
|
||
### P1-8：操作日志需要防止记录敏感数据
|
||
|
||
日志中的修改前后内容应过滤密码、Token、验证码和隐私字段；日志应追加写、限制修改、定义保存期限，并提供按操作人、模块、时间和对象检索。
|
||
|
||
## 5. 一期范围重排
|
||
|
||
### 一期上线必须完成（P0）
|
||
|
||
- 前台官网：首页、人物、课程/产品、文章/声明、团队、官方渠道和法律页面；
|
||
- 后台登录、账号、RBAC 权限矩阵；
|
||
- 公司、品牌、卢慧老师、课程产品、内容、团队和官方渠道管理；
|
||
- 首页固定模块管理；
|
||
- 素材上传、衍生图、引用保护和授权字段；
|
||
- 草稿、提交审核、退回、审批、发布、下线；
|
||
- 核心实体版本快照和恢复为草稿；
|
||
- 安全预览；
|
||
- 基础 SEO、Sitemap、Canonical、robots、JSON-LD；
|
||
- 操作日志；
|
||
- 数据库迁移、备份恢复、监控告警和部署回滚。
|
||
|
||
### 一期可简化
|
||
|
||
- 仪表盘只保留待办、最近更新和快捷入口；
|
||
- 不做复杂 PV/UV 报表，接入成熟统计平台；
|
||
- 版本对比先显示两个版本的完整内容，字段级差异后补；
|
||
- 素材标签和筛选做基础版；
|
||
- 首页模块只支持固定模块排序、显隐和内容编辑；
|
||
- 后台只保证桌面端 1366px 及以上，平板可浏览但不作为主要编辑设备。
|
||
|
||
### 延后到二期（P1/P2）
|
||
|
||
- 后台全局搜索；
|
||
- 复杂访问分析；
|
||
- AI 内容质量检查和外部信息监测；
|
||
- 双因素认证；
|
||
- 字段级版本差异；
|
||
- 批量复杂排版和更多自动化运营能力。
|
||
|
||
## 6. 推荐技术基线
|
||
|
||
在团队没有既定技术栈的前提下，建议采用较稳健、易交接的组合：
|
||
|
||
```text
|
||
前台官网：Nuxt + TypeScript（SSR/混合渲染）
|
||
管理后台：Vue + TypeScript
|
||
后端 API：FastAPI
|
||
数据库：PostgreSQL
|
||
对象存储：S3 兼容存储 + CDN
|
||
异步任务：按定时发布和图片处理量选择 PostgreSQL 任务表或 Redis 队列
|
||
反向代理：Nginx 或云平台托管入口
|
||
```
|
||
|
||
选择理由：前台可服务 SEO，后台与前台共用 Vue 生态，FastAPI 接口边界清晰，PostgreSQL 适合版本快照与结构化内容，对象存储适合图片和附件。
|
||
|
||
建议采用单仓库分应用组织：
|
||
|
||
```text
|
||
apps/
|
||
├── web/ # 前台官网
|
||
├── admin/ # 管理后台
|
||
└── api/ # 后端 API
|
||
packages/
|
||
├── ui/ # 品牌基础组件与设计令牌
|
||
├── contracts/ # API 契约和共享类型
|
||
└── config/ # 共享工程配置
|
||
docs/
|
||
infra/
|
||
```
|
||
|
||
不要强行让前台与后台复用所有页面组件；应复用设计令牌、内容 schema 和前台预览组件，避免把后台表单逻辑耦合进前台。
|
||
|
||
## 7. 分阶段开发计划
|
||
|
||
以下按“2 名全职开发 + 兼职设计/测试/内容负责人”估算。实际排期需要在技术栈、部署环境和内容量确认后锁定。
|
||
|
||
### 阶段 0：需求冻结与内容核验（3—5 个工作日）
|
||
|
||
交付物：
|
||
|
||
- 一期页面与路由清单；
|
||
- 权限矩阵；
|
||
- 状态机与发布流程图；
|
||
- 字段字典和内容 schema；
|
||
- 真实公司、人物、课程、渠道与法律信息清单；
|
||
- 域名、服务器、对象存储、CDN 和备案决策记录。
|
||
|
||
开工闸门：P0 问题全部有明确结论。
|
||
|
||
### 阶段 1：工程与部署基础（5—7 个工作日）
|
||
|
||
任务：
|
||
|
||
- 建立 monorepo、代码规范、提交规范和环境配置；
|
||
- 建立前台、后台、API 和数据库项目；
|
||
- 配置迁移、种子数据、CI 构建和测试；
|
||
- 建立开发、测试、预发布环境；
|
||
- 接入结构化日志、健康检查和基础错误监控；
|
||
- 完成自动备份与恢复脚本初版。
|
||
|
||
验收：全新环境可按文档一键启动，迁移可升级和回退，密钥不进入仓库。
|
||
|
||
### 阶段 2：认证、权限与发布内核（8—12 个工作日）
|
||
|
||
任务：
|
||
|
||
- 管理员、角色、权限矩阵和登录限流；
|
||
- 草稿、审核、退回、批准、发布、下线状态机；
|
||
- Revision、Publication、审计日志；
|
||
- 短时预览令牌；
|
||
- 定时发布任务、幂等、重试和失败告警。
|
||
|
||
验收：内容管理员不能绕过审核发布；审核员不能越权；恢复版本只生成草稿；重复发布不会产生错误状态。
|
||
|
||
### 阶段 3：素材中心与核心内容模型（10—15 个工作日）
|
||
|
||
任务：
|
||
|
||
- 素材上传、校验、对象存储、缩略图/WebP/AVIF；
|
||
- 素材授权、ALT、标签和引用关系；
|
||
- 公司、品牌、官方渠道；
|
||
- 卢慧老师、经历、成果、课程关联与权威链接；
|
||
- 课程产品、文章、声明、媒体报道和团队成员；
|
||
- 首页 PageSection 固定模块配置。
|
||
|
||
验收：全部核心对象具备创建、编辑、审核、版本、发布、下线和引用保护。
|
||
|
||
### 阶段 4：管理后台（10—15 个工作日）
|
||
|
||
任务：
|
||
|
||
- 登录、仪表盘；
|
||
- 首页三栏编辑与响应式预览；
|
||
- 人物、公司品牌、课程、内容、团队和渠道管理；
|
||
- 素材选择器；
|
||
- 审核中心、历史版本、日志与网站设置；
|
||
- 表单校验、自动保存、未保存离开提醒和错误恢复。
|
||
|
||
验收：运营人员不改代码即可完成一次“编辑—审核—预览—发布—下线—恢复”闭环。
|
||
|
||
### 阶段 5：官网前台与动效（10—15 个工作日）
|
||
|
||
任务：
|
||
|
||
- 建立品牌设计令牌和响应式布局；
|
||
- 完成沉浸式首页各模块；
|
||
- 完成人物、课程、内容、声明、团队和法律详情页；
|
||
- 完成导航锚点、滚动章节激活和浏览器返回；
|
||
- 完成视差、淡入、遮罩揭示、数字递增和降级动效；
|
||
- 实现图片响应式加载、懒加载和无障碍结构。
|
||
|
||
验收：与设计参考图同视口对比后通过视觉 QA；桌面、平板、手机无横向滚动，主要交互可用。
|
||
|
||
### 阶段 6：SEO、发布联动与内容迁移（6—9 个工作日）
|
||
|
||
任务：
|
||
|
||
- Sitemap、robots、Canonical、OG 和 JSON-LD；
|
||
- slug 和 301 重定向；
|
||
- 发布后缓存/CDN 刷新；
|
||
- 预览 noindex 与禁止缓存；
|
||
- 导入已核验的人物、品牌、课程、团队和官方渠道内容；
|
||
- 检查所有图片 ALT、链接、二维码和联系方式。
|
||
|
||
验收：搜索引擎可直接读取正文，结构化数据通过验证，未发布内容不可被公开访问。
|
||
|
||
### 阶段 7：系统测试与安全验收（8—12 个工作日）
|
||
|
||
任务：
|
||
|
||
- API 单元测试、权限测试和发布状态机测试；
|
||
- 前后台核心流程端到端测试；
|
||
- XSS、CSRF、越权、上传、限流和会话测试；
|
||
- 性能、Core Web Vitals、浏览器兼容和无障碍检查；
|
||
- 备份恢复、迁移回滚和应用版本回滚演练；
|
||
- 运营使用手册、部署手册和故障处理手册。
|
||
|
||
验收：P0 用例全部通过，无高危安全问题，恢复演练成功。
|
||
|
||
### 阶段 8：生产发布与观察（3—5 个工作日）
|
||
|
||
任务：
|
||
|
||
- 上线前数据库和素材备份；
|
||
- 灰度或维护窗口发布；
|
||
- 域名、HTTPS、CDN、备案和搜索引擎配置；
|
||
- 发布后冒烟测试；
|
||
- 观察错误率、接口耗时、任务队列和页面性能；
|
||
- 准备并验证回滚路径。
|
||
|
||
验收：连续观察期内无阻断问题，监控和告警有效，运营账号与权限完成交接。
|
||
|
||
## 8. 工期与人员判断
|
||
|
||
粗略工作量：**60—90 人日**，不含大量内容撰写、原始图片重制、备案等待和外部账号申请。
|
||
|
||
- 2 名有经验的全职开发，设计/测试/内容兼职配合：约 9—12 周；
|
||
- 1 名全栈开发独立完成：约 14—18 周；
|
||
- 如果一期继续保留后台全局搜索、复杂统计、字段级版本对比等能力，工期需要继续增加。
|
||
|
||
人员职责建议：
|
||
|
||
| 角色 | 主要职责 |
|
||
| --- | --- |
|
||
| 产品/内容负责人 | 需求决策、事实核验、文案、素材授权、验收签字 |
|
||
| 前端开发 | 官网、后台、动效、响应式、可访问性和视觉 QA |
|
||
| 后端开发 | 数据模型、权限、发布、素材、SEO、日志和部署接口 |
|
||
| 测试/交付 | 测试用例、安全回归、部署与恢复演练、交接文档 |
|
||
|
||
## 9. 阶段 0 需要确认的决策
|
||
|
||
1. 一期是否同时交付前台官网和后台 CMS；建议：是。
|
||
2. 课程和品牌动态是否需要独立详情页；建议：是。
|
||
3. “联系我们”只展示官方渠道，还是收集访客信息；建议一期只展示渠道，避免引入隐私数据管理。
|
||
4. 是否要求内容管理员与审核员职责分离；建议：是。
|
||
5. 前台部署采用自有服务器还是云平台；需要结合预算和运维能力确认。
|
||
6. 图片、视频和 PDF 使用哪家对象存储与 CDN。
|
||
7. 是否已有域名、ICP备案主体、公安备案、隐私政策和服务条款。
|
||
8. 技术栈是否接受 Vue/Nuxt + FastAPI + PostgreSQL。
|
||
9. 一期真实内容由谁提供、谁核验、谁最终签字。
|
||
|
||
## 10. 开发启动建议
|
||
|
||
先用 3—5 个工作日完成阶段 0，不立即搭大量页面。阶段 0 通过后，再并行启动“工程基础”“品牌设计令牌”和“内容核验”。这能把数据库、权限、发布和素材这些高返工风险提前消化掉。
|