migrated legacy_doc_id: D3-ARCH-DEPLOY-M6.4-NEXT-ROADMAP level: l3

后续待办路线图（M6.4 收官 · 后续要做的事）

本文定位

M6.3（JWT + 邮箱验证 + R2 签名下载）+ M6.4（§1 RBAC + Phase 2-1 密码改造 + Phase 2-2 ProductEntitlements 矩阵）全部闭环 ✅。本文是后续待办清单（不是已完成清单）· 列出 14 项待办 + 2 项主线 milestone · 用户随时按节奏抽取 · 不强制按顺序执行。 关联手册：m6.3-auth-system.md v1.8（含 §1-§9 完整实施记录 + §7.7.4-§7.7.15 共 15 条踩坑沉淀）。

📌 后续待办速览（一图扫完 · 详情见下方各章节）

🔥 A 档 · 业务价值高（3 项 · 共 3 工作日）

编号	事项	工时	一句话价值
A1	13 产品页接入 effective permissions（灰显未开通功能 + 开通 CTA）	2 天	商业转化漏斗 · 直接产生付费动机
A2	销售/客服 lookup 页（按 email 查授权状态 + 登录历史）	0.5 天	客服效率 · 每次咨询省 2-3 分钟
A3	用户自助查 entitlements（`/account/entitlements`）	0.5 天	减少客服咨询 · 用户自评续费需求

🛠 B 档 · 技术负债（4 项 · 共 5 工作日）

编号	事项	工时	一句话价值
B1	Resend 发件域 reputation + 邮件模板软化	0.5 天	摆脱腾讯邮箱白名单依赖（手册 §7.7.10 配套长期方案）
B2	CI/CD 自动化测试（后端 xUnit + 前端 Playwright）	3.5 天	替代人工冒烟 · 重构信心提升
B3	DB 定期清理任务（cron · 过期 refresh / entitlements）	0.5 天	DB 不会膨胀（短期不做也行）
B4	JWT Secret 轮换演练（手册 §7.5 SOP 走一遍）	0.5 天	紧急情况能快速响应

🎁 C 档 · 锦上添花（7 项 · 共 11+ 工作日 · 用户量 1000+ 时再做）

编号	事项	工时	触发条件
C1	多设备 session 管理（用户看登录设备 + 一键踢)	1.5 天	用户量大 + 安全事件触发
C2	后台审计日志（admin 操作可结构化查询）	2 天	合规审计需求触发
C3	数据导出 / 备份恢复脚本（每日 pg_dump 到 R2）	1 天	合规需求触发（先确认 VPS 是否已有快照）
C4	监控告警（Prometheus / 企微机器人）	1 天	用户量大 + 自己被动监控不够时触发
C5	SDK 多版本管理（manifest.json 动态发布）	1.5 天	单产品出第二版本时触发
C6	i18n 国际化（中英双语）	3 天	海外市场触发
C7	性能优化（Lighthouse / EF Core 慢查询）	1 天	任何时候 · 但当前用户量小性能非瓶颈

🎯 真正的下一站主线 milestone（不在本路线图 scope · 仅作展望）

系列	内容	工时	依赖
M7	产品 SDK 真实交付（替换 15 个 `/downloads` 占位）	每产品 1-3 月	M5 产品研发联动
M8	商业化（订单 + 支付 + 开票）	2-4 月	法务 + 财务 + 产品定价策略

⏱ 推荐执行顺序

时间窗口	内容	累计工时
接下来 1-2 周	A1 + A3	2.5 天
1 个月内	A2 + B1	1 天
2-3 个月内	B2 (后端集成测试部分)	2 天
何时再说	B3 + B4 + C1-C7	13+ 天

用户当前判断（2026-05-09）

M6.4 之后告一段落 · 不立即处理上述任何事项 · 本文档作为后续随机抽取的 backlog · 不是必须执行的计划。

一、A 档 · 业务价值高（建议优先 · 商业回报直接）

A1. 产品功能页接入 effective permissions（灰显未开通功能）

