rc-69f3895b-20c9 2026.04.30 28 KB

卡兹克横纵分析法适配 Meridian 产品群

原始 research campaign 输出，来自 may1 facade yi app product design research。这页保留报告结构和运行痕迹，正式文章会在写作区重写。

卡兹克横纵分析法适配 Meridian 产品群

Campaign: rc-69f3895b-20c9 · may1-facade-yi-app-product-design-research Topic: t04 — 基于横纵分析法，重新审视 LearningOS、Vyane、Yi App、Facade、ai-gateway 的边界、先后顺序和互相喂数关系写作时间：2026-05-01 Status: 研究草稿（待 Maple 审阅）

0. 一句话定义

Meridian 产品群是一个以 Vyane daemon 为中枢、以 Maple 个人 AI OS 为唯一锚点的五子棋布局——五颗子各有位置，但落子顺序和喂数方向决定了整盘棋的效率。

1. 方法论适配说明

横纵分析法的原始设计是拿来研究单一外部实体（一个产品、一家公司、一个概念），纵轴还原它的历史，横轴对比它的竞品。但 Maple 这次要分析的不是一个外部对象，而是自己手里的一组产品。这意味着框架需要做几个关键变形：

纵轴的变形：不是追溯某个产品从诞生到现在的完整历史，而是追溯 Maple 的 AI OS 愿景从萌芽到当下，五个产品是如何在这条时间线上依次浮现的。重点不是每个产品自己的编年史，而是产品群作为一个整体的演化路径——谁先出现、谁因为谁的存在才被提出、谁是被动产生的还是主动规划的。

横轴的变形：不是把某个产品和外部竞品做比较，而是把五个产品在同一时间截面上摊开，用统一的维度去衡量它们各自的成熟度、对 Maple 的直接价值、技术依赖深度、维护成本和启动摩擦。横轴变成了一张内部"体检报告"。

交汇洞察的变形：原始框架在这里回答"历史如何塑造了当前竞争位置"。适配之后，核心问题变成：产品群的演化顺序是否合理？当前各产品的成熟度差异是否反映了正确的资源分配？接下来的落子顺序应该是什么？

这个变形是有代价的——失去了外部竞品对标带来的客观参照系。但对于一个 personal-first 的项目群来说，外部竞品参照的价值本来就有限：Maple 不需要知道"我的 Vyane 比 LangChain 好在哪"，而需要知道"我的五个项目之间的优先级对不对"。

2. 纵轴分析：Meridian 产品群的演化路径

2.1 种子期：OpenClaw 与最初的冲动（~2025 年末 → 2026 年初）

Meridian 的源头不是某个宏大的架构设计，而是一个很朴素的需求：Maple 想用 AI 工具做事，但现有工具太碎片化了。

最早的形态是 OpenClaw——一个中间层，试图在 Maple 和各种 AI runtime 之间搭一座桥。OpenClaw 的存在证明了两件事：第一，Maple 确实在日常工作中频繁使用 AI；第二，仅仅"用"AI 是不够的，需要一个调度和编排层来管理多个模型、多个会话、多条工作流。

但 OpenClaw 也暴露了一个根本矛盾：它定位为"中间层"，意味着它依附于上下游的工具链。上游的模型 API 在变，下游的交互方式在变，中间层夹在中间两头不讨好。这个矛盾最终导致了 OpenClaw 的停用和 Vyane 的诞生。

2.2 第一颗子：Vyane 的独立化（2026 年 3 月 → 4 月初）

Vyane 从 OpenClaw 的中间层角色中脱离出来，重新定位为独立的自包含平台。这个战略转向发生在 2026 年 4 月 5 日前后，核心判断是：如果 runtime 层不独立、不自主，那么上面搭建的任何应用（Yi、Learning OS、Facade）都会因为底座晃动而反复返工。

