拷完 ≠ 校验完：免费开源的 macOS 素材备份工作台 Kocpy，以及它和 OffShoot、ShotPut、Silverstack 的对比

一个把"完成"这个词拆成七条定义的项目：从插卡到收工怎么用、功能全景、实现细节与验证工程，最后和同类工具比较功能、性能与价格。

项目入口：本站项目列表 · Kocpy 仓库 · 最新发布。本站项目卡片会打开对应仓库，下载、文档和问题反馈仍以仓库为准。

一、"拷完了"是最危险的三个字

拍摄收工的最后一个动作，往往是有人喊一句"拷完了"。

然后卡被格式化，硬盘被塞进背包，两天后剪辑那边说：少了一个文件，或者某个 MOV 解不开。

问题通常不在拷贝工具坏了，而在于我们对"完成"这个词的定义太宽松：文件管理器转完了进度条，只说明字节被写下去了；它没有说目的地上的内容和源一致，更没有说这份副本和另外几份物理上真的分散在不同的故障域里。

这正是 Kocpy 这个项目最较真的地方——它几乎把所有文档的篇幅都花在一件事上：把"完成"的每一种含义写清楚，并且只在证据到位时才显示绿色。

本篇六张截图均重新取自 macOS 版 v0.1.39，使用独立演示数据目录。素材是一段生成的测试视频、测试音频和两份拍摄记录，不含客户素材；备份实际执行并完成回读。两个目标都在同一块磁盘的临时目录里，这次演示不证明双盘、NAS 或现场设备已经验收，画面里的速度与用时也不作为性能跑分。

项目地址：

Repository · sexyfeifan

2

Kocpy

macOS 素材安全备份与项目归档工作台，支持多目标复制、回读校验、异常恢复与专业交付报告。

TypeScript

二、30 秒说清楚 Kocpy 是什么

一句话：Kocpy 是面向片场与工作室的 macOS 素材备份与项目归档工作台——本地优先、最多 4 个目的地、逐目的地独立回读校验、可追溯的项目记录。

拆开讲：

• 它不是剪辑软件，不做时间线、不做调色。
• 它也不是"历史绿色状态"的复读机：以前校验通过不等于现在健康，报告只代表它记录的那个时点。
• 它没有账号、不联网激活，默认数据落在 ~/Library/Application Support/Kocpy/，素材留在你自己选的源和目的地。
• 开源，MIT 许可，当前正式版 0.1.39，arm64 与 x64 两个 DMG，GitHub Releases 直接下载。
• 平台目前只有 macOS；构建与运行基于 Electron。

三条最常用的入口，官方文档把它摆在最前面：

普通备份不需要先建项目，这点很重要——很多工具逼你先搭一套目录结构才能干活，Kocpy 把门槛放到了"打开就能拷"。

三、它反复强调的七条"完成"定义

这是我认为最值得单独讲的部分，也是理解这个软件的关键：

1. 复制完成 ≠ 校验完成。 每个目的地必须独立回读并与哈希基准比对，才有内容验证证据。
2. 通过校验 ≠ 副本数量达标。 同一块盘上的两个文件夹、两个分区、两个不同 UUID，不必然物理独立；未知 RAID／NAS 关系不会自动帮你加一份独立副本。
3. 首次基线 ≠ 接管前完整。 它只记录接管那一刻存在的内容，不能证明此前没漏拷过文件。
4. 没有文件夹 ≠ 当天未使用设备。 空白单元保持"待确认"，"休息"或"未使用"的标记不能掩盖已记录素材的风险。
5. 刷新记录 ≠ 重新校验。 刷新只修正识别与重复统计，不重新读取全部内容哈希。
6. 历史通过 ≠ 永久健康。 长期保存必须重新读取归档盘复校验。
7. 每日交付 ≠ 新的完整备份。 它从已校验的完整卡派生并重新校验，但不增加素材卷、任务或物理独立副本数量。

