# 制作效率与目录清理审查

2026-10-08，根审查者 `/root`。本轮只有调查、统计及计划文件：没有删除、搬移、物化软链接、修改成片或生产流程。

您的观感大体成立：**中后期确实出现了“内容已准备好，却被执行包装及重复交接挡住”的情况，解除这些约束后发布明显恢复。** 减速在第39讲之前就已出现，并经历了几轮不同原因：前几讲的显示升级及方法补验，中期内容错误迟发现、长上下文和重复交接，第33讲内存事故后累积的资源准入与批准链。逐讲复盘把局部修法持续写入通用规范，逐渐增加了每段的执行负担；到43/44讲，固定讲末复盘虽已取消，旧包装仍在阻塞。

## 1. 把基线前移到第1–6讲

本次重新查了早期归档的正式编码报告、completion与根原生日志中的实际发布核验。早期窗口定义为“本轮最早保存的正式成片完成→根实际核整讲release”；内容起草发生在此前。第1讲还有更早的原型，不能把这次窗口视作从零制作时间。

| 讲次／时期 | 段数 | 可见交付窗口 | 段/小时 |
|---|---:|---:|---:|
| 第1讲，9月6日保存的制作轮次 | 20 | 4小时50分 | 4.14 |
| 第2讲，同日 | 20 | **2小时39分** | **7.54** |
| 第3讲，同日 | 17 | **2小时14分** | **7.62** |
| 第4讲，同日 | 19 | 4小时04分 | 4.67 |
| 第5讲，同日 | 18 | 2小时50分 | 6.34 |
| 第18讲，当前正式版本 | 27 | 3小时47分 | 7.13 |
| 第21讲，当前正式版本 | 20 | 2小时39分 | 7.56 |
| 第22讲，当前正式版本 | 27 | **7小时34分** | **3.57** |

早期几讲存在并行，表中各讲窗口不能相加当总工时。9月6日的部分验片后来因使用缩略拼图而撤回，因此把这组作为当时的交付速度记录；补验工作另列。第6讲包含8段旧内容重制与14段新内容，跨两天，单列在机器记录中。数据来自[早期逐段统计](early-throughput.sol.json)、[原记录定位](early-records.luna.md)和[18/21/22同字段统计](../retrospectives/lecture-22-timing-audit.sol.md)。

这次比较确认：第39讲已处于低效阶段，早期第2、3、5讲的可见交付吞吐明显更高。第21讲仍有较快的窗口，说明减速也随讲次难度、返工和执行方式变化，并非一路均匀下降。

## 2. 减速分期：至少有几种不同机制

**前几讲：需求重制、流水线耦合和验片方法补做。** 9月6–7日增加原录像窗英文字幕、透明白线图及公式出现时机调整，冻结范围已有102段，后来统一重制。这些重烧由显示要求变化触发，另有时机候选误折叠一/二阶公式等实际错误。第二讲还留下明确现场记录：两名工位的成片已完成，正做验片；两次同机进程检查均没有renderer，下一段也未启动。第三讲拆开职责后，下一段烧录已经能与前一段验片重叠。这说明串行工位耦合在早期就存在。

同一时期，50段旧完成依据因缩略拼图检查撤回，第1、2、3讲随后分别实看868、871、838张唯一完整原图。最初的验片方法错误产生了大批补做；补验本身承担了真实质量工作。

**第9–18讲：真实漏错与证据处理往返。** 第9讲17/19段曾把8处内部制作文字带进成片。第12–14讲有草稿模型试验及串位、伪中文等失败；第16讲后增加写QA前的工具覆盖检查，核对实际成功查看记录，减少expected清单与实际工具轨迹的混淆。第18讲根复查27段311项，发现12段需要补全或合成完整方程，教材已有相应关系，主审也读过，却把字幕保守策略错用于板书重构，审核口径和抽查共同漏检。这里的重点是尽早查对关系与表达，而非继续叠加机械证明。

**第22讲：理论难度、烧后文字返工与交接长尾叠加。** 同为27段，第22讲交付窗口约为第18讲的2倍，而成片分钟和抽图规模只高约10%–15%。最后成片到最后发布，第21讲约10.5分钟，第22讲约100.5分钟；22.20单段约210分钟。CPT及原音歧义有实际难度，孤字与角度字形烧后才发现、SHA误抄、把prewrite当postwrite、工具身份争议则增加了可以避免的往返。详细数据见下文。