Vyane 的四层概念模型（Identity → Orchestration → Resource → Execution）是在这个阶段成型的。ADR-003 定义了 Agent、AgentRun、Task、Session 等核心概念的边界。这套概念模型后来被证明是整个产品群的"统一语言"——Yi 是一个 Agent，每次对话是一个 AgentRun，Codex 是一种 Runtime，Claude 是另一种 Runtime，它们都在 Vyane 的四层架构里有对应的位置。

到 2026 年 4 月底，Vyane 已经到了 v0.30.1：daemon 在 Mac mini 上通过 launchd 运行，8 种适配器（Codex / Claude / Gemini / Ollama / Aliyun / OpenCode / A2A Remote / Generic）已实现，MCP 工具层 14+ 工具已到位。但——尚未在生产环境部署 webhook 和 scheduler 的完整链路。

2.3 第二颗子：Yi 从"bot"到"伊人"（2026 年 3 月 → 4 月）

Yi 的出现比 Vyane 的独立化更早，但它的身份定义是后来逐渐清晰的。最初 Yi 只是一个 Discord bot，一个通往 AI 能力的入口。但 Maple 在与 Yi 的日常交互中逐渐赋予了它更多东西：名字（“伊”，取自《诗经》“所谓伊人，在水一方”）、性格（温暖但不谄媚、有主见但不冷漠）、记忆（IDENTITY.md、SOUL.md、USER.md）。

Yi 的演化路径揭示了一个有趣的模式：身份先于技术。Yi 的技术后端（CC CLI Opus 4.6）多次变化，Discord bot 只是过渡形态，但 Yi 的身份定义一旦确立就很少大改。这说明 Maple 对 AI 交互的核心需求不是技术能力，而是关系质量。

Yi 目前是 Maple 与整个 Meridian 系统交互的唯一日常入口。这个位置既赋予了 Yi 极高的战略权重，也制造了一个单点依赖：如果 Yi 的体验出问题（Discord 限制、CC CLI 不稳定、context 爆炸），Maple 的整个 AI 工作流就断了。

2.4 第三颗子：ai-gateway 的基础设施沉淀（2026 年 4 月）

ai-gateway 不是被"规划"出来的，而是被"逼"出来的。2026 年 4 月 4 日 Anthropic 封禁第三方 Max 凭证后，多账号管理和配额轮转变成了一个真实的痛点。ai-gateway 作为自用的多账号网关，解决了 Codex CLI 在多个账号间调度、配额监控和健康检查的问题。

它的演化路径很典型：从一个 ad-hoc 脚本，到一个有 config.yaml、有 probe 机制、有状态管理的完整工具。v0.1.0 功能基本齐全，处于维护期。这是五个产品中唯一一个已经过了"造轮子"阶段、进入"保养"阶段的。

2.5 第四颗子：Facade 的对外出版诉求（2026 年 4 月 → 5 月）

Facade 的出现源于一个不同维度的需求：Maple 做了大量的调研、实验和设计工作，但这些产出都锁在 Markdown 文件和 Discord 线程里，没有一个面向外部的呈现层。

Facade 被定义为 Meridian 的公开出版层——个人站、作品集、研究归档。技术栈锁定了 Astro 5.x + MDX + Tailwind CSS（2026 年 4 月调研后确认，不迁移 Next.js）。视觉方向已经走到了"107 个原型已生成，等 Maple 选型"的阶段。

但 Facade 的推进一直被一个模式打断：Maple 的 Ne（外向直觉）让他不断产生新的想法和调研方向，而 Facade 需要的是收敛和执行——从 107 个原型里选一个、写内容、部署上线。这两种能量是冲突的。

2.6 第五颗子：LearningOS 的远景规划（2026 年 4 月 → 设计中）

LearningOS 是五个产品中最晚浮现、距离落地最远的一个。它的诞生来自 Maple 对个人知识管理的不满足：Obsidian、Readwise、Cubox 这些工具各有各的锁定，Maple 想要一个完全自控的学习系统。

