Project Spec: SourceOS 个人经营者证据化现实需求发现与产品验证

[zeropclab]

---

title: SourceOS 个人经营者证据化现实需求发现与产品验证全项目产品规格
document_type: project-product-specification
status: ready-for-agent
version: v0.1
model: gpt-5
created_at: 2026-08-02 13:23 Asia/Shanghai
scope: entire-project

SourceOS：个人经营者证据化现实需求发现与产品验证

Problem Statement

作为仍在上班、每天通常只有约两小时可投入的个人经营者，我尚未经历过一个产品从真实需求、销售、交付、复购到持续盈利的完整闭环。我缺少接触真实问题、获得独立信息、识别隐性需求、验证付费意愿、定义可交付产品、衡量留存与贡献利润的稳定能力。

评论、Issue、众筹、社区讨论、产品评价和现实对话可能提供有价值的观察，但它们并不自动等于需求。数据量、热度、情绪、点赞、模型输出和本体关系都可能制造进展感、确认偏误或伪精确。即使一个问题存在，也仍然不知道谁会付费、从哪里触达、能否交付、能否留存、成本是否可承受。因此，单独做爬虫、知识库、模型助手或产品原型都不足以解决核心问题。

我需要一个只服务于我自己的经营系统：它能把现实世界的 External Signal 转化为可追溯证据和可证伪 Need Issue，逼迫我寻找反证和真实接触，形成可报价、可交付、可测量的 Product Thesis 与 Feature definition，再将开发、发布、用户行为、付费、留存、退款、成本和贡献利润回流到下一轮判断。系统的终极价值不是生成更多分析，而是提升我持续发现、验证、构建并经营真实价值的能力，直到能获得可持续收益。

Solution

SourceOS 是一个本地优先、单人使用、证据驱动且强对抗的现实需求发现与产品验证工作台。它把经营过程组织为一条可审计链路：现实采集与人工观察 → External Signal → Evidence reference → Need Issue → 反证与发现验证 → Product Thesis / Offer → Feature definition 与 Tracking plan → 开发、Review、PR、版本和发布 → 产品结果、付费、留存与贡献利润 → 对来源、判断、Agent 和本体关系的校准。

系统不承诺自动找到盈利产品。它通过边界、状态机、预算、停止条件、追溯和反证机制，降低“我以为我在发现需求，其实在收集支持自己想法的数据”的概率。Pi Agent 只是可替换的受控认知执行平面：它可从受限证据包中提出草案、竞争解释、反证或下一步，但不能自行把假设写成事实，不能自行决定发现验证通过，也不能代表经营者向外界做出承诺。

SourceOS 的产品体验是一个克制、可信、反幻觉的研究与经营工作台。它优先显示：目前知道什么、不知道什么、最强反对意见、证据出处、风险、下一项最小现实行动。它不以数据大屏、万能评分、夸张鼓励或“巨大商机”叙事替代决策。

User Stories