前两条其实是 3-2-1 备份原则的现场版：三份副本、两种介质、一份异地。难点从来不是"复制三份"，而是如何证明第三份真的在另一个供电、另一个机箱、另一栋楼里。Kocpy 的做法是只认系统可见的存储拓扑——明确不同的底层磁盘才增加独立副本数，NAS、未知阵列、缺少拓扑的旧任务一律标成"证据不足"，而不是替你乐观推断。

顺带解释一个术语：文档里反复出现的 MHL（Media Hash List） 是影视行业通用的媒体哈希清单格式（ASC MHL 是其规范版本），记录每个文件的相对路径、大小和哈希。它的价值在于跨工具可比：别人的工具生成的清单，Kocpy 也能拿来逐条比对——这正是"接管既有备份"的基础。

同盘两个目录可以都通过回读，但盘坏掉时两处一起丢。是否满足副本要求，要在内容校验之外再检查物理独立性。

四、上手：三步完成第一份备份

1. 点"新建备份"，保持默认"普通备份"，把素材卡或文件夹拖进去（源和目的地都支持从 Finder 拖入）。
2. 选存放副本的父目录（注意：选的是父目录，不是最终落点），选"按次保存"或"保留源文件夹（镜像备份）"。
3. 核对每个来源的实际最终路径、容量与身份，然后开始。

文档里有几个容易忽略的细节：

• 按次保存会生成 源文件夹名_时间戳，例如 FX3_A001_20260830143000，无同名冲突时内部结构不变。
• 镜像备份保留所选源文件夹这一层，不是删除式同步：不删目的地多余文件，不同名不同内容按冲突策略处理，不静默覆盖。例：源 /Volumes/CARD/拍摄素材 + 目的地 /Volumes/BACKUP/交付 → 落在 /Volumes/BACKUP/交付/拍摄素材。
• 目的地选父目录，别先进入一个同名空文件夹，否则会多套一层。
• 高级选项默认折叠，但哈希与逐目的地独立回读始终开启；新任务默认包含隐藏项与空目录。
• 容量读不出来会显示"待引擎预检"，不会显示成"已通过"。
• 同一物理磁盘上的多个文件夹不算多份独立副本。

传输队列里能直接核对素材源、每个最终目的地和内容校验状态。目标不只是一个盘符：展开任务前，先确认路径确实是你这次要交付的位置。

路径图只解释落点规则。镜像备份保留来源这一层，但不是删除式同步；正式点击开始前，还是要看确认页里的每个最终路径。

偏好设置把新任务的默认值集中放在一起：SHA-256、校验后跳过同名文件、包含隐藏文件、完成后生成 PDF。完整性校验始终开启，不能拿改默认值来省掉回读。操作人应填实际负责的人；演示里留空，没有编一个签名。

第一次试用：先拿一份不怕丢的素材

先准备一个小文件夹，放几张照片、一段视频和一个空目录，选一块测试盘作为目的地。开始前看清界面列出的最终路径：目标父目录选错，可能会多套一层文件夹；选到同一块物理盘的不同目录，也不会多出一份物理独立副本。

确认页列出了两个目的地的最终路径、SHA256 回读方式和“存储关系待核对”。这次按普通备份走完整个流程，没有创建拍摄项目。需要项目、拍摄日和机位规则时，再按使用手册配置，别把目录数量当成物理副本数量。

复制进度走完后，继续等每个目的地独立回读和哈希比对完成，再看任务结论与报告。需要多份副本时，再增加另一块物理磁盘重跑；别把同盘两个文件夹算成两份。正式拍摄前，还要用自己的读卡器、线材和真实存储设备做一次完整验收。图中的小样本只用于演示操作，不用于测速。

任务详情把这两个结论分开写了出来：两个目标通过校验，但只有一份可计数副本。两处目录的内容都对得上，不等于丢掉一块盘之后还能保住素材。复制 100%、校验 100%、副本数量达标，要分别看，不能拿前两个代替第三个。

再次选择已经备份过的演示文件夹，向导会提示“疑似重复素材卡”。它此时比较的是相对路径和字节数，还没有重新读取内容哈希，所以需要人工确认，不能直接判定内容相同。这张图停在设置目的地这一步，没有再启动备份。

