第 2 篇 · CH04

把文件、创作决策、AI协作与版本历史组织成安全、可审查、可恢复的单人制作系统。

当前状态

完整章

预计学习时间

10 小时

关键概念

工作区 · 仓库 · 工作树 · 暂存区 · 提交 · 变更审查 · AGENTS.md · 密钥边界 · 可恢复性

案例文件

`AGENTS.md`、`demo/echo-cabin/AGENTS.md`、`demo/echo-cabin/production/shot_list.csv`

本章产出

建立Windows项目与媒体边界、用Codex完成有边界的文本协作

最后核验

2026-09-05

第4章　Windows、Codex与Git的单人制片工作法

写作状态

本章为完整章节。命令默认在 Windows 11 的 PowerShell 中执行；只有明确标注“AutoDL SSH / Linux”的代码才可在远程 Linux 终端执行。

导读

第一次独立制作 AI 微电影时，人们通常把注意力集中在“哪一个模型更强”“提示词怎么写”或“怎样让画面动起来”。真正让项目夭折的，却常常是更朴素的问题：剧本有三个版本，不知道哪一个被导演批准；镜头表改了编号，提示词还沿用旧编号；生成文件散落在下载目录；AI 助手一次改了几十个文件，作者没有看清变化；电脑重装后，只剩下成片片段，却失去了制作依据。

这不是整理习惯不好，而是生产系统没有建立。电影制作把创作意图分散在剧本、分镜、资产、现场记录、声音、剪辑和交付文件之中。AI 制作又增加了提示词、参考图、模型版本、随机种子、工作流和生成日志。单人创作者同时担任编剧、导演、制片、数据管理员和最终批准者。如果不把这些角色的责任写进文件结构，记忆就会成为唯一的连接层；一旦时间过去、工具切换或设备损坏，项目便无法解释，更无法恢复。

本章不把 Git 当成程序员的专属工具，也不把 Codex 当成可以替代作者的自动导演。我们把 Windows 文件系统看成片场，把项目目录看成制片办公室，把 Git 看成保存“可解释决策”的场记系统，把 Codex 看成受任务书约束的协作人员。目标不是掌握大量命令，而是建立一条任何时候都能回答六个问题的工作链：我在哪里？当前依据是什么？谁改了什么？为什么改？哪些内容已经批准？出现事故时从哪里恢复？

如果你是零基础读者，请按本章顺序操作，不需要预先理解编程。每段命令前都会说明窗口、目的和预期现象。若实际结果不同，先停止并阅读诊断段落，不要为了“让命令通过”而复制陌生的删除或覆盖命令。

知识地图

三张图分别回答三个层次的问题。第一张图说明素材、文本与工具怎样分层；第二张图说明一次修改如何经过任务约束、差异检查和作者批准；第三张图说明“恢复”为什么始于停止写入、确认范围和选择可信恢复点，而不是立刻执行撤销命令。

学习目标

完成本章后，你应该能够：

1. 在 Windows 中准确辨认资源管理器、PowerShell、编辑器和 Codex 各自显示的“位置”，并验证自己位于正确项目根目录。
2. 设计仓库、外部媒体库、缓存、密钥和备份的边界，让文本容易追踪，让大文件和隐私信息不会误入 Git。
3. 阅读 git status、git diff 与 git diff --staged，把“文件发生变化”翻译成“创作决策发生变化”。
4. 用一份有范围、输入、禁区、完成条件和验证方法的任务书与 Codex 协作，并对结果保留最终批准权。
5. 创建小而完整的提交，理解分支、工作树和提交之间的关系，而不是机械背诵命令。
6. 面对误改、冲突、设备损坏或重装时，先保护现状，再从经过验证的提交或备份恢复。
7. 为《回声舱》或自己的原创片建立可移交的制作记录，使另一个人即使没参加创作，也能理解当前版本。

核心概念

1. 路径、文件夹、项目根目录与工作区

路径是文件在存储系统中的地址，例如 D:\AI-Film\echo-cabin\README.md。文件夹是容器。项目根目录是项目约定的起点，常包含 README.md、AGENTS.md、.git和主要内容目录。工作区是你当前允许工具读取和修改的范围，它可能等于项目根目录，也可能包含多个相关目录。

Windows 的反斜杠、盘符和带空格路径会影响命令解析。PowerShell 中处理真实路径时，优先使用 -LiteralPath；进入带空格目录时给路径加引号。不要因为资源管理器打开了某个文件夹，就假设 PowerShell 和 Codex 也位于同一位置。三个界面都需要独立确认。

2. 仓库、工作树、暂存区与提交

仓库保存 Git 对历史的记录；工作树是你正在编辑的文件；暂存区是“准备纳入下一次提交”的选择；提交是被记录的一次快照。可以把它们想成剪辑室：工作树是桌面上的当前素材，暂存区是本次输出清单，提交是封存并写有场记的版本。

git status描述当前状态，git diff显示未暂存变化，git diff --staged显示已选择进入下一提交的变化，git log查看历史。它们都是只读检查，适合在不确定时先运行。git add和git commit会改变状态，但通常可追溯；删除、强制重置、清理未追踪文件则必须更谨慎。

3. 分支与独立工作树

分支是指向某条提交历史的可移动名称。它让一组尚未批准的工作与正式主线分开。Git worktree 可以让同一仓库的不同分支在不同目录同时存在，适合把“幸存版本”和“整合版本”物理隔离。分支不是备份：如果仓库所在磁盘损坏，分支也会一起丢失；远端或 bundle 才能形成不同位置的副本。

4. Codex 项目、任务与规则文件

Codex 项目关联一个工作目录。任务承载一次明确协作。AGENTS.md为目录树提供可复用规则；根目录规则提供通用边界，子目录规则可为更窄范围补充或覆盖规则。规则文件不是创作内容本身，也不能代替任务说明。优秀任务书仍应指出目标、输入、范围、禁区、完成条件和验证方式。¹

5. 变更审查与作者批准

变更审查关注实际差异，而不是工具的口头总结。作者批准是创作责任：确认差异忠于主题、连续性和生产事实。自动测试可以验证格式、链接、字段和数量，却无法决定一次停顿是否有情感力量。技术通过与创作批准是两道不同的门。

6. 密钥边界

密钥包括 API token、访问令牌、私有 SSH 密钥、带认证参数的链接和某些账户配置。它们不应写进教材、提示词示例、截图、日志或公开提交。发现泄露时应停止传播、撤销或轮换密钥，再处理历史；只删除当前文件是不够的。

7. 可恢复性

可恢复性是从明确恢复点重建可用项目的能力。它由历史、备份、说明和验证共同构成。恢复点必须知道“恢复到什么状态”；副本必须能读取；外部依赖必须有清单；私人媒体和模型若不进入 Git，就必须有独立迁移方案。

本章理论命题

单人 AI 制片的可靠性，不取决于创作者能否记住全部细节，而取决于创作状态能否被外化、审查、批准和恢复。

