wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/technology/Codex/6.建立视频库/2.pyton的yaml.md

12 KiB
Raw Permalink Blame History

1

之前我让你写文档之类的工作时，经常会遇到你说：

索引脚本用系统 python 缺少 yaml，这是环境问题，不是项目证据问题。我会按 Skill 说明改用 conda run -n skills-vault 再跑一次。

解释下，这个环境缺少什么，你的建议？

缺的是 Python 包 PyYAML，它的导入名是 yaml。我刚核对了当前环境：

  • 默认 python 是 C:\Python314\python.exe，版本 3.14.3，yaml_spec=None，也就是没有 yaml 模块。
  • conda 不在 PATH 上。
  • 但 C:\Users\wangq\miniconda3\Scripts\conda.exe 可用。
  • skills-vault Conda 环境可用：C:\Users\wangq\.conda\envs\skills-vault\python.exe，Python 3.11.15，PyYAML/yaml 版本 6.0.3。

所以我之前说“这是环境问题，不是项目证据问题”的意思是：索引脚本失败不是因为项目文档、索引文件、证据链本身坏了，而是运行脚本时用了错误解释器。脚本需要解析 .yaml / .yml，但默认系统 Python 没装 PyYAML。

我的建议：

  1. 不要往 C:\Python314 里补装项目依赖。它是系统/全局解释器，容易让不同项目互相污染。
  2. 对 skills-vault、review helper、索引/验证类脚本，默认用： 
    & 'C:\Users\wangq\miniconda3\Scripts\conda.exe' run -n skills-vault python -B <script-or-module>
    如果某个环境里 conda 已在 PATH，才可以简写成 conda run -n skills-vault ...。
  3. repo 里的自动化说明最好不要假设 conda 在 PATH；应记录显式 conda.exe 路径或提供一个小 wrapper。
  4. 只有当某个脚本明确属于 video-workbench 自己，而不是复用 skills-vault helper 时，才考虑给 video-workbench 建自己的环境依赖。否则继续复用 skills-vault 环境更稳。

一句话：当前机器不缺项目文件，缺的是默认 Python 里的 PyYAML；正确处理方式是使用已配置好的 skills-vault Conda 环境，而不是修系统 Python。

2

正确处理方式是使用已配置好的 skills-vault Conda 环境，而不是修系统 Python

我同意，skills-vault Conda 就是为本地做的通用准备，除非确实有特殊的或者依赖冲突，再重新建一个新conda。 那么，我建议你记录这个到规则里，作为默认conda/python环境，以后就不用每次都调查多次。

你觉得呢？

我同意，而且已经落到规则里了。

我在 AGENTS.md 新增了 Python / Conda Environment 小节，明确：

  • 本 repo 的本地 Python 自动化、验证、索引、helper 脚本默认用 skills-vault Conda 环境。
  • 首选显式路径：& 'C:\Users\wangq\miniconda3\Scripts\conda.exe' run -n skills-vault python -B ...
  • conda 在 PATH 时可以简写。
  • 系统 Python 缺 yaml / PyYAML 不算项目证据问题。
  • 默认不修系统 Python；只有特殊依赖、依赖冲突或项目明确要求时才新建 Conda 环境。

我只改了 AGENTS.md。另外 git status 里有一个未跟踪的 docs/cases/on-the-road-project-evolution-material.md，我没有处理它。

3

另外，关于git。这个项目只是本地做了git提交，但是没有配置对应的远程仓库。 我看到.git/文件夹里有200多M，这个应该是保存了历史的版本。由于这个是图片/视频生产的工作台，所以占地方的都是这些没法差分的二进制。 那么我若同步远程仓库，远程仓库的容量占用也会包括.git 是么？ 问题，主要是远程仓库是我自建的，硬盘比较小。我要权衡下，是否做同步。

是，远程仓库会占用“.git 等价物”的容量，但不是把你本地 .git/ 文件夹原样上传。

Git 远端通常是一个 bare repo，里面保存的是 commits、trees、blobs、refs/tags，也就是 Git 历史对象库。你 push 过去的是当前分支/标签可达的历史对象。对图片、视频这类已压缩二进制，Git 很难有效差分，所以历史里每一个版本基本都会继续占空间。

