smol.ai

Smol.ai 是一个把团队文件、对话和项目进度放在同一个“团队云盘”里的协作工具，官方把它概括为“Slack 和 Google Drive 的结合体”。它适合需要频繁交接文件、又不想让讨论散落在聊天软件里的团队，尤其是播客、视频等以“原始素材 + 修改版本 + 反馈”为核心的项目。使用方式有两种：Mac 客户端（Apple Silicon、macOS 12 及以上）和网页版，均通过 Google 账号登录。

它解决什么问题

传统做法是文件放在 Google Drive 或 Dropbox，讨论放在 Slack，项目状态记在别处。交接时，接手的人要分别打开三个地方，才能拼出完整上下文。Smol 的做法是让每个文件夹自带聊天，把文件、对话、负责人和状态放在同一处。

官方用一个播客交接场景说明：一集节目有 1 个 MOV、1 个 WAV 和 6 张缩略图，剪辑师要原始素材，同事要引用某句话，所有人要知道下一步做什么。在 Smol 里，这些内容都落在同一个“单集文件夹”中。

主要能力

文件与对话合一

• 支持嵌套文件夹，每个文件夹内有持续聊天
• 可设置负责人（owner）和状态
• 可在其中撰写文档、审阅修订、分享稳定链接

带来源的搜索

• 搜索范围覆盖文件、消息和已处理的内容
• 支持转录（transcripts）、OCR 和针对文件内容提问，并给出引用来源
• 适合“找到那句话，再核对出处”的场景

上传与预览的容错

• 上传中断后，重新选择原文件即可续传
• 导入和预览尚未完成时，已完成的文件可以先使用

与其他云盘的定位差异

官网给出了三方对比，核心差异在“交接”和“找答案”两件事上：

需要说明的是，Smol 的定价在页面上标注为“Planned pricing · storage at cost”，即规划中的按存储成本计费，示例为 230 GB 用量、3 人团队约 $3.45/月。这属于尚未落地的方案，实际价格以官方后续公布为准。Google Drive 和 Dropbox 的数字来自同一对比表，属于其订阅方案。

适合谁，不适合谁

较适合：

• 项目以文件交接为主线，且交接必须带上下文（播客、视频、设计审阅）
• 团队规模小、存储用量明确，希望只为实际存储付费
• 已经在用 Google 账号，能接受 Mac 或网页端

可能不适合：

• 需要 Windows 客户端或移动端深度使用的团队（页面只提到 Mac 与网页）
• 需要成熟企业权限体系、合规审计的大型组织
• 现在就要求确定价格和 SLA 的采购决策

上手路径

1. 用 Google 账号登录网页版，或下载 Mac 客户端（确认芯片为 Apple Silicon、系统为 macOS 12+）
2. 建一个项目文件夹，把原始素材和修改版本放进去
3. 在文件夹内开聊天，指定负责人和当前状态
4. 用搜索或文件提问定位内容，核对引用来源
5. 交接时直接分享该文件夹的稳定链接

常见卡点有两个：一是大文件导入和预览需要时间，期间可先用已完成的部分；二是上传中断后必须重新选中同一个原文件才能续传，换文件不会接上。

Smol.ai 对上传中断的处理方式是：重新选择原文件后，未完成的上传可以继续，不必从头开始。在大文件导入和预览仍在处理时，已经完成的文件可以正常使用。官网把单文件大文件上限配置为 25 GiB，因此适合录音、视频等大体积项目素材的交接。这些能力来自官网的功能说明和对比表；实际续传效果取决于网络和文件本身，官网未给出成功率或速度承诺。

上传中断后怎么续传

前提：使用 Mac 客户端或网页版，并已通过 Google 账号登录；中断前上传的是同一个原始文件。

1. 上传中断后，回到原来的项目文件夹。
2. 重新选择中断前的那份原文件，不要改名、不要换成本地转码后的副本。
3. 等待客户端识别已有进度并继续上传。

预期结果：已上传部分被复用，上传从断点继续。常见卡点有两个：一是选了不同的文件（例如重新导出过的版本），系统无法对应；二是网络反复中断，需要多次重试。

