跳转至

Repo、Evidence、Knowledge、Site 与企微的分工

核心口径

这个 repo 不是普通文档仓库，而是 Harness 未来产品形态的 MVP 工作空间。 一个团队、项目组、部门或公司都可以拥有类似 workspace，用它承载状态看板、 证据、知识、决策、实验报告、连接器、验证脚本和发布网站。

当前路径虽然保留旧文件名，内容口径已经迁移到新结构：

  • Evidence：原始证据和来源追溯。
  • Knowledge：团队知识生产和决策沉淀。
  • Registry：系统可读的本体、状态、路由和权限索引。
  • Site：发布给团队阅读的网站。
  • WeCom：企业微信交互入口和主动询问通道。

当前分工

层 角色 里面放什么 不适合放什么
Repo 实验和版本底座 Framework、workspace、测试、CI、生成器、协作规则 只停留在口头、不落地的结论
Evidence 原始证据层 inbox、raw、文件上传样例、外部来源线索、Evidence Registry 未脱敏的聊天全文、token、cookie、真实客户材料
Knowledge 知识生产层 wiki、projects、decisions、system 规则和维护日志 未确认就发布给团队的结论
Registry 机器索引层 workspace topology、人员、部门、项目、任务、上下文库、权限视图、实验登记、项目状态 长篇解释性文档和原始聊天材料
Site 发布阅读层 稳定、结构化、团队可读、客户安全的页面 原始证据、粗糙草稿、敏感材料
企微 交互入口 提问、通知、主动询问、确认、轻量阅读链接 长文档编辑、版本管理、私域原始数据仓储

Evidence、Knowledge 和 Site 的区别

Evidence 回答“事实从哪里来”。

workspaces/variai/evidence/inbox/
workspaces/variai/evidence/raw/
workspaces/variai/evidence/ingestion/
workspaces/variai/evidence/registry/

Knowledge 回答“团队当前怎么理解和决策”。

workspaces/variai/knowledge/wiki/
workspaces/variai/knowledge/projects/
workspaces/variai/knowledge/decisions/
workspaces/variai/knowledge/system/

Site 回答“团队成员应该读哪份稳定页面”。

workspaces/variai/site/
mkdocs.yml

一个材料的生命周期通常是：

Evidence
  -> Knowledge
  -> Registry / Runtime Projection
  -> Site

为什么还需要 Site

企微接入后，企微会成为主要输入输出入口，但它不替代发布层：

  • 用户在企微提问或发起任务。
  • Agent 在企微里主动询问、通知和请求确认。
  • 简短答案直接回到企微。
  • 复杂内容跳转到 Site 页面。
  • 稳定方案仍需要可引用、可审查、可版本化的网页表达。

所以 Site 是稳定知识的网页渲染层，企微是交互层，Git 是版本和 review 层。

作为搜索 benchmark 的意义

这个 repo 天然适合作为第一批 Context Router 和 Agentic Search benchmark， 因为它同时包含：

  • Evidence 原始讨论和材料线索。
  • Knowledge 编译后的 wiki、项目页和 ADR。
  • Registry 里的组织、任务、权限、实验和项目状态。
  • Site 发布页面。
  • Framework 代码、测试和生成器。

好的上下文系统应该能区分：

  • 用户要看正式结论时，优先引用 Site 或 reviewed Knowledge。
  • 用户要追溯来源时，回到 Evidence。
  • 用户要看开发进度时，读取 Registry 生成的研发进度页。
  • 用户问“为什么这样决策”时，查 ADR。
  • 用户问“系统怎么配置”时，查 Registry 和 system 规则。

作为产品 MVP 的意义

未来客户团队不一定直接感知 repo 内部结构，但产品必须提供类似能力：

  • 团队成员通过状态看板知道当前进度。
  • Agent 能从 Evidence、Knowledge、Registry 和 Site 中组合最小充分上下文。
  • 决策可以追溯到 ADR 和 Evidence。
  • 实验结论和下一步可以复盘。
  • 企微、飞书或 Web 工作台可以把这些能力包装成更容易使用的入口。

因此当前 repo 的目录结构、导航和看板都按产品 Demo 标准维护，而不是只按 内部文档仓库标准维护。