第一阶段产品闭环验收矩阵

状态: P1 rewrite / 生态层验收事实源 最后更新: 2026-05-14 Owner: Labs-FinTecAI Admin 适用范围: Data Horizon / 数据视界、FinClaw、AI Trading Matrix、Reinforcement Learning Engine、Financial Expert Foundation Model

1. 本文回答什么

本文回答一个问题：

第一阶段怎样才算真实产品闭环，而不是只完成文档对齐、战略叙述或项目命名？

本文不是完整产品路线图，也不替代各项目 Controller 的项目正文。它只定义生态层共同验收口径，让后续项目层文档能用同一套字段判断：

• 谁是第一阶段用户或消费对象；
• 输入从哪里来；
• 输出交付给谁；
• 用什么指标判断有效；
• 多长时间内验证；
• 什么情况应停止、降级或改方向；
• 需要留下什么证据，才能把“已对齐”升级为“闭环成立”。

2. 使用规则

项目 Controller 在写项目定义、MVP、PRD、task packet 或验收报告时，应从本文继承矩阵字段。

Admin 使用本文检查项目层文档是否可承接，但不直接替项目 Controller 作产品判断。

本文区分三种状态：

状态	含义	不能外推为
doc-aligned	文档边界、对象和责任已说清楚。	产品已被用户验证。
prototype-validated	有可运行或可演示原型，并通过小样本任务验证。	商业化、规模化或全生态集成完成。
closure-accepted	有用户 / 消费对象、输入、输出、指标、时间盒、kill criteria 和证据。	后续阶段不需要继续验证。

任何项目只要缺少证据，都只能保持 doc-aligned 或 prototype-validated，不得写成 closure-accepted。

3. 共同闭环字段

每个第一阶段对象至少必须回答以下字段。

字段	必填问题	验收证据
用户 / 消费对象	谁首先使用或消费输出？他们原本如何完成同类任务？	用户假设、任务描述、替代方案说明。
核心输入	第一阶段从哪些真实输入开始，不依赖哪些尚未完成的生态对象？	输入样本、数据来源、权限和边界说明。
核心处理链路	系统怎样把输入转成输出？哪些步骤是人工、半自动或自动？	流程图、状态机、任务日志或 demo 记录。
可交付输出	用户拿到什么？输出格式、粒度和复查方式是什么？	样例输出、schema、报告、界面或 API 响应。
成功指标	什么结果说明输出有价值？	量化指标、人工评分、任务通过率、用户反馈或下游复用率。
时间盒	多久内验证第一阶段是否成立？	trial 计划、batch 计划、验收日期或 checkpoint。
kill criteria	哪些失败信号要求停止、降级或改方向？	明确失败阈值、风险项、回滚或暂停规则。
非目标	第一阶段不做什么，避免把长期愿景压进 MVP。	non-goal 清单和 scope guard。
证据位置	证据写在哪里，谁负责更新？	packet、checkpoint、evaluation report、project status。

4. 三个前台对象闭环矩阵

4.1 Data Horizon / 数据视界

第一阶段判断：先证明独立金融信息感知链路成立，不等待 FinClaw 或 AI Trading Matrix 完成。

字段	第一阶段口径
首位消费对象	人类研究者、内容 / 数据服务场景，或一个明确的生态内下游对象；必须选定首位，不可同时声称服务所有对象。
替代方案	手工浏览新闻、社媒、研报、链上 / 市场数据站点、碎片化 RSS 或人工剪报。
核心输入	合法授权的信息源、市场数据、新闻事件、实体、主题、时间线和元数据。
核心处理链路	采集 -> 去重 -> 标准化 -> 实体 / 主题关联 -> 时间化 -> 输出。
可交付输出	可消费的信息包、事件时间线、主题动态、实体卡片、数据快照或 API / feed。
成功指标	覆盖率、去重准确率、延迟、来源可追溯率、人工复查通过率、下游消费率。
时间盒	一个受控信息域、市场或主题的短周期 trial，而不是全市场铺开。
kill criteria	来源授权不清、输出无法追溯、噪声高于人工可用阈值、消费对象不能复用输出。
非目标	不做金融结论，不替 FinClaw 作认知判断，不直接生成交易行动。
证据位置	projects/data-horizon/ 项目状态、reference evaluation、trial packet、checkpoint。

最低验收问题：

1. 没有 FinClaw 时，Data Horizon 的输出是否仍然有人愿意消费？
2. 输出是否能复查来源、时间和处理链路？
3. 下游对象接入时，是否能拿到稳定字段，而不是重新读散文报告？