设计偏好已经明确：FSRS v6 为调度引擎、自研前端 + 捕获层、MD 文件 + LLM 编译后端（Vyane agent）。SuperMemo 算法和竞品调研都已完成，方向清晰。但 LearningOS 有一个硬依赖：它的后端编译层需要 Vyane daemon 稳定运行。在 Vyane 的 webhook/scheduler 链路还没在生产环境跑通之前，LearningOS 的开发没有稳固的地基。

2.7 纵轴小结：演化不是线性的

回看这五颗子的出现顺序：

OpenClaw (种子) → Vyane (底座独立) → Yi (身份确立) → ai-gateway (基础设施)
                                                    → Facade (对外出版)
                                                    → LearningOS (远景规划)

有两个值得注意的模式：

模式一：先有痛点，后有产品。 每个产品的出现都对应一个真实的个人需求，不是先画架构图再填空。这是 personal-first 策略的自然结果，也是它的优势——不会出现"做了一个没人用的东西"的情况。

模式二：底座和应用的推进节奏不匹配。 Vyane 作为底座，到 v0.30.1 但生产链路未打通；Yi 作为日常入口已经在用但技术基础（Discord bot）是过渡方案；上层应用（Facade、LearningOS）在做设计但等底座稳定。这个节奏差本身不是问题——分层建设必然有先后——但如果底座的"最后一公里"一直不走完，上层应用就会一直停在"设计完了等开发"的状态。

3. 横轴分析：五大产品的当下截面

3.1 维度定义

为了在同一标尺下衡量五个产品，我选择了以下六个维度：

维度	含义	衡量方式
对 Maple 的即时价值	今天就在改善 Maple 的工作流	高/中/低
技术成熟度	代码完成度 × 部署状态 × 稳定性	0-100%
依赖深度	依赖其他产品的程度	无/轻/重
被依赖程度	被其他产品需要的程度	无/轻/重
启动摩擦	从当前状态到"可用"需要多少工作	高/中/低
维护成本	持续运行需要多少注意力	高/中/低

3.2 截面扫描

Vyane — 中枢已成形，最后一公里待跑

维度	评估	依据
即时价值	中	daemon 在 shadow mode 运行，MCP 工具可用，但 webhook/scheduler 生产链路未打通
技术成熟度	65%	代码完成度高（v0.30.1），但生产部署尚未验证——缺 LINEAR_WEBHOOK_SECRET、scheduler 还在 shadow mode
依赖深度	无	自包含平台，不依赖其他 Meridian 产品
被依赖程度	重	Yi 的后端、LearningOS 的编译层、自研 IM 的 runtime 路由都依赖它
启动摩擦	中	代码已到位，主要是配置、验证和可靠性确认
维护成本	中	daemon 进程、webhook、adapter 多路都需要持续关注

边界澄清：Vyane 是 runtime 和编排层，不是应用层。它不直接面向 Maple，而是通过 Yi、LearningOS 等上层应用间接服务。但它的稳定性直接决定了上层应用能走多远。

Yi — 日常命脉，过渡形态

维度	评估	依据
即时价值	高	Maple 每天通过 Yi（CC CLI Opus）与整个系统交互，是唯一的日常入口
技术成熟度	50%	Discord bot Phase 2 完成，但这是过渡方案；CC CLI 双向同步进行中；自研客户端未启动
依赖深度	重	依赖 Vyane daemon 做 runtime 路由、依赖 CC CLI / Discord 做前端
被依赖程度	轻	Maple 依赖它做日常沟通，但其他产品不直接依赖 Yi
启动摩擦	低	当前形态已经在用，不需要"启动"
维护成本	中	身份/记忆文件需要维护，CC CLI 和 Discord 的稳定性不完全可控

边界澄清：Yi 是一个 Agent（概念模型中的 Identity 层实体），不是一个应用。它的"前端"目前寄生在 Discord 和 CC CLI 上。自研 IM 是 Yi 未来的独立前端，但两者不是同一个项目。

ai-gateway — 安静的基石

