ai-web-delivery-doc/03-系统架构与领域模型.md

AI 软件交付与持续服务平台领域模型与架构候选

状态：版本 0.15，更新日期 2026-10-13。阶段 2 历史讨论仍留在后文。2026-10-13 会议对应用、组件和工单版本的修订见下一节，依据 D085、D086。架构和实施尚未定案。

2026-10-13 会议对领域基线的修订

事项	现在采用的口径
任务执行与恢复	不单独做「任务执行、版本与恢复 / 自动能力与人工接续」层。每一次工单创建一个版本，恢复使用这个版本
应用	应用指功能。邮箱应用是例子。后文把仅邮箱写成零 APP、把邮箱只写成独立服务的句子，以此节为准改读
组件	初级版本不提供 Web、API、worker 选择，按应用预设固定带上。高级版本以后用界面选择这个项目要不要组件
域名	域名是需要购买的资源，不包含在应用里

工单版本是完成后的结果版本，还是同时保留发起前版本，以及带数据恢复是否仍另选时间点，尚未说明。下文原有的两层恢复记录保留，待这次口径补全后再决定是否替代。

阶段 2 完成基线与后续交接

本节汇总最终结论，后文保留各轮论证。本阶段完成的是业务概念、主要关系和默认边界；不把尚未讨论的具体价格、期限或技术实现一并认定为已确认。

概念与关系	已确认基线
客户与项目	普通客户拥有项目，项目代表一个业务目标；仅邮箱可无 APP，项目可包含多个 APP
项目组	单层，一个项目至多归属一个组；用于整理和汇总，不改变授权、资源隔离或历史账目
应用目录与预设	同时支持单应用和组合方案，项目可继续添加 APP；软件及支持版本声明必需/可选组件和资源，无平台统一必需组件清单
APP 与部署组件	APP 是完整软件实例，Web/API/worker 等为可分别配置运行资源的组件，不与 Deployment 或副本数一一对应
项目与环境资源	同集群同环境默认同 namespace，实际名称显式绑定；数据库是独立资源，业务默认项目逻辑数据库独立，同项目 APP 可按授权共享
资源归属与引用	保存归属与使用绑定，最后引用移除前提示，采用使用中/待释放/已释放；宽限期重新引用可取消释放，执行前重查引用及操作状态
独立服务与购买记录	域名、邮箱、API 等独立选配，购买/订阅与实际开通、使用分别记录；删 APP 不自动取消独立服务，账目按实际购买项汇总，共享资源不重复收费
工单范围	一个工单只属于一个项目，可改多个 APP，跨项目分别提交；提交需求与附件保持可核对，新增/改变需求另建工单，沟通归客服/TG
发布与版本	平台保存业务主记录并关联 Git 工程记录；项目发布组合记录各 APP 的实际提交、产物、配置、结构及恢复点，工单提交版本与执行基准分别保存
回退与数据恢复	普通版本回退默认保留业务数据并检查兼容，带数据恢复另选时间点并明确影响；风险改动前建立恢复点，基础备份独立于工单
预览与正式访问	K8s 持续实例通过默认域受保护预览，工单完成直接更新；正式上线允许平台购买域名或客户自有域名绑定，默认域不得正式公开
预览地址与保护	使用独立唯一标识绑定应用端点，统一预览网关显示提示，采用所有者登录/受控分享并配合验证；未来沙盒为隔离临时实例及临时入口
项目协作与公共服务	独立项目通过明确 API 关系和授权协作；平台拥有公共应用，客户购买其 API 服务权益，分组不自动互通
计费与供应方式	持续基础服务包年，定制按原工单规则；资源支持自建与未来外部数据库/存储，供应商成本和服务加价可配置

用户的概括认可确认上述已讨论的推荐方向，包括平台工单关联 Git 工程记录和需求固定原则；没有替代尚缺的经营主体/客户地区事实，也没有自动确定三天释放期、备份保留时长、费用金额或具体供应商。

后续阶段	交接事项
阶段 3：02/05	注册购买与开通状态，付款授权和失败处理，人工金额确认，AI 转人工费用，续费/扩容/退款，释放期与备份保留，分享权限和举报处置，域名绑定/采购收费
阶段 4：03	平台单库/多库和模块责任，Git 服务与同步机制，网络和入口保护，权限及一致性，托管资源适配与数据恢复技术方案
阶段 5：迁移规划	旧项目标识与真实资源映射，旧默认域/正式域及工单记录导入，切换和回退
阶段 6：04	应用接入版本契约，多 APP 发布协调，备份/恢复演练，沙盒隔离、工作流和资源释放实现
阶段 7：06	首期范围、试点、明确验收指标、实现任务与排期

阶段 2 无需追加全面确认。当前以 02/05 核对四条业务路径，再讨论权益和费用；新业务事实允许回溯修订。以上表保存阶段 2 收口时基线，后续补充以本节为准。

阶段 3 对领域关系的补充

新事实	模型影响与尚待评审方案
普通/高级向导	同一项目/APP/资源模型的不同操作界面，不拆成两个权威业务系统
付款与开通	订单、支付及各项服务开通结果分开；支持部分完成、等待人工和异常核查
失败后修订需求再试	原工单关联不可覆盖的需求修订及执行尝试；新尝试绑定一个修订/基准/预算，真正扩大范围仍新工单
系统回执	状态、修改摘要、失败与恢复结果属于工单执行记录，不扩展为客服会话
外部工作流	推荐平台持有执行记录，第三方运行 ID/事件/查询通过适配器关联；引擎成功不能直接作为发布完成
年付与 AI 权益	年度开发/运维套餐可包含 AI 用量；充值积分、套餐包含用量与未来测试赠送独立，超额按实际成本扣充值
熟客价格政策	普通账户匹配固定项目服务费和赠送政策；中介不成为新角色层级，原订单保留规则版本
退役与再部署	退役不退年费，仅存代码/启动配置等轻量材料，释放运行/数据库/文件/相关备份；重部署初始化新业务，不恢复旧数据或计算退款差价
到期未续费	外部停服、最多一周业务数据保留、续费恢复或释放；具体代码/备份保留与资源引用保护需协调
系统外差额	首期不建退款引擎，建议订单可关联人工结算说明；不能覆盖原价或伪造自动退款结果