五、功能全景

README 里那张"当前主要功能"表基本是全量能力，我按使用场景重排一下：

这套功能的取向是：它不是"复制更快"的工具，而是"结论更硬"的工具。

素材库接着显示这次备份里的四个文件，并区分历史校验和当前可访问副本。右下角是测试视频的缩略图与媒体信息，不是客户画面。查看、播放和后续代理处理从这里继续，但“可访问”本身不是一次新的完整哈希校验。

报告中心里，同一任务显示“自动 PDF 已保存”，旁边是 PDF、MHL 与 ASC MHL 的导出入口。本次确认了自动 PDF 已保存；没有把所有导出格式或剪辑软件导入一并算作通过。交接前仍应核对报告对应的时间、来源、目的地和校验结论。

六、五个案例：从插卡到归档

案例 A：一天的普通备份

不建项目，插卡 → 拖入 → 选父目录 → 核对最终路径 → 开始。复制（紫色进度）与目的地独立回读（绿色进度）分开显示。全部目的地校验完成后，每个素材卷目录里会自动落一份 Kocpy报告/素材卷名_任务标识_首次完成校验快照.pdf。

报告采用不覆盖发布：字节与预期 SHA-256 先落检查点，独占发布后再回读一次；同名不同内容的旧报告会被保留并报错，而不是盖掉。

展开已完成的任务，能继续往下看每个目标的校验日志，以及首次完成校验的 PDF 快照。“已回读确认”对应报告文件本身。这里仍是四个测试文件、同一块盘上的两个目录，不是两份物理独立副本；图中的速度也不是设备跑分。

案例 B：一个拍摄日的收工

1. 建项目，填拍摄周期、设备、机位、收工所需副本数。
2. 连卡和盘；要多份物理独立副本就用不同的物理设备。
3. 新建备份，选来源、项目、日期、设备、机位。
4. 核对文件数、素材量、最终路径、容量与身份。
5. 等复制与逐目的地回读完成，看当天收工矩阵。
6. 处理待确认与风险，导出报告、交接，安全后推出设备。

矩阵里五种状态是有讲究的：

• 已满足收工要求：该单元每个已发现素材卷都达到要求的物理独立副本数。
• 应该有素材 · 缺少备份：当天明确计划用这台设备，却没有记录。
• 当天未发现素材 · 待确认：没有记录，也没有足够信息判断设备是否使用。
• 当天未使用 / 休息日：由人确认，不计入收工缺口。

关键在于 Kocpy 不允许"文件夹不存在"自动等同于"没拍"——空白默认是未知，要人签字。这条规则在真实片场能挡掉一整类事故。

某个机位当天没有记录，不能直接判成没拍。先确认是否计划使用，再核对每个素材卷的独立副本；“休息”或“未使用”需要人确认。

案例 C：把已有备份纳入记录

三种粒度：单张素材卡、单日所有机位、整个项目。先确认日期／设备／卷映射再写记录，支持：

• 清单校验：拿外部 MHL／SHA 清单逐条比对；
• 首次基线：只记录接管时存在的内容（文档明确警告：这不证明接管前完整）；
• 仅导入结构：不校验，只把目录关系读进来。

差异处理页给出缺失／额外／大小／哈希明细，可 Finder 定位、从健康副本修复；要改旧清单必须经确认并留审计，且不豁免大小或哈希异常。

三条路回答的问题不同：清单比对能查当前差异，首次基线只记录接管时的内容，仅导入结构则不做内容校验。不要把后两条当成历史完整性的证明。

案例 D：一张跨了两天的卡，但对方只收今天

1. 先完整备份整卡，至少一个目的地完成独立回读——不要先从卡上删"非本日"素材。
2. 进入"完整卡日期归属与当日交付"，选一个已校验的完整卡副本，点"重新分析"。
3. 媒体内嵌日期、路径日期、修改时间都只是建议，逐组人工填"确认日期"并记录确认人。
4. 选确认好的拍摄日 + 交付父目录，勾证据边界，开始。
5. Kocpy 从已校验副本读取、写入独立目录、逐文件回读 SHA-256，再出 MHL／JSON 和 PDF。