这一定义包含四层意思。第一，文件名、目录和镜头 ID 是叙事生产的基础设施，不只是行政工作。第二，AI 可以提出、整理和修改，但创作批准必须有明确的人类责任主体。第三，版本历史的价值不在于“保存得多”，而在于每个恢复点都能说明一项完整决策。第四，备份只有在另一位置、可读取且能够还原时才成立；同步图标、压缩包文件名或一次成功的复制提示，都不能独立证明可恢复。

理论模块一：项目文件是外化的创作记忆

电影是一种跨时间协作的艺术。剧本写作时决定人物欲望，分镜阶段把欲望转成空间和视线，生成阶段把静态设计转成运动，剪辑阶段又重新解释前面的材料。单人创作者虽然没有庞大团队，仍然在不同日期扮演不同职能。昨天的“导演”与今天的“剪辑师”并不共享完整记忆。因此，文件系统的首要职责不是把东西放整齐，而是让未来的自己能够重建当时的判断。

外化记忆至少需要三类信息。第一类是作品状态，例如当前剧本、镜头表和角色定稿。第二类是决策依据，例如为什么选择或排除某种机位方案，为什么拒绝某个角色参考。第三类是生产证据，例如提示版本、生成参数、失败原因和技术检查。只保存最终文件，会留下结果而没有推理；只保存全部尝试，又会形成无法辨认主次的“文件坟场”。有效系统必须同时标出当前版本、历史路径和批准状态。这个三分法是本教材结合单人 AI 制片所作的工作性总结。¹⁰

经典案例：《记忆碎片》的秩序与可解释性

《记忆碎片》把信息顺序变成叙事机制。观众接触到的片段并不少，困难在于每个片段与因果链的关系需要不断重建。项目目录也可能出现同样的问题：final.mp4、final2.mp4、最终真的版.mp4都是真实文件，却没有提供可靠顺序和决定依据。数量没有形成记忆，命名也没有形成历史。⁶

这部影片给工作台的启示不是模仿其倒叙，而是认识到“顺序”会改变理解。镜头提示如果脱离对应的镜头卡，就像一段失去时间位置的场景；参数截图如果没有镜头 ID，就无法证明属于哪次生成。Git 提交提供一种有序的文本历史，但只有在提交说明表达决策时才有意义。update files几乎不能帮助未来的你，而“固定 SH-005 机位并补充动作剪辑把手”能够直接连接到导演意图。

《回声舱》深度推演一：从 SH-005 追到计划依据

《回声舱》的当前 SH-005 是主人公按住通讯键、问出“你怎么证明你是我？”，随后松键并看向气闸的计划镜头。它至少涉及镜头表中的时长、景别和短横移，视频提示中的按键、呼吸、台词与安静剪辑把手，声音表中的按键声和室内底噪，以及剪辑计划中的切点。它们仍都是教学文本和待生成计划；如果被分别命名为“第五个”“特写2”“新声音”和“最终版”，关系只能存在于作者脑中。

统一使用 SH-005 后，检索便成为最便宜的生产控制。你可以在项目根目录搜索这个 ID，检查所有文本是否仍指向同一叙事事件。当前《回声舱》登记的是 7 秒、中景、过肩视角与短横移；视频提示也应与这一计划相互核对。若未来某次教学推演提出固定机位，而提示却要求快速环绕，差异会在生成前暴露；但它必须写成未批准的备选方案，不能倒灌为当前项目事实。

这里的关键不是“所有文件必须完全一样”，而是差异必须有理由。例如将来若镜头表分类为固定机位，提示词又写“几乎不可察觉的前移”，可把前移解释为生成模型的微小稳定补偿，但这一例外应写入制作笔记。可解释的差异是导演选择，不可解释的差异是生产事故。

成功、失败与边界（一）

成功方案：目录中只有一份被标为当前的镜头表；每个提示、声音事件和质控条目都使用稳定镜头 ID；重大改变由一条提交说明记录原因。三个月后打开项目，创作者能在十分钟内重建 SH-005 的状态。

失败方案：每次修改都另存一个“最终版”，镜头编号在不同文件中漂移，AI 对话承担了全部说明。聊天记录一旦丢失，文件仍在，却无法判断哪个结果可信。

边界情况：探索早期不必为每个草图建立严密审批。可以设置 exploration 区域，允许快速试验；一旦某个结果进入镜头生产，就必须获得稳定 ID、来源记录和明确状态。系统要约束进入生产线的材料，而不是消灭探索。

理论模块二：文本历史与媒体存储必须分层

Git 特别擅长比较文本：一行提示词被删除、一个镜头时长由 6 秒改为 4 秒、一个批准字段被改变，都能清楚显示。大型视频、模型权重和批量生成图像则不同。它们通常难以逐行比较，体积增长极快，而且可能包含许可、隐私或平台限制。把所有东西塞进一个仓库，看起来“集中”，实际上会让克隆、审查和恢复都变得沉重。

适合进入教材或项目仓库的通常包括：Markdown 文档、CSV 表格、JSON 配置、SVG 图解、小型脚本、提示词、少量经过许可且确有教学价值的精选媒体。通常应留在外部媒体库的包括：模型权重、缓存、虚拟环境、批量生成结果、代理文件、原始录音、未授权参考、密钥和临时下载。两类存储通过镜头 ID、资产 ID、相对路径登记或校验值建立联系，而不是靠“都放在同一文件夹”建立联系。

.gitignore只告诉 Git 哪些未追踪路径通常不应加入版本历史。它不是加密工具，也不会把已经提交过的密钥从历史中抹除。若一个密钥曾经进入提交，即使后来把文件加入 .gitignore，仍需撤销并轮换该密钥。密钥应优先放在操作系统凭据存储、受保护的环境变量或平台推荐的秘密管理位置，示例文件只保留变量名和假值。Git 命令的准确作用范围应以官方参考为准。²

经典案例：《后窗》的观察边界

《后窗》把观察范围限制在一个窗口与庭院。限制没有让信息变少，反而让观众清楚知道“我们看见了什么、看不见什么、哪些判断只是推断”。项目边界也承担相似功能。仓库应该明确声明它追踪什么，不追踪什么；外部媒体库应该有索引；未进入仓库的内容不能被假装已经备份。⁷

当边界模糊时，创作者容易犯两种相反错误：以为云同步了项目目录便等于保存全部素材，或以为把全部素材复制到仓库便等于安全。前者忽略外部引用，后者忽略仓库体积、许可和泄密风险。像影片中的观察者一样，生产系统必须承认视野边界，并为视野之外的部分建立另一套登记和备份。

理论模块三：差异审查是创作批准的技术形式

创作批准不是在聊天里说一句“可以”，而是确认一组具体变化符合意图。Git 的差异视图恰好提供了审查对象：哪些行新增、哪些行删除、哪些文件移动。它不会替你判断艺术质量，却能确保你正在判断真实发生的变化，而不是 AI 对变化的自我描述。

