用工程化管理搞定同人AU反应项目：目录、Git与模板实战

SIKAYD (swap AU) react to their originals 是一个典型的同人 AU 反应类创作标题基于角色互换设定让平行世界版本的角色们观看原作片段并做出反应。这类项目经常以 WIP 状态在社交平台连载开头还会标注 not my idea表示核心点子来自他人。很多创作者推进这类项目时资料只存在聊天记录、网盘文件名和浏览器收藏夹里结果设定散落、素材覆盖、灵感来源无法追溯写到一半想找某个反应片段对应的原作素材往往要翻很久。本文尝试把工程化的项目管理办法引入同人创作流程用目录结构、Markdown 模板、Git 分支、批处理脚本和检查清单把这类 AU 反应项目组织成可复现、可排查、可持续维护的工作区。即使你还没有开始创作也可以先把这套框架搭起来后面每一步都按它落地。1. 先理解这类 AU 反应项目为什么需要“工程化管理”同人创作常被当成纯灵感驱动的工作但只要有连载、跨平台、多角色、多章节它很快就会变成一个小型内容生产项目。此时如果只有灵感没有结构问题会集中爆发。1.1 这个标题背后的创作形式“SIKAYD (swap AU) react to their originals”可以拆成几个关键部分SIKAYD项目或 AU 的名字它可能是某个原作的角色互换衍生设定。swap AU角色互换设定通常把原作中 A 和 B 的身份、性格、立场互换。react to their originals角色们观看、体验原版角色的故事片段并给出反应。WIPwork in progress表示作品尚未完成。not my idea作者声明核心设定或点子不是自己原创。这类内容的核心不是“直接讲一个新故事”而是“让已知角色在特定观看场景下产生新的互动”。它的看点在于角色反应带来的反差、共鸣和信息差。因此内容生产者需要同时维护两套信息原作的客观剧情片段和 swap AU 角色对剧情的反应。两套信息只要缺少一处片段就会失去意义。1.2 手工管理的常见失控点只用文档和聊天记录推进时最常见的问题包括角色设定放在不同的版本里无法确定哪一份是当前有效设定。原作片段放在视频链接或截图里没有标注属于哪个章节、哪个时间点。反应剧情写到一半忘记该角色在这个 AU 里是否知道原作真相。图像素材被反复覆盖旧版本无法找回。多个合作者各改各的文件最终靠“最终版”“最最终版”区分版本。这些问题的根源不是创作能力而是缺少一个可验证的内容组织方式。同人创作虽然不要求代码规范但项目结构带来的好处是通用的每个文件有明确位置每个状态有明确记录每次改动有历史可查。1.3 用项目管理思维解决创作问题下面要建立的这套工作区不依赖特定平台也不强制使用复杂工具。核心思路只有三条用目录把设定、反应记录、素材、脚本分开。用 Markdown 模板让每个角色、每个场景都有固定字段。用 Git 和脚本管理版本、状态和批量操作。这三条分别解决“找不到”“不一致”“被覆盖”三类问题。后面的章节会逐步落地。2. 用一套目录和模板把设定、反应记录、素材分开设定、反应记录、素材图片是 AU 反应项目的三类核心资产。它们应该各占一个目录而不是混在同一个文件夹里。2.1 建议的项目目录结构假设项目名为SIKAYD-reaction-project推荐结构如下SIKAYD-reaction-project/ ├── README.md ├── docs/ │ ├── setting.md │ ├── timeline.md │ ├── characters/ │ │ ├── character-template.md │ │ └── char_a.md │ ├── scenes/ │ │ ├── scene-template.md │ │ └── ep01-react-to-originals.md │ └── reaction-records/ │ ├── original-clip-index.csv │ └── reaction-log.md ├── assets/ │ ├── images/ │ │ ├── raw/ │ │ └── processed/ │ ├── audio/ │ └── video/ ├── scripts/ │ ├── rename_assets.sh │ └── check_links.py ├── templates/ │ ├── character-sheet.md │ └── scene-sheet.md ├── .gitignore └── CONTRIBUTING.md这里每个目录都有明确职责docs/setting.md存放 AU 的核心设定和与官方设定的差异。docs/characters/每个角色一份独立文件。docs/scenes/每个反应场景一份剧本式文档。docs/reaction-records/用于记录原作片段索引和反应日志。assets/放图片、音频、视频且原始文件和处理后文件分目录。scripts/放批量处理和检查脚本。templates/放可复用的文档模板。注意这里目录名是参考实际使用时可以换成自己的语言习惯但“原始素材”和“处理后素材”一定要分开避免重复导出时覆盖原图。2.2 角色设定卡模板角色设定卡的核心功能是回答“在这个 AU 里这个角色是谁”。模板字段越固定越容易发现遗漏。--- id: char_a name: 角色 A role_in_original: 原作身份 role_in_swap: Swap 后身份 status: active | draft | deprecated creator: 角色设计者 source_inspiration: 设定灵感来源 last_updated: 2025-01-01 --- ## 与官方版本的核心差异 - 差异 1 - 差异 2 ## 该角色知道什么 - 知道原作完整剧情 - 知道自己是 Swap 版本 - 对其他 Swap 角色的了解程度 ## 反应行为备注 - 面对冲突时倾向于... - 面对原作悲剧时倾向于...字段解释id角色唯一标识图片和文档都用它做前缀例如char_a_cover.png。role_in_original和role_in_swap用于快速对比原版身份和 AU 身份。status标记该角色设定是否已经定稿。source_inspiration记录设计灵感来源尊重 not my idea 原则。last_updated方便后期排查“哪个设定最新”。2.3 反应场景脚本模板反应场景是核心内容单元。它要把“原作片段”和“AU 角色反应”放在一起否则读者很难理解角色在惊讶什么。--- id: scene_ep01 title: 第 1 话观看原作分歧点 status: wip original_source: 原作第 X 章 约 00:00:00-00:05:00 published: false --- ## 本场景目标 一句话说明这个反应片段想表达什么。 ## 原作片段 - 链接或文件路径 - 时间范围 - 剧情摘要 ## 出场角色 - 角色 A知道真相反应克制 - 角色 B不了解真相反应激烈 ## 反应流程 1. 播放片段前的对话 2. 播放中断言点 3. 角色反应 4. 讨论或冲突 ## 画面/台词草稿 场景描述 对话 A这里不对原作里不是这样。 B你怎么知道 A我只是觉得……他应该更冷静。这里的original_source字段非常关键它建立了反应内容与原作片段的对应关系。这个字段缺失时后续排查“这段反应对应原作哪里”会非常困难。2.4 用 YAML front matter 记录状态和灵感来源模板区的---内容就是 YAML front matter。它适合被脚本读取也适合人工快速浏览。一个项目里常见的状态字段包括字段可选值含义statusidea/wip/review/published内容当前处于哪个阶段source_inspiration文字描述核心点子是谁的参考了什么publishedtrue/false是否已公开发布last_updated日期最后更新时间状态字段和标题里的 WIP 是配套的。WIP 不应只作为口号而应该落到每个文件的status字段里。3. 用 Git 和 WIP 分支管理未完成内容很多创作者不用 Git是因为觉得“我又不写代码用不上”。但 Git 解决的是文件版本和历史回溯问题和是否写代码无关。对 WIP 项目来说它的价值尤其明显。3.1 为什么 WIP 不能和正式发布混在一个分支WIP 内容意味着不完整可能有半句台词、未完成的设定、临时占位图。如果这些内容和正式发布内容放在同一个分支又直接推到远程仓库很容易出现两种问题发布时不小心带出半成品。想在正式版回退到某个稳定状态结果被 WIP 提交干扰。更稳妥的做法是main保存可公开、可发布的内容。dev保存可预览但要联调的内容。wip/xxx保存尚未完成的章节或角色设定。这种分支划分不是代码项目专用内容项目同样适用。3.2 初始化 Git 仓库与 .gitignore 配置初始化仓库cd SIKAYD-reaction-project git init git branch -M main git add . git commit -m chore: init SIKAYD reaction project structure.gitignore要避免提交无关文件和超大文件.DS_Store Thumbs.db node_modules/ __pycache__/ *.log assets/images/raw/*.png assets/video/*.mp4这里把原始图片和视频忽略掉是因为它们通常体积大、不便于直接进入 Git 历史。处理后的小体积预览图可以提交。3.3 推荐的分支工作流和提交规范基本工作流git checkout -b wip/ep01-reaction # 编辑 docs/scenes/ep01-react-to-originals.md git add docs/scenes/ep01-react-to-originals.md git commit -m wip(scenes): 完成 ep01 前两个反应节拍提交信息建议统一用feat、fix、docs、wip做前缀前缀使用场景feat新增设定、新场景wip半成品提交只是存档fix修正设定冲突、修复链接docs修改说明文档chore调整目录、脚本、忽略文件提交信息里写清楚“这一步完成了什么是否完整”。这样几个月后回看历史也能知道当时在想什么。3.4 用 Git 检查历史时间线避免内容覆盖当发现某个角色设定被误改时先确认是不是提交覆盖了旧内容git log --oneline -- docs/characters/char_a.md git diff HEAD~1 HEAD -- docs/characters/char_a.md git checkout HEAD~1 -- docs/characters/char_a.md第一条命令查看该文件的提交历史。第二条命令查看最近一次修改内容。第三条命令把某次历史版本恢复回来。恢复后要确认新内容是否需要保留。如果两边都需要最好重新建立一份char_a_v2.md而不是直接覆盖。注意Git 不是备份工具的替代品团队成员都要养成提交前先git status的习惯避免把不需要的文件一起提交进去。4. 用脚本批处理素材并验证项目健康度素材文件一多手动改文件名、手工查链接会非常浪费时间。下面两个脚本可以减轻重复工作。4.1 图片文件命名规范化脚本推荐遵循场景标识_描述_序号.扩展名的命名方式例如ep01_char_a_reaction_01.png。可以用脚本批量处理。#!/usr/bin/env bash # rename_assets.sh # 用法: bash scripts/rename_assets.sh assets/images/raw set -euo pipefail target_dir${1:-assets/images/raw} prefix${2:-img} if [ ! -d $target_dir ]; then echo 目录不存在: $target_dir exit 1 fi index1 for file in $target_dir/*; do if [ -f $file ]; then ext${file##*.} new_name${prefix}_$(printf %03d $index).${ext} mv -n $file $target_dir/$new_name index$((index 1)) fi done echo 完成共处理 $((index - 1)) 个文件这里使用了set -euo pipefail脚本遇到错误会直接退出避免半途继续处理。mv -n表示不覆盖已有文件这是为了防止误覆盖。4.2 Markdown 链接和 TODO 检查脚本反应文档里经常出现图片链接失效、TODO 未处理的情况。可以用简单 Python 脚本检查。# scripts/check_links.py import re import sys from pathlib import Path def check_markdown(path: Path): text path.read_text(encodingutf-8) problems [] for m in re.finditer(r!\[.*?\]\((.*?)\), text): link m.group(1) if link.startswith((http://, https://)): continue if not (path.parent / link).exists(): problems.append(f图片不存在: {link}) if TODO in text: problems.append(f包含未完成 TODO: {path}) return problems def main(): root Path(docs) has_error False for md in root.rglob(*.md): problems check_markdown(md) if problems: has_error True for p in problems: print(f{md}: {p}) if has_error: sys.exit(1) print(检查通过) if __name__ __main__: main()运行方式python scripts/check_links.py这个脚本只处理本地相对路径的图片链接远程链接可以直接跳过。它会把包含TODO的文件也标记为问题帮助你在发布前发现半成品。4.3 素材压缩命令和参数说明WIP 阶段不需要保留超大原图。处理图片时可以使用ffmpeg或magick命令下面以magick为例# 压缩为宽度 1280 的 JPG质量 82 magick input.png -resize 1280x -quality 82 assets/images/processed/output.jpg # 压缩为 WebP适合网页展示 magick input.png -resize 1280x -quality 80 assets/images/processed/output.webp参数说明参数作用常见问题-resize 1280x限制宽度等比缩放不写x可能变形-quality 82控制压缩质量数值过高文件大过低画面糊-resize 1280x^按比例覆盖到目标尺寸会裁剪慎用实际项目中要先将原始素材放入assets/images/raw处理后再放入assets/images/processed避免原图被覆盖。4.4 项目状态看板用表格追踪 WIP 条目脚本只能处理机械任务创作状态还是要人维护。可以在docs/reaction-records/reaction-log.md中维护一张状态表| 场景 ID | 标题 | 原作片段 | 状态 | 负责人 | 灵感来源 | | --- | --- | --- | --- | --- | --- | | scene_ep01 | 第 1 话观看原作分歧点 | 原作第 X 章 | wip | 角色 A | not my idea | | scene_ep02 | 第 2 话观看背叛节点 | 原作第 X 章 | idea | 未定 | 待确认 |表格的核心作用是把“看起来很多事”变成“具体有几件事”。每次推进一个场景只更新对应行即可。5. 从灵感记录到发布的完整工作流目录和脚本搭好之后创作流程可以按下面五步推进。每一步都对应一个明确产出。5.1 记录灵感先注明来源再动笔任何新点子进来不要直接写剧情。先创建一条灵感记录--- id: idea_001 title: Swap A 看到原版角色死亡场景时失控 status: idea source_inspiration: 来自 Twitter 用户 xxx 的讨论 date: 2025-01-01 --- ## 核心灵感 一句话描述。 ## 关联角色 角色 A、角色 B。 ## 适合放入哪个场景 待定。这个步骤是对标题里 not my idea 的正面回应。如果核心点子来自别人的讨论记录来源不仅是对原作者的尊重也能避免日后出处争议。若不确定来源至少要写“来自公共平台讨论具体出处待确认”。5.2 写设定角色原版与 Swap 版差异清单单开设定文档重点是“差异”。如果 Swap 版和原版几乎一样那这个反应内容会缺少冲突感。建议在docs/setting.md中维护一张差异清单维度原版角色 ASwap 角色 A冲突/看点身份原版身份Swap 后身份身份错位性格冷静冲动反应反差立场中立偏向一方与原作剧情冲突对原作剧情的了解知道不知道信息差这张表不是设定集而是编剧工具。它帮助你在写反应场景时快速找到“哪个差异可以产生反应”。5.3 写反应片段原作片段、角色反应、情感节拍三列对齐写作时不要只写角色说完一句话就结束。建议把反应片段拆成三列原作片段、角色反应、情感节拍。| 原作片段 | 角色反应 | 情感节拍 | | --- | --- | --- | | 原版角色在桥边犹豫 | A 打断播放说“他不可能犹豫” | 否认 | | 原版角色选择牺牲自己 | B 沉默随后低声说“原来如此” | 接受 | | 原版角色转身离开 | A 站起来想阻止屏幕里的人 | 冲动 |三列对齐之后这段反应就有了叙事曲线。只写对话容易显得零散加入情感节拍后读者能感受到角色从否认到接受的变化。5.4 发布前检查清单发布不应该是“写完就发”。在从wip改为published之前逐项打勾[ ] 场景文档中的published字段已改为false且确认可公开。[ ] 原文片段链接依然有效。[ ] 所有本地图片路径能在 Markdown 中正确显示。[ ] 角色设定卡与反应文档中的称呼一致。[ ] 核心点子来源已根据 not my idea 原则注明。[ ] Git 分支已合入mainWIP 分支可删除或保留。[ ] 发布后备份原始素材避免换设备丢失。这份清单可以放在CONTRIBUTING.md或项目根目录的CHECKLIST.md中每次发布前执行一次。6. 常见问题排查从现象到根因即使流程再完整实际操作中仍会遇到各种问题。下面按“现象、可能原因、检查方式、解决方案”的格式整理。6.1 图片在 Markdown 中无法显示项目内容现象Markdown 预览中图片位置显示为裂图可能原因文件路径错误、大小写不一致、文件名包含中文或空格检查方式运行python scripts/check_links.py查看实际文件是否存在解决方案统一使用英文小写文件名路径使用相对路径对特殊字符做 URL 编码推荐在项目一开始就统一文件名规范避免后续逐个修改。6.2 Git 提交了不该提交的大文件项目内容现象Git 仓库体积快速膨胀clone 变慢可能原因大图或视频被直接提交检查方式git ls-files解决方案将大文件从仓库移除并清理历史必要时使用 Git LFS不要只在.gitignore里写规则已经提交进历史的大文件不会被忽略要专门处理。6.3 找不到某条反应记录对应哪个原作片段项目内容现象看到一句反应台词不知道它针对原作哪个片段可能原因original_source字段没有填写或者填写在旧版本里检查方式打开场景文档的 YAML front matter查看original_source解决方案以后在创建场景文件时就先填片段来源再写内容如果内容已经分散在多个文件里建议先建索引表把已知对应关系补上再继续创作。6.4 协作时出现“最终版”覆盖项目内容现象合作方在聊天窗口发来新文件替换了原文件可能原因没有统一工作区成员直接改共享目录检查方式对比文件时间戳和 Git 提交历史解决方案所有成员使用同一 Git 仓库大文件走网盘但只同步原始素材协作时建议约定所有人不在共享网盘里直接编辑只提交到仓库再进行合并。6.5 灵感来源和署名信息丢失项目内容现象发布后被人提醒“这个点子来自我”但找不到记录可能原因灵感和正文没有绑定存储检查方式查看前端 YAML 的source_inspiration字段解决方案新建文档时强制要求填写source_inspiration不明确时写“待确认”灵感记录应在创建时就录入不要等到发布前才补。时间久了谁都记不清来源。7. 把这个流程用起来的最佳实践这套方案的价值不在于工具本身而在于它把“模糊的创作计划”变成了“可检查的项目状态”。7.1 个人创作与多人协作的环境差异如果只是个人创作可以简化流程保留目录结构、Markdown 模板、脚本和本地 Git 即可。可以不建远程仓库也可以不拆多个分支只在本地维护main和wip/xxx。如果是多人协作则需要额外注意统一 Markdown 排版规则避免每次都靠人工调整。统一角色 ID避免同一个角色在不同人文件里叫法不同。远程仓库使用同一个托管平台并开启分支保护防止直接推送到main。设定和场景文档分开评审避免把未完成的设定合入正式内容。维度个人创作多人协作分支本地mainwip即可远程main/dev/wip/xxx文件命名手动保持规范用脚本强制规范灵感来源自己记得即可必须写入字段避免争议合并审查自己检查需要第二人确认备份至少一份外部备份远程仓库是协作中心7.2 可复用检查清单这里是适用于 AU 反应项目日常维护的检查清单项目初始化时[ ] 创建目录docs、assets、scripts、templates[ ] 添加.gitignore并初始化 Git[ ] 复制角色模板和场景模板[ ] 创建灵感记录模板每次创作前[ ] 创建对应的wip分支或确认当前工作区干净[ ] 检查角色设定卡是否最新[ ] 确认原作片段来源[ ] 确认灵感来源是否已注明每次发布前[ ] 运行check_links.py[ ] 检查所有场景的status和published[ ] 检查图片已压缩[ ] 合并分支并确认历史记录完整定期维护[ ] 清理无用素材[ ] 备份原始素材到外部存储[ ] 更新状态看板表格[ ] 归档已发布场景7.3 下一步可以扩展的方向如果这套工作区已经能稳定支撑一个 WIP 项目下一步可以按需要扩展用文档生成工具把 Markdown 渲染成静态站点方便内部预览。在灵感记录中增加标签字段按“虐心、搞笑、高能”等维度索引。为角色设定卡增加关系图避免角色关系越来越复杂后失去控制。引入自动化脚本在提交时检查状态字段是否合法。对大文件素材接入对象存储减少本地仓库体积。最关键的一点是不要为了使用工具而使用工具。目录、脚本、Git 都是为了让你把精力放回创作本身。当你能在一分钟之内找到任意角色的当前设定、任意反应片段对应的原作来源时这套流程就已经成功了。建议先用一个小场景完整跑一遍再逐步迁移历史内容这样代价最小也最容易坚持。