代码/配置归档与业务数据清理已明确，计算减配和附件隔离仍属建议。首期充值消费，初始推荐 100 积分/USD；AI 调用成功与否不改变已耗费用。测试赠送只能支持非正式部署，平台可销毁测试资源，不能影响已购正式服务。客户/价格客户组可预留例外退役结算，但首期仅启用年付不退，客户自建项目组不等同价格客户组。

上述是领域责任，不冻结表结构。包含权益、试用权益、充值账本、年度套餐和项目/资源生命周期分别表达；不能合成一个余额或“已删除”字段。原始调用、套餐抵扣、积分扣费和实际发布也不是同一结果，重复事件不得重复扣费。

阶段 4 工作流/Git 专题：比较内部执行与第三方接口，确定平台状态所有权、输入/结果契约、外部标识、事件或查询、停止/超时与恢复、重复操作保护、费用核对、Git Issue/PR/发布映射。之后再决定进程/数据库/队列和执行器，首期无需先建通用可视化工作流编辑器。

阶段 2 逐轮讨论记录

阶段 1 已形成业务基线。本阶段回答客户账号、项目、应用、服务、运行类型和资源之间的关系，先解释业务概念，再决定字段和实现；不在本轮生成数据库表或决定部署成几个服务。

第一轮：项目代表什么，核心边界已确认

已经确认以项目组织客户业务、支持仅邮箱和应用加域名邮箱、系统生成标识及资源显式绑定。本轮用户进一步确认：一个项目代表一个客户业务目标，允许同时包含多个相关应用，并搭配域名、邮箱服务。

项目是客户组织一项业务目标的长期单位，在其下管理相关应用和服务。项目可有零个、一个或多个应用：仅邮箱项目可以没有 Web 应用，官网可只有一个应用，商城与内容中心可为同一业务项目下的两个相关应用。实际资源数量由应用需求和购买配置决定，共享通过显式绑定与授权表达；默认 namespace 关系见第二轮已确认基线。

概念	当前用于讨论的含义	不应靠它推断的关系
客户账号	项目及购买记录的客户归属和操作边界	客户来源、行业或供应商账号
项目	客户组织业务、改动任务及相关服务的长期单位	一份订单、一个仓库或固定 namespace
应用目录项与版本	平台已接入的一种基础软件及具体版本，如官网模板、内容中心或开源商城	客户已经购买或实际运行的实例
应用实例	为客户运行、定制和更新的具体应用	模板的所有客户共用同一份代码或数据库
服务产品与服务实例	产品是可购买的内容，实例是客户实际开通的域名、邮箱、托管等服务	一项独立服务必须对应一个新 Web 应用
运行配置与工作负载	声明同一应用的 Web、API、worker、scheduler 等组成及运行参数	每个 worker 都需要成为独立项目或独立业务应用
资源及绑定	实际 namespace、仓库、数据库、存储和供应商目标，通过标识明确关联	名称相等、编号后缀或手工备注所暗示的关系

项目、应用目录项、客户实例和运行组件需区分。用户现已认可 APP 表示完整软件实例、Web/worker 表示部署组件的分层。Content Hub 的 API 与发布 worker 可表达为同一应用的不同组件；独立内容软件也可以作为另一 APP，不按进程或容器数量定义业务项目。

用已有场景核对第一轮

场景	已确认边界下的表达	后续细化
企业官网加域名与邮箱	官网应用绑定资源，域名邮箱独立服务和账目，项目关联工单及线上版本	无需因为买邮箱再强制建立另一个项目
仅邮箱	零个 Web 应用，无仓库或 K8s 工作负载要求	项目与服务实例具体归属规则后续核对
Content Hub API 加 worker	一个应用由正式运行配置声明多个工作负载	不以进程数量决定项目数量
商城加内容中心	可属于一个客户业务项目，各自定义运行组成、代码和数据依赖	版本、工单和服务怎样关联单个或多个应用
旧 projectxx-x 入口	保存真实资源和显式业务关联，不靠后缀识别	新入口是否为独立应用或项目后续讨论；不在此合并或改名现网资产

项目边界已确认，工单只能属于一个项目，可涉及其中多个 APP，跨项目需求分别提交工单。独立服务的使用关联和发布组成继续细化；一项业务目标不等同于一张订单、一笔订阅、一个 namespace 或一个数据库。

第二轮：应用、部署、资源计费与协作

用户补充的目标：多应用项目需要可解释的费用；Web 与采集 worker 可共享项目数据；独立项目可通过 API 协作；平台自有新闻 API 等公共应用可向多个客户提供独立收费服务；未来接入外部托管数据库和云存储；客户可按项目组整理和查询项目，并保留未来批量操作的可能。是否首期接入某一家云供应商、具体数据库数量和 API 计价单位尚未决定。

APP 与部署组件：已确认保留两个层次

APP 表示一套可安装、定制和维护的软件实例；部署组件表示其中可单独配置运行资源和副本的 Web、API、worker 等单元。一个 APP 可以有多个组件，组件各自扩容，但软件的兼容关系与版本组成仍有归属。APP 不按 Deployment 或副本数量定义，计费依照实际购买项。