Codex 在项目中可以读取规则、分析文件、提出计划、修改文本和运行检查。项目级 AGENTS.md用来告诉协作者长期有效的边界，例如教材语言、命令环境、不可覆盖的批准字段和验证要求。更深目录的规则可针对具体子项目补充限制。任务提示则负责本次工作：目标是什么、允许修改哪些路径、哪些内容不得动、完成后运行哪些检查。长期规则与一次任务分开，能减少提示词越来越长却仍遗漏关键约束的问题。¹

《回声舱》深度推演二：把备选固定机位写成可审查的假设

SH-005 当前登记为短横移，并没有“迅速推进、环绕人物”的旧提示。现在另设一个不写入当前计划的教学假设：“人物按住通讯键质问时努力保持镇定；摄影机不替她惊慌。”如果把它发展成固定机位备选，任务只能起草探索文件，不得修改当前镜头 ID、台词、时长或状态。

备选草案写完后，作者不先接受总结，而是阅读差异：是否清楚写出“固定机位”相对于当前短横移的代价；表演是否被拆成按键、受控呼吸、提问、松键与安静停留等可观察阶段；负面约束是否排除了大幅摇头和夸张惊讶；是否意外改变其他七个镜头。只有这些问题逐项得到答案，作者才可能决定要不要启动一次受控比较；它本身仍不是创作批准。

差异审查还会发现看似细小的责任越界：AI 为了让验证通过，把 approved从 false改成true；重新格式化 CSV 时改变了引号；将“待生成”媒体写成已有文件；把 Windows 命令换成 Bash。这些变化未必恶意，却会破坏生产事实。自动化可以检查结构，不能自行制造批准。工具提供的代码审查能力可以帮助定位问题，但不能取代上述创作责任。⁵

成功、失败与边界（二）

成功方案：任务限定两个文件；Codex 修改后列出实际文件；作者用差异逐行判断；结构验证通过；最后提交说明写出镜头意图与影响范围。

失败方案：提示只写“优化整个项目”；AI 同时改剧本、镜头、提示、状态与导航；测试通过后直接提交。测试只能证明规则允许这些内容，不能证明作者真的批准了每个创作变化。

边界情况：机械重排或统一格式可能产生很大差异。此时先单独提交格式化，再提交内容改变，避免两种变化混在一起。若无法分开，至少使用路径级检查和统计摘要，确认没有批准字段或镜头 ID 被意外改写。

理论模块四：提交应表达一个可以解释的决定

Git 中的提交（commit）是一个项目快照，同时保存父级关系、作者、时间和说明。对创作者而言，最有用的理解是“可以独立解释、独立审查、必要时独立撤回的一项决定”。提交太大，事故恢复会连带丢掉无关工作；提交太碎，每一个标点都成为历史噪声。合适粒度通常围绕一项创作或工程意图。工作树、暂存区、提交与分支的基础模型可参见 Pro Git。³

例如“补齐第4章工作簿、图解和验证”可以构成一项完整改变，因为三者共同定义章节交付；“顺便重写第5章”则应拆开。又如“记录 SH-005 固定机位备选并同步其声音假设”可以包含多个探索文件，因为它们属于同一镜头决策；在作者批准前，它不应覆盖当前短横移计划。路径数量不是粒度标准，意图的完整性才是。

经典案例：《窃听大阴谋》的材料再解释

《窃听大阴谋》中，同一段录音因重听、强调和语境改变而获得不同意义。版本历史也不是把过去封死，而是让创作者看到解释如何变化。第一次提交可能把停顿理解为恐惧，第二次改为隐瞒，第三次通过声音延迟让两种读法并存。历史的价值在于呈现决策链，使回退不是盲目复原旧文件，而是重新选择某个创作立场。⁸

但 Git 不能自动保存所有外部媒体，也不能证明某个生成结果优质。它保存的是被纳入追踪的状态。若提交说明与内容不符，历史仍会误导。因此，每次提交前至少要回答：这次决定是什么？哪些文件实现它？哪些验证已经运行？哪些事实仍待生成或实机验证？

理论模块五：恢复从“停止扩大损失”开始

新手遇到误删或错误修改时，最危险的冲动是连续尝试陌生命令。恢复操作往往也会写入磁盘或改变工作树；如果连现状都没有记录，就可能把仍可救回的内容覆盖。可靠恢复遵循“止损—取证—分级—副本验证—执行”的顺序。

止损意味着暂停生成、同步、清理和批量重命名。取证意味着记录当前路径、git status、磁盘位置、异常发生时间和已知操作。分级意味着区分未提交文本、已提交文本、未追踪媒体、外部备份与设备级损坏。副本验证意味着在可能的情况下先复制或打包当前状态，在另一目录验证恢复方案。最后才选择针对性动作。

常见事故的处理边界不同：已提交文本通常可从 Git 历史读取；未提交文本可能仍在工作树、编辑器历史或本地快照；从未进入 Git 的视频不能靠 Git 恢复；被云同步删除的文件要检查服务回收站和版本历史；格式化磁盘后的恢复则应优先减少写入并咨询专业数据恢复，而不是继续安装软件到同一磁盘。这里没有一条万能命令。

成功、失败与边界（三）

成功方案：发现批量误改后立即停手，保存状态与差异，在仓库外建立当前工作树副本，然后从已知提交提取单个文件进行比较。恢复目标明确，原现场仍保留。

失败方案：不看状态就运行破坏性清理或强制重置，希望“回到正常”；结果未追踪文件和未提交修改同时消失，而且没有副本可供复核。

边界情况：版本控制命令有时确实是最快恢复方式，但必须先明确命令将影响已追踪还是未追踪文件、单个路径还是整个仓库，以及是否已有可验证恢复点。本书不把高风险命令作为新手快捷方式。

理论模块六：备份必须以可还原为判据

“我已经复制了”只是动作，“我可以从副本还原”才是结果。有效备份至少回答：副本位于哪个独立故障域；覆盖哪些文件；何时创建；是否完整；是否能读取；恢复步骤是否已演练。把两个副本放在同一块物理硬盘的不同文件夹，可以防误删，却不能防硬盘损坏。云同步可以提供异地副本和版本，但同步也会传播删除、加密或错误覆盖，所以不能替代独立历史备份。

文本仓库可以创建 Git bundle，把分支、提交和标签封装为单文件，再生成 SHA-256 校验值。外部媒体库则适合采用清单：相对路径、大小、修改时间、可选校验值和许可状态。校验值能够发现位级变化，但不证明内容语义正确；一次测试还原能够验证结构和读取，却仍要结合抽样播放视频、打开工程文件和检查关键表格。备份之外必须安排恢复演练，这与信息系统连续性规划中“验证恢复能力”的基本原则一致。⁹

理论模块七：状态、文件与事实必须分开

零基础创作者容易把三种东西混为一谈：磁盘上有一个文件、表格里登记了一个状态、现实中已经完成了一项工作。它们可能一致，也可能不一致。SH-003_v002.mp4存在，说明某处有一段名为该名称的文件；它不自动说明文件能够播放，也不说明内容属于当前提示，更不说明导演批准采用。表格中写“已完成”同样只是一条陈述，需要文件、日志和观看判断支撑。

