跳转至

团队项目 Repo：产品 MVP 形态

核心结论

当前这个仓库不只是 OrgReOrg / Harness 的研发仓库，也是未来产品形态的最小 Demo。

未来一个项目组、部门或客户团队，可以拥有一个类似的团队项目 repo。这个 repo 不只是存代码或文档，而是承载：

  • 当前状态看板。
  • 团队知识库。
  • 决策记录。
  • 实验报告。
  • 任务技能包。
  • 测试和 benchmark。
  • 发布网站。
  • 企微 / 飞书 / Web 的交互入口。

换句话说，未来产品不是单纯给团队一个聊天机器人，而是给团队一个可演进的 Agentic Knowledge Workspace。

为什么 repo 是 MVP 容器

P0 阶段，一个 repo 已经能提供很多企业协作所需的基础能力：

能力 repo 中的实现
版本管理 Git commit、branch、PR、review
知识生产 vault/00-inbox、vault/10-raw、vault/20-wiki
决策追溯 vault/40-decisions、docs/knowledge/decision-log.md
状态同步 domain/orgreorg-demo/project-status.json -> docs/project-progress.md
发布阅读 docs/、MkDocs、Cloudflare Pages
实验验证 framework/evals、scripts/ wrapper、tests/、vault/50-outputs
Agent 工作规则 AGENTS.md、CLAUDE.md、任务技能包
质量门禁 vault_lint、MkDocs strict build、pytest、CI

这不是最终产品的全部形态，但它是最小可运行形态。

最小团队空间结构

未来给一个团队或部门创建空间时，最小结构可以是：

text team-project/ AGENTS.md CLAUDE.md packaging.manifest.json framework/ connectors/ context/ dashboard/ evals/ governance/ policy/ task_skills/ templates/ workflows/ domain/ <team-domain>/ mkdocs.yml docs/ index.md project-progress.md knowledge/ decision-log.md roadmap.md experiments.md vault/ 00-inbox/ 10-raw/ 20-wiki/ 30-projects/ 40-decisions/ 50-outputs/ 90-system/ scripts/ vault_lint.py package_boundary_lint.py generate_project_progress.py eval_*.py tests/ wecom/

P0 已经开始用结构化状态数据生成 project-progress.md：当前 Demo 的私域状态写在 domain/orgreorg-demo/project-status.json，通用生成器在 framework/dashboard/project_status.py，CLI wrapper 是 scripts/generate_project_progress.py。产品化后，应该继续从项目计划、实验报告、ADR、issue、PR、知识卡片和工具日志中自动生成更多字段。

可打包层与私域层

当前 repo 是完整 MVP，但未来产品化时不能把整个 repo 原样打包。它要拆成两层：

  • 可打包层：Agent 工作规则、项目空间模板、vault/docs/dashboard 结构、SearchConnector、Tool Gateway、WeCom adapter contract、eval harness、任务技能包规范、权限和审计规则。
  • 私域层：当前 OrgReOrg / Harness 的项目讨论、路线图、实验语境、真实 owner、组织职责、业务资料和团队知识库内容。

当前 MVP 的领域知识是“如何开发这个 Demo”。未来某个部门或项目组使用产品时，这部分会替换成它自己的部门知识、项目状态、业务流程和组织事实。

因此后续新增文件时需要先判断：

文件类型 默认归属 说明
adapter contract、schema、lint、generator、eval harness 可打包 用合成 fixture 验证
任务技能包 manifest、模板和 lint 可打包 包内不存组织事实，只存任务工作流和验证方法
vault/00-inbox、vault/10-raw、项目 ADR、真实讨论 私域 不进入通用产品包
domain/<team-domain>/project-status.json 私域 每个团队替换成自己的状态数据
docs/project-progress.md 混合 页面结构由 generator 生成，当前状态内容不可打包
企业微信接口代码 混合 adapter 可打包，真实通讯录和消息不可打包

当前 repo 已经前置建立 framework/、domain/orgreorg-demo/ 和 packaging.manifest.json。后续不再把新的可打包代码继续堆在 scripts/；稳定模块应迁入 framework/，scripts/ 只保留 CLI wrapper 和兼容入口。

状态看板应该回答什么

团队成员进入项目空间后，第一眼应该知道：

  • 当前项目处在什么阶段。
  • 预期目标是什么。
  • 哪些模块已经完成。
  • 哪些模块正在进行。
  • 哪些模块被阻塞。
  • 每个实验结论是什么。
  • 决策依据在哪里。
  • 下一步应该做什么。

所以 docs/project-progress.md 不是普通文档，而是未来产品里的项目状态视图原型。

与企微 / 飞书 / Web 的关系

未来普通团队成员不一定直接打开 GitHub。

更合理的入口是：

text 企业微信 / 飞书 / Web -> 查看项目状态 -> 提问或补充资料 -> 接收主动询问 -> 审核知识卡片 -> 跳转到 docs 页面阅读稳定内容

repo 仍然是底座：Agent、工程成员和发布系统在 repo 中维护知识、决策、测试和发布内容。

当前 repo 的自审

当前已经具备：

  • docs/project-progress.md：研发进度总览。
  • domain/orgreorg-demo/project-status.json：结构化项目状态数据。
  • framework/dashboard/project_status.py / scripts/generate_project_progress.py：项目状态页生成器和 CLI。
  • vault/：知识生产和决策沉淀。
  • docs/：团队阅读网站。
  • framework/ / scripts/ / tests/：本地实验、可复用实现、CLI wrapper 和验证。
  • 双远程 GitHub 推送和 Cloudflare Pages 发布镜像。
  • ADR-014 自试用自演进闭环。
  • ADR-015 任务技能包治理。

当前还缺：

  • 从 ADR、issue、PR、知识卡片和工具日志自动汇总更多看板字段。
  • 真实企微入口。
  • 结构化 owner / module / status 数据。
  • 真实 SearchConnector 和 Tool Gateway。
  • 面向非工程团队成员的 Web 状态界面。
  • 跨多个项目 repo 的组织级汇总视图。
  • 新团队 scaffold 已能生成最小 docs、vault、domain topology、project status、experiment registry、LoopRun 和 Semantic Review seed；后续还要接入真实 repo 创建流程。

产品化方向

下一步不应只继续堆文档，而要把 repo 空间产品化：

  1. 继续完善 project_status 数据结构，把 owner、阻塞项、质量信号和更新时间拆成可查询字段。
  2. 定义 experiment_report 数据结构。
  3. 定义 knowledge_card 提升流程。
  4. 让 dashboard generator 聚合 project status、实验报告、ADR 和知识卡片。
  5. 通过企业微信或 Web 展示同一份状态数据。
  6. 支持项目空间模板，一键创建新团队的 repo / vault / docs / CI，并自动替换 scaffold seed。

相关页面