Demo 演示方案

文档版本：v1.0
更新日期：2025-01
作者：B2B2B Hotel Platform Team
演示目标受众：投资人 / 技术合伙人 / 潜在代理商

1. 演示目标

本次 Demo 演示的核心目标分为以下三个层面：

1.1 向投资人展示系统的核心价值

• 市场机会：中国 OTA B2B 酒店分销市场规模超 2000 亿元，但中间环节效率低下， 供应商分散、价格不透明、响应不及时，存在巨大的聚合优化空间。
• 商业模式清晰：通过聚合多供应商、服务多代理商，以技术手段降低信息不对称， 赚取佣金差价和服务费。
• 可验证的 MVP：演示系统已具备从查价、试单到下单的完整链路，不是 PPT 创业。

1.2 证明 OPC + AI 模式的可行性

• OPC（One Person Company）可行性：演示系统如何通过 AI Agent 自动化 90% 的 运维和运营工作，使一个人即可管理多供应商、多代理商的复杂业务。
• AI 不是噱头：AI Agent 不是锦上添花的附加功能，而是系统运营的核心引擎， 负责异常检测、智能诊断、自动修复、知识沉淀等关键环节。
• 可复制性：展示了从 0 到 1 的完整技术栈，后续扩展到更多城市、更多供应商的 成本低、周期短。

1.3 展示技术能力（特别是 AI Agent 运营能力）

• 架构能力：微服务 + 事件驱动 + 分布式缓存，支撑高并发查价场景。
• AI Agent 能力：基于 LLM 的智能运维 Agent，能够理解业务上下文、分析日志、 生成诊断报告、自动推送告警。
• 工程素养：全链路 Trace、结构化日志、自动化测试、CI/CD 流程完备。

2. 演示环境

2.1 硬件需求

部署架构（单机全栈）：

┌─────────────────────────────────────────────────┐
│                  8C16G 云服务器                   │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐   │
│  │  Nginx   │  │ API GW   │  │   Frontend   │   │
│  │  (反向代理)│  │(Kong/APISIX)│ │  (Next.js)  │   │
│  └────┬─────┘  └────┬─────┘  └──────────────┘   │
│       │             │                            │
│  ┌────┴─────────────┴────────────────────────┐   │
│  │           后端微服务 (Go)                   │   │
│  │  ┌────────┐ ┌────────┐ ┌──────────────┐  │   │
│  │  │供应商服务│ │ 订单服务 │ │  价格服务    │  │   │
│  │  └────────┘ └────────┘ └──────────────┘  │   │
│  │  ┌────────┐ ┌────────┐ ┌──────────────┐  │   │
│  │  │代理商服务│ │ AI Agent│ │  通知服务    │  │   │
│  │  └────────┘ └────────┘ └──────────────┘  │   │
│  └───────────────────────────────────────────┘   │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐   │
│  │  Redis   │  │  MySQL   │  │  ClickHouse  │   │
│  │ (缓存+会话)│ │ (业务数据)│ │ (Trace+分析) │   │
│  └──────────┘  └──────────┘  └──────────────┘   │
│                                                   │
│  ┌──────────┐  ┌──────────┐                      │
│  │  MinIO   │  │  Kafka   │                      │
│  │(对象存储) │ │(消息队列) │                      │
│  └──────────┘  └──────────┘                      │
└─────────────────────────────────────────────────┘

2.2 软件环境

2.3 预置数据

2.4 数据准备脚本

# 一键初始化演示数据
make demo-init

# 包含以下步骤：
# 1. 创建数据库表结构（make db-migrate）
# 2. 导入 Mock 供应商配置
# 3. 生成酒店/房型数据（Faker 自动生成）
# 4. 生成 30 天历史数据（查价 + 订单）
# 5. 预热缓存（热门城市/日期组合）
# 6. 生成 AI 诊断报告样本
# 7. 启动所有服务并健康检查

3. 演示场景设计

场景一：查价聚合（核心价值）⭐⭐⭐

目标：展示系统最核心的能力——并行查询多个供应商并返回最优价格。

操作步骤：

1. 打开查价页面，输入查询条件：
2. 城市：上海
3. 入住日期：明天
4. 离店日期：后天
5. 入住人数：2 人

6. 房间数：1 间

7. 展示查询过程：

