实战型爬虫采集PRD需求文档提示词

角色定义与任务定位

请以“资深数据产品经理兼技术方案架构师”的身份进行创作。你的核心目标是：为一项具体的网络爬虫数据采集项目，撰写一份详尽、清晰、可落地的产品需求文档（PRD）。这份文档需面向技术开发、测试及项目管理人员，旨在明确项目范围、技术边界、数据规范与验收标准，确保开发工作精准高效。

适用场景

• 启动新的数据爬虫采集项目，需要标准化需求输入。
• 对现有爬虫任务进行重构或优化，需重新定义需求。
• 向开发团队（特别是后端、数据工程师）传递清晰、无歧义的技术实现要求。
• 作为项目管理和验收的基准文档。

核心提示词

（以下提示词可直接组合或部分使用，以生成或结构化文档内容）

• 文档标题与概述：“《[项目名称]数据爬虫采集需求文档（PRD）》，版本V1.0。项目概述：旨在从[目标网站/平台]采集[具体数据类型，如商品详情、新闻正文、评论列表]，用于支撑[业务场景，如市场分析、内容聚合、价格监控]。”
• 需求背景与目标：“阐述当前业务痛点（如数据缺失、手工采集低效），明确本爬虫项目要解决的核心问题。列出具体的业务目标与数据目标（例如：每日更新覆盖10万条商品SKU，字段完整率≥99%）。
• 目标源站分析：“详细描述目标网站结构：网站域名、主要页面URL模式、页面渲染技术（静态HTML/动态JS加载/API接口）。分析潜在反爬机制：登录验证、IP频率限制、验证码、数据混淆等。”
• 数据字段定义：“以表格形式明确定义每个待采集字段：字段名（英文）、中文描述、数据类型、是否必填、示例值、清洗规则（如去除HTML标签、单位统一转换）。
• 采集逻辑与规则：“定义爬取策略：广度优先/深度优先。明确翻页规则、列表页到详情页的跳转逻辑。设定请求频率、并发数、重试机制（如失败后重试3次，间隔2秒）。规定去重依据（如基于URL哈希或业务ID）。
• 非功能性需求：“规定性能指标：日均采集量、单次任务耗时上限。明确数据存储格式（JSON/CSV/数据库表）。定义监控与报警需求：任务成功率监控、数据质量异常报警（字段缺失率突增）。
• 验收标准：“可量化的验收条件：连续3天采集任务成功率达99.5%以上；采集数据样本经业务方抽查，准确率不低于99.8%；文档中定义的所有必填字段采集完整。

风格方向

• 文体风格：技术文档风格，追求客观、精准、条理清晰。避免模糊描述和主观形容词。
• 视觉结构：采用层级分明的标题体系（1.， 1.1， 1.1.1）。大量使用列表和表格来呈现字段、规则、参数，增强可读性。
• 语言基调：使用定义式、指令式语句。多用“应”、“必须”、“建议”、“禁止”等明确词汇界定要求。

构图建议（文档结构框架）

• 1. 文档修订历史：记录版本、日期、修改内容、修改人。
• 2. 项目概述：背景、目标、范围、名词解释。
• 3. 目标源分析：网站信息、技术分析、反爬风险评估。
• 4. 详细需求：数据字段定义表、采集流程与规则（可用流程图）、清洗与存储规则。
• 5. 非功能性需求：性能、稳定性、监控、安全要求。
• 6. 项目规划与验收：里程碑、验收标准、风险与应对。
• 7. 附录：示例URL、接口返回样例、关键代码片段（如解析规则）。

细节强化

• 边界案例说明：在规则描述中，主动说明异常情况处理，如“当列表页为空时，任务应标记为成功并记录日志”。
• 示例驱动：关键规则旁附上URL示例或数据片段示例，让开发人员一目了然。
• 参数化配置：将可能变化的配置（如请求头、等待时间）明确为可配置参数，提升灵活性。
• 数据关系图：如果采集数据存在关联关系（如父-子评论），建议用简单的关系图进行说明。

使用建议

• 生成文档时，请将“[ ]”中的占位符替换为您的具体项目信息。
• “核心提示词”部分可作为与大语言模型对话的初始指令或分段补充指令，以生成或完善各章节内容。
• 在实际项目中，务必与开发工程师就“目标源站分析”和“采集逻辑”部分进行技术评审，确保可行性。
• 本方案侧重于需求定义，具体爬虫代码实现、代理IP池搭建等需另行规划。