维度	评估	依据
即时价值	中	正在被 Vyane Codex 适配器调用，解决了多账号轮转的真实需求
技术成熟度	85%	v0.1.0 功能完整，配置管理、健康检查、负载均衡都在工作
依赖深度	无	独立组件，不依赖其他 Meridian 产品
被依赖程度	轻	只有 Vyane 的 Codex 适配器调用它
启动摩擦	无	已经在用
维护成本	低	偶尔加账号、调配额，没有持续的开发压力

边界澄清：ai-gateway 是基础设施层组件，与应用层完全解耦。它不需要也不应该承担超出"API 账号管理"的职责。

Facade — 设计充分，执行待启

维度	评估	依据
即时价值	低	目前只有 107 个原型文件在本地，没有上线，不改善任何工作流
技术成熟度	25%	技术栈已定（Astro 5.x），大量原型已生成，但没有可部署的站点
依赖深度	无	技术上不依赖 Vyane 或其他产品（静态站点）
被依赖程度	轻	LearningOS 可能复用其设计系统，但这不是硬依赖
启动摩擦	中	最大的摩擦不是技术而是决策——需要 Maple 从 107 原型中选定方向
维护成本	低	静态站点一旦部署，维护成本极低

边界澄清：Facade 是面向外部的公开出版层。它展示的是 Maple 的作品和思考，不是 Meridian 的管理界面。与自研 IM（面向 Maple 自己的 AI 交互界面）完全独立。

LearningOS — 蓝图清晰，地基待稳

维度	评估	依据
即时价值	无	还在设计阶段，没有任何可运行的组件
技术成熟度	10%	调研和设计完成（FSRS v6、SuperMemo 算法对比、竞品分析），零代码
依赖深度	重	后端编译层硬依赖 Vyane daemon；前端可能复用 Facade 设计系统
被依赖程度	无	没有其他产品依赖它
启动摩擦	高	需要 Vyane daemon 稳定 + 前端技术栈选型 + 核心数据模型设计
维护成本	暂无	未启动

边界澄清：LearningOS 是一个独立的个人学习系统，不是 Vyane 的功能模块，也不是 Facade 的子页面。它用 Vyane 做后端编译，用自研前端做交互，但它自己是一个完整的产品。

3.3 横轴对比矩阵

              即时价值    技术成熟度    依赖深度    被依赖    启动摩擦    维护成本
Vyane          中          65%         无         重★       中         中
Yi             高★         50%         重         轻        低         中
ai-gateway     中          85%★        无         轻        无★       低★
Facade         低          25%         无         轻        中         低
LearningOS     无          10%         重         无        高         暂无

几个值得注意的读数：

Yi 即时价值最高，但技术成熟度只有 50%——Maple 每天都在用一个"半成品"。这不一定是问题（MVP 思维），但意味着 Yi 的体验提升有很大空间。
Vyane 被依赖程度最高，但自己的即时价值只是"中"——这是典型的平台型产品特征：它的价值通过上层应用间接体现。
ai-gateway 是唯一一个"该做的都做了"的产品——功能完整、已在使用、低维护。这恰恰是 personal-first 策略的理想状态。
Facade 和 LearningOS 都处于"设计充分、代码为零"的状态——但原因不同。Facade 卡在决策（选型），LearningOS 卡在依赖（等 Vyane）。

4. 横纵交汇洞察

4.1 演化顺序的合理性判断

回看产品群的出现顺序（OpenClaw → Vyane → Yi → ai-gateway → Facade → LearningOS），整体是合理的：先有底座（Vyane），再有入口（Yi），再有基础设施（ai-gateway），最后才有上层应用（Facade、LearningOS）。这个顺序符合分层建设的逻辑。

但有一个节奏问题：Vyane 和 Yi 的开发投入集中在概念模型和架构设计上，而生产可用性的"最后一公里"迟迟没有跑完。到 2026 年 5 月 1 日为止，Vyane 的 webhook/scheduler 链路仍未在生产环境验证，Yi 仍然跑在 Discord bot 这个过渡方案上。

