跳到主要内容

项目上下文模板

状态: Active / 保留 最后更新: 2026-05-07 Owner: Curvature Labs 用途: 定义 FinTec AI Ecosystem 五个项目级 context 的最小治理模板，支持多人、多项目、多 Agent 高效协作

0. 当前处理口径​

本文应保留为项目级文档的最小协作协议。

它不是某个项目的事实源，也不是产品定义文档；它定义的是项目级事实源应覆盖哪些字段、如何继承生态上下文、以及何时向治理层触发 sync / escalation。

当前项目级文档包的默认结构为：

  • project-anchor.md：项目定位、生态角色、第一阶段目标、边界和上游 / 下游关系；
  • inherited-context.md：从生态基线、项目注册表和上游治理判断继承的上下文；
  • current-state.md：当前事实、已知材料、缺口、风险、开放问题和下一步；
  • CONTEXT.md：项目级领域语言、已接受术语、产品 / 系统级 context 对齐和已解决歧义；可按成熟度逐步补齐；
  • 后续正式产品定义、MVP 定义、PRD、issue 和 context-scoped ADR。

projects/finclaw/ 是当前最完整的已落地样板。后续重写 Data Horizon / 数据视界、AI Trading Matrix、Reinforcement Learning Engine 和 Financial Expert Foundation Model 时，应以本文为最低字段协议，并参考 FinClaw 已形成的文档包结构。

1. 使用目的​

本模板用于让 Data Horizon / 数据视界、FinClaw、AI Trading Matrix、Reinforcement Learning Engine、Financial Expert Foundation Model 的项目级文档保持最小一致性。

统一模板不是为了形式一致，而是为了：

  • 降低团队成员和个人域 Agent 的恢复成本；
  • 让项目状态、边界、风险和待决问题可继承；
  • 让项目实践能向生态治理层结构化回流；
  • 支持后续 to-prd、to-issues、triage 等技能从同一类输入中工作。

五个 context 可以处在不同成熟度，不要求内容深度相同。

2. 最小字段​

每个项目级 context 至少应覆盖以下字段。

2.1 定位​

  • 项目 / 系统名称；
  • 在 3 + 2 结构中的类型；
  • 在生态中的角色；
  • 一句话定义。

2.2 当前阶段​

  • 当前推进状态；
  • 当前最重要的问题；
  • 当前已知进展；
  • 当前不应误解的地方。

2.3 独立闭环​

三个前台产品 / 系统必须补齐第一阶段独立闭环：

  • 目标用户或消费对象；
  • 核心输入；
  • 核心处理链路；
  • 可交付输出；
  • 价值验证方式；
  • 非目标与风险边界。

两个基础设施 / 能力底座必须补齐：

  • 启动触发条件；
  • 依赖的前台数据或反馈对象；
  • 第一阶段可推进到什么程度；
  • 不应提前承诺的范围。

2.3.1 产品 / 系统级 Context 对齐​

在进入 PRD、MVP 拆解或 issue 拆解前，每个对象还应补齐产品 / 系统级 context。

该层位于生态级 context 与具体产品定义 / MVP 定义 / PRD / issue 之间，用于回答“这个独立产品 / 系统目前被团队如何理解、已经沉淀了什么、下一步应以什么形态进入产品化讨论”。

该层可承载在项目 CONTEXT.md 中；若项目尚未建立 CONTEXT.md，应先在 current-state.md 中以显式段落临时承载，后续再提升到项目级 context。

对于三个前台独立产品 / 系统，至少应覆盖：

  • 团队当前认知；
  • 已有材料与产出物清单；
  • 材料状态：已接受 / 候选 / 待验证 / 过时；
  • MVP 版本应具备的产品形态；
  • 长期完成态或目标形态；
  • 模块 / 能力结构，限于产品与领域层，不要求进入代码模块设计；
  • 核心交互方式；
  • 参考项目、竞品、反例或启发来源；
  • 最小价值验证方式；
  • 当前最重要的待决问题。

对于两个基础设施 / 能力底座，至少应覆盖：

  • 当前被哪些前台产品 / 系统触发；
  • 已有能力材料、实验或产出物；
  • 第一阶段可成立的能力形态；
  • 长期能力沉淀目标；
  • 消费对象和反馈来源；
  • 评估方法；
  • 参考系统、竞品、论文、框架或反例；
  • 不应提前产品化或过度承诺的范围。

