# cloudbadge云徽章

**Repository Path**: elfbobo_admin_admin/cloudbadge

## Basic Information

- **Project Name**: cloudbadge云徽章
- **Description**: CloudBadge 是一个数字徽章管理平台——组织用它来创建、颁发、管理"能力徽章"，个人用它来收集、展示自己的学习成就。就像游戏里拿成就勋章，但是严肃版的，遵循国际标准 Open Badges 3.0。
- **Primary Language**: Java
- **License**: AGPL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2026-05-18
- **Last Updated**: 2026-05-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

CloudBadge 云徽章服务系统
综合工程手册 v3.1 — 从蓝图到代码的全景视角

技术栈：Quarkus + nop-entropy + PostgreSQL + GraphQL
规范：Open Badges 3.0
更新：2026-05-15
目录
项目全景速览（给新人看的 5 分钟导览）
架构设计与技术决策（为什么选这些技术）
数据模型全貌（11 张表和它们的关系）
业务逻辑规则（大白话版功能说明书）
Phase 实际进度（做了什么、没做什么）
前端体系（AMIS 管理台 + 参考前端 + 小程序）
API 约定与接入指南（怎么和后端通信）
权限与多租户（谁能干什么、数据怎么隔离）
部署与运维（Docker、数据库迁移、CI/CD）
风险与后续规划（坑在哪、下一步干什么）
1
项目全景速览
一句话说明
CloudBadge 是一个数字徽章管理平台——组织用它来创建、颁发、管理"能力徽章"，个人用它来收集、展示自己的学习成就。就像游戏里拿成就勋章，但是严肃版的，遵循国际标准 Open Badges 3.0。
系统怎么运转？（打个比方）
想象一个电子版的 Scouts 童子军体系：

