15 KiB

Raw Blame History

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

讨论记录编号: RD-2026-05-01-02 关联文档: 第一轮讨论 | PRD 讨论日期: 2026-05-01 状态: 进行中

1. 讨论背景与议程

1.1 讨论背景

基于第一轮专家讨论的结论，GEO平台已确定：

产品定位: 专注中国市场的GEO品牌认知管理平台
核心功能: AI曝光度评分、竞品对比、报告导出
MVP范围: 7个国产AI平台覆盖

本轮讨论聚焦于：

现有代码架构的评估与改进
技术方案可行性验证
关键技术决策

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优先

支持者: 梁文峰、马斯克

论点:

成本低 (降低90%+)
效果好 (语义理解 vs 字符串匹配)
稳定性高 (不受平台UI变更影响)
速度快 (秒级 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保留

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

论点:

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

共识结论

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

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

3.2 辩题: 平台适配器设计

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

梁文峰方案: 统一Prompt抽象

# 梁文峰建议的架构
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

马斯克方案: 简化到极致

# 马斯克建议: 只需要一个统一接口
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平台的适配器

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

# 统一接口
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 状态: 已通过

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

决策: 策略模式 + 配置化

# 评分策略
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. 参考资料

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

15 KiB Raw Blame History Unescape Escape

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

目录

1. 讨论背景与议程

1.1 讨论背景

1.2 专家参与

1.3 讨论议程

2. 技术架构评估

2.1 现有架构分析

2.2 梁文峰视角: LLM API vs Playwright

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

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

3. 核心问题辩论

3.1 辩题: 数据采集策略

正方: LLM API优先

反方: Playwright保留

共识结论

3.2 辩题: 平台适配器设计

梁文峰方案: 统一Prompt抽象

马斯克方案: 简化到极致

共识结论

3.3 辩题: 缓存策略

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

梁文峰方案: 多级缓存

4. 架构决策记录 (ADR)

ADR-001: 数据采集策略

ADR-002: 平台适配器接口

ADR-003: 评分计算服务

5. 技术选型共识

5.1 核心技术决策

5.2 架构重构目标

5.3 模块职责划分

6. 实施路线图

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

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

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

7. 风险评估

7.1 技术风险

7.2 业务风险

7.3 成本估算

8. 结论与后续行动

8.1 关键决策总结

8.2 待办事项

8.3 下次会议

附录

A. 讨论参与者观点摘录

B. 参考资料

15 KiB

Raw Blame History