不把业务 APP 与 K8s Deployment 固定一一对应。运行契约可以映射到 Deployment、StatefulSet、Job 或 CronJob 等实际工作负载；同一组件的多个副本也不等于多个客户 APP。工作负载种类和资源档位是配置，不从名字或编号推导。

层次	已认可的概念职责	例子
客户账号	拥有项目与服务购买权限	一个客户管理多项业务
项目组	单层分组，一个项目至多归属一个组，无嵌套或多组要求	“评价与内容业务”收纳评价网和内容中心
项目	长期业务与运行资源管理单位，可含多个应用和独立服务	一个站点及为其采集数据的相关应用
应用实例（APP）	一套软件的客户实例，保存基础版本及定制成果	官网、商城、内容中心
环境与部署组件	区分生产/测试等目标，描述 Web、worker 的运行组成与资源配置	Web 两副本，采集 worker 一副本
资源实例及使用绑定	数据库、缓存、卷、对象存储等实际资源；分别记录归属和使用者	Web 与 worker 显式绑定同一数据库
外部服务订阅与调用关联	接入另一项目或平台服务的授权、接口与服务权益	内容中心调用评价网 API；网站订阅新闻 API

本表形成概念基线，具体关系基数及生命周期还需核对，不是强制逐层建立菜单、数据库表或微服务。一个仅邮箱项目无需为了补齐层次而创建 APP、namespace 或数据库。

namespace、数据库和共享：默认关系与实际授权分开

namespace 管理 K8s 资源作用域，不直接决定数据库能否共享。服务可以通过包含 namespace 的 DNS 名称跨 namespace 访问；实际连通还受网络策略和数据库授权限制。同 namespace 也不会自动获得另一个应用的数据库权限。K8s 跨 namespace 服务访问

namespace 本身也不等于默认网络隔离；如需项目间限制访问，需有实际生效的网络策略及数据库、服务凭据授权。网络插件必须支持策略执行。K8s 网络策略

以下默认关系已获用户认可；具体配置覆盖与执行机制后续细化：

• 项目在某个集群的同一环境内，相关工作负载默认放在同一 namespace，符合共同管理及共享卷的需求。项目与实际 namespace 显式绑定；以后不同环境或集群有各自目标，不靠名称相等关联。
• 数据库是独立资源，项目可有零个、一个或多个逻辑数据库；模板决定默认需求。例如官网与采集 worker 默认绑定同一数据库，两个不同基础系统也可各用各的数据库，仍属于同一项目。
• 数据库部署在哪里、哪个应用可以用、费用归谁，分别记录。同项目应用按需要授权，并非全部自动获得相同权限；worker 可具有与 Web 不同的写入权限。
• 评价网与内容中心按用户指定保留为两个独立项目，各有自己的数据库和 namespace，通过 API 协作。可归入同一项目组，但不因分组自动合并数据库或授权。

数据库供应商实例与逻辑数据库需区分：一个数据库服务器或托管实例可以承载多个逻辑数据库。namespace 既不是数据库服务器，也不是逻辑数据库。共享与性能还取决于位置、网络和应用写入方式，不能仅靠相同 namespace 保证更快或数据格式兼容。

PVC 与数据库连接有不同约束：Pod 直接引用的 PVC 必须位于同一 namespace。多组件共享同一个 PVC 还需核对访问模式、后端及应用的并发写入能力；不能将“跨 namespace 能连数据库”推导成“直接引用另一 namespace 的 PVC”。K8s 持久卷与 namespace

资源计费：按实际购买项计算，项目汇总

Web 与 worker 分别需要购买的运行配置，可以分别计价，再汇总到项目；如果售卖的是覆盖整个组合的套餐，则由套餐表达包含的组件和额度。不能同时对同一配置收套餐价和全部组件价。运行配置按本轮明确的包年档位，不按实时 CPU、内存用量收费。

共享数据库、存储的费用归属于资源或其明确分配的服务份额，多个 APP 引用不会产生多份采购费用。资源的归属、使用绑定、计费归属要区分；资源成本已经包含在套餐时，不再另列同一份费用。

示例：官网 Web 配置费 + 采集 worker 配置费 + 一份共享数据库服务费 + 一份共享存储服务费。域名、邮箱、公共 API 订阅与定制工单按选配另外计算。此处解释组成，不设定具体金额、套餐和服务周期；人工、AI 定制仍是核心销售价值。详见 05 商业模式与成本指标。

外部数据库与云存储：统一管理，分别适配

目标模型应支持自建与外部托管资源，不把数据库限定为现有服务器上的 PostgreSQL，也不把存储限定为 Longhorn。应用契约声明所需引擎、版本、容量及访问能力；实际资源绑定选择可支持的供应方式。先保留能力边界，供应商与接入版本以后确定。

资源类别	怎样接入应用	需要保留的差异
自建数据库或托管数据库（RDS 类）	显式绑定连接目标、逻辑数据库与授权；应用通过网络连接	引擎与扩展、区域、版本、容量、备份和恢复能力
块存储或文件存储	兼容的存储驱动/后端提供卷，通过 PVC 挂载	节点与区域限制、访问模式、容量、快照、并发访问能力
对象存储	应用通过支持的对象接口访问 bucket 或授权范围	应用适配、对象权限、请求/容量/流量成本，不等同普通文件系统

外部托管数据库纳入平台资源目录、开通和账目，不意味着其 CPU、内存由 K8s 本地配额调度。建议记录供应商资源标识、规格、实际目标、状态、凭据引用、采购账目与客户服务归属；开通可以由供应商 API 或人工完成，不能因统一模型就承诺全部步骤自动化。