该层不是完整 PRD，也不是实现规格。它的目的不是把产品一次性定义完，而是让多人、多项目、多 Agent 在进入细节前共享同一个产品 / 系统语境。

2.4 输入 / 输出​

  • 当前可接受输入；
  • 当前产生输出；
  • 输出的消费对象；
  • 输出是否进入其他 context 或生态治理层。

2.5 边界 / 非目标​

  • 本项目拥有的职责；
  • 本项目不拥有的职责；
  • 与相邻 context 的边界；
  • 当前最需要防止的角色坍缩。

2.6 关键接口​

  • 相邻接口；
  • 上游 / 下游关系；
  • 当前接口状态；
  • 待定义的契约。

2.7 当前风险​

  • 产品风险；
  • 技术风险；
  • 协作风险；
  • 合规 / 金融风险；
  • 生态边界风险。

2.8 待决问题​

  • 当前必须继续 grill / clarify 的问题；
  • 可以由项目 owner 决定的问题；
  • 必须回流生态层的问题。

2.8.1 Sync / Escalation 触发条件​

只有当项目实践影响生态级事实时，才必须触发 sync / escalation。

最小触发条件包括：

  • 项目实践挑战 3 + 2 结构或五层能力链条解释；
  • 项目实践改变相邻 context 边界，例如 FinClaw 开始承担真实交易执行或 AI Trading Matrix 的执行系统职责；
  • 项目实践产生新的跨 context 接口需求；
  • 项目实践暴露金融风险、合规风险或用户误导风险；
  • 项目实践产生可被多个 context 复用的能力、数据、评估方法或学习资产；
  • 项目实践证明现有 governance fact 不够用、错误或阻碍推进。

以下不需要默认 sync / escalation：

  • UI 文案调整；
  • 局部 backlog 排序；
  • 单项目内技术实现选择；
  • 不影响生态边界的商业化实验；
  • 一次性探索草稿。

2.9 Owner / Review Responsibility​

  • Primary owner；
  • Contributors；
  • Review / acceptance responsibility；
  • 需要同步的个人域 Agent 或团队角色。

在启动期：

  • 生态级 governance fact 的接受权先归 Curvature Labs / Founder 代表的 ecosystem owner；
  • project owner 可以提出、挑战或补充生态事实，但不能单方面升级为生态事实；
  • 涉及具体产品 / 系统的事实，接受前应尽量让相关 project owner review；
  • 跨项目边界、风险、接口和启动节奏的最终记录应落回本仓库的 baseline/、registry/、contexts/、projects/* 或 governance/ 中的正式入口。

2.10 相关文档​

  • current state；
  • inherited context；
  • project anchor；
  • project-level CONTEXT.md；
  • 产品定义、MVP 定义、PRD 和 issue；
  • context-scoped ADRs；
  • 相关生态级正式事实源、对象注册、同步记录、升级记录或项目工程化承接位置。

3. 使用规则​

  • 模板是最小协作协议，不是内容上限；
  • 缺失字段应显式标记为“待补充”，不要用空泛文字填充；
  • 项目级实践如果冲击生态边界，应回流本仓库的正式治理入口；
  • 局部实现细节不需要默认升级为生态 decision；
  • 后续新增字段必须服务协作效率、可恢复性、评审或风险控制；
  • 已落地和后续落地的正式治理、context、决策、索引、项目状态、PRD、issue 与参考说明文档默认使用中文。必要英文专名、产品名、技能名、文件路径、代码标识和行业术语可以保留英文。

4. 当前保留判断​

截至 2026-05-07，本文应保留为 Active 模板。

保留原因：

  • INDEX.md 中除 FinClaw 外的其他项目目录仍以项目锚点、继承上下文和当前状态三件套承载；
  • registry/project-registry.md 已把各项目入口拆分为 project-anchor.md、inherited-context.md、current-state.md 和可选 CONTEXT.md；
  • projects/finclaw/ 已证明该模板可以落成更完整的项目级文档包；
  • 后续 PRD、issue、triage 和多 Agent 协作仍需要统一的最小输入形态。

后续使用方式：

  • 重写其他项目目录时，先按本文检查最小字段；
  • 对成熟度更高的项目，再补齐项目级 CONTEXT.md；
  • 若某项目实践改变生态级事实，应按本文 sync / escalation 规则回流；
  • 本文不应继续扩写成项目管理方法论，也不应替代具体项目文档。