8. 前端实时显示每个供应商的查询状态（查询中 ✓ / 已返回 ✓ / 超时 ✗）
9. 展示并行查询的进度条，5 个供应商同时发起请求

10. 高亮显示返回时间：最快 200ms，最慢 1.2s，聚合总耗时 1.2s（取最慢）

11. 展示结果页面：

12. 按价格从低到高排序
13. 每个价格标注来源供应商
14. 支持按供应商、价格区间、酒店星级过滤

15. 标注"缓存命中"标签

16. 对比演示（关键）：

17. 第一次查询：耗时 1.2s（无缓存，全部走实时 API）
18. 第二次查询（相同条件）：耗时 15ms（缓存命中）
19. 用大字体标注："缓存加速 80 倍"

演示话术：

"您看到这个查询，5 个供应商同时查询，1.2 秒返回全量结果。如果用传统方式 逐个调用，至少需要 5 秒以上。更重要的是，同样的查询第二次只需要 15 毫秒， 这就是我们缓存层的价值——每天可以为代理商节省大量等待时间。"

场景二：供应商差异（为什么要聚合）⭐⭐

目标：直观展示同一酒店在不同供应商的价格差异，证明聚合的必要性。

操作步骤：

1. 在查价结果中，选择某酒店（如"上海外滩某酒店标准间"），展开详情

2. 展示该酒店在不同供应商的价格对比： ┌──────────────┬──────────┬──────────┬──────────┐ │ 供应商 │ 标准间 │ 大床房 │ 套房 │ ├──────────────┼──────────┼──────────┼──────────┤ │ 供应商A │ ¥388 │ ¥528 │ ¥888 │ │ 供应商B │ ¥412 │ ¥498 │ ¥920 │ │ 供应商C │ ¥365 │ ¥508 │ ¥850 │ │ 供应商D(真实) │ ¥395 │ ¥515 │ ¥898 │ │ 供应商E(不稳) │ ¥370 │ -- │ -- │ ├──────────────┼──────────┼──────────┼──────────┤ │ ✅ 最优价格 │ ¥365 │ ¥498 │ ¥850 │ │ 💰 最大差价 │ ¥47 │ ¥30 │ ¥70 │ └──────────────┴──────────┴──────────┴──────────┘

3. 高亮最大差价：标准间相差 ¥47，占比 12.8%

演示话术：

"同一间酒店、同一时间，5 个供应商的价格差可以达到 12% 以上。如果代理商只接 入 1-2 个供应商，很可能给客户报了高价，流失订单。我们的聚合系统自动为代理商 找到最优价格，这就是我们的核心价值。"

场景三：试单流程（端到端闭环）⭐⭐⭐

目标：展示从查价到下单的完整业务闭环。

操作步骤：

1. 查价：输入条件，选择最优价格房型
2. 试单（Pre-Book）：
3. 点击"预订"按钮
4. 系统向供应商发起试单请求
5. 展示试单状态：提交中 → 供应商确认中 → 试单成功（返回 Order ID）
6. 展示试单耗时：约 2-3 秒
7. 确认订单（Confirm）：
8. 在试单有效期内（通常 10 分钟），点击"确认预订"
9. 展示订单确认状态

10. 展示生成的订单号和供应商订单号

11. 展示试单成功率监控：

12. 打开监控面板，展示各供应商试单成功率
13. 供应商A: 98.5%, 供应商B: 95.2%, 供应商C: 88.7%
14. 低成功率的供应商会被标记为"需关注"

演示话术：

"酒店预订有一个行业特点：查到的价格不一定能订到，房间可能已经被订走了。 所以我们有'试单'这个环节——先锁定房间再让客户付款。试单成功率直接影响客户 体验，我们通过 AI 实时监控每个供应商的试单成功率，低于阈值自动告警。"

场景四：精细化管控（运营能力）⭐⭐

目标：展示系统对供应商和代理商的精细化管理能力。

4.1 供应商熔断演示

操作步骤：

1. 打开供应商管理面板，展示 5 个供应商的健康状态
2. 模拟供应商E不稳定：通过脚本让供应商E的接口延迟升高到 5 秒
3. 展示熔断过程：
4. 第 1 次超时：触发告警（黄色）
5. 连续 3 次超时：自动熔断（红色），停止向该供应商发送请求
6. 剩余 4 个供应商继续正常服务
7. 查价结果中不再出现供应商E的价格
8. 恢复供应商E：延迟恢复正常后，半开探针请求成功，自动恢复

