@66rpg/lumimaker 0.1.54 → 0.1.55

package/skill/lumimaker-copy-editing/SKILL.md

@@ -0,0 +1,241 @@
+---
+name: lumimaker-copy-editing
+description: 幻光文游（文游、AVG、视觉小说、解谜等带剧情作品）的文案导出与导入。把台词、旁白、选项、分支、结局、线索、谜题、界面文字和数值整理成编剧能直接改的《作品完整文案.md》，配一份给研发和 AI 的《Readme_文案说明.md》，并把编剧改过的文稿比对后写回游戏源数据。用户说「请将整个项目的所有文案导出，便于让我修改」「请把我改过的文案导入正式游戏」，或提到导出文案、导入文案、导出剧本、把剧本或台词交给编剧/作家审稿、编剧改完了更新到游戏、按改稿修改台词选项数值、建立「文案编辑」文件夹时使用；工程里已有「文案编辑」文件夹，用户要求改剧情、台词或数值时也使用，以便同步文稿。导入严禁编写固定转换代码。
+---
+
+# 文案导出与导入指引
+
+带剧情的作品，文字往往要交给不懂编程的编剧、作家反复打磨。本技能指导 Agent 为作品维护一份**人能直接读、直接改**的完整文稿，并在编剧改完后把改动准确带回游戏。
+
+---
+
+## 协作分工与边界
+
+- **文案导出、导入与文稿格式**：由本技能（`lumimaker-copy-editing`）说明。
+- **发布作品**：查阅 `lumimaker`。
+- **模板目录规范**：查阅 `lumimaker-template-spec`。
+
+---
+
+## 1. 按用户请求选择流程
+
+| 用户请求 | 执行 |
+|---|---|
+| 导出文案、把剧本整理给编剧、建立文案编辑文件夹 | 第 5 节导出；工程里还没有 `文案编辑/` 时，额外做第 7 节 |
+| 导入改稿、编剧改完了要更新进游戏 | 第 6 节导入 |
+| 在已有 `文案编辑/` 的工程里改台词、加章节、调数值 | 改完后按第 8 节同步文稿 |
+
+---
+
+## 2. 文件夹与文件
+
+**位置**：工程根目录 `文案编辑/`。项目主文档已约定位置时以约定为准。
+
+| 文件 | 给谁看 | 作用 |
+|---|---|---|
+| `作品完整文案.md` | 编剧、作家 | 作品里的全部文字和数值，按阅读顺序整理，可以直接改。 |
+| `Readme_文案说明.md` | 研发、AI | 标记规则、文稿与源数据的对应关系、导出与导入方法、变更记录。 |
+| `_导出基线/作品完整文案.md` | AI | 每次导出时的原样副本，导入时用来找出编剧改了哪里。编剧不要动。 |
+| `历史版本/` | 所有人 | 每次导入或覆盖前，保存编剧交回的稿子，便于找回。 |
+
+- 前两个文件必须有，后两项强烈建议有。文档一律用 UTF-8 保存。
+- 导出脚本（可选）放在工程 `scripts/`，例如 `scripts/export-copy.mjs`，并在 `package.json` 加一条 `copy:export` 脚本。
+- `文案编辑/` 不进构建产物：不要打包进 `dist/`。
+
+---
+
+## 3. 《作品完整文案.md》怎么写
+
+读者是**毫无编程基础**的编剧。正文里不出现代码、JSON、字段名、文件路径；给程序看的东西一律藏在标记里。完整示例见 [文档模板](references/templates.md)。
+
+### 3.1 组织顺序
+
+- **剧情向**：按故事发展顺序，章 → 场景 → 台词。分支剧情在选项下面按分支依次展开，每段开头写清「从哪个选项进入」「结束后回到哪里」。
+- **解谜向**：按玩家拿到线索的顺序，或按房间、关卡顺序；谜题的题面、提示、答案、解开后的文字放在一起。
+- **非线性**（自由探索、多角色）：按地点或角色分组，开头给一份「推荐阅读顺序」。
+- 不属于某段剧情的文字集中放在后面：角色表、结局总览、界面文字、系统提示、成就、数值总表。
+
+### 3.2 内容类型标签
+
+每条文字前用【】标出类型，让编剧一眼看懂这句话出现在哪里：
+
+| 标签 | 用途 |
+|---|---|
+| 【旁白】 | 叙述、环境描写 |
+| 【角色名】 | 对白，如【林夏】 |
+| 【内心·角色名】 | 心理独白 |
+| 【手机·角色名】 | 手机聊天、短信；同一段对话用小标题归在一起 |
+| 【选项 A】【选项 B】 | 玩家可以点的选项 |
+| 【线索】【物品】【文件】 | 线索、道具描述，日记、信件等可阅读内容 |
+| 【谜题】【提示】【答案】 | 题面、提示语、正确答案 |
+| 【界面·名称】 | 按钮、菜单、标题、设置项等界面文字 |
+| 【系统提示·名称】 | 获得提示、错误提示、加载文字等 |
+| 【结局·名称】【成就·名称】 | 结局名与结局文字、成就名与描述 |
+| 【角色·名称】 | 角色表里的角色名、简介 |
+
+标签不够用时可以按作品新增，但要登记在 `Readme_文案说明.md` 里。
+
+### 3.3 机关说明
+
+选项效果、出现条件、跳转去向用〔〕写成中文短句，编剧可以照着改：
+
+- 〔数值：林夏好感 +5〕
+- 〔条件：已获得线索「旧照片」〕
+- 〔跳转：第二章 天台〕
+- 〔结局条件：林夏好感 ≥ 60 且 找到全部 3 张照片〕
+
+〔〕的写法要固定、好读，具体语法登记在 `Readme_文案说明.md` 里。
+
+### 3.4 给 AI 的标记
+
+每条能导回游戏的文字，在标签后面紧跟一个 HTML 注释标记（Markdown 预览里不显示）：
+
+```markdown
+【林夏】<!-- @ch1.n002 -->
+“这么晚了，谁会打电话来？”
+
+- 【界面·开始按钮】<!-- @ui.start --> 开始游戏
+```
+
+- 标记里只写一个稳定 ID。ID 规则、ID 对应的源数据位置都写进 `Readme_文案说明.md`。
+- 优先沿用源数据里已有的 ID；源数据没有 ID 时，按「章.场景.序号」自行编号并记录对应位置。不要只靠会随增删变化的数组下标定位。
+- 章节、场景、选项组也加标记（如 `<!-- @scene ch1 -->`），方便定位新增内容。
+- 一条文字的范围：长文字从标签行的下一行开始，到下一个标签、标题或分隔线为止；短文字可以和标签写在同一行。游戏里的换行，在文稿里就写成换行。
+
+### 3.5 其他约定
+
+- **变量占位**：程序会替换的内容统一写成中文花括号，如 `{玩家名}`，对应关系登记在说明里，并提醒编剧保留。
+- **文字样式**：能用 Markdown 表达的就用 Markdown（如 `**粗体**`）；不能表达的写成〔效果：抖动〕这类中文说明。转换规则登记在说明里。
+- **AI 的说明文字**：写成引用块 `> 说明：……`，只帮助理解，不属于游戏文字。
+- **编剧批注**：编剧想给开发者留言时写 `> 批注：……`，导入时不进游戏，单独汇报。
+- **不能在文稿里改的文字**：画在图片里的字、程序自动拼出的文字等，列在文末「附录：不能通过本文稿修改的文字」，并说明改法。
+
+### 3.6 数值
+
+作品有数值时必须全部导出：属性初始值与上下限、选项带来的变化、解锁与结局的判断条件、道具数量、价格、计时、谜题答案等。按复杂度决定放法：
+
+- **数值少、主要挂在选项上**：写在对应文字旁的〔数值〕里，文末再附一张初始值表。
+- **数值系统复杂**（公式、成长表、商店、战斗等）：单独设「数值总表」章节，用表格集中列出；剧情里只写〔数值：见数值总表·好感规则〕这类指引。
+
+### 3.7 文稿开头固定放「阅读与修改须知」
+
+用大白话写清：哪些能改、标记和〔〕是做什么的、新增和删除怎么写、批注怎么写、改完对助手说什么。模板见 [文档模板](references/templates.md)。
+
+---
+
+## 4. 《Readme_文案说明.md》写什么
+
+这是给研发和 AI 的对照手册。目标：**任何一个新会话的 AI，即使没有加载本技能，只读这两个文档也能完成导出和导入。**必须包含：
+
+1. **基本信息**：对应作品、文稿与基线位置、最近导出时间和游戏版本、导出方式（脚本命令，或 AI 手工整理）。
+2. **文案来源清单**：每类文字在哪个源文件、哪个位置，对应文稿哪一章。写在组件里的界面文字也要逐个列出文件。
+3. **标记规则**：ID 格式、ID 到源数据位置的换算、标签清单、〔〕语法、变量名对照、占位符与样式的转换规则。
+4. **未收录内容**：哪些文字没有进文稿，原因和改法。
+5. **导出步骤**：本工程的具体做法。
+6. **导入方法**：通用步骤（与第 6 节一致的精简版），加上本工程特有的注意事项（如某处文字有长度限制、某个角色名在多处出现）。
+7. **变更记录**：每次导出、导入的日期和摘要。
+
+模板见 [文档模板](references/templates.md)。
+
+---
+
+## 5. 导出流程
+
+```
+导出进度：
+- [ ] 1. 检查有没有未导入的改动
+- [ ] 2. 盘点全部文案和数值来源
+- [ ] 3. 生成《作品完整文案.md》
+- [ ] 4. 自检：不漏、不重、能对上
+- [ ] 5. 保存基线，更新《Readme_文案说明.md》
+- [ ] 6. 告诉用户
+```
+
+1. **检查未导入的改动**：已有文稿时，先和 `_导出基线/` 比较。不一致说明编剧改过还没导入，先口语问用户：「是先把这些修改导入游戏，还是放弃它们重新导出？」无论怎么选，覆盖前都把旧稿复制到 `历史版本/作品完整文案_年月日-时分.md`。
+2. **盘点来源**：数据文件、组件里写死的文字、网页标题、作品名和简介、提示与报错文字、存档界面、成就、结局，以及全部数值。宁可多收也不要漏；确实不该给编剧看的（如调试文字）登记为「未收录」。
+3. **生成文稿**：按第 3 节组织。可以写**固定的导出脚本**（推荐用于后端+前端工程，或文案多、要反复导出的工程），以后直接运行；小工程也可以由 AI 手工整理。导出脚本只管导出，不管导入。
+4. **自检**：
+   - 源数据里的每条文字在文稿里都有，且只出现一次；每个标记都能在源数据里找到。
+   - 标记下的文字与源数据一致（按占位符、样式规则换算后）。
+   - 有导出脚本时，输出源数据条数和文稿标记数，两者应相等。
+5. **保存基线**：把刚生成的文稿原样复制到 `_导出基线/作品完整文案.md`；更新说明里的导出时间、版本和变更记录。
+6. **告诉用户**：说清文件位置、整理了哪些部分，提醒改完后用导入口令。首次导出按第 7 节。
+
+---
+
+## 6. 导入流程（由 AI 判断，不写固定转换）
+
+编剧改稿时可能比较随意：删了标记、挪了段落、改了标签、合并或拆开句子、从 Word 粘贴带来奇怪的引号和空格。所以**不要设计一键把文稿直接转换进游戏的固定代码**。每次导入都由 AI 先读 `Readme_文案说明.md`，再按这份稿子的实际情况决定做法：临时修一份结构规整的副本、和基线逐段比对、临时写辅助脚本都可以。临时脚本用完即删，不要固化成以后直接运行的导入工具。
+
+```
+导入进度：
+- [ ] 1. 读说明、备份
+- [ ] 2. 找出改动
+- [ ] 3. 逐项判断怎么改
+- [ ] 4. 改源数据
+- [ ] 5. 验证
+- [ ] 6. 刷新文稿和基线，汇报
+```
+
+1. **读说明、备份**：读 `Readme_文案说明.md`。把编剧交回的稿子复制到 `历史版本/作品完整文案_年月日-时分_编剧稿.md`。确认要改的源文件可以回退（有 git 就确认能回退，没有就先备份这些文件）。
+2. **找出改动**：
+   - 用编剧稿和 `_导出基线/` 比较，找出改动处。
+   - 再把当前游戏重新导出一份到临时位置，和基线比较。如果导出之后游戏本身也改过，两边的改动都要保留，冲突处问用户。
+   - 没有基线时，用当前游戏重新导出的版本和编剧稿比较。
+   - 标记丢失或错位时，根据前后标记、标签和与基线文字的相似度找回位置；需要时先在临时位置修一份结构规整的副本再比较，不要改动编剧原稿。
+3. **逐项判断怎么改**：
+
+| 改动类型 | 处理 |
+|---|---|
+| 改字、改标点 | 直接改对应源数据；顺手清理不可见字符和多余空格。 |
+| 新增台词或段落 | 按所在位置在源数据里新建条目，按规则分配新 ID。 |
+| 删除 | 删除对应条目，并修好指向它的跳转和条件。 |
+| 改数值 | 改对应字段，检查是否超出合理范围。 |
+| 改说话人 | 改这一句的说话人；若改的是角色表里的名字，全局生效。 |
+| 改选项、分支、结局、条件、跳转 | 能按〔〕说明明确实现的直接做；需要新玩法、新界面或说法有歧义的，先口语确认。 |
+| 批注 | 不进游戏，汇总给用户。 |
+| 看不懂、可能有多种理解 | 列出来问用户，不要猜。 |
+
+4. **改源数据**：保持数据格式合法（引号、换行要转义），保留占位符和样式标记；写在组件里的界面文字也要改到。
+5. **验证**：
+   - 运行工程已有的校验、类型检查或构建（如 `npm run validate`、`npm run build`）。
+   - 把改完的游戏重新导出到临时位置，和编剧稿逐段比较。剩下的差异只能是批注、排版差异，或已记下的「未导入项」。
+   - 界面文字变长时，留意按钮、标题会不会撑破布局；能预览就预览。
+6. **刷新文稿和基线，汇报**：
+   - 重新导出，覆盖 `作品完整文案.md` 和 `_导出基线/`，让下一轮从规整的新版本开始。没有导出脚本时，也可以用修好结构、补齐标记、且已通过第 5 步比对的编剧稿作为新版本。编剧原稿已在 `历史版本/`；稿里的批注在新稿对应位置保留。
+   - 更新说明里的变更记录。
+   - 用大白话汇报：改了哪些章节、大约多少处；新增和删除了什么；数值有哪些变化；哪些批注没进游戏；还有哪些要用户确认。不要念字段名、文件路径和 ID。
+
+---
+
+## 7. 首次导出额外要做
+
+工程里还没有 `文案编辑/` 时，完成第 5 节后再做：
+
+1. **交付前自测**：假装自己是一个新会话，只看两个文档，检查能否说清每类文字该改到哪里、新增一句该怎么落到源数据。说不清就补充 `Readme_文案说明.md`。
+2. **写进项目主文档**：在 `AGENTS.md` 加一节「文案导出与导入」，写明文稿位置、两条口令、「收到口令时先读 `Readme_文案说明.md`」，以及第 8 节的同步约定。没有 `AGENTS.md` 就写进 `README.md`；两者都没有就新建 `AGENTS.md`。有 `README.md` 时再加一小段给人看的说明。段落模板见 [文档模板](references/templates.md)。
+3. **告诉用户**（大白话，参考）：
+
+> 我把作品里所有的文字都整理成了一份文稿，放在 `文案编辑/作品完整文案.md`，用记事本或任何能打开文本的软件都能直接改。
+> - 以后想拿到最新的文稿，对我说：「请将整个项目的所有文案导出，便于让我修改」
+> - 改好之后想放回游戏，对我说：「请把我改过的文案导入正式游戏」
+
+---
+
+## 8. 修改游戏文案后同步文稿
+
+本轮在已有 `文案编辑/` 的工程里改了游戏文案（加章节、改台词、调数值）后：
+
+- **文稿和基线一致**（编剧没在改）：本轮修改完成后重新导出，保持文稿最新，并在回复里提一句。
+- **文稿和基线不一致**（编剧有改动还没导入）：**不要覆盖**。提醒用户有未导入的修改，建议先导入。
+
+---
+
+## 9. 红线
+
+1. 不写固定的导入转换代码；导入永远由 AI 读说明后比对完成。导出可以写固定脚本。
+2. 没有备份时不覆盖编剧的稿子。
+3. 不漏导：界面文字、系统提示、数值都要进文稿，或登记为「未收录」。
+4. 文稿正文不出现代码、字段名、文件路径；标记只放在 `<!-- -->` 里。
+5. 不把 `文案编辑/` 打包进发布产物。
+6. 和用户沟通用大白话，不念 ID 和字段名。

