geo/2026-05-31-003-feat-geo-monetization-closed-loop-plan.md at 3b581b22ba45bae91ef769b95960c98d384c82b0

28 KiB

Raw Blame History

title	type	status	date	origin	secondary-origin
feat: GEO Platform Monetization Closed Loop	feat	completed	2026-05-31	docs/brainstorms/2026-05-31-geo-next-phase-core-flow-repair-requirements.md	docs/brainstorms/2026-05-31-geo-platform-monetization-closed-loop-requirements.md

Summary

修复 GEO 诊断系统（当前空输入=0 分）、建设免费 GEO 健康分获客入口、接入真实支付与功能限制、添加 AI 内容生成能力、打通内容分发与效果归因闭环，实现从获客到续费的完整商业变现链路。同时用 API 契约测试驱动核心功能修复，辅以少量 E2E 烟雾测试验证关键用户路径。

Problem Frame

GEO 平台已具备 8 个 Agent、6 维度诊断框架、内容 Pipeline、知识库 RAG 等模块，但三个致命问题阻断了变现闭环：(1) 诊断系统使用空输入调用，永远返回 0 分，产品核心价值为零；(2) 内容 Pipeline 只做格式化不生成内容，核心付费功能缺失；(3) 支付是模拟的，没有功能限制，用户无付费动力。此外，Onboarding 缺少付费墙触发点、分发没有实际发布集成、监控没有归因逻辑、邮件服务未接入业务系统——各模块存在但互不连通。

Requirements

Origin: docs/brainstorms/2026-05-31-geo-next-phase-core-flow-repair-requirements.md

R1. 修复诊断系统：实现自动数据采集，让诊断产出非零有差异的评分 → U1
R2. 添加 AI 内容生成阶段：在 ContentPipeline 前端添加 Stage 0 → U5
R3. 接入真实支付：微信支付+支付宝+功能限制中间件 → U4
R4. 建设免费 GEO 健康分公开页面 → U2
R5. 重设计 Onboarding 流程，嵌入付费墙触发点 → U3
R6. 执行闭环：内容分发集成微信/知乎/头条 → U5
R7. 效果归因系统 → U6
R8. 为诊断 API 编写契约测试 → U1
R9. 为公开健康分 API 编写契约测试 → U2
R10. 为内容生成 API 编写契约测试 → U5
R11. 为支付 API 编写契约测试 → U4
R12. 编写跨步骤集成测试 → U8
R13. 编写获客路径 E2E 烟雾测试 → U9
R14. 编写核心流程 E2E 烟雾测试 → U9
R15. 完成后端测试目录统一验证 → U8
R16. 建立共享 fixture 体系 → U8

Key Technical Decisions

KTD-1. 诊断自动数据采集采用"AI 平台查询+CitationRecord 分析"双通道方案（V1 跳过网站爬取）。 通过调用现有 AI 平台适配器查询品牌关键词分析引用情况，通过分析已有 CitationRecord 数据聚合引用指标。网站爬取通道留待 V2 迭代，降低首版复杂度。AI 平台查询填充"引用就绪度"维度，CitationRecord 分析填充"E-E-A-T/主题权威"维度，品牌官网 URL 解析填充"内容可提取性/Schema 标记"维度（基于简单 HTTP GET + HTML 解析，非完整爬取）。

KTD-2. 免费 GEO 健康分页面为独立公开页面，不依赖现有 Dashboard。 新建 /health-score 路由，无需认证即可访问。结果缓存 24 小时（按品牌名+竞品哈希），避免重复查询消耗 API 额度。

KTD-3. 支付集成采用微信支付+支付宝双通道。 使用官方 SDK，后端实现支付回调 Webhook 处理订阅状态更新。

KTD-4. AI 内容生成集成到现有 ContentPipeline 前端。 在 Stage 1(RuleValidator) 之前添加 Stage 0(AI Generator)，基于诊断结果+RAG 知识库+LLM 生成初稿，后续阶段不变。

KTD-5. 效果归因采用"内容发布时间窗口+引用变化关联"方案。 发布内容时记录时间戳和基线引用数据，2-4 周内定期检查引用变化。

KTD-6. 微信公众号采用半自动模式。 生成内容+格式化+一键复制，用户手动粘贴到公众号编辑器。知乎和头条利用 API 实现自动发布。