托管数据库可减少服务器维护、数据库安装、补丁和备份等工作；应用的数据结构、查询优化、连接配置及使用方式仍需团队负责。此处以官方 RDS 的责任划分解释概念，并未选定 AWS。RDS 管理与责任范围

云盘接入不能只增加供应商字段：驱动、节点/区域可用性和网络条件必须兼容现有集群。对象存储适合经应用支持的素材、上传和备份场景，不能默认无修改替代任意 PVC。K8s StorageClass 与存储后端、对象存储概念

用户提出第三方服务成本加 20% 服务费，后台可调整。独享资源可直接归属采购成本；共享供应商实例需先定义可核对的分配份额，不能向每个项目重复收取整台实例费用。第三方流量、请求和备份等浮动成本怎样对客户结算，进入阶段 3 决定，不自动改变既定计算资源档位订阅。

跨项目协作、平台公共应用和项目组

跨项目协作保存独立的 API 使用关系：提供方、使用方、接口、授权引用和依赖；不因两个项目属于同一客户或分组而自动互通。评价网加内容中心是本轮明确的两个项目协作样本；服务变化时还需知道哪些依赖方可能受影响。

平台自有新闻 API 则包含两个不同对象：平台部署和维护的应用，以及对外销售的 API 服务产品。客户购买的是订阅、权限和调用权益，并不必为每个客户复制一套新闻系统或开放新闻系统数据库。服务订阅与平台应用的成本各自记录；持续基础服务按包年方向，API 包含额度、超额或其他计量规则后续确定，不将计算配置规格直接套到 API。

客户项目组已纳入目标，先承担命名、归组、筛选和查找。建议未来可按组汇总费用；移动分组不自动搬迁 namespace、合并资源或重定价已有账目。客户整理分组、平台行业/价格政策分组、供应商账号池分配是不同用途。

未来批量操作可利用项目成员关系筛选目标，但具体操作未提出，不提前承诺批量删除、发布或扩容。以后逐项定义权限、执行范围与每个项目的成功/失败结果；分组本身不成为技术隔离边界。

用本轮场景检验候选模型

场景	组织与运行关系	费用表达
网站加持续采集 worker	一个项目；同软件可为一个 APP 多组件，独立软件可为多个 APP；显式共享数据	Web、worker 运行配置分别覆盖，共享数据库和存储不重复计费
一个项目含商城和内容应用	多个应用，可有不同数据库引擎和存储要求	各组件配置与实际购买资源合并展示到项目
评价网与内容中心协作	两个项目、各自数据库及 namespace，通过 API 对接，可放同一项目组	各自资源费归各项目；API 是否另收费按服务关系决定
平台新闻 API 提供给多个站点	平台拥有服务应用，客户项目绑定 API 订阅和授权	客户购买 API 服务，不重复承担同一平台实例的整笔资源采购
更换自建数据库为托管数据库	保留业务身份，变更资源绑定并执行数据迁移、验证和切换	按新服务规格与成本规则结算，不把更改连接地址当作完整迁移
项目分组	客户整理多个独立项目，分组不改变运行隔离	可汇总既有账目；不因加入组自动新增费用或叠加资源费

第三轮：应用目录、组合方案与运行配置

多应用项目下，需要区分业务组织、应用基础和运行组成。例如“供应链业务”表达项目用途，“Odoo 商城”表达所选应用基础，“Web 与后台 worker、数据库和存储”表达该应用的运行要求。行业、软件来源和部署组成不能全部压成一个固定项目类型字段。

已确认：目录同时支持单应用及包含多个应用的组合方案，客户可在已有项目中继续添加应用。例如先开通官网，再添加独立内容中心。组合不是固定且不可变的项目类型；它的具体默认组件、连接和配置尚需细化。

用户明确：每种应用的必需和可选资源由其预设决定，平台不存在适用于全部应用的固定组件清单。应用及版本的运行配置表达组件、资源依赖、默认值和允许的选配；组合方案引用这些配置。客户业务用途和行业分类另行记录。

应用预设样本	必需项	可选项
自有金融官网系统	Web、数据库、PVC；所提供软件包含后台和持久数据	独立域名、邮箱及该软件支持的其他能力
纯前端个人网站	交付并提供访问所需的静态产物/运行能力，无应用数据库或持久 PVC 要求	独立域名、邮箱及其支持的额外服务

“可选”不是随意关闭软件必需依赖；软件不支持的资源能力不能仅靠勾选生成。是否将某种附加能力接入目录，仍按接入契约验证。静态产物是否使用容器服务或专门静态托管方式，属于后续架构选择。

第四轮：资源存续、工单范围、预览与分组

包年服务与资源释放

用户明确持续服务采用包年，不采用随开随关的按小时模式；人工和 AI 定制仍按原工单费用规则，不变为无限次包年开发。提前删除、到期、扩容的账目与退费阶段 3 另定，资源是否还有引用与订阅是否到期分别记录。

业务默认每个项目拥有独立的逻辑数据库，不设计跨项目混用业务数据库的通常路径；同项目 APP 可按需要共享。供应商实例是否承载多个独立逻辑数据库，是物理供应层面的另一问题。

资源保存归属用户、所属项目及实际引用它的 APP/组件/环境。用户要求类似引用计数的机制：删除最后一个引用前提示将失去数据，并在客户资源管理页显示待释放状态；全部引用消失后可以延迟释放，用户举例为三天。三天是候选宽限期，后台参数和最终期限待确认。资源真正释放后不承诺原数据仍能恢复。

