novel-workflow-04-character-design

novel-workflow-04-character-design：角色设计

用于把一个角色从“名字、身份或模糊印象”深化成能推动剧情、能承载主题、能被写作使用的 lorebook 角色节点。这个流程不是人物表批量生成，也不是章节剧情规划。

默认按用户主导推进：先了解用户对角色的已有印象、角色功能、关系倾向和不想要的方向。可以给出候选动机、矛盾、角色弧或可写特征，但不要把候选直接写成最终设定。只有用户明确要求“你来定”“直接完整设计”时，才由 Agent 主导补全。

如果用户还在整理角色感觉、只有标签或萌点、想做 20/24/80/200 问、调色盘、三面性、混色、核心人格层或二次解释，先参考 novel-technique-character-card-workshop。本流程负责把已经确认的角色设定落到 Project Workspace；重型角色理解问答交给那个 skill。

目标

• 明确角色的一句话定义和戏剧功能。
• 设计角色的外部目标、内在需求、弱点、恐惧和误信念。
• 建立角色与主线、主题、世界规则、势力、地点和其他角色的关系。
• 写出角色弧光或“不变化”的理由。
• 把稳定设定保存到合适位置的 index.md 正文，把当前处境保存到 state.md。

使用时机

当用户要设计这些对象时使用本流程：

• 主角、视角角色、核心同伴、反派、竞争者、导师、家人、重要配角。
• 某个势力、地点、规则或开局事件背后的代表人物。
• 已有角色太薄，需要补动机、矛盾、关系、角色弧或可写特征。
• 需要把聊天中的角色设定整理进当前小说 workspace。

如果用户还没有明确小说题材、简介、主角基础定位或世界基础，先回到 novel-workflow-01-idea-exploration、novel-workflow-02-project-bootstrap 或 novel-workflow-03-lorebook-bootstrap。

边界

不要在本流程中：

• 创建 Thread、Scene、Plot 等剧情系统对象。
• 写章节级大纲、逐场戏安排或完整剧情推进。
• 用角色卡字段堆砌替代角色逻辑。
• 把临时状态、当前任务、章节进度混进稳定设定。
• 为了让角色显得完整而伪造尚未确认的设定。

如果用户要求推进当前时间点的局势、角色行动或势力态势，切到 novel-workflow-08-plot-planning，由 World Engine 查询当前状态并在用户确认后推进时间线。如果用户要开始追踪角色随时间变化的状态，先切到 novel-workflow-world-engine-init。

工作方式

先读取已有 workspace，再判断角色缺口。优先查看：

• lorebook/note/story-concept/
• lorebook/note/project-positioning/
• lorebook/note/synopsis/
• lorebook/note/initial-plot-seed/
• 与角色相关的 rule、faction、location、item、character 节点。

设计前先确认或整理：

• 用户已经确定的角色印象、身份、气质或关系。
• 这个角色在故事中的功能，例如推动、阻碍、映照、诱惑、见证或制造压力。
• 用户倾向保留、回避或暂时不确定的方向。
• 需要你补充的是候选方向、逻辑校对，还是完整设定草案。

如果用户只需要快速校准一个角色，可以先用 novel-technique-character-card-workshop 的 20 问入口：Q24_01 到 Q24_20 覆盖角色核心、调色盘、背景来源、欲望恐惧、防御决策、与 {{user}} 的关系和行为表达。台词或防误读不清楚时，再补 Q24_21 到 Q24_24。

设计多名角色或需要连续推进时，用 task_create 建立 task checklist，并用 task_set_status 一步步推进。不要一次性写完再汇报。

建议 task checklist：

1. 读取故事基础和相关 lorebook。
2. 确认角色名单、角色功能和优先级。
3. 给出核心角色定义、动机矛盾和关系位置的候选，并让用户确认关键方向。
4. 根据已确认方向整理角色弧、可写特征和当前状态。
5. 写入或更新合适位置的 character 内容节点。
6. 汇报保存路径、角色核心定义和待定问题。

如果用户只要求补一个角色，只做这个角色；但仍要检查它和主线、世界规则、势力或关系网是否自洽。

角色设计重点

每个重要角色至少回答这些问题：