可以把生产状态分成五级。第一级是“计划”：镜头、资产或媒体位已登记。第二级是“文本就绪”：提示、参数或工作流说明已经写好。第三级是“技术产出”：模型或软件产生了文件，且基本技术检查通过。第四级是“创作选择”：作者观看多个结果后选择某一版本。第五级是“交付采用”：该版本已经进入时间线、通过整体检查并包含在交付包中。不同项目可以换名称，但不能用一个含糊的“完成”遮住五个层次。

这种分级对 AI 生成尤为重要。生成接口可能先返回任务编号，随后排队、运行、失败或完成。接口接受请求只到达“任务已提交”；历史记录显示成功且输出文件存在，才到达“技术产出”；播放文件、检查内容、与相邻镜头比较后，才可能成为“创作选择”。如果教材没有真实运行 H3，就只能把提示与适配卡标记为教学参考或待实机验证。

状态迁移还需要权限。自动脚本可以把“缺少文件”判断为“结构不完整”，可以在检测到文件后建议进入技术检查，却不应自行把镜头标为“导演批准”。Codex 可以生成质控清单并指出证据，但最终艺术判断属于创作者。批准字段之所以需要保护，不是因为 AI 永远会犯错，而是因为责任不能由数据处理动作悄悄改变。

对于小白，一个实用方法是在每项状态后面写“凭什么”。例如：文本就绪——提示文件存在且字段校验通过；技术产出——文件可播放，8秒，1920×1080，有音轨；创作选择——2026-09-05观看后选中，理由为视线和停顿最接近导演阐述。证据越具体，未来越不需要猜。

理论模块八：目录结构是一种低成本的制片调度

一个好的目录不追求层级越多越专业，而追求“从入口到目标不需要猜”。根目录应当有入口文档，告诉读者产品是什么、如何验证、哪些内容不在仓库。创作文件、生产表格、提示、报告和精选媒体应有清晰职责。临时内容与正式内容分开，原始材料与派生材料分开，可重建内容与不可替代内容分开。

目录设计需要同时考虑人的阅读和工具的遍历。人希望名称有意义，工具希望模式稳定。例如 course/chapters/ch04.md可由章节索引推导；prompts/video/SH-005.md可由镜头 ID 检索。若把全部文档平铺在根目录，人会迷失；若为了分类建立十层空目录，路径变长且难以移动。通常在三至五步内从项目入口到核心文件已经足够。

命名规则要优先表达身份，再表达试次和版本。SH-005_take-003_v001.mp4比第三次新版本.mp4更稳定，因为“第三次”仍知道属于哪个镜头。日期适合日志、备份和交付包，例如 2026-09-05-handoff.md；不宜替代镜头身份。版本号适合表达同一对象的技术演进，但是否批准仍须状态记录。

目录还应该容纳失败。生成失败不是垃圾，而是边界知识：哪个提示导致身份漂移，哪个运动组合造成空间扭曲，哪个参数超出模型能力。并非所有失败媒体都要永久保存；至少应保留有代表性的失败描述、低体积预览或参数记录。批量失败原片可以按保留策略清理，但清理前确认它们没有被案例、报告或剪辑引用。

对《回声舱》而言，八个镜头规模很小，仍值得建立目录规范，因为它是后续原创片的训练场。若在八镜头时学会稳定 ID、状态和边界，扩大到四十镜头仍能沿用；若八镜头就依赖个人记忆，规模扩大只会放大混乱。制片系统的价值不是为当前复杂度增加仪式，而是让复杂度增长时不必推倒重来。

理论模块九：最小操作闭环比命令大全更重要

学习 Git 容易陷入命令收集：知道几十个子命令，却在真实事故中不知道先用哪一个。小白更需要一个稳定的最小闭环。第一组是位置检查：Get-Location、目录列表、仓库根。第二组是状态检查：git status、未暂存差异、已暂存差异。第三组是历史检查：简短日志、具体提交内容。第四组才是有意改变状态：选择路径、提交决定。恢复与清理不属于每日快捷动作，应在有副本和明确范围时使用。

每条命令都可以用四问法理解。它读取还是写入？作用对象是一个文件、当前工作树、整个仓库还是远端？失败时是否保持原状？执行后用什么独立方式核验？例如 git status只读取状态，风险低；git add改变暂存区，但不改变工作文件；git commit创建历史；推送会改变远端；递归删除会直接影响文件系统。把命令放在责任模型中，比记住拼写更可靠。

PowerShell 也应采用同样方法。Get-Content读取文件，Get-FileHash读取并计算校验值；Set-Location只改变当前会话位置；New-Item会创建对象；移动、覆盖和递归删除会改变磁盘内容。Windows 文件路径含空格、方括号或通配符字符时，-LiteralPath可以减少意外解释。这里的命令语义与参数仍应查阅 Microsoft 官方文档。⁴

当命令输出与预期不同，不要立即执行网上搜到的第二条命令。先抄下完整错误、当前目录、工具版本和目标路径。许多问题只是处在错误目录、使用了另一套 Python、尚未安装依赖或没有访问私有仓库的凭据。诊断的第一任务是缩小不确定性，而不是让红色文字尽快消失。

理论模块十：交接文档把个人项目变成可持续项目

单人项目也需要交接，因为未来的自己就是下一位接手者。设备迁移、系统重装、课程暂停和工具升级都会造成上下文断裂。一次高质量交接不要求复述全部历史，而要提供能够继续工作的最小充分信息。

最小交接包括七部分：作品目标与当前范围；正式分支和提交；已经完成并验证的内容；尚未完成或仅文本就绪的内容；外部媒体、模型与凭据的位置说明；能够重现检查的命令；下一步与已知风险。若存在多个版本，还要说明它们的关系，例如“十二章教材为活动主线，80课和43课仅为归档资料，不进入导航”。

交接中的措辞必须校准证据。“已提交”表示本地提交存在；“已推送”表示远端包含提交；“已合并”表示目标分支包含变化；“网站构建通过”表示构建命令成功；“视觉检查通过”表示在指定宽度实际查看；“媒体验收通过”表示真实媒体被播放和判断。将这些词分开，接手者才不会重复劳动或建立在错误前提上。

对于《回声舱》，交接还应说明八份图片提示和八份视频提示是否只是教学参考，哪些媒体位待发布，当前 H3 适配卡的核验日期，以及工作流文件是否真实存在。明确缺失不是失败，而是保护事实。项目最危险的状态不是“尚未生成”，而是文档声称已经生成、读者却找不到证据。

最后，交接应能在另一台电脑上被执行。路径不要只写“桌面那个文件夹”，命令标明 PowerShell 或远程 Linux，依赖写进声明文件，私有仓库说明登录前提。真正的迁移测试是在新位置克隆或还原、运行验证并打开关键产物；仅在原电脑上写出步骤仍然只是一份计划。

案例推演

《回声舱》的目录为什么这样分

下面是一个教学化结构，不要求你的项目逐字一致：