页面展示：

供应商状态面板：
  供应商A  ████████████████  健康  延迟 200ms
  供应商B  ████████████████  健康  延迟 350ms
  供应商C  ██████████████░░  注意  延迟 800ms
  供应商D  ████████████████  健康  延迟 280ms
  供应商E  ░░░░░░░░░░░░░░░░  🔴 熔断  连续超时 3 次
            [自动恢复倒计时: 30s]

4.2 代理商管控演示

操作步骤：

1. 切换到代理商 Agent-B 的视角
2. 展示管控规则：
3. 价格策略：在供应商价格基础上加价 15%
4. 供应商白名单：不允许查看供应商E的价格（因质量不稳定）
5. 最低利润率：每单最低 ¥20
6. 演示效果：
7. Agent-B 查价结果只有 4 个供应商的价格
8. 所有价格均加价 15%
9. 某房型加价后利润不足 ¥20 的，自动标记"不推荐"

演示话术：

"每个代理商有自己的价格策略和供应商偏好。系统能做到千店千面——同一个酒店， 不同的代理商看到不同的价格。供应商熔断是全自动的，不需要人工干预，这就是 AI Agent 带来的运营效率提升。"

场景五：AI Agent 运营（最大亮点）⭐⭐⭐⭐⭐

目标：这是整个 Demo 的高潮，展示 AI Agent 如何实现自动化运营。

5.1 AI 异常检测

操作步骤：

1. 模拟异常：通过脚本让供应商C的查价成功率从 95% 下降到 60%
2. 展示 AI 检测过程：
3. 监控面板实时显示成功率下降曲线（红色标记）
4. AI Agent 在 2 分钟内自动识别异常
5. 飞书通知弹出："⚠️ 检测到供应商C查价成功率异常下降"
6. AI 自动分析原因："初步判断：供应商C接口响应超时比例增加， 超时率从 2% 上升到 35%，建议检查供应商侧服务状态"

5.2 AI 智能诊断

操作步骤：

1. 在飞书/管理后台，输入一个订单号（如 ORD-20250115-0042）
2. AI Agent 自动拉取完整诊断报告： ``` 📋 订单诊断报告 - ORD-20250115-0042

🔍 基本信息 - 酒店：上海外滩某酒店 - 房型：标准大床房 - 入住：2025-01-15 ~ 2025-01-16 - 代理商：Agent-A - 供应商：供应商B

📊 性能数据 - 查价耗时：856ms（缓存未命中） - 试单耗时：2.3s - 确认耗时：1.1s - 全链路耗时：4.2s

🔄 完整链路 [14:23:01.234] 查价请求 → 并行查询 5 个供应商 [14:23:01.856] 供应商B 返回最优价格 ¥395 [14:23:05.100] 试单请求 → 供应商B [14:23:07.400] 试单成功 → 获得供应商订单号 SUP-B-78901 [14:23:08.500] 确认预订 → 订单确认

💡 AI 分析 - 本次查询缓存未命中，建议预热该城市/日期组合 - 查价耗时偏高（>800ms），主要瓶颈在供应商E超时 - 供应商B 试单耗时正常（<3s） ```

5.3 AI 知识库

操作步骤：

1. 打开 AI 知识库页面
2. 展示自动沉淀的故障经验：
3. "供应商C超时故障处理"（自动归档）
4. "供应商E熔断恢复流程"（自动归档）
5. "代理商Agent-B价格策略优化建议"（AI 生成）
6. 演示搜索："供应商超时怎么办？" → AI 返回相关故障案例和处理方案

演示话术：

"这是整个系统最核心的差异化能力。传统的酒店 B2B 平台，需要运维团队 7x24 小时 盯监控、查日志、处理故障。我们用 AI Agent 替代了 90% 的运维工作——它自动检测 异常、自动诊断问题、自动推送告警、自动沉淀知识。这意味着，一个人就能运营 整个平台，运营成本降到传统模式的十分之一。"

场景六：全链路 Trace（工程能力）⭐⭐

目标：展示系统的可观测性和工程素养。

操作步骤：