边界写得很硬：完整卡和原始清单永不修改；当日交付不计入素材卷数、任务数与独立副本数；"没有进入当日交付"不等于"可以删卡"。

先保留完整卡，再人工确认日期，最后生成当天交付。没有进当天交付的文件，不意味着可以从原卡删除；派生交付也不增加独立副本计数。

案例 E：把项目归档到 NAS

独立入口，不混进素材卡计数：网络共享先在 Finder 挂载 → 选源项目文件夹和目标父目录 → 预检（文件数、精确字节、空目录、既有 MHL／PDF、目标文件系统、挂载点、实际最终归档目标）→ 开始 → 扫描／复制／从目标回读／出报告。

界面会明确告诉你：它显示文件系统与挂载点，但不凭"目录可访问"就宣称这是 NAS。服务器内部磁盘拓扑、ACL、扩展属性、时间戳、历史完整性都不在它的结论范围内。最终目录里的 Kocpy报告 会给出明细 PDF 与高清 PNG，同样带 SHA-256 并回读核对。

NAS 或网络共享先挂载，再做预检。目录能访问，只说明这次能读写，不证明服务器内部有多少块独立磁盘，也不证明旧数据一直完整。

七、往深了说：它是怎么实现的

技术栈

package.json 里的实际配置是：

用 WebAssembly 的 SQLite + 纯 JS 哈希，意味着没有原生编译依赖，代价是超大文件集下的内存占用——文档也直说"百万文件持续项目仍可能占用大量内存"。这种坦白在同类项目里并不多见。

完整清单：complete-v2 的冻结逻辑

每次新任务会冻结一份范围策略与初始指纹：包含隐藏项、AppleDouble／系统元数据、既有清单与报告、空目录；指纹覆盖路径、大小、时间戳、目录元数据和每一项显式排除。

然后是这套设计里最关键的一条：

复制结束后必须再扫一次源，并要求与冻结指纹一致，任务才允许完成；每个目的地还要包含记录过的目录范围以及独立验证过的文件。

换句话说：如果拍摄过程中有人往卡里写了文件、或者删除了东西，任务不会"成功"。符号链接和特殊条目也不静默跳过，而是明确报错并显示相对路径——"不要为了通过而关闭校验"被写进了工程红线。

主动关掉"包含隐藏文件"也不会变成静默旧扫描：每个被排除的路径、类型、字节数、时间和原因都会记进任务快照，结论随之降级为"按明确过滤范围一致"。

开始时的扫描不是永久通行证。复制后再扫源，检查有没有新增、删除或变化；目标还要覆盖记录的目录范围并完成独立验证。

卷身份与恢复

• 复制期间每 15 秒重新确认源与目的地卷身份；记录过 UUID 的卷给不出同一 UUID 就停，不会退回"看目录名像不像"。
• 0.1.19 修过一个真实缺陷：旧版对任意子目录查盘身份，失败会被误报成"UUID 变了"；新版改为查询该路径实际所属设备，原盘一致时可以恢复旧失败任务，不必删项目重来。
• 恢复中心提供四条路：从安全检查点继续、扫描复用断点、只重试失败目标、不重拷直接重新校验。已通过校验的目的地不会因为单个目标失败被重写。
• 磁盘回来后先"只读检查连接与身份"（记录身份、当前 UUID、挂载点、权限、可用空间），核对确认后才能重试；真换盘或格式化则要求另建任务，不许覆盖旧 UUID 消警告。

盘重新接上不等于还是原来的盘。先做只读连接和身份检查，再决定继续、复用断点或只重试失败目标；真正换盘时应另建任务。

报告、清单与代理的发布语义