建议流程为“使用中 → 待释放 → 已释放”：

• 移除最后一个引用时展示将删除的数据库、卷及影响，客户确认后进入待释放。
• 宽限期内新增有效引用或撤销释放可取消倒计时；只暂停 APP、仍保留使用绑定时不应误判为零引用。
• 执行释放前重新检查实际引用及正在执行的发布/恢复等操作，避免只按一个过期计数删除资源。用户直接绕过平台的连接不属于可靠引用，应禁止作为正常使用路径。
• 项目的数据库/卷、备份及独立域名/邮箱/API 订阅分别管理；零 APP 引用不意味着自动取消独立服务。备份保留及最终清除需有明确政策，避免无引用资源无限占用空间，也避免误承诺永久可恢复。

用户在阶段收口时认可上述释放方案；具体宽限期、提示/取消入口及备份清除规则移交阶段 3。

工单范围与多个 APP 的版本组成

已确认一张工单只能修改一个项目，可同时涉及项目内多个 APP；跨项目协同分别提交工单。客户提交一次需求，内部可拆分成多个 APP 的执行任务，不要求客户为了前后端接口配套改动再分成多个工单。

建议建立“项目发布记录”：保存本次项目内各 APP 实际采用的 Git 提交、构建产物、配置及数据库结构版本。未改动的 APP 也有明确当前版本，因此一次工单可产生一个可核对的前后组合。多仓库分别保存实际提交，不假定存在覆盖全部 APP 的一个 Git 提交。

Git 记录源代码和迁移脚本，发布记录补充实际运行组成与数据恢复点。数据库内容、上传文件、密钥和客户数据不写入 Git。恢复项目历史组合时检查共享数据及 APP 兼容关系；单独恢复一个 APP 只在兼容时提供。工单提交时与实际执行时的版本仍分别保存。

多 APP 发布可以内部协调、记录部分成功并执行恢复，不能仅靠“一个工单”承诺数据库和所有部署具有瞬时原子切换。发布顺序、兼容策略和失败补偿留到运行设计。

代码回退与数据恢复：收口时已确认采用推荐方向

用户已认可两层恢复方向：普通应用回退默认保留数据，带数据恢复作为明确选择的另一个操作；不采用所有回退都覆盖数据的默认规则。

恢复动作	已确认行为	数据影响
应用版本回退	恢复目标 APP/项目组合的代码、产物和兼容配置，先保留当前业务数据	保留后来新增订单、内容和上传；不兼容则进入恢复评估
带数据的时间点恢复	选定明确数据库和文件恢复点，协调所有使用它的 APP	会覆盖恢复点之后的新数据，需明确提示范围、时间及影响

仅备份结构不足以保护记录内容：删字段或批量修改数据后，结构定义无法找回原数据。结构迁移脚本应版本化、尽量兼容前后版本；并非所有迁移都有无损逆操作。PostgreSQL schema-only 的范围

持久数据应有独立于工单的基础周期备份或持续恢复保护，以覆盖客户操作、采集 worker 等日常写入；仅在修改代码时备份无法覆盖平时的数据损坏。工单按风险补充关键恢复点，基础保护的规格、保留范围与成本阶段 3 定义。

建议按改动风险及应用数据能力建立恢复材料：

• 纯前端/样式修改：记录 Git、产物、配置及结构版本，不必为每次改字完整复制数据库或卷。
• 数据库结构迁移、批量改写或删除：在首次影响持久数据前建立并校验恢复点；小型项目可采用逻辑备份，较大数据或高频写入项目评估基线备份加日志归档/供应商时间点恢复。
• 上传文件、附件或应用在卷内修改内容：按需要建立卷快照或对象版本/备份；数据库记录与文件必须有可核对的一致恢复范围，独立时间的两个备份不自动组成一致状态。
• 后台采集 worker 会持续写入，快照或备份期间需采用应用支持的一致性方法；必要时协调暂停相关写入。恢复时先停止相关写入、恢复到隔离目标并核对，再切换使用者，避免破坏正在工作的数据。

PostgreSQL 时间点恢复依赖基线备份与连续 WAL，物理恢复的范围通常是整个数据库集群，不能在承载多个客户的共享实例上直接回退而影响其他客户；可恢复到隔离实例，再处理目标项目的数据。MariaDB/其他引擎及托管服务需各自适配，不能套用一套 PostgreSQL 方法。PostgreSQL PITR

Longhorn 的增量备份可复用未变化数据块，减少每次备份重复复制的成本；本地快照与集群外备份职责不同，不能以本地快照替代灾难恢复。存储快照的一致性也不能自动等同于应用数据库和附件的一致性。参考官方能力，不表示现有集群已支持或配置这些方案。Longhorn 增量备份、Longhorn 快照与备份概念

备份占用取决于基础数据大小、变化量、写入日志、副本及保留期限，并非零成本。建议分开保留近期任务恢复点、周期备份和长期代码历史，具体期限与价格阶段 3 决定。可定位任意历史工单的代码版本，并不意味着每个历史时间的数据都永久可恢复；数据恢复界面需显示实际可用的恢复点和保留范围。

数据库保护点通常建立于实际数据修改前，不应冒充工单提交时数据；两个时点可能相隔数天。发布与恢复记录保存准确时间和范围，恢复前保护当前状态。默认模式已明确，涉及数据覆盖时的具体确认步骤移交阶段 3。

运行实例、默认预览入口与未来沙盒

已确认运行实例仍由 K8s 在线维护。新项目的应用需要访问时分配平台默认建站域，仅用于客户测试/预览，不允许当作正式公开站点。工单过程当前无需对客户透明，完成后直接更新其正在访问的运行实例；不增加发布前客户验收步骤。