导入和预览处理期间能做什么

Smol 的设计是让已完成的文件先可用，导入和预览在后台继续。也就是说，一个项目里多个大文件同时进来时，先传完的文件可以先打开、先分享，不必等整批处理完。

例如播客交接场景：一集节目有 1 个 MOV、1 个 WAV 和 6 张缩略图。剪辑师需要原始素材，同事需要引用片段，大家还要知道下一步做什么。先完成的文件可以先进入使用，聊天和状态在同一文件夹里同步推进。

大文件上限与适用场景

官网对比表列出 Smol 的“Large originals”为 25 GiB configured per file，即单文件可配置到 25 GiB。这个量级覆盖多数播客原始录音和较长视频素材。

需要注意：25 GiB 是配置值，不是每个账户的默认承诺；实际可用空间与存储方案有关。官网提到“Planned pricing · storage at cost”，即按存储用量计费，但未公布具体价格和免费额度，不能据此推断免费或无需登录。

和其他网盘相比的差异点

在官网对比中，Google Drive 和 Dropbox 的大文件上限分别标为 5 TB per file 和 350 GB web / 2 TB desktop，单文件容量远高于 Smol。但 Smol 的差异不在单文件大小，而在“文件 + 对话 + 负责人 + 状态”放在同一个项目文件夹里，交接时上下文不丢。

选择条件可以这样判断：

• 如果核心需求是超大单文件（数百 GB 以上）的存储和同步，传统网盘更合适。
• 如果核心需求是项目交接时把素材、讨论、引用来源和下一步放在一起，Smol 更贴合。
• 如果上传环境不稳定、经常中断，续传能力是优先考虑项，建议先用一个中等大小文件实测再决定。

Smol.ai 的核心差异是把“文件、对话、负责人、下一步状态”收进同一个项目文件夹，而不是让文件留在网盘、讨论散在聊天工具里。它更适合需要反复交接的创作型项目，例如播客、视频、设计评审；如果你只需要大容量同步和成熟的办公套件，Google Drive 或 Dropbox 仍是更稳妥的选择。以下对比基于官网展示的示例与说明，并非独立基准测试。

三者各自把“交接”放在哪里

Smol 的定位是“Slack 和 Google Drive 的结合体”：每个文件夹自带聊天，项目里有嵌套文件夹、负责人和状态，文档可写、修订可评、链接可分享。官网用一个播客交接场景说明问题：一集节目有 1 个 MOV、1 个 WAV、6 张缩略图，剪辑师要原始素材，队友要一句引用，所有人都要知道下一步做什么——Smol 的做法是让这些内容留在同一个“剧集文件夹”里。

Google Drive 和 Dropbox 的处理方式不同：

表中价格与容量均来自官网对比区展示的示例数字，实际以你选定的方案为准。

找资料时，差别在“能不能核对来源”

Smol 强调的不只是搜索，而是对已处理内容（转录、OCR）提问并给出带来源引用的答案。对交接场景这意味着：队友问“这句话原话是什么”，答案能指回具体文件或片段，而不是只给一段无法追溯的摘要。Google Drive 一侧依赖 Gemini 与办公套件，Dropbox 一侧提供搜索、转录和 AI 集成——三者都能找，但 Smol 把“引用出处”作为明确卖点。

上传与预览的容错

Smol 官网提到两点容易被忽略的细节：重新选择原文件后可以续传中断的上传；导入和预览还在处理时，已完成的文件可以先使用。对动辄几个 GB 的录音、视频素材，这比“传完才能干活”更贴近真实交接节奏。官网还给出一个示意性对比：1 GiB 文件上传约快 2 倍，属于说明性比较，不是基准测试结论。

怎么选

• 选 Smol：项目以文件夹为单位反复交接，素材大、参与人多，且你希望对话和状态不离开文件；能接受 Mac 客户端（Apple Silicon、macOS 12+、Google 登录）或网页版。
• 选 Google Drive：团队已经在 Workspace 生态里，需要池化大容量和完整办公套件，交接靠评论和 Chat 就够。
• 选 Dropbox：核心需求是稳定同步加创意审阅（Replay），对“文件夹内聊天 + 状态”没有强需求。