• 不覆盖发布贯穿始终：报告、交付目录、修复写入都是"唯一临时文件 → 同步落盘 → 回读校验 → 原子发布"，失败不留下半成品。
• PDF 统一走一条 HTML→PDF 路径：报告 HTML（含缩略图）写进仅属主可读的唯一临时目录，用本地文件加载（而不是可能超限的 data: URL），打印前删除。8,407,048 字节的 HTML 实测打印出 23,223 字节 PDF 并清理了临时文件——这类数字被写进了验证记录。
• 代理证据链：代理只能从已校验的备份副本入队；入队时冻结源路径、字节、原任务哈希与全部转码参数，转码前再完整读一次源并核对哈希；完成后记录输出 SHA-256、分辨率、帧率、时间码等，取不到的字段显示"未知"，不填默认值冒充通过。
• MHL／ASC MHL 只允许从已完成、完整校验且无未解决清单差异的副本导出；有未达副本要求素材卷的项目，会拒绝生成项目归档包。

代理不仅要能播放，还要知道它来自哪份已校验素材、用了什么参数。图里分开了源证据、转码过程和输出证据，不能用一次成功生成替代这些核对。

生成剪辑代理的表单里，预设、编码、输出尺寸、码率、封装和命名规则分别设置。图中用的是测试视频 Demo_001.mp4，选择 H.264 1080p 和 MP4；码率 0 在这里表示质量模式。这次只展示参数，没有加入队列或生成代理，也没有验证专有 RAW 格式。

工程红线（AGENTS.md）

仓库里那份 AGENTS.md 有几条我特别认同：

• 绝不为了测试通过而削弱校验、路径包含、身份检查、独占写入或恢复证据。
• 测试只用生成的夹具与隔离临时目录，不碰用户的生产项目、源素材、目的地副本与原始清单。
• "复制完成、内容校验、独立副本策略"是三个独立事实；未知存储拓扑不是物理独立的证明。
• 隐私：私有计划文档、附件、执行台账一律不进仓库；不发布真实素材、可识别的项目夹具、私人路径或原始诊断数据。
• 发布：不 force-push、不复用版本号、不替换已发布二进制；已知的严重数据安全缺陷阻塞相关版本发布；Apple Silicon 原生、Rosetta、Intel 原生必须分别标注；没有实据就不得声称 Developer ID／公证／硬件认证。

八、验证与发布工程：25 天，46 个版本

这个项目的发布节奏，以及它怎么说明已测和未测的内容，也值得单独写：

• 仓库创建于 2026-08-26，最新推送 2026-09-20；46 个 Release，从 v0.0.1 到 v0.1.39，跨度约 25 天。
• 当前源码全量回归：52 个测试文件 / 519 项通过，4 项按真实硬件或压力条件跳过；类型检查、生产构建、源码与媒体来源门禁、依赖审计全部通过，npm audit 0 个已知漏洞。
• 仓库里内置了 test:large（10 万）与 test:million（100 万）的目录压力测试脚本，以及必须在可牺牲卷上显式执行的真实介质测试协议。
• 双架构 CI 分开标注：原生 Apple Silicon 与 原生 Intel 各自跑完源码／类型／全量回归、报告实际渲染、ad-hoc 候选 DMG、严格深层签名结构和包内隔离运行时专项。
• 三级流水线：候选提交 → 冻结提交 → annotated tag；冻结提交到打标签之间没有跟踪文件变化；正式附件从 GitHub 原样回下载，SHA256SUMS.txt、GitHub 附件摘要、本地重算三方一致才发布。

更难得的是"未验证清单"——它明确写下自己没做过什么：

• 没有 Developer ID 签名，也没有 Apple 公证；不宣称通过 App Store 审核。
• 当前没有真实 NAS／SMB 真机结果；真实外置双盘、网络中断／重挂载、拔盘、睡眠、空间耗尽的本版复验边界仍然保留。
• "10k" 只是 10,000 条恢复元数据的结构与容量估算，不是 10,000 个真实文件的复制、哈希、恢复或性能测试。
• Resolve 有合成样本的实际导入证据；Premiere Pro／Final Cut Pro 的清单只完成结构与生成检查，未宣称实机导入。
• 自动测试、磁盘映像和同盘多目录不代替真实现场介质验收。