4.2 FinClaw

第一阶段判断：先证明独立金融认知产品闭环成立，不把真实交易执行作为产品完成条件。

字段	第一阶段口径
首位用户	有金融市场兴趣、需要 AI 辅助研究和理解市场、但缺少稳定研究框架的个人用户或小型研究用户。
替代方案	手工搜索、群聊碎片信息、通用 ChatGPT、KOL 观点、单一行情工具或主观笔记。
核心输入	用户问题、资产 / 主题、可引用资料、市场上下文、历史讨论和必要约束。
核心处理链路	任务理解 -> 信息整理 -> 证据绑定 -> thesis / risk / counterpoint -> 执行前认知检查。
可交付输出	结构化市场认知快照、风险与反证、条件化策略假设、跟踪问题、执行前检查点。
成功指标	用户任务完成率、输出可复查率、结构化字段完整率、人工评分、重复使用意愿。
时间盒	一个明确市场场景和若干真实用户任务的 MVP trial。
kill criteria	输出不能解释证据、频繁给出确定性收益承诺、用户无法复用、直接越界触发交易执行。
非目标	不做真实交易执行，不承诺收益，不替代 Data Horizon 做完整信息感知底座。
证据位置	projects/finclaw/ 产品定义、MVP 定义、evaluation reports、trial closeout。

最低验收问题：

1. 用户是否能用输出完成一项原本分散、低质量或高摩擦的研究任务？
2. 输出是否可复查、可反驳、可继续跟踪？
3. 没有 AI Trading Matrix 时，FinClaw 是否仍然是独立认知产品？

4.3 AI Trading Matrix

第一阶段判断：先证明受治理的交易执行支持闭环成立，真实执行必须有授权、审计、风控和回滚边界。

字段	第一阶段口径
首位用户 / 消费对象	需要策略组织、回测、仿真、执行支持或授权执行工作流的交易研究者、策略操作者或受控系统。
替代方案	手工策略记录、独立回测脚本、交易所界面、量化框架、人工执行清单。
核心输入	策略假设、市场数据、信号、约束、账户 / 权限边界、风控规则。
核心处理链路	假设登记 -> 回测 / 仿真 -> 风险检查 -> 授权检查 -> 执行支持记录 -> 反馈归档。
可交付输出	策略候选、回测结果、仿真记录、执行检查清单、授权记录、风险提示、反馈数据。
成功指标	策略复现率、风控触发准确性、审计完整率、授权链路通过率、执行支持错误率。
时间盒	一个受控市场、受控账户或纯仿真环境的执行支持 trial。
kill criteria	授权边界不清、审计缺失、绕过风控、错误行动不可回滚、输出被误当成无约束自动交易。
非目标	不补造未经上游支持的认知结论，不做无授权真实交易，不以收益曲线替代治理验收。
证据位置	projects/trading-matrix/ 项目状态、仿真 / 回测报告、execution support checkpoint。

最低验收问题：

1. 系统是否能把策略假设转成可审计执行支持对象？
2. 风控和授权是否在流程里，而不是写在外部声明中？
3. 失败案例是否能回流为结构化反馈，而不是只留下收益结果？

5. 两个基础设施对象触发矩阵

Reinforcement Learning Engine 和 Financial Expert Foundation Model 第一阶段不以完整产品闭环验收，而以触发条件清晰为验收。

5.1 Reinforcement Learning Engine

字段	第一阶段口径
当前状态	Dormant / readiness gated。
启动前置	前台对象产生真实结果、误差、案例、用户反馈、执行或认知链路数据。
首位消费对象	前台产品 Controller、评估系统或后续模型能力沉淀流程。
核心输入	feedback signal、error taxonomy、case、action / cognition trace、用户行为和人工标注。
可交付输出	学习样本、错误归因、策略 / workflow 改进建议、模型训练或评估输入。
成功指标	反馈可分类率、错误归因可复查率、改进建议被采纳率、对前台指标的可解释提升。
kill criteria	缺少真实反馈、只用合成评价自证、强化高风险行为、无法追溯学习来源。
证据位置	projects/reinforcement-learning-engine/ readiness checkpoint、evaluation reports。

5.2 Financial Expert Foundation Model