一个可操作的判断方法：拿你最近一次真实交接，数一数“文件在哪、讨论在哪、谁负责、下一步是什么”分别散落在几个工具里。超过两个，Smol 的整合方式值得试；只有一个，换工具收益有限。

Smol.ai 把“找原话”和“核对出处”放在同一条搜索链路里：你可以搜索文件、文件夹内的聊天消息，以及系统处理过的内容（如转录文本、OCR 识别出的文字），提问后得到的回答会附带来源引用，方便回到原文核对。它适合需要从录音、文档或团队对话中定位具体表述并确认出处的场景，例如播客制作中的素材交接。前提是相关内容已进入 Smol 的项目文件夹，且文件已完成或正在进行转录、OCR 等处理；处理未完成时，可先用已完成的部分。

搜索覆盖哪些内容

根据网站说明，Smol 的搜索范围包括三类对象：

• 文件：项目文件夹中的录音、视频、图片、文档等。
• 消息：每个文件夹内持续的聊天记录，包括反馈、决定和下一步安排。
• 已处理内容：转录文本、OCR 识别结果，以及针对文件内容提出的问题。

这意味着你不必先想起“那句话在哪个文件里”，可以直接按内容线索搜索，再顺着引用回到原始文件或对话。

从提问到拿到引用：具体怎么用

1. 把材料放进项目文件夹。Smol 以“团队网盘 + 每个文件夹一个聊天”的方式组织内容，文件与围绕它的讨论在同一处。网站给出的典型场景是一集播客：一个 MOV、一个 WAV、六张缩略图，分属编辑、引用和交接等不同需求。
2. 等待或确认内容被处理。转录、OCR 和文件问答依赖内容处理；网站提到可以在导入和预览继续进行时使用已完成的文件，说明处理是分步完成的。
3. 用自然语言提问或输入关键词。例如“编辑提到原始素材的那句话在哪”“这版缩略图的反馈是什么”。
4. 查看回答附带的来源引用。回答会标注引用的文件或消息来源，点击或对照引用即可核对原文，而不是只相信一段概括。
5. 回到文件夹继续协作。确认出处后，可在同一文件夹的聊天中回复、更新状态或安排下一步，文件、对话和进度不会分散在多个工具里。

验证是否找对了

核对时重点看两件事：引用指向的是原始文件还是转录文本；引用片段与你记忆中的表述是否一致。若引用来自转录，遇到同音词或专有名词时，回到音视频原文件复核更稳妥。

一个贴切的例子

网站描述的真实交接场景是：归档里有一个 MOV、一个 WAV 和六张缩略图。编辑需要原始素材，队友需要一句可引用的原话，所有人都要知道下一步做什么。在 Smol 中，这些需求可以在同一个“单集文件夹”里完成——文件、对话、转录与来源引用、负责人和状态放在一起，找原话时直接搜索并查看引用，而不必在网盘和聊天工具之间来回切换。网站明确说明这类对比是工作流示意，不是应用切换的性能基准。

适用条件与边界

• 适合：项目制团队，尤其是需要频繁引用录音、视频或文档原话，并要求可追溯出处的播客、内容制作和创意交接场景。
• 依赖处理进度：转录、OCR 和文件问答的效果取决于内容是否已被处理；大文件导入期间，部分内容可能尚不可搜索。
• 不是纯存储工具：网站将自身定位为“文件 + 对话 + 处理”的一体化团队网盘，并称处理属于存储之外的额外能力；如果你只需要同步文件，传统网盘更直接。
• 平台限制：Mac 版为 beta，要求 Apple Silicon、macOS 12 及以上，并使用 Google 登录；也可通过网页版使用。
• 价格：网站展示的是“计划中的定价、按成本转嫁存储”的示意（如 230 GB 约 $3.45/月），并非已生效的正式报价，实际费用需以官方后续公布为准。