把"我没测什么"写进发布说明，比写十个新功能更能建立信任——这也是我认为最值得其他开源项目抄的一节。

源码测试、安装包验证和真实介质验收各管一层。某层通过不会自动替代下一层；图中的硬件与软件导入边界仍保留原文的未验证说明。

九、横向对比：功能、性能、价格

9.1 先看价格（2026-09-27 抓取，以官网为准）

补充两个有意思的行情：OffShoot 还有 DIT Bundle（OffShoot + FoolCat + EditReady）$299；想象产品的 ShotPut 系列对学生／教师有 30% 教育折扣。

对比要点：OffShoot 与 ShotPut Pro 的标价几乎一致（$169），行业主流工具的永久授权价位就在这个量级；Silverstack 走订阅＋短租，更适合按项目计成本的剧组；Kocpy 是零成本 + 源码可见。

9.2 功能对比

表中"—"表示该产品主打不在这一项，不代表绝对没有；具体以各自官网为准。

9.3 性能：我为什么不给跑分

网上这类对比最常见的做法是贴一张"每秒拷了多少 MB"的表。我拒绝这么写，原因有三：

1. 结果取决于介质，不取决于软件。 同一张 CFexpress 卡配不同读卡器、同一块盘走不同 USB 根端口，差异常常大于工具差异。
2. 各家默认的校验强度不同。 ShotPut Pro 默认 xxHash64（另有 XXH3-64/128、C4）——哈希速度极快，但它是非密码学哈希；Kocpy 提供 SHA-256 / SHA-1 / MD5，其中 SHA-256 计算更慢，换来的是通用性与抗碰撞性。用 xxHash 的总耗时去和 SHA-256 的总耗时比，是不公平的比较。
3. "复制"和"复制+回读"必须分开算。 Kocpy 自己就在文档里写明：不能把带完整校验的任务总用时直接等同于 Finder 单纯复制的用时；多目的地总写入量、小文件数量、介质连接方式都会影响。

Kocpy 自身的性能口径倒是可以量化地说清楚：

• 归档转存按 4 MiB 分块采样，约每 250 ms 更新一次进度；瞬时速度、ETA 是界面态，不逐采样写进持久记录。
• 复制速度（写入目标）与回读速度（从目标重读并算 SHA-256）分开显示；阶段切换会重置速率窗口，报告与终态阶段显示 0。
• 暂停立刻清掉速度与预计时间，继续后重新采样，暂停时间不计入速率；未到 100% 的阶段不四舍五入成 100%——字节 100% 之后还要等文件收尾、哈希核对和终态。
• 备份优先：转码不与新备份抢持续读写；开始复制、恢复、失败重试或复校验时，代理在安全边界暂停并显示"备份优先"，队列空闲后自动继续；用户手动暂停永不被自动恢复。
• 优化有明确边界：干净启动与检查点减少了重复序列化与无变化索引扫描，但没有减少源哈希、逐目的地独立回读、落盘同步或源变化检查。

想要真实数字，正确做法是拿同一张卡跑各家的试用版：OffShoot 10 天、ShotPut Pro 30 天 10 次、CCC 30 天，Kocpy 直接免费——这是开源在这一行最实在的优势。

9.4 Kocpy 的优势与短板

优势

1. 零成本 + 源码可审计。 对学生、独立摄影师、小团队，$169×N 不是小数目。
2. 证据语义最严格：逐目的地独立回读、冻结范围、15 秒卷身份复核、把"副本数"和"物理独立"分开判定——这几条在同价位商业工具里也要到 Pro 版才齐。
3. 现场管理颗粒度：拍摄日／设备／机位收工矩阵、日计划、规则版本、交接冻结、经审计的清单修订，这套东西更接近DIT 工作流而非单纯传输。
4. 接管既有备份：MHL 比对、首次基线、仅导入结构三档，能把历史上乱糟糟的目录纳入记录而不必重拷。
5. 报告即证据：每目的地自动 PDF、不覆盖发布、落盘回读，交付给客户时不用再自己拼清单。
6. 透明度：验证记录把"没测什么"列出来，AGENTS.md 把红线写出来。