1. 打开 Trace 查询页面，输入订单号
2. 展示完整调用链的瀑布图： ``` 查价请求 (1145ms) ├── 缓存查询 (2ms) ❌ MISS ├── 供应商A 查询 (312ms) ✅ 200 条结果 ├── 供应商B 查询 (456ms) ✅ 180 条结果 ├── 供应商C 查询 (1100ms) ✅ 150 条结果 ├── 供应商D 查询 (280ms) ✅ 190 条结果 └── 供应商E 查询 (1145ms) ❌ TIMEOUT 结果聚合 + 缓存写入 (8ms)

试单请求 (2310ms) ├── 价格校验 (5ms) ├── 库存锁定 (10ms) ├── 供应商B 试单 (2200ms) ✅ 成功 └── 确认回调 (95ms)

订单确认 (1105ms) ├── 支付状态校验 (5ms) ├── 供应商B 确认 (1000ms) ✅ 成功 └── 订单状态更新 (100ms) ```

1. 点击任一节点，展示详细日志和 Span 属性

2. 展示 Trace 数据存储：ClickHouse 中存储了全部链路数据， 支持按时间、供应商、代理商等维度查询

演示话术：

"全链路 Trace 是工程能力的基础设施。每次查价、试单、确认，我们都能追踪到 每一毫秒花在哪里、哪个供应商慢了、哪个环节出了问题。这不仅是运维工具， 更是业务优化的数据基础——我们知道哪里有瓶颈，就知道在哪里优化。"

场景七：数据看板（经营全景）⭐⭐

目标：展示系统的数据驱动经营能力。

操作步骤：

1. 打开数据看板，展示以下内容：

实时监控

• 实时 QPS：当前查询速率，如 12 req/s
• 成功率：查价成功率 96.2%，试单成功率 94.8%
• P99 延迟：查价 P99 = 1.8s，试单 P99 = 3.2s
• 缓存命中率：65.3%（30 天平均）

供应商健康度矩阵

┌──────────┬────────┬────────┬────────┬────────┬────────┐
│  供应商   │ 可用性  │ 响应时间 │ 价格竞争力│ 试单成功率│ 综合评分│
├──────────┼────────┼────────┼────────┼────────┼────────┤
│ 供应商A   │ 99.9%  │ 200ms  │ ⭐⭐⭐  │ 98.5%  │  92    │
│ 供应商B   │ 99.5%  │ 350ms  │ ⭐⭐⭐⭐│ 95.2%  │  88    │
│ 供应商C   │ 98.2%  │ 800ms  │ ⭐⭐⭐⭐⭐│ 88.7%  │  82    │
│ 供应商D   │ 99.8%  │ 280ms  │ ⭐⭐⭐  │ 97.1%  │  90    │
│ 供应商E   │ 85.0%  │ 3000ms │ ⭐⭐⭐⭐ │ 72.3%  │  65    │
└──────────┴────────┴────────┴────────┴────────┴────────┘

收入趋势

• 30 天收入趋势图：日均订单 16 单，日均佣金 ¥1,280
• 月累计佣金：¥38,400
• 月运营成本：¥12,000（服务器 ¥5,000 + API 调用 ¥4,000 + 其他 ¥3,000）
• 月净利润：¥26,400

演示话术：

"这是我们过去 30 天的运营数据。日均 16 单，每单平均佣金 ¥80，月净利润超过 ¥26,000。这只是 2 个代理商、5 个供应商的数据，如果扩展到 20 个代理商， 月收入可以轻松突破 20 万。而且由于 AI Agent 的自动化运营能力，边际成本 增长非常缓慢。"

4. 演示脚本（时间线）

4.1 总体时间安排

总计：25 分钟

4.2 详细脚本

Phase 1：开场介绍（0:00 - 2:00）

[0:00] 自我介绍 + 一句话定位
"大家好，我是 XXX。我们在做的是一个 B2B2B 酒店分销聚合平台，
 用 AI Agent 实现一个人运营整个平台。"

[0:30] 市场背景
"中国 OTA B2B 酒店分销市场规模超 2000 亿，但行业效率极低——
 供应商分散、价格不透明、运维成本高。我们用技术解决这个问题。"

[1:00] 解决方案概述
"我们的系统做三件事：1）聚合多供应商实时查价；2）服务多代理商差异化定价；
 3）用 AI Agent 自动化 90% 的运维运营工作。"