Smol.ai 目前展示的是计划中的定价，核心思路是“存储按实际用量计费”（storage passthrough），而不是按人头卖套餐。官网示例中，一个 3 人团队使用 230 GB 存储，存储费用估算约为 $3.45/月；但同一处也注明“Storage only; processing extra”，即这个数字只覆盖存储，转录、OCR 等处理能力可能另计。因此它更适合以项目交接为核心、希望文件和对话放在一起的小团队，而不是只需要网盘同步的团队。

定价结构：你实际在为什么付费

根据官网对比表，Smol 的费用可以拆成两层：

官网还提到“Pay for the storage you use. Plans adjust to fit your archive.”，说明套餐会随归档规模调整，而不是固定档位。需要注意：页面标注为“Planned pricing”，即这是规划中的价格，不是已生效的正式报价；具体计费方式、处理功能如何收费，官网未给出细节。

和 Google Drive、Dropbox 的计费对比

官网对比表把三者放在同一组维度下，但计费逻辑完全不同：

这张表的关键信息不是“谁更便宜”，而是计费锚点不同：Google Drive 和 Dropbox 按人头收固定订阅费，Smol 把成本锚定在存储量上。团队人数多、存储用量小的场景，按人头计费可能更可预测；人数少但素材体积大（例如播客原始录音）的场景，按用量计费的结构更贴近实际消耗。不过 Smol 的处理功能若额外收费，总成本需要把两部分加在一起看，官网目前没有给出这部分价格。

它把“项目交接”做进了产品结构

官网的定位是“Slack 和 Google Drive 的结合体”：每个文件夹自带聊天，文件、对话、负责人和状态放在同一处。官网用一个播客交接场景说明问题：一集节目有 1 个 MOV、1 个 WAV、6 张缩略图，编辑要原始素材，同事要引用片段，所有人要知道下一步做什么——传统做法是 Google Drive/Dropbox 放文件、Slack 放反馈和决策、项目笔记另记负责人，信息分散在三处。

Smol 的对应能力包括：

• 嵌套文件夹 + 持续聊天 + 负责人和状态：项目上下文不离开文件夹。
• 搜索文件、消息和已处理内容：转录、OCR、文件问答带来源引用，方便核对原话出处。
• 断点续传：重新选择原文件后可恢复中断的上传；导入和预览未完成时也能使用已完成的文件。
• 上传速度：官网称自适应上传约为传统云盘的 2 倍（1 GiB 示例对比，属说明性比较）。

这些能力决定了它的适用边界：如果你需要的是“文件 + 对话 + 交接状态”同处一地，它的结构是匹配的；如果你只需要同步和分享文件，这些功能就是多余成本。

适合与不适合的团队

较适合：

• 3 人左右的小团队或项目组，素材体积中等（示例为 230 GB 级别）。
• 播客、视频、设计等有“原始文件 → 修改 → 反馈 → 交接”链路的创作型项目。
• 经常需要从长录音、扫描件里找原话并核对来源的团队。
• 希望存储成本随归档增长平滑变化，而不是按席位扩张的团队。

不太适合：

• 只需要网盘同步、不需要对话和状态管理的团队——按人头订阅的成熟方案更直接。
• 对处理功能（转录、OCR）有强需求、且需要先确认这部分价格的团队——官网尚未公布，需向官方确认。
• 需要成熟企业权限体系和大规模协作的组织——官网对比对象是 Google Workspace 和 Dropbox 的标准版，未展示企业级治理能力。
• 非 Mac 用户需注意：官网提供 Mac 下载（Apple Silicon、macOS 12+、Google 登录）和网页版入口，桌面端目前是 Mac beta。

决策前的核对清单

1. 估算团队当前归档体积，按官网示例的单价结构粗算存储成本。
2. 明确你是否需要转录、OCR、带引用问答；若需要，先确认这部分是否额外收费及价格。
3. 确认团队设备环境：Mac 桌面端为 beta，其他场景走网页版。
4. 由于是计划中定价，正式购买前以官网当时页面为准，不把示例金额当作报价。