作品事实模型

一部长篇作品同时包含稳定规则和持续变化。某座城的地理结构可以长期不变，人物知道了一个秘密以后却必须更新；某个分支曾被认真推演，最终仍可能被放弃；某段正文已经通过审查，后续修订又会产生新的版本身份。

ArcVellum 的项目格式围绕这些差异建立。每一类信息都有明确用途、所有者、生命周期和写回路径。项目文件保持人类可读，机器同时维护 Schema、指纹、事件和账本，使文件能够被编辑，也能够被验证。

四个事实层级

这个分层解决两个常见混乱。首先，模型在推演中说过的话不会自动写入世界观；其次，界面上显示的状态只是可读解释，最终权威仍来自正式项目与 Engine。

Canon：世界能够成立的边界

Canon 保存高稳定度事实与禁止变化。典型内容包括：

• 世界规则、技术水平、制度与物理约束；
• 时间线中的固定事件及其先后关系；
• 地点、组织、身份和资源的既有关系；
• 已确认的秘密、公开事实与可见范围；
• 修改需要高风险审批的禁区。

场景产生新事实时，系统先生成 Canon 候选 patch。语义审查检查它是否来自正文、是否与现有规则冲突、是否把推测误当事实；通过后再进入明确的 apply 操作。这个过程保留来源场景、内容摘要与版本身份。

人物：稳定结构与动态状态并存

人物文件区分长期塑形因素和场景后状态。

稳定结构

• belief：人物当前相信的世界解释；
• desire：人物持续追求的结果；
• intention：近期准备采取的行动；
• fear：主动回避的代价；
• secret：掌握却未公开的信息；
• moral_line：行动不可轻易越过的边界；
• background_story：不会被正文直接说明，却通过选择、回避、误判和语气影响行为的经历。

动态状态

位置、健康、资源、已知事实、未知事实、关系张力与人物弧会在场景以后变化。state-evolve 先准备 patch，Agent 审查因果和副作用，随后由受审计操作应用。人物档案因此可以维持连续性，又不会把每次临场情绪写成永久性人格。

主要人物与次要人物分文件保存。任务编译器通常加载主要人物，并按当前场景参与者、关系和地点选择相关次要人物，减少无关上下文。

场景：规划义务的最小叙事单元

场景定义携带的不只是标题和梗概。正式场景通常包含：

• 目标、冲突、参与者、地点与时间；
• 场景功能，如推进主线、改变关系、制造误判或兑现承诺；
• word_count_target 与允许偏差；
• 节奏角色、速度、密度、叙述距离和对话/反思比例；
• 从上一场接住的压力；
• 留给下一场的问题、代价和钩子；
• 读者在场景前后的认知与情绪变化；
• 当前候选、审查、晋升和写回状态。

场景 YAML 描述义务，正文候选实现义务，Review 判断实现程度。三者拥有独立身份，使系统能够识别“文本写得顺畅但没有完成场景功能”这类文学失败。

长篇账本：跨场景保存读者体验

仅靠 Canon 很难维护长篇的阅读动力。ArcVellum 还维护一组面向叙事效果的账本：

• Reader Question Ledger：读者当前会追问什么，何时应该回答；
• Promise / Payoff Ledger：作品已经做出哪些承诺，计划兑现、反转或解释的时间；
• Continuity Ledger：物件、伤势、知识、关系、地点和时间变化；
• Rhythm Plan：章节及全书的张力、速度和叙事距离曲线；
• Word Budget：目标字数、实际正文、剧情库存和欠账场景；
• Decision Ledger：分支选择、人工批准、策略变更和写回决定。

这些账本把“读者还在等什么”变成可查询状态。后续场景的 Context Packet 可以提取仍然活跃的问题和承诺，Review 也能检查它们是否拖延过久或过早消耗。

文风：独立版本化的生成资产

文风在项目中表现为可挂载版本。一个可靠版本包含来源声明、写作机制抽象、句法与节奏规律、视角和叙事距离、意象和词汇策略、对话方法、禁止模式、适用边界与反例。文风文件以中文字符数衡量详细度，推荐范围为 500 至 2500 字。

挂载动作记录版本身份。正文任务在生成阶段读取文风，Review 再检查实际遵循情况。这样可以把文风从事后评分项提升为生成时的首要约束。

正文的三个身份

候选正文

候选来自当前 TaskPackage 和编剧态。它可以被重写、修订或放弃，仍未进入读者看到的正式作品。

已晋升正文

晋升要求候选内容指纹、AgentReview、确定性 Style Lint、字数、Canon、连续性、读者体验和任务完成证据互相匹配。正式正文进入阅读器与章节汇编。

交付正文

交付管线重新汇编已晋升内容，过滤场景编号、工作流程、Canon 备注、世界状态变化、Review、提示词和草稿标记。Markdown 与 DOCX 使用同一份干净内容模型，再分别执行格式渲染。

内容身份阻止版本漂移

文件名无法证明内容没变。ArcVellum 对关键产物计算 SHA-256，并在 Review、Promotion、Approval 和 Apply receipt 中记录目标摘要。任何候选修改都会让旧审查失效。

这条规则防止一种隐蔽错误：A 版本通过审查，B 版本沿用 A 的通过标记进入正式作品。系统在晋升前重新计算摘要，并要求 Review 指向精确候选。

项目读模型怎样形成

API 不把整个目录直接交给前端。Projection 层读取正式文件和账本，生成稳定的 DTO：章节、场景、人物、关系、任务、质量、进度、正文目录和交付状态。DTO 带版本号与稳定 ID，前端可以缓存、增量更新和恢复选择。

写操作沿相反方向进入明确命令：用户在档案 IDE 中编辑，先形成草稿和差异，再执行检查、保存版本和失效传播；用户选择候选晋升，也要通过应用用例进入 Engine。只读投影与命令端口共同保持界面便利和项目权威。

文件可读性与机器合同的平衡

ArcVellum 使用 YAML、Markdown、JSON 与 JSONL 保存项目。人类可阅读的资产适合 YAML/Markdown，结构化审查和 Receipt 适合 JSON，追加事件适合 JSONL。Schema、原子写入和内容摘要补足普通文件系统的事务能力。

这种格式方便作者备份、版本控制、迁移和手工校勘。代价是跨文件一致性需要专门 Gate，因此项目操作始终经过内核公开接口，避免随意重命名或局部编辑破坏引用。

最小完整项目

一个能够开始正式场景开发的项目至少需要：

1. 项目身份、题材、创作方向和交付目标；
2. Canon 基础与禁止变化；
3. 主要人物及当前状态；
4. 长篇结构、目标字数与场景库存；
5. 已挂载或明确选择的默认文风；
6. 场景定义与前后衔接义务；
7. 工作流目录、任务事件和审批账本。

系统允许逐步补齐资产。每条正式路线会明确指出缺少的事实和允许的下一步，不依赖模型凭经验猜测项目目录。