NVivo 15 跨平台协作：2026 项目交付清单

项目已经交到导师手里，所有人都能打开 NVivo 15，但 Mac 端看不到部分分析项，音视频和外部附件也无法定位。

最快解法：不要把项目在 Windows 与 Mac 之间反复手工转换；先指定唯一主项目平台、统一主要版本，再用脱敏副本完成一次跨平台试交付。需要 Windows 完整功能时，以 Windows 为主，Mac 只执行已验收的任务。

SECTION 01谁该看这份 NVivo 15 Windows Mac 协作清单？

这份清单适合跨校、跨实验室开展质性研究的课题组成员，尤其是使用 Mac 编码、由 Windows 用户负责汇总和论文交付的研究生与博士生。

如果你负责高校软件部署、项目归档、许可证安排或数据安全审核，也可以把下面的时间轴直接改成课题组的交付流程。

最后更新于 2026 年 8 月 29 日，项目格式、平台差异与版本信息核实自 NVivo／Lumivero 官方帮助文档及官方版本资料。NVivo 15 后续小版本如果改变功能对齐或协作规则，应在放行前重新复核。

SECTION 02立项时先把主项目和平台边界写下来

NVivo Windows 与 Mac 使用不同的项目文件格式：Windows 项目通常是 .nvp，Mac 项目通常是 .nvpx。官方说明两端可以转换，但不建议把转换作为持续工作流；如果课题组需要跨平台工作，官方建议把 Windows 版本作为主项目，并在那里导入数据。参考官方跨平台项目转换说明。

这意味着你在课题启动阶段就要做出一个决定，而不是等到论文交付前再讨论：

• 需要完整查询、报告、关系分析或复杂协作功能：Windows 作为主项目平台。
• Mac 用户主要负责阅读、基础编码、备忘录或经过验证的批注：可以把 Mac 作为受控工作端。
• 两端都要轮流执行复杂分析：先暂停正式编码，完成样例项目验证；验证不通过，就不要扩大跨平台范围。
• 课题组没有明确负责人、合并入口和恢复方式：暂时不要让多人各自复制项目继续工作。

建议在项目说明文件中记录以下信息：

• 主项目文件名、保存位置和负责人。
• 每位成员的操作系统与 NVivo 主要版本。
• 每个人可以访问的资料范围。
• 哪些任务必须回到主平台执行。
• 禁止直接覆盖主项目、删除隐藏项目元素或从未验收副本继续派生。

注意：“Mac 能打开项目”只证明文件可以被载入，不代表所有代码、查询、媒体、链接和报告功能都能在 Mac 端继续使用。转换后的不可见项目元素不应直接判断为已删除；官方说明，部分不支持的元素只是被隐藏，转换回 Windows 后可能重新出现。

SECTION 03首次导入前建立文件与版本基线

跨平台交付最容易被忽略的不是项目本身，而是项目外部依赖。NVivo 可以使用外部文件、未嵌入的音视频、文档中的文件超链接和备忘录中的链接；这些路径会受到 Windows 与 macOS 文件系统差异影响。官方转换说明明确要求，项目转换后需要更新文件链接，否则可能无法访问关联文件。

正式导入前，按下面顺序准备：

1. 冻结原始资料。 将原始访谈、音频、视频、图片、PDF、转录文本和外部附件集中存档，原始目录设置为只读。
2. 复制主项目。 在主项目平台中执行复制或另存为，所有转换都针对副本完成，不能直接覆盖唯一项目。
3. 核对主要版本。 记录每台设备安装的 NVivo 主要版本和小版本；不要只看应用名称相同就认为项目完全兼容。
4. 整理文件清单。 为每个项目文件、附件、媒体和外部链接记录文件名、相对用途、当前路径和是否嵌入项目。
5. 标记高风险内容。 重点圈出外部音视频、复杂表格、嵌入图片、文档内超链接、查询、报告和依赖特定功能的分析对象。
6. 生成校验记录。 记录项目文件大小、附件数量、关键代码数量、备忘录数量、代表性查询名称和预期导出结果。这里的数字必须来自你自己的项目清单，不要套用网上的典型值。

关于项目文件和外部资料的区别，可以参考NVivo 官方文件类型说明。它特别提醒，无法直接导入的资料可能需要作为外部文件保存，并通过路径关联原始文件。

SECTION 04试转换不是演示，而是一次小型验收

试转换应使用脱敏项目，至少包含以下元素：

• 一组文本或 PDF 资料。
• 已建立的代码层级和部分编码。
• 备忘录或项目日志。
• 一个查询及其预期结果。
• 一段音频或视频及其转录。
• 一个外部文件链接或文档内超链接。
• 一张包含图片或复杂排版的代表性资料。

Windows 到 Mac 的转换，应在 Windows 端通过复制项目生成 Mac 格式副本；Mac 到 Windows 则应在 Windows 端打开 Mac 项目并保存转换后的副本。具体操作入口和格式限制，应以你安装版本对应的官方转换步骤为准。

试转换完成后，不要只检查“项目是否打开”，而要逐项记录：

不要把所有平台差异都当成数据损坏。官方资料指出，Mac 端可能不会显示 Windows 端创建的某些项目元素；同时，编码覆盖率显示也可能因为空格处理方式不同而出现差异。你的验收记录应区分“数据丢失”“功能暂不可用”“界面隐藏”和“结果显示差异”四种情况。

SECTION 05正式编码阶段只放行已验证任务

完成试转换后，安排两端成员对同一小批脱敏资料执行相同或相近的编码任务。不要直接把整套访谈资料交给 Mac 用户，否则一旦发现问题，你很难判断是转换、路径、版本还是操作方式造成的。

