172 lines
15 KiB
Markdown
172 lines
15 KiB
Markdown
# 会议图表与可视化计划
|
||
|
||
目录协作版本 0.18，产品业务基线 0.15，2026-10-13。G01、G02、G04、G05 的可编辑文字已按 H0004 修订；SVG、PNG 和离线会议图集尚未重绘，讲解时以 Markdown 为准。清单与顺序仍见下文。未确认技术架构或工期。
|
||
|
||
## 已生成图表
|
||
|
||
| 图号 | 可编辑正文与源 | 展示成果 |
|
||
| --- | --- | --- |
|
||
| G01 | [产品业务全景](diagrams/G01-产品业务全景.md) | 主图 SVG/PNG |
|
||
| G02 | [领域概念关系](diagrams/G02-领域概念关系.md) | 主图、工单/购买项、项目例子；各有 SVG/PNG |
|
||
| G03 | [购买与开通](diagrams/G03-购买与开通.md) | 泳道长图 SVG/PNG，按步骤分段讲解 |
|
||
| G04 | [定制工单处理](diagrams/G04-定制工单处理.md) | 主泳道、失败/恢复；各有 SVG/PNG |
|
||
| G05 | [收费与权益](diagrams/G05-收费与权益.md) | 三类权益主图、AI 消耗记账；各有 SVG/PNG |
|
||
|
||
五个主题共九幅主图/展开图，已完成渲染与逐图检查，并提供离线展示页。G06–G08尚未生成；本轮不选择技术方案、不改变业务基线。图内为表达而省略的分支写在各图 Markdown 中，正文与确认记录仍是完整依据。
|
||
|
||
## 应该先画哪些图
|
||
|
||
建议采用 **七张产品图，加一张面向技术讨论的附图**，分别回答定位、组成、购买、修改、收费、存续与首期边界。先生成 G01–G05，足以组织第一轮产品说明；G06/G07补足异常与范围，G08用于与开发讨论接口责任。编号是图表标识，不是新增规划阶段。
|
||
|
||
| 图号 | 推荐图形 | 回答的问题 | 优先级与依据 |
|
||
| --- | --- | --- | --- |
|
||
| G01 | 产品业务全景图 / 业务能力地图 | 我们卖什么，为谁提供什么服务，整体有哪些能力？ | 第一批；01、02、05 |
|
||
| G02 | 领域概念关系图 | 客户、项目、APP、组件、资源和服务分别是什么，怎样关联？ | 第一批；03 领域基线 |
|
||
| G03 | 购买与开通泳道图 | 客户如何选择、充值、购买、开通并访问，谁执行各步骤？ | 第一批；02、05 |
|
||
| G04 | 定制工单处理泳道图 | 自动/人工怎样分支、转换、失败重试、更新线上？ | 第一批；02、04、05 |
|
||
| G05 | 收费与权益关系图 | 年付套餐、包含 AI 用量、充值积分和测试赠送怎样消费？ | 第一批；05、D073–D080 |
|
||
| G06 | 项目生命周期状态图 | 开通、运行、退役、到期、续费与释放怎样转换？ | 补充；02、03、05 |
|
||
| G07 | 首期与后续范围图 | 熟客首期交付什么，哪些能力留以后，哪些仍待技术评审？ | 补充；06、07、08 |
|
||
| G08 | 业务数据流示意图 | 需求、版本、运行结果、AI 消耗怎样在平台和外部能力间流动？ | 技术附图；03/04，接口方案待评审 |
|
||
|
||
可将每张主图作为一页会议材料；不把全部功能和异常塞进一张巨图。图是文字基线的表达，发现遗漏可反向修订正文，但不能在绘图时悄悄创造新规则。
|
||
|
||
## 这些常见图怎样选
|
||
|
||
| 图形 | 适用用途 | 在本项目的使用方式 |
|
||
| --- | --- | --- |
|
||
| 思维导图 | 分类、梳理功能、收集想法 | 可作 G01 的初稿；开会时整理成有层次的能力地图，更容易区分产品能力与内部支撑 |
|
||
| 泳道流程图 | 按参与角色看步骤、分支与交接 | G03/G04，适合讲客户与平台、自动执行和人员怎样配合 |
|
||
| 概念关系图 | 对象之间的归属、包含、引用和使用 | G02；表达业务概念及基数，暂不列数据库表/字段 |
|
||
| 状态图 | 某一对象有哪些状态、什么事件触发变化 | G06；项目、支付、工单及余额不要混成一个状态机 |
|
||
| 数据流图 | 信息从哪里来、经谁处理、存在哪里、输出给谁 | G08 先画简化业务数据流，正式技术分层/接口待阶段 4 |
|
||
| 用户旅程图 | 客户目标、触点、体验和痛点 | 以后优化注册/购买体验时可补；当前步骤和责任用泳道图已经足够 |
|
||
| 技术架构图 | 系统模块/进程/存储及调用边界 | 阶段 4 确定候选比较后画，不预先指定单库/多库或微服务 |
|
||
| 数据库 ER 图 | 表结构、键与数据库关联 | 字段设计时再生成；不能拿概念关系图当建表方案 |
|
||
| 部署架构图 | 节点、集群、网络、运行组件和存储部署 | 阶段 4/6 的技术材料；不是 G01 的业务全景 |
|
||
| 甘特图 | 时间、依赖和人员排期 | 阶段 7 有估算后再画；当前 G07 只展示范围，不编造日期 |
|
||
|
||
本轮不用为了图的名称齐全而制作所有类型。对领导先讲价值和完整业务，对开发再展开领域关系、异常和数据责任。
|
||
|
||
## G01 产品业务全景图
|
||
|
||
目标：一页解释公开平台的定位和端到端服务。核心标题应落在“应用技术封装＋AI/团队定制＋持续运行”，不变成“VPS 转售平台”。
|
||
|
||
建议分层呈现：
|
||
|
||
- 客户与入口：长期通过 SEO/广告/案例/目录获客；首期由熟客普通账户试用，中介不另造账户角色。
|
||
- 客户能力：选择应用、普通/高级购买、项目管理、定制工单、运行预览/正式访问及维护。
|
||
- 服务产品：已接入应用、年付开发/运维套餐、AI 定制、人工高级定制、域名、邮箱及未来公共 API。
|
||
- 交付支撑：应用契约、部署组件/资源、版本与发布、积分与权益、供应商账号池及客户沟通渠道。
|
||
|
||
选用金融官网、纯前端站点、Web＋worker、仅邮箱作小例子。可以画业务能力模块，不把模块框等同独立服务、数据库或团队岗位。长期应用目录面向各行业，具体首期支持清单仍待验证。
|
||
|
||
## G02 领域概念关系图
|
||
|
||
目标：帮助同事准确理解关系，减少旧命名约束带来的误会。
|
||
|
||
主线应包含客户、可选单层项目组、项目、APP、运行组件和资源/独立服务，明确“项目可有零到多个 APP；APP 可有多个组件；组件引用所需资源；同资源多引用只计一份购买项”。
|
||
|
||
图中必须说明：
|
||
|
||
- APP 是完整软件，Web/worker 不必各自算一个 APP；应用预设决定必需与可选依赖。
|
||
- 同集群同环境项目默认同 namespace，namespace 不是数据库身份/自动共享授权。资源用显式关系绑定。
|
||
- 数据库/存储归属、引用与付费项分别表示，共享不重复收费；项目可零到多个数据库。
|
||
- 一个工单属于一个项目，可涉及多个 APP；项目发布组合关联实际版本，不要求所有仓库同名或同一 Git 提交。
|
||
- 跨项目可 API 协作，平台公共 API 是客户订阅权益；项目组不自动授权互通。客户项目组与价格客户组用不同术语。
|
||
|
||
示例建议分三块：金融官网及必需资源、官网和 worker 共用数据、评价网与内容中心分属项目通过 API 协作。仅邮箱以“零 APP”角标表达。详细费用与全部版本字段留 G05/正文，避免关系线过多。
|
||
|
||
## G03 购买与开通泳道图
|
||
|
||
建议泳道：客户、平台业务处理、自动开通能力、内部人员。箭头表达实际步骤/交接，不能把后台推理日志当客户步骤。
|
||
|
||
主流程：案例预选或目录选择 → 普通应用/必需配置/选配服务，或高级 APP/资源配置 → 年付套餐及积分合计 → 充值余额不足则充值 → 确认消耗真实积分 → 开通任务状态 → 检查实际服务可用 → 项目访问入口及成功邮件。
|
||
|
||
关键分支：
|
||
|
||
- 普通单 APP 与高级多 APP 是两种界面，汇合至相同订单/开通模型。
|
||
- 付款不等于开通，各购买服务可能部分完成或等待人工账号准备；开通失败走人工排查，不新增首期系统内退款分支。
|
||
- 默认域只受保护预览，正式访问可绑定自有域名或平台代购；试用赠送部署不能走正式域名路径。
|
||
- 完成通知失败不把已经开通的服务改为失败。仅邮箱不创建无关 Web 资源。
|
||
|
||
主图只画首期正式购买；新客赠送仅注记后续，授予/升级细则不画成已确定流程。
|
||
|
||
## G04 定制工单处理泳道图
|
||
|
||
建议泳道：客户、平台工单、自动执行能力、人工团队、发布/运行检查。客服/TG作为旁侧沟通渠道，不成为每张工单必经的会话。
|
||
|
||
共同起点：项目创建可提交 → 固定文字/附件修订 → 选择自动/人工 → 检查执行条件（应用/版本、权益/积分）。
|
||
|
||
自动路径：需求分析 → 可处理则开发 → 内部验收 → 有限修复 → 发布 → 运行核验 → 摘要/版本/预览回执。需要人工则转换同一工单，保留原需求、执行与消耗。
|
||
|
||
人工路径：内部评估 → 设置金额 → 客户同意/拒绝 → 满足消费条件后人工处理 → 验证并上线 → 系统回执。拒绝仅停止本次改动，不停掉已有有效项目。
|
||
|
||
异常路径：发布前失败保留旧版；发布后新版不可运行进入恢复并核验，恢复异常人工接管；失败回执后可修订同范围需求再试，新增业务范围另工单。余额不足停止新调用，任务信息保留。
|
||
|
||
收费角标：所有真实项目 AI 调用含失败、修复、人工辅助与转人工均消耗权益，先抵扣包含用量，超额扣充值积分；回退不退已消耗费用。循环必须显示停止条件，不能画无限“直到成功”。代码更新、引擎成功和实际上线三个结果要区分。
|
||
|
||
技术细节如 Git 服务、Dify、队列、重试参数用概念或“待选执行器”表达，不在主图中定案。源码/数据库技术变更可展开明细，客户回执先讲完成了什么。
|
||
|
||
## G05 收费与权益关系图
|
||
|
||
目标：让同事理解钱从哪里来、什么被扣、哪些权益不能混用，而不是展示复杂计费公式。
|
||
|
||
建议画三类权益池并明确用途：
|
||
|
||
1. 真实充值积分：正式套餐/服务消费及超额 AI；推荐设计默认 1 USD = 100 积分，允许小数。
|
||
2. 年付套餐内含 AI 用量：正式项目可用，消耗完以后扣充值积分；年付开发/运维可合并套餐，熟客固定服务费使合计符合合作价。
|
||
3. 后续新客测试赠送：仅测试预览、禁正式域名、可撤销/销毁，不能转真实余额或支付正式年付服务；授予细则未定。
|
||
|
||
展示一个简单算例：AI 实际成本 1 USD，20% 加价，超额应扣 120 积分。注明计算依据为实际调用成本，不按满意成果、文件数量或普通 token 总数统一单价计费；失败和修复真实调用同样消耗。
|
||
|
||
年度套餐包含开发/运维，不画提前退役按月退款；域名/邮箱独立年度服务。人工新增需求金额独立确认，同一 AI 调用不重复计费。真实余额与测试权益不得只画成一个总余额。
|
||
|
||
## G06 项目生命周期状态图
|
||
|
||
目标：解释资源何时存在、数据何时保留、代码何时归档。
|
||
|
||
图分正常开通、主动退役、到期未续费三条路径。候选状态标签是为了表达业务，具体枚举由技术设计进一步确定，不能误当已建数据库字段。
|
||
|
||
- 正常：等待开通 → 开通中 → 运行中；异常进入人工核查/重试，核验后恢复正常流程。
|
||
- 主动退役：客户确认 → 停运行并按引用释放数据资源/相关备份 → 代码及启动配置归档；不退款，后续再部署是新业务数据初始化。
|
||
- 到期：提前邮件 → 未续费停外部访问/停止相关运行 → 业务数据最多保留一周 → 期内续费条件满足则恢复，或期满清除并归档。
|
||
|
||
注明主动退役与到期保留是不同触发规则。共享资源有其他有效引用时不能销毁；最后引用释放期三天只是候选，不画成固定 SLA。域名/邮箱等独立年度服务不要用项目状态一键注销。
|
||
|
||
此图不承诺退役数据恢复；运行期间工单回退的数据保护仍属另一能力，不因退役清除规则取消正常运行备份。
|
||
|
||
## G07 首期与后续范围图
|
||
|
||
采用分栏范围图，不画甘特日期：
|
||
|
||
- 首期方向：熟客普通账户、自助年付套餐和充值积分、配置/开通与状态、固定运维、有限自动 AI、人工接续、工单原件/回执/版本、保护预览、代码归档退役和到期处理。具体应用、自动任务及高级组合支持清单还需阶段 6/7 验证。
|
||
- 后续业务：公开新客赠送策略与试用转正式、克隆、组织/成员授权、例外按月退役结算等。
|
||
- 待技术评审：数据库/执行进程边界、工作流/Git、附件安全与格式实现、减配能力、供应商适配、迁移/恢复。
|
||
|
||
外部托管数据库/存储及公共 API 属目标能力，是否进入哪个实施版本仍待决定，不能自动标为二期承诺。图中也要区分“首期熟客”与“长期公开获客”，避免领导误以为只建内部录入工具。
|
||
|
||
## G08 业务数据流技术附图
|
||
|
||
目标：与开发讨论谁保存何种信息，技术选型暂留空。可先画一个简化业务流：需求/附件 → 平台工单与修订 → 执行输入（APP/基准/权益） → 代码/产物/检查结果 → 发布 → 运行核验 → 工单回执；AI 实际消耗 → 权益抵扣/积分账目，客服记录旁侧独立。
|
||
|
||
建议明确平台业务记录、Git 工程记录、客户应用业务数据和供应商用量记录四类数据。图中的数据记录位置是逻辑责任，不代表四个数据库、四个微服务或已选厂商。
|
||
|
||
外部执行器/回调或查询、Issue/PR同步、发布核验、故障核对是待技术评审接口，用虚线标注。保持平台工单为业务主记录，不能靠引擎输出“成功”关闭工单，也不能给测试赠送正式资源权限。后续技术图再明确进程、数据库、队列、协议和网络。
|
||
|
||
## 会议讲解顺序
|
||
|
||
建议依次讲：为什么做和卖什么（G01）→ 项目怎样组成（G02）→ 客户怎样买到可运行应用（G03）→ 怎样定制并交付（G04）→ 怎样收钱（G05）→ 何时停止/保留什么（G06）→ 首期边界与下一阶段取舍（G07）。开发会再进入 G08。
|
||
|
||
只做简短汇报时用 G01/G03/G04/G05/G07，G02/G06作为问题展开页。每页保留一个结论和少量关键规则，完整分支以文档为准，不要求投影上阅读所有脚注。
|
||
|
||
## 后续绘制与维护要求
|
||
|
||
- 首次生成优先 G01，再 G02–G05，随后补 G06/G07；逐张核对，不一次让所有图共同引入新假设。
|
||
- 可交付 SVG、用于会议的 PNG 和可编辑源文件；源码放本目录 `diagrams` 下，按图号命名。具体绘图工具生成时选择，不预设 Figma、某个 AI 或特定账号。
|
||
- 主图面向横向投影/单页展示，中文、字大、留白足、关系线清楚；复杂局部拆图。图中用实线表示确认业务，虚线和文字标签表示候选/后置，不只靠颜色区分。
|
||
- 每张图写图号、日期、业务基线、源文档/决定及确认状态；SVG/PNG只是展示产物，可编辑来源和正文共同保留。
|
||
- 已确认的技术方案出现后再画技术架构/ER/部署图。图内节点不与微服务、数据库表或现网命名自动等同。
|
||
- 业务修订时同时更新受影响图及本清单状态；图与正文冲突以明确人类决定为依据核查，不能只看哪个文件新。
|
||
- 正式生成时做可读性、箭头/泳道/标签、规则一致性和导出检查，随后更新 07/08 和追加交接。本轮成果与校验见 H0003；G06–G08仍不能当作已生成。
|