01 / 制作笔记
人物怎样开口
对白修改记录
作为项目剧本作者，我负责剧情与分场设计、人物塑造和对白写作。写作前先整理人物背景、关系与风格参考，AI 辅助整理上下文、检查逻辑，Gemini 在限定范围内润色。回稿之后，我再核对事实、称谓、时间和结构。
每轮改稿后，我都会检查有没有改错剧情。需要返工时，指出具体是哪一句出了问题，再说明怎么改。每次任务保留运行 ID、输入哈希和结果，中断后也能查到进度，不必重复提交。
三处具体的改稿
原句把“没见过本人”写成了“不知道长相”，改稿时删去了这个多出的判断。
修正前她手里正拿着枪，Webb 先生就死在她旁边。
修正后她当时手里拿着枪，Webb 先生就死在她旁边。
把证词限定在当时，避免与当前场景混淆。
英文是为此处展示所作的意译。工作稿、模型原始回稿和校验记录分别保存；文字审查之后，配置同步与实机演出仍需另行处理。
来源：2026-09-17 L1 对白校验记录 reviewed_changes；2026-09-23 个人改稿说明。
这些例子取自历史工作稿，供说明改稿思路；并非当前正式台词或整章实机验收结果。
02 / 制作笔记
叙事与逻辑核查
线索什么时候出现，能证明什么。
我把案件拆成场景、人物、证据、疑点和指证步骤，再用 AI 辅助梳理与交叉检查。时间线、人物事实、证据属性、称谓和各方视角分别核对，最后复查疑点与误报，留下出处。
看见持枪，不等于看见开枪。
一位目击者看见 Vivian 持枪，就认定她杀了人。摘要里要写清楚：持枪是他看到的，杀人是他的推断。
同一份审查里，“约 23:20”且后来撤回的说法，不能被记成确切的 23:20。这里是对报告的说明性转述，并非 NPC 原台词。
先拆解，再核查
先整理共同事实，让不同的审查任务各自检查，再复核疑点与出处。查人物语气，就集中看同一角色的台词；查信息泄露、事实和视角，则各有侧重。依赖前一步的任务按顺序做，独立的检查才并行。
来源：2026-09-28 U1 对白配置前风险审查及证词出处表；episode-consistency-audit 编排定义。
历史审查和现有流程是分别展示的两个例子，并非同一次运行；这里列出的问题也不代表至今未修复。
03 / 制作笔记
角色、场景与道具
角色与场景素材的制作
我负责内容需求、工作流和验收标准，与合伙人及美术同事一起制作。身份参考、候选生成、人工审核、状态派生和规格处理分开进行，修订与确认记录也都保留。
Emma · 身份与服饰参考
微笑状态
愤怒状态场景制作中，我会整理 Midjourney 提示词与候选图，角色和道具则保留统一索引。之后处理透明素材、位置和工程命名，把候选、待审和正式交付分开。生产入口和来源索引一起留下，换机器或换人接手时也能核对。
蓝月俱乐部 · 场景资产来源：Emma O’Malley 角色库、Unit4 Emma 表情库、2026-09-05 美术工作区记录。
这些都是团队协作的成果，不是我一个人生成的。放在网页上展示或者存进素材库，也不代表它们就是最终敲定的版本。
04 / 制作笔记
语音与角色表演
两段对质表演的制作过程
这两段取自同一场对质：Morrison 受压后的辩解，和 Emma 克制的反驳。都是已确认素材，分别播放。展开制作过程，可以看到实际使用的角色参考、原始语音和交付处理。
表演要求、参考图与素材处理
做表演前，我会先问：上一句给了什么压力，人物此刻知道什么，又想通过这句话达到什么目的？再结合音轨里的停顿安排动作，用平静、目标表情、回落三帧参考保持角色一致。候选经过人工确认后，统一绿幕、尺寸和音量，并与对白条目对应。
来源：2026-09-14 已确认交付批次；条目 210019 / 210021 的 context_card、run_spec、review_decisions 与 delivery_report。
这里的场景版为作品集合成：原表演配上对应的警局办公室背景，音轨与时序保留。它不是实机录屏，也不能替代当前版本的完整演出验收。
05 / 制作笔记
预览工具与配置同步
台本预览与配置同步
我和 AI 协作做网页预览与配置工具，把场景、人物、证据和对白入口放在一起查看。脚本负责解析台本、比较差异和受限回写，让内容先在网页上检查，再进入正式配表与运行时。
修改文字，保留结构
台词回写只改 Words 文本。ID、说话人、路由、脚本、参数和场景归属必须核对，结构不一致就拒绝同步。为网页预览增加的字段，也不会默认带入 Unity。
工具默认只读。明确执行写入时，也只改本地 AVG 文本，不直接写 Unity。其他配置按设计 / State → 预览配置 → 验证与交接 → Unity 的顺序处理。
游戏结果界面示例 · 非网页编辑器截图来源：sync_unit1_script_to_json.py 模块合同；网页配置预览规则与 Unity 接入记录。
这里说明工具规则与流程；配图是游戏结果示例，并非编辑器截图。
06 / 制作笔记
测试与版本交接
测试范围与检查结果
引用有没有对应，运行时能不能加载，玩家实际玩起来如何，需要分别检查。我先确定范围，用 AI 辅助整理问题与路径，再由脚本和 Unity 测试执行检查，记下日期、版本、结果和未完成的事项。
2026.10.14 / 一批合并后检查
这一批四组、八项通过，范围限于上表。完整视觉、演出、存档迁移和所有剧情分支尚未由这批检查覆盖，后续单表更新也不在其中。
来源：U2ConfigFeedback-20261014 / push-merge / report.md。
历史批次记录。整理作品集时未重新运行 Unity 测试。
07 / 制作笔记
项目推进与沟通
团队分工与制作安排
做策划，也负责项目推进。我需要说清需求和验收范围，安排程序交接、带新策划，判断美术工作的先后。内容、State、对话工程、角色制片、配表和数据发布分成阶段，再看人员和依赖怎样安排。
一段对白需要经过哪些制作环节
内容侧先明确说什么、何时说、谁知道；制片侧需要台词、情绪和角色参考；配置侧需要入口、分支与资源对应；验收再检查加载、播放和触发。我把每一段需要什么、交出什么、接下来交给谁写清楚。
反复用下来有效的方法，我会整理成 Skill，和规则、脚本、模板一起做版本管理。我也写体验报告、梳理叙事定位、准备发行 pitch，向团队外的人说明游戏是什么、目前做到哪里。
来源：2026-04-01 策划工作模块总览；2026-03-31 团队总览；Skill 维护与归档规则；发行 pitch 说明。
这里展示管理方法与准备材料，不作为历史排期全部完成或已签发行协议的证明。
08 / 制作笔记
NPC 记忆与玩家档案
NPC 记忆与玩家档案的记录规则
在《猫神町》原型里，NPC 记忆保存参与过的事件、来源 ID、日期与类型。角色所知和玩家所知分开更新；生成对白时，提供角色知道的事实、亲历记忆和本次已经播放的对白。
调查档案官只接收玩家可见、符合归档类型的新事件。旧档案用来合并和去重，不把隐藏设定、未播台词或私密记忆补进来。
四个具体的测试例子
档案区分转述、亲见、材料记载、已确认和存在矛盾的内容。留下来源，才能回头看清角色的判断是从哪里来的。
来源：gameService.ts memory / deliver；caseProvider.ts；archiveAgent.ts buildArchiveBatch / validateArchivePatch；archiveAgent.test.ts。
这里展示规则与测试样例，网页本身不连接在线模型，也不运行原型测试。这套做法并不等于彻底解决了幻觉。
