ai-web-delivery-doc/00-分阶段讨论计划.md

# AI 软件交付与持续服务平台分阶段讨论计划

这是一项包含业务模式重构、产品设计、自动交付和现网迁移的长期规划。通过分主题的连续讨论逐步完成，不以单次会话或上下文容量作为系统范围上限。

目录协作版本 0.18，业务基线 0.15，2026-10-13。2026-10-13 会议口径已写入正文，见 08 与 H0004。架构仍未定案。最新进度见 [08](08-当前讨论状态.md)，交接按 [09](09-协作与交接规范.md)保存。

## 阶段 1 业务全貌与产品边界

**主文档：01 立项与产品定位。已形成阶段性业务基线。**

讨论公开服务网站卖什么、如何展示应用能力、客户购买后得到什么，以及客户、运营、设计、开发和运维如何协作。当前使用普通客户账号，中介也作为普通客户；企业组织和二次授权后置。

已明确核心销售是可稳定运行的 Web 应用技术封装及 AI、团队的二次开发定制能力，基础服务支撑体验和成本覆盖。客户用文字和附件提交一次清楚的改动任务，自动或人工模式处理后直接更新线上，人工额外确认金额；工单固定需求以减少追加和争议，客服或 TG 负责沟通。需求变更、支付和恢复细节分别留到业务规则与执行阶段，阶段 1 形成前提后已完成阶段 2 的领域核对。

展示网站、开源业务应用、内容运营、数据服务、仅邮箱和持续托管均进入整体场景。应用目录可扩展到经接入验证的各行业容器化系统；具体组合与对外服务表达逐项确认，不用现有模板限制产品范围。

完成条件：能用几个典型客户案例解释完整业务，并列出明确的目标能力、暂不纳入的能力和仍待研究的能力。此时不要求确定数据库或首期所有细节。

## 阶段 2 领域模型与项目类型

**主文档：03 的领域模型部分。已收口，结论见开头“阶段 2 完成基线与后续交接”。**

讨论客户账号、项目分组、服务产品、应用目录、订单、项目、环境、工作负载、资源和工单之间的关系。组织协作只作为后续扩展边界；用真实场景检验模型，不按客户来源拆业务流程。

重点处理用户提出的旧系统问题：自动生成标识，项目类型声明部署组成，worker 等工作负载有正式配置，命名空间有默认值且可配置，代码仓库与数据库通过显式关系绑定。

本阶段分轮讨论：先确定项目与应用、独立服务的边界；再区分应用目录、类型和运行配置；随后明确实例、环境、工作负载和资源绑定；最后检验工单、版本、订单关联及代表性场景。第一轮核心边界已确认：项目代表一个客户业务目标，允许多个相关应用及配套服务。第二轮根据用户实例提前展开部署组件、共享资源计费、namespace 与数据库关系、跨项目协作、公共 API、客户项目组及外部托管资源；费用组成同步 05，具体价目留到阶段 3，供应商接入留到架构与运行阶段。

完成条件：用展示站、仅邮箱、Web 加 worker、多应用或入口场景检验关系，不需要依赖项目名、仓库名与 namespace 相等或解析 `-x` 才能工作。概念图与字段说明可以逐轮完善，暂不生成生产建表迁移。

已达到上述领域完成条件。用户认可已讨论推荐方向：项目发布组合、代码/数据两层恢复、引用释放、受保护预览、自有域名绑定及平台/Git 职责。参数、规则状态和实现按 03 交接表后置，不为等待备份期限或法律地区而重新开放整轮领域确认。

## 阶段 3 业务流程与商业规则

**主文档：02，当前阶段。费用与权益讨论时使用 05。**

本轮已明确案例快捷入口与普通单 APP 向导、高级多 APP 配置、付款后开通状态/邮件、工单系统回执与失败修订重试、退役/再部署、年付及 AI 赠送方向、到期关闭外部访问和最多一周数据保留。建议方案见 02；先整体记录，再逐轮细化，不能把主要路径已描述等同于商业规则全部完成。

本轮补齐年付开发/运维套餐、预充值积分（推荐 1 USD = 100 积分）、全部模式实际 AI 消耗计费、套餐包含用量后超额扣充值、退役不退费且仅代码/配置归档。未来测试赠送永远只测试，禁止正式域名且可销毁；公开授予细则和客户例外按月结算后置，首期不做退款引擎。

具备进入阶段 4 的首期业务前提。下一轮建议先讨论平台业务模块/数据所有权与部署/数据库边界，再单独讨论工作流与 Git 接入。技术参数、充值渠道、模板支持范围按依赖细化，不能为了讨论所有运营细则把首期复杂化。

逐条讨论公开展示、需求或应用选择、注册、购买、付款、运行成果、改动工单、客服渠道、人工金额确认、直接线上更新、回退、续费及退役。覆盖等待、失败、取消、退款、需求变化和争议等分支；不预设每张工单都需客户验收再发布，成员及二次授权后置。

明确客户可以买什么、订单授予什么权益、工单如何归属和收费。用户注册与下工单作为完整业务能力设计，不作为在旧管理员表旁边临时加表的补丁。