现状：/api/me 已返回 13 产品的 effectivePermissions.products[]（含 tier + Source + ExpiresAt）· 前端 auth.ts 的 AuthUser 接口已支持
缺：13 个产品功能页（/products/xidsp / /products/xicore / ... / /products/ximind）尚未消费这个数据 · 当前所有功能对所有用户一视同仁
要做：
1. 每个产品页顶部加"权限横幅"：free 显示"开通 Pro 解锁全部功能" · trial 显示"试用中 · X 天后到期" · pro/enterprise 隐藏横幅
2. 高级功能 UI 区块根据 tier 灰显（CSS opacity-40 pointer-events-none）+ 鼠标悬停显示"需 Pro 开通"提示
3. 底部加"联系销售开通"CTA 按钮（trial/free 显示）
预估：13 产品 × 1.5 小时 ≈ 2 个工作日（一次性投入 · 后续随产品页改版自然维护）
价值：商业转化漏斗的关键一步 · 让免费用户清晰感知"还有什么没用上" → 产生付费动机

A2. 销售/客服 lookup 页（按 email 查产品授权状态）

场景：客户来电问"我开通的什么版本 / 什么时候到期" · 客服需要 5 秒查到答案
要做：
1. 后端加 GET /api/admin/users/lookup?email=xxx 端点（按 email 模糊匹配 · 返回 user + entitlements + last login + 最近 5 次登录 IP）
2. 前端 /admin/lookup 页（搜索框 + 结果卡片 · 直接跳 /admin/users/detail?uid=N）
预估：0.5 工作日
价值：客服效率工具 · 直接节省每次客户咨询的 2-3 分钟

A3. 用户自助查看自己的 entitlements（`/account/entitlements`）

场景：用户想看"我开通的什么产品 / 什么版本 / 什么时候到期"
要做：在 /account 加一个 tab"我的产品授权" · 渲染 effectivePermissions.products[] 表格（产品名 + tier badge + 过期倒计时 + Source 标识）
预估：0.5 工作日
价值：减少客服咨询 · 也是用户自己评估"还要不要续费"的依据

二、B 档 · 技术负债（建议穿插做 · 不修会越来越痛）

B1. Resend 发件域 reputation 累积 + 邮件模板软化

背景：手册 §7.7.10 · 腾讯企业邮拦截 send.joysnd.com · 当前应急方案是 IT 加白名单 + admin 后台直接重置密码绕过邮件流
长期对策：
1. 模板软化：去【】方括号 + 删"请勿泄漏"等钓鱼词 + 加 plain text 版本 + 加 reply_to: support@joysnd.com
2. 启用 Resend 域名 reputation 监控（Dashboard → Audience → Reputation Score · 每周看一次）
3. 1-2 周后让一批真实用户在 Gmail/Outlook 标记"非垃圾" · reputation 自然提升 → 腾讯/网易反垃圾算法跟进
预估：模板改动 0.5 天 · reputation 累积无需主动工时（被动等待）
价值：解决"邮件发了但收不到"的根本问题 · 不再依赖 IT 白名单这个临时方案

B2. CI/CD 自动化测试（后端集成测试 · 前端 E2E）

现状：M6.3-M6.4 全程靠人工冒烟脚本（smoke-m6.3-prod.sh / smoke-m6.3-stage4.sh 等）· 每次发版手动跑
要做：
1. 后端：xUnit + Testcontainers（Postgres/Redis 容器）· 测 AuthController + AdminController + EntitlementsController 关键路径 · 接进 GitHub Actions
2. 前端：Playwright 跑 5 个核心流程（注册-验证-登录 / admin 创建用户 / admin 重置密码 / 用户改密码 / admin 给产品授权）· 接进 Cloudflare Pages 部署前 hook
预估：后端 2 工作日 + 前端 1.5 工作日 ≈ 3.5 工作日
价值：未来每次改动不再需要人工跑 7+ 步冒烟 · 重构信心提升 · 但短期成本不低

B3. 数据库定期清理任务（cron · 过期 refresh tokens / entitlements）

要做：
1. SQL：DELETE FROM "RefreshTokens" WHERE ("RevokedAt" IS NOT NULL AND "RevokedAt" < NOW() - INTERVAL '7 days') OR "ExpiresAt" < NOW() - INTERVAL '7 days';
2. SQL：DELETE FROM "UserProductEntitlements" WHERE "ExpiresAt" IS NOT NULL AND "ExpiresAt" < NOW() - INTERVAL '90 days';（保留 90 天审计窗口）
3. 实现：VPS crontab + bash 脚本（每周日 03:00 北京）· 或后端加 IHostedService 定时任务
预估：0.5 工作日
价值：DB 不会膨胀 · 但当前数据量小 · 几个月内不做也不会出问题

B4. JWT Secret 轮换演练（手册 §7.5 SOP 已写 · 实际未演练过）

