实验室里常见的症状是：一名成员在 Mac 上完成了编码，另一名成员又从 Windows 打开旧副本，最后没人能确认哪一版才是主项目。
最快的判断是：ATLAS.ti 26 Project Cloud 适合个人跨设备续作和非同步共享，但不应当当作多人同时编辑同一项目的协作空间。 需要实时编码时优先评估 ATLAS.ti Web；需要桌面分析、项目合并或编码者一致性检验时，应建立唯一主项目，再用桌面版分发与合并。
最后更新于 2026 年 9 月 7 日。本文核实自 ATLAS.ti 26 Mac 官方手册 26.1.1+34607、Project Cloud、Project Transfer、Team Work、Project Merge 与一致性分析文档。(ATLAS.ti 26 Mac 官方手册)
这篇内容适合三类人：
- 质性研究课题负责人：需要为多人编码建立主项目、权限和交付规则。
- 研究生与编码员：需要在 Mac 与 Windows 之间安全接续项目，避免覆盖新版本。
- 高校技术支持人员：需要评估远程 Mac、账号许可、数据存储和桌面版部署边界。
[ SECTION_01 ] 先把四条路线分开：同步、合并和远程桌面不是一回事
Project Cloud、ATLAS.ti Web、桌面项目包合并和远程 Mac 桌面版，解决的是四种不同问题。把它们都叫“云协作”，是项目出错的起点。
| 路线 | 更适合的场景 | 主要限制 | 初步评分 |
|---|---|---|---|
| Project Cloud | 同一研究者在 Mac 与 Windows 间续作；向成员发送独立副本 | 不适合两台设备同时编辑；桌面项目与 Web 项目当前不可见 | 个人续作：★★★★★ |
| ATLAS.ti Web | 多人需要在浏览器中对同一项目进行实时协作 | 桌面版专属分析、格式和项目转移边界需单独验证 | 实时协作：★★★★☆ |
| 桌面项目包合并 | 异步分工、编码者一致性检验、统一主项目 | 需要管理员回收、检查和合并；文档编辑不当会产生重复 | 正式研究流程：★★★★★ |
| 远程 Mac 桌面版 | 实验室没有 Mac，但必须验证 Mac 桌面版行为 | 依赖远程交互、许可证和数据传输；不自动解决团队流程 | Mac 验收：★★★★☆ |
这里的星级是本文基于官方限制制定的决策权重，不是 ATLAS.ti 官方评分。Project Cloud 当前标记为 Beta；官方说明项目主要保存在本地，上传后才进入云端，并且不用于两台设备同时编辑同一项目。(Project Cloud 官方说明)
[ SECTION_02 ] 个人跨设备续作：Project Cloud 可以用，但必须保持单线程
如果只有一个研究者在 Mac 与 Windows 之间切换，Project Cloud 的价值比较明确：项目可以从一台设备上传，再在另一台设备下载继续工作。项目状态会区分“本机更新”“云端更新”和“版本同步”。
通过标准只有三个：
- 开始工作前，确认当前设备拿到最新版本。
- 结束工作后，完成上传，并确认上传状态已经更新。
- 另一台设备没有同时打开并修改同一项目。
官方手册明确提醒，云端版本更新时，下一台设备必须先下载最新版本再继续；如果两台设备都有未上传修改，应立即停止继续编码。不要用“最后保存的一份”猜测正确版本，也不要把两个副本直接覆盖。
第一轮验收动作
准备一个不含真实受访者信息的项目副本，加入少量文本、代码、备忘录和编码片段，然后按以下顺序执行：
- 在 Windows 或 Mac 创建并上传项目。
- 在第二台设备查看项目状态，下载最新版本。
- 新增一条测试备忘录和一段测试编码。
- 上传修改后的项目。
- 回到第一台设备，确认必须先下载新版本。
- 检查备忘录、代码和编码是否仍然存在。
停止条件： 项目状态无法说明哪一版更新、下载后出现旧数据，或成员已经在不同副本上继续编码。此时应恢复到最后一个确认一致的版本，再重新分发。
ATLAS.ti 26 Mac 的系统要求包括 Intel 或 Apple Silicon Mac、至少 4 GB RAM 和 macOS 10.15 或更高版本；若使用较大的机器学习模型，官方建议至少 8 GB RAM。这只是能否运行软件的门槛，不代表远程交互或大型多媒体项目一定适合。(ATLAS.ti 26 Mac 系统要求)
[ SECTION_03 ] 小型课题组异步分工：唯一主项目比“大家都登录”更重要
当成员分别编码不同访谈、不同时间段或不同文档时，桌面版团队流程更容易控制。官方建议由项目管理员建立 Master project，再导出项目包；成员各自导入副本，完成编码后回传项目包，最后由管理员合并并重新分发新的主项目。(ATLAS.ti 团队工作流程)
课题组需要提前写清楚四项规则：
- 主项目归属： 只有一人负责建立、修改和发布主项目。
- 成员命名： 每名成员使用可识别的用户名或缩写。
- 文档范围： 每名成员只处理分配到的文档，避免重复编辑。
- 回收方式： 项目包要带成员名、轮次和日期，不能只叫“最终版”。
ATLAS.ti 会根据电脑登录信息建立用户账号。不同设备使用不同用户名时，合并后可能出现多个相似身份；因此，正式分发前应先检查 User Manager。用户身份会影响后续查看“谁完成了哪些编码”，也影响一致性检验的可读性。(ATLAS.ti 用户身份管理说明)
用一轮脱敏材料做验收
不要拿完整访谈库直接试错。先选取一轮脱敏材料，执行：
- 管理员建立主项目。
- 添加文档、初始代码和代码定义。
- 导出项目包并命名，例如“项目名_轮次_成员名”。
- 成员导入后只编码指定文档。
- 成员导出自己的项目包并回收。
- 管理员先检查，再执行 Merge。
- 检查文档数量、编码数量、备忘录、用户身份和冲突报告。
- 保存新的主项目快照，再决定是否进入下一轮。
官方团队文档特别提醒：如果成员编辑了同一份文档，后续可能无法按预期合并，文档会被重复保留。需要修改原始文档时，应由项目管理员在主项目中完成。
[ SECTION_04 ] 实时编码：不要把 Project Cloud 当作多人共编空间
如果课题负责人要求成员同时打开一个项目、即时看到彼此的编码，Project Cloud 不是合适的默认路线。官方明确说明，Project Cloud 的共享会创建独立副本，并不等于多人同时操作同一个项目实例。
此时可以评估 ATLAS.ti Web，但需要把 Web 和桌面版看作阶段性工作流，而不是无条件混用。官方 Project Transfer 文档建议，需要同步编码时从 Web 版本开始；如果要使用桌面版功能，则导出项目并导入桌面版。桌面项目转入 Web 后，文档格式可能发生变化，因此不适合建立一部分人使用桌面版、另一部分人使用 Web 的混合团队。(ATLAS.ti 项目转移文档)
适用判断：
- 实时讨论、共同标记和浏览器协作优先：先验证 ATLAS.ti Web。
- 桌面版分析、复杂项目管理或正式一致性检验优先：采用桌面主项目。
- 两者都要用：按阶段交付，先在一种环境完成一轮，再导出、检查和迁移。
- 需要边在 Web 编码、边在桌面版继续处理同一项目：先停止设计，做脱敏项目验证。
ATLAS.ti 26 的官方一致性分析文档还指出，编码者一致性检验需要从共同 Master project 开始，所有编码者都应使用桌面版 Mac 或 Windows；不能让其中一名编码者直接使用 Web 版本完成同一套 ICA 流程。(ATLAS.ti 编码者一致性说明)
[ SECTION_05 ] 项目合并与一致性检验：先保住实体身份，再谈统计结果
多人编码后怎样合并项目，关键不在“有没有一个 Merge 按钮”，而在于成员是否从同一个主项目复制出来。ATLAS.ti 的合并逻辑依赖实体 ID；如果成员从不同项目开始，即使文档名称和代码名称相同，也可能被当成不同实体处理。(ATLAS.ti 项目合并文档)
编码者一致性检验建议采用以下顺序：
- 负责人建立稳定的代码体系和定义。
- 从共同主项目导出两个或多个编码副本。
- 成员独立编码同一部分材料。
- 检查用户名、项目名称和文档范围。
- 先导入副本并查看内容，再进入合并。
- 设置 Intercoder Agreement Mode。
- 合并项目，查看同一引文上的编码者标识。
- 再执行一致性分析，不要只看合并是否成功。
Mac 官方文档说明，两个编码者的项目需要逐次合并；合并后可以在边栏查看不同编码者对同一引文的编码，并据此运行一致性分析。(ATLAS.ti Mac 合并与一致性分析)
通过标准：
- 文档没有重复。
- 编码者身份可以区分。
- 代码和引文实体没有成倍复制。
- 冲突报告能够解释。
- 一致性分析需要的文档、代码和编码全部存在。
停止条件：
- 成员分别重新导入了原始文档。
- 代码体系是从零建立，而不是来自共同主项目。
- 合并后出现大量重复文档。
- 用户身份全部显示为同一个人，无法追溯。
- 删除的代码或编码又在其他副本中出现。
需要注意的是，官方说明合并不能简单执行“减法”。某成员删除的代码或编码，如果仍存在于另一份项目中，合并后可能再次出现。
[ SECTION_06 ] 敏感访谈与大体积多媒体：先判断能不能进云端
Project Cloud 文档说明，云端项目使用端到端加密，并存储在欧洲服务器；Beta 期间每名用户有 500 MB 云端空间，视频等文件可能快速消耗空间。数据是否允许进入该环境，仍应由学校伦理审批、数据分类、受访者同意范围和适用的跨境要求共同决定，本文不替学校作法律结论。
验收时要区分两类资料：
- 项目内部文件： 文本、图片或已纳入项目包的资料，重点检查下载、导入和导出。
- 外部链接资料： 音频、视频或大型文件只保留路径，重点检查换设备后路径是否仍然可访问。
ATLAS.ti 官方文档说明，大型音视频可以作为链接资料处理，以节省项目空间；但这也意味着路径、权限和存储位置会成为额外故障点。
如果学校不批准云端存储，或换设备后多媒体链接无法稳定恢复，应保留本地桌面项目和受控传输路线。不要为了方便，把原始访谈材料复制到未经审核的个人空间。
[ SECTION_07 ] 实验室没有 Mac：用远程 Mac 验收桌面版，不要直接迁移正式数据
实验室以 Windows 或 Linux 为主时，远程 Mac 的价值不是替课题组自动完成协作，而是验证 Mac 桌面版是否确实满足研究流程。NOVAKVM 提供按周期使用的远程 Mac 环境，相关入口可以从 NOVAKVM 的远程 Mac 服务页面 查看；若需要比较不同地区节点，也可参考 M4 Mac 方案页面。
验收应使用脱敏样例，按以下步骤执行：
- 准备不包含真实姓名、联系方式和原始音视频的项目副本。
- 通过 VNC、SSH 或网页控制台进入远程 Mac。
- 启动 ATLAS.ti 26，检查账号和许可证状态。
- 下载或导入测试项目。
- 打开文档、代码、备忘录和分析视图。
- 完成一小段编码，并导出项目包或分析结果。
- 在现有 Windows 或 Linux 设备上重新导入成果。
- 退出 ATLAS.ti，清理测试文件、下载目录和临时缓存。
- 记录权限、交互、导入导出和退出清理是否通过。
许可证也是验收项。官方手册说明，首次激活需要联网；许可证过期后软件会进入受限状态，只能在一定规模内保存项目，且自动备份会受到限制。课题组不能只验证“软件能打开”，还要确认实际使用账号有可用许可。(ATLAS.ti 许可证激活说明)
[ SECTION_08 ] 两张表完成最终放行判断
| 研究需求 | 首选路线 | 必须验证的事项 | 不通过时的回退 |
|---|---|---|---|
| 一人在 Mac 与 Windows 之间继续编码 | Project Cloud | 最新版本提示、下载、上传、单设备编辑 | 回到最后一致版本，改用项目包 |
| 成员分别编码不同材料 | 桌面项目包合并 | 用户名、文档分工、项目包回收、合并报告 | 由管理员重新分发主项目 |
| 多人同时查看并编码 | ATLAS.ti Web | 同一项目可见性、浏览器操作、导出结果 | 改为阶段性交付 |
| 编码者一致性检验 | 桌面版 Master project | 共同主项目、独立副本、ICA 模式、编码者身份 | 重新建立副本，不在旧副本上补救 |
| 敏感访谈或大型音视频 | 本地受控桌面项目 | 学校审批、路径恢复、传输权限、只读原始副本 | 不上传云端，保留本地项目 |
| 没有 Mac 但需要桌面版验证 | 远程 Mac | 启动、许可证、项目下载、分析、导出、清理 | 采用 Windows 桌面版或 ATLAS.ti Web |
最小放行清单
- [ ] 已确认本轮使用的是 ATLAS.ti 26 官方支持的 Mac 或 Windows 版本。
- [ ] 已指定唯一主项目管理员。
- [ ] 已为每名成员设置可识别的用户身份。
- [ ] 已使用脱敏样例完成一次上传、下载或项目包导入。
- [ ] 已确认成员不会同时编辑同一份 Project Cloud 项目。
- [ ] 已明确每名成员负责的文档范围。
- [ ] 已禁止成员重新导入或修改管理员维护的原始文档。
- [ ] 已完成一次试合并，并检查重复文档和冲突报告。
- [ ] 已确认编码者一致性检验所需材料来自共同主项目。
- [ ] 已检查 Web 与桌面项目之间的导入、导出和格式变化。
- [ ] 已核对敏感资料的审批、存储和传输边界。
- [ ] 已在远程 Mac 上完成许可证、桌面分析、导出和退出清理验收。
- [ ] 已保留只读原始副本和合并前快照。
| 路线 | 适合度 | 关键风险 | 负责人应作出的决定 |
|---|---|---|---|
| Project Cloud | 个人续作 5/5；多人实时共编 1/5 | 旧版本覆盖、独立副本误解、Beta 变化 | 只允许单线程或异步分发 |
| ATLAS.ti Web | 实时协作 4/5；桌面 ICA 2/5 | Web 与桌面项目不可直接当作同一工作区 | 需要同步时优先 Web，分阶段迁移 |
| 桌面项目包合并 | 异步编码 5/5；操作便利 3/5 | 重复文档、身份混乱、冲突处理 | 建立唯一 Master project |
| 远程 Mac | 桌面版验收 4/5；长期大规模协作 3/5 | 许可证、交互、数据清理和网络依赖 | 先做脱敏验收，再决定是否长期部署 |
如果当前方案只是把 Windows、Linux 和个人电脑上的多个副本来回传递，真实缺点通常有三个：版本状态不透明、成员身份难以追溯、正式合并前缺少可重复的验收环节。直接购买一台 Mac 又会把一次性的桌面版验证，变成长期硬件、维护和闲置成本。
更稳妥的做法是先保留主项目规则，再用 NOVAKVM 的远程 Mac 完成一次脱敏项目验收。这样能在不立即购买实机的前提下，确认 ATLAS.ti Mac 版的许可证、项目下载、桌面分析、合并前准备和成果导出是否满足课题组流程。若后续是长期稳定重负载、需要本地物理接口或必须完全离线处理，购买并由学校管理 Mac 仍可能更合适；若只是临时验证、跨平台交付或短期缺少 Mac，按周期使用远程 Mac 通常更容易控制决策成本。