1. 作为个人经营者，我希望在今天页面看到最重要的一项现实行动、它的证据依据和最强反对意见，以便有限时间不被低价值任务分散。
2. 作为个人经营者，我希望设置每日两小时和同时在制数量限制，以便系统不鼓励无限并行的研究、验证和开发。
3. 作为个人经营者，我希望手工记录访谈、销售对话、观察、邮件和线下反馈，以便现实输入不依赖公开评论。
4. 作为个人经营者，我希望登记来源的人群、情境、市场、语言、访问方式、预期证据和实际成本，以便知道为何采集它。
5. 作为个人经营者，我希望以版本化来源配置管理查询、关键词、频道、账号、排除项和访问策略，以便历史采集可解释、可回放。
6. 作为个人经营者，我希望创建带现实问题、任务类型、范围、预算和停止条件的采集任务，以便不把“多抓一些数据”当作目标。
7. 作为个人经营者，我希望在正式采集前看到试运行预览，以便发现访问失败、样本偏差、上下文缺失和成本不可接受的问题。
8. 作为个人经营者，我希望启动、暂停、恢复、取消、重试和终止采集运行，以便我始终控制外部动作与预算。
9. 作为个人经营者，我希望每个运行保留原始响应、来源版本、解析版本、时间、分页、错误和检查点，以便可追溯和可恢复。
10. 作为个人经营者，我希望看到父帖、回复链、时间顺序、删除节点、附件、字幕和缺失上下文，以便不从孤立句子推断需求。
11. 作为个人经营者，我希望系统显式显示同源传播、转载、营销、机器人和不明身份风险，以便不把重复内容看作独立市场。
12. 作为个人经营者，我希望在 Evidence Inbox 分诊候选信号为接受、忽略、合并、反证或上下文修复，以便保留人工判断和审计。
13. 作为个人经营者，我希望能从每个 External Signal 回到原始材料和采集过程，以便随时检查系统是否断章取义。
14. 作为个人经营者，我希望把信号、支持证据、反证、未知项与自己的解释分开标记，以便事实和推断不混在一起。
15. 作为个人经营者，我希望从证据创建一个 Need Issue，并清楚记录行动者、情境、触发、受阻任务、问题、替代方案、代价和期望结果，以便问题定义可复核。
16. 作为个人经营者，我希望为每个 Need Issue 记录支持证据和反证，并追踪它们的独立性和谱系，以便不靠单一来源升级结论。
17. 作为个人经营者，我希望修改关键 Need Issue 字段时保留版本与理由，以便未来能理解判断为何改变。
18. 作为个人经营者，我希望 Need Issue 只能沿合法状态路径变化，以便“发现验证”不会被开发进度或主观热情越级替代。
19. 作为个人经营者，我希望拒绝、休眠和重开 Need Issue 时记录原因、新证据和竞争解释，以便失败成为资产而不是被删除。
20. 作为个人经营者，我希望 Pi Agent 只能在指定证据包和明确任务中运行，以便它不会把无边界猜测伪装成研究。
21. 作为个人经营者，我希望查看每次 Agent Run 的输入、模型、提示版本、工具、引用、输出、成本、错误和人工修改，以便 Agent 结论可审计。
22. 作为个人经营者，我希望 Agent 能提出需求草案、反证、竞争解释、缺失上下文和下一验证动作，以便扩大认知而不接管判断。
23. 作为个人经营者，我希望在运行中暂停、取消或要求 Agent 寻找反证，以便它的产出服从当前现实问题。
24. 作为个人经营者，我希望每个重要结论都有强硬教练的异议、依据、未知项、可证伪条件和最小下一步，以便避免确认偏误。
25. 作为个人经营者，我希望系统在证据不足时明确说“不知道”，以便我不会把空白解读为机会。
26. 作为个人经营者，我希望建立现实验证实验，明确验证对象、假设、方法、渠道、预算、通过阈值、失败阈值和停止条件，以便把“问题看起来存在”推进到可验证行动。
27. 作为个人经营者，我希望所有私信、报价、广告、预售、收费、交付承诺和发布外部动作都必须由我批准，以便系统不擅自代表我行动。
28. 作为个人经营者，我希望记录回应、拒绝、无回应、预约、试用、预付、付款、退款、支持负担和交付结果，以便失败路径与成功路径同样可学习。
29. 作为个人经营者，我希望从一个经发现验证的 Need Issue 建立多个 Product Thesis，以便不把一个问题与单一解决方案绑定。
30. 作为个人经营者，我希望为 Product Thesis 明确使用者、受益者、决策者、付费者、触发、承诺结果、替代方式、信任路径、渠道、价格和交付机制，以便能真正测试报价。
31. 作为个人经营者，我希望先用人工或服务化交付验证结果，再决定自动化什么，以便不在未验证前建设过度产品。
32. 作为个人经营者，我希望记录每个报价、购买、拒绝、退款和交付成本，以便知道方案是否具有经济性。
33. 作为个人经营者，我希望只有获得建设授权的 Product Thesis 才能产生 Feature definition，以便开发不抢跑真实验证。
34. 作为个人经营者，我希望在 Feature definition 中固定用户任务、范围、不做什么、验收标准、Tracking plan、成功阈值、负指标和回滚条件，以便功能不是模糊愿望。
35. 作为个人经营者，我希望将 Feature definition 拆为开发 Issue，并让 Need Issue、产品命题、功能、分支、PR、版本和发布互相追溯，以便交付不脱离原始需求。
36. 作为个人经营者，我希望在合并前看到测试、静态检查、验收、Review、迁移、Tracking 验证、风险和回滚证据，以便发布前的判断可复核。
37. 作为个人经营者，我希望只有通过 Review 并形成 PR 证据后才能合并主分支，以便版本控制与交付质量成为闭环一部分。
38. 作为个人经营者，我希望记录版本、发布时间、目标人群、暴露范围、异常和回滚，以便发布结果可归因。
39. 作为个人经营者，我希望按 Tracking plan 记录激活、关键任务完成、重复使用、付费、退款、支持时间、基础设施成本和本人合理工时，以便产品结果是可观察的。
40. 作为个人经营者，我希望依据预先设定的成功阈值和负指标做保留、迭代、回滚或停止决定，以便不在结果出现后改写标准。
41. 作为个人经营者，我希望计算贡献利润而不是只看收入，以便判断产品是否能长期养活我。
42. 作为个人经营者，我希望查看来源、证据组合、Agent 建议、本体关系和产品决策在过去对结果的预测表现，以便持续校准系统。
43. 作为个人经营者，我希望使用本体关系发现角色错位、交接断点、约束冲突、跨领域同构和负空间，以便产生新的需求假设。
44. 作为个人经营者，我希望每条弱关联都保留关系路径、来源、反例、未知项和最小验证动作，并标记为 hypothesis，以便本体不会成为自我说服机器。
45. 作为个人经营者，我希望管理开发利用与开放探索的独立预算，以便既能提高已有有效渠道的产出，也能发现未知方向。
46. 作为个人经营者，我希望系统按地区、语言、人群和证据类型展示来源覆盖与偏差，以便全球扩展基于有效证据而不是清单数量。
47. 作为个人经营者，我希望在桌面端使用完整工作台，在移动端处理阅读、快速记录和有限审批，以便工具适合真实工作环境。
48. 作为个人经营者，我希望界面尊重我但不顺从我：它批判假设和证据，不攻击个人，并在否定方向时给出最小下一步，以便我能持续面对现实。