发行者（Issuer）— 像一个"认证机构"或"学校"，有权颁发徽章。比如某大学、某培训公司。
徽章类（BadgeClass）— 像一本"徽章手册"，描述一个成就的标准。比如"Python 高级开发"这个徽章需要完成哪些任务。
颁发断言（Assertion）— 像一张"证书"，证明张三在 2026 年 5 月 15 日拿到了"Python 高级开发"徽章。
证据（Evidence）— 像证书附件，比如代码仓库链接、项目截图、考试分数。
用户（UserProfile）— 领徽章的人，有自己的徽章墙、星币余额、签到记录。
技术栈一览
层	技术	为什么选它
后端框架	Quarkus 3.35 + nop-entropy 2.0	nop-entropy 自动生成 CRUD 代码，省 80% 手写量；Quarkus 启动快
数据规范	Open Badges 3.0 (W3C VC)	国际通用标准，徽章可在不同平台间互认
数据库	PostgreSQL 15+	原生 JSONB 支持能力维度、对齐标准等扩展字段
API 协议	GraphQL + REST (/r/ 转换层)	前端灵活按需取字段；/r/ 路径为小程序提供 REST 兼容
管理后台	AMIS (百度低代码前端)	写 JSON 配置就能生成 CRUD 页面
参考前端	React 19 + Vite 7 + Tailwind + shadcn/ui	app/ 目录下的独立前端，10 页面，作为 UI 参考
小程序	Taro 4 + React + TypeScript	一套代码编译到微信小程序 + H5
多租户	共享数据库 + tenant_id	一套系统服务多个机构，数据逻辑隔离
项目目录结构
cloudbadge-parent/ ← Java 后端主工程 ├── cloudbadge-common/ ← 公共工具（OB3/常量/工具类） ├── cloudbadge-issuer/ ← 发行者管理（api/dao/service/web） ├── cloudbadge-badge/ ← 徽章类管理（api/dao/service/web） ├── cloudbadge-assertion/ ← 签发 + 证据（api/dao/service/web） ├── cloudbadge-tenant/ ← 租户管理（api/dao/service/web） ├── cloudbadge-user/ ← 用户/积分/签到/通知（api/dao/service/web） ├── cloudbadge-web/ ← 聚合层 + AMIS + GraphQL ├── cloudbadge-app/ ← 主应用入口（生产部署打包） ├── cloudbadge-codegen/ ← 代码生成辅助工程 └── cloudbadge-miniapp/ ← Taro 小程序（Phase3） app/ ← React 参考前端（独立工程，Kimi OAuth + tRPC + MySQL） ├── src/pages/ ← 10 个页面组件 ├── api/ ← tRPC 路由（参考，非生产） └── db/ ← Drizzle ORM schema（参考） deploy/ ← SQL 迁移脚本 + Docker 配置 nop-entropy/ ← nop-entropy 框架源码（本地安装）
2
架构设计与技术决策
整体架构图
┌─────────────────────────────────────────────────────────────────┐ │ 客户端层 │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ AMIS 管理后台 │ │ React 前端 │ │ Taro 小程序/H5 │ │ │ │ (JSON 驱动) │ │ (app/ 参考) │ │ (cloudbadge-miniapp)│ │ │ └──────┬───────┘ └──────┬───────┘ └──────────┬───────────┘ │ ├─────────┼─────────────────┼─────────────────────┼──────────────┤ │ │ Open Badges 3.0 协议层 │ │ │ │ (JSON-LD + VC Data Model v2.0) │ │ ├─────────┼─────────────────────┬───────────────────┼──────────────┤ │ │ GraphQL API + nop-auth + nop-tenant │ │ │ │ /graphql | /r/BizObject__method │ │ ├─────────┼─────────────────────┴───────────────────┼──────────────┤ │ │ BizModel 业务逻辑层 │ │ │ ┌──────▼─────────┐ ┌──────────────┐ ┌───────────▼────────────┐ │ │ │ IssuerBiz │ │ BadgeBiz │ │ AssertionBiz │ │ │ │ TenantBiz │ │ UserBiz │ │ AggregateBiz (15方法) │ │ │ └────────────────┘ └──────────────┘ └────────────────────────┘ │ ├────────────────────────────────────────────────────────────────┤ │ nop-orm + PostgreSQL │ │ Excel/DSL 模型 → Entity + DAO → EQL 查询 → JSONB 扩展 │ └────────────────────────────────────────────────────────────────┘
核心设计理念
可逆计算公式
CloudBadge = Delta ×-extends nop-entropy<BusinessModel>
意思是：云徽章 = 对 nop-entropy 平台的差量定制，不修改平台源码。所有业务逻辑写在 BizModel 和 Delta 文件里，升级平台时零冲突。
10 个关键技术决策
决策	选择	理由（大白话）
后端框架	Quarkus	启动快（亚秒级），nop-entropy 官方推荐
低代码平台	nop-entropy	Excel 定义数据模型 → 自动生成 Entity/GraphQL/AMIS，省大量手写代码
管理后台	AMIS	写 JSON 配置就出页面，不用写 Vue/React 代码
数据库	PostgreSQL	JSONB 天然适合存"能力维度"这种半结构化数据
API	GraphQL	前端按需取字段，避免"取了一大堆不要的数据"
多租户	tenant_id 逻辑隔离	一张表存所有机构的数据，用 tenant_id 区分
OB3 合规	严格	遵循国际标准，徽章可在不同平台间互认互通
模块拆分	5 领域模块	按业务领域拆：发行者/徽章/签发/租户/用户
认证方式	nop-entropy 内置	POST /r/LoginApi__login，JWT Token
前端参考	React + Tailwind	app/ 目录做 UI 参考和原型验证，不直接用于生产
Maven 模块职责
cloudbadge-common
公共工具包。OB3 序列化/验证/JSON-LD 构建、常量定义、字典文件。

cloudbadge-issuer
发行者管理。CBIssuer 的 CRUD、注册、公钥上传、状态管理。

cloudbadge-badge
徽章模板管理。CBBadgeClass 的 CRUD、发布/归档、能力维度配置。

cloudbadge-assertion
徽章签发 + 证据管理。核心业务：颁发、吊销、能力聚合、证据提交。

cloudbadge-tenant
租户管理。开通/配置/功能开关/主题/能力框架。

cloudbadge-user
用户体系。注册、角色、星币、签到、任务进度、通知、收藏。

cloudbadge-web
聚合层。AMIS 页面、GraphQL Schema、跨模块聚合 BizModel。

cloudbadge-app
生产部署包。Quarkus 入口、application.yaml、Dockerfile。