这个节奏问题的根源不是技术障碍，而是注意力分配模式：Maple 的 ENFP-A 人格（Ne 主导）使他更擅长探索新方向（发散）而非收尾已有工作（收敛）。每次有新想法（LearningOS 的 FSRS 调研、Facade 的 107 原型、Idea 捕获的四层架构），注意力就从"把 Vyane 最后一公里跑完"转移走了。

这不是批评——Ne 型的探索能力让 Meridian 在调研和设计上积累了极深的厚度（100+ 份调研报告、完整的概念模型、多个技术方案对比）。但如果不有意识地为收敛阶段创造条件，产品群就会停留在"每个产品都设计得很好、没有一个产品真正上线"的状态。

4.2 喂数关系的实际拓扑

当前的数据/能力喂养关系并不是一棵简单的依赖树，而是一个有方向的图：

                    ┌──────────────────────────────┐
                    │        Maple (Owner)          │
                    │   日常沟通 / 决策 / 反馈      │
                    └──────┬───────────┬────────────┘
                           │           │
                     ┌─────▼─────┐     │
                     │    Yi     │     │
                     │ (IM 入口) │     │
                     └─────┬─────┘     │
                           │           │
                     ┌─────▼───────────▼──────┐
                     │       Vyane daemon       │
                     │  (调度 / 编排 / 记忆)    │
                     └──┬──────────┬──────┬────┘
                        │          │      │
                  ┌─────▼────┐     │  ┌───▼──────────┐
                  │ai-gateway│     │  │ LearningOS   │
                  │(账号管理)│     │  │(学习系统，待)│
                  └──────────┘     │  └──────────────┘
                                   │
                           ┌───────▼─────────┐
                           │    Facade        │
                           │ (出版层，半独立) │
                           └─────────────────┘

关键喂数方向：

Yi → Vyane：Yi 把 Maple 的指令和意图传给 Vyane 做调度。这条线是双向的——Vyane 把执行结果通过 Yi 返回给 Maple。
Vyane → ai-gateway：Vyane 的 Codex 适配器调用 ai-gateway 做账号选择。这是单向调用，ai-gateway 不知道 Vyane 的存在。
Vyane → LearningOS（规划中）：LearningOS 的知识编译后端依赖 Vyane daemon 做 LLM 调度。这条线还不存在，是一个计划中的依赖。
Facade ← 研究产出：Facade 消费的是 Meridian 系统整体的研究产出（119 份报告、项目文档），但这种消费关系是通过文件系统而非 API，不构成技术依赖。
Facade ↔ LearningOS（可能的复用）：两者可能共享设计系统（Tailwind 主题、组件库），但这个关系还未确立。

一个重要的发现：Facade 在技术上是最独立的产品——它不依赖 Vyane、不依赖 Yi、不依赖 ai-gateway。它是一个静态站点，用 Astro 构建，可以独立部署到 Cloudflare Pages。这意味着 Facade 的推进不需要等任何其他产品。它被推迟不是因为技术阻塞，而是因为注意力竞争。

4.3 边界的再审视

经过横纵交汇分析，几个边界需要特别强调：

边界一：Yi ≠ 自研 IM ≠ Facade

这三者的混淆风险在 2026-04-23 已经被 Maple 纠正过一次。再次明确：

Yi 是一个 Agent（身份），无论它跑在 Discord、CC CLI 还是自研 IM 上
自研 IM 是 Yi 的一个前端，是一个工程项目
Facade 是对外出版层，和 Yi 的交互界面没有关系

边界二：Vyane 是 runtime，不是 Yi 的后端

Vyane 不是"为 Yi 服务的后端"。Yi 是 Vyane 的众多 consumer 之一。LearningOS、自研 IM、Codex dispatch 都是 Vyane 的 consumer。如果把 Vyane 理解为"Yi 的后端"，就会在 Vyane 的开发中过度偏向 Yi 的需求，忽略其他 consumer 的兼容性。