Implementation Decisions

• SourceOS 是单一经营者的私人经营系统，不是多租户 SaaS。它的核心价值是决策质量和经营能力，而非向公众出售采集或 AI 功能。
• 整体采用本地优先、模块化单体：Web/API、Worker 和领域模块围绕同一 PostgreSQL 事实源协作；原始材料进入内容寻址文件仓；外部系统通过可替换 Adapter 接入。
• 领域对象保持明确边界：External Signal 是观察；Evidence reference 是对观察或验证结果的不可变引用；Need Issue 是内部问题记录；Discovery validation 是有限的发现结论；Product Thesis 是可报价的方案假设；Feature definition 是受建设授权约束的实现响应；Tracking plan 是发布后的学习契约。
• 关键谱系必须可追溯：原始现实信号 → 证据与反证 → Need Issue 版本 → 验证实验 → Product Thesis / Offer → Feature definition → Release → 行为、付费、留存、成本与贡献利润 → 下一轮校准。任何不能增强真实性、速度、可恢复性或决策质量的能力不是当前优先项。
• 采集能力由 Source Profile、Acquisition Mission 和实际运行三层组成。任务必须有范围、预算和停止条件；原始响应优先于解析结果保存；缺失上下文必须显式记录；成功抓取不等于获得有效证据。
• Need Issue、Product Thesis、Feature delivery 使用独立状态机，禁止一个状态机的进展伪装成另一个层次的成功。discovery_validated 不代表愿意付费、留存或盈利；发布不代表产品成功。
• Pi Agent 是运行级、版本化、可审计的辅助组件。它只从受限 Evidence Bundle 与受控工具读取材料，输出 proposal；它不能自行访问任意网络、写入业务事实、跨越验证门禁或发起外部商业动作。
• 强硬教练是产品规则而不是人格装饰。它默认审查样本偏差、伪需求、付费意愿、触达渠道、替代方案、交付成本、留存、机会成本和反证；它基于新事实提出异议，旧异议不得反复表演。
• 现实验证与市场回应是正式领域对象。每个实验必须说明假设、对象、方法、成本、时间、通过/失败阈值、停止条件与经营者批准；拒绝、无回应、退款和负利润均需保留。
• Feature definition 只有在建设授权后创建，必须包含受限范围、验收标准、Tracking plan、成功阈值、负指标和回滚条件；然后才可进入开发 Issue、Review、PR、版本和发布过程。
• 交付与版本控制需要以 Git 分支、Review、测试、PR、合并、迁移、发布和结果记录形成谱系，但系统在第一阶段以本地 Git 读取与手工证据为主，不自动执行远程破坏性操作。
• 产品结果必须统一记录正负结果和全量关键成本：获客、平台、模型、基础设施、退款、交付与合理工时。经营决策以贡献利润和预先固定阈值为基础，而非只看收入、注册或活跃。
• 本体用于生成可追溯的关系缺口与弱关联假设，不能自动提升为真实需求。它必须保存关系路径、反例、未知项和最小现实验证动作，并接受结果校准。
• 用户体验采用桌面优先的“现实证据工作台”：当前行动、证据、异议和下一步优先；复杂控制、原始材料、审计与技术细节按需展开；移动端范围保持克制。
• 全球扩展以 Unicode、语言、时区、货币、区域和来源偏差从数据模型第一天正确表达为前提，但不预建设全球分布式架构、不以来源数量定义覆盖。
• 首个可用产品优先验证一条真实纵向链，而非并行建设所有模块：一个稳定来源或人工输入 → 可追溯 Evidence → Need Issue → 反证/现实验证 → Product Thesis → 一个可测量 Feature 或服务化交付 → 结果反馈。

