DoTodo Intelligence Engine / 技术方案

把每天的网页、聊天和转写稿，变成可以验证想法的长期智能引擎。

插件已经负责采集现场。后端要做的是把 source 变成 derived analysis、idea card、topic thread、memory candidate 和 verification report。

查看全链路 产出样例 看案例 MVP 路线
Execution Graph source -> idea -> decision
1
采集端Browser Sense、聊天导入、录音转写、手动笔记，把现场变成原始输入。
2
Source 层保留原文、URL、时间、hash、行为信号和来源，作为可回放事实。
3
Derived 层生成摘要、关键点、实体、问题、证据和行动项。
4
Index 层写入全文索引和向量索引，让历史内容可以被重新召回。
5
Idea / Thread抽取想法卡片，连接主题线、相似内容、支持和反驳材料。
6
验证报告对新想法输出可行性、风险、缺失证据和下一步实验。

动画现在按真实顺序从上到下推进：先收集，再保留 source，再结构化、索引、沉淀想法，最后产出验证报告。

01 / 全链路步骤

不要把所有能力揉成一个知识库。按责任拆成 7 个处理层。

点击左侧步骤，右侧动画会切换到对应阶段。第一版可以先做 1 到 5，图谱和长期记忆稍后接入。

1
观察浏览现场记录停留、滚动、复制、选中、手动保存和 active lens。
2
提取正文content-script 把页面正文提成 Markdown，同时保留 URL、title、domain。
3
进入本地队列浏览器 IndexedDB 暂存，后端离线时不丢，恢复后继续上传。
4
上传 Collector手动保存和自动候选都走统一接口，插件不直接写长期 memory。
结果：一条 browser source它还是原始资料，不是结论，也不是正式记忆。
这一阶段做了什么
  1. 判断页面是否值得保存。
  2. 把网页现场转成 Markdown + metadata。
  3. 把行为信号作为后续排序权重。
  4. 通过 Collector API 交给后端。