建议按照以下证据核对：

• 代码层级是否一致，父子代码和名称有没有变化。
• 同一段文字的编码范围是否一致。
• 代码注释、备忘录和研究日志是否仍然可见。
• 样例查询是否能运行，结果是否能解释。
• 音频和视频能否打开，并能否跳转到已标记片段。
• 含复杂表格、图片或嵌入对象的资料是否正常显示。
• 外部文件是否能从项目内直接访问。
• 交付后的导出文件能否被导师或数据管理员重新打开。

如果关键分析只能在 Windows 端执行，就立即收窄 Mac 用户的任务范围。比较稳妥的分工是：Mac 端负责经过验收的阅读、基础编码、备忘录和资料初筛；Windows 主项目负责复杂查询、报告、阶段合并、最终导出和论文引用结果复核。

NVivo 的导出功能也应纳入验收，而不是等论文完成后才尝试。官方文档列出了文档、PDF、数据集、音频、视频、图片及转录内容的不同导出方式，可参考NVivo 官方导出说明。如果某类结果必须由 Windows 导出，就把它写入交付规则，而不是默认 Mac 端也能完成。

SECTION 06阶段合并与最终归档的控制点

跨平台项目最危险的阶段通常不是第一次转换，而是多人完成不同副本后准备合并。你需要提前规定：

• 谁可以创建交换副本。
• 交换副本采用什么命名方式。
• 谁负责检查编码和备忘录。
• 什么时候提交，什么时候冻结。
• 哪个文件是主项目，哪个文件只是临时副本。
• 合并后由谁重新运行关键查询。
• 任何成员是否有权直接覆盖主项目。

如果学校已经部署了官方协作服务或集中式项目管理方案，应先核对账号、许可、数据存储位置和管理员权限。官方新建项目文档说明，项目可以保存为本地项目或网络位置，也可以在具备权限和连接条件时创建协作服务器项目；但网络位置、缓存、本地副本和权限规则不能凭经验推断，必须结合学校实际部署核实，参考NVivo 官方项目创建与协作服务器说明。

在没有经过学校审核的协作机制之前，不要把多个独立转换副本当作“自动同步”。手工合并适合受控交付，不适合每天双向来回交换。

阶段合并后，至少重新运行：

• 论文正文实际引用的查询。
• 用于生成表格或图表的分析任务。
• 代表性资料的编码覆盖检查。
• 关键备忘录和研究日志检查。
• 音视频及外部附件抽样访问。
• 论文需要的导出任务。

同时保存四类文件：主项目、交换副本、导出成果和版本说明。版本说明中要写清转换方向、执行人、使用版本、修改范围、已知限制和恢复步骤。

SECTION 07最终归档前的可勾选交付清单

下面这份清单适合在论文提交、阶段验收或跨校移交前使用。每一项都应留下文件、截图、日志或负责人记录，而不是只口头确认。

• [ ] 已指定唯一主项目平台和主项目负责人。
• [ ] 已记录所有成员的操作系统与 NVivo 主要版本。
• [ ] 已区分 .nvp 与 .nvpx 项目文件。
• [ ] 已保留只读原始项目和原始资料目录。
• [ ] 所有转换均基于副本执行，未覆盖唯一主项目。
• [ ] 已完成一次脱敏项目的 Windows 到 Mac 或 Mac 到 Windows 试转换。
• [ ] 已核对代码结构、编码范围和备忘录内容。
• [ ] 已核对查询、报告、图表和导出任务的可用性。
• [ ] 已测试外部文件、音视频和文档内超链接。
• [ ] 已记录隐藏项目元素、功能限制和必须回到主平台的任务。
• [ ] 已用同一批样例资料完成两端试编码对照。
• [ ] 已规定交换副本命名、提交、冻结、合并和备份节奏。
• [ ] 已重新运行论文实际引用的查询和导出任务。
• [ ] 已保存主项目、交换副本、导出结果、版本说明和恢复步骤。
• [ ] 已确认后续审稿或复核不依赖某一位成员的个人电脑。

如果你还需要确认 Mac 端当前版本是否具备某项新能力，应查看对应版本资料，而不是沿用旧经验。比如 Lumivero 在 NVivo 15.3 官方发布说明中提到，Framework Matrix 已加入 Mac 版本，同时部分 AI 摘要能力可在 Windows 与 Mac 使用；这类变化说明平台差异会随着小版本更新，不能把旧版清单永久当作结论。参考NVivo 15.3 官方版本说明。

如果课题组只有一名 Mac 用户，或者实验室暂时没有 Mac，不必为了完成一次兼容性验证立即采购设备。你可以先准备一台具备独立权限的远程 Mac，在论文周期内用脱敏项目完成接收、附件定位、样例编码、查询复核和导出验收，再决定长期采用 Windows 单平台、Mac 单平台还是受控双轨环境；需要了解 MACNOX 的远程 Mac 使用方式，可先查看科研场景下的 Mac 远程环境和套餐与租赁方案。

与直接让 Mac 用户反复转换项目相比，远程 Mac 方案的价值不在于把所有任务都搬到另一端，而在于给你一个独立、可撤销、便于验收的接收环境。自购设备会带来一次性采购、许可证迁移和后续维护成本；实验室共用电脑又容易出现账号混用、文件残留和版本不一致。若你只需要在交付前验证一次，或只在论文阶段临时使用 Mac，先租赁一台具备独立权限的远程 Mac，通常比为单次验收新增实体设备更容易控制范围；但如果你长期运行高强度分析、需要本地外设或必须遵守学校的物理隔离要求，仍应优先采用学校批准的本地设备或集中式环境。

SECTION 08常见问题 FAQ