第二十二节 — 第一阶段缺口
这一节回答：第一阶段明示不抢答的开放问题有哪些？为什么不抢答？什么条件下会被触发处理？
三类缺口
| 类别 | 含义 | 来源 | 处理路径 |
|---|---|---|---|
| 战略待定 | 战略层尚未给定答案，工程层不替代 | 继承自白皮书 §15 | 触发条件成立时回到战略层讨论 |
| 工程延后 | 战略已定但第一阶段优先级不够 | 工程层新增 | 接口契约不变，后续版本演化补 |
| 场景外 | 不在第一阶段服务范围 | 战略边界 + 工程定位 | 暂不投入，演化预留接口 |
缺口来源分层（详见各 P1 / P2 段标注）：
- 继承自白皮书 §15：商业模式与定价 / 个人 vs 机构分立 / 更多市场普适性 / L1-L3 商业强度
- 产品层新增（产品定义文档识别）：跨设备同步 / Channel 优先级 / 任务类型最终形态
- 工程层新增（本架构文档识别）：认知质量验收方法（OQ-002）/ 自动 Prompt 优化 / 实时 metric dashboard / 分布式 trace / 等
- ADR 待定：ADR-004 至 ADR-010 共 7 条（详见 §23）
明示这些缺口不是"工程不完整"，而是有意识的不投入 —— 第一阶段焦点是"本地优先单机的认知层 MVP 走通"，不抢答与该焦点无关的问题。
战略待定的缺口
这一类与战略层的"未决问题"（详见上位继承与不变量章节）对齐：
第一阶段不抢答的战略未决
| 未决问题 | 工程层影响 | 触发讨论条件 |
|---|---|---|
| 商业模式与定价 | 不影响第一阶段架构 | 用户量达到 1000+ / 主动信号价值验证后 |
| 多用户共享 Watchlist / 团队级审计 | State Store schema 预留 user_id，但不实现共享 | 企业用户出现 |
| 跨设备同步（用户多机 FinBayes 状态同步） | 不实现，State Store 单机本地 | 用户明确需求出现 |
| Channel Adapter 第二阶段优先级（TG / Discord / Slack 谁先） | 主推 Web 与 CLI / TUI，Channel 接口预留 | 用户访问通道偏好数据出现 |
| 任务类型清单的最终形态（是否扩展、是否细分） | 不写死，按 LLM Function Calling 动态识别（详见 CHAP-04 / CHAP-09） | 评估闭环发现新型任务模式 |
| 认知质量验收的最终方法（OQ-002） | CHAP-21 给出第一阶段建议，但不锁定 | 上线后实际质量数据积累 |
已经过深度调研但 ADR 待定
| 议题 | 调研产物 | ADR 编号 |
|---|---|---|
| 自然语言到任务的识别策略（OQ-003） | projects/finbayes/research/intent-recognition-and-llm-strategy/ 已起草 README + summary + recommendations | ADR-004 |
| Prompt 是代码还是数据 | CHAP-19 给出初步倾向（混合策略） | ADR-009 |
| 输出端凭证类内容过滤的位置 | CHAP-17 给出初步倾向（两处都做） | ADR-010 |
工程延后的缺口
战略已对齐、第一阶段不投入但接口契约预留的能力：
高级测试 / 评估能力
| 能力 | 第一阶段做什么 | 演化路径 |
|---|---|---|
| 模糊测试（fuzzing） | 不做 | 评估闭环成熟后加 |
| 自动 Prompt 优化（如 DSPy） | 不做（避免反馈循环失控） | 评估指标稳定后探索 |
| 实时 metric dashboard（Prometheus + Grafana） | 不做，用 CLI / TUI 命令查询 | 多用户部署后引入 |
| A/B 实验框架 | 不做（单用户单机不必要） | 远程托管后引入 |
| 浏览器 UI 自动化测试（Playwright） | 不做（Web UI 最小可用） | Web UI 成为主入口后引入 |
高级可观测性
| 能力 | 第一阶段做什么 | 演化路径 |
|---|---|---|
| 分布式 trace（OpenTelemetry） | 不做（单进程不需要） | 拆分进程或远程部署时引入 |
| 云端日志聚合（Datadog / Loki） | 不做（本地优先违背） | 用户显式选择上报时引入 |
| 实时质量告警 | 不做（评估周期跑足够） | 用户对认知质量提出实时监控需求时 |
| 异常上报到云服务（Sentry） | 不做 | 用户显式选择时 |
部署能力
| 能力 | 第一阶段做什么 | 演化路径 |
|---|---|---|
| 远程托管部署 | 不做，第一阶段单机 | 商业模式验证 + 多用户隔离设计完成 |
| 多用户的真正运行时隔离 | 仅 user_id 维度预留，不实现强隔离 | 远程托管时实现 |
| 容器化（Docker / K8s） | 不做（单机不需要） | 远程托管时 |
| 跨平台兼容性矩阵测试 | 主流平台各一基线 | 用户分布数据驱动 |
数据能力
| 能力 | 第一阶段做什么 | 演化路径 |
|---|---|---|
| State Store 从 SQLite 迁 PostgreSQL | 不做，SQLite 足够 | 多用户或单用户数据规模超 SQLite 上限时 |
| 数据回溯与时间旅行（如 EventSourcing） | 不做，仅靠审计 trail 复盘 | 复盘需求复杂化时 |
| 多语言 / 国际化 | 不做，第一阶段中文 + 英文术语 | 用户群扩展时 |
| 跨用户数据聚合 / 群体智能 | 不做（隐私 + 单用户） | 商业模式与隐私策略明确后 |
场景外的缺口
明示不在第一阶段服务范围：
| 场景 | 不做的理由 |
|---|---|
| 真正的"自动化交易代理" | 战略边界：FinBayes 不直接下单 / 不持账户凭证（详见 CHAP-02） |
| "金融执行凭证管家" | 战略边界：凭证一律不收 |
| 替用户做最终判断的"AI 决策"模式 | 认知层定位：不替用户决策（详见 CHAP-03） |
| 个性化广告 / 行情诱导 | 业务定位：仅服务用户认知，不卖流量 |
| 跨用户的"群体趋势"推断 | 隐私 + 战略：用户画像主权 |
| 实时高频信号（毫秒级触发） | 性能定位：认知层不做高频系统 |
这些不仅第一阶段不做，演化路径上也不做 —— 与战略定位冲突。
缺口的演化触发条件
缺口被触发时如何处理：
关键约束：
- 工程层不替战略层做决策 —— "战略待定"缺口被触发时回到 governance/change-protocol.md 走战略变更流程
- 工程层不为缺口偷偷开后门 —— 例如不会"先在 State Store 做多用户隔离的临时方案"，因为这种临时方案常常被锁定下来变成事实标准
- 演化中的不变量（详见 CHAP-19）任何时候不变
缺口与质量目标的关系
缺口与 CHAP-03 的 8 个质量属性的关系：
| 质量属性 | 第一阶段缺口影响 |
|---|---|
| 可用性 | 不影响（第一阶段降级链已覆盖核心可用性需求） |
| 性能 | 不影响（缺的是优化空间，不是基础性能） |
| 可演化性 | 关键 —— 缺口的接口契约预留是可演化性核心承接 |
| 可测试性 | 部分影响（fuzzing / 浏览器自动化等延后，但核心测试体系已完整） |
| 可观测性 | 不影响（核心可观测已完整，缺的是高级集成） |
| 战略保真度 | 不影响（战略边界是缺口的约束，不是缺口的产物） |
| 部署便捷性 | 不影响第一阶段 |
| 用户主权 | 不影响（用户主权是战略级，缺口都遵守） |
缺口管理的工程动作
| 动作 | 内容 |
|---|---|
| 缺口登记 | 每个缺口在本章登记 + 在工程实施仓 issue tracker 留 placeholder |
| 缺口触发判断 | 每个 release 评估各缺口的触发条件是否成立 |
| 缺口推进 | 触发时按上述流程图走战略 / 工程分流 |
| 缺口与不变量冲突 | 缺口处理方案若与演化中的不变量冲突，停下来回战略层 |
与其他章节的关系
- 战略未决问题 → CHAP-02 上位继承与不变量
- 8 个质量属性 → CHAP-03 架构目标与质量取舍
- 任务类型清单非写死 → CHAP-04 业务对象与关系
- 第一阶段不抢答的部署形态 → CHAP-14 部署形态
- 演化中的不变量 → CHAP-19 演化与版本管理
- 第一阶段不做的测试能力 → CHAP-20 测试体系
- 第一阶段不做的评估能力 → CHAP-21 评估闭环
- 待写 ADR 清单 → CHAP-23 架构决策索引
- 缺口对应的风险 → CHAP-24 风险登记