[1:30] 演示预告
"接下来我会用 20 分钟展示这三个能力的实际运行效果。"

Phase 2：查价聚合（2:00 - 5:00）

[2:00] 操作：打开查价页面，输入查询条件
"我们先看最核心的功能——查价。上海，明天入住，2 人 1 间。"

[2:30] 展示：并行查询过程
"您可以看到，5 个供应商在同时查询，进度实时展示。"

[3:00] 展示：结果页面 + 价格排序
"结果已经出来了，1.2 秒。价格从低到高排列，每个价格都标注了供应商来源。"

[3:30] 关键对比：缓存加速
"再看一次同样的查询——15 毫秒！缓存加速 80 倍。每天代理商要查几百次价格，
 这节省的时间和 API 成本是巨大的。"

[4:00] 展示：过滤和筛选
"代理商可以按供应商、价格、星级来筛选。比如只要 4 星以上、300 元以下的。"

[4:30] 过渡
"但光看价格还不够，我们来看一个关键问题——不同供应商的价格差异有多大？"

Phase 3：供应商差异（5:00 - 7:00）

[5:00] 操作：选择某酒店，展开价格对比
"同样的酒店、同样的时间，您看这个价格对比表——"

[5:30] 展示：价格差异表格
"标准间最高 412，最低 365，差价 47 块，差了 12.8%。
 如果代理商只接入一个供应商，很可能给客户报高价。"

[6:00] 展示：供应商覆盖不全的问题
"更极端的情况——供应商E连大床房和套房都查不到。
 如果代理商只接了供应商E，就白白流失了这些订单。"

[6:30] 过渡
"查到价格之后，怎么下单呢？我们来看试单流程。"

Phase 4：试单流程（7:00 - 10:00）

[7:00] 操作：从查价结果选择房型，点击预订
"选最优价格，点击预订。系统会先试单——先锁定房间。"

[7:30] 展示：试单过程
"试单请求已发出... 2.3 秒后返回成功，获得了供应商订单号。
 在试单有效期内，代理商可以确认预订。"

[8:00] 操作：确认预订
"点击确认——订单完成。整个过程不超过 5 秒。"

[8:30] 展示：试单成功率监控
"我们来看各供应商的试单成功率。供应商A 98.5%，
 供应商C 只有 88.7%——这意味着每 10 次预订有 1 次会失败。
 这个数据我们会实时监控。"

[9:00] 展示：订单列表
"这是今天的订单列表，每个订单都有完整的链路追踪。"

[9:30] 过渡
"这么复杂的系统，怎么保证稳定性？我们来看精细化管控能力。"

Phase 5：精细化管控（10:00 - 13:00）

[10:00] 展示：供应商健康面板
"这是供应商健康面板。5 个供应商，实时监控状态。"

[10:30] 操作：模拟供应商E不稳定
"我模拟一下供应商E出故障的情况——接口延迟升高到 5 秒。"

[11:00] 展示：自动熔断过程
"注意看——第一次超时，告警。连续 3 次超时，自动熔断！
 系统不再向供应商E发送请求，其余 4 个供应商正常服务。
 30 秒后自动探测恢复——恢复成功，自动打开。整个过程无需人工干预。"

[12:00] 展示：代理商管控
"再看代理商管控。Agent-B 的策略：加价 15%，屏蔽供应商E。
 同样的查价，Agent-B 看到的结果完全不同。"

[12:30] 过渡
"这些管控能力虽然强大，但仍然需要人盯。如果我们让 AI 来做呢？"

Phase 6：AI Agent 运营（13:00 - 18:00）⭐ 重点

[13:00] 模拟异常：供应商C成功率下降
"我来模拟一个真实场景——供应商C的查价成功率突然从 95% 降到 60%。"

[13:30] 展示：AI 自动检测
"看这里——AI 在 2 分钟内自动检测到异常。"

[14:00] 展示：飞书通知
"飞书自动收到通知：检测到异常，初步判断是接口超时率上升。"

[14:30] 展示：AI 智能诊断
"我们在飞书里输入一个订单号，AI 自动拉出完整诊断报告。
 您看——从查价到确认的每一毫秒、每个环节都清晰可见。
 AI 还给出了优化建议。"

[15:30] 展示：知识库
"而且，这些故障经验会自动沉淀到知识库。下次遇到类似问题，
 AI 可以直接给出解决方案，不需要从零开始排查。"

