# 第二轮专家讨论：技术架构与实现方案

> **讨论记录编号**: RD-2026-05-01-02
> **关联文档**: [第一轮讨论](./00-专家讨论总览.md) | [PRD](../1-PRD/01-GEO平台PRD-v1.0.md)
> **讨论日期**: 2026-05-01
> **状态**: 进行中

---

## 目录

1. [讨论背景与议程](#1-讨论背景与议程)
2. [技术架构评估](#2-技术架构评估)
3. [核心问题辩论](#3-核心问题辩论)
4. [架构决策记录 (ADR)](#4-架构决策记录-adr)
5. [技术选型共识](#5-技术选型共识)
6. [实施路线图](#6-实施路线图)
7. [风险评估](#7-风险评估)
8. [结论与后续行动](#8-结论与后续行动)

---

## 1. 讨论背景与议程

### 1.1 讨论背景

基于[第一轮专家讨论](./00-专家讨论总览.md)的结论，GEO平台已确定：
- **产品定位**: 专注中国市场的GEO品牌认知管理平台
- **核心功能**: AI曝光度评分、竞品对比、报告导出
- **MVP范围**: 7个国产AI平台覆盖

本轮讨论聚焦于：
1. 现有代码架构的评估与改进
2. 技术方案可行性验证
3. 关键技术决策

### 1.2 专家参与

| 专家 | 参与角色 | 贡献领域 |
|------|---------|---------|
| **埃隆·马斯克** | 第一性原理导师 | 技术成本重构、架构效率 |
| **梁文峰** | AI技术导师 | LLM集成、API设计 |
| **史蒂夫·乔布斯** | 产品设计导师 | 技术简化、用户体验 |
| **杰夫·贝索斯** | 可扩展性导师 | 多租户架构、长期扩展 |

### 1.3 讨论议程

```
议题 1: 现有架构评估 (14:00-14:45)
├── 梁文峰: LLM API vs Playwright 成本分析
├── 马斯克: 第一性原理审视现有架构
└── 乔布斯: 架构复杂性对产品的影响

议题 2: 核心模块设计 (14:45-15:30)
├── 梁文峰: 平台适配器统一接口设计
├── 乔布斯: 数据采集的极简体验
└── 贝索斯: 分析引擎的可扩展性

议题 3: 技术决策投票 (15:30-16:15)
├── 数据采集策略
├── 缓存方案
├── 多租户方案
└── API设计规范

议题 4: 风险与缓解 (16:15-17:00)
├── 识别主要风险
├── 制定缓解措施
└── 确认后续行动
```

---

## 2. 技术架构评估

### 2.1 现有架构分析

**现有技术栈** (来自代码审查):

| 组件 | 当前技术 | 评估 |
|------|---------|------|
| 后端框架 | Python FastAPI | ⭐⭐⭐⭐⭐ 合理 |
| 数据库 | PostgreSQL + SQLAlchemy 2.0 | ⭐⭐⭐⭐ 良好 |
| 任务调度 | APScheduler | ⭐⭐⭐⭐ 可用 |
| 前端框架 | Next.js 14 | ⭐⭐⭐⭐⭐ 合理 |
| UI组件 | shadcn/ui | ⭐⭐⭐⭐ 良好 |
| 数据采集 | Playwright | ⭐⭐ 需要优化 |

### 2.2 梁文峰视角: LLM API vs Playwright

**核心论点**: 现有Playwright爬虫方案存在根本性问题

```
成本对比分析:

Playwright方案:
- 每次查询成本: ~$0.10 (EC2 + Playwright启动)
- 响应时间: 30-60秒
- 成功率: ~70% (被反爬概率高)
- 维护成本: 高 (平台UI变更需同步更新)

LLM API方案:
- 每次查询成本: ~$0.001 (DeepSeek API)
- 响应时间: 3-5秒
- 成功率: ~99%
- 维护成本: 低 (Prompt固定即可)
```

**梁文峰建议**:
> "用LLM API直接查询，而非猜测AI平台的回答。物理本质上，AI引用品牌的本质是LLM的推理过程，而非网页爬取。"

### 2.3 马斯克视角: 第一性原理审视

**现有架构的问题** (基于第一性原理):

| 层级 | 现有方案 | 第一性原理审视 |
|------|---------|---------------|
| 数据采集 | Playwright模拟浏览器 | 应直接调用LLM API |
| 品牌匹配 | 字符串精确匹配 | 应使用LLM理解语义 |
| 竞品识别 | 预定义品牌库 | 应动态从响应中提取 |
| 成本结构 | 高计算成本 | 应优化到10%以下 |

**重构方向**:
```
从"爬虫+规则"到"API+AI理解"
```

### 2.4 乔布斯视角: 复杂性管理

**乔布斯核心观点**:
> "简单性来自于去除明显的部分，优雅来自于去除所有不必要的部分。"

**架构复杂性警告**:
```
当前架构问题:
1. 7个平台 = 7套适配器实现
2. 平台UI变更 = 代码更新
3. 维护成本随平台数量线性增长

简化方向:
1. 统一适配器接口
2. 抽象Prompt模板层
3. 配置驱动的平台支持
```

---

## 3. 核心问题辩论

### 3.1 辩题: 数据采集策略

**辩题**: 应当采用何种数据采集策略？

#### 正方: LLM API优先

**支持者**: 梁文峰、马斯克

**论点**:
1. 成本低 (降低90%+)
2. 效果好 (语义理解 vs 字符串匹配)
3. 稳定性高 (不受平台UI变更影响)
4. 速度快 (秒级 vs 分钟级)

**证据**:
```
DeepSeek API成本:
- DeepSeek-V3: $0.27/百万tokens
- 假设每次查询消耗1000 tokens: $0.00027/次

vs Playwright成本:
- 每次查询 EC2 t3.medium: ~$0.005
- 加上Playwright启动: ~$0.01-0.10
```

#### 反方: Playwright保留

**支持者**: (需要更多数据采集场景)

**论点**:
1. LLM API可能有内容安全限制
2. 某些平台API不支持直接调用
3. 需要原始网页内容作为验证

#### 共识结论

```
最终策略: LLM API为主，Playwright兜底

架构设计:
┌─────────────────────────────────────────┐
│           CitationEngine                │
│  ┌─────────────────────────────────┐    │
│  │     LLM Adapter (主要)          │    │
│  │     - DeepSeek                  │    │
│  │     - GPT-4o-mini (备份)        │    │
│  └─────────────────────────────────┘    │
│  ┌─────────────────────────────────┐    │
│  │     Playwright Adapter (兜底)    │    │
│  │     - 仅当LLM不可用时启用       │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
```

### 3.2 辩题: 平台适配器设计

**辩题**: 如何设计统一的平台适配器接口？

#### 梁文峰方案: 统一Prompt抽象

```python
# 梁文峰建议的架构
class BasePlatformAdapter:
    """统一的平台适配器接口"""

    def build_prompt(self, keyword: str, brand: str) -> str:
        """构建查询Prompt"""
        return f"查询: {keyword}。请判断{brand}品牌是否被提及。"

    def parse_response(self, raw_response: str) -> CitationResult:
        """解析LLM响应"""
        # 使用LLM理解语义，非规则匹配
        pass
```

#### 马斯克方案: 简化到极致

```python
# 马斯克建议: 只需要一个统一接口
class CitationService:
    async def query(
        self,
        keyword: str,
        brand: str,
        platforms: list[str]
    ) -> CitationResult:
        # 单一方法处理所有平台
        pass
```

#### 共识结论

```
采用分层适配器架构:

Layer 1: CitationService (核心业务)
    ↓ 调用
Layer 2: LLMAdapter / PlaywrightAdapter (采集策略)
    ↓ 调用
Layer 3: PlatformAdapters (文心/kimi/通义等)
```

### 3.3 辩题: 缓存策略

**辩题**: 如何设计缓存以降低API成本？

#### 乔布斯观点: 缓存即简单性

```
缓存设计原则:
1. 不缓存的数据: 实时查询结果
2. 可缓存的数据:
   - 品牌基础信息 (TTL: 24h)
   - 平台配置 (TTL: 1h)
   - 统计聚合数据 (TTL: 5min)
3. 缓存粒度: 按 (keyword, brand, platform, date)
```

#### 梁文峰方案: 多级缓存

```
缓存层级:
L1: 内存缓存 (进程内) - 热点数据
L2: Redis缓存 (分布式) - 共享数据
L3: 数据库 (持久化) - 历史数据

缓存策略:
- 查询结果: 不缓存 (数据时效性)
- 评分计算: 缓存5分钟
- 统计报表: 缓存1小时
```

---

## 4. 架构决策记录 (ADR)

### ADR-001: 数据采集策略

**编号**: ADR-001
**日期**: 2026-05-01
**状态**: 已通过

**问题**: 现有Playwright爬虫方案成本高、稳定性差

**决策**: 采用LLM API为主，Playwright兜底的混合策略

**选项对比**:

| 选项 | 成本 | 效果 | 维护 | 决策 |
|------|------|------|------|------|
| 仅Playwright | 高 | 一般 | 高 | 拒绝 |
| 仅LLM API | 低 | 好 | 低 | 风险 |
| 混合策略 | 中 | 好 | 中 | **通过** |

**后果**:
- 正面: 成本降低80%+，稳定性提升
- 负面: 需要额外的LLM API密钥管理

### ADR-002: 平台适配器接口

**编号**: ADR-002
**日期**: 2026-05-01
**状态**: 已通过

**问题**: 如何统一7个AI平台的适配器

**决策**: 采用统一的抽象接口 + 配置驱动的实现

```python
# 统一接口
class PlatformAdapter(ABC):
    platform_name: str
    platform_config: PlatformConfig

    @abstractmethod
    async def query(self, keyword: str, context: QueryContext) -> QueryResult:
        pass

    @abstractmethod
    def build_prompt(self, keyword: str, context: QueryContext) -> str:
        pass
```

### ADR-003: 评分计算服务

**编号**: ADR-003
**日期**: 2026-05-01
**状态**: 已通过

**问题**: 如何实现评分算法的灵活扩展

**决策**: 策略模式 + 配置化

```python
# 评分策略
class ScoringStrategy(ABC):
    @abstractmethod
    def calculate(self, citations: list[Citation]) -> Score:
        pass

# 具体策略
class DefaultScoring(ScoringStrategy):
    weights = {
        "mention_rate": 0.3,
        "sov": 0.4,
        "quality": 0.3
    }

# 配置驱动
score_config = {
    "strategy": "default",
    "weights": {...}
}
```

---

## 5. 技术选型共识

### 5.1 核心技术决策

| 决策项 | 选中方案 | 备选方案 | 决策依据 |
|--------|---------|---------|---------|
| 数据采集 | LLM API + Playwright兜底 | 仅LLM API | 梁文峰分析 |
| LLM选择 | DeepSeek-V3优先 | GPT-4o-mini | 成本效益最优 |
| 缓存层 | Redis | Memcached | 已有技术栈 |
| 任务队列 | APScheduler + Redis | Celery | 简化架构 |
| API文档 | OpenAPI/Swagger | 其他 | FastAPI原生支持 |

### 5.2 架构重构目标

```
重构前 (现有架构):
┌─────────┐    ┌──────────┐    ┌──────────┐
│ Playwright│ → │ 字符串匹配│ → │  数据存储 │
└─────────┘    └──────────┘    └──────────┘

重构后 (目标架构):
┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ LLM API │ → │ 语义理解  │ → │ 评分计算 │ → │  数据存储 │
└─────────┘    └──────────┘    └──────────┘    └──────────┘
```

### 5.3 模块职责划分

| 模块 | 职责 | 负责人 | 依赖 |
|------|------|--------|------|
| CitationEngine | 核心引用检测引擎 | 待定 | LLMAdapter |
| LLMAdapter | LLM API调用封装 | 待定 | DeepSeek API |
| PlatformAdapter | 各平台适配 | 待定 | CitationEngine |
| ScoringService | 评分计算 | 待定 | CitationEngine |
| CacheService | 缓存管理 | 待定 | Redis |
| SchedulerService | 任务调度 | 待定 | APScheduler |

---

## 6. 实施路线图

### 6.1 第一阶段: 架构重构 (2周)

**目标**: 建立新的技术基础

| 任务 | 负责人 | 工期 | 验收标准 |
|------|--------|------|---------|
| LLMAdapter开发 | 待定 | 3天 | 支持DeepSeek/GPT |
| 平台适配器重构 | 待定 | 5天 | 7个平台统一接口 |
| 评分服务重构 | 待定 | 3天 | 可配置权重 |
| 缓存层实现 | 待定 | 2天 | Redis集成 |
| 集成测试 | 待定 | 2天 | 全流程测试通过 |

### 6.2 第二阶段: 功能开发 (4周)

**目标**: 完成MVP功能

| 功能模块 | 工期 | 验收标准 |
|---------|------|---------|
| 品牌管理 | 1周 | CRUD + 竞品管理 |
| 数据采集 | 1.5周 | 7平台覆盖 |
| 分析引擎 | 1周 | 评分 + 对比 |
| 报告导出 | 0.5周 | PDF + CSV |

### 6.3 第三阶段: 优化上线 (2周)

**目标**: 性能优化与发布

| 任务 | 工期 | 目标 |
|------|------|------|
| 性能优化 | 1周 | P99 < 500ms |
| 安全审计 | 0.5周 | 无高危漏洞 |
| 部署上线 | 0.5周 | 生产可用 |

---

## 7. 风险评估

### 7.1 技术风险

| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|
| LLM API成本超预期 | 中 | 高 | 设置预算告警，优先使用DeepSeek |
| 平台API变更 | 高 | 中 | 设计变更检测，自动告警 |
| 数据一致性 | 低 | 高 | 事务 + 幂等性设计 |
| 性能瓶颈 | 中 | 中 | 异步 + 缓存 |

### 7.2 业务风险

| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|
| 用户增长超预期 | 低 | 中 | 水平扩展架构 |
| 竞争对手模仿 | 高 | 中 | 快速迭代，建立数据壁垒 |
| 合规要求 | 中 | 中 | 预留合规改造时间 |

### 7.3 成本估算

**基于LLM API方案**:

| 成本项 | 单价 | 估算用量 | 月成本 |
|--------|------|---------|-------|
| DeepSeek API | ¥0.1/千次 | 10万次/月 | ¥1,000 |
| Redis | ¥200/月 | 1实例 | ¥200 |
| PostgreSQL | ¥500/月 | 1实例 | ¥500 |
| 服务器 | ¥1000/月 | 2台 | ¥2,000 |
| **合计** | | | **¥3,700/月** |

---

## 8. 结论与后续行动

### 8.1 关键决策总结

| 决策 | 结论 | 负责人 |
|------|------|--------|
| 数据采集策略 | LLM API为主，Playwright兜底 | 待定 |
| 适配器架构 | 统一接口 + 配置驱动 | 待定 |
| 评分算法 | 策略模式 + 可配置权重 | 待定 |
| 缓存方案 | Redis多级缓存 | 待定 |

### 8.2 待办事项

| 待办 | 负责人 | 截止日期 | 状态 |
|------|--------|---------|------|
| 详细技术设计文档 | 技术负责人 | +3天 | 进行中 |
| LLMAdapter原型开发 | 开发团队 | +1周 | 待开始 |
| 平台适配器接口定义 | 架构师 | +3天 | 待开始 |
| 成本效益分析报告 | 产品经理 | +1周 | 待开始 |

### 8.3 下次会议

| 项目 | 内容 |
|------|------|
| 时间 | 2026-05-08 |
| 议题 | 原型评审、技术设计确认 |
| 准备物 | LLMAdapter原型、适配器接口文档 |

---

## 附录

### A. 讨论参与者观点摘录

**梁文峰**:
> "LLM API的成本每年下降90%，现在是投入的最佳时机。用API成本是爬虫的1/10，效果还更好。"

**马斯克**:
> "不要用复杂的方式解决简单问题。一个统一接口可以解决所有7个平台，为什么要7套代码？"

**乔布斯**:
> "架构的复杂性最终都会转嫁到用户身上。保持简单，用户才能专注在真正重要的事情上。"

**贝索斯**:
> " scalability不是事后补救的。设计之初就要考虑多租户场景，数据隔离不能妥协。"

### B. 参考资料

1. [DeepSeek API定价](https://api.deepseek.com/pricing)
2. [Semrush GEO工具分析](https://www.semrush.com/blog/best-generative-engine-optimization-tools/)
3. [AWS EC2定价](https://aws.amazon.com/ec2/pricing/)

---

**记录人**: GEO产品团队
**审核人**: 待定
**日期**: 2026-05-01
