KANONARA

傷勢與角色狀態連貫

讀者追蹤傷勢、疾病、疲勞與裝備,遠比你以為的久。如何記錄角色狀態、安排康復節奏,並把傷變成回收。

發布於 26 Sept 2026 · 1 分鐘閱讀

她在第十二章守門時斷了手臂。到了第十四章她爬上攻城梯,而章節底下的第一則留言只說了一句:「手臂?」傷勢、疾病、疲勞、損壞的裝備、花掉的錢:讀者以一種令作者吃驚的耐心追蹤角色狀態,因為讀者唯一的工作是記住,而作者的工作是發明,而發明會把記住擠出去。

狀態連貫,是隨故事推進記錄每個角色的身體與裝備什麼為真的實踐,好讓「第二十章時她身上什麼為真」永遠是一次查詢,而不是一次猜測。它的缺席就是經典的連貫性錯誤,維基百科把它定義為「故事線中與情節所建立的邏輯流向相抵觸的不一致」:從未痊癒卻痊癒的傷、自己重新鍛造自己的劍、場景一換就結束的熱病。

狀態帳冊

為每個角色,那些值得標日期的狀態:

  • 健康:傷勢與疾病,附發生的章節、嚴重程度,以及預期的病程。
  • 疲勞:飢餓、失眠、長途騎乘。疲勞是作者最先忘記的狀態,而兩夜未眠之後的戰鬥,無論文本提不提,都是一場不同的戲。
  • 裝備:她身上帶著的、可能損壞、花用或遺失的東西。武器、信物、錢財。使用已經遺失的東西是物品漂移,本身就自成一種連貫性錯誤(見七種連貫性錯誤)。
  • 情緒狀態:上一章的事件之後,她站在什麼位置。恐懼與悲傷會改變決定,而沒有被追蹤、下一章就重設的悲傷,讀起來是假的。

規則就是在章節之間追蹤角色狀態裡的那些:為每次變更標日期、保留歷史、註明確立它的場景。本指南的其餘部分,談的是身體與裝備特有的欄位:一道傷的病程,以及康復的節奏。

一道傷是一份合約

傷口上到頁面的那一刻,它就是一個鋪陳,而鋪陳要求兌現。原則是契訶夫的。如同契訶夫在一八八九年的信裡所寫:「如果槍不打算響,就絕不能把上了膛的步槍放上舞台。」斷掉的手臂是一把上了膛的步槍。要麼它在痊癒之前約束著場景,而那份約束就是這道傷在講的故事;要麼它是布景,而布景讓讀者追蹤了二十章,花的是信任。

這也是為什麼傷需要的是一條病程,而不是一個狀態:發病、最糟、好轉、痊癒或永久。每個階段都是材料。爬梯那場戲在第一週不可能、第三週勉強、第二個月沒問題;同一場戲對上不同的階段,就是不同的戲。

康復的節奏,尤其是在連載裡

這個失敗模式在寫作討論裡有名字。在 Descriptionary 這個寫作部落格上,Shonna White 點名「方便的康復時程」:傷勢恰好在劇情需要的時候痊癒;方便會磨損可信度,揮手抹去傷勢的效果會侵蝕張力,而讀者從「他們要怎麼撐過這個?」漂向「我為什麼要在乎?」。她的建議朝另一個方向跑:把康復蓋進劇情裡,因為「限制製造張力」,而且跨越真實障礙的勝利,感覺是掙來的。實用的翻譯:

  1. 在受傷那場戲就定下病程。 決定寫實的跨度,然後在它裡面寫;寫作者用的康復參考資料,把表淺割傷放在數天、深度撕裂傷放在四到八週、肢體重大骨折放在八到十二週(Rebecca Shedd 寫給寫作者的康復時程指南)。劇情需要它更快時,在頁面上買下那個速度:一位治療者、一個代價、一項永久損失。
  2. 讓傷花費場景,而不是段落。 在要緊的每一場戲裡被承認一次,勝過每一頁被提醒一次。
  3. 升高。 故事後段的傷應該比前段的更重;如果第一章與第二百章都是扭傷手腕加兩天復原,身體的賭注就已經扁平了。
  4. 利用既立的傷。 舊傷在最糟的時刻復發,是長篇裡最便宜的回收之一,因為那把槍是讀者跟你一起上膛的,而他記得。

連載多出一道皺褶:章節時間與故事時間會漂開,而讀者即時體驗那道落差。一條橫跨一個月故事時間的康復弧線,可能橫跨四個月的發表時間;對角色讀起來仍然新鮮的傷,對觀眾讀起來可能是遠古史,而留言區會照那樣對待它。用故事時間而非發表順序為狀態標日期,正是讓帳冊保持誠實的東西(見多重視角與倒敘下的時間線)。

傷之外

同一套紀律也涵蓋更安靜的狀態。疾病有病程:熱病會退、咳嗽會留,腦震盪在發生的那場戲之後很久,都還可能留下頭痛與霧感。疲勞會累積,並由必須發生在某個地方的休息償還。錢是狀態:第九章花掉最後一枚銅板的角色,若沒有一筆收入事件,第十章買不了船位。而跨過書界,狀態就是交接:從第二冊帶出來的傷,是第三冊的開場條件,而這正是系列層級的紀錄要緊的原因之一(見系列聖經與單本聖經)。

把這一切兜在一起的習慣:在章節邊界更新帳冊,而且在任何動作戲之前,查一遍房間裡每個人的健康與裝備。三十秒的檢查,買到連載作者無法用其他方式買到的東西:每個星期,在公開場合是對的。

Kanonara 如何處理這件事

健康、所在地、物品欄與同類的狀態,在 Kanonara 裡是帶著完整歷史的結構化紀錄,所以「第二十章之前她受傷了嗎」不必考古就有答案。章節被分析時,偵測到的狀態變更以附有證據的提案抵達,而且只有在你核准時,紀錄才更新。請看Kanonara 的運作方式。