正式公开发布允许客户绑定自有域名，或通过平台购买域名；默认建站域仅预览。默认域名和独立域名是访问方式及发布资格，不应推导为“未买域名就没有实际 K8s 服务器”。正式上线可沿用同一持续实例，更改访问绑定与公开发布状态；如另需专属运行环境再单独选配。域名验证、绑定及采购的具体服务规则移交阶段 3。

未来 AI 执行可使用临时隔离沙盒，必要时通过受保护入口映射出来。开发沙盒/临时预览与客户持续实例分开，默认不连接客户可写生产数据或以正式身份发送邮件/调用付费业务接口。独立数据副本、脱敏、权限及费用后续设计。

用户与项目采用系统生成 ID，实际访问入口显式绑定应用端点。建议再生成独立的唯一预览标识，避免直接暴露用户信息或可枚举编号；例如 p-7f2k9m-web.preview.example.net，多 APP 的不同 Web/API 入口各自映射。不从仓库名、namespace 或可读项目编号推算目标。临时沙盒可有另外的临时入口及有效期；随机地址本身不替代访问权限。

行业参考：Vercel 会为部署生成唯一访问 URL，并提供预览/部署访问保护；可借鉴稳定项目入口与具体部署入口分开的方式，无需照搬域名格式。Vercel 生成 URL、Vercel 访问保护

默认域名的访问提示、验证码与责任边界

用户提出默认预览域名统一显示免责声明，通过验证码后才展示应用。技术上可用统一预览访问网关实现，网关验证后签发限时访问凭据，再放行原访问目标，不需要让每个客户模板重复实现。页面说明这是客户测试内容，并提供投诉/举报入口。验证码是人机验证还是客户持有的访问码，及是否结合登录/限时分享，仍待定。

建议默认仅项目所有者、员工及持有受控分享权限的人可访问；免责声明和人机验证作为附加提示与防滥用机制。单纯任何人答验证码即可访问，仍可被用作公开传播入口；需覆盖深链接、API、静态内容及绕过网关的后端路径。跨应用登录、Cookie、WebSocket 与机器接口兼容性留架构阶段核对。

ngrok 官方描述中间提示页用于降低钓鱼风险，且提供跳过路径，不能将该产品行为当作通用法律免责证明。ngrok 中间提示页

法律适用地区尚未明确，当前不作免责结论。以欧盟 DSA 为例，托管责任例外涉及对违法内容的知情及及时移除/禁止访问等条件；免责声明或验证码并不能替代这些条件，此处不是判断本平台必然适用 DSA。产品规划应包含服务使用规则、举报受理、停用入口与处置记录，具体义务在确定经营主体、用户地区及服务性质后核对。欧盟 DSA 第 6、16 条

项目组保持简单

用户明确：项目至多属于一个组，分组不嵌套，不需要多组或复杂标签体系。建议允许未分组；一个组可含多个项目，为协作查询及以后功能扩展提供基础。API 协作依然通过明确关系表达，分组不提供隐含授权，批量操作清单后置。

阶段 2 逐轮核对结果（收口后）

五项主题已形成领域基线，用户认可推荐方向；参数和执行细节按本文件开头交接清单进入后续阶段，不再要求阶段 2 完成采购或建表。

顺序	仍需确认的内容	用于核对的业务例子	本阶段要得到的结果
1. 目录与运行配置	已明确按应用预设必需/可选项；支持版本和组合契约后续工程化	金融官网必须有 Web/数据库/PVC，纯前端个人站无数据库/PVC	不再要求平台统一必需组件清单
2. 资源与服务归属	引用释放机制及独立服务分开管理已确认	删除最后一个数据库使用 APP；保留独立邮箱	三天仅候选；账目、备份清理与订阅期限阶段 3 细化
3. 工单与成果范围	单项目多 APP、项目发布组合及两层恢复方向已确认	同时改前后端；普通回退保留新订单	具体引擎、操作确认及保留期限后置
4. 环境与部署实例	默认域受保护预览、沙盒后置、正式域可平台购买或自有绑定已确认	客户已有自己的域名	保护实现后置，法律地区待补事实，不承诺验证码免责
5. 分组与关系基数	已明确单层、单归属，不嵌套不多组	两个协作项目放一个组	不继续扩展复杂分组模型

阶段 2 收口后转入阶段 3 的状态、价格、续费、释放、投诉和恢复操作规则；技术选型和具体恢复实现仍按计划后置。

本阶段后续轮次

1. 项目、客户应用实例和独立服务的核心边界已形成基线，生命周期继续核对。
2. 应用目录、基础软件版本、项目类型与运行配置分别表达什么；类型怎样声明组件和默认要求。
3. 实例、环境、工作负载和资源的绑定、默认值及可覆盖项；处理 worker、namespace、仓库及数据库旧约束。
4. 工单、代码、线上版本、订单和分组怎样关联，用真实场景核对完整模型。

这里保留整体讨论地图，但每轮只展开一个主题。下面原有领域清单用于查阅，统一系统部署、Git 和数据库部分暂不要求逐项选择。

统一系统与部署结构

统一系统意味着公开能力目录、客户、员工、服务产品、订单、项目、工单和交付有一致的业务模型、权限与生命周期。来源不驱动系统设计；当前以普通客户账号为边界，企业组织与成员协作后置。产品整体性不由进程数量或数据库数量单独决定。

客户门户、员工后台和任务执行器可以是同一产品的不同界面或运行组件，也可以共用数据库。是否拆分要依据权限、负载、故障隔离、事务边界和维护成本论证。

