真实分布口径
先看 997 skills 的一级来源分布
这部分是唯一按 不重复加总 统计的口径。也就是说，下面四组的数量相加，刚好等于 997。它回答的是“这些 skills 从哪里来”。
Skills Distribution Atlas
997 个 skills 是怎么分布的，为什么平台必须要有这么多
MedRoundTable 不是把一个模型包成聊天框，而是把医学科研从问题识别、文献回顾、研究设计、数据准备、分析执行到最终交付拆成可调用的最小能力单元。这个页面先给你看真实分布，再解释为什么少了这些原子能力，14 位专家就只能“会说”，无法“把事情做完”。
Skills
997
真实技能总量
Agents
14
专家协作入口
Integrations
5
外部整合层
Lanes
14
执行链路
一句话解释
为什么不是 20 个大功能，而是 997 个 skills
因为医学科研不是一句“帮我做个方案”就能完成。它背后至少要拆成：证据检索、纳排标准、终点定义、样本量、CRF 字段、数据库路由、质控、图表表达、导出、审查等大量可执行动作。
如果这些动作不被拆成 skill，14 位专家只能发表意见；一旦拆成 skill，他们就能按角色调用具体能力，把讨论推进成真实交付。
OpenClaw 官方口径
869 个 OpenClaw Medical Skills 的官方 8 大类分布
这部分单独回答 OpenClaw 包装层的真实结构。MedRoundTable 里最大的 skill 来源就是 OpenClaw Medical Skills Wrapper，这里按 OpenClaw 官方当前公开 README 的 8 大类口径展示。
口径说明
我们平台和 OpenClaw 的关系
第一层：平台总量是 997，这是 MedRoundTable 完整口径。
第二层：其中最大的一层是 869 个 OpenClaw Medical Skills，我们把它们包装成 MedRoundTable 可调用的技能表面。
第三层：前台不会把 869 个技能逐条堆给用户，而是继续按 14 位专家、14 条能力链路、数据库入口和交付物 重排成真正能用的工作台。
执行工作流
这些 skills 被如何动员到科研流程里
这里不是再把 997 做一次加总，而是展示平台如何把这些能力映射进真实工作流。一个 skill 可能服务多个阶段，所以这部分是 执行映射口径，不是新的总数。
入口
研究问题
从一句临床问题进入，系统先判断需要证据扫描、方案设计还是多组学 / 数据分析支撑。
编排
14 位专家
临床、文献、流调、统计、生信、数据工程和质量门禁分别调度各自的能力面。
执行
14 条能力链路
证据合成、试验设计、数据库织网、AI 建模、多组学、诊断推理、自动研究闭环等在此接力。
交付
方案与报告
最终收敛为研究方案、证据清单、统计计划、图表、Word 纪要和 PPT 汇报材料。
专家调度
14 位专家如何分摊这 997 个 skills
平台不是让每位专家都“会一点点”，而是给每个角色分配稳定的主责能力面。下面按三层团队展示每组常调用的 skill 面和典型交付物。
为什么必须很多
如果 skill 数量太少，平台会在哪些地方失效
前台可见性对照
这些公开数据库和工具，现在在平台前台处于什么状态
这里专门避免混淆“底层已接入”和“用户已经能在前台明确看到”。我把它拆成三类：已接入且已展示、已接入但未单独展示、尚未单独包装展示。
优先接入仓库
这 4 个仓库最适合继续把平台做实
这 4 个仓库不是“看起来相关”，而是分别落在中文文献回顾、生物医学文本挖掘、多组学分析和自动科研交付这 4 条最关键的执行链路上。
平台回答
一句话说清楚为什么平台要有 997 个 skills
因为 MedRoundTable 想做的不是“回答一个医学问题”，而是把一个医学研究项目从想法推进到交付。要做到这件事，就必须把文献、设计、数据库、分析、合规、导出这些动作拆成大量可复用、可调度、可审查的 skill，14 位专家才能真正接力完成工作，而不是只给概念性建议。
下一步入口