3
数据模型全貌
大白话
数据库里有 11 张表，分两批建的：第一批（Phase1）6 张核心表，第二批（Phase2）5 张扩展表。所有表都有 tenant_id 字段做租户隔离。
Phase1 核心表（6 张）
表名	大白话	关键字段
cb_issuer	发行者档案	name, url, email, image, publicKey, status(active/archived)
cb_badge_class	徽章模板	name, description, image, criteriaNarrative, abilityModel(JSON), alignment(JSON), tags, status(draft/published/archived)
cb_assertion	颁发断言（证书）	badgeId, issuerId, recipientUserId, issuanceDate, abilityModel(JSON), evidence(JSON), proof(JSON), status(valid/revoked/expired)
cb_evidence	证据附件	assertionId, name, narrative, media(JSON), approvalStatus(pending/approved/rejected)
cb_tenant	租户配置	tenantName, theme(JSON), abilityFramework(JSON), featureToggles(JSON), aiConfig(JSON)
cb_user_profile	用户扩展	userId, role(user/observer/group_leader/super_admin), avatarUrl, badgeCount, starCoinBalance
Phase2 扩展表（5 张）
表名	大白话	关键字段
cb_star_coin	星币流水账	userId, amount, type(earn/spend), reason, badgeId(opt)
cb_check_in	签到记录	userId, checkInDate, consecutiveDays, starCoinEarned
cb_task_progress	任务进度	userId, badgeId, progressPercent, status(not_started/in_progress/completed)
cb_favorite	收藏夹	userId, badgeId
cb_notification	通知消息	userId, type(5种), title, content, isRead, relatedId(opt)
待补充字段（V3 迁移脚本，尚未执行）
注意
以下字段已在业务设计中确认，但尚未写入 Flyway 迁移脚本，需要新建 V3__ 补充：
cb_badge_class 新增: allowDuplicate(Boolean), requireApproval(Boolean), starCoinReward(Long)
cb_assertion 新增: approvalStatus(String: pending/approved/rejected), approvedBy(String), approvedAt(DateTime)
表关系图
CBIssuer (发行者) ──1:N──> CBBadgeClass (徽章模板) │ │ │ │ └────────────┐ ┌─────┘ │ │ CBAssertion (颁发断言) │ ├── 1:N ──> CBEvidence (证据) │ CBUserProfile ──> NopAuthUser (平台内置) │ CBTenant (租户配置) ── 扩展表 ── CBUserProfile ──1:N──> CBStarCoin (星币流水) CBUserProfile ──1:N──> CBCheckIn (签到记录) CBUserProfile ──1:N──> CBTaskProgress (任务进度) CBUserProfile ──1:N──> CBFavorite (收藏) CBUserProfile ──1:N──> CBNotification (通知)
字典枚举一览
字典名	值
issuer_status	active（启用）、archived（归档）
badge_status	draft（草稿）、published（已发布）、archived（归档）
assertion_status	valid（有效）、revoked（已吊销）、expired（已过期）
evidence_approval	pending（待审核）、approved（已通过）、rejected（已拒绝）
cloudbadge_role	user（用户）、observer（观察者）、group_leader（组长）、super_admin（超管）
tenant_status	active（活跃）、archived（归档）
star_coin_type	earn（赚取）、spend（消费）
task_progress_status	not_started、in_progress、completed
notification_type	badge_earned、task_update、check_in_success、badge_revoked、star_coin_change
4
业务逻辑规则（大白话版功能说明书）
徽章生命周期
一个徽章从无到有经历这些阶段：

草稿(draft) ──发布──> 已发布(published) ──归档──> 归档(archived) │ ├── 管理员手动颁发 ──> CBAssertion(证书) └── 系统自动颁发 ──> 任务进度100%触发 │ 有效(valid) ──> 已吊销(revoked) ──> 已过期(expired)
徽章授予规则
谁来发？
管理员手动颁发 + 系统自动触发（任务完成 / 签到奖励等）。
部分徽章需要审批（由 requireApproval 字段控制）。

能重复发吗？
由徽章类的 allowDuplicate 字段控制。
true = 同一个人可以拿多次（比如"月度之星"每月一次）。
false = 拿过就不能再拿。

审批流程
如果 requireApproval = true，颁发后进入 pending 状态，管理员审批后变 approved。暂时未实现。

星币体系（游戏化激励）
大白话：星币就是平台里的"游戏金币"。做好事赚币，攒够了花币换奖励。

场景	金额	说明
获得徽章	每枚 10 星币	可由徽章类 starCoinReward 覆盖默认值
每日签到	10 星币	连续 1-6 天每天 10 个
连续签到 7 天	额外 50 星币	第 7 天总共拿 60 个
任务完成	按配置	与徽章类关联
消费	不定	兑换徽章 / 解锁展示效果（Phase3）
连锁反应
签到 → 赚星币 → 更新用户余额 → 发通知 → 更新徽章计数（如果签到关联了徽章）
签到规则
每人每天只能签 1 次，无补签
昨天签了今天签 = 连续天数 +1
断了 = 连续天数归零重新计
签到后自动发星币 + 发通知
任务体系
每个徽章可以通过 task_definition（JSON 字段）关联一个任务。任务进度 0% → 100%，达到 100% 时自动触发颁发。