echo-cabin/
├─ AGENTS.md                 项目协作规则
├─ README.md                 入口、当前状态与恢复说明
├─ story/                    梗概、剧本、导演阐述
├─ production/               镜头表、资产表、声音表、剪辑计划
├─ prompts/                  图片与视频提示，按稳定 ID 命名
├─ reports/                  生成日志、质控与决策记录
└─ media-index/              外部媒体登记，不伪装实际媒体

D:\AI-Media\echo-cabin\      仓库外媒体库
├─ source\                   原始且尽量只读
├─ generated\                批量生成结果
├─ selected\                 已选素材
├─ proxy\                    可重建代理
└─ delivery\                 交付导出

仓库中的文本可以小步审查，媒体库承担容量。两者必须通过稳定 ID 连接。例如 SH-005_take-003_v001.mp4能说明镜头、试次和文件版本，但“v001”不是创作批准；批准状态仍应记录在镜头表或选择日志中。原始素材目录最好避免覆盖，代理和缓存则明确可重建。

一份足够明确的 Codex 任务书

示例性质：这是供练习差异审查的假设任务，不描述《回声舱》的既有修改，也不授权改动其生产记录。

目标：为一个备选的固定机位方案起草视频提示与决策说明，比较它是否比已登记的短横移更适合克制表演。

依据：
- production/shot_list.csv 中 SH-005 当前登记的时长、景别、短横移和叙事功能；
- 当前视频提示；
- AGENTS.md 的项目规则。

允许创建：
- `exploration/SH-005-fixed-camera-alternative.md`
- `exploration/SH-005-camera-comparison.md`

不得修改：
- 当前镜头表、提示、批准状态、台词、其他镜头；
- 不创建图片、音频或视频；
- 不把待生成内容写成实际存在。

完成条件：
- 备选表演拆为可见阶段；
- 说明备选摄影机运动与主体运动的关系；
- 记录比较理由和仍待验证项；
- 展示差异；不把文本草案声称为已生成或已批准。

它没有规定每一句文字，因此仍给协作者留出判断空间；同时边界足够清楚，使审查可以回答“是否完成”。如果输入文件不存在，正确行为是报告缺失，而不是虚构一个看似完整的结果。

从修改到提交的证据链

一次完整任务应留下：任务意图、实际差异、验证结果、未决事项和提交说明。它们可以分别位于任务对话、Git diff、终端输出、决策记录和提交历史，但最终 README 或移交文档要能把这些信息串起来。对外说“已经完成”时，应区分：文本已写、自动检查已过、网页已构建、媒体已实机生成、创作者已观看批准。五者不是同义词。

一次完整工作日：从开机到安全收工

为了让抽象方法落到实际动作，下面模拟一个不写入《回声舱》现有文件的教学工作日。当前项目事实是：SH-005 仍为 planned/pending，登记为 7 秒中景、过肩视角和短横移；没有已生成媒体，也没有“旧环绕版本”或“固定机位改稿”的历史。模拟目标因此不是篡改这些事实，而是为一个独立的备选固定机位草案写出比较记录。输入是当前登记、视频提示和导演阐述；交付仅为 exploration/ 下的草案与决策说明。

上午开始时，创作者先打开项目，却不立刻让 Codex 工作。他在 PowerShell 查看当前位置与仓库根，发现当前目录其实是旧备份 echo-cabin-copy。如果忽略这一步，后续修改可能全部发生在无人使用的副本里。进入正式目录后，git status显示第3章有一份昨天未提交的用户修改。它与今天任务无关，因此不能被覆盖，也不应顺手纳入提交。创作者把这一事实写入任务边界。

随后他阅读项目入口和子目录规则，确认视频提示只提供教学文本，不代表 H3 已实机生成；批准字段不能由自动化自行改变。任务书要求 Codex 只读取 SH-005 的相关文件，报告当前计划与备选想法的差异，再只创建两份探索草案。Codex 发现当前短横移要同时协调侧向画面变化、按键动作和提问，而固定机位会把注意力更多留在听觉反应；这是一项待比较的导演选择，而非既有冲突。它把备选表演拆成可见阶段，并在决策记录中写明其假设和待验证项。

工具报告完成后，创作者先看 git status --short。如果出现第三个文件，先查明原因。再看 git diff --stat理解变化规模，最后读两个文件的完整差异。他检查删除内容是否只是冲突描述，新增内容是否真的可见、可生成，时长是否仍为当前登记值，声音事件是否被擅自移动。发现 Codex 顺手统一了另一个镜头的标点，他要求撤回该无关变化，而不是接受“只是格式化”。

差异收窄后运行项目验证；若探索目录不属于当前验证范围，则记录这一限制而不是虚报“全部覆盖”。验证器可以确认 ID、字段和引用，但不能判断“短暂屏息”是否过于戏剧化。作者朗读备选表演阶段，想象镜头持续时间，决定把吞咽改成一次短暂屏息。再次审查后，他只暂存两份探索文件，查看 staged diff，提交“docs: 记录 SH-005 固定机位备选方案及待验证项”。提交后，第3章的未提交修改仍然存在，这正是保护用户工作而非追求空白状态的结果。

收工前，他没有简单写“今天完成”。交接记录写明：备选文本与结构验证已完成；H3 未实机生成；固定机位仅是等待比较的未批准方案；昨日第3章修改仍未提交；当前提交编号是什么；bundle 最近一次验证日期是什么。即使电脑当晚损坏，远端或 bundle 能恢复今天的文本决策，外部媒体则由另一份备份承担。

这个工作日并不依赖高级 Git 技巧。它依赖的是顺序：位置先于修改，范围先于授权，差异先于批准，验证先于声明，恢复点先于收工。小白只要稳定重复这条顺序，就已经具备比“会很多命令但不看范围”更可靠的生产能力。

三种项目规模方案及其成本

同一套原则可以用不同复杂度实现。最小方案适合一至两周、八镜头以内的练习片：一个 Git 仓库、一个外部媒体目录、一份 README、一份镜头表、一份备份清单。每个工作日结束时提交完整决定，每周复制一次媒体。它的优点是负担低，缺点是并行试验与多人接手能力有限。

标准方案适合一至三分钟原创片：仓库按故事、生产、提示和报告分区；媒体按原始、生成、选择、代理和交付分区；每个镜头有稳定 ID；重要试验有日志；正式变化通过分支或小提交组织；远端加离线副本；每个阶段做恢复抽查。它增加少量维护，却能清楚支持几十个镜头和多轮修订。

扩展方案适合多人或大量生成：除上述结构外，还可能使用对象存储、媒体资产管理、Git LFS、自动清单、权限控制和持续集成。工具更强，但配置、费用和恢复复杂度也更高。个人学习项目不应因为“专业”而直接采用最重方案。系统复杂度也会制造故障，只有当镜头数、协作人数或媒体规模真的需要时才升级。

选择方案时可问四个问题：不可替代数据有多少；单次失败最多能承受丢失多少工作；换电脑时需要多久恢复；除自己之外是否有人需要理解项目。如果答案是“几乎没有真实媒体、一天损失可接受、两小时可重建、只有自己”，最小方案足够；若已经有私人配音、数百个生成版本和正式交付，标准或扩展方案才合理。

