5.5 复盘室：完整项目案例分析

5.5 复盘室：完整项目案例分析

本节摘要：一个从头走到尾的完整项目——企业竞品情报采集系统，四十天、三站点、日均八千页。任务单、架构、关键决策点、事故与量化结果全部摊开，把前四章的方法论放进真实约束里检验，最后给出可迁移的复盘模板。

任务单与背景

某消费电子公司的产品团队要一套竞品情报系统：三个竞品官网与社区，持续跟踪新品发布、价格变动、用户反馈，产出周报供产品与定价决策。约束条件写得很硬：法务要求全部采集动作可自证合规；预算只有一台十六核服务器加一台备份机；六周内出第一期报告；团队两人，一人兼职。

按 1.1 节的五要素落任务单：目标是"产品决策情报"，不是海量归档——量级与频率要素据此定为"日均八千页、每小时一轮增量"；字段要素为"标题、价格、评分、评论数、发布时间、来源"；合规要素采纳 1.5 节全套（robots 检查、两秒间隔、真实 UA、匿名化）；验收要素为"字段完整率 98%、新品感知不超过六小时、周报自动生成"。

架构与关键决策

两台机器跑三站点持续采集，5.1 节的分布式架构在这里被裁剪成"单机多进程加备份热stand"：主服务器跑主控加两个采集进程，备份机跑一个采集进程兼灾备。裁剪的理由很直接——三站点的任务规模撑不起完整集群，按域名分片的逻辑保留（三个站点正好三个分片），消息队列用单机 Redis 承担，运维成本省下一大截。

采集侧的配置浓缩了第 2 章的全部要点，也是这个项目最核心的代码资产：

import asyncio, json
from crawl4ai import AsyncWebCrawler, BrowserConfig, CrawlerRunConfig, CacheMode
from crawl4ai import BFSDeepCrawlStrategy, JsonCssExtractionStrategy
from crawl4ai.content_scraping_strategy import PruningContentFilter

SITE_CONFIGS = {
    "competitor-a": {
        "start": "https://www.competitor-a.com/products",
        "schema": {"baseSelector": "div.product-card",
                   "fields": [
                       {"name": "title", "selector": "h2", "type": "text"},
                       {"name": "price", "selector": "span.price", "type": "text"},
                       {"name": "rating", "selector": "span.stars", "type": "attribute", "attribute": "data-value"},
                   ]},
        "wait_for": "css:div.product-card:nth-child(12)",   # A站懒加载，等第12张卡片
        "mean_delay": 2.0,
    },
    "competitor-b": {
        "start": "https://shop.competitor-b.com/new",
        "schema": {"baseSelector": "li.new-item",
                   "fields": [
                       {"name": "title", "selector": "a.title", "type": "text"},
                       {"name": "price", "selector": "em", "type": "text"},
                       {"name": "pub_date", "selector": "time", "type": "attribute", "attribute": "datetime"},
                   ]},
        "wait_for": None,                                   # B站静态直出，无需等待
        "mean_delay": 2.5,
    },
}

async def poll_site(site: str, cfg: dict) -> list[dict]:
    """单站点一轮增量轮询：发现层加内容指纹比对"""
    run_cfg = CrawlerRunConfig(
        deep_crawl_strategy=BFSDeepCrawlStrategy(max_depth=1, max_pages=40),
        extraction_strategy=JsonCssExtractionStrategy(schema=cfg["schema"]),
        content_filter=PruningContentFilter(threshold=0.45),
        cache_mode=CacheMode.ENABLED,                        # 指纹未变的页面直接命中缓存
        mean_delay=cfg["mean_delay"],
        semaphore_count=4,
    )
    async with AsyncWebCrawler(config=BrowserConfig(
            headless=True,
            user_agent="CompetitorWatch/1.0 (+contact: intel-team@example.com)")) as crawler:
        r = await crawler.arun(cfg["start"], config=run_cfg)
        return json.loads(r.extracted_content or "[]")

rows = asyncio.run(poll_site("competitor-a", SITE_CONFIGS["competitor-a"]))
print(len(rows), rows[0])
# 输出：40 {'title': '智能手表X5', 'price': '1299', 'rating': '4.6'}
​

配置表按站点分字典，差异点（等待条件、间隔、schema）显式化——这是维护性的关键：B 站第十九天改版，改动只落在配置表一行与 schema 一份，采集代码零改动。清洗与入库直接复用第 3 章管线：三层规整、两级去重、按 日期加来源 分区落库、curated 层周版本发布，评论的昵称字段进管线即哈希（匿名化工位）。

事故与量化结果

四十天里两起事故值得记录。事故一（第十九天）：B 站改版，字段完整率从 98.4% 掉到 41%。5.4 节的看板在四十分钟内告警（损耗信号先于完整率报表触发），值班按 P1 动作卡执行：暂停 B 分片、raw 快照对比、schema 修复版本 1.4.1、五十页验证回基线、恢复。数据暴露窗口两小时，未污染当周版本。事故二（第三十一天）：A 站连续 429，5.3 节的自适应控制器自动降到冷静档，两小时后试探恢复——这次连 P2 都没报，只在日志里留了痕迹，自适应的价值第一次被团队直观感受到。

def weekly_report(week_partitions: list[str]) -> dict:
    """周报骨架：从 curated 分区聚合出决策情报"""
    return {
        "价格变动": [("智能手表X5", 1399, 1299, -7.1)],     # 品名 旧价 新价 变动百分比
        "新品上架": [("降噪耳机Air3", "2026-09-14")],
        "舆情热点": [("续航虚标", 187)],                     # 关键词与提及量
        "数据质量": {"字段完整率": 0.981, "重复率": 0.028,
                     "采集页数": 57400, "缓存命中率": 0.71},
    }

report = weekly_report(["curated/v2.6/part-dt=20260908-0914"])
print(report["价格变动"][0])     # 输出：('智能手表X5', 1399, 1299, -7.1)
print(report["数据质量"]["缓存命中率"])   # 输出：0.71
​

量化的最终结果：新品中位感知时间三小时四十分（目标六小时）；字段完整率稳态 98.1%（目标 98%）；缓存命中率 71%（5.2 节第一杠杆兑现，实际网络请求不到三成）；两台机器峰值负载 60%；周报自动生成，人工只写解读按语——两人的团队从"盯屏采集"变成"每周两小时审读"。

解读与变式

复盘时最值得说的不是技术选型，是三个决策点的因果。裁剪分布式：如果上了完整集群，六周工期会被运维吃掉一半——架构复杂度应该匹配任务规模，而不是匹配"看起来专业"。配置表显式化：改版事故的恢复时间被压到两小时，八成功劳在"差异点集中可见"，schema 修复的人在一张表上找问题，不是在一堆代码里。匿名化前置：法务的合规自证要求倒逼管线设计，事后看这条"约束"反而让系统更干净——合规要求从来不是负担，是设计输入。

变式一：站点扩到十家以上时，单机多进程撑不住，把采集进程平移到 5.1 节的多节点架构，主控逻辑不变——这正是当初保留域名分片与消息队列接口的回报。变式二：需求从"竞品情报"升级为"行业指数"时，把周报层换成 4.3 节的榜单时间序列加告警，采集与入库层原样复用。变式三：若数据要供模型消费（比如训练价格预测），在 curated 层后面接 4.4 节的数据集卡片流程，授权核验的底子这时候直接兑现。

这个案例走完，教程的工程主线也走到头了。最后一章回到选型视野：工具生态怎么读、社区怎么跟、这门手艺的下一步在哪里。