字段	第一阶段口径
当前状态	Dormant / readiness gated。
启动前置	有足够高质量任务、领域样本、评估用例、反馈资产和明确模型能力缺口。
首位消费对象	Data Horizon、FinClaw、AI Trading Matrix 或共享金融任务能力层。
核心输入	金融语义样本、结构化任务、长上下文案例、评测集、反馈 / 学习资产。
可交付输出	领域语义、推理、结构化输出、任务适配能力或模型能力评估报告。
成功指标	指定任务集提升、结构化输出一致性、引用 / 证据保真、跨项目复用率。
kill criteria	用模型规模替代任务验证、缺少评测集、缺少真实产品输入、能力提升不可复查。
证据位置	projects/financial-expert-foundation-model/ readiness checkpoint、model evaluation packet。

6. 阶段推进判定

6.1 可进入项目层 MVP / trial

当某个前台对象同时满足以下条件，可以进入项目层 MVP / trial：

1. 首位用户或消费对象明确；
2. 输入样本和输出样例存在；
3. 成功指标和 kill criteria 已写入项目文档；
4. 时间盒和 evidence path 明确；
5. 非目标能阻止 scope creep；
6. trial 不依赖其他尚未闭环对象先完成。

6.2 可进入生态协同接口设计

相邻对象满足以下条件后，才进入正式接口设计：

1. 双方各自最小闭环已经可描述；
2. 上游输出有稳定字段、样例和边界；
3. 下游消费场景具体；
4. 接口失败不会破坏任一方独立闭环；
5. 反馈路径和责任 owner 明确。

优先接口仍为：

接口	进入条件
Data Horizon -> FinClaw	信息对象、事件、实体、主题和时间线能被 FinClaw 稳定消费。
FinClaw -> AI Trading Matrix	认知对象、策略假设、风险约束和失效条件能进入执行支持域。
AI Trading Matrix -> Reinforcement Learning Engine	执行 / 仿真结果、错误和反馈能结构化回流。
Reinforcement Learning Engine -> Financial Expert Foundation Model	高价值反馈资产足以进入模型能力沉淀。

7. Evidence Matrix

项目层不能只用叙述证明闭环。最低 evidence 应包括：

证据类型	最低要求	可存放位置
用户 / 消费对象证据	明确任务、替代方案、使用方式或访谈 / trial 记录。	project status、trial packet、evaluation report。
输入样本	至少一个真实或准真实输入样本，含权限和来源边界。	project docs、reference report、fixtures。
输出样例	至少一个可复查输出，最好有 schema 或字段表。	project docs、evaluation report、task packet。
过程证据	demo、日志、状态机、流程图或人工操作记录。	checkpoint、closeout、engineering packet。
指标证据	通过 / 失败标准、评分表、错误分类或用户反馈。	evaluation report、acceptance matrix。
决策证据	是否继续、降级、暂停或转向。	checkpoint、controller state、closeout。

8. 常见误判

误判	正确判断
文档写清楚了，所以产品闭环成立。	这只是 doc-aligned。还需要用户、输入、输出、指标、时间盒和证据。
生态链路完整，所以第一阶段应先集成五个对象。	第一阶段先让前台对象独立闭环，基础设施保持触发条件清晰。
FinClaw 输出策略假设，所以已经进入交易执行。	策略假设仍属于认知输出，真实执行必须进入执行治理层。
AI Trading Matrix 有回测收益，所以执行闭环成立。	还要看授权、审计、风控、复现和失败反馈。
RLE / FEFM 战略价值高，所以应马上启动。	缺少真实反馈和任务资产时只能保持 readiness gated。

9. 对后续批次的要求

Batch 8C 项目层 audit 必须检查每个项目是否具备本文字段，并标记：

• has-user-or-consumer
• has-input-sample
• has-output-example
• has-metric
• has-timebox
• has-kill-criteria
• has-evidence-path
• missing-example
• missing-eval-case
• readiness-gated

Batch 8D 若讨论 Admin 是否统一重写各 Controller 项目正文，必须先确认是否改变治理边界。没有授权前，Admin 只输出 audit / packet / matrix，不替项目 Controller 批量重写项目正文。

Batch 8E 项目层内容重构执行计划，应把本文字段转成具体 rewrite packet，而不是继续追加抽象战略说明。

10. 本文边界

本文已经把原先“第一阶段产品闭环判断 / 待吸收 checklist”改写为验收矩阵。

本文不声明：

• 三个前台对象已经完成第一阶段闭环；
• 两个基础设施对象已经可以启动实施；
• 项目层文档已经完成重构；
• 团队反馈根因已经全部 resolved；
• Admin 已获得统一重写项目正文的授权。

本文只证明：生态层已经具备一份可被项目 Controller 继承的第一阶段闭环验收事实源。