《回声舱》在教材中采用标准方案的简化形式，不是因为八镜头本身需要复杂管理，而是它承担教学示范。读者可以看到镜头表、提示、声音与剪辑如何通过 ID 关联，也能清楚看到哪些媒体尚未生成。迁移到原创片时，不必复制每一个目录；应复制判断原则，再按真实规模删减。

范围失控的修订示范

原始任务：“把《回声舱》项目优化得更专业。”这句话几乎无法审核。“专业”可能指剧本、视觉、命名、网站、代码、视频参数或版权说明；“项目”允许修改全部路径；没有完成条件，也没有禁止自动批准。即使 AI 产出很多内容，作者也无法判断工作何时结束。

第一次收窄：“检查所有 SH-005 文件并修复不一致。”它已经有对象，但“所有”和“修复”仍然危险。检查可以是只读，修复会写入；不一致可能是错误，也可能是有理由的跨文件表达。我们应先把诊断与修改分成两步。

诊断任务可以写成：“只读取镜头表、SH-005图片提示、视频提示、声音表和剪辑计划，列出镜头ID、时长、景别、摄影机运动、关键声音点与状态之间的冲突；不修改文件。”输出应包含文件与字段位置、事实、可能影响和需要作者选择的问题。此时即使判断不理想，也不会污染项目。

作者若在独立审看后确认固定机位确实优于当前短横移，才可另行授权修改任务：“只修改视频提示与决策记录，使摄影运动服从固定机位；保持时长、对白、ID 和批准状态；把表演拆为四段；标明仍待 H3 实机验证；运行项目验证并展示差异。”现在完成条件可检查，创作权也清楚。在真正授权前，这不是《回声舱》的当前方案。

如果执行中发现声音切点也必须改变，Codex 不应默默扩大范围。它应报告具体登记冲突，例如：“当前声音表的按键声与备选表演的停顿点不能同时成立；需要额外修改声音表，或保留当前短横移方案。”作者可以扩大任务、另建任务或保留问题。停止在边界处不是效率低，而是避免一项局部修改变成未经批准的连锁重写。

小白如何读懂一段差异

差异视图通常用文件标题和行前符号表示变化。以文本为例，前面带减号的行表示旧版本中存在、当前版本删除；带加号的行表示新增。它并不是在说“减号内容错误、加号内容正确”。正确与否仍要结合任务。文件重命名、换行符或整体格式化有时会让差异看起来很大，因此先看统计与文件列表，再进入具体段落。

阅读差异可以分四轮。第一轮只看范围：有没有陌生路径、媒体、配置或密钥文件。第二轮看身份：镜头ID、角色名、状态、版本和路径是否改变。第三轮看意图：删改是否解决任务中的创作问题，有没有把具体表演重新写成空泛形容词。第四轮看副作用：链接、脚注、CSV字段、代码块环境和相邻镜头是否受损。

暂存区让你可以只选择本次决定。如果一个文件同时包含今天任务和昨天私人笔记，零基础阶段不要急着使用复杂的交互式分块暂存；更安全的做法是先将任务拆到不同文件，或明确保留全部现有修改并寻求人工判断。工具能力越强，越需要知道自己选择了什么。

审查二进制文件必须换方法。Git可能只能告诉你一张 WebP 或一个 MP4 改变了，不能显示画面差异。你需要打开文件、核对尺寸与时长、检查是否能播放，并与旧版并排观看。若文件本来不应进入仓库，首先问为什么出现，而不是直接暂存。

从“能恢复文本”到“能继续制作”

恢复一个仓库并不等于恢复一个制片环境。要继续制作，至少还需要运行环境、外部媒体、模型或远端服务、字体与插件、私人凭据以及足够明确的版本说明。把这些全部复制进 Git 并不安全，因此项目必须把“可由代码重建”和“必须独立迁移”区分开。

运行环境应尽量由声明重建：Python版本、依赖文件、安装步骤、关键软件版本和验证命令。虚拟环境目录通常不复制，因为其中包含机器相关路径且体积大；新电脑重新创建更可靠。ComfyUI 自定义节点与模型则应有名称、来源、版本或校验记录，但模型权重本身根据许可和容量另行迁移。

私人凭据不能写入移交文档。文档只说明需要哪一类凭据、由哪个官方入口重新登录或配置、本机变量名是什么。迁移完成后要验证账户权限和目标仓库，而不是看到登录窗口消失就假设成功。私有 GitHub 仓库在另一台电脑上克隆前，必须让该设备完成有权账户的认证。

媒体恢复应从清单开始。清单列出相对路径、镜头ID、文件大小、选择状态和备份位置；恢复后核对数量与校验值，再抽样打开。尤其要保存 SQLite 等有附属日志的项目数据库时，应遵循对应软件的备份方式，不能只在应用运行中随意复制主文件。对本教材项目，主要媒体仍是待生成状态，必须把“没有媒体”作为真实现状记录，而不是在清单中制造空链接。

最终恢复验证应回答一个创作问题：我能否从当前恢复点继续完成下一镜头？如果文本齐全但不知道哪个角色图被批准，不能；如果媒体齐全但镜头表版本错乱，也不能；如果两者齐全而 H3 适配信息过期，可以在核验后继续。可恢复性是生产连续性，不只是文件数量一致。

制作方法

第一步：先认清你在哪个窗口

资源管理器用于浏览和移动文件；编辑器用于修改内容；PowerShell 用于执行命令；Codex 用于在授权工作区内协作。看到以 PS开头并带路径的提示符，才是 PowerShell。不要把命令输入网页地址栏、文件搜索框或 Python 的 >>>提示符。

第二步：验证当前目录和项目根

在 PowerShell 中运行：

执行环境：Windows PowerShell

Get-Location
Get-ChildItem -Force
git rev-parse --show-toplevel
git status --short --branch

第一条显示当前位置；第二条显示包括隐藏项在内的目录内容；第三条要求 Git 返回仓库根；第四条显示分支和简短状态。若第三条提示“not a git repository”，不要立即初始化仓库。先确认是否进入错目录，或项目是否尚未克隆。

进入已有项目可使用：

执行环境：Windows PowerShell

Set-Location -LiteralPath 'D:\Projects\your-film'

预期是提示符路径改变。随后再次运行四条检查。D:\Projects\your-film只是占位路径，必须替换成你自己的项目根目录；不要机械复制示例盘符。

第三步：先读入口与规则

执行环境：Windows PowerShell

Get-Content -Raw .\README.md
Get-Content -Raw .\AGENTS.md

如果 AGENTS.md不存在，第二条会报找不到路径，这不等于项目损坏。阅读 README 是为了知道项目当前产品、入口命令和已知状态；阅读规则是为了知道可修改范围、语言、测试和安全边界。进入更深子目录工作前，还要检查该目录是否有更具体的 AGENTS.md。

第四步：建立仓库与媒体边界

先写清哪些内容进入 Git，哪些留在外部，再配置忽略规则。检查当前忽略效果：

执行环境：Windows PowerShell

