232 lines
12 KiB
Markdown
232 lines
12 KiB
Markdown
# 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、索引/验证类脚本，默认用：
|
||
```powershell
|
||
& '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](/C:/Users/wangq/Documents/Codex/video-workbench/AGENTS.md:16) 新增了 `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 都可以”。
|
||
|
||
我会建议采用“默认排除媒体，白名单保留少量关键资产”的策略。例如：
|
||
|
||
```gitignore
|
||
# 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 策略：
|
||
|
||
```gitignore
|
||
# 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，完成在路上
|
||
|
||
然后同步远程库。 |