从入口 URL 开始完成 AI 规则识别、样本回归、人工审核、生产采集和失败恢复；4 周从需求沟通推进到研发阶段，目前处于开发中。
4 周从需求沟通完成产品结构、Agent 工作流和交互原型，并进入研发阶段，目前处于开发中；在线原型可演示接入、审核、采集与失败恢复。
面向标讯采集业务的公司项目。我负责产品结构、Agent 工作流、规则与运行模型及交互原型，4 周从需求沟通推进到研发阶段，目前处于开发中。在线演示只使用模拟数据，不含公司、客户或真实标讯信息，也不公开内部代码。
用三个关键界面走完标讯网站的接入与运行闭环：先让 AI 生成并验证规则，再核对采集结果，最后处理生产故障。
招投标信息来源分散，不同网站在页面结构、访问方式和字段质量上差异很大。一次性脚本难以维护，采集失败后也缺少统一上下文。
核心问题：接入效率、生产稳定性和结果可核对性需要在同一套工作流中解决。产品以网站为中心组织规则、计划和运行记录。Agent 生成规则并运行样本回归，人负责发布；系统再按故障类型决定自动重试或进入人工诊断。
关键取舍：不追求无人值守，而是让自动化拥有清晰的人工作业点与失败出口。从需求沟通到产品结构、Agent 工作流和交互原型在 4 周内完成；项目目前处于开发中，在线原型覆盖 URL 接入、AI 字段识别、样本回归、规则审核、采集记录、原文查看和失败队列。
当前可核验：4 周产品交付周期、研发阶段状态、在线交互原型和三组关键业务界面。从入口 URL 创建分析任务，识别页面结构、采集字段与访问约束，并用样本回归验证结果。
以网站为中心组织接入信息、采集计划、采集规则和历史运行，减少跨对象查找成本。
记录每次采集的类型、状态、产出与原文样本，让结果能够从批次回到具体内容。
按故障类型区分自动重试与人工诊断，并把修复、回归和恢复结果留在同一条处理链路中。
选择：Agent 分析页面结构、生成字段规则并运行样本回归，人工查看置信度、样本和原始数据后决定是否发布。
理由：页面识别可以自动化，但生产规则需要明确的人工作业点，避免低质量规则直接进入采集。
选择：采集计划、采集规则、访问配置和运行记录都挂在网站下，列表导航只保留接入、运行和治理三组主任务。
理由：官网演示和日常使用都需要快速理解对象关系，以网站为中心比平铺规则、任务和来源对象更直接。
选择：执行记录展示批次事实和采集样本，原文库保留正文、来源地址和对应运行记录。
理由：标讯结果需要被核对；从批次直接查看内容，比只展示成功数量更能证明采集质量。
选择：超时和临时服务错误进入自动重试，规则失效、反爬拦截等问题进入 AI 辅助的人工诊断。
理由：不同故障需要不同责任边界，先分流再处理可以减少人工噪声，也保留必要的接管能力。