我刚看了当前仓库：

  • 本地 .git 约 250.8 MiB
  • git count-objects 显示对象还没 pack：size: 250.70 MiB, in-pack: 0
  • 最大的一批 blob 主要是 PNG，每个约 2.4-2.7 MiB
  • 本地其实已经配置了远程 URL：https://git.wantsong.life/wantsong/video-workbench.git，但我没有联网验证远端是否已建好或是否已同步

所以第一次 push 后，远端占用大概率和这 250 MiB 同量级，可能因为 pack 压缩稍小一些，但不会小到“只剩文本项目”的水平。以后每多提交一批生成图、视频、重试图，远端会持续增长。

我的建议是：不要把完整媒体生产历史直接当作默认远程同步策略。更合理的是分层：

  1. Git 同步工作台的“控制面”：project.md、execution-plan.md、slides.md、brief、prompt、handoff、规则、脚本、索引。
  2. 图片/视频成品作为“资产面”：可以本地归档、NAS、对象存储、独立备份盘，Git 里只记录路径、文件名、版本、hash、生成参数。
  3. 已经提交进 Git 历史的媒体文件，如果要让远端变小，光改 .gitignore 不够，必须重写历史或建一个干净的新远程仓库。
  4. Git LFS 可以改善 clone/pull 体验，但如果你的远端也是自建小硬盘，LFS blob 仍然占远端磁盘，只是换了存放位置，不是免费减容。

如果你重视“完整可回滚历史”，同步这 250MB 目前还不算夸张；但这个 repo 是图片/视频工作台，增长曲线会很快。我会倾向于：现在先不要无脑 push 全历史；先决定是否保留媒体历史。如果只是想远程备份流程和文本证据，最好做一次媒体历史瘦身或新建一个 clean remote。

4

当前项目一共475M，除了.git/外还有其他文件，同步的话，远程仓库应该是475m的规模上，进行部分压缩吧？

不是 475MB 这个口径。

你本地现在大概是：

  • 项目总目录：475.9 MiB
  • .git：约 250.8 MiB
  • 去掉 .git 的工作区文件：225.1 MiB
  • 当前 Git 跟踪文件：约 225.0 MiB

本地之所以是 475MB，是因为 Git 仓库本地有两份东西：

  1. 工作区 checkout 出来的真实文件：图片、Markdown、项目文件，约 225MB
  2. .git 里的历史对象库：提交历史、当前版本对象、旧版本对象，约 251MB

远端 Git 仓库通常是 bare repo，只保存第 2 类，也就是 Git 对象库，不额外保存一个 checkout 工作区。所以远端不是按 475MB 上传后压缩，而更接近 .git 的规模，当前大概是 200-250MB 级别，取决于 pack 压缩效果。

但是有两个重要补充：

  • 如果你以后继续把新生成图片/视频 commit 进去，远端会持续按历史增长。二进制旧版本不会因为当前文件被替换就消失。
  • 别人 clone 到本地后，会重新变成类似你的结构：远端对象库 + checkout 工作区，所以 clone 后本地仍可能接近 475MB 或更多。

所以权衡远端硬盘时，看“远端仓库占用”应主要参考 .git / packed object size，而不是项目目录总大小。当前第一次完整同步，我会按 250MB 左右预估；保守一点按 300MB 留空间。后续增长才是主要风险。

5

  1. Git 同步工作台的“控制面”：project.md、execution-plan.md、slides.md、brief、prompt、handoff、规则、脚本、索引。
  2. 图片/视频成品作为“资产面”：可以本地归档、NAS、对象存储、独立备份盘，Git 里只记录路径、文件名、版本、hash、生成参数。

这个策略我基本同意，那么这个是手动控制的，还是要做一个Git策略？

建议做成 Git 策略，不要靠手动记忆。

手动控制可以临时用，但这个 repo 的图片/视频产物会越来越多，靠“下次记得别 add”迟早会失手。更稳的是三层：

  1. .gitignore 控制默认不入库 把生成图、视频、临时渲染、批量输出目录默认 ignore。这样 git add -A 不会误收大文件。

  2. 资产清单入库 Git 里保留文本控制面，比如：

    • prompt / brief / design
    • slides.md
    • image path
    • hash
    • 生成时间
    • 使用的参考图
    • 是否被接受

  3. 少量例外显式入库 关键 anchor 图、小型参考图、最终封面等可以允许入库，但要通过明确路径或命名规则，而不是“所有 PNG 都可以”。