**第33讲：用户指出内存问题后修复，随后保护流程扩张。** 用户先提出检查30多GiB内存是否必要或属于bug，代理随后定位并修复。该修复属于用户推动的纠错，不计为逐讲自主改进的收益。单条33.02曾占约33.2GiB匿名RSS，主机耗尽内存。实际修正稀疏PNG主时钟后，对照段降至约2.62GiB；但资源准入、占用声明、ROOT fresh及wrapper采用继续逐段执行。到43/44讲，监控权限和目录前缀等机械错误足以挡住启动，需要多轮新包装和根批准。

**第39讲已在反复交接。** 17次当前渲染运行区间累计约124分钟，记录同时存在长字幕DOM失败、方法选择错、图显示失败及根提示导致重复看29张图。第39讲不能作为“早期快速制作”的基线，最多用于比较慢期内部变化。

固定逐讲复盘最早可核安装在9月7日。它既发现过真实缺陷，也把越来越多局部修法加入每轮通用工作：三份主要规范合计从9月6日约14.4KB、103行，增长至9月12日125.4KB、641行，9月23日143.4KB、741行。第22讲50个Astra会话的命令提及工作流规范，其中15个多次提及workflow；这些记录反映了规范进入反复交接的频率，完整读取量未单独统计。记录没有完整角色工作/等待计时，不能逐分钟分摊各机制的贡献。

您的判断得到支持：**局部改进逐渐变成重复输入、重复取证和串行批准，确实拖慢了生产。** 同时，早期方法债务、中期真实内容漏错、需求重制和内存事故分别增加了工作量。详见[分期原因及原证据](early-causes.sol.md)、[规范体积历史](policy-size-history.root.json)。

## 3. 中后期速度：实际发布记录

| 时期 | 统计窗口 | 实际发布段数 | 发布段/小时 |
|---|---|---:|---:|
| 第39讲，已处于低效期 | 10月1日固定12小时 | 17 | 1.42 |
| 第41讲 | 10月2日固定12小时 | 15 | 1.25 |
| 慢期43/44讲 | 10月3–4日固定12小时 | 10 | **0.83** |
| 10月4日取消过度流程后 | 授权至最后发布，8.47小时 | 53 | **6.26** |
| 10月7日恢复后的收尾 | 授权至全部完成，8.13小时 | 124 | **15.25** |

慢期相对前两例分别降低41%和33%。10月4日恢复窗口里确实达到每小时数段。10月7日同时复用在制材料、扩大并行并释放积压。表中统计发布吞吐；前三项采用固定12小时窗口，后两项从授权起算至最后发布。

成片完成到发布的中位间隔为 **88.6 → 37.2 → 30.3分钟**；最长内部无发布间隔为 **193.0 → 59.2 → 34.5分钟**。尾部包含看图、独立物理审核、技术核验、排队和包装。约68.34小时用户暂停已排除；第47讲跨暂停的70小时首末跨度没有当作制作慢的证据。

后期177份不同段的实际发布回执已与当前成片绑定核对：172份直接匹配输出SHA，另5份经completion SHA及输出SHA链匹配。交叉检查补齐了5份使用不同status措辞的成功回执；详见[统计及逐段证据](throughput.sol.md)、[机器汇总](throughput-summary.sol.json)、[逐段CSV](throughput-events.sol.csv)。全54讲成品为958段中文QFT视频及958份同名英文SRT，当前所有1953条release链接均可解析。

### 补充：所有已统计快慢窗口，包含零发布小时

按实际发布回执切分固定60分钟窗口，公开完整序列，不仅选择快例。四个观察区间共有40个完整小时及2个部分小时；后三个明确活动/许可收尾区间的28个完整小时中，**5小时零发布，5小时只发布1段**，合计10/28小时。慢期43/44的12小时平均仍为0.83段/小时，最长相邻发布间隔约193分钟。最高已统计固定小时为10月7日21:54:45–22:54:45香港时间，发布27段；这是发布吞吐，材料准备可能已提前完成。

另将全部54讲958段现行成片及根检查时间列成[全54讲粗时间表](slow-fast-complete-lectures.sol.csv)。8讲粗值低于1段/小时：17、19、20、27、29、43、44、47；这些全部保留。第47跨明确用户暂停，其余长跨度未完全取得持续活动证据，粗墙钟值与净工作速度分别解释。比如第29讲13段跨17.59小时，粗值0.739；第19讲跨数日的0.185不当成持续工作的速度。

[全部窗口与分布报告](slow-fast-complete-throughput.sol.md)及[42窗口CSV](slow-fast-complete-throughput.sol.csv)包含全部已取得可信区间的高低值。实际发布回执覆盖204段；全54粗表覆盖958段，不能把它们合称全54讲逐小时首次发布历史。第39的7个零发布小时活动状态未知，与确认活动期的5个零发布小时分开。

