title: SourceOS 采集任务工作台与证据导向采集管理产品规格
document_type: product-specification
status: ready-for-agent
version: v0.1
model: gpt-5
created_at: 2026-08-02 13:17 Asia/Shanghai
related_product_definition: ../product-definition/20260802-00：08-个人经营者证据化现实需求发现与产品验证智能体产品规划定义-gpt-5-v0.1.md
related_architecture: ../architecture/20260802-00：42-SourceOS证据化现实需求发现与产品验证智能体整体架构设计-gpt-5-v0.1.md
SourceOS 采集任务工作台与证据导向采集管理
Problem Statement
作为单人经营者，我缺少稳定接触现实世界的渠道，也无法可靠判断评论、讨论、差评、访谈记录和公开行为中哪些是独立、可追溯且能够改变产品判断的信号。现有“爬虫”或“采集工具”通常只回答抓到多少数据，却不回答为什么采、是否完整、是否来自同一传播链、是否补齐了关键不确定性，以及它是否改变了一个 Need Issue、验证行动或产品决策。
我需要一个私人使用的采集工作台，用有限的时间、金钱和注意力管理现实采集：定义来源与任务，明确证据缺口，运行受约束的采集，处理上下文与失败，分诊信号，保留反证，并将结果回流到 Need Issue 和后续现实验证。系统必须直说“不知道”、阻止无边界采集和同源重复造成的自我欺骗，但不把采集数量、热度、情绪强度或模型判断伪装成真实需求、付费意愿、留存或盈利。
Solution
SourceOS 提供以“采集任务（Acquisition Mission）”为中心的现实采集工作台。经营者先登记一个有明确覆盖范围和证据用途的采集源，再创建一条有现实问题、任务类型、来源、范围、预算和停止条件的任务。任务只能以 draft 身份存在，直到通过试运行和人工启动进入实际执行；运行后产生可追溯的原始材料、External Signal、上下文状态、质量数据和进入 Evidence Inbox 的候选，而不是自动宣布发现了需求。
工作台把采集管理分成七个相连但不混淆的面：采集源、采集任务、运行控制、信号分诊、上下文修复、质量与覆盖、结果校准。强硬教练在每个关键节点呈现基于事实的反对意见：例如“这批评论来自同一传播链”“缺失父帖导致上下文不可用”“你的任务没有反证路径”“停止条件是数据量，不是有效证据”。经营者保留最终决定权，但系统保留事实、未知项、异议、理由和下一步最小行动。
首个可用版本不建设“全球通用爬虫”。它以一个稳定、结构化、可 fixture 回放的公开来源完成纵向闭环；优先目标是让经营者在每天有限的工作时间内获得可以支持、反驳或缩小一个 Need Issue 的证据，而不是展示数据规模。
User Stories
- 作为单人经营者，我希望登记采集源的名称、平台、访问入口、目标人群、市场、语言和预期证据类型，以便知道每个来源为什么存在。
- 作为单人经营者，我希望给采集源标记草稿、试运行、活跃、退化、暂停和退役状态，以便不把失效来源伪装成可靠输入。
- 作为单人经营者，我希望保存采集源配置版本、差异、试运行结果和回滚记录，以便复核某次采集究竟使用了什么规则。
- 作为单人经营者，我希望配置来源的查询种子、频道、账号、主题、关键词和排除项，以便让采集范围与现实问题相关。
- 作为单人经营者，我希望登记来源的访问方式、凭据引用、频率、速率、成本和故障历史，以便在不稳定外部环境中安排任务。
- 作为单人经营者，我希望为一个证据缺口创建采集任务，而不是仅输入“找需求”，以便任务有可判断的目的。
- 作为单人经营者，我希望在任务中写明现实问题、关联 Need Issue 或假设、任务类型和预期证据，以便采集结果能回到经营判断。
- 作为单人经营者，我希望选择探索、定向取证、反证和上下文修复等任务类型，以便系统知道不同任务不能用同一成功标准评估。
- 作为单人经营者，我希望设置地区、语言、角色、人群、时间窗、排序、分页深度和内容深度，以便采集范围可解释且可重放。
- 作为单人经营者，我希望为每个任务设置时间、请求、条数和成本预算，以便有限的两小时工作时间不被无边界采集吞掉。
- 作为单人经营者，我希望为每个任务设置至少一条停止条件，以便系统在收集到足够证据、预算耗尽或条件不成立时停下。
- 作为单人经营者，我希望先获得试运行预览，以便在正式消耗预算前看到预计范围、样本、上下文风险和成本。
- 作为单人经营者，我希望明确启动、暂停、恢复、取消、重试和终止任务，以便控制外部动作而不是依赖自动黑箱。
- 作为单人经营者，我希望在中断后从检查点恢复任务，以便网络、服务或本地进程中断不会造成重复或不可解释的结果。
- 作为单人经营者，我希望看到队列位置、运行进度、限流、分页、失败类型、重试次数和已消耗预算，以便判断任务是在推进还是卡住。
- 作为单人经营者，我希望每个运行保留来源版本、输入快照、原始响应、解析版本和时间，以便未来能离线重放和复核。
- 作为单人经营者，我希望系统显式提示父帖、回复链、附件、字幕、分页、排序或删除节点缺失，以便不从孤立句子做需求判断。
- 作为单人经营者，我希望对缺失上下文创建修复任务，以便先补全事实，再讨论含义。
- 作为单人经营者，我希望在 Evidence Inbox 中看到去重后的信号簇、原文预览、来源、上下文完整度和进入理由，以便快速分诊而不丢失谱系。
- 作为单人经营者，我希望把候选信号接受、忽略、合并、标为反证或送入上下文修复，以便人工判断留下审计轨迹。
- 作为单人经营者，我希望手工导入访谈、销售对话、邮件、笔记和线下观察，以便公开评论不是唯一的现实输入。
- 作为单人经营者，我希望区分独立主体、同源转载、营销内容、机器人内容和不明来源，以便不把重复表达当成市场规模。
- 作为单人经营者，我希望看到技术成功率、解析成功率、上下文完整率、重复率、独立来源数、反证比例和单位有效证据成本，以便衡量采集质量而不迷信条数。
- 作为单人经营者，我希望看到不同地区、语言、人群、情境和证据类型的覆盖缺口，以便知道盲点在哪里。
- 作为单人经营者，我希望系统提示来源偏差与样本不足，以便它不能用看似精确的分数制造信心。
- 作为单人经营者，我希望强硬教练指出同源重复、无行为证据、无代价、上下文缺失、反证缺失和错误外推，以便更早停止错误方向。
- 作为单人经营者，我希望每条反对意见同时给出所依据的事实、未知项、可证伪条件和最小下一步，以便批判推动行动而不是只制造挫败感。
- 作为单人经营者，我希望将采集结果关联为 Need Issue 的 supporting 或 counter evidence reference，以便 Need Issue 可以回到具体的 External Signal。
- 作为单人经营者，我希望系统明确显示“External Signal”“Evidence reference”“Need Issue”“假设”和“产品结论”的区别，以便模型或人都不能越级下结论。
- 作为单人经营者，我希望从验证、交付和经营结果反向看到哪些来源、查询和任务真正改变过决策，以便下一轮减少低价值采集。
- 作为单人经营者，我希望保留一小部分开放探索预算，以便系统不会只在已知领域做局部优化。
- 作为单人经营者，我希望在桌面端完整编辑来源和任务，在移动端至少查看状态、处理紧急审批和快速导入材料，以便产品符合实际工作方式。
- 作为单人经营者，我希望界面先说清楚当前最重要的事实、异议和下一行动，技术细节按需展开，以便不被复杂控制台压垮。
- 作为单人经营者，我希望系统在没有足够证据时明确显示“不知道”，以便我不会把空白解释成机会。
Implementation Decisions
- 核心领域对象为
AcquisitionMission：它是一次受约束、可审计的采集意图，不等同于采集源、实际运行、External Signal、Evidence reference 或 Need Issue。
AcquisitionMission 初始状态为 draft。首个已实现的公共接口允许创建草稿并按 ID 重新获取；该接口已确认是本规格的主测试接缝。- 创建草稿必须包含现实问题、任务类型、一个采集源、地区、语言、目标人群、查询种子、时间预算、条数上限、成本预算和停止条件。停止条件必须至少有一条；没有停止条件的任务返回请求校验错误。
- 任务类型以受控枚举演进：
exploratory、targeted_evidence、counterevidence、context_repair。不同类型使用不同的成功和停止判据，不能压缩为统一“机会分”。
- 采集源是独立的配置实体。来源配置要可版本化，并把运行时使用的配置快照写入实际采集运行，避免后来修改来源后无法解释历史结果。
- 实际执行将在草稿之后引入
dry_run、queued、running、paused、completed、failed、cancelled 等运行状态；这些状态属于运行事实，不能覆盖或混同任务定义的版本与意图。
- 试运行是正式采集的前置能力：它只使用受限样本和预算，返回候选范围、估算成本、可访问性、上下文风险和预期输出；试运行不自动启动正式采集。
- 正式采集必须从耐久队列执行，记录检查点、租约、尝试次数、结构化错误和预算消耗。暂停、取消、恢复、重试与终止是显式命令，不能通过删除记录伪造状态。
- 原始响应先于解析结果保存。解析、翻译、OCR、字幕和上下文修复均是可版本化派生产物；在没有重新联网的前提下，应能从原始材料重放。
- 解析必须显式建模根内容、父子回复、顺序、分页、删除、附件和缺失节点。缺失不是空值后静默忽略，而是可见的上下文风险和可创建的修复任务。
- 信号收件箱接收的是候选 External Signal，不是自动创建的 Need Issue。经营者或受限 Agent 可以提出分类和关联建议，但不能自动宣布“真实需求成立”。
- 支持证据与反证必须并列保存。相同传播链、相同作者、同一转载链或营销复制的信号先聚类，再估计独立性，禁止把重复条数当作市场规模。
- 质量视图分开呈现技术可靠性、上下文可靠性与证据可靠性：请求/解析成功不等于上下文完整；上下文完整不等于独立证据；独立证据不等于付费或留存。
- 强硬教练只针对判断、证据和下一行动提出异议。每条异议必须包含依据、未知项、可证伪条件和最小行动；系统不评价经营者本人，也不使用虚假的置信度数字。
- 工作台采用桌面优先的信息架构：现实采集下设控制台、采集源、采集任务、运行队列、信号收件箱、上下文修复和质量审计。移动端只承诺阅读、快速导入和受限审批。
- 视觉与文案采用克制、可信、可读的“现实证据工作台”风格：优先事实与下一行动，避免霓虹数据大屏、无意义仪表盘、庆祝性进度条和“发现巨大商机”之类的误导性文案。
- 本规格与 Need Issue 生命周期集成，但不改变 Need Issue 的独立定义：External Signal 只能支持、反驳或触发 Need Issue 的下一验证动作；
discovery_validated 不代表付费、留存或盈利已经成立。
- Pi Agent 是受控辅助者：可对已入库的材料提取候选、建议反证或建议修复任务；不得自行扩大来源范围、任意构造访问路径、启动外部动作或改写业务事实。
- 首个真实来源选择以目标人群可触达性、稳定访问路径、fixture 完整性和上下文恢复能力为依据。建议优先已有公开、结构化且可回放的 GitHub Issue/Discussion/评论路径；选择不是永久限制，也不表示该来源本身能代表全球需求。
Testing Decisions
- 好测试只验证使用者或调用方能观察到的行为，不测试私有方法、内部协作者调用次数或数据库表的偶然形状。期望值来自规格中的明确字面规则，而不是复制实现算法。
- 主测试接缝为公共 HTTP API，当前已由经营者确认：创建采集任务草稿后，可使用其 ID 重新获取同一任务；空停止条件必须被拒绝。该接缝优先于模型或仓储级测试。
- 测试采用单条纵向切片的 red → green 节奏：先写一个失败的行为测试，再仅实现使其通过所需的最小代码；不批量预写未来任务、队列或连接器测试。
- 已有 API 行为测试是本功能的先例：来源、条目、作业与 Need Issue 使用异步 HTTP 客户端通过 FastAPI 公开边界测试，测试数据库使用真实 PostgreSQL 模式创建，而非以内部仓储 mock 代替行为验证。
- 后续试运行、正式运行与上下文修复仍以 HTTP API 为主接缝。只有外部平台 Adapter 的网络边界才使用固定 fixture 或协议替身；不得 mock 自己的领域对象来证明领域行为。
- 连接器测试必须覆盖成功、空结果、分页、限流、超时、拒绝访问、删除节点、结构变化和离线重放。真实网络探针是补充，不允许用网络波动替代可重复 fixture 测试。
- 状态与恢复测试必须验证可见行为：中断后恢复不会重复写入业务对象，失败运行不会被显示为成功，预算和停止条件在重试后仍生效。
- 质量测试必须分别断言原始材料谱系、上下文缺失显式性、去重/独立性标记和反证保留，禁止只断言“抓取条数”。
- 浏览器端在工作台真正接入后，只对关键路径做端到端测试：创建草稿、试运行预览、人工启动、暂停/取消、分诊一个信号和查看原文谱系。视觉细节不以脆弱快照取代行为验证。
Out of Scope
- 在本规格的首个实现中，建设覆盖全球所有平台、国家、语言或登录态的通用采集系统。
- 规避验证码、反爬机制、登录限制或平台访问控制。
- 自动把评论、热度、星标、众筹金额、情绪表达或语义相似度判定为真实需求、市场规模、付费意愿或盈利。
- 自动代表经营者发帖、私信、报价、投放广告、预售、收费或做出交付承诺。
- 用本体、弱关联或 Agent 输出直接提升 Need Issue 状态；它们只能产生带出处、反例、未知项和最小验证行动的假设。
- 多租户、团队权限体系、跨区域部署、微服务、Kafka、独立搜索/向量/图数据库或预先为全球规模做的基础设施。
- 全量重做现有来源、条目、作业和 Need Issue 功能；本规格通过兼容的纵向切片逐步接入。
- 修复与本功能无关的 Need Issue 响应缺陷；该缺陷需在独立 Issue 中处理，避免混淆变更范围。
Further Notes
核心成功标准
首个闭环成功不是“采集到 10 万条评论”，而是经营者能在受限时间和成本内完成一次真实任务，并得到以下至少一种可审计结果：
- 新增一条能改变 Need Issue 的支持或反证；
- 发现当前证据不足，并形成更具体的下一现实接触行动；
- 发现同源重复、上下文缺失或访问不可行，从而停止错误采集方向；
- 为一次 Product Thesis、验证实验或停止决策提供可回到原始材料的依据。
反成功指标
以下数据可以被记录，但不得单独作为成功、优先级或需求强度结论：采集条数、页面数、互动量、情绪强度、模型评分、来源数量、任务完成率和 Need Issue 数量。
强硬教练的结论状态
每个重要判断应落在四种状态之一：暂时支持并给出最小可逆行动；被证伪并停止；证据不足并继续获取；存在真实分歧并保留分歧。共识只表示对事实、未知项、风险和下一步达成一致，不表示经营者必须接受系统建议。
当前实现事实
已经完成并通过测试的第一纵向切片是：创建一条带预算和停止条件的 draft Acquisition Mission，并通过公开 API 重新获取；空停止条件被拒绝。它不是采集执行器，也不是完整工作台。下一条应优先实现试运行预览，验证采集前的范围、预算和上下文风险，而不是先扩展界面或堆叠来源。
title: SourceOS 采集任务工作台与证据导向采集管理产品规格
document_type: product-specification
status: ready-for-agent
version: v0.1
model: gpt-5
created_at: 2026-08-02 13:17 Asia/Shanghai
related_product_definition: ../product-definition/20260802-00：08-个人经营者证据化现实需求发现与产品验证智能体产品规划定义-gpt-5-v0.1.md
related_architecture: ../architecture/20260802-00：42-SourceOS证据化现实需求发现与产品验证智能体整体架构设计-gpt-5-v0.1.md
SourceOS 采集任务工作台与证据导向采集管理
Problem Statement
作为单人经营者，我缺少稳定接触现实世界的渠道，也无法可靠判断评论、讨论、差评、访谈记录和公开行为中哪些是独立、可追溯且能够改变产品判断的信号。现有“爬虫”或“采集工具”通常只回答抓到多少数据，却不回答为什么采、是否完整、是否来自同一传播链、是否补齐了关键不确定性，以及它是否改变了一个 Need Issue、验证行动或产品决策。
我需要一个私人使用的采集工作台，用有限的时间、金钱和注意力管理现实采集：定义来源与任务，明确证据缺口，运行受约束的采集，处理上下文与失败，分诊信号，保留反证，并将结果回流到 Need Issue 和后续现实验证。系统必须直说“不知道”、阻止无边界采集和同源重复造成的自我欺骗，但不把采集数量、热度、情绪强度或模型判断伪装成真实需求、付费意愿、留存或盈利。
Solution
SourceOS 提供以“采集任务（Acquisition Mission）”为中心的现实采集工作台。经营者先登记一个有明确覆盖范围和证据用途的采集源，再创建一条有现实问题、任务类型、来源、范围、预算和停止条件的任务。任务只能以
draft身份存在，直到通过试运行和人工启动进入实际执行；运行后产生可追溯的原始材料、External Signal、上下文状态、质量数据和进入 Evidence Inbox 的候选，而不是自动宣布发现了需求。工作台把采集管理分成七个相连但不混淆的面：采集源、采集任务、运行控制、信号分诊、上下文修复、质量与覆盖、结果校准。强硬教练在每个关键节点呈现基于事实的反对意见：例如“这批评论来自同一传播链”“缺失父帖导致上下文不可用”“你的任务没有反证路径”“停止条件是数据量，不是有效证据”。经营者保留最终决定权，但系统保留事实、未知项、异议、理由和下一步最小行动。
首个可用版本不建设“全球通用爬虫”。它以一个稳定、结构化、可 fixture 回放的公开来源完成纵向闭环；优先目标是让经营者在每天有限的工作时间内获得可以支持、反驳或缩小一个 Need Issue 的证据，而不是展示数据规模。
User Stories
Implementation Decisions
AcquisitionMission：它是一次受约束、可审计的采集意图，不等同于采集源、实际运行、External Signal、Evidence reference 或 Need Issue。AcquisitionMission初始状态为draft。首个已实现的公共接口允许创建草稿并按 ID 重新获取；该接口已确认是本规格的主测试接缝。exploratory、targeted_evidence、counterevidence、context_repair。不同类型使用不同的成功和停止判据，不能压缩为统一“机会分”。dry_run、queued、running、paused、completed、failed、cancelled等运行状态；这些状态属于运行事实，不能覆盖或混同任务定义的版本与意图。discovery_validated不代表付费、留存或盈利已经成立。Testing Decisions
Out of Scope
Further Notes
核心成功标准
首个闭环成功不是“采集到 10 万条评论”，而是经营者能在受限时间和成本内完成一次真实任务，并得到以下至少一种可审计结果：
反成功指标
以下数据可以被记录，但不得单独作为成功、优先级或需求强度结论：采集条数、页面数、互动量、情绪强度、模型评分、来源数量、任务完成率和 Need Issue 数量。
强硬教练的结论状态
每个重要判断应落在四种状态之一：暂时支持并给出最小可逆行动；被证伪并停止；证据不足并继续获取；存在真实分歧并保留分歧。共识只表示对事实、未知项、风险和下一步达成一致，不表示经营者必须接受系统建议。
当前实现事实
已经完成并通过测试的第一纵向切片是：创建一条带预算和停止条件的
draftAcquisition Mission，并通过公开 API 重新获取；空停止条件被拒绝。它不是采集执行器，也不是完整工作台。下一条应优先实现试运行预览，验证采集前的范围、预算和上下文风险，而不是先扩展界面或堆叠来源。