输入URL、标题、正文 Markdown、阅读时长、滚动、复制、选中、active lens。
现有项目对接browser-extension -> /collect/browser/page
原则手动保存是强意图；自动候选是 routing；不要让用户做人肉中间件。
1
标准化 URL去掉 fragment，计算 page_id，避免同一页面重复进入。
2
计算内容 hash用正文 Markdown 生成 content_hash，作为幂等和变更判断依据。
3
写入原文和元数据content/*.md 保存原文，pages/*.json 保存元数据和信号。
4
更新 manifest每日 manifest 和稳定 manifest 都刷新，给下游 worker 一个确定入口。
结果：可回放 source数据库可以重建，但 data/source 不能丢。
这一阶段做了什么
  1. 把原始输入变成稳定文件。
  2. 用 hash 做去重和幂等。
  3. 写入每日目录。
  4. 刷新下游可消费 manifest。
路径data/source/browser/YYYY-MM-DD/
稳定入口data/source/_manifests/browser.manifest.json
幂等键normalized_url + content_hash。会议可以用 minute_token + sha256。
1
读取新 sourceworker 只处理自己没见过的 content_hash 或 transcript hash。
2
做结构化理解LLM 输出摘要、关键点、实体、主张、问题、证据句。
3
区分事实和判断把“材料里说了什么”和“系统推断什么”分开记录。
4
记录 prompt 版本后续效果不好时可以重跑，而不是污染原始 source。
结果：derived analysis可筛选、可比较、可追溯的中间理解。
这一阶段做了什么
  1. 读 source 原文。
  2. 抽摘要、实体、claims、evidence。
  3. 标注证据强弱和开放问题。
  4. 保存为可重算的 derived 结果。
输出summary、key_points、entities、claims、questions、evidence、actions。
不要做不要在这一步直接生成最终结论。先把材料拆清楚。
提示词重点真实需求、非显然洞察、证据强弱、落地风险、可验证动作。
1
切分 Chunk按标题、段落和语义边界切分，保留 source 位置引用。
2
写向量索引为 chunk、summary、idea title 分别生成 embedding。
3
写全文索引关键词、专有名词、项目名和人名不只依赖向量召回。
4
合并排序结合时间、lens、手动保存、复制、重复访问和被引用次数。
结果：Hybrid Retrieval能找相似语义，也能精确找项目名和历史时间点。
这一阶段做了什么
  1. 把 source 切成可召回片段。
  2. 写入 pgvector。
  3. 写入 PostgreSQL FTS。
  4. 用行为信号和时间做 rerank。
MVP 推荐Postgres + pgvector + PostgreSQL FTS，先不要拆出太多基础设施。
权重手动保存、复制、重复访问、被 idea 引用的 source 排名更高。
查询例子“过去 30 天我看过哪些和 Agent 商业化有关的材料？”
1
扫描 Derived从 claims、questions、actions 里找可复用的想法苗头。
2
生成想法卡写 title、description、假设、适用场景、开放问题。
3
挂证据连接支持材料、反对材料和来源 source，不让想法悬空。
4
合并相似想法新想法不是每次新建，和历史 idea 做相似度与状态更新。
结果：Idea Card它是未来验证、写作和决策真正会复用的对象。
这一阶段做了什么
  1. 从内容中抽出“可继续推进的想法”。
  2. 给每个想法挂来源和证据。
  3. 识别相似旧想法。
  4. 维护 new/exploring/validated 等状态。
结构title、description、evidence_for、evidence_against、open_questions、status。
状态new、exploring、validated、rejected、active。
价值以后你提出新想法时，系统能找历史相似、支持材料和风险。
1
聚合主题线把同一主题下的网页、聊天、会议和 idea 放到一个 thread。
2
识别人和项目抽取参与人、项目、公司、承诺和长期状态变化。
3
生成记忆候选稳定偏好、重要承诺、项目状态进入 candidate，而不是直接写死。
4
审核和过期记忆必须有来源、版本、有效期、撤销入口和审计记录。
结果：Thread / Memory Candidate先轻量关系表，稳定后再接 Graphiti 或 Mem0。
这一阶段做了什么
  1. 把零散资料组织成长期主题线。
  2. 记录人、项目、想法之间的关系。
  3. 只把稳定事实放入记忆候选。
  4. 通过审核、过期和撤销保护边界。
Thread同一主题下的 source、idea、meeting、chat 自动聚合。
Memory Candidate只有稳定偏好、长期项目状态、重要承诺才进入候选。
后续增强Graphiti 做 temporal graph；Mem0 做 Agent 长期记忆层。
1
解析新想法把用户一句话拆成核心命题、目标用户、假设和验证问题。
2
召回历史材料找相似 idea、相关 source、会议讨论、聊天记录和反例。
3
组织证据把材料分成支持、反对、缺失证据和需要外部补充的信息。
4
生成验证报告输出可行性判断、风险、下一步实验，并回链所有 source。
结果：Verification Report它回答“这个想法值不值得继续推进”。
这一阶段做了什么
  1. 理解用户新想法。
  2. 找历史相似和相关证据。
  3. 区分支持、反对和缺口。
  4. 给出下一步最小验证动作。
用户输入“我有个想法：人主要负责聊天，AI 帮我沉淀和验证想法。”
系统输出历史相似、支持证据、反对证据、缺失信息、下一步实验。
交付物Verification Report，可回链到每个 source 和 idea。

02 / 每步产出样例

每一步都要留下可检查的中间产物，而不是只得到一个“AI 回答”。

下面用同一个例子串起来：你读到一篇关于 AI Agent 创业机会的网页，后来又在聊天里提出“用聊天驱动个人知识引擎”。

1

采集 Source：浏览器上传 payload

插件把网页现场转成一条可上传的 source，不在这里做最终判断。

下一步怎么用Collector 用 URL、content_hash 和 captured_at 做落盘、去重和审计。
{
  "source_type": "browser_page",
  "capture_mode": "manual",
  "active_lens_ids": ["ai_agent_startup"],
  "url": "https://example.com/agent-startup",
  "title": "AI Agent 创业机会：从工作流切入",
  "domain": "example.com",
  "captured_at": "2026-05-16T21:10:32+08:00",
  "signals": {
    "active_read_seconds": 186,
    "scroll_depth": 0.82,
    "selected_text_count": 2,
    "copied_text": true,
    "saved_manually": true
  },
  "content": {
    "markdown": "# AI Agent 创业机会\\n...",
    "word_count": 2830,
    "quality": {
      "page_type": "article_document",
      "text_density": 0.71
    }
  }
}
2

落盘与幂等：page record

Collector 写原文、元数据和 manifest，让后续 worker 有稳定入口。

下一步怎么用SourceIngestWorker 读取 browser.manifest.json，只处理没见过的 content_hash。
{
  "schema_version": "collector.browser.page_record.v1",
  "page_id": "9f6c...a21",
  "normalized_url": "https://example.com/agent-startup",
  "title": "AI Agent 创业机会：从工作流切入",
  "content_path": "data/source/browser/2026-05-16/content/9f6c.md",
  "metadata_path": "data/source/browser/2026-05-16/pages/9f6c.json",
  "summary_path": "data/derived/browser/2026-05-16/9f6c.summary.json",
  "content_hash": "sha256:3a9b...f11",
  "signals": {
    "saved_manually": true,
    "copied_text": true
  },
  "collector_result": {
    "accepted": true,
    "status": "stored"
  }
}
3

Derived 分析：结构化理解

把原文拆成摘要、主张、证据、问题和行动项，但还不生成最终结论。

下一步怎么用IndexWorker 用 derived 做索引；IdeaExtractorWorker 从 claims/questions 里抽想法卡。
{
  "source_id": "browser:9f6c...a21",
  "summary": "文章认为 AI Agent 产品应先切入明确工作流，而不是做泛助手。",
  "key_points": [
    "高频、可评估、可复用的工作流更适合早期商业化",
    "泛助手难证明 ROI，容易变成演示型产品"
  ],
  "entities": [
    {"type": "concept", "name": "AI Agent"},
    {"type": "concept", "name": "workflow automation"}
  ],
  "claims": [
    {
      "claim": "AI Agent 创业应从明确工作流切入",
      "evidence": "文章列举客服、销售跟进、代码审查等场景",
      "strength": "medium"
    }
  ],
  "open_questions": [
    "DoTodo 的第一条可验证工作流是什么？"
  ],
  "actions": [
    "把 Browser Sense MVP 的目标改成想法验证闭环"
  ]
}
4

Hybrid Index：可召回 chunk

同一份材料会进入全文索引、向量索引和时间/权重排序。

下一步怎么用当你问“历史上有没有类似想法”，系统用 hybrid retrieval 找 source、idea 和 transcript。
{
  "chunk_id": "chunk_9f6c_004",
  "source_id": "browser:9f6c...a21",
  "path": "data/source/browser/2026-05-16/content/9f6c.md",
  "text": "早期 AI Agent 产品不要从泛助手开始，应从可评估的工作流切入...",
  "embedding_ref": "pgvector:chunks.embedding",
  "fts_terms": [
    "AI Agent",
    "工作流",
    "商业化",
    "ROI",
    "泛助手"
  ],
  "ranking_signals": {
    "manual_save": 1.0,
    "copied_text": 0.7,
    "read_seconds": 186,
    "recency_days": 0
  }
}
5

Idea Card：想法卡片

这是系统真正要沉淀的认知资产，必须挂来源和证据。

下一步怎么用VerificationAgent 用 idea card 找历史相似、支持证据和反对证据。
{
  "idea_id": "idea_chat_driven_intelligence_engine",
  "title": "用聊天驱动个人智能情报引擎",
  "description": "人主要负责聊天和表达想法，AI 负责提炼、关联历史资料、验证可行性。",
  "status": "exploring",
  "source_ids": [
    "browser:9f6c...a21",
    "chat:2026-05-16:idea-talk"
  ],
  "evidence_for": [
    "已有 Browser Sense 采集端，source 可以持续进入系统",
    "网页材料支持从明确工作流切入，而想法验证是高频工作流"
  ],
  "evidence_against": [
    "聊天内容噪音高，自动写 memory 有隐私和误记风险"
  ],
  "open_questions": [
    "7 天内能否稳定抽出高质量 idea cards？",
    "验证报告是否比普通搜索更省时间？"
  ]
}
6

Thread / Memory：主题线和记忆候选

不是所有内容都写入长期记忆。先进入候选，再审核、过期、回滚。

下一步怎么用下次讨论 DoTodo MVP 时，系统可以带出这个 thread 的历史材料和待验证承诺。
{
  "thread": {
    "thread_id": "thread_browser_sense_mvp",
    "title": "Browser Sense MVP：从采集到想法验证",
    "source_ids": ["browser:9f6c...a21", "meeting:2026-05-16"],
    "idea_ids": ["idea_chat_driven_intelligence_engine"],
    "current_focus": "新想法输入后的历史验证报告"
  },
  "memory_candidate": {
    "memory_type": "project_state",
    "content": "DoTodo 第一版应优先验证：采集 -> idea card -> verification report。",
    "source_id": "meeting:2026-05-16",
    "confidence": 0.78,
    "approval": "pending",
    "expires_at": "2026-06-16"
  }
}
7

Verification：想法验证报告

最终输出不是搜索结果，而是基于历史材料的判断和下一步实验。

下一步怎么用用户根据报告决定继续推进、补证据、搁置或转成任务。
{
  "question": "用聊天驱动个人知识和想法验证引擎是否值得做？",
  "verdict": "值得做 MVP，但不应先做完整 GraphRAG。",
  "similar_history": [
    "Browser Sense 产品方案 v0.5",
    "AI 知识管理分层调研",
    "DoTodo 采集架构文档"
  ],
  "supporting_evidence": [
    {
      "source": "browser:9f6c...a21",
      "point": "文章支持从明确工作流切入，想法验证符合这个标准"
    }
  ],
  "counter_evidence": [
    "聊天噪音高，需要 memory candidate 审核机制",
    "只做问答 UI 会削弱产品差异"
  ],
  "missing_evidence": [
    "连续 7 天真实输入后的 idea 抽取准确率",
    "验证报告是否能减少用户整理和搜索时间"
  ],
  "next_experiment": "先做一个 CLI/Web 页面：输入新想法 -> 找历史相似 -> 输出验证报告。"
}

03 / 详细案例

三种输入进入系统后，最后都会变成可复用的判断材料。

每个案例都展示从采集、分析、关联到最终产物的流动方式。

案例 A：读到一篇 “AI Agent 创业机会” 长文
1
插件采集用户阅读 3 分钟、复制一段价格策略、手动保存。
2
Derived抽出观点：AI Agent 产品要从明确工作流切入，而不是泛助手。
3
Idea生成想法卡片：Browser Sense 可以作为创业者认知工作流入口。
4
Relation关联到历史的 DoTodo 产品方案、AI Team Work OS 报告。
5
Verification输出商业化判断：适合从个人高频研究者开始验证。

输出示例：Idea Card

标题：聊天驱动的个人智能情报引擎

AI Agent 创业 Browser Sense 个人认知资产 
{
  "status": "exploring",
  "evidence_for": [
    "用户已经在浏览器插件中沉淀 source",
    "资料价值来自后续复用，不是收藏本身"
  ],
  "open_questions": [
    "MVP 用户是否每天愿意保存 5 条以上 source",
    "验证报告是否比普通搜索更省时间"
  ]
}
案例 B：和朋友聊到一个产品想法
1
聊天导入导入对话片段：“未来人主要负责聊天，AI 负责提炼和验证。”
2
命题抽取识别核心命题：自然对话可以成为知识系统的主输入。
3
历史检索找到你之前保存过的 LLM Wiki、Mem0、Graphiti、Browser Sense 文档。
4
冲突检查提示风险：聊天噪音高、隐私边界难、记忆写入要审计。
5
下一步建议先做“新想法输入 -> 历史相似 -> 验证报告”的闭环。

输出示例：验证报告摘要

判断：方向成立，但 MVP 不应该先做完整 GraphRAG，应先做 idea cards。

支持：已有采集端 风险：隐私 实验：7 天日总结 
{
  "feasibility": "medium-high",
  "similar_history_count": 6,
  "next_experiment": "连续 7 天输入网页和聊天，检查 idea 抽取命中率",
  "do_not_build_first": ["完整图谱", "复杂权限", "万能聊天 UI"]
}
案例 C：会议录音转文字稿
1
音频源Collector 已经采集飞书会议音频，转写 worker 生成 transcript。
2
结构化抽取决策、承诺、问题、待办、参与人和项目。
3
Memory Candidate“下周要验证插件自动候选打扰率”进入记忆候选，而不是直接写死。
4
Thread归入 Browser Sense MVP thread，和网页资料、聊天想法合并。
5
复用下次讨论 MVP 时自动提示上次承诺、未验证风险和相关资料。

输出示例：Memory Candidate

候选记忆需要来源、有效期、置信度和人工确认状态。

项目状态 待验证 可审计 
{
  "memory_type": "project_state",
  "content": "Browser Sense MVP 下一步验证自动候选打扰率",
  "source": "meeting_transcript_2026_05_16",
  "expires_at": "2026-06-16",
  "approval": "pending"
}

04 / 数据对象

系统里真正长期存在的，不是“回答”，而是这些可重建、可审计的对象。

Source 是地基；Idea 是资产；Verification Report 是把资产变成判断的交付物。

Source

网页、聊天、会议、笔记的原始材料。必须有来源、时间、hash 和原文路径。

Derived

摘要、关键点、实体、claims、questions、evidence、actions。

Chunk

面向检索的切片，连接 source、embedding、全文索引和位置引用。

Idea

从材料里抽出的想法卡片，包含支持证据、反对证据和开放问题。

Thread

长期主题线，把相关 source、idea、meeting、chat 组织成认知轨迹。

Memory

稳定偏好、项目状态、历史承诺。必须有版本、来源、有效期和撤销机制。

05 / MVP 路线

先打通“每天输入 -> 自动提炼 -> 新想法验证”的小闭环。

这条路线和现有 Browser Sense 最顺，不需要第一天上完整知识图谱。

第 1 步

消费现有 browser manifest，把 source 入 Postgres，记录处理状态。

第 2 步

生成 derived analysis：摘要、实体、问题、证据、行动项。

第 3 步

建立 pgvector + FTS hybrid retrieval，支持相似资料检索。

第 4 步

抽取 idea cards，做相似 idea 和 source 的历史关联。

第 5 步

输入新想法，生成验证报告，并回链到原始 source。

06 / 工程拆分

建议新增后端大脑层，不继续把复杂能力塞进插件。

插件保持轻；后端负责持久化、索引、工作流和审计。

建议目录

backend/
  app/
    api/
    workers/
    models/
    services/
    prompts/
    repositories/
  migrations/
  pyproject.toml

Worker 拆分

✓
SourceIngestWorker
读 manifest，入库，幂等。
✓
DeriveWorker
生成结构化理解。
✓
IdeaExtractorWorker
抽取 idea cards。
✓
VerificationAgent
把检索结果变成判断报告。

07 / 关键决策

第一版的克制点，决定系统能不能真的跑起来。

这些约束能避免项目过早进入“架构很完整，但没有日常价值”的状态。

✓
Source 永远优先于摘要。
摘要可以重算，原文和来源不能丢。所有报告必须能回链。
✓
先 Postgres + pgvector。
等数据量、查询模式和延迟瓶颈明确后，再拆 Qdrant、Neo4j、Elasticsearch。
✓
Memory 先候选，后晋升。
Agent 记忆不能随便写。要有来源、版本、有效期、撤销和审计。
✓
Graph 先轻量关系表。
等 thread、entity、idea 关系稳定后，再接 Graphiti 或 Neo4j。
✓
产品第一闭环是验证报告。
不是“问答机器人”，而是帮你判断新想法和历史材料之间的关系。
总结：DoTodo Browser Sense 负责把阅读现场变成可追溯 source；DoTodo Intelligence Backend 负责把 source 变成 idea、thread、memory candidate 和 verification report。第一版只要跑通“采集 -> idea -> 历史验证”，这个产品就有了自己的灵魂。