两种任务并行：

徽章关联任务：完成这个任务就能拿对应徽章
独立成长任务：不关联特定徽章，完成后奖励星币
通知系统
类型	触发时机
badge_earned	颁发徽章成功
task_update	任务进度更新
check_in_success	签到成功
badge_revoked	徽章被吊销
star_coin_change	星币变动
能力画像
每个徽章的 abilityModel（JSONB）定义了若干能力维度（如"编程"、"设计"、"沟通"），每个维度有分数。用户获得多个徽章后，系统自动聚合为"能力画像"。

怎么聚合？
同一维度的分数取最高值。比如"编程"维度的 3 个徽章分别得了 60、80、90 分，最终显示 90 分。参照国家/行业标准映射（如 1+X 证书），存储在 alignment 字段。
5
Phase 实际进度
总进度：约 70%
（Phase2 基本完成，Phase3 进行中，测试和部署待启动）
Phase1 — 环境搭建与模型设计
100%
条目	状态	产出
架构设计文档	完成	CloudBadge-Architecture-Design.md（1608 行）
Maven 模块骨架	完成	8 个子模块
ORM 数据模型	完成	app.orm.xml（6 张核心表）
字典文件	完成	6 个 YAML 字典
Entity 类	完成	_gen 基类 + 手动扩展类
Phase2 — 核心业务功能
85%
#	条目	状态	说明
1	数据模型补全	完成	V2 Flyway 迁移 + 5 张新表 DDL
2	BizModel 补全	完成	7 个 BizModel 有实质实现（47 个方法）
3	OB3 合规	完成	Serializer / Verifier / JsonLdBuilder / Constants
4	GraphQL Schema	完成	cloudbadge.graphqls 完整定义
5	AMIS 管理后台	完成	14 个 JSON 页面（3 层级：超管/租户/用户）
6	RBAC 权限	存在	XML 配置文件已创建，内容未经完整验证
7	v2.0 业务功能	完成	聚合层 + BatchLoad + 跨模块联动
8	部署与集成	完成	Docker Compose / Flyway / CI-CD 骨架
BizModel 实现详情
BizModel	模块	方法数	状态	遗留 TODO
CBIssuerBizModel	issuer-service	5	完整	无
CBBadgeClassBizModel	badge-service	4	完整	无
CBAssertionBizModel	assertion-service	9	实现	revoke/跨模块需验证
CBEvidenceBizModel	assertion-service	6	实现	submit 跨模块需验证
CBTenantBizModel	tenant-service	5	完整	无
CBUserProfileBizModel	user-service	8	完整	无
CloudBadgeAggregateBizModel	web	15	完整	无
Phase3 — 前端与测试
25%
#	条目	状态	说明
1	小程序骨架	完成	Taro 4 + React + TS，6 个页面框架
2	小程序页面内容	存在	页面已创建，但内容完整度未经审查
3	参考前端 app/	完成	10 个页面完整实现（React + shadcn/ui），UI 参考
4	前端提示词	完成	CLOUDBADGE-FRONTEND-PROMPT.md 可用于其他 AI 平台
5	单元测试	未开始	全项目 0 测试覆盖
6	联调与集成测试	未开始	后端 + 前端联调
7	上线部署	未开始	生产环境部署
已解决的关键问题
问题	解决时间	处理方式
双模块冲突	2026-05-15	删除旧版 cloud-badge-* 模块
垃圾文件残留	2026-05-15	删除 io/ 残留目录
聚合层 stub	2026-05-15	完整实现 15 个聚合方法
跨模块调用	2026-05-15	BatchLoad + issue() 联动
缺失 Entity	2026-05-15	创建 5 个新版 Entity + 5 个 _gen 基类
6
前端体系
重要区分
项目里有三个前端，它们的定位完全不同，不要搞混：
AMIS 管理后台（生产用）：JSON 配置驱动，管理员用
app/ 参考前端（UI 参考）：完整的 React SPA，用于 UI 原型验证和页面需求参考
cloudbadge-miniapp（生产用）：Taro 小程序，面向终端用户
AMIS 管理后台（14 个页面）
超级管理员后台
租户管理（开通/停用）
系统配置
全局监控大屏
租户管理员后台
发行者管理（CRUD）
徽章模板管理（创建/发布/归档）
颁发管理（颁发/吊销断言）
用户管理（角色分配）
审核中心（证据审批）
用户端页面
徽章广场
我的徽章
个人资料 + 统计
我的收藏
签到中心
任务列表
app/ 参考前端（10 个页面）
注意
app/ 使用 Kimi OAuth + tRPC + MySQL 技术栈，与生产后端（nop-entropy + PostgreSQL + GraphQL）不兼容。它的价值在于 UI/UX 设计参考，不能直接对接后端。已生成 CLOUDBADGE-FRONTEND-PROMPT.md 提示词用于在其他 AI 平台生成适配版本。
页面	路由	核心功能
登录	/login	Kimi OAuth 重定向登录（参考）
仪表盘	/	4 个统计卡片 + 断言状态进度条 + 快捷操作 + 最近颁发表
徽章管理	/badges	搜索/筛选 + 3 列卡片网格 + 创建/编辑弹窗(9字段含 abilityModel) + 发布/归档/删除
发行者管理	/issuers	搜索 + 卡片网格 + 创建/编辑弹窗(6字段)
签发管理	/assertions	表格视图 + 颁发弹窗(7字段) + 吊销(含原因) + 删除
用户管理	/users	4 个统计卡 + 角色分配(下拉) + 星币/徽章计数
徽章广场	/square	Hero 区 + 搜索 + 4 列卡片网格 + 收藏(红心) + OB3 标识
我的徽章	/my-badges	能力画像(聚合进度条) + 有效徽章 + 已吊销徽章
签到	/check-in	连续天数 + 周日历 + 签到按钮 + 奖励规则卡
星币	/star-coins	余额展示 + 赚/花筛选 + 交易列表(类型图标+颜色)
通知	/notifications	5 种类型(图标+颜色) + 未读标识(蓝色左边框+"新") + 标记已读
Taro 小程序（cloudbadge-miniapp）
页面	功能	状态
徽章广场（首页）	浏览可领取徽章，搜索/筛选，3 列网格	骨架完成
徽章详情	查看要求，点击"开始任务"	骨架完成
我的徽章	已获得徽章列表（卡片/列表切换）	骨架完成
个人中心	统计面板 + 签到入口 + 设置	骨架完成
签到中心	日历 + 连续天数 + 奖励说明	骨架完成
任务详情	步骤列表 + 进度更新	骨架完成
7
API 约定与接入指南
认证方式
登录接口：