KTD-7. API 契约测试驱动修复，E2E 仅做烟雾测试。 每个核心 API 先写契约测试定义期望行为，再修复实现。E2E 只覆盖 2 个最关键路径（获客+核心流程），不追求全面覆盖。

High-Level Technical Design

flowchart TB
    subgraph Phase1["Phase 1: 核心价值修复 + 契约测试"]
        A[品牌名输入] --> B[自动数据采集]
        B --> B1[AI平台查询]
        B --> B2[CitationRecord分析]
        B1 & B2 --> C[GEO诊断引擎]
        C --> D[6维度评分]
        D --> T1[诊断API契约测试]
    end

    subgraph Phase2["Phase 2: 获客入口 + 契约测试"]
        D --> E[免费健康分页面]
        E --> F{查看详细建议?}
        F -->|免费概要| G[注册]
        F -->|完整分析| G
        G --> H{执行优化?}
        H -->|升级付费| I[订阅支付]
        E --> T2[健康分API契约测试]
    end

    subgraph Phase3["Phase 3: 执行闭环 + 契约测试"]
        I --> J[AI内容生成]
        J --> K[人工审核]
        K --> L[发布到平台]
        L --> M[效果归因追踪]
        M --> N[ROI报告]
        N --> O[续费/升级]
        J --> T3[内容生成API契约测试]
        I --> T4[支付API契约测试]
    end

    subgraph Phase4["Phase 4: 集成验证"]
        T1 & T2 & T3 & T4 --> T5[跨步骤集成测试]
        T5 --> T6[E2E烟雾测试]
    end

Implementation Units

U1. GEO 诊断自动数据采集与修复

Goal: 修复当前诊断系统（空输入=0 分），实现自动数据采集填充 GEODiagnosisInput，让诊断产出真实有价值的分数。

Requirements: R1, R8

Dependencies: 无

Files:

backend/app/services/diagnosis/geo_diagnosis.py — 修改诊断服务，添加自动数据采集
backend/app/services/diagnosis/data_collector.py — 新建自动数据采集服务
backend/app/api/diagnosis.py — 修改 API 端点，支持自动采集+异步诊断
backend/app/schemas/diagnosis.py — 新建诊断请求/响应 schema
backend/app/models/diagnosis_record.py — 新建诊断历史记录模型
backend/tests/test_api/test_diagnosis_contract.py — 新建诊断 API 契约测试
backend/tests/test_services/test_data_collector.py — 新建数据采集服务测试

Approach:

新建 DataCollectorService，两个采集通道（V1）：
- AI 平台查询通道：复用现有 ai_engine 适配器，查询品牌相关关键词，分析引用情况填充"引用就绪度"维度
- 历史数据通道：从 CitationRecord 聚合已有引用数据，填充"E-E-A-T/主题权威"维度
- 品牌官网解析：简单 HTTP GET + HTML 解析（检查 Schema 标记、标题层级等），填充"内容可提取性/Schema 标记"维度
修改 GEODiagnosisService.diagnose() 接受 DataCollectorOutput 作为输入
修改诊断 API 端点：POST /api/v1/diagnosis/geo/{brand_id} 触发异步诊断，GET /api/v1/diagnosis/geo/{brand_id}/result 轮询结果
诊断结果持久化到 diagnosis_records 表，支持历史对比
免费版返回综合分+3 核心维度，付费版返回全部 6 维度
先写契约测试：定义诊断 API 的期望行为（非零评分、维度结构、免费/付费差异），再修复实现

Execution note: 先写诊断 API 契约测试（红色），再实现 DataCollectorService 和修改诊断服务（绿色）。

Patterns to follow:

复用 backend/app/services/ai_engine/ 下的平台适配器
复用 backend/app/workers/citation_engine.py 的查询执行模式
异步任务模式参考 backend/app/services/detection/detection_scheduler.py
契约测试参考 backend/tests/conftest.py 中的 async_client fixture

Test scenarios:

输入有效品牌名，自动采集数据并返回非零诊断分数
输入不存在的品牌名，返回低分但非零（基于 AI 平台查询结果）
免费用户请求诊断，只返回 3 个核心维度
付费用户请求诊断，返回全部 6 维度
同一品牌 24 小时内重复请求，返回缓存结果
诊断结果持久化，第二次诊断可展示历史对比
契约测试：POST /api/v1/diagnosis/geo/{brand_id} 返回 202 + task_id
契约测试：GET /api/v1/diagnosis/geo/{brand_id}/result 返回非零 overall_score

