第九节 产品立场与边界
FinBayes 的产品形态、商业立场、生态位置都建立在一组产品立场与边界之上。本节用结构化的方式说清楚：
- 核心定位边界（identity 级别，不可变）：FinBayes 是什么、不是什么
- 当前版本的产品立场（落地后持续评估和优化）：当前阶段的具体功能、约束、立场
- 立场演化的治理原则：什么时候、按什么流程调整
把当前阶段的所有具体约束都锁定为"永久不变量"会有真实代价：产品初期的具体限制和约束如果被锁死在战略层，可能极大影响产品的工程化落地和完整形态的实现。区分清楚"定位"与"立场"，给产品演化留出合理空间。
一、核心定位边界（identity 级别，不可变）
FinBayes 是金融认知层，不是执行层
- 输出认知材料（结构化分析、条件化结论），不输出执行指令
- 用户基于 FinBayes 认知输出自主形成判断后自行选择交易工具执行
- FinBayes 与下游执行端之间必须有用户自主判断这一步（详见第六节生态位置）
这条核心定位边界定义 FinBayes 是什么。如果未来产品形态做了根本性变化（直接下单、自动执行、替用户决策），那 FinBayes 变成另一种产品——执行助手 / 投资建议产品 / 喊单产品——不再是本白皮书定义的金融认知层。
这是 identity 级别的边界，不变更。
二、当前版本的产品立场（落地后持续评估和优化）
下面是 FinBayes 当前版本（第一阶段 M0-M3）的几个核心产品立场。这些是工程化落地版本要实现的功能 / 约束 / 立场，落地后会由产品 + 工程 + 商业团队持续评估和优化——不是永久不可变的承诺。
用户对自己金融认知资产的主权
用户在 FinBayes 中积累的金融认知资产（关注集、历史判断、复盘记录、动态认知画像）属于用户自己。当前版本支持：
- 可查看：用户可以完整查看自己的金融认知资产
- 可修改：用户可以修改 / 删除任何资产条目
- 可清空：用户可以一键清空全部资产重新开始
具体的查看 / 修改 / 清空 UI、工程实现机制由 L2 产品定义层和 L3 架构层承接。这些主权机制在用户产品全链路上生效，是 FinBayes 与用户之间的信任基础——后续演化时主权的范围、形式、深度可调整，但主权本身作为产品立场是稳定的方向。
两步写入契约（候选 → 用户确认）：长期金融认知资产（关注集、历史判断、复盘记录、动态认知画像）的写入采用 候选 → 用户确认 两步契约。这条契约保障用户对自己金融认知资产的主导权（用户不会被动地"被画像"）。具体的两步契约工程实现由架构文档承接（详见 projects/finbayes/engineering/architecture.md §11 / §13 / §17）。
金融执行凭证的处理
当前版本立场：用户的金融执行凭证留在用户自己的环境里——FinBayes 当前版本的工程实现不收集、不存储、不训练用户的金融执行凭证。
这条立场适用于以下凭证类型（不限于）：
- 交易所 API key / Secret key
- 私钥（特别是 Crypto 自托管钱包的私钥）
- 资金账户密码 / 银行卡号 / 支付凭证
- 任何能代表用户在金融账户上进行执行（下单、转账、变更账户状态）的凭证
当前版本的工程实现：架构文档定义的凭证过滤机制 + 相关 ADR（详见架构文档）。
与本机 Provider 配置的区分：本机 Provider 配置（用户在本地部署形态下配置的模型 Provider 凭证、数据 Provider 凭证、本地服务所需的秘密等）不属于金融执行凭证范畴——这些配置不能代表用户在金融账户上进行执行，只是用户本地运行 FinBayes 的环境配置。本机 Provider 配置的处理由架构文档承接（详见 architecture.md §9 / §13），与本节的金融执行凭证立场无关。
演化方向：当前版本严格不收金融执行凭证。未来如果出现合理的业务场景（如合规的机构服务、用户主动授权的特定场景等），凭证处理方式可由产品 + 工程 + 商业 + 合规团队联合评估调整——但调整必须走治理流程（详见下文立场演化的治理原则），不是工程或产品团队可以单独决定的变更。
认知输出的事实空间约束
FinBayes 当前版本的认知输出按事实空间生成，反方证据、关键风险、失效条件不因用户偏好被省略。
当前版本的工程实现：架构 §13 已强调"画像不裁剪事实空间"作为综合层的非可选契约——反方证据、关键风险、失效条件不因画像偏好被裁剪。
这条立场的价值定位：直接保护用户的判断质量。如果 FinBayes 因为"用户喜欢看多"就只给看多材料，那 FinBayes 与喊单产品的输出形态就没有本质区别（详见第四节理由一）。
演化方向：当前版本严格按事实空间生成。未来如果用户场景出现需要权衡（如用户明示要求过滤特定类型反方证据），事实空间约束的具体边界可调整——但调整必须走治理流程。
付费层级的输出质量
当前版本立场：所有付费层级共享同一套结构化认知输出本质——FinBayes 当前版本的付费层级设计上，付费等级不改变结构化认知输出的本质质量。
- 付费可能改变：用量上限、附加入口形态、保留时长、增值能力
- 付费不改变（当前版本）：结构化认知输出 10 要素的完整性（详见第五节）、条件化结论的有效性、反方证据呈现深度、失效条件标注完整性
当前版本立场的商业含义：这条立场是第八节商业立场核心锚点三的硬约束在产品层的落地。它是 FinBayes 与"VIP 群有更准信号"型喊单产品的核心商业差异（详见第四节理由二）。
演化方向：当前版本付费层级不影响输出质量本质。未来如果商业模式演化需要重新评估（如不同业务场景的付费层级设计、机构服务的差异化等），由商业团队 + 产品团队 + 战略团队联合评估调整——必须走治理流程。
三、立场演化的治理原则
上述当前版本立场可能随产品演化、商业模式调整、技术能力增强而调整。
调整原则：
- 不变更核心定位边界：FinBayes 是认知层不是执行层这条边界不变。其他立场可调整
- 重大调整走 ADR 流程：任何对当前版本立场的重大调整（如凭证处理方式、用户主权范围、付费层级输出质量、事实空间约束等）必须走 ADR 流程，记录决策依据 + 调整范围 + 演化路径
- 必要时启动战略白皮书 patch 工作流：如果调整足够大、影响范围足够广，启动专门的战略白皮书 patch 工作流，让对用户和生态的立场变更被公开记录和评议（参考
commons/playbooks/document-workflows-meta-playbook.md） - 持续评估与优化：当前版本立场在落地后由产品 + 工程 + 商业团队持续评估，识别需要优化的部分；评估周期、责任人、评估输出物由产品团队规划承接
这些机制不是"绝对不可改"，是"改的代价足够大，让维护者认真考虑是否真的要改"——目的是保护当前版本立场的相对稳定性，同时给产品演化留出柔性空间。
工程承接（指针式）
- 核心定位边界：在架构 §4 的输出对象设计、§6 的任务分类、§13 的相关约束落地等多处承接
- 当前版本的产品立场：由 L2 产品定义层 + L3 架构层 + 商业团队规划共同承接（凭证过滤机制、用户主权三件套的 UI/工程实现、画像不裁剪事实空间的综合层约束、付费层级的差异化设计等）
- 立场演化的治理机制：本工作流的
decisions/目录承接 ADR 流程；战略层 patch 由战略白皮书 patch 工作流承接
总结
FinBayes 是金融认知层——这条核心定位边界是 identity 级别的，不变更。
其他的产品立场（用户主权、凭证处理、画像不裁剪事实空间、输出质量跨付费层级一致）是当前版本的核心产品立场，落地后会持续评估和优化。重大调整走治理流程。
这种区分让 FinBayes 在产品初期保留足够的实施柔性，同时锁定不可变更的核心定位边界。