cee5d0c58d
7 本写作书（Story Engineering、成为作家、Writing Tools、小说面面观、 我能否相信自己、小说课、风格感觉）按 15 个创作领域全量合并成综合 skill， 丢弃 v1 压缩蒸馏的思路（案例限 3 个、引文限 2 行、文件 ≤220 行）——被审计 证实丢了原文 75% 体积。 落点：.claude/skills/<slug>/ 下，每包含 SKILL.md 入口 + references/ 全量 内容（按主题拆分）+ scripts/ 可执行清单 + _coverage.md 覆盖对照表（唯一 追溯文件）。craft/ 目录只剩 books/ 原料层与 MERGE_PLAN.md / README.md / scripts/check_craft_skills.py 等 SoT。 规范要点： - 整合规范 v2：只重复合并、不压缩抛弃；举例保留具体对话/数字/动作/原句 - 追溯分离：SKILL.md 与 references/ 内容文件无《书名》unit-slug 标记， 所有来源只在 _coverage.md（落点到文件级即可） - 门禁：覆盖闭合 + frontmatter + 包结构 + 标记扫描，craft 15 个全过 craft/skills/ 的 15 个 skill 整体搬到 .claude/skills/，新建 _index.md 统管 运行时技能（33）与方法论参照（15），后者标签【方法论参照】，明示不落库、 不进 meta/chains。AGENTS.md 同步目录树与定位段。
5.8 KiB
定使命：一个场景只交付一件事
来源单元：《Story Engineering》（Larry Brooks）story-engineering/scene-mission-driven，Part 6 · The Function of Scenes。 本文件管"这个场景干什么"。场景给多少篇幅见 scene-detail.md，从哪里进从哪里出见 scene-entry-exit.md，边界与误区见 boundaries-and-pitfalls.md。
原文引文
"Every scene has a mission to accomplish. The mission of each scene is to deliver a single, salient, important piece of story to the reader. Less is more here. More than one bomb going off, or even a little mouse trap clicking shut, is often too much for one scene."
— Larry Brooks, Story Engineering (2011), Part 6
（/scene-mission-driven）
方法核心
每个场景必须有一个戏剧使命（mission）——交付一条关键信息，或做出一个关键决策，或推动一个关键情节节点。一个场景 1 个 mission；多个 mission = 戏剧张力稀释。（/scene-mission-driven）
Mission 的 3 种类型：
- 信息型：告诉读者一个关键事实（背景 / 真相 / 即将发生的事）
- 决策型：角色在场景内做出一个不可逆决定
- 动作型：场景推进情节 / 改变主角状态
3 类的共同点：改变故事的下一步走向。（/scene-mission-driven）
为什么 1 个 mission：
- 多个 mission = 读者注意力分散
- 每个 mission 都削弱其他 mission 的冲击力
- 1 个 mission = 读者每次被打动 1 次，印象深
（/scene-mission-driven）
操作法：
- 写场景前，用 1 句话回答"这个场景让故事前进了什么"
- 写场景后，再用 1 句话验证
- 说不清 = 这个场景删 / 并
（/scene-mission-driven）
使命的量级标准：mission 必须达到"改变故事走向"的量级，"角色出门"这种不算 mission。（/scene-mission-driven）
反例："这个场景让角色思考了，之后她做决定"——思考 + 决定 = 2 mission，拆。（/scene-mission-driven）
内心独白场景怎么算：mission 默认是"看得见"的，但内心独白场景也有 mission，归入信息型——角色领悟了某件事。（/scene-mission-driven）
案例
案例 1：James Patterson——极致的任务驱动
- 方法：每场景 1 mission，每章 1 场景，100+ 章/书
- Mission 例子：
- Chapter 1：介绍主角
- Chapter 2：介绍反派
- Chapter 3：第一场追逐
- Chapter 4：反派接近主角
- …… 一直到高潮，1 mission/章
- 结果：验证了"每场景 1 mission"的可读性优势
（/scene-mission-driven）
注意：帕特森式"一场一使命、一章一场"是极致做法，不是唯一正确的写法，见下文误区。（/scene-mission-driven）
案例 2：反例——写作者 1 场景塞 3 件事
- 问题：1 个场景里：(1) 角色做决定 (2) 角色见到反派 (3) 角色得到关键信息
- 诊断：3 mission = 戏剧张力稀释，读者消化不了
- 方法：拆成 3 场景，每个 1 mission
- 结果：故事节奏加快，戏剧强度提升
（/scene-mission-driven）
案例 3：反例——1 场景无 mission
- 问题：1 场景里角色在咖啡馆，描述环境，角色想，角色离开，什么都没发生
- 诊断：0 mission = 删
- 方法：删场景，或并入相邻场景
- 结果：小说变紧凑
（/scene-mission-driven）
可执行步骤（整篇/整段场景改稿）
- 列出所有场景
- 完成标准：用户列出当前所有场景（或一段内的所有场景）
- 逐场景回答 mission
- 完成标准：每个场景 1 句话："这个场景让故事前进了什么？"
- 说不清 = 这个场景无 mission
- 统计
- 全有 mission = 通过
- ≤ 1 个无 mission = 还行
- ≥ 2 个无 mission = 改稿，删 / 并
- 检查 mission 数量
- 完成标准：每个场景只 1 mission
- 有 2+ mission = 拆场景
- 改稿
- 完成标准：列出"删哪些 / 拆哪些 / 并哪些"
（/scene-mission-driven）
配表使用：场景逐场登记可用 ../scripts/scene-ledger-template.md，改稿逐关过用 ../scripts/scene-revision-checklist.md。
激活场景与语言信号
用户会在这些情境下需要这条方法：
- 新场景建："我要写 1 个场景，它应该做什么？"
- 场景诊断："这个场景有用吗？"
- 节奏优化："我的小说拖，怎么改？"
- 改稿："我写完一稿，怎么诊断场景？"
语言信号："场景任务 / 场景使命 / scene mission"、"这个场景有什么用 / 场景为什么"、"场景太多 / 场景散 / 小说拖"、"场景诊断 / 1 个场景 1 件事"。（/scene-mission-driven）
本单元的误区提醒
- 把"1 场景 1 mission"当教条：Patterson 风格是极致做法，不是唯一正确，不要拿它苛责一切写法。（/scene-mission-driven）
- Mission 太小：如"角色出门"——mission 必须"改变故事走向"才算数。（/scene-mission-driven）
- 乱造 mission 变体：集中于"信息 / 决策 / 动作"3 种，不要造新类。（/scene-mission-driven）
更多边界（不适用场景、盲点、易混方法）见 boundaries-and-pitfalls.md。
中文落地（中文适配）
网文连载"每章必有钩子"的节奏要求（见《成为作家》单元盲点条）与"一场一使命"天然合拍：一章一场、一场一使命、章末落在使命刚完成或刚被打破的位置，就是帕特森式排法的中文连载版。（中文适配；依据 story-engineering/scene-mission-driven 与 becoming-a-writer/fiction-scene-craft）