Verification: 调用 POST /api/v1/diagnosis/geo/{brand_id} 返回真实非零评分，且不同品牌评分有差异。契约测试全部通过。

U2. 免费 GEO 健康分公开页面

Goal: 建设无需注册即可访问的 GEO 健康分页面，作为获客和市场教育的核心入口。

Requirements: R4, R9

Dependencies: U1

Files:

frontend/app/(public)/health-score/page.tsx — 新建公开健康分页面
frontend/app/(public)/health-score/components/ScoreCard.tsx — 评分卡片组件
frontend/app/(public)/health-score/components/CompetitorComparison.tsx — 竞品对比组件
frontend/app/(public)/health-score/components/ShareButton.tsx — 分享按钮组件
frontend/lib/api/health-score.ts — 健康分 API 客户端
backend/app/api/health_score.py — 新建公开健康分 API（无需认证）
backend/app/schemas/health_score.py — 健康分响应 schema
backend/tests/test_api/test_health_score_contract.py — 新建健康分 API 契约测试

Approach:

新建公开路由 /health-score，无需登录即可访问
页面核心交互：输入品牌名 → 30 秒内展示 GEO 健康分报告
报告内容：综合评分（大数字+健康等级色标）、3 核心维度雷达图、3 竞品对比柱状图、最严重 3 个问题概要
"查看详细修复建议"按钮 → 触发注册弹窗
注册后自动关联本次诊断结果到用户账户
支持生成可分享链接（含品牌名参数）和 PDF 下载
后端：GET /api/v1/public/health-score?brand=XXX 无需认证，返回免费版诊断结果
结果缓存 24 小时（Redis），避免重复查询

Patterns to follow:

前端页面参考 frontend/app/(dashboard)/onboarding/Step4HealthReport.tsx 的报告展示模式
API 参考 backend/app/api/diagnosis.py 但无需认证
分享功能参考 backend/app/api/reports.py 的 PDF 生成

Test scenarios:

未登录用户输入品牌名，30 秒内看到健康分报告
报告包含综合评分、3 维度、3 竞品对比
点击"查看详细建议"弹出注册弹窗
注册后诊断结果自动关联到账户
生成可分享链接，他人打开看到相同报告
24 小时内重复查询同一品牌返回缓存结果
契约测试：GET /api/v1/public/health-score?brand=XXX 返回 200 + 非零评分
契约测试：无品牌名参数返回 422

Verification: 未登录状态下访问 /health-score，输入品牌名后看到完整报告且可分享。契约测试通过。

U3. Onboarding 重设计与转化层

Goal: 重设计 Onboarding 流程以"查看 GEO 健康分"为第一步，嵌入付费墙触发点。

Requirements: R5

Dependencies: U1, U2

Files:

frontend/app/(dashboard)/onboarding/page.tsx — 重写 Onboarding 主页面
frontend/app/(dashboard)/onboarding/Step0HealthScore.tsx — 新建第一步：健康分
frontend/app/(dashboard)/onboarding/Step1BrandName.tsx — 修改为简化版
frontend/app/(dashboard)/onboarding/Step4HealthReport.tsx — 修改为含升级提示
frontend/app/(dashboard)/onboarding/Step5ActionSuggestions.tsx — 修改为含执行按钮+付费墙
frontend/components/subscription/UpgradePrompt.tsx — 新建升级提示组件

Approach:

新流程：Step0(输入品牌名看健康分) → Step1(注册/登录) → Step2(补充竞品信息) → Step3(查看详细报告+升级提示) → Step4(行动建议+执行按钮)
Step0 直接复用 U2 的健康分页面组件，嵌入 Onboarding 流程
在以下场景嵌入升级提示：
- 查看详细 6 维度分析时 → "升级 Pro 版查看完整分析"
- 点击执行优化建议时 → "升级 Starter 版开始优化"
- 查看效果归因报告时 → "升级 Pro 版追踪优化效果"
升级提示组件 UpgradePrompt 统一管理，显示当前套餐限制和升级收益

Patterns to follow:

现有 Onboarding 步骤组件模式（Step1-5 的 props 接口）
useOnboardingData hook 的数据管理模式

Test scenarios:

新用户进入 Onboarding，第一步看到健康分输入框
输入品牌名后看到免费健康分报告
注册后继续 Onboarding，看到详细报告含升级提示
免费用户点击"执行优化"时看到升级弹窗
已完成 Onboarding 的用户不再看到引导

Verification: 新用户从健康分开始 Onboarding，在关键节点看到升级提示。

U4. 真实支付集成与功能限制

Goal: 接入微信支付+支付宝，实现功能限制中间件，让付费真正生效。

Requirements: R3, R11

Dependencies: U3

Files:

backend/app/services/payment/wechat_pay.py — 新建微信支付服务
backend/app/services/payment/alipay.py — 新建支付宝服务
backend/app/services/payment/base.py — 新建支付基类
backend/app/api/payments.py — 新建支付 API 端点
backend/app/middleware/subscription_enforcement.py — 新建功能限制中间件
backend/app/services/subscription.py — 修改添加真实支付逻辑
backend/app/api/subscriptions.py — 修改添加支付 Webhook
backend/app/models/subscription.py — 修改添加支付相关字段
backend/tests/test_api/test_payment_contract.py — 新建支付 API 契约测试
backend/tests/test_services/test_payment.py — 新建支付服务测试

Approach:

支付基类定义统一接口：create_order, verify_callback, refund
微信支付：使用官方 SDK，实现 JSAPI 支付（H5 页面）和 Native 支付（扫码）
支付宝：使用官方 SDK，实现手机网站支付
支付 Webhook：POST /api/v1/payments/callback/wechat 和 /alipay，验证签名后更新订阅状态
功能限制中间件：在 API 路由层检查用户套餐，超限返回 403+升级提示
限制维度：查询数/品牌数/诊断频率/内容生成数/知识库数/数据保留期
先写契约测试：定义支付 API 的期望行为（创建订单、回调处理、功能限制）

Execution note: 先写支付 API 契约测试（红色），再实现支付服务（绿色）。

Patterns to follow:

支付回调参考 backend/app/api/auth.py 的 Webhook 处理模式
功能限制参考 backend/app/middleware/rate_limit.py 的中间件模式
订阅逻辑复用 backend/app/services/subscription.py 的 PLANS 配置

Test scenarios:

创建支付订单，返回支付链接/二维码
支付成功回调，订阅状态更新为 active
免费用户超出查询限制，返回 403+升级提示
Pro 用户在限制内正常使用
支付失败回调，订阅状态不变
订阅到期，自动降级为免费版
契约测试：POST /api/v1/payments/orders 返回 201 + order_id + pay_url
契约测试：POST /api/v1/payments/callback/wechat 验证签名后更新订阅

Verification: 完整支付流程：创建订单→支付→回调→订阅激活→功能解锁。契约测试通过。

U5. AI 内容生成与分发集成

Goal: 在 ContentPipeline 前端添加 AI 生成阶段，集成知乎/头条 API 发布和微信半自动发布。

Requirements: R2, R6, R10

Dependencies: U1, U4

Files:

backend/app/services/content/ai_generator.py — 新建 AI 内容生成服务
backend/app/services/content/content_pipeline.py — 修改添加 Stage 0
backend/app/services/distribution/publishers/zhihu_publisher.py — 新建知乎发布器
backend/app/services/distribution/publishers/toutiao_publisher.py — 新建头条发布器
backend/app/services/distribution/publishers/wechat_publisher.py — 新建微信半自动发布器
backend/app/services/distribution/publish_engine.py — 新建发布引擎
backend/app/api/distribution.py — 修改添加发布 API
backend/tests/test_api/test_content_contract.py — 新建内容生成 API 契约测试
backend/tests/test_services/test_ai_generator.py — 新建 AI 生成测试
backend/tests/test_services/test_publishers.py — 新建发布器测试

Approach:

AI 内容生成服务：
- 输入：诊断结果（问题维度）+ RAG 知识库上下文 + 目标关键词 + 目标平台
- 调用 LLM 生成初稿，基于诊断结果针对性优化
- 输出传入现有 Pipeline（RuleValidator → SensitiveFilter → SEOOptimizer → HTMLGenerator）
发布引擎：
- 知乎：通过知乎创作中心 API 发布文章（需 OAuth 授权）
- 头条：通过头条号 API 发布文章（需 API Key）
- 微信：生成格式化内容+复制引导，不直接调用 API
发布流程：AI 生成 → 人工预览/编辑 → 确认发布 → 调用对应 Publisher → 记录发布状态
发布记录关联到 Content 模型，用于后续归因