Testing Decisions

• 好测试通过用户或调用者能观察到的公共行为验证规格，不依赖私有实现、内部协作者调用次数、数据库偶然结构或自行复刻实现的期望值。
• 整个项目的主测试接缝是“经营者通过公开工作台/API 完成一次现实到结果的纵向旅程”。它涵盖采集/人工输入、证据、Need Issue、验证、命题、功能、交付与结果，但每次实现只切出一个最小垂直行为，不试图一次测试全链。
• 已确认的第一公共 HTTP 子接缝为 Acquisition Mission：创建受预算和停止条件约束的草稿任务，并能用 ID 取回；空停止条件必须被拒绝。该能力已以先红后绿的方式实现。
• 已有异步 API 测试为先例：来源、条目、作业、Need Issue 和采集任务通过真实 FastAPI HTTP 边界与测试 PostgreSQL 验证。继续优先使用此类测试，而不为领域对象堆叠内部 mock。
• 每个纵向切片遵守 red → green：先写一个失败的行为测试，再只写最小实现使其通过；重构和扩大范围留给独立 Review 阶段，不批量预写未来测试。
• 采集 Adapter 使用固定 fixture 和离线回放测试覆盖分页、限流、超时、空结果、结构变化、删除节点和幂等重试；网络探针只能补充真实访问验证，不能替代可重复测试。
• 关键状态机用 API 与性质测试验证：非法跃迁被阻止；中断后恢复不重复产生业务效果；失败不被显示为成功；反证、未知项和批准记录不会被覆盖。
• Agent 测试验证协议、边界和可审计性：受限输入、工具白名单、中止、重试、输出结构、引用存在性和人工批准。测试不把模型文本质量或“看起来聪明”当作通过标准。
• 浏览器端仅对关键人机闭环做端到端测试：创建采集任务、查看原文谱系、创建 Need Issue、记录反证、批准实验、形成 Feature definition、登记交付结果。视觉样式不以脆弱快照替代行为验证。
• 迁移、备份恢复、任务重放、权限批准、Tracking 事件与贡献利润计算属于发布前验证；每条测试结果都应能被纳入 Review/PR 证据。