要做：在低峰期按手册 §7.5 走一遍轮换流程 · 验证流程顺畅
预估：0.5 工作日（含演练 + 文档更新）
价值：紧急情况下（Secret 泄漏）能快速响应 · 不演练就是纸面 SOP

三、C 档 · 锦上添花（用户判定后置 · 不阻塞主线）

C1. 多设备 session 管理（`/account/sessions` 列出所有 active refresh tokens · 单独撤销）

场景：用户怀疑账号被盗 · 想看"哪些设备/IP 登录了我的账号" + 一键踢掉某台
依赖：RefreshToken 表已有 IpAddress + UserAgent 字段 · 后端只需新增 GET + DELETE 端点
预估：1.5 工作日
价值：典型互联网产品功能 · 但当前用户量不大 · 优先级低

C2. 后台审计日志（admin 操作单独表 · 可查询）

现状：admin 改 role / status / 重置密码 / 授权产品都通过 _log.LogWarning 写入 stdout · docker logs 可查 · 但不可结构化查询
要做：
1. 新建 AdminAuditLogs 表（admin uid / target uid / action / before / after / ip / ua / timestamp）
2. 后端 EntitlementsController + AdminController 关键操作前后写入
3. 加 GET /api/admin/audit-logs + 前端 /admin/audit 页面
预估：2 工作日
价值：合规 + 安全审计 · 但当前规模不强需求

C3. 数据导出 / 备份恢复脚本

要做：
1. 每日自动 pg_dump 到 R2 桶（保留 30 天滚动）
2. 一键恢复脚本（VPS 上 dropdb + createdb + restore + 重启 api）
预估：1 工作日
价值：合规 · 但 VPS provider 可能已有快照备份机制（先确认再做）

C4. 监控告警（Prometheus + Grafana / 或 Cloudflare Workers + 企微机器人）

场景：API 502 时 30 秒内推消息到企微群
要做：
1. 后端加 /health 详细版（DB/Redis/Resend 各探一次）
2. Cloudflare Worker 每分钟 ping 一次 · 异常推 webhook
预估：1 工作日
价值：被动监控 → 主动告警 · 但当前用户少 · 出问题大概率自己先发现

C5. SDK 多版本管理（资源白名单从硬编码字典改为 R2 列目录 + 版本元数据）

现状：DownloadsController.cs 白名单只有 3 项硬编码 key（whitepaper-overview / sdk-xidsp / sample-xialgo）
要做：
1. R2 加 manifest.json（每个产品 → 版本列表 → key + size + checksum + release-notes）
2. 后端动态读 manifest · 前端 /downloads 显示版本下拉
预估：1.5 工作日
价值：未来产品 SDK 多版本发布时刚需 · 当前一个产品一个版本不需要

C6. i18n 国际化（中文+英文双语）

现状：项目已有 pages/en/ 目录结构 · 但仅首页 + 几个核心页有英文版 · admin 后台 + auth 流全中文
要做：
1. auth.ts 错误码映射加英文版（用户语言切换）
2. admin 页面所有文案抽到 i18n 字典
3. Header 加语言切换按钮
预估：3 工作日（一次性投入大 · 但后续维护成本高 · 每加一个 UI 文案要双语写）
价值：海外市场拓展才用 · 国内市场单语足够

C7. 性能优化（前端 Lighthouse 分数 / 后端 EF Core 查询慢日志）

要做：
1. 前端：npm run build 后用 Lighthouse 测 5 个关键页 · LCP/CLS/FID 报告
2. 后端：开启 EF Core LogLevel.Information for Microsoft.EntityFrameworkCore.Database.Command · 找 >100ms 的 query
预估：1 工作日（不一定有问题 · 测试本身就有价值）
价值：当前用户量小 · 性能不是瓶颈 · 但提前测让未来扩张时有基线对比

四、推荐执行顺序（基于"商业 ROI / 风险 / 工时"综合判断）

阶段	内容	预估	决策建议
接下来 1-2 周	A1（产品页接 effective permissions）+ A3（用户自助看授权）	2.5 天	直接商业转化提升 · 投入产出比最高
1 个月内	A2（客服 lookup）+ B1（Resend reputation 长期对策）	1 天	减少客户运营摩擦 · 不做也行但很快会痛
2-3 个月内	B2（CI/CD 自动化测试 · 选做后端部分）	2 天	降低未来迭代风险 · 但短期不出大事
何时再说	B3 / B4 / C1-C7	累计 10+ 天	用户增长到 1000+ 时再分批做