git status --short
git check-ignore -v .\.venv\Scripts\python.exe
git ls-files

git check-ignore会说明某路径被哪条规则忽略；如果没有输出，可能未被忽略或路径不存在。git ls-files列出已追踪文件。不要用它判断外部媒体是否已备份，因为未追踪文件本来就不会出现。

推荐在项目的媒体说明中记录：媒体根路径、原始目录、可重建目录、选择目录、交付目录、备份位置、许可与隐私限制。路径可以因电脑改变，因此最好允许本机配置覆盖，不要把个人用户名或令牌硬编码进共享文档。

第五步：修改前建立基线

执行环境：Windows PowerShell

git status --short --branch
git diff --stat
git diff
git log -5 --oneline --decorate

如果工作树本来就有修改，把它们视为用户现有工作。记录路径和性质，不要假设可以丢弃。重大任务可先创建一个命名明确的分支；但分支不会自动保存未提交内容，所以创建前后都要查看状态。

执行环境：Windows PowerShell

git switch -c textbook/ch04-workstation

若分支已存在，命令会失败并保留现状。先用 git branch --list查看，不要随意添加强制参数。

第六步：让 Codex 在边界内执行

把任务书写成自然语言即可，但应包含真实路径和完成条件。对需要判断的修改，要求它先阅读依据；对大范围修改，要求分阶段完成并在每阶段审核。若任务涉及外部服务、推送、删除、覆盖或账号权限，应另行明确授权。Codex 可以运行验证，不应把“命令退出码为零”夸大为创作验收。

第七步：逐层阅读差异

执行环境：Windows PowerShell

git status --short
git diff --stat
git diff -- .\course\chapters\ch04.md
git diff --check

先看路径范围，再看具体内容，最后检查常见空白错误。审查表至少包含：是否只改允许路径；是否误删信息；ID、时间、批准状态是否改变；是否出现密钥或私人路径；命令环境是否正确；“待生成”是否被写成“已完成”。二进制文件的差异通常只能显示“发生改变”，需要另行打开检查。

若内容正确，再选择进入下一次提交的路径：

执行环境：Windows PowerShell

git add -- .\course\chapters\ch04.md .\course\workbooks\ch04.md
git diff --staged --stat
git diff --staged

--明确后面是路径。不要默认运行 git add .，尤其在仓库已有用户修改、下载文件或凭据时。暂存后必须再看一次 staged diff，因为下一提交包含的是暂存区，不是你主观以为完成的内容。

第八步：运行与风险相称的验证

文本项目常见验证包括元数据、内部链接、脚注、测试和网站构建。以本教材为例：

执行环境：Windows PowerShell

.\.venv\Scripts\python.exe .\scripts\book.py validate
.\.venv\Scripts\python.exe .\scripts\book.py build-site
.\.venv\Scripts\python.exe -m pytest -q

本教材仓库把虚拟环境解释器写完整，避免系统中多个 Python 时误用解释器。若该路径不存在，先检查项目 README 中的环境创建步骤，再运行 Get-Command python确认你正在诊断哪个 Python。依赖未安装与内容校验失败是两类问题：前者需要进入正确虚拟环境或安装项目声明的依赖，后者需要修改内容。不要通过删除测试或放宽规则来掩盖真正失败。

自动检查后仍要人工阅读页面、表格和图解。对生成媒体，还要实际播放、核对时长、分辨率、音频和连续性。接口接受任务，只代表任务被接受；文件存在，只代表产生了输出；可播放且符合创作意图，才接近镜头验收。

第九步：提交一项完整决定

执行环境：Windows PowerShell

git commit -m "docs: complete chapter 4 recoverable workstation"
git log -3 --oneline --decorate
git status --short --branch

提交说明应回答改变了什么和为什么。提交后状态不一定为空：其他未纳入本次任务的修改应继续保留。不要为了得到“clean”而删除不认识的文件。推送是把提交写到远端，会影响外部状态；本地提交与远端备份是不同动作。

第十步：建立并验证恢复副本

以下命令在仓库外创建 bundle 示例。先把目标改成你明确拥有的备份目录：

执行环境：Windows PowerShell

$backupRoot = 'D:\ProjectBackups\echo-cabin'
New-Item -ItemType Directory -Force -Path $backupRoot | Out-Null
git bundle create (Join-Path $backupRoot 'echo-cabin.bundle') --all
git bundle verify (Join-Path $backupRoot 'echo-cabin.bundle')
Get-FileHash -Algorithm SHA256 (Join-Path $backupRoot 'echo-cabin.bundle')

验证输出应说明 bundle 合法并包含引用，最后一条生成校验值。再选择临时目录做一次只读性质的恢复演练：克隆 bundle、查看日志、打开关键文档。媒体库应另做复制与抽样读取，bundle 不会自动包含被忽略或从未追踪的媒体。

第十一步：事故诊断时先分类型

执行环境：Windows PowerShell

Get-Location
git status --short --branch
git diff --stat
git log -5 --oneline --decorate

如果文件被修改但未提交，差异仍在工作树；如果已提交，可以在历史中找到；如果未追踪，Git 没有历史；如果目录本身丢失，要转向备份、云版本或存储恢复。先把诊断输出保存到仓库外，再决定下一步。恢复单个文件、恢复一组提交和恢复整块磁盘不是同一个问题。

第十二步：写一份可移交说明

每个阶段结束时更新 README 或 handoff，至少写：项目目标、当前分支与提交、完成内容、未完成内容、真实媒体状态、依赖环境、验证命令、备份位置、已知风险和下一步。移交说明不是向自己邀功，而是降低未来重新理解项目的成本。

常见误区

误区一：资源管理器打开了项目，所以终端也在项目里

不同窗口有独立上下文。永远用 Get-Location和 Git 根检查确认。命令找不到文件时，先查位置，不要复制文件到随机目录来“修好路径”。

误区二：Git 会自动保存所有东西

Git 只记录被追踪并提交的内容。未追踪视频、忽略的密钥、虚拟环境和外部媒体不会出现在提交中。git status干净也不代表全部项目资产已备份。

误区三：.gitignore能保护已经泄露的密钥

忽略规则主要影响未追踪文件。密钥一旦进入历史，应当视为可能泄露，先轮换，再按托管平台与团队策略处理历史。

误区四：测试通过就等于课程或影片通过

测试能确认可计算的合同，例如章节数量、链接、字段与篇幅。它不能确认解释是否清楚、电影分析是否准确、生成画面是否好看，也不能代替用户对创作方向的批准。

误区五：AI 说“只改了两个文件”就可以相信

协作者总结可能遗漏。用 git status和git diff --stat验证实际范围，再读内容差异。信任建立在可检查证据上，不建立在措辞自信上。

误区六：提交越大越省事

大提交把多项意图绑在一起，审查困难，恢复时也难拆分。按创作决定拆分；同一决定涉及多个文件可以一起提交，无关决定应分开。

误区七：分支等于备份

分支保护历史组织，不防磁盘、账户或仓库整体损坏。至少还需要远端或仓库外 bundle；大媒体需要独立副本。