10月4日53段/8.467小时的旧均值终点是最后发布10:28:29UTC；新小时表为包含许可收尾，延长至结束10:34:20UTC，多出的约6分钟不参与旧均值。这两个区间边界在汇总时区分。

## 4. 后期执行包装怎样阻塞

**资源保护后来扩张成了逐段审批生产线。** 第33讲的OOM是真事故：单段约33GiB匿名RSS，61GiB内存与8GiB swap耗尽。限制和定位问题最初有依据；稀疏PNG作为主时钟造成的内存问题修正后，对照段约2.62GiB。但随后仍把ROOT fresh、claim、slot、scope、wrapper、方法采用、consumer等逐段串在正式执行之前。一次监控或参数错误就会触发新的包装、归档和批准，内容并没有随之改善。

三个能直接核实的例子：

- **43.10：监视代码先失败，再清理占用声明，再重批。** guardian读取 `/proc/1/ns/pid` 遇权限错误，结果要求保留claim并重新ROOT full fresh。两轮失败及claim/profile清理后才完成烧录。上一段发布到这段发布间隔3小时13分，其中最后成片到发布还需58分钟。故障和恢复包装处于这条关键链上；日志没有逐分钟拆分整个3小时。
- **44.03：代码已通过，输出目录前缀仍挡住启动。** 审查已证明资源算法AST未变，唯一问题是ROOT参数中的basename不满足 `private_runtime` 前缀。意见明确code/candidate unchanged，却仍需新不可变包、ROOT argv及多项启动前置核验。这是纯机械模板问题被流程放大的实例。
- **43.11、43.13、44.04：实际运行数分钟，交付尾部约1.5–2小时。** guardian记录的运行区间分别约273、234、127秒；成片到发布分别约106、122、91分钟。试验授权只有两项并发且singleMux。主要延迟发生在成片前后的交接和恢复。

根是发布唯一写者，这本来可避免共享manifest覆盖；后来根还成为多种无关执行包装的串行签发者，独立工位即使交稿也不能直接推进。**应保留的是内容版本、真实身份、独立审核与真正成片检查；不需要让每个机械执行步骤都重新成为一项审核任务。** 10月4日的直接入口保留原4K/1.5倍/DFN/响度及质量检查，有限技术差分只去掉共享mux和资源准入。这使执行并行度提高，质量检查继续保留。

另一个累积问题是**交接采用完整工作树副本，而非当前稿件与有限差异**。本次逐字节SHA核查发现：项目中4999份 `lecture-mai.json` 只有100种不同内容，4899个路径是相同内容的额外副本；7478份 `READY.sol.json` 只有3584种内容。`batch/`里的raw路径约7.67GiB、79,830项，scripts路径34,732项。大量交接和归档反复携带旧材料，增加目录体积及版本定位负担。相同内容的精确路径组已保存在重复清单中。

## 5. 第22讲的返工、上下文与费用

第22讲的既有量化记录提供另一个阶段：第18讲同27段，首个当前正式成片完成到末次发布核验3小时47分；第21讲20段，2小时39分；第22讲27段，7小时34分。第22讲有9份被取代的正式成片、30次布局测试，以及CPT源音、符号和孤字换行等真正返工。22.20还因工具身份/实际看图覆盖争议，重新实际查看28/28张，成片到发布约210分钟。这些既有质量工作，也有方法/身份取证链变复杂，两者并存。

渲染规模无法独自解释减速：18→22讲成片总长只增加约14%，普通图增加约10%，正式运行区间合计69.3→75.5分钟，但可见窗口翻倍。22讲的最后成片到末次发布尾部约100.5分钟，21讲约10.5分钟。既有响应时延资料没有受控的纯decode TPS，不能证明或排除某时段模型服务变慢；不过有直接证据的流程失败、长尾和返工已足够说明存在额外原因。

成本也不只取决于“让贵模型少做几类任务”：22讲51个Astra会话仍有1162次响应，约1.192亿缓存输入、581万非缓存输入；当时账本的标准费率加权proxy占已识别生产子代理约51.9%。多轮长历史、整份规范/材料反复回显、跨轮重新采用，会让类别减少却没有相应减少调用和上下文。这采用当时标准费率加权账本，核算范围为已识别生产子代理。[22讲原量化复盘](../retrospectives/lecture-22-quantitative-retrospective.md)保留原口径和限制。

