建立可移交的 AI 软件交付规划文档仓库。

纳入截至 2026-10-13 会议回写后的产品基线与会议图源。

01-立项与产品定位.md

@@ -0,0 +1,237 @@
+# AI 软件交付与持续服务平台立项与产品定位
+
+状态：阶段 1 业务基线，版本 0.15，更新日期 2026-10-13。自动转人工改为先经 AI 验收、失败达到 x 次再转，x 未定。计费模式见 05 的 2026-10-13 补充。架构尚未决定。
+
+## 立项原因
+
+当前团队约 80% 的主要业务是企业展示官网，包含金融交易平台或机构的品牌官网。这是用户提供的业务占比，不是对项目目录的统计结果。多数订单来自一个作为订单中介的甲方，由团队负责开发和运行交付。
+
+与此同时，用户直接承接供应链电商、货代等业务系统，采用接近需求的开源系统部署，再通过 AI 定制开发、配置和处理数据。这些项目此前未进入资产库，原因是客户来源不同，而不是交付业务不相关。
+
+新平台面向公开市场提供服务，通过 SEO、广告及公开的案例和应用能力展示吸引客户自行注册、提交需求和购买服务。现有中介及直接客户只是业务样本和迁移对象，来源不驱动产品模型。需求分析、方案选择、交付和持续服务中反复发生的人工协调需要转为可追踪的工作流。
+
+## 产品定位草案
+
+建议定位为“AI 驱动的软件交付与持续服务平台”。AI 建站空间可以是其中面向展示网站的服务表达；正式产品名称待确认，目录代号暂保留 `ai-web-delivery`。
+
+核心销售价值是团队将 Web 应用接入、配置、部署和维护封装为可稳定运行的交付基础，并通过 AI 工作流或人员利用 AI，基于该基础完成客户需要的二次开发与系统定制。客户购买的是适合自身业务、能够运行交付的应用成果；技术封装是团队持续积累的能力，定制服务是核心销售内容。
+
+基础应用、标准部署、运行资源、域名和邮箱支撑客户接触、体验和持续使用服务，帮助客户认识平台能做什么，并覆盖相应成本。基础收费可以保留必要服务收益，但不把运行资源销售或托管规模作为核心商业定位。只需要标准应用或独立基础服务的客户仍可按已确认规则购买，不强制购买定制。
+
+首期以团队利用 AI 处理人工定制工单提供这一核心价值，后续再把成熟任务转为自动 AI 工作流。自动化程度改变的是执行方式，不改变二次开发定制在产品中的核心地位。
+
+平台既是对外服务网站，也是交付与持续运营系统。公开网站展示能做什么、有什么案例、哪些基础应用已支持，以及服务内容和定制入口；客户提出需求后，平台推荐自有模板或成熟系统，完成配置、范围内定制、验证、运行交付和后续服务。
+
+系统上线后，平台还应承接数据迁移、批量内容处理、功能修改和运维任务。客户可以直接选已支持的应用，也可以先描述需求，由平台推荐方案；两种入口如何呈现，后续细化。
+
+共同机制是按需求选择基础系统并持续交付，各类系统的代码、数据库和运行组成可以不同。统一产品不要求把所有客户应用改写成同一种技术栈。
+
+## 现有业务样本与交付差异
+
+| 场景 | 已观察到的内容 | 对新平台的意义 |
+| --- | --- | --- |
+| 企业及金融机构官网 | project37、40 的源码有通用内容后台和不同品牌前端；线上 37、40、58、67 展示机构、服务、教育、新闻或下载入口 | 可将共用应用能力与品牌定制分开，行业、页面范围和收费不等同于模板类型 |
+| TraderTopMark 评价网站 | 源码包含机构、评分评论、新闻、多语言和社区内容等业务实体 | 超出展示站范围，需自己的功能和验证契约 |
+| Content Hub 内容中心 | API、内容分发 worker 等通过任务和发布端点协作，服务可连接多个目标站点 | 需表达后台工作负载及跨应用服务关系，不能都当作独立网页 |
+| 供应链电商 | 基于 Odoo Community 19 的 Compose 项目；包含商品、分类、图片迁移及中西双语处理 | 开源系统定制和数据任务属于服务交付，不能只围绕前端改版 |
+| 货代系统 | 基于 Frappe/ERPNext 的 Freight Ops；包含订单、费用、单证、客户门户和报表，运行组成有队列、scheduler、数据库和缓存 | 项目类型需覆盖完整业务应用及多组件运行，而非单一 Web 容器 |
+| 仅邮箱服务 | 用户说明已有这类项目 | 服务可不包含代码开发或 Web 部署 |
+
+官网采样反映的是展示和内容能力，不据此认定系统实现了交易执行。项目 30 至 67 并未全部盘点，失败访问也不能直接证明项目已关停或仅有邮箱。
+
+目前官网与 Content Hub 的源码已有 Gitea 构建、推送镜像和 K8s 更新流程，但并非完全相同：官网样本使用 `latest` 且按仓库名推导部署目标；Content Hub 构建 SHA 镜像并更新多个工作负载。TraderTopMark 还存在首次自动创建资源的流水线分支，需要迁移时单独核对。
+
+用户补充确认：电商和货代目前都是本地开发、本地运行，通过 FRP 映射给客户测试，尚未正式部署到服务器或 K8s。源码中的 Compose 配置是当前本地运行组成的参考，不是已完成生产上线的证据。新平台目标可以统一提供上线与运行服务，但不能直接把旧官网流水线复制到每一种系统。
+
+## 对外服务网站与获客
+
+平台通过公开展示软件交付能力吸引新客户，不依赖运营人员事先录入客户或中介提交订单。SEO、广告和已有合作关系都可以带来客户，但不会产生三套业务流程或三种客户身份模型。
+
+建议公开站点包含应用和服务目录、行业场景、真实案例、定制能力说明以及提交需求或购买的入口。展示内容需要让客户理解应用能解决什么、默认包含什么、可定制什么及哪些需要评估，避免只陈列技术名称或容器镜像。
+
+应用目录同时承担定制能力展示：让客户看到基础应用能完成什么，以及团队可在其上调整哪些界面、功能、业务流程或数据。演示、案例和定制入口应围绕这些成果展开；服务器规格是运行选配信息，不能取代对核心开发能力的表达。具体页面和客户转化路径后续讨论。
+
+公开目录和案例可以形成可访问、可检索的页面；SEO 页面组织、广告落地页、服务定价展示及转化流程后续细化，不在本轮承诺渠道效果。
+
+订单来源如需记录，可作为统计和推广归因信息。它不是项目类型、部署规则或访问授权依据。
+
+## 客户账户与项目管理
+
+当前以面向散户的自助服务为主，每个客户账号管理自己的项目和订单。中介也作为普通客户账号理解，只是可能频繁提交订单；无需为其预先建立中介组织、下级客户或专门报价链路。
+
+账号是当前的操作与权限边界。用户将立项账号交给其他人使用，不要求平台识别谁是中介或最终客户；这种业务安排不构成新增账户类型。内部运营人员的管理权限仍需设计，不能因此允许不同客户账号访问彼此项目。
+
+企业组织、成员协作和二次授权明确后置，本轮早先关于中介与最终客户分别参与和报价可见范围的草案撤回。未来有实际需要时再设计，不提前影响当前注册和项目模型。
+
+项目可分组，用于管理和后续差异收费。分组由平台设置还是客户自建、是否需要两种分组，是待讨论的产品细节。
+
+## 可持续扩展的应用目录
+
+支持能力不限于现有官网模板。目标包括 GitHub 等来源中各行业的可容器化应用：团队完成一次接入和交付验证后，将具体应用版本录入目录，作为可向客户展示、推荐和交付的能力。
+
+“调通一次”需要形成可重复执行的接入成果。建议至少记录：
+
+- 应用来源、版本、适用场景、默认能力及许可信息。
+- 可复现的构建或镜像来源，以及完整运行组成和外部依赖。
+- 参数、数据库、缓存、文件、队列及启动初始化要求。
+- 可修改的代码或插件范围、可配置能力，以及需要人工评估的定制。
+- 可执行的安装、健康检查、验收、升级、备份和恢复步骤。
+- 对外说明、演示或案例，以及可提供的服务和资源规格。
+
+具体上架标准在领域模型和交付阶段制定。容器化是重要接入条件，但“容器能启动”与“能按客户需求稳定交付、升级和维护”是不同的验证范围。
+
+热门项目可以成为选型线索，但新平台区分“已接入可交付”和“候选待评估”。客户也可以提出目录之外的需求，进入应用评估或人工方案流程，不直接承诺任意项目均可自动支持。
+
+应用目录中的一个版本及其交付能力，是项目可选择的基础，不等于客户只能使用原样软件。配置、插件扩展、界面与功能调整、数据服务及运行维护共同组成后续交付。
+
+目录展示基础应用、案例和团队经验，不将“预先列出的可定制能力”作为客户提交需求的限制。客户可以自由说明希望怎样修改，工单记录一次清楚的需求；可行性、实施方式和人工价格由内部评估确定，沟通通过客服渠道完成。应用接入契约及已验证能力是内部选型和执行依据，不代表人工只能接受清单内需求，也不代表所有需求都已承诺可实现。
+
+## 工单目的、处理模式与沟通渠道
+
+工单的核心目的是固定客户这一次明确提出的改动，减少客户摇摆、无限追加以及“是否提出过、是否完成”的争议。客户把要执行的需求以文字或详细文档附件提交，工单主要伴随代码修改，并关联实际处理及线上版本；不要求客户使用 Git。
+
+客户提交时选择自动或人工模式。自动模式由 AI 完成修改，并先做 AI 验收；验收通过后更新线上，客户直接看到结果。验收失败达到 x 次后才自动转为人工模式，沿用原工单。x 未定。人工模式由内部评估设置金额，系统显示价格，客户点击同意或拒绝，同意后人工执行并更新线上。
+
+人工价格确认类似网购改价确认，仅承担金额的同意或拒绝；价格沟通不在工单中进行。自动模式没有这项人工价格确认，也不采用每次客户验收预览后才上线的默认流程。代码检查与发布验证仍是内部执行责任。
+
+其他沟通、需求澄清、价格协商及后续反馈归在线客服或 Telegram 等渠道。用户考虑接入 TG 机器人接口处理沟通；当前作为渠道候选记录，不作为工单执行方式，也未决定实现。
+
+已确认提交后保存本次文字和附件的固定版本；新增或改变业务范围另建工单，客服或 TG 聊天不自动扩大原范围。本轮允许失败后修订需求再次尝试，原始需求和历史尝试仍保留；系统提供成功摘要、失败原因及预览入口等回执，不因此增加客服会话。具体规则见 02。
+
+工单全程追踪的是需求原件、初始与当前模式、模式转换、人工金额及确认、执行记录、代码和线上版本、回退结果。客户不满意时目标支持回到任意历史工单发起前的应用版本；普通回退保留数据，带数据恢复另选时间点，具体恢复规则后续细化。
+
+Git Issue 关联适合进一步评估开发任务的追踪。建议平台保留客户任务、处理模式、人工价格确认和执行状态，Git 侧关联 Issue、PR 与提交，平台再关联实际线上版本；客服会话独立。具体比较见 03、任务流程见 02，尚未作为最终技术架构定案。
+
+## 分组和差异收费的讨论方向
+
+用户希望对项目分组，并支持不同收费标准；金融行业网站可能采用更高收费标准。分组与定价属于目标能力，但来源不是固定分类，更不是系统驱动方式；具体分组、收费规则及优先级尚未确定。
+
+建议区分以下维度，避免一个“组”同时承担归属、权限、行业、技术和价格全部含义：
+
+| 维度 | 回答的问题 | 示例 |
+| --- | --- | --- |
+| 客户账号 | 谁在平台拥有和操作项目 | 普通客户，也包含经常下单的中介 |
+| 项目分组 | 怎样整理项目或应用不同服务政策 | 具体分组及其管理者待定，不预设为客户来源 |
+| 行业 | 客户在哪个行业经营 | 金融、供应链、货代 |
+| 服务产品 | 客户购买什么 | 官网交付、商城定制、业务系统、邮箱、持续运维 |
+| 系统基础及运行类型 | 采用什么软件和运行组成 | 自有模板、已接入开源应用、API 加 worker |
+| 定价与服务政策 | 适用什么收费与交付条款 | 组或行业价目、套餐、个别项目报价 |
+
+这是一种待讨论的拆分方式，不是已确定的字段设计。相同行业可以存在不同应用类型，同一客户账号也可以购买不同服务。
+
+价格如何按组、行业、服务及合同匹配，需要明确规则。建议订单和人工报价保存当时采用的条款版本，防止后来调价或移动分组改变历史费用。
+
+## 服务范围与任务形态
+
+目标全貌涵盖展示官网、评价及内容业务、可持续扩展的各行业应用、邮箱与附加资源，以及持续运行和定制服务。成熟系统不仅供安装，还可能包含业务适配、插件扩展、流程调整、数据迁移及上线后处理。
+
+Content Hub 案例还需区分两层工作流：交付平台执行安装、定制与维护；部署出来的内容中心运行自己的采集、生成及分发任务。当前发布 worker 与 Hub API 使用 Hub 数据库，再通过目标站点 API 发布，不要求跨站共用业务数据库。现有发布器实际注册范围有限，不能据此认为已经支持任意站点。
+
+工单或服务请求可能产生不同成果：
+
+- 软件开发与配置：代码、模块、页面、业务规则或配置版本。
+- 数据服务：迁移、导入、清洗、图片同步、翻译及校验报告。
+- 内容运营：生成、发布、分发与持续维护。
+- 运行服务：环境准备、部署、监控、备份、恢复或升级。
+
+是否把这些全部称为工单，还是区分订单、交付任务、工单和周期服务，后续讨论。任务不一定生成代码提交，也不一定需要新建站点。
+
+## 客户购买什么与如何收费
+
+二次开发定制是核心销售服务，运行资源是必须覆盖成本的基础交付服务。客户根据应用类别和规模选择配置档位，按购买的档位包年；扩容时调整费用。数据库、CPU、内存、持久存储等进入配置和定价，具体规格、扩容差价及生效时点后续制定，不按实际瞬时用量结算。
+
+应用选择与资源购买关联，但已接入、已调通的开源应用标准拉取部署不另收部署费。应用接入、非标准配置和定制开发与标准部署分开判断；目录外项目尚不适用免费标准部署承诺。
+
+| 可购买的服务 | 已确认的收费方向 |
+| --- | --- |
+| 应用运行资源 | 配置档位包年，扩容调整费用，覆盖基础运行成本 |
+| 已接入开源应用标准部署 | 不另收部署费，运行资源正常收费 |
+| 人工开发、设计或调整 | 工单人工评估报价，客户确认后跟进 |
+| AI 定制工作流 | 首期有限范围开放，年付套餐包含用量，超额实际成本加价 20% 后扣充值积分；失败/重试/转人工均计真实消耗 |
+| 域名 | Gname 购买成本加平台服务费，独立收费 |
+| 企业邮箱 | 共享池与独享账号分别定价，独立收费 |
+
+默认建站域名可以是平台提供的三级或四级域名，仅供客户测试/预览，不允许作为正式公开网站入口。预览应用仍购买包年运行资源，不强制配邮箱；正式公开发布需要独立域名路径，允许客户自有域名绑定或平台代购。域名、邮箱可以独立购买，不强制绑定应用托管或开发服务。用户要求预览入口展示提示并经验证码放行，其访问保护与法律责任评估见 03。
+
+共享邮箱使用 Migadu 账号池；收发需求较高的客户可申请独享账号，经人工工单处理。用户提出的共享池约 100 个域名、供应商费用 90 美元、零售 10 美元是本轮业务示例；包年方向已明确，零售计价对象仍待细化，不能直接作为对外价目。池内域名、邮箱共用供应商账号额度，账号容量与客户服务规格需分别定义。
+
+基础服务按第三方成本加价、AI 工单超额按模型成本加价，人工定制按评估报价。计费依据与核心销售价值分别表达。后台可调整配置价格、固定服务费、赠送额度、加价比例和邮箱规格等参数。首期既有合作客户采用账户价格政策，使基础及固定项目服务费合计符合原谈好的价格。共享成本需分摊，不能认为每位客户都有独立供应商采购账单。具体规则见 [05 商业模式与成本指标](<05-商业模式与成本指标.md>)。
+
+## 首期交付与自动化边界
+
+首期包含客户自助购买、运行成果或预览、工单提交和后台处理，先由深度合作的既有中介客户试用；中介仍是普通客户账户。长期对外公开获客与服务散户目标不变。简单固定运维例如添加域名和邮箱由程序封装，不必调用 AI。
+
+首期有限自动 AI 有套餐包含用量，自动评估/开发/检查后直接更新，不能处理转人工。复杂任务人工评估金额，客户同意后执行，协商归客服/TG。所有归属客户项目的 AI 调用均计消耗，包括人工辅助、失败与重试；超过包含用量扣充值积分，与人工费用分别说明，避免重复计同一调用。
+
+自动能力按成熟度扩展，不承诺任意需求自动成功。首期年付套餐可包含初始开发与运维，不采用按月/小时退费；退役清理运行及业务数据，仅存代码和启动配置以便重新部署。特殊差额系统外处理。新客测试赠送永远不作正式权益，禁止绑定域名并可销毁；具体额度策略后置。标准部署和有限自动清单后续验证。
+
+## 供应商账号池与服务分配
+
+Migadu 和 Cloudflare 的账号目前需要人工注册、准备和维护。首期可自动执行已有有效账号支持的操作，缺少账号或容量时转人工处理，不将账号注册也假定为自动步骤。
+
+平台需要管理供应商账号池和实际资源绑定。Cloudflare 分组分配用于控制单个账号发生信誉问题、停用或故障时的影响范围；Migadu 还需按共享容量、客户收发需求及独享要求分配。具体分配与停用规则后续细化。
+
+项目业务分组、收费分类与供应商账号分配是不同职责。不能预设一个项目分组永远对应一个 Cloudflare 或 Migadu 账号，也不能把账号名写进项目编号作为隐式关系。
+
+## AI 对话工作如何转为工作流
+
+本节讨论长期工程化方向。首期有固定运维和有限自动 AI 定制，复杂开发及数据任务可由人工工单承担；不要求首期上线前完成所有 AI 工作流。
+
+当前大量工作通过与 AI 对话完成，为工作流化提供了真实样本。可复用的是任务步骤、工具、约束、产物和验收方式，而不是把一段聊天记录原样变成无人值守流程。
+
+用户在对话中实际承担了需求补全、方案选择、提供权限、纠正结果、决定是否继续等职责。工作流必须显式处理这些决策；证据不足时进入澄清或人工接续，不能假设每次都能自动判断。
+
+建议将任务分为 AI 判断、程序执行和人工决策三个部分。AI 适合理解需求、推荐候选、生成改动及解释异常；确定性的批量写入、数字检查、去重和结果核对由程序执行；涉及业务含义或服务范围的未决事项保留明确的确认入口。
+
+电商样本已有这种组合：按源商品 ID 导入和更新，图片分批同步，翻译结果做结构与数字校验，再写入目标系统。这说明部分步骤已经有工程化基础，但完整的自助服务、授权、预算、调度和异常处理仍需设计。
+
+一次性大规模迁移与周期内容分发的执行模式不同。新平台需分别表达数据来源、目标、操作范围、结果验证、进度、重试、费用及恢复条件，再评估各类任务的自动化程度。
+
+## 已确认的设计前提
+
+- 全面重构业务与系统，旧资产库是迁移来源，不默认作为新系统底座。
+- 企业官网是当前主要业务，长期目标覆盖各行业应用的交付、定制、数据和持续服务。
+- 核心价值是可稳定运行的 Web 应用技术封装，以及 AI 和团队的二次开发定制能力；基础服务支撑交付、获客与成本覆盖。
+- 新系统是公开服务网站，通过 SEO、广告和能力展示获客，来源不驱动业务模型。
+- 以普通客户账号为当前模型，中介也作为普通客户；组织、成员和二次授权后置。
+- 支持项目分组与差异收费，具体分类和定价模型待定。
+- 团队接入并验证容器化应用后可录入能力目录，支持范围持续扩展。
+- 项目组织业务；其与客户、订单、应用和服务的关系需要重新设计。
+- 类型配置表达工作负载，资源通过明确绑定关联，不靠人工编号、后缀或名称相等。
+- 首期方向仍包含客户自助下单、预览和修改工单；完整服务范围与首期边界分开确定。
+- 保留人工评估、报价与高级定制；支持旧数据迁移和业务衔接。
+- 首期熟客年付套餐含 AI 用量，固定运维及有限自动定制并存，复杂需求走人工；新客测试赠送细则后置。
+- 运行资源按购买的配置档位包年，扩容调整费用；已接入开源应用标准部署不另收费。
+- 域名、邮箱、人工与 AI 定制独立计费；价格及赠送政策后台管理，超额 AI 当前拟加价 20%，熟客可配置固定项目服务费。
+- Cloudflare 与 Migadu 账号池纳入资源管理，账号注册目前人工完成，不能把池准备假定为全自动。
+- 工单固定本次要执行的清晰需求，主要伴随代码修改，支持文字和文档附件，不预先用能力清单限制需求入口。
+- 提交时有自动、人工两种模式；自动修改并更新线上，需要人工时自动转为人工模式，人工模式额外确认金额。
+- 沟通、澄清、价格协商和后续反馈归在线客服或 Telegram，TG 机器人接口作为后续沟通渠道候选。
+- 目标支持回到任意历史工单发起前的应用版本；回退的数据范围、保存期限及 Git 集成实现仍待细化。
+
+## 阶段 1 小结与后续事项归属
+
+阶段 1 已明确公开市场定位、可扩展应用目录、普通客户账户和独立服务，以及固定需求、独立客服、两种模式、直接更新和回退目标。阶段 3 将首期范围修订为熟客试用、固定运维、有限自动 AI 及人工复杂定制；阶段 2 领域关系仍适用。
+
+仍未确认的细项不从记录中删除，但按依赖归入后续阶段：
+
+| 后续主题 | 归属阶段与文档 |
+| --- | --- |
+| 项目边界、分组、应用与服务关系、项目类型和资源绑定 | 阶段 2，03 当前讨论部分 |
+| 需求锁定与变更、价格确认、支付、资源档位、邮箱单位周期和基础维护 | 阶段 3，02 与 05 |
+| 数据库与模块边界、Git 接入及客服/TG 技术实现 | 阶段 4，03 架构部分 |
+| 版本产物保留、历史恢复及数据范围、执行失败和供应商操作流程 | 阶段 3 的规则与阶段 6 的执行设计，02 与 04 |
+
+这些问题不要求在阶段 1 全部解完。阶段 2 已完成领域基线，当前进入阶段 3 细化业务流程和商业规则；组织协作仍后置，首期完整工程清单未定案。
+
+## 样本依据
+
+源码与页面采样日期为 2026-10-10。页面仅检查公开展示，不提交表单或操作后台；项目文档中的数据规模和完成情况不代表本轮重新验收了客户数据。
+
+- 官网：[project37](https://project37.website-build.org/)、[project40](https://project40.website-build.org/)、[project58](https://project58.website-build.org/)、[project67](https://project67.website-build.org/)。
+- [project37 源码规范](<D:\work\dev\src\project37\AGENTS.md>)、[project37 CI](<D:\work\dev\src\project37\.gitea\workflows\ci.yml>)、[project40 CI](<D:\work\dev\src\project40\.gitea\workflows\ci.yml>)。
+- [TraderTopMark 业务模型](<D:\work\dev\src\tradertopmark\db\schema.ts>)、[部署流水线](<D:\work\dev\src\tradertopmark\.gitea\workflows\ci.yml>)。
+- [Content Hub 构建与发布](<D:\work\dev\src\content-hub\.gitea\workflows\ci.yml>)。
+- [Content Hub 端点与任务模型](<D:\work\dev\src\content-hub\src\db\schema.ts>)、[跨站发布器](<D:\work\dev\src\content-hub\src\publishers\tradertopmark.ts>)、[实际发布器目录](<D:\work\dev\src\content-hub\src\publishers\registry.ts>)。
+- [电商项目说明](<D:\work_mk\titan\dianshang\README.md>)、[多语言任务方案](<D:\work_mk\titan\dianshang\docs\multilingual-local-translation-plan.md>)。
+- [货代项目说明](<D:\work_mk\titan\wuliu\README.md>)、[运行架构](<D:\work_mk\titan\wuliu\docs\02-architecture.md>)、[CI/CD 路线](<D:\work_mk\titan\wuliu\docs\07-cicd-k8s-roadmap.md>)。