Patterns to follow:

AI 生成参考 backend/app/services/content/content_generation_service.py 的 LLM 调用模式
RAG 集成参考 backend/app/services/knowledge/rag_service.py
平台规则复用 backend/app/services/distribution/platform_rules.py
Publisher 模式参考 backend/app/services/ai_engine/ 的适配器模式

Test scenarios:

基于诊断结果+知识库上下文生成针对性优化内容
生成内容通过 Pipeline 校验（RuleValidator + SensitiveFilter）
知乎 API 发布成功，返回文章 URL
头条 API 发布成功，返回文章 URL
微信半自动模式生成格式化内容+复制引导
发布记录保存到 Content 模型，状态为 published
契约测试：POST /api/v1/content/generate 返回 201 + content_id + 生成内容

Verification: 从诊断建议到内容生成到发布的完整流程可走通。契约测试通过。

U6. 效果归因系统与 ROI 报告

Goal: 建设效果归因系统，追踪已发布内容的 AI 引用变化，生成 ROI 报告证明付费价值。

Requirements: R7

Dependencies: U5

Files:

backend/app/services/attribution/attribution_engine.py — 新建归因引擎
backend/app/services/attribution/roi_calculator.py — 新建 ROI 计算器
backend/app/api/attribution.py — 新建归因 API
backend/app/models/attribution_record.py — 新建归因记录模型
backend/app/services/monitoring/monitor_service.py — 修改集成归因
frontend/app/(dashboard)/dashboard/roi/page.tsx — 新建 ROI 报告页面
frontend/lib/api/attribution.ts — 新建归因 API 客户端
backend/tests/test_services/test_attribution.py — 新建归因测试

Approach:

归因引擎核心逻辑：
- 内容发布时记录：发布时间、目标关键词、发布前基线引用数据
- 定期（每 3 天）检查目标关键词的引用变化
- 归因判定：引用率上升 + 新引用内容与已发布内容语义相关 → 归因为该内容贡献
- 归因窗口：2-4 周，窗口内持续追踪
ROI 计算器：输入订阅费用+归因引用提升+行业平均引用价值，输出 GEO ROI 百分比
A/B 对比报告：优化前诊断分数 vs 当前诊断分数，按维度对比
效果保障：如果 2-4 周内无任何引用提升，提供额外优化建议或延长服务

Patterns to follow:

监控模式参考 backend/app/services/monitoring/monitor_service.py
定期任务参考 backend/app/services/detection/detection_scheduler.py
报告生成参考 backend/app/api/reports.py

Test scenarios:

发布内容后自动创建归因追踪记录
3 天后检查引用变化，记录 delta
引用率上升且语义相关，归因为该内容贡献
归因窗口结束后生成 ROI 报告
优化前后 A/B 对比报告展示各维度变化
无引用提升时提供额外优化建议

Verification: 发布内容→2-4 周后→归因报告展示引用提升和 ROI。

U7. 邮件集成与 Dashboard 变现 UI

Goal: 将 EmailService 接入业务系统（周报、续费提醒），Dashboard 添加订阅状态、用量进度、ROI 面板。

Requirements: R7 (邮件部分)

Dependencies: U4, U6

Files:

backend/app/services/email_service.py — 修改添加新模板
backend/app/services/email/email_scheduler.py — 新建邮件调度器
backend/app/templates/geo_weekly_report.html — 新建周报模板
backend/app/templates/renewal_reminder.html — 新建续费提醒模板
backend/app/templates/trial_expiring.html — 新建试用期到期模板
frontend/app/(dashboard)/dashboard/page.tsx — 修改添加变现 UI
frontend/components/subscription/SubscriptionStatus.tsx — 新建订阅状态组件
frontend/components/subscription/UsageProgress.tsx — 新建用量进度组件
frontend/components/dashboard/ROICard.tsx — 新建 ROI 卡片组件

Approach:

邮件模板新增：GEO 变化周报、续费提醒（到期前 7 天/3 天/1 天）、试用期到期提醒、欢迎邮件
邮件调度器：APScheduler 定时任务，每周一发送周报，每日检查续费提醒
Dashboard 变现 UI：顶部订阅状态栏、用量进度条、ROI 卡片、功能锁定 UI
配置真实 SMTP（支持 SendGrid/阿里云邮件推送）

Patterns to follow:

邮件模板参考 backend/app/services/email_service.py 现有模板格式
Dashboard 组件参考 frontend/app/(dashboard)/dashboard/page.tsx 的 KPI 卡片模式
订阅状态参考 backend/app/services/subscription.py 的 PLANS 配置

Test scenarios:

每周一自动发送 GEO 变化周报给注册用户
订阅到期前 7 天发送续费提醒
试用期到期前 3 天发送提醒
Dashboard 显示当前套餐和用量进度
超出用量时显示升级提示
ROI 卡片展示引用率提升和归因内容

Verification: 注册用户收到周报邮件，Dashboard 显示订阅状态和 ROI 数据。

U8. API 契约集成测试与测试基础设施

Goal: 编写跨步骤集成测试验证完整链路，完成后端测试基础设施统一。

Requirements: R12, R15, R16

Dependencies: U1, U2, U4, U5

Files:

backend/tests/test_integration/test_monetization_flow.py — 新建变现闭环集成测试
backend/tests/conftest.py — 增强 fixture 体系
backend/tests/fixtures/auth.py — 新建认证 fixture 模块
backend/tests/fixtures/database.py — 新建数据库 fixture 模块
backend/tests/fixtures/client.py — 新建 httpx 客户端 fixture 模块
backend/tests/fixtures/brands.py — 新建品牌测试数据 fixture 模块

Approach:

编写跨步骤集成测试：品牌创建→诊断→方案→内容生成→效果追踪的完整链路
验证 U1-U5 的 API 契约测试在集成场景下仍然通过
完成后端测试目录统一验证（原 QA 计划 U1）
建立共享 fixture 体系：按领域拆分到 backend/tests/fixtures/ 下
- auth.py：override_get_current_user、auth_token、auth_headers
- database.py：async_engine、async_session（含自动 rollback）
- client.py：async_client（httpx AsyncClient with app）
- brands.py：预创建的测试品牌和竞品数据
conftest.py 通过 pytest plugin 机制自动加载 fixtures/ 下所有模块

Patterns to follow:

backend/tests/conftest.py 现有 fixture 模式
backend/tests/test_integration/test_business_flow.py 现有集成测试模式

Test scenarios:

品牌创建→诊断→方案→内容生成→效果追踪全链路通过
数据在步骤间正确传递（品牌 ID、诊断结果 ID、内容 ID）
共享 fixture 可被其他测试复用
数据库 fixture 在测试结束后自动 rollback
多个测试并行运行时 fixture 互不干扰

Verification: cd backend && pytest tests/test_integration/test_monetization_flow.py --tb=short 通过。cd backend && pytest tests/ -q 全部测试被发现且无新增失败。

U9. E2E 烟雾测试

Goal: 编写 2 个关键路径的 Playwright E2E 烟雾测试，验证最核心的用户路径端到端可用。

Requirements: R13, R14

Dependencies: U2, U3

Files:

frontend/e2e/tests/health-score-smoke.spec.ts — 新建获客路径烟雾测试
frontend/e2e/tests/core-flow-smoke.spec.ts — 新建核心流程烟雾测试

Approach:

获客路径烟雾测试：访问健康分页面→输入品牌名→看到报告→点击注册
核心流程烟雾测试：登录→创建品牌→触发诊断→查看诊断结果
使用独立 setup（直接调用 API 创建测试数据），不依赖共享 fixture
确保截图和视频录制配置正确（screenshot:on-failure, video:retain-on-failure）

Patterns to follow:

frontend/e2e/tests/login.spec.ts 现有 E2E 测试模式
frontend/e2e/pages/login.page.ts Page Object 模式

Test scenarios:

获客路径：未登录→访问 /health-score→输入品牌名→30 秒内看到报告→点击注册→注册弹窗出现
核心流程：登录→创建品牌→品牌出现在 Dashboard→触发诊断→诊断结果非零
测试失败时自动截图保存