POST /r/LoginApi__login
Header: nop-tenant: 0
Body: { "principalId": "admin", "principalSecret": "123", "loginType": 1 }
Response: { "accessToken": "xxx", "refreshToken": "yyy", "userInfo": { ... } }
后续请求：

Header: Authorization: Bearer {accessToken}
Header: nop-tenant: {tenantId}
GraphQL 调用约定
命名规则：BizObject__methodName

列表返回：用 items 而非 list

分页参数：

query: {
  filter: { eq: { name: "status", value: "published" } },
  page: { pageNo: 1, pageSize: 20 },
  orderBy: { createTime: "DESC" }
}
常用 API 速查
操作	GraphQL	说明
查徽章列表	CBBadgeClass__findPage	自动生成 CRUD
查某个徽章	CBBadgeClass__get(id: "xxx")	自动生成
颁发徽章	CloudBadgeAssertion__issue	自定义 BizMutation
吊销徽章	CloudBadgeAssertion__revoke	自定义 BizMutation
能力聚合	CloudBadgeAssertion__aggregateAbility	自定义 BizQuery
用户统计	CloudBadgeAggregate__getUserStats	聚合 BizModel
签到	CBCheckInBizModel__checkIn	自定义 BizMutation
REST 兼容	POST /r/CBBadgeClass__findPage	GraphQL → REST 转换层
8
权限与多租户
RBAC 权限体系（三级门禁）
操作权限（action-auth）
大白话：能不能点这个按钮？
比如"创建徽章"按钮，只有管理员才能看到和点击。XML 配置文件定义。

字段权限（data-auth）
大白话：进门后能看到什么？
比如普通用户看别人的资料时看不到手机号。XML 配置 + xmeta 定义。

行权限（tenant_id）
大白话：只能管自己部门的事。
A 学校的管理员查"所有徽章"时，SQL 自动加 WHERE tenant_id = 'A学校'，不会看到 B 学校的数据。内置功能，无需配置。