不将几个旧后台简单拼接为新产品，也不预设所有能力必须运行在一个进程里。

领域模型先回答的问题

概念	必须明确的关系或职责
客户账号与内部权限	普通客户注册、项目归属、员工操作；中介没有特殊身份，组织与成员后置
项目分组与定价政策	单层、项目单归属；客户整理与平台价格分类分别表达，不以同组推断运行权限
应用能力目录	应用来源、版本、适用场景、接入状态、支持范围及运行契约
服务产品和套餐	运行配置档位及域名、邮箱、人工、AI 等独立选配服务，购买后交付什么
订单和订阅	配置档位年付、扩容调整、独立服务购买、报价确认、费用与续费
项目	客户组织业务的单位，与订单、服务、应用的关系
项目类型	是否定义业务能力、默认组成或资源要求，怎样支持组合与版本
应用与环境	项目支持多应用、APP 与组件分层已确认；组件版本及预览/生产环境关系待定
工作负载	Web、worker、scheduler 等角色及运行配置
资源与绑定	namespace、仓库、数据库、域名、邮箱和存储的归属及使用关系
改动工单	限一个项目、可涉及多个 APP；文字与附件、处理模式、人工金额确认、执行及版本追踪
客服渠道	在线客服、Telegram 及拟接入 TG 机器人中的咨询、澄清、价格沟通和反馈；关联方式待定
成果版本与恢复	工单提交时版本、执行基准、各次预览、发布组成、历史回退及数据恢复范围
代码协作关联	平台工单与外部 Issue、PR、提交和构建的明确映射，不依赖编号相等
供应商账号池与分配	Cloudflare、Migadu 等账号的可用状态、共享容量、独享关系及实际资源绑定
托管资源供应方式	自建/外部数据库、卷和对象存储的能力、供应商目标与账目，不以供应商实例代替逻辑数据库
API 协作与公共服务	客户项目间接口依赖，以及平台自有服务产品、订阅、调用授权与收费
价格与成本记录	后台可调参数、价格规则版本、供应商采购成本与客户独立账目

这些不是建表清单。概念、基数和数据所有权先用业务实例验证，再转成具体数据库设计。

运行资源按购买的配置档位订阅，不按实际瞬时用量收费；购买配置、运行观测及价格版本分别表达。项目业务分组、价格分类、供应商账号分配不预设一一对应。供应商账号池也不是客户账户或组织模型，不能混淆权限归属。

首期复杂定制走人工模式，内部评估与设置价格，客户同意后执行并更新线上。自动模式后续按能力开放，提交后 AI 修改并发布，需要人工时自动切换到同一工单的人工模式；人工金额确认是条件步骤，沟通与反馈由客服渠道承担。

Git Issue 集成方案评估

用户建议将工单绑定 Git Issue，并在阶段 2 收口时认可平台业务主记录关联 Git 工程记录的推荐方向。下面保留方案比较；具体实现、Issue 强制范围、Git 服务供应商及同步机制留到阶段 4。

Git 本身管理代码版本，Issue 是 Gitea、GitHub 等托管服务的协作能力。GitHub 支持 Issue 与 PR 关联；Gitea 支持 Issue、PR、提交引用，也支持外部工单追踪引用。这能建立工程追踪关系，处理模式、人工价格确认、实际发布和恢复记录仍需产品模型表达。GitHub Issue 与 PR 关联、Gitea 引用与外部追踪

候选	适用性与代价	本轮建议
改动工单以 Git Issue 承载需求和开发记录	与主要伴随代码的任务更契合，可复用工程追踪；处理模式、客户权限、人工金额确认、费用及实际发布恢复仍需平台表达	可以评估，但不能仅靠 Issue 状态决定整个业务任务是否完成
平台工单直接关联 PR、提交和发布，无独立 Git Issue	工程关联较少，避免两套讨论或状态同步；团队若需要 Issue 看板需另评估	可作为较轻的接入方案
平台改动工单关联 Git Issue、PR、提交和发布	平台表达任务授权、模式和人工金额确认，Git 追踪改动，客服独立；需明确关联和同步边界	当前推荐方向，Issue 是否必须及首期接入范围待定

推荐方案仍是一个产品：客户通过平台提交改动工单，客服渠道承担沟通，Git 服务接入工程能力。平台保存原始文字与附件、需求版本、初始与当前模式、人工金额确认、执行状态及线上版本；Git 侧保存开发任务、内部技术记录和代码改动。代码工单可关联 Issue，少量无代码服务任务不强制建立 Issue。

已确认保存工单提交内容及附件的不可覆盖版本，新增或改变需求另建工单，客服/TG 不自动修改原范围，用于防止追加及完成争议。补缺、原需求未完成修复和新增的区别、执行中变更及费用细则阶段 3 处理。

建议一个平台工单可关联零个或多个开发任务，一个开发任务可关联多个 PR 或提交；发布版本可包含多个工单的成果，关系基数仍需真实场景验证。关联记录包含实际服务实例、仓库及外部标识，不以工单号等于 Issue 号或仓库名等于项目名建立关系。

先同步任务、链接及必要工程摘要，不复制在线客服或 TG 的全部对话。Issue 关闭或 PR 合并不能代替生产发布成功和费用状态；工单执行完成应关联实际线上更新结果。同步失败不丢失客户提交，重试不得产生重复 Issue，具体接口及一致性策略留到架构阶段。

现有 Gitea 可以作为候选接入能力评估，无需为绑定 Issue 先迁移到 GitHub。候选服务的实际版本、API 和权限支持在实施前核对，当前未操作任何外部仓库或工单。

版本追踪与恢复模型建议

