【历史参考】 本文保留 FinBayes 早期工程化讨论和旧实现上下文，便于追溯。当前战略、产品定义和工程化落地以
engineering/子目录为准。
FinBayes 产品定义文档
0. 文档目的
本文定义 FinBayes 的产品目标、用户范围、核心概念、任务体系、第一阶段市场、交互方式、结构化输出契约和边界。本文不是旧 FinClaw 文档的修订稿，也不以既有工程实现作为约束；它从 FinBayes 的目标场景重新描述一个金融认知层 AI Native 应用应该是什么。
0.1 上游继承与边界
本文继承下列上位事实源：
- 生态对象边界、阶段、接口、风险口径：当前有效生态基线 与 生态对象注册表。注册表已对齐 FinBayes 为认知层对象（2026-05-24 完成迁移）。
- 认知层产品的成熟设计经验：旧 FinClaw 产品体验蓝图与战略白皮书作为参考底盘——可继承的是「用户问题 / 黄金路径 / 行动语义降级 / 证据-未知-反方分层 / 执行边界」这类产品判断；不继承的是其旧 PRD / 工程实现 / execution 资产 / 第三方评测作为本轮 FinBayes 的约束。
- 行动判断的非执行边界统一对齐 当前有效生态基线 §10「金融风险边界」。
本文在以上之上重新定义 FinBayes 的核心对象（金融认知任务 / Session / Watchlist / 动态认知画像 / 结构化认知结果），并明确五个核心对象与多入口契约的关系。
本文服务四类读者：
- 产品与设计成员：理解 FinBayes 的产品边界、交互主线和核心对象。
- Runtime / Agent 工程成员：理解任务识别、Agents / Skills 编排和输出契约。
- Web UI 团队：理解本次迭代需要被支撑的集成契约，而不是重新定义前端实现任务。
- 后续评审者：判断 FinBayes 是否仍停留在金融 Chatbot，还是已经形成可持续金融认知应用。
1. 一句话定位
FinBayes 是金融信息链路「感知 - 认知 - 执行」中的认知层 AI Native 应用。它帮助用户理解金融信息、组织金融判断、识别风险和形成有条件行动判断，但不替用户进入交易执行、账户操作、下单、调仓或自动策略执行。
2. 产品要做成什么
FinBayes 第一阶段要做成的不是“一个更懂金融的 Chatbot”，也不是“一个接了更多数据源的单一金融 Agent”。它要做成一个可被 Web、TUI / CLI、MCP 和 Channel 共用的金融认知任务系统：
用户最终应该感受到：
| 用户体验目标 | 产品要做成的能力 |
|---|---|
| 用户不用懂内部任务分类，也能自然提问 | 将自然语言、多模态资料或任务模板解析为明确的金融认知任务 |
| 用户能得到金融角度的理解，而不是普通聊天回复 | 输出包含结论、依据、视角、风险、反方、信息缺口和下一步观察的结构化认知结果 |
| 用户能围绕同一问题持续追问、验证和复盘 | 用 Session 组织连续上下文，用历史任务结果支持后续追问 |
| 用户能把长期关注对象沉淀下来 | 用 Watchlist 承载标的、主题、事件、板块和叙事，并支持后续认知刷新 |
| 系统能越来越理解用户 | 从交互中动态更新用户关注市场、风险阈值、认知深度和偏好，而不是依赖静态问卷 |
| 不同市场有不同金融语义 | 至少让 Crypto 和 US Stocks 具备各自的市场包、任务支持、风险表达和输出补充 |
| 不同入口输出质量一致 | Web、TUI / CLI、MCP 和 Channel 共享同一任务契约与结构化结果契约 |
因此，FinBayes 的第一阶段完成态应包含四个可验证对象：
- 金融认知任务层：能把用户输入稳定映射为用户侧意图大类和内部执行任务类型。
- 金融认知运行层：能按市场包、Agents、Skills 和工作流执行任务。
- 结构化结果层：能输出可被 UI 渲染、CLI 展示、MCP 返回、Channel 分发和 Memory 记录的结果对象。
- 连续认知层：能通过 Session、Watchlist 和动态画像承接追问、复盘、关注对象和用户偏好变化。
3. 产品问题
金融用户面对的问题不是单纯缺少信息，而是信息进入认知链路后无法被稳定处理：
- 信息来源碎片化：行情、新闻、公告、链上数据、社交叙事、财报、宏观事件分散在不同系统。
- 任务表达自然但模糊：用户常以「这个怎么看」「还能不能上车」「这条消息影响大吗」提问，系统需要理解真实意图。
- 市场语义差异大：加密货币和美股在事件类型、数据结构、风险来源和分析范式上差异明显。
- 认知过程难以沉淀：一次性回答无法承接后续追问、复盘、观点变化和长期关注对象。
- 个性化难以动态生成：用户的金融偏好、风险阈值、关注市场、认知深度会随着市场、周期、标的和任务变化。
- 行动问题容易越界：用户常问「该不该买/卖/持有」，产品必须能给出有条件认知判断，同时不进入执行环节。
FinBayes 的核心价值是把这些自然、模糊、跨市场、动态变化的问题，转化为可执行、可解释、可复用、可分发的金融认知任务。
4. 产品目标
FinBayes 第一阶段的目标是建立一个可用的金融认知 runtime 和产品体验底座：
- 能通过轻 Chat 理解用户自然语言输入，并在必要时结合任务模板补充关键条件。
- 能将用户输入映射为一个或一组金融认知任务。
- 能通过多 Agents 和金融原子 Skills 完成任务执行。
- 能输出统一结构化认知结果，而不是普通聊天文本。
- 能支持连续会话、多会话、TUI / CLI、本地运行、MCP 调用和 Channel 分发。
- 能在使用过程中静默更新用户动态认知偏好画像。
- 能支持 Web UI 集成，但不把 Web UI 实施纳入本次落地范围。
- 能在加密货币市场和证券市场（美股）两个市场中证明认知质量。
5. 产品非目标
FinBayes 第一阶段明确不做以下事情：
- 不做真实交易执行。
- 不下单、不调仓、不触发订单、不连接自动交易策略。
- 不做账户托管、资金划转、交易所密钥管理。
- 不把行动判断包装成无条件买卖建议。
- 不把 Web UI 实施纳入本次文档包和改造范围。
- 不用静态问卷替代动态用户画像。
- 不把多市场能力简化为「接更多数据源」。
- 不让用户面对复杂内部任务类型列表。
6. 目标用户
FinBayes 的首要设计锚点是主动型个人投资者 / 研究者：他们有明确关注对象，愿意用 AI 辅助理解市场，但尚未形成稳定的金融认知体系。
同时，FinBayes 不排斥以下用户：
| 用户群体 | 典型需求 | 产品响应 |
|---|---|---|
| 金融小白 | 看懂事件、概念、资产和风险 | 用更通俗的解释层、示例和关键概念拆解降低门槛 |
| 主动型个人投资者 / 研究者 | 分析标的、对比机会、识别风险、复盘观点 | 提供结构化分析、任务模板、关注对象和连续追问 |
| 专业金融从业者 | 快速组织证据、形成多视角判断、复核假设 | 提供更高密度输出、来源、反方、约束和可复用结果 |
| 职业交易员 | 在行动前确认条件、风险和反方证据 | 提供有条件行动判断和观察清单，不进入执行 |
| 外部 Agent / 工具 | 调用金融认知能力作为工作流一环 | 通过 CLI / MCP / API 返回结构化结果 |
产品不按身份硬切，而按认知深度、任务复杂度、市场类型、用户偏好和输出用途动态适配。
7. 核心体验原则
7.1 Chat 是入口，不是全部
FinBayes 以轻 Chat 作为主入口，但 Chat 不等于唯一交互方式。用户可以直接用自然语言提问，也可以附加图片、文档、链接、截图、音视频等多模态资料；当系统判断需要关键补充信息时，可以在当前交互流中触发任务模板。
7.2 任务模板不应打断轻 Chat
任务模板不是传统表单跳转，而是嵌入当前会话的轻量补充机制。它用于帮助用户快速提供市场、标的、周期、关注点、风险偏好、已有观点等关键信息，避免用户用大段自然语言描述仍无法获得准确结果。
7.3 默认理解，必要时追问
FinBayes 默认应尽量理解用户真实意图并继续执行。只有在意图不清、关键条件缺失、直接回答可能误导、或多个高风险解释路径并存时，系统才发起反向追问。追问应一次只问最关键问题，并给出默认假设。
7.4 UI 不决定能力质量
Web、TUI / CLI、MCP 和 Channel 只是交互和展示方式不同，不应导致意图识别、任务执行、认知内容和输出质量不同。所有入口共享同一套任务识别、Agents / Skills 编排和结构化输出契约。
8. 核心概念模型
8.1 输入
输入是用户表达需求的入口，包括：
- 自然语言；
- 图片、文档、音视频、截图、链接等多模态资料；
- 用户主动选择的任务模板；
- 系统建议补充的任务模板；
- 外部 Agent 通过 CLI / MCP 提交的结构化请求。
8.2 Session
Session 是连续交互和上下文组织机制。它承载用户的一次或多轮会话、任务识别记录、任务执行结果、追问、修正、反馈和历史上下文。
Session 不是核心产品对象，也不应成为用户必须理解的概念。对用户而言，它更像一个可以继续回来的工作现场。
8.3 金融认知任务
金融认知任务是 FinBayes 的核心工作单元。用户输入被解析后，会映射为一个或一组金融认知任务，并由 Orchestrator 调度 Agents、Skills 和工作流执行。
一次输入可能产生：
- 单一任务；
- 多个并行任务；
- 顺序依赖任务；
- 需要用户补充信息后才能执行的待确认任务；
- 不支持或越界任务的降级响应。
8.4 Watchlist
Watchlist 是持续关注对象集合，不是金融认知任务的替代品。它可以包含：
- 标的：BTC、ETH、NVDA、TSLA 等；
- 主题：AI 芯片、稳定币监管、ETF 资金流等；
- 事件：财报、解锁、监管听证、链上攻击等；
- 板块：Layer 2、半导体、银行、能源等；
- 叙事：AI Agent、RWA、降息交易、风险偏好回升等。
对象可以由用户主动加入，也可以由系统从高频关注、反复追问和动态画像中识别后建议加入。
8.5 动态认知画像
FinBayes 不用静态问卷构建用户画像。用户画像是系统在持续交互中静默形成和更新的动态认知偏好模型。
画像信号包括：
- 关注市场；
- 关注标的、主题、事件、板块；
- 常见任务类型；
- 输出深度偏好；
- 风险阈值；
- 周期偏好；
- 对机会、风险、解释、对比、行动判断的关注程度；
- 用户历史观点及其变化。
画像不是单一标签，而是随市场、周期、任务和用户当前状态变化的组合。
8.6 结构化认知结果
结构化认知结果是任务执行后的统一输出对象。它可以被 Web 渲染、TUI 展示、MCP 返回、Channel 分发和 Memory 记录。
它不是普通聊天文本，也不是单一报告模板。它应保留任务类型、输入上下文、结论、证据、风险、反方、信息缺口和可继续追问项。
9. 任务体系
FinBayes 采用「用户侧简单表达 + 内部细粒度执行类型」的任务体系。
9.1 用户侧意图大类
第一阶段定义六类用户可理解的意图大类：
| 意图大类 | 用户问题示例 | 产品响应 |
|---|---|---|
| 解释类 | 这条消息是什么意思？这个指标怎么看？ | 拆解概念、事件和影响链路 |
| 分析类 | 帮我分析 BTC / NVDA 现在的状态 | 调用市场包和相关 Skills 形成结构化分析 |
| 对比类 | BTC 和 ETH 谁更强？NVDA 和 AMD 有什么差异？ | 从多个维度比较对象和场景 |
| 验证 / 复盘类 | 我之前的判断还成立吗？上次为什么看错？ | 对历史观点、事实变化和假设失效进行复核 |
| 风险识别类 | 这里最大的风险是什么？有哪些反方证据？ | 识别风险、盲点、信息缺口和推翻条件 |
| 行动判断类 | 现在还能追吗？该不该继续关注？ | 给出有条件行动判断、前提、风险和下一步观察，不进入执行 |
9.2 内部执行任务类型
内部执行任务类型用于真实调度，不直接暴露给用户。示例包括：
- 新闻 / 事件影响分析；
- 单标的基本面分析；
- 技术面状态分析；
- 链上数据解读；
- 宏观数据解读；
- 财报 / 公告解读；
- 多资产横向比较；
- 观点反证检查；
- 历史判断复盘；
- 风险清单生成；
- 条件化行动判断；
- 结构化报告生成。
用户侧意图大类用于产品理解和交互表达；内部执行任务类型用于工程调度、测试和评估。一个用户问题可以映射到一个或多个内部执行任务类型。例如，“NVDA 财报后现在怎么看？”可能同时触发财报 / 公告解读、单标的基本面分析、技术面状态分析和风险清单生成。
9.3 任务路由策略
FinBayes 不应要求用户换一种提问方式来适配系统。系统应优先自动理解、拆解和归类：
- 能直接识别时，直接执行；
- 需要多个任务时，拆成任务批次；
- 不完全落在现有类型时，归入最接近上位类型并记录新任务模式；
- 缺少关键条件时，触发澄清或任务模板；
- 越过执行边界时，降级为认知层行动判断或拒绝执行动作。
任何验收场景都只是覆盖性样例，不允许把实现写成针对样例字符串的硬编码逻辑。验收必须证明系统实现的是上述两层任务体系，而不是只支持几个示例问题。
10. Agents 与 Skills
10.1 Agents
Agents 负责认知角色、市场专长、任务判断和协作编排。第一阶段建议的 Agent 角色包括：
| Agent | 职责 |
|---|---|
| Intent Router Agent | 识别用户意图，生成金融认知任务或澄清请求 |
| Task Orchestrator Agent | 编排任务依赖、Agent 调度和输出聚合 |
| Crypto Market Agent | 处理加密市场相关认知任务 |
| US Stocks Market Agent | 处理美股市场相关认知任务 |
| Risk Agent | 识别风险、未知和信息缺口 |
| Challenge Agent | 提供反方证据和推翻条件 |
| Profile Agent | 从交互中更新动态认知画像 |
| Output Agent | 将结果组织为结构化认知输出 |
10.2 Skills
Skills 是可复用、可组合、可测试的金融原子能力。第一阶段建议包含：
- 行情读取；
- 新闻 / 事件抽取；
- 链上指标解释；
- 交易所市场数据解释；
- 财报摘要；
- 公告解读；
- 技术指标计算；
- 宏观事件解析；
- 估值指标解释；
- 风险清单生成；
- 来源引用整理；
- 结构化摘要生成；
- Channel 分发格式化。
Agents 不应直接包含所有金融能力。它们应调用 Skills，并通过 Orchestrator 组合结果。
11. 第一阶段市场范围
FinBayes 产品定义上必须支持多市场，但第一阶段从两个市场做深：
| 市场包 | 范围 | 选择理由 |
|---|---|---|
| Crypto Market Pack | 加密货币、链上、交易所、项目叙事、代币机制、资金流、社区和安全事件 | 体现 AI Native 金融认知差异化，验证高噪音市场下的任务编排 |
| US Stocks Market Pack | 美股上市公司、财报、公告、行业、估值、市场情绪、分析师 / 机构 / insider 信息 | 验证传统证券市场的结构化研究和长期关注场景 |
不把「多市场」理解为只接更多数据源。每个市场包都应有自己的术语、任务类型、数据约束、风险表达和输出结构补充。
12. 主体验蓝图
第一阶段主体验是：
Web UI 是主要可视化场景，但本次文档包不定义 Web UI 具体实施。TUI / CLI 必须保留完整体验，即使没有 Web UI，用户也应能完成完整提问、任务执行、结果阅读、追问、Watchlist 操作和分发。
13. 任务模板机制
任务模板有三种触发方式：
- 系统自动触发：用户问题过宽、缺少关键条件或任务类型需要结构化输入。
- 用户主动选择：用户从轻 Chat 附近选择常用模板。
- Agent 建议触发：系统先给出初步理解，再建议使用模板补充条件。
任务模板第一阶段服务高频金融认知任务，不建设庞大模板库。模板字段应围绕任务质量，而不是模拟传统表单。
示例字段：
- 市场；
- 标的 / 主题 / 事件；
- 周期；
- 用户当前观点；
- 用户关注点；
- 风险承受语境；
- 输出深度；
- 是否需要加入 Watchlist；
- 是否需要 Channel 分发。
14. 结构化输出契约
所有入口应共享同一个结构化输出骨架：
| 模块 | 说明 |
|---|---|
| 直接结论 | 先回答用户最关心的问题 |
| 关键依据 | 事实、数据、事件、来源或模型判断依据 |
| 多视角解读 | 市场、周期、资金、基本面、技术面、链上、宏观等视角 |
| 风险与反方 | 哪些地方可能错，哪些条件会推翻判断 |
| 行动判断 / 下一步 | 有条件建议、观察条件、验证动作，不进入执行 |
| 信息缺口 | 当前缺少哪些资料、数据或验证 |
| 可继续追问项 | 建议用户继续问什么，或系统可继续展开什么 |
不同任务类型可以增减模块，但不能退化为只给一段文本。
15. 行动判断边界
FinBayes 可以处理用户的行动倾向问题，但输出必须保持在认知层。
允许输出：
- 倾向判断；
- 条件化建议；
- 场景分歧；
- 观察动作；
- 验证动作；
- 风险和反方证据；
- 不确定性说明。
不允许输出：
- 无条件买卖指令；
- 自动下单；
- 调仓执行；
- 账户操作；
- 资金划转；
- 自动交易触发。
早期不应把附加条件做得过窄过多，但必须保持「不进入执行」这一底线。本节所约束的范围与 当前有效生态基线 §10 金融风险边界 完全一致；任何对此边界的扩展或例外都必须先走 变更协议 的 L1 流程。
16. Web、TUI、CLI、MCP 与 Channel
| 入口 | 定位 | 第一阶段要求 |
|---|---|---|
| Web | 主要可视化交互场景 | 本次不实施 UI，但 runtime 必须支撑集成 |
| TUI / CLI | 完整本地交互场景 | 保留完整体验，不作为降级入口 |
| MCP | 外部 Agent 调用入口 | 支持结构化请求和结构化结果 |
| Channel | 结果分发和轻量触达 | 支持结构化结果摘要、链接和后续追问入口 |
Web 和 TUI / CLI 的差异只在交互体验和展示形态，不应影响输出质量。
17. Proactive / Heartbeat
FinBayes 第一阶段以用户主动提问为主。Proactive alerts / heartbeat 可以保留和改造，但作为辅助能力。
合适的辅助方向：
- 提醒某个 Watchlist 对象可能需要更新；
- 提示某个关注条件被触发；
- 为用户生成待复盘任务；
- 将高相关事件加入候选关注列表；
- 给 Channel 发送低噪音结构化摘要。
不合适的方向：
- 频繁主动推送交易信号；
- 自动触发执行动作；
- 以价格波动替代认知判断；
- 对用户画像做不可解释的强假设。
18. 成功标准
第一阶段成功不以功能数量衡量，而以认知质量和可集成性衡量：
- 用户可以用自然语言提出加密或美股问题，并得到结构化认知结果。
- 系统能在关键条件缺失时触发合理任务模板或澄清，而不是泛化追问。
- 同一个任务通过 Web API、TUI / CLI、MCP 得到同质量核心结果。
- Watchlist 能承载标的、主题、事件、板块和叙事。
- 用户画像能从交互中产生可解释的动态偏好信号。
- 行动判断始终停留在认知层，不进入执行。
- Web UI 团队可以基于任务状态、事件流和结构化结果完成集成。
19. 关键开放问题
后续仍需进一步明确：
- 第一阶段 Crypto 与美股市场包的具体数据源和可用性。
- 哪些任务模板必须首发，哪些应由真实使用数据驱动新增。
- 用户画像信号的可见性：用户是否能查看、编辑或关闭某些画像推断。
- Watchlist 的默认层级：对象、主题、事件、板块是否需要不同视图。
- Channel 分发的频率、触发条件和用户控制方式。
- 结构化结果如何支持引用、版本、复盘和结果对比。