5.3 KiB
Raw Blame History

定使命:一个场景只交付一件事

来源单元:《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

方法核心

每个场景必须有一个戏剧使命(mission)——交付一条关键信息,或做出一个关键决策,或推动一个关键情节节点。一个场景 1 个 mission;多个 mission = 戏剧张力稀释。

Mission 的 3 种类型:

  1. 信息型:告诉读者一个关键事实(背景 / 真相 / 即将发生的事)
  2. 决策型:角色在场景内做出一个不可逆决定
  3. 动作型:场景推进情节 / 改变主角状态

3 类的共同点:改变故事的下一步走向。

为什么 1 个 mission:

  • 多个 mission = 读者注意力分散
  • 每个 mission 都削弱其他 mission 的冲击力
  • 1 个 mission = 读者每次被打动 1 次,印象深

操作法:

  • 写场景前,用 1 句话回答"这个场景让故事前进了什么"
  • 写场景后,再用 1 句话验证
  • 说不清 = 这个场景删 / 并

使命的量级标准:mission 必须达到"改变故事走向"的量级,"角色出门"这种不算 mission。

反例:"这个场景让角色思考了,之后她做决定"——思考 + 决定 = 2 mission,拆。

内心独白场景怎么算:mission 默认是"看得见"的,但内心独白场景也有 mission,归入信息型——角色领悟了某件事。

案例

案例 1:James Patterson——极致的任务驱动

  • 方法:每场景 1 mission,每章 1 场景,100+ 章/书
  • Mission 例子:
    • Chapter 1:介绍主角
    • Chapter 2:介绍反派
    • Chapter 3:第一场追逐
    • Chapter 4:反派接近主角
    • …… 一直到高潮,1 mission/章
  • 结果:验证了"每场景 1 mission"的可读性优势

注意:帕特森式"一场一使命、一章一场"是极致做法,不是唯一正确的写法,见下文误区。

案例 2:反例——写作者 1 场景塞 3 件事

  • 问题:1 个场景里:(1) 角色做决定 (2) 角色见到反派 (3) 角色得到关键信息
  • 诊断:3 mission = 戏剧张力稀释,读者消化不了
  • 方法:拆成 3 场景,每个 1 mission
  • 结果:故事节奏加快,戏剧强度提升

案例 3:反例——1 场景无 mission

  • 问题:1 场景里角色在咖啡馆,描述环境,角色想,角色离开,什么都没发生
  • 诊断:0 mission = 删
  • 方法:删场景,或并入相邻场景
  • 结果:小说变紧凑

可执行步骤(整篇/整段场景改稿)

  1. 列出所有场景
    • 完成标准:用户列出当前所有场景(或一段内的所有场景)
  2. 逐场景回答 mission
    • 完成标准:每个场景 1 句话:"这个场景让故事前进了什么?"
    • 说不清 = 这个场景无 mission
  3. 统计
    • 全有 mission = 通过
    • ≤ 1 个无 mission = 还行
    • ≥ 2 个无 mission = 改稿,删 / 并
  4. 检查 mission 数量
    • 完成标准:每个场景只 1 mission
    • 有 2+ mission = 拆场景
  5. 改稿
    • 完成标准:列出"删哪些 / 拆哪些 / 并哪些"

配表使用:场景逐场登记可用 ../references/scene-ledger-template.md,改稿逐关过用 ../references/scene-revision-checklist.md。

激活场景与语言信号

用户会在这些情境下需要这条方法:

  1. 新场景建:"我要写 1 个场景,它应该做什么?"
  2. 场景诊断:"这个场景有用吗?"
  3. 节奏优化:"我的小说拖,怎么改?"
  4. 改稿:"我写完一稿,怎么诊断场景?"

语言信号:"场景任务 / 场景使命 / scene mission"、"这个场景有什么用 / 场景为什么"、"场景太多 / 场景散 / 小说拖"、"场景诊断 / 1 个场景 1 件事"。

本单元的误区提醒

  1. 把"1 场景 1 mission"当教条:Patterson 风格是极致做法,不是唯一正确,不要拿它苛责一切写法。
  2. Mission 太小:如"角色出门"——mission 必须"改变故事走向"才算数。
  3. 乱造 mission 变体:集中于"信息 / 决策 / 动作"3 种,不要造新类。

更多边界(不适用场景、盲点、易混方法)见 boundaries-and-pitfalls.md。

中文落地(中文适配)

网文连载"每章必有钩子"的节奏要求(见《成为作家》单元盲点条)与"一场一使命"天然合拍:一章一场、一场一使命、章末落在使命刚完成或刚被打破的位置,就是帕特森式排法的中文连载版。(中文适配;依据 story-engineering/scene-mission-driven 与 becoming-a-writer/fiction-scene-craft)