Verification: cd frontend && npx playwright test health-score-smoke core-flow-smoke 通过。

Scope Boundaries

Deferred for later:

网站爬取通道（诊断数据采集 V2）
全面 E2E 测试覆盖（原 QA 计划 U3/U4/U5 → 上线后逐步扩展）
性能基线测试（原 QA 计划 U7 → 上线后有真实负载后建立）
CI 安全扫描（原 QA 计划 U8 → 上线后集成）
Alembic 迁移验证（原 QA 计划 U8 → 上线后添加）
前端组件测试（原 QA 计划 U10 → 上线后扩展）
行业 GEO 基准数据积累
API 市场开放和第三方集成
白标报告和专属客户成功经理
多语言和国际 AI 平台支持
知识库自动构建（从品牌官网自动提取 GEO 相关信息结构）
批量内容生成（一次生成多平台内容）
内容日历和排期执行系统

Outside this product's identity:

传统 SEO 工具功能（关键词排名、外链分析等）
广告投放和营销自动化
社交媒体管理
基础设施级别的渗透测试

Deferred to follow-up work:

E2E 测试迁移到共享 fixture（U9 完成后，将独立 setup 替换为 U8 的共享 fixture）
性能基线设定阈值和告警（上线后根据数据设定合理阈值）
跨浏览器 E2E 扩展（稳定 Chromium 后再扩展）
知乎/头条 API OAuth 授权完整流程
批量内容生成

Open Questions

微信公众号 OAuth 授权流程的具体实现方案需在 U5 实施时确认
知乎和头条 API 的申请和审核周期可能影响 U5 的交付时间
诊断自动数据采集的品牌官网解析可能遇到反爬机制，需准备降级方案
真实 SMTP 配置需要用户提供邮件服务商账号信息
效果归因的具体技术实现方案（基于引用检测还是基于评分变化）
付费版定价是否需要调整（当前 ¥199/599/1999 是否匹配价值感知）

Risks & Dependencies

Risk	Impact	Mitigation
诊断数据采集不准确	用户不信任健康分，获客失效	先用 AI 平台查询数据（已有适配器），品牌官网解析作为增强
微信/知乎/头条 API 审核不通过	分发集成延期	微信降级为半自动，知乎/头条备选手动发布
支付 SDK 集成复杂度超预期	付费闭环延期	先实现支付宝（文档更友好），微信支付后续迭代
GEO 效果归因窗口内无可见提升	用户认为产品无效	提供效果保障机制，延长归因窗口或提供额外优化
免费诊断 API 调用成本过高	运营成本失控	24 小时缓存+频率限制+深度限制
LLM API Key 不可用影响内容生成	核心付费功能不可用	支持多 LLM Provider 降级，至少保证一个可用

Sources & Research

Origin requirements: docs/brainstorms/2026-05-31-geo-next-phase-core-flow-repair-requirements.md
Secondary origin: docs/brainstorms/2026-05-31-geo-platform-monetization-closed-loop-requirements.md
QA plan (downscoped): docs/plans/2026-05-31-002-test-quality-assurance-system-plan.md
Existing diagnosis system: backend/app/services/diagnosis/geo_diagnosis.py
Diagnosis API root cause: backend/app/api/diagnosis.py line 75 (GEODiagnosisInput())
Existing content pipeline: backend/app/services/content/content_pipeline.py
Existing distribution rules: backend/app/services/distribution/platform_rules.py
Existing monitoring: backend/app/services/monitoring/monitor_service.py
Existing subscription: backend/app/services/subscription.py
Existing email: backend/app/services/email_service.py
Existing E2E tests: frontend/e2e/tests/

28 KiB Raw Blame History Unescape Escape

Summary

Problem Frame

Requirements

Key Technical Decisions

High-Level Technical Design

Implementation Units

U1. GEO 诊断自动数据采集与修复

U2. 免费 GEO 健康分公开页面

U3. Onboarding 重设计与转化层

U4. 真实支付集成与功能限制

U5. AI 内容生成与分发集成

U6. 效果归因系统与 ROI 报告

U7. 邮件集成与 Dashboard 变现 UI

U8. API 契约集成测试与测试基础设施

U9. E2E 烟雾测试

Scope Boundaries

Open Questions

Risks & Dependencies

Sources & Research

28 KiB

Raw Blame History