[!TIP] 受众：好奇"人类出规格、模型执行"到底靠不靠谱的人，以及写技术规格的人。 核心目标：用一次真实交接的完整记录，展示规格里哪几种东西必须写死，以及执行方带着证据纠正规格时该怎么处理。 问题-方案映射：

  • 一份数据走两趟网络 → 勘察发现根因是拓扑，补一个 bind mount 变纯本地 IO
  • 规格不能有歧义 → 实测事实与假设分开标注，安全约束写死
  • 规格可能写错 → 执行方实测发现问题，带着证据改掉并记录

只讲这一次实际发生了什么：不喊口号，也不下"AI 分工的未来"这种大结论，你从记录里自己判断这套分工成立在哪。

1. 起因是一件很土的事

家里的下载机把文件下到 SSD，归档盘是另一台机器上的 14T 机械盘。原来的做法是先从 SMB 拉到自己的 Windows 机器、再 SMB 推回去——一份数据走两趟物理网络，又慢又绕。

2. 先勘察再动手：根因不是工具是拓扑

动手之前先勘察，结果根因根本不是工具问题，是拓扑问题：

  • 归档盘早已在宿主机挂载，并 bind 给了三个容器，唯独漏了下载机那个容器，所以它只能走网络。
  • 承担 SMB 共享的那个容器上有一条 cgroup IO 限速（80 MB/s 硬顶），所有经它读写归档盘的流量都撞这个天花板。
  • 两个容器挂在两块不同物理网卡的网桥上，网桥之间无互联，容器间流量必须出物理口经网关绕一圈回来。

结论：补一个 bind mount，搬运就从"两趟网络"变成纯本地 IO。预期收益：100 GB 的搬运从约 25–30 分钟降到约 7 分钟。

3. 规格里写了什么

规格文档里哪几种东西是必须写死的，各配一个本次的真实例子：

第一，实测事实与待确认假设分开标注，并且明确写"标注实测的不要重新推导，也不要因为与常识/文档不符而擅自改回"。本次写死的实测数字包括：归档盘顺序写 233 MB/s、顺序读 254 MB/s（dd O_DIRECT，1GiB）；文件系统是 exfat，簇 4 MiB（引导扇区读出来的，不是猜的）；非特权容器能写 exfat、无需 idmap，不支持硬链接，同盘 rename 原子可用；rsync --preallocate 在 exfat 上不支持、必须禁用（Operation not supported）；exfat 时间戳精度 10 ms，所以增量判断可靠、不会误重传。

第二，由实测事实推出的硬性设计要求。4 MiB 簇导致的真实浪费：照片目录实际占用 840G / 真实大小 600G，77400 个文件，白吃 240 GB。所以规格直接规定：必须做按簇对齐的空间预检（Σ ceil(size / 4MiB) * 4MiB），UI 上同时显示"真实大小"和"落盘占用"两个数字——否则"名义 10MB 的一千个小文件"会在只剩 1.8T 的盘上把人坑到。

第三，安全约束写死，不给执行方发挥空间：路径白名单（先 realpath 再校验前缀，防穿越和符号链接逃逸）、subprocess 传参数列表永不 shell=True、删源必须四步全绿且用户显式勾选、目标已存在拒绝覆盖。

第四，明确的"不做什么"清单及理由：不改下载器配置、不装任何钩子或定时扫描（我明确要求全手动）、不引入第三方 Python 依赖、不动那条 80 MB/s 限速、不迁移文件系统。

第五，验收清单写成可直接执行的命令和判据，不写"确认功能正常"这种话。

4. 执行结果

交付物：下载机容器补上挂载点；一个单文件的搬运服务（纯标准库 + 系统自带 rsync）+ systemd 单元 + SQLite 队列 + 内嵌前端。状态机 PRECHECK → COPYING → VERIFYING → COMMITTING → [DELETING_SRC] → DONE，先写进同盘 staging 目录，校验通过再原子 rename 落位。

验收全部实跑：

  • 复制速率 287–321 MB/s，高于 233 MB/s 的基线。
  • 空间预检：2TB 稀疏文件被拒绝入队，报出簇对齐后的需求量。
  • 膨胀显示：一个 200 个小文件的目录，真实 57 KB / 落盘 800 MiB。
  • 中断恢复：复制 8 秒后重启服务 → 任务标 FAILED、staging 现场保留、源未删；重新提交续传，46.8s 完成（全量是 54.8s），字节级验证确认续传生效。
  • 安全：../../etc、/etc、符号链接、拿 staging 当目标，全部被拒。

5. 三处实测偏离

执行方没有照抄规格，而是在真实环境里发现规格写错了，带着证据改掉并记录：

  1. 规格写 --partial-dir=.rsync-partial。实测 rsync 3.2.3：--append 与 --partial-dir 互斥，且 --partial-dir 只是把 partial 存下来，重跑并不续传（sent 字节 = 全量）。改用 --partial --append-verify 后，2 GiB 文件已传 1 GiB 时重跑，sent 降到 1.07 GiB，speedup 2.0，真正续传。
  2. 规格要求源/目标两栏都显示"落盘占用"。实测目标侧那个 77k 文件的目录递归统计要 ~8s，整个目标根列表会卡 15s+。改成只有源栏做递归，目标栏浅列表，权威的"真实 vs 落盘"对比放在提交前的确认弹窗里。
  3. rsync 尾斜杠语义：直接传 staging/<base> 会生成 staging/<base>/<base> 双层嵌套。

还有一条如实记录的孤立异常：某次 20 GiB 任务的进度条停在第 3 条进度行，但日志里 80 条全在；同代码同文件重跑正常，未复现、无已知根因，记录在案持续观察。这条我坚持要写——肯把"我不知道为什么"写进交付报告，比一份全绿的报告可信。

6. 哪些必须我来定

不做"AI 全自动"的幻想，实事求是地分：

  • 能交出去：在给定约束下写代码、部署、按清单逐项验收、在真实环境里量数字、发现规格与现实不符时带着证据纠正。这次这些都做得住。
  • 不能交出去：判断"根因是拓扑不是工具"这类问题定性；决定不做什么（拒绝自动化、拒绝动限速、拒绝迁移文件系统都是有代价的取舍）；把安全边界写死；以及决定什么数字算"实测过"。

小结

一句朴素的总结：分工能成立，靠的不是模型多强，而是规格里把哪些是事实、哪些是假设、哪些不许改，一条条写清楚了。