四种角色
角色	大白话	能力范围
super_admin	平台老总	管所有租户、全局配置、能看所有数据
group_leader	机构管理员	管自己租户的一切（徽章、用户、颁发）
observer	观察者/导师	只能看，不能改（巡课用）
user	普通用户	管自己的徽章、签到、收藏、星币
权限矩阵
操作	super_admin	observer	group_leader	user
管理租户	✓	👁	✗	✗
创建/发布徽章	✓	✗	✓	✗
颁发/吊销徽章	✓	✗	✓	✗
查看徽章	✓	✓	✓	✓
管理用户	✓	✗	✓	✗
签到	✓	✗	✓	✓
查看手机号	✓	✗	✓	✗
多租户自动隔离
请求进来时，nop-entropy 从 nop-tenant Header 取到租户 ID，然后：

自动在所有 SQL 查询中加 WHERE tenant_id = '当前租户'
自动为新建实体注入 tenant_id
数据权限配置中的 @biz:tenantId 变量自动可用
结论
：业务代码里不需要手动处理租户隔离，nop-entropy 帮你搞定。只需确保 application.yaml 中 nop.tenant.enabled = true。
9
部署与运维
Docker Compose 生产配置
┌──────────────────────────────────────────────────┐ │ Nginx │ │ (反向代理 + SSL + 静态资源) │ └───────────────┬──────────────────────────────────┘ │ ┌───────────────▼──────────────────────────────────┐ │ Quarkus 应用 (Docker) │ │ ┌────────────────────────────────────────────┐ │ │ │ nop-graphql 引擎 │ │ │ │ nop-auth 权限认证 │ │ │ │ nop-tenant 多租户 │ │ │ │ CloudBadge BizModels │ │ │ └────────────────────────────────────────────┘ │ └───────────────┬──────────────────────────────────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌──────────┐ │PostgreSQL│ │ Redis │ │ OSS/COS │ │(JSONB) │ │(缓存) │ │(文件存储) │ └────────┘ └────────┘ └──────────┘
Flyway 数据库迁移
脚本	内容	状态
V1__init_core_tables.sql	6 张核心表 DDL	已创建
V2__v2_features.sql	5 张新表 + 修改旧表	已创建
V3__补充字段.sql	allowDuplicate / requireApproval / starCoinReward / approvalStatus	待创建
铁律
：迁移脚本一旦提交不要修改，只能新建 V3、V4...（像 Git commit 一样，只追加不改历史）
环境准备
工具	版本
JDK	17+
Maven	3.9.3+
PostgreSQL	15+
Node.js	20+（前端开发）
Docker	最新版（部署）
开发启动
# 1. 编译
mvn clean install -DskipTests

# 2. 运行（开发模式，热重载）
java -Dquarkus.profile=dev -jar cloudbadge-app/target/cloudbadge-app-runner.jar

# 3. 访问
# 管理后台: http://localhost:8080
# GraphQL Playground: http://localhost:8080/graphql
# 默认用户: nop / 密码: 123
10
风险与后续规划
当前风险清单
风险	级别	缓解措施
零测试覆盖	高	补单元测试 + 集成测试后再上线
RBAC 权限未完整验证	高	逐条测试权限矩阵中的每个操作
app/ 参考前端与后端不兼容	中	已生成适配版提示词，需在新前端中重写
V3 迁移脚本未创建	中	需要在联调前完成
nop-entropy 学习曲线	低	已有 7 个 BizModel 实现经验
AMIS 定制能力上限	低	复杂页面混用自定义 Vue/React 组件
后续规划
近期（Phase3 完成）
补单元测试（目标 80% 覆盖）
V3 迁移脚本（待补充字段）
小程序页面内容完善
后端 + 前端联调
生产部署 + 性能测试
中期（Phase4）
AI 任务拆解（PlanCoach）
AI 证据审核
OB3 数字签名（Ed25519）
社交分享 + 海报生成
产品级 UI 设计
远期（Phase5+）
微信登录集成
内容安全审核
成长小队功能
WebSocket 实时推送
团队数据大屏
多 AI 协作约定
重要
本项目采用多 AI Agent 协作开发模式——不同的 AI 接入同一项目并行工作。因此：

• 检查进度时需要扫描文件系统变化，不能仅依赖对话历史
• 每个 AI 生成代码前应先了解项目当前实际状态
• 修改代码时注意不要覆盖其他 AI 的工作成果
• 使用本手册作为项目状态的"单一事实来源"
CloudBadge 云徽章服务系统 — 综合工程手册 v3.1

最后更新：2026-05-15 | 技术栈：Quarkus + nop-entropy + PostgreSQL + GraphQL + Open Badges 3.0