仅绑定 Git Issue 无法定位整个应用的历史运行状态。建议将平台成果版本和部署记录明确建模，关联到工单、目标应用及环境，并保存版本组成：

记录	需要解释的内容
需求与执行	提交与附件版本、工单发起时应用版本、执行时基准及每次处理尝试
代码与构建	仓库、实际提交、PR、构建结果和可追踪的镜像 digest 或产物引用
应用组成	Web、worker 等工作负载采用哪些产物及配置版本，相关配置和凭据版本引用
发布与完成	哪个成果更新到哪个目标环境、健康检查及执行结果；不设默认客户验收发布门槛
数据兼容与恢复	数据结构版本、迁移及备份或快照引用，能否保留现有业务数据运行历史应用
回退	当前版本、目标历史版本、涉及工单、恢复范围、执行状态及恢复后有效版本

工单发起时版本和执行时基准需分别保存；排队期间其他工单可能已发布。平台业务记录和账目不随应用回退恢复为旧状态，回退作为新的动作保留完整历史。

回到一个完整历史版本，与仅撤销某张工单的修改分别提供语义。Git 的 revert 可通过新提交撤销历史提交的改动；它不等同于重新部署历史镜像，也不恢复数据库和外部资源。Git revert 官方说明

目标是可选择任意历史工单发起前的应用版本。能否直接恢复需核对产物保留、配置及数据兼容，无法直接恢复时进入恢复评估，不把需求静默改成“只能回退最近一次”。已确认普通回退保留数据，带数据恢复另选实际可用时间点；版本材料、数据恢复点的保留与长期成本阶段 3/6 细化。

用户指出的旧约束与目标要求

旧约束	新模型需支持的能力
人工编写 projectxx 编号	系统生成稳定标识；可读编号和历史别名独立
用 -x 后缀识别入口和关联	显式描述用途、类型及关联关系
worker 等依赖人工特殊处理	类型配置声明工作负载组成、依赖和资源要求
namespace 只能跟随约定	默认命名可覆盖；保存实际资源目标并检查冲突
项目、namespace、数据库名称关联	用资源 ID、目标配置和凭据引用明确绑定
仓库名要与 namespace 相同	代码来源与部署目标独立配置，CI 根据绑定定位

业务用途、软件目录/支持版本、组合方案与运行配置分别表达，资源必需/选配由应用预设声明；类型模型不能成为另一套固定命名约束。实例可覆盖参数的具体清单按版本运行契约在阶段 6 定义。

示例：一个应用由 Web 与 worker 组成，它们是否共享镜像、数据库、存储，以及 worker 的副本数和启动命令，都应有配置表达，而不是从项目名字推测。

数据库问题需拆开讨论

先区分两种数据：平台数据包含账户、订单、工单、项目和交付记录；客户应用数据是客户网站自身的会员、内容、订单等业务数据。平台数据库是否统一，与客户应用数据库如何隔离，是两个独立决定。

平台还可能保存日志、素材和构建产物，它们是否使用其他存储也需单独论证。“统一数据库”不代表所有文件和运行日志必须塞进同一组业务表。

平台候选方案	可以怎样组织	需要权衡的问题
模块化应用与一个平台数据库	客户、订单、工单及项目按模块管理，一个数据库保存业务记录	事务便利、责任边界、权限及后续拆分能力
多个运行组件与一个平台数据库	API 与异步执行器分开运行，明确各模块的数据写入责任	故障隔离、并发访问、迁移协调和耦合
多个服务与各自数据库	服务拥有各自数据，通过 API 或事件协作	一致性、幂等、查询汇总、分布式恢复及运维成本

这里只列候选方案，不选定一种。先完成领域模型和完整流程，再按真实负载、团队维护能力与事务要求比较。

无论哪种方案，客户注册都需身份与项目归属，工单需作者、权限、状态、范围和成果关联；成员模型后置。是否适合重用旧表必须逐项评估，不能只增加用户和工单表就认为设计完成。

客户应用的数据技术不能由平台数据库选择决定。现有官网与 Odoo 样本使用 PostgreSQL，货代样本使用 MariaDB 及 Redis；目标目录需描述应用依赖，不能将所有客户应用强制套进旧站点数据库规则。

Content Hub 提供两个需分开的关系样本：同一应用的 API 和 worker 共用应用数据；内容中心通过 API 为目标网站发布内容，目标网站仍有自己的业务数据。平台交付任务与被部署应用内部的内容任务也要分别建模。

迁移与目标模型

旧 ID 通过导入映射关联新 ID。namespace、仓库、数据库及域名按实际目标导入，不要求重命名，也不依靠名称相等建立关系。

旧名称后缀、备注和默认规则可以提供映射线索，但需校验才能形成正式关系；无法确认的记录进入待核对清单。迁入的多工作负载需归入正式运行配置，不能丢失启动命令、副本、数据和权限等差异。

旧代码或脚本复用需评估模型适配、权限、幂等、恢复、测试和维护成本。可以保留合格能力，也可以重写；迁移计划独立于代码复用决定。

后续架构讨论的产物

先完成概念关系及典型场景，再形成模块与数据所有权、应用和数据库候选比较、架构决策记录。最后细化表结构、API、事件、任务、权限和数据迁移契约。

AI 执行、构建、资源开通和发布都需有输入输出、授权、状态、恢复和成本边界。具体部署分工待目标设计确认，不把旧 CI 或脚本限制作为永久前提。

现状参考

旧代码只用于盘点和迁移分析，不是新系统的结构要求：

• 旧资源配置
• 旧数据库结构
• 旧业务与运维接口

现网操作继续遵守当前运维规则。对新模型的讨论不触发生产改名、表结构变更或部署切换。