package/skill/lumimaker-copy-editing/references/templates.md

@@ -0,0 +1,277 @@
+# 文档模板
+
+照这里的结构写，内容按作品替换。示例里的角色、剧情、ID、文件路径、字段名都是虚构的；路径和字段名以工程实际数据为准。
+
+---
+
+## 1. 《作品完整文案.md》示例
+
+````markdown
+# 《雨夜来电》作品完整文案
+
+> 说明：本文稿由助手根据游戏整理，最近导出于 2026-10-10 23:00。
+
+## 阅读与修改须知
+
+1. 直接改文字就行：标签（如【林夏】）下面或后面的内容，就是游戏里显示的文字。
+2. 【】是这句话的类型或说话人；〔〕是这句话带来的效果、出现条件或跳转去向。两者都可以改，比如把〔数值：林夏好感 +5〕改成 +10。
+3. 形如 `<!-- @ch1.n001 -->` 的内容是给助手认位置用的（很多软件里看不到），请不要改也不要删；不小心删了也没关系，助手会尽量找回。
+4. 想加一句：照着上下文的样子，新起一行写【说话人】，下一行写内容，不用写标记。
+5. 想删一句：把这一整段（标签和文字）删掉即可。
+6. 花括号里的内容（如 {玩家名}）会被游戏自动换成实际内容，请保留花括号。
+7. 想给开发者留言：另起一行写「> 批注：你的想法」，它不会进游戏。
+8. 改好之后，对助手说：「请把我改过的文案导入正式游戏」。
+
+## 目录
+
+- 角色表
+- 第一章 雨夜来电
+- 第二章 天台
+- 结局
+- 界面文字与系统提示
+- 数值总表
+- 附录：不能通过本文稿修改的文字
+
+---
+
+## 角色表 <!-- @scene characters -->
+
+【角色·林夏】<!-- @char.linxia.name --> 林夏
+
+【角色简介·林夏】<!-- @char.linxia.bio -->
+主角的大学同学，说话直来直去。
+
+---
+
+## 第一章 雨夜来电 <!-- @scene ch1 -->
+
+> 说明：游戏开场。地点是主角的公寓，深夜。
+
+【旁白】<!-- @ch1.n001 -->
+窗外的雨下了整整一夜。
+
+【内心·{玩家名}】<!-- @ch1.n002 -->
+这么晚了，谁会打电话来？
+
+### 手机对话：陌生号码 <!-- @group ch1.phone1 -->
+
+【手机·陌生号码】<!-- @ch1.p001 -->
+你还记得三年前的约定吗？
+
+【手机·{玩家名}】<!-- @ch1.p002 -->
+你是谁？
+
+### 选项：要不要回拨 <!-- @choice ch1.c1 -->
+
+【选项 A】<!-- @ch1.c1.a -->
+立刻回拨
+〔数值：林夏好感 +5〕〔跳转：回拨〕
+
+【选项 B】<!-- @ch1.c1.b -->
+先不理会
+〔跳转：第二章 天台〕
+
+### 回拨 <!-- @scene ch1_callback -->
+
+> 说明：选了「立刻回拨」才会看到这一段，结束后进入第二章。
+
+【林夏】<!-- @ch1_callback.n001 -->
+“是我。别挂，听我说完。”
+
+【线索】<!-- @clue.old_photo -->
+旧照片：照片背面写着“天台见”。
+〔获得条件：听完林夏的电话〕
+
+---
+
+## 第二章 天台 <!-- @scene ch2 -->
+
+【谜题】<!-- @puzzle.door.question -->
+天台的门上有一把四位数密码锁。
+
+【提示】<!-- @puzzle.door.hint1 -->
+照片背面的日期，也许就是答案。
+
+【答案】<!-- @puzzle.door.answer --> 0612
+
+---
+
+## 结局 <!-- @scene endings -->
+
+【结局·重逢】<!-- @ending.reunion.title --> 重逢
+〔结局条件：林夏好感 ≥ 60〕
+
+【结局文字·重逢】<!-- @ending.reunion.text -->
+雨停了。她站在天台边，回头冲你笑了笑。
+
+---
+
+## 界面文字与系统提示 <!-- @scene ui -->
+
+- 【界面·开始按钮】<!-- @ui.start --> 开始游戏
+- 【界面·继续按钮】<!-- @ui.continue --> 继续游戏
+- 【系统提示·获得线索】<!-- @ui.toastClue --> 获得线索：{线索名}
+
+---
+
+## 数值总表 <!-- @scene stats -->
+
+> 说明：可以直接改表格里的数字。
+
+| 数值 | 初始值 | 最小 | 最大 | 说明 | |
+|---|---|---|---|---|---|
+| 林夏好感 | 20 | 0 | 100 | 达到 60 进入「重逢」结局 | <!-- @var.affection_linxia --> |
+
+---
+
+## 附录：不能通过本文稿修改的文字
+
+- 标题画面上的「雨夜来电」四个字是图片，要改需要换图，请告诉助手。
+````
+
+---
+
+## 2. 《Readme_文案说明.md》模板
+
+````markdown
+# Readme_文案说明
+
+> 给研发和 AI 看。编剧只需要看《作品完整文案.md》。
+> 收到导出或导入口令时先读本文件。本文件写明了完成导出和导入所需的全部规则，不依赖其他说明。
+
+## 1. 基本信息
+
+| 项 | 内容 |
+|---|---|
+| 作品 | 雨夜来电 |
+| 文稿 | `文案编辑/作品完整文案.md` |
+| 基线 | `文案编辑/_导出基线/作品完整文案.md`（每次导出时的原样副本，不要手改） |
+| 历史稿 | `文案编辑/历史版本/` |
+| 最近导出 | 2026-10-10 23:00，游戏版本 0.3.0 |
+| 导出方式 | `npm run copy:export`（`scripts/export-copy.mjs`，只导出不导入） |
+
+## 2. 文案来源清单
+
+| 内容 | 源文件 | 位置 | 文稿章节 |
+|---|---|---|---|
+| 剧情、对白、选项 | `src/data/story.json` | `scenes.<场景ID>.nodes[]` | 各章节 |
+| 角色名、简介 | 同上 | `characters.<角色ID>` | 角色表 |
+| 线索 | 同上 | `clues.<线索ID>` | 首次获得处 |
+| 谜题 | 同上 | `puzzles.<谜题ID>` | 所在章节 |
+| 结局 | 同上 | `endings.<结局ID>` | 结局 |
+| 界面文字 | 同上 | `ui.<键>` | 界面文字与系统提示 |
+| 网页标题 | `index.html` | `<title>` | 界面文字与系统提示 |
+| 数值 | 同上 | `variables.<变量ID>`、选项 `effects[]`、结局 `condition` | 数值总表、各〔〕 |
+
+## 3. 标记规则
+
+### 3.1 ID 与源数据位置
+
+标记格式为 `<!-- @ID -->`，紧跟在【标签】之后。
+
+| ID 形式 | 源数据位置 |
+|---|---|
+| `@<场景ID>.<节点ID>` | `scenes.<场景ID>.nodes[id=<节点ID>].text`，说话人在 `speaker` |
+| `@<场景ID>.<选项组ID>.<选项ID>` | 该选项组节点的 `options[id=<选项ID>].text` |
+| `@char.<角色ID>.name` / `.bio` | `characters.<角色ID>.name` / `.bio` |
+| `@clue.<线索ID>` | `clues.<线索ID>.name` 与 `.text`，文稿写成「名称：内容」 |
+| `@puzzle.<谜题ID>.question` / `.hintN` / `.answer` | `puzzles.<谜题ID>.question` / `hints[N-1]` / `answer` |
+| `@ending.<结局ID>.title` / `.text` | `endings.<结局ID>.title` / `.text` |
+| `@ui.<键>` | `ui.<键>` |
+| `@var.<变量ID>` | `variables.<变量ID>` 的 `initial`、`min`、`max` |
+| `@scene` / `@group` / `@choice` | 只用于定位，不对应文字 |
+
+新增条目的 ID：节点用 `n` + 三位数字，接在该场景现有最大序号之后；选项用下一个字母。
+
+### 3.2 标签清单
+
+【旁白】【角色名】【内心·角色名】【手机·角色名】【选项 A/B/C】【线索】【谜题】【提示】【答案】【界面·名称】【系统提示·名称】【结局·名称】【结局文字·名称】【角色·名称】【角色简介·名称】
+
+说话人标签与 `speaker` 的对应：【林夏】= `linxia`；【内心·{玩家名}】= `speaker: "player"` 且 `type: "thought"`。
+
+### 3.3 〔〕语法
+
+| 文稿写法 | 源数据 |
+|---|---|
+| 〔数值：<变量名> +N / -N〕 | `effects: [{ "op": "add", "var": "<变量ID>", "value": N }]` |
+| 〔数值：<变量名> = N〕 | `effects: [{ "op": "set", "var": "<变量ID>", "value": N }]` |
+| 〔条件：已获得线索「X」〕 | `condition: { "hasClue": "<线索ID>" }` |
+| 〔条件：<变量名> ≥ N〕 | `condition: { "var": "<变量ID>", "gte": N }` |
+| 〔跳转：<场景标题>〕 | `goto: "<场景ID>"` |
+| 〔结局条件：A 且 B〕/〔……A 或 B〕 | `condition: { "all": [A, B] }` / `{ "any": [A, B] }` |
+
+变量名对照：林夏好感 = `affection_linxia`。
+
+### 3.4 占位符与样式
+
+| 文稿 | 源数据 |
+|---|---|
+| `{玩家名}` | `{playerName}` |
+| `{线索名}` | `{clueName}` |
+| `**文字**` | `<b>文字</b>` |
+| 〔效果：抖动〕 | 节点 `fx: "shake"` |
+
+## 4. 未收录内容
+
+| 内容 | 原因 | 改法 |
+|---|---|---|
+| 标题画面 logo 文字 | 在图片里 | 替换 `assets/ui/logo.png` |
+| 控制台调试输出 | 玩家看不到 | 不需要改 |
+
+## 5. 导出步骤（本工程）
+
+1. 如果文稿和基线不一致，先问用户是导入还是放弃；覆盖前把旧稿存进 `历史版本/`。
+2. 运行 `npm run copy:export`，生成 `文案编辑/作品完整文案.md`。
+3. 核对脚本输出：源数据文字条数应等于文稿标记数。
+4. 把文稿复制到 `_导出基线/`，更新第 1 节的时间与版本、第 7 节的记录。
+
+## 6. 导入方法
+
+### 6.1 通用步骤
+
+不要写固定的导入转换代码，每次由 AI 按稿子实际情况处理：
+
+1. 把编剧稿复制到 `历史版本/作品完整文案_年月日-时分_编剧稿.md`，确认要改的源文件能回退。
+2. 用编剧稿和基线比较，找出改动；再把当前游戏重新导出到临时位置和基线比较，确认导出后游戏本身有没有变化，冲突处问用户。
+3. 标记丢失或错位时，根据前后标记、标签和文字相似度找回位置，需要时在临时位置修一份规整副本，不改编剧原稿。
+4. 按第 3 节规则把改动写回源数据：改字直接改；新增按位置建条目、分配新 ID；删除要修好相关跳转和条件；〔〕按语法表换算；批注不进游戏；看不懂的问用户。
+5. 运行 `npm run validate` 和 `npm run build`；重新导出到临时位置，和编剧稿逐段比较，剩下的差异只能是批注、排版或已记录的未导入项。
+6. 重新导出覆盖文稿和基线，更新变更记录，用大白话向用户汇报。
+
+### 6.2 本工程注意事项
+
+- `ui.*` 里的按钮文字建议不超过 6 个字，超了要提醒用户可能放不下。
+- 角色名只在 `characters` 里定义，对白只引用角色 ID；改角色表里的名字即可全局生效。
+
+## 7. 变更记录
+
+| 日期 | 操作 | 摘要 |
+|---|---|---|
+| 2026-10-10 | 首次导出 | 共 2 章、128 条文字、1 项数值 |
+````
+
+---
+
+## 3. 写进项目主文档的段落
+
+### `AGENTS.md`
+
+```markdown
+## 文案导出与导入
+
+- 作品全部文案整理在 `文案编辑/作品完整文案.md`（给编剧改），对照说明在 `文案编辑/Readme_文案说明.md`（给研发和 AI）。
+- 用户说「请将整个项目的所有文案导出，便于让我修改」：先读 `Readme_文案说明.md`，按其中的导出步骤执行（技能 `lumimaker-copy-editing`）。
+- 用户说「请把我改过的文案导入正式游戏」：先读 `Readme_文案说明.md`，由 AI 比对后修改源数据，不要运行固定的导入转换代码。
+- 开发中改了游戏文案（加章节、改台词、调数值）后：文稿和 `_导出基线/` 一致就重新导出并在回复里提一句；不一致说明编剧有未导入的修改，不要覆盖，提醒用户先导入。
+```
+
+### `README.md`
+
+```markdown
+## 修改文案
+
+作品里所有的文字都在 `文案编辑/作品完整文案.md`，可以直接打开修改。
+
+- 想拿到最新文稿：对助手说「请将整个项目的所有文案导出，便于让我修改」
+- 改完放回游戏：对助手说「请把我改过的文案导入正式游戏」
+```