用户当前判断

Phase 2-2 之后"基本告一段落" · M6.5 候选项都是锦上添花 · 不阻塞主营业务推进。本路线图作为后续随机抽取的 backlog · 不是必须执行的计划。

五、下一个真正的"主线 milestone"会是什么

按 site-top-architecture.md 的 5 层 13 产品架构推演 · M6 系列结束后的自然下一站应该是：

M7 系列 · 产品 SDK 真实交付（替换占位）

现状：/downloads 页 18 项中只有 3 项接入了真实 R2 下载（whitepaper-overview / sdk-xidsp / sample-xialgo）· 其余 15 项是 M5.7 占位
要做：每个产品（XiDSP / XiCore / XiAmp / ... / XiMind）真实开发 + 打包 + 上传 R2 + 打开真下载入口
预估：每个产品 1-3 个月 · 全部产品并行开发不现实 · 按用户优先级排
依赖：与 M5（产品研发）阶段联动 · 不在本 web 仓 scope 内

M8 系列 · 商业化（订单 + 支付 + 开票）

现状：当前 entitlements 矩阵纯 admin 手动开通 · 无订单系统 · 无支付链路 · 无发票
要做：接入支付（微信支付 / 支付宝 / 海外 Stripe）· 订单表 + 自动开通 entitlement · 财务对账 + 开票
预估：2-4 个月 · 是个大项目
依赖：法务（合同模板）+ 财务（收款账号）+ 产品（定价策略）

六、关键资产盘点（M6 系列收官状态）

6.1 代码资产

仓库	主要内容	M6 系列贡献
`xisound-api`	.NET 8 后端 · 鉴权 + 业务 + admin 后台	M6.1 留资 / M6.2 VPS 部署 / M6.3 Auth / M6.4 RBAC + Phase 2-1 + 2-2
`xisound-website`	Astro SSG 前端 · 营销页 + auth 流 + admin UI	M5.7 假账号 → M6.3 真 API · M6.4 admin 后台 + 用户详情
`xisound-docs`	MkDocs 静态站 · 内部文档 / 决策记录 / 踩坑总结	M6.3 主手册（v1.0 → v1.8 · 共 15 条踩坑沉淀）

6.2 部署资产

VPS：腾讯云 /opt/xisound-api · Docker Compose 4 容器（api / nginx / postgres / redis）· GitHub Actions 自动部署
CDN：Cloudflare Pages（xisound-website 自动部署）+ Cloudflare R2（资源下载 · xisound-downloads bucket）
DNS：api.joysnd.com + www.joysnd.com + joysnd.com（Cloudflare 托管）

6.3 运维工具集（M6.4 commit `23b54fb` 沉淀）

scripts/admin-promote-bootstrap.sh · admin 账号引导
scripts/deploy-m6.4-phase1.sh · 部署脚本（已被 GitHub Actions 替代）
scripts/diag-cors-preflight.sh · CORS 诊断
scripts/fix-cors-allow-methods.sh · nginx CORS 修复
scripts/set-zhangzm-password.sh · bcrypt 应急重置（已被 admin UI 替代）

6.4 知识资产（手册 §7.7 共 15 条踩坑）

M6.3 §7.7.4-§7.7.9（前 6 条 · 文件系统 / 部署 / 工具链）
M6.4 §7.7.10-§7.7.14（5 条 · 邮件 / nginx / bcrypt / CI/CD）
Phase 2-2 §7.7.15（1 条 · PowerShell [] 通配符）

每条都按"症状 / 根因 / 证据 / 解决 / 关键洞见"五段式 + commit 链接 · 是项目最有价值的"硬骨头转化文档"。

七、版本历史

版本	日期	作者	变更摘要
v1.0	2026-05-09	AlgoDepartment · Web + 架构组	首版 · M6.4 Phase 2-2 收官时建立 · 含速览 + 14 项详情 + M7/M8 主线展望 + 6 节资产盘点

**Xisound · M6.4 Next Roadmap · v1.0 · 2026-05-09** *M6.3 + M6.4 全部闭环后的后续待办清单 · A/B/C 三档 14 项 + M7/M8 主线展望 · 配套手册 [m6.3-auth-system.md v1.8](40-m6.3-auth-system.md)* © MMXXVI · Xisound AlgoDepartment