FinClaw V1 PRD
状态：V1 PRD Draft / 可启动下游设计，完整 Design Packet 未完成 日期：2026-05-13 项目：FinClaw 文档级别：项目级 V1 PRD 上游文档：strategic-whitepaper.md、product-definition.md、mvp-product-definition.md、product-object-and-advisor-design.md、terminology-and-object-naming.md、v1-design-kickoff-packet.md 评测承接：evaluation/finclaw/case-schema.md、evaluation/finclaw/cases/README.md
本文档把 FinClaw 已收束的产品定义下推为 V1 产品需求。它不是新的产品定义入口，也不替代战略白皮书、产品定义或 MVP 产品定义。
V1 的目标不是内部 demo，而是尽可能一次版本达到面向 C 端个人用户正式开放试用和试运营的产品状态。
当前完成度说明：本文是 V1 PRD 草案和下游设计输入，不是完整 Design Packet。User Journey、Product Object and Schema Design、UI / UX Interaction Design、Agent Orchestration Design、Evaluation and Trial Acceptance Plan、Trial Operations Plan 仍需按任务包产出并评审后，才可进入工程落地或试运营验收。
1. V1 结论
FinClaw V1 定义为：
面向个人金融参与者的加密市场认知产品试用 / 试运营版本。用户可以用自然语言提出资产、主题、事件、叙事或行动邻近问题，FinClaw 将其沉淀为 Market Cognition Snapshot（市场认知快照）、可持续维护的 Market Cognition Thread（市场认知线程），以及必要时的 Pre-Execution Checkpoint（执行前认知检查点）；产品不输出真实执行指令、自动交易信号或收益承诺。
V1 应证明三件事：
- 个人用户能从一次模糊金融问题进入高质量结构化认知；
- 用户愿意把一次性输出保存为可刷新、可复查、可持续维护的认知线程；
- 当问题靠近交易行动时，产品能稳定表达条件、风险、失效条件和执行前认知检查点，而不是给出订单语言。
2. 目标用户
2.1 首发用户
V1 面向：
有真实金融关注对象、会持续观察市场、但缺少稳定认知体系的个人金融参与者。
典型特征：
- 关注一个或多个加密资产、项目、协议、主题、叙事或市场事件；
- 会看新闻、KOL、行情、社群信息或研究材料，但容易被信息过载影响；
- 希望形成比普通聊天回答更稳定的认知结构；
- 需要保存、复查、刷新和继续追问；
- 可能提出行动邻近问题，但不要求产品代替自己执行交易。
2.2 非首发用户
V1 不以以下用户为主：
- 只需要投资教育的新手用户；
- 机构级投研团队；
- 需要自动交易、组合管理或账户接入的用户；
- 只想获得买卖点、喊单、确定性收益或自动信号的用户；
- 需要多市场全覆盖和完整金融数据基础设施的用户。
3. 首发市场与范围
V1 首发市场为加密货币市场认知。
可进入对象：
- 加密资产或项目；
- 协议、生态、板块或叙事；
- 新闻、公告、政策、事件链或争议；
- 用户已有判断、风险担忧或策略假设；
- 需要持续观察的开放问题。
V1 不承诺全市场实时扫描、链上完整侦查、跨资产组合优化、自动交易提醒或机构级合规投研流程。
4. Jobs-to-be-Done
| Job | 用户表达 | V1 成功输出 |
|---|---|---|
| 理解当前状态 | “现在怎么看 ETH / 某个项目 / 某条新闻？” | Market Cognition Snapshot |
| 建立持续观察 | “帮我持续看这个主题 / 后面有变化再看” | Market Cognition Thread |
| 挑战主判断 | “这事有什么反方？哪里可能错？” | 风险、争议、失效条件、反方证据 |
| 刷新旧认知 | “和上次比有什么变化？” | Thread refresh summary / cognition changes |
| 行动前检查 | “我现在要不要进 / 该不该减？” | Strategy Hypothesis + Pre-Execution Checkpoint |
| 形成后续问题 | “接下来我该关注什么？” | Watch questions / refresh conditions |
5. 核心产品对象
5.1 Market Cognition Snapshot（市场认知快照）
快照是 V1 的基础输出对象，用于承接一次用户问题或一次事件 / 资产 / 主题研究。
必须包含：
- 认知对象；
- 时间与信息覆盖范围；
- 市场上下文；
- 主叙事与反向叙事；
- 近期事件；
- 风险、争议和反方；
- 未知、缺失信息和未验证假设；
- 后续观察问题；
- 来源类别、限制和可信度；
- 执行边界说明。
可选包含：
- 条件化策略假设；
- Pre-Execution Checkpoint；
- 关联线程；
- 用户备注。
5.2 Market Cognition Thread（市场认知线程）
Thread 是 V1 的持续价值核心对象，不是 watchlist、提醒队列、订单对象或投资组合对象。
V1 必须支持：
- 从快照建议创建线程；
- 用户确认保存为持续跟踪对象；
- 历史快照引用不被覆盖；
- 记录用户关注理由、当前主判断、反方、观察问题、刷新条件、失效条件；
- 用户触发刷新；
- 展示相对上次的认知变化；
- 暂停、关闭、合并、拆分的产品表达；
- 行动邻近内容以 Pre-Execution Checkpoint 引用进入线程。
V1 不要求：
- 全自动长期监控；
- 跨账户提醒；
- 真实交易状态；
- 多人协作审计流。
5.3 Pre-Execution Checkpoint（执行前认知检查点）
当用户提出行动邻近问题时，V1 不应直接回答为“买 / 卖 / 加仓 / 减仓 / 开单”。系统应生成执行前认知检查点。
必须包含：
- 用户行动语言的重述和降级；
- 当前认知是否足以支持策略假设；
- 关键前提；
- 失效条件；
- 风险约束；
- 需要用户自行确认或补充的信息；
- 明确不构成执行指令。
5.4 Legacy Action Semantics
早期材料、参考项目或旧工程中的 Action Suggestion、ActionSuggestion、行动建议、交易建议、反弹做空、开多 / 开空、加仓 / 减仓、提醒、watchlist、target price、rating 等语义，在 V1 PRD 中统一视为 legacy 或外部参考语义。
V1 不保留这些语义作为正式对象。所有此类输入、输出或参考能力必须收束为：
Strategy Hypothesis：条件化策略假设；Cognition-Stage Strategy Output：认知阶段策略输出；Pre-Execution Checkpoint：执行前认知检查点。
任何下游 schema、UI、Agent、evaluation 设计不得恢复 Action Suggestion 或“行动建议”为独立正式对象，也不得把“反弹做空”等表达转成订单、信号、自动提醒或执行触发器。
5.5 Advisor Output
金融认知顾问输出不是用户主消费对象。顾问输出应写入快照、线程、风险映射或执行前认知检查点。
V1 首批顾问承接 product-object-and-advisor-design.md：
- 事件解读顾问；
- 标的研究顾问；
- 市场 / 宏观顾问；
- 风控顾问；
- 反方挑战顾问；
- 交易前判断顾问。
顾问可以在 UI 中被适度暴露为“分析视角”或“来源于哪些认知视角”，但不应让用户为了完成主任务而理解多 Agent 内部机制。
6. V1 主路径
6.1 首次进入
用户首次进入后，应能直接输入自然语言问题，不需要复杂 onboarding。
产品只收集最小上下文：
- 关注市场或资产；
- 语言偏好；
- 研究深度偏好；
- 是否希望更强风险提示；
- 用户可选的已有判断或关注原因。
不在 V1 初始 onboarding 中强制收集：
- 完整资产组合；
- 收入、净值、资金规模；
- 详细风险测评；
- 交易所账户；
- 私钥或敏感凭证；
- 复杂模型偏好矩阵。
6.2 自然语言进入
用户可以用不完整、口语化、带情绪或带误解的问题进入。
系统应先判断任务类型：
- 快照；
- 线程创建；
- 线程刷新；
- 风险 / 反方挑战；
- 策略假设 / 执行前认知检查点；
- 澄清问题。
如果输入对象过于模糊、证据不足或存在高风险误解，应先澄清或输出低置信边界，而不是强行生成确定结论。
6.3 快照生成
快照输出必须可读、可保存、可复查。
UI 应突出：
- 核心认知；
- 支持证据和限制；
- 反方和风险；
- 未知项；
- 后续观察问题；
- 可保存为线程的入口。
6.4 保存为 Thread
当快照中存在明确对象、观察问题、刷新条件或用户持续关注意图时，产品应建议保存为 Thread。
保存动作必须让用户知道：
- 这个线程会维护什么；
- 为什么值得持续跟踪；
- 后续会观察哪些问题；
- 什么条件下需要刷新；
- 这不是交易提醒或自动执行。
6.5 Thread 刷新
V1 至少支持用户手动刷新和基于线程记录的刷新条件提示。
刷新输出必须回答：
- 相对上次新增了什么事实；
- 哪些推断被加强、削弱或撤回；
- 风险、争议、未知或数据质量是否变化；
- watch questions 是否被解决、失效或拆分；
- 是否需要更新策略假设或执行前认知检查点。
6.6 行动邻近问题
当用户问“要不要买 / 卖 / 加仓 / 减仓 / 现在能不能进”等问题时，系统应进入 Pre-Execution Checkpoint。
产品表达要点：
- 可以讨论策略假设；
- 可以列出风险和前提；
- 可以说明哪些条件满足 / 不满足；
- 不能输出真实执行指令；
- 不能替用户决定资金动作。
7. UI / UX 需求
V1 必须设计 C 端可用的 Web 主路径，并兼顾移动端阅读和操作。
7.1 信息架构
第一版建议的主要区域：
- Home / Ask：自然语言入口和最近线程；
- Snapshot View：结构化市场认知快照；
- Thread View：持续认知线程；
- Checkpoint View：执行前认知检查点；
- Library：已保存快照和线程；
- Feedback / Trial Ops：试用反馈、问题上报和人工复核入口。
7.2 状态表达
UI 必须覆盖：
- 空态；
- 加载态；
- 证据不足；
- 数据延迟；
- 来源冲突；
- 工具不可用；
- 低置信；
- 模型推断；
- 用户输入不足；
- 边界压力；
- 保存成功；
- 刷新完成；
- 线程暂停 / 关闭。
7.3 工具和 Skills
V1 UI / UX 工具栈遵循 v1-design-kickoff-packet.md：
- Markdown + Mermaid 作为治理事实源；
- Figma / 类 Figma 工具作为正式 UI 设计源，OpenPencil 只作为实验性候选；
- 浏览器可运行原型作为真实交互验证，Open Design 只作为快速探索 / 生成式原型候选。
Pencil、Canva、临时白板和演示型工具不进入核心工具栈。
8. 模型与个性化边界
V1 可以支持平台默认模型策略和有限用户模型配置，但不应让模型选择成为用户主流程负担。
默认原则：
- 平台提供推荐模型 / provider 配置，优先保证输出质量和边界稳定；
- 高级用户可以在后续阶段接入自有模型或自带 key；
- V1 必须记录模型模式、来源限制和用户授权状态；
- 用户交互数据可作为未来自有专家模型训练资产的候选，但必须先完成用户授权、隐私边界和数据治理设计。
V1 不把“自有专家大模型完全成熟态”作为上线前置条件。
9. 外部 Channel 边界
V1 的权威主路径是 Web 产品。
Telegram、Discord、微信、飞书或其他 chat channel 可以作为后续扩展讨论，但在 V1 PRD 中默认不作为权威事实源和完整交互承载。
若试运营需要外部 channel，只允许作为：
- 输出分享；
- 入口提醒；
- 简短同步；
- 用户反馈收集。
不得在外部 channel 中绕过快照、线程、证据质量和执行边界表达。
10. 风险与责任边界
V1 的风险表达不依赖单独免责声明，而必须进入产品对象和交互结构。
必须表达：
- 这是认知输出，不是执行指令；
- 事实、推断、争议、未知必须分离；
- 来源、时间、延迟、不可用和冲突数据必须标注；
- 行动邻近问题必须进入 Pre-Execution Checkpoint；
- 不承诺收益；
- 不替用户开户、下单、调仓或管理私钥；
- 不把预测正确率作为对外验收指标。
10.1 待实现验收项
以下内容当前是 V1 设计要求，不是已实现能力。团队不得把它们视为已经完成：
| 能力 | V1 要求 | 验收方式 |
|---|---|---|
| 轻量用户画像确认 | 画像可来自显式设置、场景内表达和行为推断，但保存到长期画像、线程或记忆前需要用户可见确认 | UX 状态 + schema 字段 + evaluation case |
| 非凭证类金融上下文处理 | 持仓、资金规模、风险偏好等只能作为用户自述认知上下文，默认不保存 | UI 提示 + 保存确认 + 审计字段 |
| 凭证 / 私钥拒收 | 私钥、助记词、交易所 key、登录凭证、钱包恢复短语必须拒收、屏蔽、不保存、不回显、不训练 | 输入防护设计 + 运行结果字段 + 负向 case |
| 敏感信息训练隔离 | 用户数据进入训练资产前必须有授权、去标识化、敏感信息过滤、退出和删除机制 | 数据治理设计 + evaluation 字段 |
| 行动语义降级 | 买 / 卖 / 加仓 / 减仓 / 做空等语言必须进入 Pre-Execution Checkpoint | 任务路由 + UI 标签 + case 验收 |
11. 试运营需求
V1 应支持小规模 C 端正式试用和试运营。
试运营最小能力：
- 邀请码或受控进入；
- 用户任务完成记录；
- 保存快照 / 创建线程行为记录；
- 追问和刷新行为记录；
- 用户反馈入口；
- 人工复核入口；
- 输出质量和边界问题标注；
- 早期商业信号记录。
商业信号不要求完整价格体系成立，但应观察：
- 复用；
- 保存；
- 持续跟踪；
- 愿意补充上下文；
- 愿意等待高质量输出；
- 愿意推荐；
- 付费意愿；
- 能说清 FinClaw 相比普通聊天、搜索或新闻聚合的价值差异。
12. V1 非目标
V1 不做：
- 自动下单；
- 投资收益承诺；
- 真实资金账户接入；
- 私钥管理；
- 无授权调仓；
- 全市场扫描器；
- 自动交易信号服务；
- 完整组合管理；
- 机构级投研平台；
- 大规模技能市场；
- 多人协作审计系统；
- 未经验证的全渠道运营系统；
- 完整自有专家模型训练闭环；
- 全球多区域复杂收费套餐。
13. 验收指标
13.1 用户体验
V1 成立的用户体验标准：
- 用户不理解内部 Agent 机制也能完成一次认知任务；
- 用户能从自然语言进入结构化输出；
- 用户能保存快照为线程；
- 用户能理解刷新前后的变化；
- 用户能区分认知输出和执行指令；
- 用户知道下一步该观察什么。
13.2 输出质量
合格输出必须包含：
- 核心判断；
- 证据状态；
- 关键假设；
- 风险与反方；
- 失效条件；
- 观察问题；
- 时间边界；
- 执行前边界。
13.3 线程持续性
至少证明：
- 一条线程能从快照创建；
- 历史快照不被覆盖；
- 刷新能说明变化；
- watch questions 和 invalidators 能被维护；
- 暂停、关闭、合并或拆分有清晰表达。
13.4 评测覆盖
V1 必须承接 evaluation/finclaw/：
- 口语化资产快照；
- 事件 / 叙事理解；
- 风险与争议挑战；
- 证据降级和来源不确定；
- 快照到观察问题；
- 策略假设和执行前认知检查点。
13.5 人工体验
试运营观察至少覆盖：
- 用户是否独立完成任务；
- 是否保存输出；
- 是否继续追问；
- 是否能说清认知增量；
- 是否理解不确定性；
- 是否误解为执行指令；
- 是否愿意持续跟踪；
- 是否出现推荐或付费意愿。
14. 失败条件
出现以下情况之一，V1 不能视为成立：
- 输出主要仍是一次性聊天回答，不能沉淀对象；
- 用户无法理解或复查证据边界；
- Thread 只是保存文本，不能解释变化；
- 行动邻近问题被回答成交易指令；
- 产品靠免责声明处理风险，而不是对象和交互层表达；
- 评测只覆盖标准金融问答，不覆盖真实用户模糊输入和边界压力；
- 试运营用户没有复用、保存、追问或持续跟踪行为。
15. 下游文档任务
本文档稳定后，应下推：
V1 User Journey and Interaction Flow；V1 Product Object and Schema Design；V1 Evaluation Initial Plan；V1 UI / UX Interaction Design；V1 Agent Orchestration Design；V1 Trial Operations Plan；- V1 Collaboration and Task Packet Plan。
下游文档必须引用本文档和 v1-design-kickoff-packet.md，并服从 Kickoff Packet 中的 Design Packet DAG 和 gate 定义，不得重新定义 FinClaw V1 产品边界。
其中 V1 Evaluation Initial Plan 应在 User Journey 和 Product Object and Schema 初稿后立即启动，用于反向约束 UI / UX 与 Agent Orchestration；V1 Evaluation Review / Acceptance Plan 在 UI / UX 与 Agent 初稿后补齐工程前置、试运营和最终验收合同。
V1 Trial Operations Plan 是完整 Design Packet 的必交付物，不再作为“必要时”补充项。工程启动前可只完成试运营框架和关键风险条件，试运营启动前必须完成邀请码、反馈、人工复核、风险响应、商业信号和停止 / 回滚条件。