总体判断是：**您指出的流程官僚化确实发生过，并在43/44讲有非常具体的阻塞证据；它与真实质量返工共同造成低效。** 记录能定位具体阻塞；各角色净工作与等待时间未完整记录，无法分配全程各因素占比。稳定的参数化入口、交付就接下一项、机械字段由脚本处理、只重审受影响内容，是已有事实支持的方向。本轮不再实施任何流程调整。

## 6. 目录体积与清理计划

统计采用一遍lstat盘点，不跟随软链接。约670,907个常规文件路径、78,714个目录、3275条软链接；常规文件按硬链接去重占 **431.0GiB allocated**，按路径相加则482.4GiB。相差约51.4GiB主要是硬链接重复计数，不能当作可回收空间。`.git`约23.8GiB包含在总量内；后续Git可达性审查已把无引用对象垃圾回收加入计划，详见[Git清理计划](GIT_CLEANUP_PLAN.md)。正式中文QFT MP4共46.19GiB。新审查产物不包含在该盘点中。

建议分批计划：

| 类别 | 已定位数量/候选规模 | 建议 |
|---|---:|---|
| 临时 `work/render-*` 工作帧和编码中间件 | 8886文件；条件去重容量25.31GiB | 优先清理，保留必要失败/修复实证；与正式QA图分别存放 |
| 私人workspace/proposal等媒体副本 | 201文件；条件容量13.69GiB | 同字节副本或已采用主树材料保留后删除；复用主树已采用材料 |
| archive/failed/pre-*旧媒体 | 285文件；条件容量14.83GiB | 保留重要HOLD/物理修复对照，其余过时版本候选 |
| 普通QA抽图 | 72,066文件；去重候选池109.25GiB | 用户已确定删除截图池；正式图资源、物理/质量报告及时钟索引保存 |
| 私人project/clone完整工作树 | 标记池70,328文件、39.32GiB | 汇集唯一正式内容/物理报告后可整树清；与上述媒体等重叠 |
| 相同原始转写JSON副本 | 4999路径、100种内容 | 每种需要的原字节保留一份，索引映射旧路径；逻辑副本超额约5.36GiB，实际释放量还取决于硬链接和保留路径 |
| 非采用ClearVoice试验资源 | 源包约0.66GiB，runtime约0.21GiB | 小报告/试听依据保存后列候选；所选DeepFilter环境6.27GiB建议留 |
| 原始worker日志 | 约19GiB大体积样本 | 保留真实工具/身份实证；可压缩原字节、消除重复前缀副本，不直接整批丢弃 |

未压缩WAV、切分源片及QA池已按用户最新选择纳入计划：当前采用WAV约79.45GiB，切分源片约11.95GiB，加上QA池109.25GiB，约200.65GiB。私人媒体、旧版及渲染缓存另有可释放量，最终按inode合并计算。正式文稿/时间轴/审核与生成文件的选定13,871项只有约0.22GiB；大体积主要来自音频、截图和媒体副本。

未来编辑所需的核心材料、物理存档价值判断、软链接物化方案和具体路径见[清理计划](CLEANUP_PLAN.md)。逐文件分类在 [JSONL清单](cleanup-candidates.sol.jsonl)，其中B项列候选，C项列保留材料。按类别的汇总见[容量JSON](cleanup-candidates.sol.summary.json)，原始盘点见[目录报告](disk-inventory.luna.md)。

本轮没有启动生产进程。清理待备份和用户批准后按选定批次实施。

2026-10-08进一步更新：用户确定未压缩WAV及其它可确定性快速重建的内容可以删除。当前WAV79.45GiB、切分源片11.95GiB和QA截图池109.25GiB合成约200.65GiB清理池。保留完整原录像、转写与正式内容、时间轴、图原资源、物理原报告及重建代码/参数。网页和内部字幕导出也可再生；release中的最终视频和英文SRT保留。方案已更新，尚未实施。

## 7. 改进归属与自主迭代评价的修正

2026-10-08用户纠正：单段烧录内存修复由用户指出问题后推动，不能计为代理自动改进。内存从约33.2GiB降到约2.62GiB的技术结果保留，收益归属于用户推动的纠错。用户要求的完整方程、公式时机、英文视频窗和透明图等也须与代理自主改动分开评价。

因此，此前以这些成品与技术改善支持“自动改进总体有益”的评价高估了自主迭代收益。现有证据支持：自主迭代中有局部有效的提示、脚本及验片方法修正，但中后期流程扩张造成明确负作用，不能认定自主改进好的居多。评价每轮自主改动，应核其发起来源、最终解决的实际问题及反复执行成本；本轮只修正审查结论，不实施流程调整。