• 一句话角色定义：这个角色是谁，为什么值得被写。
• 戏剧功能：主角、反派、同伴、镜像角色、诱惑者、导师、见证者、牺牲者、制度代表等。
• 外部目标：角色现在想得到什么，为什么必须行动。
• 内在需求：角色真正需要学会、面对、放下或承认什么。
• 弱点与恐惧：角色会因为什么做错判断。
• 误信念：角色对自己、他人或世界的错误理解是什么。
• 资源与限制：身份、能力、知识、关系、物品、伤病、禁忌或制度约束。
• 关系位置：与主角、势力、地点、规则和关键人物的关系。
• 角色弧：会成长、堕落、醒悟、固执不变，还是作为主题反证存在。
• 可写特征：说话方式、行动习惯、判断习惯、审美、禁忌、反复出现的小动作。

不要把这些问题写成机械表格。正文应优先解释角色如何在故事中产生压力、选择和变化。

写入 workspace

把用户确认过的稳定角色设定写入内容节点，可变当前状态写入 state.md。先更新已有节点，缺失时再创建新节点。

按角色用途选择节点位置：

• 主角、视角角色、全书常用核心角色：放在 lorebook/character/{slug}/index.md。
• 场景相关、地点绑定、或只出场一次的角色：放在对应场景、地点或事件内容节点之下，例如 lorebook/location/{place}/character/{slug}/index.md。
• 明确属于某个势力的角色：可以放在对应势力节点下，例如 lorebook/faction/{faction}/members/{slug}/index.md。
• 势力内部角色较多时，按组织架构继续分文件夹，例如 lorebook/faction/{faction}/departments/{department}/members/{slug}/index.md。

不要把所有人物都塞进 lorebook/character/。分门别类的标准是：后续创作时，用户和 Agent 最可能从哪里找到这个角色。

需要追踪当前处境时，创建或更新：

• 对应角色节点同级的 state.md

创建常用核心角色节点时，使用：

workspace node new lorebook/character/{slug} --type character --title {角色名} --state

创建绑定到地点或势力的角色时，把 TARGET 换成对应目录下的角色路径，但 --type character 不变。

写入时遵守：

• summary 保持短而可复用。
• 角色定义、画像、动机、误信念、关系和角色弧写入 Markdown 正文，不使用 character.* frontmatter 字段。
• 正文标题可按需要使用“角色定义”“角色画像”“动机与矛盾”“关系与角色弧”等。
• refs 建立到相关角色、地点、势力、规则、物品或 note 的必要引用。
• tags 只写有意义、易理解、可复用的中文短标签；不要为了填字段随意设置。
• 编辑后用 read 复查 index.md / state.md，并用 rg --files 或 rg -n 检查相关路径和 Markdown 引用。

index.md 是稳定设定，不写当前章节临时状态。当前处境、持有物、当前目标、风险与限制写入 state.md。

多角色与关系

同时设计多名角色时，先确定角色之间的功能差异，避免每个人都只是“重要配角”。

可以使用多角色代入检查角色逻辑。每次代入一个角色时，先说明：

• 他知道什么。
• 他不知道什么。
• 他想要什么。
• 他害怕什么。
• 他可能误判什么。
• 他在当前局势下可能采取哪些行动。

这些行动只用于校验角色动机和关系压力，不在本流程中展开章节级剧情规划。角色关键行动、关系转折和角色弧必须经过用户确认后，才能写入稳定设定。

优先区分：

• 谁推动主角行动。
• 谁阻碍主角行动。
• 谁揭示世界规则或制度代价。
• 谁体现主题的另一种答案。
• 谁承担情感关系、利益关系、秘密关系或误解关系。

关系设计要能产生选择压力，不只写“关系很好”“互相信任”“互相敌对”。

收尾

完成后只输出：

• 已保存或更新的角色节点路径。
• 每个角色的一句话核心定义。
• 最重要的关系和角色弧。
• 仍未确定但会影响写作的问题。
• 下一步建议：通常进入 novel-workflow-world-engine-init、novel-workflow-08-plot-planning、novel-workflow-07-opening-plot-design 或 novel-workflow-09-chapter-writing。

聊天回复不要把完整角色文件重复粘贴一遍。

完成标准

• 角色不只是设定集合，而是能在剧情中制造选择、压力和变化。
• 核心角色已有 lorebook/character/.../index.md。
• 需要追踪当前处境的角色已有 state.md。
• 稳定设定和当前状态已经分离。
• 角色和相关世界规则、势力、地点、人物之间有必要 refs。
• 重要未定项被显式保留，没有伪装成已确认事实。