采集项目工作流：需求、设计与维护

本文基于模型知识整理。

一句话定义

采集项目工作流 = 需求定义 → 可行性评估（合规+技术判型）→ 方案设计 → POC 试抓 → 开发测试 → 上线监控 → 维护应对，每个阶段有明确出口条件。

为什么重要

「直接开写代码」是采集项目返工率最高的原因：没验证字段可得性就全量开发、没定义交付物就开抓。本篇把散落全库的工程实践收拢成一张可执行的项目清单。

前置知识

kp-018（工程化采集）、kp-024（管线与指标）。

核心概念

• 出口条件：每阶段结束的判定标准，不满足不进入下一阶段。
• POC（50 条试抓）：用最小成本验证「该不该做、能不能做」。
• 字段契约：与需求方共同确认的字段清单、口径与空值语义（kp-024）。
• 改版预案：解析失效时的定位—修复—回填流程。

原理与机制

七阶段流程与出口条件：

① 需求定义      出口: 一句话业务问题 + 指标草案 (kp-024 反向设计)
② 可行性评估    出口: 合规自检通过(kp-004) + 判型结论( kp-012 )
③ 方案设计      出口: 路线(解析/接口/浏览器)+频率+字段契约文档
④ POC 试抓     出口: 50条样本字段齐全率>95% 且人工抽查通过
⑤ 开发测试      出口: 全流程跑通; 失败重试/断点续抓/监控就位
⑥ 上线运行      出口: 连续3天水位线无告警( kp-023 )
⑦ 维护迭代      出口: 每次改版事故有复盘+解析回填数据

POC 的人工抽查清单（自动指标会漏的问题）：

□ 字段语义对不对(如「到手价」≠「标价」)
□ 抽 10 条与页面人工比对一致
□ 空值集中在哪类页面(模板差异?)
□ 翻到最后一页行为是否符合预期
□ 时间字段时区/格式统一

改版应对的标准动作：告警触发（kp-023）→ 打开 DevTools diff 新旧结构 → 修选择器/接口参数 → 从 raw 层重跑清洗回填缺口（kp-024 分层的回报时刻）。

实例或案例

两个团队做同一个「竞品周报」需求：A 团队直接开发两周上线，第 3 周站点改版全线瘫痪且无法回补；B 团队按本流程先做 POC，第 2 天发现「销量」字段在详情页不存在（仅列表页有），重新谈定口径后开发，上线后一次改版靠 raw 回填零损失。POC 花一天，省两周。

常见误区

• 误区一：需求不落纸。 「抓点数据看看」式需求必然返工；一句话业务问题 + 指标草案是开发的输入。
• 误区二：POC 靠眼看不算字段齐全率。 主观「差不多」会在全量时放大成灾难；95% 齐全率是硬出口。
• 误区三：无维护预算。 站点必然改版，项目预算必须包含维护人日；把改版应对当异常是规划错误。

自测题

1. POC 阶段要验证哪三件事？

答：字段可得性（齐全率>95%）、语义正确性（人工比对）、结构稳定性（各页模板差异）。

1. 为什么「字段契约」必须在开发前冻结？

答：它是需求方与分析方的共同输入；边开发边改字段口径会导致采集与分析双向返工。

1. 改版事故的处置顺序？

答：告警定位 → DevTools diff 结构 → 修复解析 → 从 raw 重跑回填缺口 → 复盘沉淀。

与其他知识点的关系

本篇是 kp-030/031/032 三个案例的通用骨架；kp-023 提供阶段⑥的验收手段；kp-024 的分层管线支撑阶段⑦的回填能力。

延伸阅读

本库 kp-024、kp-023、kp-030。