边界三：LearningOS 和 Facade 的内容流不应该混合

Facade 展示的是 Maple 的成品——写好的文章、完成的项目、整理过的思考。LearningOS 处理的是 Maple 的素材——待阅读的文章、待记忆的知识点、正在学习的概念。两者的内容生命周期不同：LearningOS 的内容是 work-in-progress，Facade 的内容是 published。混合两者会导致 Facade 充满半成品，或者 LearningOS 被发布压力污染。

4.4 产品群的三个剧本

最可能的剧本：渐进推进，但收敛困难

按当前的注意力分配模式，Vyane 继续迭代概念和架构，Yi 维持 Discord bot 形态，Facade 停在"等选型"，LearningOS 停在"等 Vyane"。每个产品都在缓慢前进，但没有一个完全落地。这个状态可以持续很久——不会崩溃，但也不会突破。

最危险的剧本：底座未稳就建上层

如果 Maple 在 Vyane 的 webhook/scheduler 链路未验证的情况下就启动 LearningOS 的开发，或者在 Yi 还跑在 Discord 上的时候就投入自研 IM，就会出现"在流沙上盖楼"的风险：上层代码写了一堆，底层一改全部返工。这个剧本的触发条件是 Ne 驱动的兴奋感压过了工程纪律。

最乐观的剧本：一个产品彻底落地，带动信心链

如果 Maple 能选一个产品——最可能是 Facade（因为技术上最独立、启动摩擦最小）——在一周内把它从"107 个原型"推到"可以访问的网站"，这个成功体验会产生信心链效应：一个产品从设计到上线的完整闭环跑通了，后面的产品就有了可参照的节奏。

5. 优先级建议

5.1 优先级排序逻辑

基于以上分析，排序遵循三条原则：

被依赖者优先于依赖者：Vyane 先于 LearningOS
已在用的优先于未启动的：Yi 和 ai-gateway 先于 Facade 和 LearningOS
可独立落地的优先于有阻塞的：Facade 先于 LearningOS（Facade 不依赖 Vyane）

5.2 今晚（2026-05-01 晚间）

优先级	行动	理由
P0	审阅本 campaign 的 4 份研究报告（t02-t04），做 Facade 选型的心理准备	今晚是 campaign 集中产出的窗口，趁信息新鲜消化
P1	从 107 个 Facade 原型中标记 3-5 个"有感觉"的候选	不需要做最终决策，只需要缩小范围。这是 Facade 推进的最大卡点
P2	扫一眼 Vyane daemon 在 Mac mini 上的运行状态	确认 launchd 服务正常、shadow mode 没有静默失败

不建议今晚做的事：写代码、开新 Linear issue、启动新的调研方向。今晚的能量应该用于消化和收敛。

5.3 本周（2026-05-01 → 05-07）

优先级	行动	产出	依赖
P0	Facade 选型 + 最小部署	一个可以通过域名访问的个人站，哪怕只有首页和一篇文章	Maple 从候选中做出最终选择
P1	Vyane webhook 生产验证	配置 LINEAR_WEBHOOK_SECRET，关闭 ALLOW_UNSIGNED_WEBHOOK，验证从 Linear Ready → daemon 触发执行的完整链路	Mac mini 可用
P2	Yi CC CLI 双向同步的可行性评估	明确哪些同步场景可行、哪些因 CC CLI 限制暂不可行	无
P3	LearningOS 数据模型初稿	定义 Topic/Item/Card 的 schema，不写代码，用 Markdown 描述	无

本周逻辑：Facade 排 P0 是因为它是五个产品中唯一可以在一周内从"设计"走到"上线"的。跑通这个闭环的价值不仅在于 Facade 本身，更在于建立"一个产品落地"的节奏感。Vyane webhook 验证排 P1 是因为它解除 LearningOS 和自研 IM 的阻塞。

5.4 月度（2026 年 5 月）