[16:00] 强调核心价值
"这就是我们最大的差异化——AI Agent 不只是一个功能，而是整个运营体系的核心。
 传统平台需要 5-10 人运维团队，我们只需要 1 个人 + AI。
 运营成本降到十分之一。"

[17:00] 技术细节（简述）
"技术上，我们用 LLM 做语义理解和报告生成，用规则引擎做实时检测，
 用向量数据库做知识检索。三者协同，形成完整的 AI Agent 运营闭环。"

[17:30] 过渡
"最后我们快速看一下系统底层的工程能力。"

Phase 7：全链路 Trace（18:00 - 20:00）

[18:00] 操作：打开 Trace 页面，输入订单号
"这是刚才那个订单的完整调用链。"

[18:30] 展示：瀑布图
"查价 1.1 秒，其中供应商E 超时拖慢了整体。
 试单 2.3 秒，主要时间在供应商确认。
 全链路 4.2 秒，每个环节都有 Trace ID，可以追溯到具体日志。"

[19:00] 展示：ClickHouse 存储
"所有 Trace 数据存储在 ClickHouse，支持任意维度查询。
 我们可以按时间、供应商、代理商分析性能瓶颈。"

[19:30] 过渡
"最后看一眼经营数据。"

Phase 8：数据看板（20:00 - 22:00）

[20:00] 展示：实时监控指标
"实时 QPS 12，查价成功率 96%，P99 延迟 1.8 秒。"

[20:30] 展示：供应商健康度矩阵
"供应商综合评分一目了然，供应商E得分最低，和我们之前熔断的判断一致。"

[21:00] 展示：收入趋势
"过去 30 天，日均 16 单，月佣金 ¥38,400，净利润 ¥26,400。
 这只是 2 个代理商的数据。"

[21:30] 收尾
"总结一下——我们用技术聚合多供应商，用 AI Agent 实现一个人运营，
 MVP 已经跑通，月利润超过 2.6 万。谢谢大家，欢迎提问。"

Phase 9：Q&A（22:00 - 25:00）

参考第 5 章准备的问题和回答。

5. 投资人关注点

5.1 可能被问到的问题及标准回答

Q1："市场规模多大？"

回答要点： - 中国酒店 B2B 分销市场规模约 2000-3000 亿元/年 - OTA 平台（携程、美团、飞猪）占据 C 端主流，但 B2B 分销链条长、效率低 - 下游中小旅行社/差旅公司约 20 万家，每家年采购额 50-500 万不等 - 酒店供应商（含连锁/单体）约 30 万家，数字化程度参差不齐 - 聚合平台通过技术手段提升效率，有巨大的降本增效空间

Q2："你们和携程/美团有什么不同？"

回答要点： | 维度 | 携程/美团 | B2B2B 平台 | |------|----------|-------------| | 模式 | B2C 直销，面向终端消费者 | B2B2B 分销，面向代理商 | | 客户 | 个人用户 | 中小旅行社、差旅公司、TMC | | 价值 | 流量 + 品牌 | 价格聚合 + 技术服务 | | 竞争 | C 端流量争夺 | B 端效率提升 | | 关系 | 互补而非竞争 | 服务携程/美团的下游代理商 |

核心定位：我们不是携程的竞争对手，而是携程生态的效率补充。 中小旅行社从携程拿货价格高、选择少，我们从更多渠道聚合最优价格。

Q3："技术壁垒在哪？"

回答要点： 1. 供应商聚合技术：不同供应商 API 标准不一，需要统一抽象层。 我们设计了标准的 Supplier Adapter 接口，新增供应商只需实现接口，1-2 天接入。 2. AI Agent 运营能力：基于 LLM + 规则引擎 + 向量数据库的智能运维体系， 能自动检测异常、诊断问题、生成报告、沉淀知识。这是竞品没有的能力。 3. 精细化管控：供应商熔断、代理商差异化定价、试单成功率监控等， 这些都是实际运营中打磨出来的能力，需要深厚的行业理解。

Q4："为什么一个人能做？"