误区八：看到错误就立刻重装或清理

错误信息是诊断证据。重装会改变环境，清理会删除线索。先记录版本、路径、状态和时间，再选择最小修复。

误区九：路径里有中文或空格就一定不能用

现代工具通常支持中文和空格，常见问题来自未加引号、编码或旧脚本假设。优先使用 -LiteralPath和明确引号；若某工具确有兼容问题，再建立短路径工作目录，并记录映射。

误区十：文件名带“final”就是批准版

文件名不能替代状态字段、选择日志和提交历史。批准是一项责任行为，应记录批准对象、版本、日期和限制。

正文练习

练习一：建立位置感

在自己的项目中运行 Get-Location、Get-ChildItem -Force、git rev-parse --show-toplevel和git status --short --branch。用自己的话解释每条输出。如果项目不是 Git 仓库，只记录事实，不要为了完成练习而初始化。

判断过程

正确答案不是固定路径，而是四层信息一致：PowerShell 当前目录位于预期项目；目录中存在入口文件；Git 能识别根目录；状态显示你预期的分支和修改。任何一层不一致，都应先定位原因。

练习二：把一个镜头决定拆成文件链

任选一个镜头 ID，列出剧本、镜头表、提示、声音、生成日志和质控中哪些文件与它有关。指出哪个文件定义叙事意图，哪个记录技术实现，哪个拥有批准权。

判断过程

镜头表通常承载镜头身份和核心叙事规格，提示文件实现生成，声音表和剪辑计划协调时间，日志记录试验，质控记录判断。具体项目可以不同，但不得让多个文件同时无规则地声称自己是最终真相。

练习三：审查一次模拟差异

假设差异同时修改 SH-005 提示、把 approved=false改为true、增加一个带 token 的命令示例。指出哪些属于目标修改，哪些必须拒绝，为什么。

判断过程

提示修改需要依据导演意图逐行审查；批准字段不能由自动化自行改变；真实 token 必须停止传播并轮换。即使结构测试全部通过，后两项仍不应接受。

练习四：设计三级恢复

为“误改一份 Markdown”“误删未追踪视频”“系统盘格式化”分别写恢复首步。不要写万能命令。

判断过程

未提交文本先保存状态和差异，再从编辑器历史或 Git 基线比较；未追踪视频先停止写入并检查媒体备份、同步版本或回收位置；格式化磁盘先减少对原盘写入并评估专业恢复。三者的证据与风险不同。

章末工作簿

打开第4章工作簿。工作簿把本章方法转成七份可复制成果：工作区地图、仓库边界表、Codex 任务合同、提交审核单、事故分级卡、恢复演练记录和镜头链检查。练习均为可选，不会阻塞后续章节。

章节小结

Windows、Codex 与 Git 并不是三套互不相干的工具。Windows 文件系统决定材料在哪里，Codex 帮助你在规则与任务范围内处理材料，Git 把文本变化变成可审查历史。三者只有围绕创作责任组织起来，才构成单人制片工作台。

最小可靠闭环是：确认位置与基线；定义输入、范围和禁区；进行修改；阅读实际差异；运行结构和内容检查；由作者批准；提交一项可解释决定；在独立位置保留可验证副本。任何环节都可以很简单，但不能由一句“应该没问题”替代。

判断系统是否真正适合小白，可以观察一次失败：路径错误时，它是否提醒先确认位置；依赖缺失时，它是否区分环境故障与内容错误；修改越界时，是否能从差异中发现；媒体尚未生成时，是否允许诚实保留待办；恢复演练失败时，是否保留原项目不受影响。一个只能在一切顺利时运行的流程不叫可靠。好的工作台会把错误变成信息，把下一步限制在可以理解和验证的范围内，使新手不会因为害怕损坏项目而停止创作，也不会因为工具给出绿色提示就跳过自己的判断。

对 AI 微电影而言，文件管理不是创作之外的杂务。镜头 ID、版本说明、生成状态和恢复记录共同保护导演意图。一个可恢复的项目允许你大胆试验，因为失败版本不会吞掉当前成果；一个可审查的项目允许你有效使用 AI，因为协作者的能力不会越过作者批准；一个可移交的项目则让作品在设备、时间与团队变化后仍保持连续性。

请把本章的判断原则落在自己的项目上：不追求零风险，而要让风险被看见、责任能定位、变化可解释、关键材料有独立副本。条件允许时，再做一次不会伤及原件的恢复练习；它会把“我有备份”的希望转成可检查的证据。做到这些，工作台才从目录升级为制作系统。

注释与书目

延伸阅读

先阅读 Git 官方参考中 status、diff、add、commit、worktree与bundle条目，再阅读在线版 Pro Git的起步、基础与分支章节。PowerShell 命令应查阅 Microsoft PowerShell 文档。Codex 的项目规则与审查能力会更新，应以 AGENTS.md 官方说明和代码审查说明为准。

延伸阅读的目标不是增加命令数量，而是学会在执行前查清作用范围。你可以为自己的项目建立一页“安全命令卡”：左侧列只读检查，右侧列会改变状态的操作；每条恢复命令旁写清影响对象、已有副本和回退方法。等这张卡真正用于一次小型恢复演练后，再把它视为生产系统的一部分。

---

1. OpenAI, “AGENTS.md”, Codex documentation, accessed 2026-09-08. 用于说明项目级与目录级规则发现及由根目录向当前工作目录叠加的规则关系；具体界面与能力可能更新，应以官方文档为准。 ↩↩

2. Git Project, Git Reference, accessed 2026-09-05. 本章 status、diff、add、commit、branch、worktree与bundle的命令语义以官方参考为准。 ↩

3. Scott Chacon and Ben Straub, Pro Git, 2nd ed., Apress, 2014, online edition. 用于工作区、暂存区、提交、分支和分布式历史的基础解释。 ↩

4. Microsoft, PowerShell Documentation, accessed 2026-09-05. 用于 Get-Location、Get-ChildItem、Set-Location、Get-Content与路径处理。 ↩

5. OpenAI, “Code review”, Codex documentation, accessed 2026-09-05. 本章将工具辅助审查映射为教材制作中的差异核对，不把自动审查等同于作者批准。 ↩

6. Christopher Nolan, dir., Memento, Newmarket, 2000. 本章只对信息顺序与记忆主题作文字概述，不使用剧照或剧本对白。 ↩

7. Alfred Hitchcock, dir., Rear Window, Paramount, 1954. 用于分析观察边界与推断边界，不复制影片对白或画面。 ↩

8. Francis Ford Coppola, dir., The Conversation, Paramount, 1974. 用于说明同一记录在版本与语境变化中可被重新解释。 ↩

9. National Institute of Standards and Technology, Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1, 2010. 本章借用备份、恢复与演练的基本思想，不把该指南当作个人电影项目的强制规范。 ↩

10. 本章关于“创作状态外化”“创作批准与技术通过分离”“稳定镜头 ID 连接文本与媒体”的表述为教材结合单人 AI 制片情境所作的原创总结。 ↩