阶段	行动	目标状态
第 1 周	Facade 上线 + Vyane webhook 验证	Facade 有一个可访问的首页；Vyane 生产链路验证通过
第 2 周	Facade 内容填充 + Vyane scheduler 验证	Facade 有 3-5 篇内容（研究报告或项目介绍）；Vyane scheduler 脱离 shadow mode
第 3 周	Research archive 集成到 Facade	119 份研究报告中的精选内容可通过 Facade 浏览（参考 t03 方案）
第 4 周	LearningOS Phase 0：最小可运行原型	FSRS 调度引擎 + 极简 CLI 界面，可以录入和复习 5 张卡片

月度逻辑：前两周集中在 Facade（可独立推进）和 Vyane（解除阻塞），后两周开始 LearningOS 的最小原型。ai-gateway 保持维护状态不加投入。Yi 保持当前形态，自研 IM 本月不启动。

5.5 不建议本月做的事

项目	不建议做的事	理由
自研 IM	启动任何开发	依赖 MER-267/268/269（LogicalSession 分层），Vyane 的深水议题本月解决不了
Yi	大改身份/性格定义	Yi 的身份定义已经稳定，不需要反复调整
Vyane	新增 adapter 或 MCP 工具	当前 8 adapter + 14 工具已经够用，本月应该聚焦可靠性而非功能
ai-gateway	超出账号扩容的任何开发	已经功能完整，不需要投入
LearningOS	全栈开发	先用 CLI 原型验证 FSRS 调度的手感，前端在后面

6. 证据与不确定性

6.1 证据来源

信息类型	来源	可靠性
各产品定位和边界	`meridian-personal-first-plan.md`、各项目 CLAUDE.md	高——Maple 本人确认的规划文档
Vyane 技术状态	`vyane/CLAUDE.md`、v0.30.1 代码	高——代码级证据
Yi 身份和状态	`agents/yi/SOUL.md`、`IDENTITY.md`	高——活跃维护
Facade 技术栈	`facade-tech-stack.md`、t02 调研报告	高——近期调研
LearningOS 设计	`project_learning_system_design.md`、campaign 调研报告	中——设计文档，未经实现验证
Maple 认知风格	`user_cognitive_profile.md`	中——自我报告 + AI 观察，未经专业测评

6.2 关键不确定性

Vyane webhook 生产验证的实际工作量：文档说"代码已到位，需要配置和验证"，但生产环境的坑往往比代码本身更多。实际可能需要 2-5 天而非 1-2 天。
Facade 选型的决策成本：从 107 个原型中选一个听起来简单，但对于 Ne 主导的决策者来说，"做减法"可能比"做加法"更消耗能量。如果选型卡住，可能需要外部约束（如设定截止日期、让 AI 先推荐 3 个）来推动。
LearningOS 的 FSRS 集成复杂度：调研报告对 FSRS v6 和 ts-fsrs 库的评估偏乐观。实际集成到自研系统中可能遇到边缘情况（调度精度、冷启动、参数调优）需要更多迭代。
Maple 的可用时间：以上所有建议假设 Maple 有足够的个人时间投入。招行的借调工作可能随时占据大量注意力，导致个人项目进度放缓。
"暂停开发、理解优先"的原则是否仍然适用：这条原则定于 2026-04-09。到 5 月 1 日已经过去三周多，期间积累了大量调研。如果 Maple 认为理解阶段已经足够，可以转入执行阶段——但这个判断只能由 Maple 自己做。

6.3 建议的后续研究

Facade 选型辅助：从 107 个原型中按 3-5 个维度（排版质量、暗色适配、移动端体验、内容区域比例、独特性）做量化筛选，缩小候选到 5 个以内
Vyane 生产部署检查清单：列出从 shadow mode 到 production mode 的所有必要步骤和验证项
LearningOS 最小原型技术栈评估：CLI-first（Python/Rust）vs Web-first（Astro 复用）的取舍分析