工单保存本次文字和附件、自动或人工模式、内部处理、人工金额确认与线上版本。在线客服或 Telegram 负责沟通，TG 机器人作为渠道候选；提交后需求如何锁定和变化另行讨论。客户要求可回到历史工单发起前版本，整版回退、选择性撤销和数据恢复分别讨论；Git 关联评估保存到 03。

完成条件：角色权限、输入输出、状态转换及主要异常可以解释清楚；商业规则与系统自动行为一致。

## 阶段 4 系统架构与数据边界

**主文档：03 的架构部分。重要决定汇入 07。**

基于前三阶段确定的需求，对比应用部署方式、模块责任和数据库边界。分别回答是否需要独立执行进程、哪些业务需要事务一致、谁拥有数据、跨边界如何协作以及如何恢复。

统一系统可以有多个运行组件；多个运行组件也可以使用同一数据库。应用数量、数据库数量和产品整体性分别论证，不能相互替代。

完成条件：记录候选方案、选择理由、限制和可演进路径。随后才细化数据库结构、API、事件、任务接口和权限实现。

## 阶段 5 旧业务迁移与切换

**到这一阶段再按需要建立迁移专文，当前不批量新增空文档。**

盘点旧资产、现网资源、代码仓库、凭据引用及手工约定。设计导入映射、校验、冲突处理、演练、切换和回退，明确迁移期间由哪个系统负责写入。

新 ID 与旧记录、namespace、仓库、数据库及域名建立映射。迁入时不要求给线上资源改名，也不把历史名称规则转成新系统关系规则。迁移业务记录与迁移客户应用数据库是两类工作，需要分别规划。

完成条件：代表性旧项目可试导入、核对并演练切换；重复导入不产生重复资产，异常可处理，现网服务和发布链路有明确衔接方式。无缝衔接是目标，能否完全零中断需演练验证。

## 阶段 6 自动交付与运行体系

**主文档：04。依赖已确定的类型、权限、架构和资源模型。**

细化应用接入与版本、模板契约、安装配置、AI 开发、数据任务、质量验证、预览、生产发布、人工接续、备份和恢复。区分平台交付工作流与客户应用内部任务，定义输入、产物、预算、重试和权限。

K8s、CI/CD 和现有代码作为候选能力评估，不预设旧脚本调用方式、命名约束或部署分工必须保留。模板工程化与资源配置要支持类型版本和实例差异。

完成条件：普通交付和异常恢复都可追踪；多工作负载、版本发布与数据变更能够在统一模型内解释。

## 阶段 7 版本规划与工程实施

**主文档：06。此时才正式确定首期和后续版本。**

根据完整目标、依赖、成本和风险，决定先交付什么、如何试点、哪些能力逐期完善，并制定验收、实施任务和工期评估。

首期熟客普通账户自助购买年付套餐、预览与工单；固定运维、有限自动 AI/套餐包含用量及人工复杂定制并存。实际调用均消耗权益，超额扣充值积分；固定项目服务费衔接旧报价，提前退役不退费且不保业务数据，无退款引擎。公开获客/测试赠送细则、克隆和例外按月结算留后续。

本轮已提前明确收费方向，并同步到 01 和 05：运行资源按配置档位包年，服务独立选配，后台配置价格。跨阶段出现的明确结论即时记录，不要求为维护讨论顺序而推迟保存，也不据此认定整个商业设计阶段完成。

完成条件：首期范围可验收，后续路线不被首期简化设计堵死，迁移和业务切换纳入实施计划。

## 每轮讨论方式

新人员/AI 先读 AGENTS、README、08、09 和最新交接，再按下面步骤讨论。前三阶段主要由产品组织，阶段 4/5/6 由技术与产品共同评审；技术负责可行性与方案，产品负责业务边界、成本/承诺与切换影响。阶段 5 是迁移规划，不自动授予实施或现网操作权限。

1. 读取主文档的当前主题和已确认决定，选择一个子问题。
2. 用业务例子澄清目标、边界和异常，必要时比较方案。
3. 确认本轮结论，更新主文档及受影响章节。
4. 在 07 保存确认依据/建议/未决，追加交接记录并更新 08 和必要导航，说明下一轮入口。若仅解释且无变化，不生成空交接。

建议每轮围绕一至三个相关问题。发现前提变化时回到相应阶段修订，不为满足既定顺序而草率确定后续方案。

## 当前进度

- 已完成：阶段 1 业务基线与阶段 2 领域基线，分别见 01 和 03；03 开头保存关系汇总及交接清单。
- 当前：阶段 3 首期基线已形成；G01–G05 已生成，见 [会议图集](diagrams/README.md)，10 保留图表规格与后续计划。会议核对后以 03 进入阶段 4，先讨论业务与数据边界。
- 未完成：完整业务与商业规则、架构选择、字段/数据库设计、迁移、自动交付细化和实施排期。

阶段 1/2 基线不等于全部字段和实施细节冻结。其余阶段材料仍需逐轮细化，未决事项按对应阶段继续，不因后续参数未知重新要求前两阶段全部确认。