我会建议采用“默认排除媒体，白名单保留少量关键资产”的策略。例如：

# Generated media assets
projects/**/slides/**/s*-v*-image.png
projects/**/slides/**/s*-v*-image.jpg
projects/**/slides/**/s*-v*-image.webp
projects/**/renders/**
projects/**/exports/**
projects/**/videos/**
garden-gpt-image-2/**

# Keep text control files tracked
!projects/**/slides/**/*.md
!projects/**/tasks/**/*.md
!projects/**/visual-system/**/*.md

但这里有一个关键点：.gitignore 只管未来，不会移除已经进入历史的图片。如果你要让远端变小，需要另做一次历史清理，或者更简单地新建一个 clean remote / clean branch，只保留控制面和必要资产。

我的建议顺序是：

  1. 先定 media policy，写进 AGENTS.md 或 docs/workflows/。
  2. 加 .gitignore，防止继续增长。
  3. 再决定当前历史是否要瘦身。
  4. 如果要同步远端，小硬盘场景下优先同步 clean 后的仓库，而不是现有全媒体历史。

6

你可以看下项目在路上的真实结构，占用大的是镜头slides/snn/，镜头目录下是图片和脚本混杂的。 另外visual-system/作为公共部分，intake/作为输入，我觉得是要保留在git里的。

现在在路上已经全部提交了，但是可以参考在路上来考虑后续项目的策略。

看了 在路上 的真实结构后，我会把策略定得更细：不要按 slides/ 目录整体排除，要按“镜头目录里的媒体产物”排除。

当前 在路上 大致是：

  • slides/: 178.61 MiB
    • 其中 PNG：84 个，177.97 MiB
    • Markdown：131 个，只有 0.64 MiB
  • visual-system/: 9.93 MiB
    • PNG：14 个，9.9 MiB
  • intake/: 9.24 MiB
    • PNG：4 个，9.11 MiB
  • archive/: 22.02 MiB
    • PNG：21 个，21.9 MiB

所以你的判断是对的：visual-system/ 和 intake/ 应该保留在 Git 里。它们是输入、身份、风格、公共视觉依据，不是普通生成废料。真正需要控制的是 slides/sNN/ 下的 *-image.png 这类逐镜头生成产物。

我建议后续项目采用这个 Git 策略：

# Per-shot generated media: do not track by default
projects/**/slides/s*/*.png
projects/**/slides/s*/*.jpg
projects/**/slides/s*/*.jpeg
projects/**/slides/s*/*.webp
projects/**/slides/s*/*.mp4
projects/**/slides/s*/*.mov
projects/**/slides/s*/*.wav
projects/**/slides/s*/*.mp3

# Keep per-shot control/script records
!projects/**/slides/s*/*.md
!projects/**/slides/*.md

# Keep project source authorities
!projects/**/intake/**
!projects/**/visual-system/**

# Heavy generated/export areas
projects/**/renders/**
projects/**/exports/**
projects/**/videos/**
tmp/*
garden-gpt-image-2/*

这个策略的核心是：

  • slides/sNN/*.md 入库：brief、prompt、packet、return、review、design 都保留。
  • slides/sNN/*.png/mp4/... 默认不入库：生成图和视频走资产备份。
  • intake/ 入库：用户/GPT 原始输入和输入参考图保留。
  • visual-system/ 入库：角色、风格、公共参考、anchor 资产保留。
  • archive/ 后续要谨慎：如果是废弃生成图，不建议默认入库；如果是退役但仍有解释价值的角色/风格依据，最好移动或归档到 visual-system/ 的有说明位置。

当前 .gitignore 只排除了 tmp/ 和 garden-gpt-image-2/，对后续项目不够。在路上 既然已经全部提交，可以先不动历史，把它当作样本；但从下一个项目开始，应该把这个 media policy 写进 .gitignore 和工作流规则里，否则每次 git add -A 都会继续把镜头图收进去。

7

是的archive/现在都是废弃图，废弃文档，不入库

把这个补一下，放到.gitignore 和工作流规则里

打Tag，完成在路上

然后同步远程库。