短板

1. 没有 Developer ID 签名，也没有 Apple 公证 —— 首次打开要去"系统设置 → 隐私与安全性"里放行，公司电脑可能被 MDM 直接拦掉。这是目前最实际的使用门槛。
2. 没有真实 NAS／SMB 真机结果，外置双盘、拔盘、睡眠、空间耗尽等边界仍标注"未复验"。
3. 仅 macOS，没有 Windows 版。
4. 没有云与团队协同：无 S3、无账号体系、无跨团队同步（这其实是"本地优先"的主动选择，但对需要云端交接的团队就是缺口）。
5. 播放 QC 与元数据字段库不是它的强项——要示波器、100+ 元数据字段、ALE/XML 深度交付，Silverstack 那条产品线更成熟。
6. v0.1.x 早期，社区很小（仓库当前 2 star、0 fork、0 open issue），出问题主要靠自己和 issue。
7. Electron 体量：安装包与内存占用高于原生工具，百万文件级项目文档自己也提示注意内存。

9.5 谁该用哪个

• 预算敏感、macOS、要严格校验 + 现场收工管理 → Kocpy（免费，先用非生产数据验自己的读卡器与存储）。
• 要跨平台、行业通用的 offload，还要 S3／脚本 API／团队共享授权 → OffShoot Pro（$249）或标准版（$169）。
• 要"拷完就出漂亮报告 + 通知自动化"，默认哈希更快 → ShotPut Pro（$169）。
• 要当 DIT 中枢：播放 QC、元数据库、ALE/XML 交付、与调色／直播工具联动、按项目租授权 → Silverstack。
• 只要整盘／系统级备份，不关心清单证据 → Carbon Copy Cloner 7（$49.99）或 rsync。
• Windows 或纯命令行 → rsync、robocopy 之类，别为这个装 macOS 专属工具。

十、写在最后

Kocpy 有意思的地方不在于它比 $169 的工具"更快"，而在于它拒绝把含糊的词写进界面：完成要拆成七种含义，副本要区分"通过校验"和"物理独立"，未知要写成"待确认"而不是绿色对勾，没测过的东西要写在发布说明里。

对一个拿素材当命的行业来说，这种偏执是加分项。

当然，代价也摆在明面上：没有签名与公证、没有真实 NAS 实测、只有 macOS、社区还很小。我的建议是：拿非生产数据先跑一轮——按它自己文档的说法，磁盘映像和自动测试不能代替真实介质验收，正式使用前先用非生产数据验证你自己的读卡器、连接方式与存储设备。

• 项目与下载：https://github.com/sexyfeifan/Kocpy/releases
• 使用手册 / 安装与升级 / 架构与安全边界 / 验证记录，都在仓库 docs/ 下
• 许可：Kocpy 代码 MIT；独立调用的 FFmpeg/x264 运行时按 GPL-2.0-or-later 单独授权，相关声明与对应源码随安装包提供

附录：速查卡

安装（0.1.39）

# Apple Silicon（M 系列）
Kocpy-0.1.39-arm64.dmg
# Intel
Kocpy-0.1.39-x64.dmg
# 下载后先核对同一 Release 的 SHA256SUMS.txt，再拖入「应用程序」

从源码运行（macOS，Node.js 22 + npm）

npm ci
npm run verify:release   # 源码树卫生 + 媒体运行时来源门禁
npm run typecheck
npm test                 # Vitest 全量回归
npm run dev
# 打包：npm run dist:arm64  /  npm run dist:x64

三步备份

新建备份（普通备份）→ 拖入素材源 → 选 1–4 个父目录 → 核对最终路径 → 开始
复制完成 ≠ 校验完成：等每个目的地独立回读 + 哈希比对都过了，才算完成

数据与记录

应用记录：~/Library/Application Support/Kocpy/
素材：留在你自己选择的源与目的地
报告：写入各备份目的地的 Kocpy报告/ 目录
无需账号；报告同步文件夹、工作站包、局域网索引只有你主动配置才会用到