回答要点： - 传统平台运维团队：5-10 人（监控 1 人、告警处理 2 人、供应商对接 2 人、 客服 2 人、数据分析 1 人） - 我们用 AI Agent 替代： - 监控 + 告警处理 → AI 自动检测 + 飞书推送 - 供应商对接 → 标准 Adapter 接口，新增供应商半天搞定 - 客服 → AI 自动诊断 + FAQ 知识库 - 数据分析 → AI 自动生成运营报告 - 人力需求：1 人（产品+技术）+ AI Agent（7x24 自动运营）

Q5："怎么赚钱？"

回答要点：

收入模型： | 收入来源 | 模式 | 预估单价 | |----------|------|----------| | 佣金差价 | 供应商价格 + 加价 - 供应商成本 | ¥30-80/单 | | 服务费 | 代理商月费（增值服务） | ¥500-2000/月/代理商 | | API 接入费 | 供应商接入平台 | ¥0（早期免费） |

单位经济模型（单笔订单）： - 供应商成本：¥350（酒店结算价） - 代理商售价：¥420（含 ¥70 毛利） - 我们的佣金：¥30（从供应商返佣）+ ¥20（代理商服务费）= ¥50 - 单笔 API 成本：¥0.5 - 单笔净利润：¥49.5

Q6："需要多少钱？"

回答要点：

启动资金需求：5 万元

项目	金额	说明
云服务器（6个月）	¥18,000	8C16G × ¥3,000/月 × 6
域名 + SSL + 备案	¥500
供应商 API 预付费	¥5,000	测试和初期调用
飞书/企微企业版	¥2,400	AI 通知渠道
LLM API 费用（6个月）	¥3,000	AI Agent 用
预留流动资金	¥21,100	供应商垫资等
合计	¥50,000

融资计划： - 天使轮：50-100 万，出让 10-15% 股权 - 资金用途：60% 技术研发、20% 市场推广、20% 运营储备 - 目标：6 个月内实现月净利润覆盖 1 人工资（¥20,000+）

Q7："多长时间盈利？"

回答要点： - MVP 已盈利：月净利润 ¥26,400（2 个代理商数据） - 盈亏平衡点：月佣金 ¥12,000（覆盖服务器 + API 成本） - 扩展到 5 个代理商：预计月净利润 ¥60,000+ - 扩展到 20 个代理商：预计月净利润 ¥250,000+ - 结论：MVP 阶段已盈利，关键是代理商拓展速度

5.2 核心数据准备清单

在演示前，确保以下数据准确可用：

成本数据

收入模型

盈亏平衡分析

• 月固定成本：¥6,100
• 每单边际成本：¥0.50（API 调用）
• 每单佣金收入：¥80
• 盈亏平衡点 = ¥6,100 ÷ (¥80 - ¥0.50) ≈ 77 单/月
• 相当于 1 个代理商每月下 77 单（约每天 2.5 单）
• 结论：仅需 1 个活跃代理商即可覆盖运营成本

6. 风险与应对

6.1 风险矩阵

6.2 应急预案

演示现场可能出的问题及应对

精简版脚本（15 分钟）

6.3 演示前检查清单

• [ ] 服务器健康检查通过（make health-check）
• [ ] 所有服务启动正常（docker-compose ps）
• [ ] 预置数据初始化完成（make demo-init）
• [ ] 缓存已预热（热门查询条件）
• [ ] AI Agent 告警通道正常（飞书 Webhook 测试）
• [ ] 演示数据验证（查价结果、订单数据、Trace 数据）
• [ ] 备用网络就绪（手机热点）
• [ ] 演示脚本通读 2 遍以上
• [ ] Q&A 清单准备完毕
• [ ] 录屏备份（防止现场出问题可以播放录屏）

7. 附录

7.1 演示相关命令速查

# 启动全栈服务
make up

# 初始化演示数据
make demo-init

# 健康检查
make health-check

# 模拟供应商熔断
make demo-circuit-breaker

# 模拟 AI 告警
make demo-ai-alert

# 清理演示数据
make demo-clean

# 查看实时日志
make logs

# 查看 AI Agent 日志
make logs-ai

7.2 关键页面 URL

7.3 演示物料清单

• [ ] 笔记本电脑（充满电 + 充电器）
• [ ] HDMI/VGA 转接线
• [ ] 手机 + 热点
• [ ] 备用演示账号密码（写在纸上）
• [ ] 一页纸产品介绍（投给投资人带走）
• [ ] 名片

文档结束
下一步：根据演示反馈持续迭代优化。