Out of Scope

• 自动保证盈利、自动找到需求、自动证明市场规模，或以系统输出代替现实销售、交付和留存。
• 在首阶段连接全球所有平台、语言、国家或登录态来源，或为“未来全球规模”预建设微服务、Kafka、Kubernetes、跨区域分片、独立图/向量/搜索集群。
• 规避验证码、访问控制、登录限制或平台机制；任何外部沟通、报价、收费、投放、预售、发布和停止都不能由 Agent 自行决定。
• 将评论量、情绪、star、众筹金额、模型评分、本体相似度或采集规模直接作为需求强度、付费意愿、留存或盈利结论。
• 面向公众售卖 SourceOS、建设团队协作、复杂权限、多租户账务或社交功能。
• 在尚未完成一条真实纵向链之前，大规模美化仪表盘、堆叠采集来源、训练专有模型或构造巨型本体。
• 与当前项目范围无关的既有缺陷修复；例如现有 Need Issue 响应的 evidence_count 缺失应作为独立修复切片，不能伪装为本规格的完成。

Further Notes

产品成功的层级

SourceOS 必须持续区分以下层级，禁止跳级表述：

观察到信号
→ 证据可追溯
→ 问题有暂时支持
→ 问题通过发现验证
→ 方案可交付
→ 有人愿意付费
→ 用户获得结果并留存
→ 单位经济性为正且可持续

任何一层失败都不是经营者个人失败，而是一个假设被否定或证据不足；系统应记录原因并给出停止、修正或最小下一行动。

里程碑

里程碑	目标	可演示成果
M0 证据脊柱	真实输入到 Need Issue 可追溯	从一条信号建立带支持/反证的 Need Issue
M1 受控认知	Pi 受限协助与反证门禁	Agent 提出草案但不能越权验证
M2 进入现实	实验、报价、回应与经济性	一次真实外部行动改变 Product Thesis
M3 建设测量	功能定义到发布与 Tracking	一个 Feature 有验收、PR、版本和结果
M4 个人复利	WIP、本体和预测校准	系统帮助减少错误方向或提高现实行动质量
M5 受控扩展	来源组合按效果扩展	新来源因有效证据和决策价值而被保留

最强冷水

SourceOS 本身可能成为一种高级拖延：用采集、图谱、Agent、规划和漂亮工作台制造“正在创业”的感觉。对抗方式不是否定工具，而是持续要求每项能力回答：它是否帮助经营者更快接触现实、淘汰错误方向、获得可验证的对象、完成一次真实交易或改善贡献利润？如果答案长期是否定的，应停止扩建该能力。

当前实现事实

当前项目已有来源、条目、作业、Need Issue 和采集任务的初步 API 基础。最新完成的采集任务切片支持创建并读取带预算和停止条件的 draft 任务，空停止条件被拒绝；它尚未执行真实采集。完整产品仍处于规格、原型和早期纵向实现阶段，不能被描述为市场验证完成。

子规格关系

采集任务工作台子规格是本项目规格的一个可独立交付部分。后续 Issue 应按上述里程碑切为纵向片段，并始终保留从项目级目标到子规格、测试、PR、发布和结果的追溯。