想象你接下了一个大工程：在市中心盖一栋两百层的摩天大楼。光靠几个工地散工和一堆散装建材显然不行——你需要蓝图、材料仓库、规格说明书，还得让不同的专业施工队各司其职。写一部长篇小说，本质上就是这样的工程：一百万字、几百个章节、几十个角色。写到第 50 章时，你还得记得第 3 章埋下的伏笔、第 12 章主角是左撇子的细节。通用聊天框式的 AI 工具像散装水泥，而 Novelcrafter 就是那套完整的“施工管理平台”：世界观知识库是材料仓库，章节大纲是施工蓝图，角色卡是材料规格书，AI 是施工机器人，还能接入不同大模型组成的“专业施工队”。这篇内容，我们就把这座“小说大厦”的每个工区都逛一遍。

岗位关联

对 AI 从业者而言，理解 Novelcrafter 的产品架构，等于掌握“长上下文记忆、知识库检索、角色一致性”这组可复用的工程范式——它们正是大模型应用落地时最常遇到的真实挑战。

目录
  1. 可视化演示
  2. 产品定位
  3. 世界观知识库
  4. 章节编排
  5. 角色卡体系
  6. AI协作功能
  7. 多模型接入
  8. 工作流建议
  9. 竞品与价格
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示Codex结构化知识库的语义注入机制、从Book到Arc到Chapter到Text的层次化创作工作流，以及角色卡一致性检查系统。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Codex知识库：5类条目语义注入AI CHR=角色，LOC=地点，PLT=情节 ITM=道具，LORE=世界设定 AI生成时自动注入相关Codex条目 AI(prompt + codex_entries) -> consistent text

产品定位

想象你在市中心接下一单大工程：一栋两百层的摩天大楼。你会随手叫几个工地散工、拎几袋水泥就开始干吗？当然不会——你需要一家专业的建筑公司，他们带来塔吊、图纸体系、材料台账和施工计划。写一部长篇小说正是如此：几十万字、上百章、几十个有名有姓的角色，通用 AI 聊天工具就像散工，而 Novelcrafter 就是那家“专业建筑公司”。

这家公司擅长的赛道只有一条：长篇小说。市面上大多数 AI 写作工具是“万能工具箱”，写邮件、写周报、写营销文案样样行，但样样不精。Novelcrafter 反其道而行——它砍掉通用功能，把全部精力投入到解决长篇创作最痛的三个问题：长上下文记忆（写着写着忘了前面的设定）、人物设定连贯（角色前后矛盾）、章节管理（一百章的结构失控）。

三大痛点在工程上各有对应的解法。长上下文记忆：模型窗口装不下百万字，就用“知识库 + 分层摘要”把关键设定外置；人物设定连贯：用结构化的角色卡约束每次生成；章节管理：用大纲树把“卷—章—节”组织成清晰层级。这三板斧合起来，构成了一个面向长篇创作的“内容工程平台”，而不是一个简单的对话窗口。

所以，判断一款工具是否适合盖小说大楼，先别问它能不能聊天，而要问它有没有“图纸、仓库、规格书”。Novelcrafter 的定位，就是把散落的水泥钢筋收拢成一套施工体系——后面每一节，我们都会走进这座大厦的不同工区看看。

U=min⁡(1, CwinSbook)×100%\displaystyle U = \min\left(1,\ \dfrac{C_{win}}{S_{book}}\right) \times 100\%
公式刻画了“上下文覆盖率”：模型窗口能装下的字数除以全书已写字数。写短稿时覆盖率接近 100%，写到 50 万字时若窗口只有 3 万，覆盖率就掉到 6%。Novelcrafter 的工程化方案，正是要让这个数字尽量维持在高位。
  1. C_win（模型窗口容量）AI 模型一次推理最多能“看到”的字数，好比施工队一次性能背到楼上的材料量。
    CwinC_{win}
  2. S_book（全书已写字数）小说目前已经完成的总字数，相当于大楼已建成的总体积。
    SbookS_{book}
  3. min(1,·)（覆盖率封顶）比值超过 1 说明窗口比全文还大，取 1 即 100%，避免出现超过满分的怪数。
    min⁡(1, CwinSbook)\min\left(1,\ \dfrac{C_{win}}{S_{book}}\right)
  4. ×100%（百分比化）把小数换算成习惯的百分比表达，方便直观比较。
    ×100%\times 100\%

世界观知识库

盖摩天大楼，第一件事不是动工，而是建材料仓库。钢筋、水泥、玻璃幕墙全部按类入库、贴上标签，工程师随手一查就知道某型号钢材放在哪。Novelcrafter 的世界观知识库，就是小说世界的“中央仓库”。

长篇小说的世界观里有地理、历史、势力、魔法规则、科技设定……如果这些散落在各个章节里，AI 写作时很容易“凭空捏造”出前后矛盾的细节。知识库把它们结构化地沉淀下来，写作时 AI 先查库再动笔，就像施工前先领物料单。

知识库有三个关键能力。设定沉淀：把世界观条目分类存放，比如“东方大陆”“灵气复苏体系”“天机阁组织”，每条设定都带标签和说明；场景管理：主角常去的酒楼长什么样、街道什么布局，场景描述从库中引用，保证第 10 章和第 80 章写的是同一家店；素材引用：生成章节时，AI 自动检索相关设定注入上下文，相当于把材料从仓库搬到施工现场。

仓库理得清，施工才不慌。写小说时，作者和 AI 都能随时“凭单领料”，从仓库里取出那座酒馆的招牌样式、那位角色的佩剑颜色——地基打得深，上面几十层楼才不会歪。

P=KhitKreturn×100%\displaystyle P = \dfrac{K_{hit}}{K_{return}} \times 100\%
P 是知识检索的精确率：返回的设定条目中真正相关的占比。精确率越高，说明知识库的标签和索引设计越合理。如果 AI 写“雨夜打斗”时把“沙漠绿洲”的设定也翻出来，那仓库管理就失败了。
  1. K_hit（命中条目数）检索返回的结果里，真正和当前场景相关的设定条目数，是“用得上”的材料。
    KhitK_{hit}
  2. K_return（返回条目数）检索系统一共返回的条目数。返回 10 条、命中 6 条，精确率就是 60%。
    KreturnK_{return}
  3. 比值与百分比化命中数除以返回数，再乘 100% 得到直观的精确率指标。
    KhitKreturn×100%\dfrac{K_{hit}}{K_{return}} \times 100\%

章节编排

材料入库后，建筑师要画施工蓝图：这栋楼计划建多少层、每层什么功能、哪层先浇混凝土。Novelcrafter 的章节编排就是这套蓝图系统，它让两百章的工程变得井井有条。

长篇小说动辄上百章，没有结构规划就动笔，写到中期必然失控。Novelcrafter 提供“章节大纲生成”和“章节树管理”两件核心武器：前者用 AI 把世界观和角色卡转化为分章剧情计划，后者把章节组织成“卷—章—节”的层级树，随时拖拽调整。

大纲生成不是凭空变出剧情，而是基于知识库的伏笔和角色卡的目标，产出每章的核心冲突、视角人物和情节走向；章节树则像文件管理器，作者可以折叠、展开、排序、增删章节；一旦调整，AI 会联动更新后续大纲——就像施工中改了蓝图，相关工种的计划一起重排。

蓝图的价值不在于画得好看，而在于让每个施工队知道自己下一步干什么。有了章节树，作者每天打开工作台，都清楚今天该砌哪面墙、该留哪个窗洞。

Nchapter=⌈WtotalWper⌉\displaystyle N_{chapter} = \left\lceil \dfrac{W_{total}}{W_{per}} \right\rceil
章节数量估算公式：全书预计总字数除以每章目标字数，向上取整。假设目标 90 万字、每章 3000 字，则约需 300 章。这个数字是排工期、估进度的基础。
  1. W_total（全书总字数）计划完成的小说总字数，相当于大楼的总建筑面积。
    WtotalW_{total}
  2. W_per（每章目标字数）单章计划字数，网文常见 2000–4000 字。
    WperW_{per}
  3. ⌈·⌉（向上取整）第 299.5 章不存在，余数不足一章也要按一章计。
    ⌈WtotalWper⌉\left\lceil \dfrac{W_{total}}{W_{per}} \right\rceil

角色卡体系

大楼的每一层都要用同一规格的钢筋：直径、强度、厂商标号都有明文规定。如果 30 层的钢筋和 90 层的不是同一型号，整栋楼的结构安全都成问题。角色卡就是小说人物的“材料规格书”。

读者最不能忍的，是主角第 10 章是左撇子、第 80 章突然右手用剑。人设崩塌的本质，是写作时没有一份权威的“人物规格书”可供比对。Novelcrafter 的角色卡，把角色的性格、外貌、能力、口头禅、目标、黑历史全部结构化存储。

角色卡体系有三层作用。角色设定：每个角色一张卡，字段包括基础属性、性格标签、说话风格、人际关系；一致性维护：AI 生成每章时自动比对角色卡，检测“失忆了还认识老朋友”这类冲突；关系图谱：把角色间的恩怨情仇可视化为网络图，写到某段互动时可以随时查看双方的历史交集。

规格书在手，质检员（AI）才能随时抽检。角色的眼睛颜色、剑法是左手还是右手、怕不怕猫——这些“材料参数”写进卡片，两百章之后的主角，依然是读者初遇时的那个人。

S=NconsistNconsist+Nconflict×100%\displaystyle S = \dfrac{N_{consist}}{N_{consist} + N_{conflict}} \times 100\%
一致性得分：全书与角色卡一致的描述次数，除以一致与冲突次数之和。得分越接近 100%，说明角色越“稳”。Novelcrafter 的目标不是 100%——人工修订总会引入变化——而是让冲突早发现、早修正。
  1. N_consist（一致描述数）全书所有角色描述中，与角色卡设定相符的次数，是“用对了规格”的部件数。
    NconsistN_{consist}
  2. N_conflict（冲突次数）与角色卡设定相矛盾的描述次数，比如把左撇子写成右手持剑。
    NconflictN_{conflict}
  3. 比值与百分比化一致次数占比越高人设越稳；分母同时包含两类次数，避免“没写就没冲突”的假象。
    NconsistNconsist+Nconflict×100%\dfrac{N_{consist}}{N_{consist} + N_{conflict}} \times 100\%

AI协作功能

现代工地不会让工人徒手搬砖。塔吊吊装混凝土、机器人喷涂墙面、无人机巡检进度——机器干的是重复劳动，把工程师从体力活里解放出来，专心盯设计。Novelcrafter 里的 AI，就是这样的“施工机器人”。

很多作者担心“AI 写作 = 替代我”，但 Novelcrafter 的 AI 是协作角色：你仍是总工程师，AI 负责润色文笔、续写灵感、检查上下文，让产出更快更稳。

AI 协作主要有三件事。辅助润色：对一段生硬的对话做文笔优化，同时保持角色说话风格——靠角色卡约束，不会把糙汉子的台词润成书生腔；灵感续写：卡文时给出 3 个候选走向，每个都基于当前剧情与世界观，而不是胡编；上下文感知：生成前自动把知识库相关条目、近期情节摘要拼接成提示词，模型虽然窗口有限，但“看到的”都是关键信息。

机器搬砖 ≠ 机器盖楼。AI 润色出的是“半成品毛坯”，最终砌墙、封顶、验收都得工程师说了算。把琐事交给机器人，把创意留给自己，这才是人机协作的正确姿势。

E=WrevisedTmanual\displaystyle E = \dfrac{W_{revised}}{T_{manual}}
润色效率 = 单位人工时间内完成的修订字数。比如作者花 30 分钟人工打磨 1000 字，效率约 2000 字/小时；如果 AI 先润色再人工把关，同样的时间能处理 6000 字，效率提到 12000 字/小时，翻了 6 倍。公式把“省时间”量化成了可对比的指标。
  1. W_revised（修订字数）一轮修改中实际处理的总字数，包括 AI 改写和人工微调，是机器与人的共同产出。
    WrevisedW_{revised}
  2. T_manual（人工耗时）作者投入在这轮修订上的总时间，单位通常是小时。
    TmanualT_{manual}
  3. 比值（单位时间产出）总数除以时长，得到“每小时处理多少字”，效率越高说明辅助越有效。
    WrevisedTmanual\dfrac{W_{revised}}{T_{manual}}

多模型接入

盖楼需要的不只是一支施工队：打地基找基础工程队，装玻璃幕墙找专业幕墙公司，接水电找机电安装队。每支队伍各有绝活。Novelcrafter 的多模型接入，就是让你按工种挑选 AI“施工队”。

不同大模型各有所长：有的推理能力强，适合设计剧情逻辑；有的文笔细腻，适合润色对白；有的便宜快速，适合批量生成草稿。Novelcrafter 允许在不同 Notebook（写作项目）里绑定不同模型，还可以随时切换。

多模型接入的具体玩法有三层。模型切换：在章节级别绑定模型，这一章写打斗就用动作描写强的模型，下一章写权谋就换推理派；场景适配：大纲和世界观架构这类“重脑力”任务用旗舰模型，日常润色用轻量模型节约成本；密钥管理：自带各家 API Key，按实际调用量计费，账目透明。

聪明的总包不会让所有工种拿同样的工钱。Novelcrafter 让每种“施工队”去干自己最擅长的活儿，既保证质量，又不让预算失控——这是长篇创作工程里非常现实的一课。

V=QscorePprice\displaystyle V = \dfrac{Q_{score}}{P_{price}}
模型性价比 = 质量评分 ÷ 价格。质量评分可以用主观打分或自动评估指标，价格看每千字调用成本。选模型不是选最贵的，而是选性价比最高的——打地基可以请最贵的队，但扫马路请高级工程师就是浪费。
  1. Q_score（质量评分）对该模型在特定场景下输出质量的量化打分（0–100），比如“剧情逻辑合理性”。
    QscoreQ_{score}
  2. P_price（成本价格）该模型在同样场景下的调用成本，单位如元/千字，是请这支施工队的“工钱”。
    PpriceP_{price}
  3. 比值（单位成本的质量）每花一块钱能买到多少质量分，V 越大越值得用。
    QscorePprice\dfrac{Q_{score}}{P_{price}}

工作流建议

再好的施工队，没有流程也会乱成一锅粥。正规工地永远先打地基、再立骨架、然后砌墙、最后装修——顺序反了，返工成本翻倍。Novelcrafter 也沉淀出一条“黄金工作流”。

工具只是脚手架，流程才是关键。Novelcrafter 官网和资深用户社区推荐的流程可以总结为：先建世界观 → 再设角色卡 → 生成大纲 → 逐章写作 → AI 润色 → 人工修订。

这条流程背后有工程逻辑。世界观和角色卡是“约束条件”，先定约束再生成内容，AI 才不容易跑偏；大纲是“中间产物”，把大目标拆成小任务，每章写作时只需关注局部；AI 润色放在初稿之后、定稿之前，先保证内容完整再追求文笔；人工修订永远是最后一道关，AI 的自信不能替代人味。

流程的价值不是束缚人，而是让每一次动笔都有前后文。先建世界再写章，就像先打地基再盖楼——每一步都在为下一步减少返工。这条黄金工作流，才是 Novelcrafter 真正值钱的部分。

T=∑j=1mtj\displaystyle T = \sum_{j=1}^{m} t_j
总工期 = 各环节耗时之和。建世界观 3 天、设角色卡 2 天、出大纲 5 天、写作 60 天、润色修订 10 天，总计 80 天。工程管理的价值在于：识别哪些环节能并行（比如大纲和角色卡微调可以同时做），把串行变成并行，压缩总工期。
  1. t_j（单环节耗时）第 j 个环节消耗的时间，如“建世界观”用 3 天、“写作”用 60 天。
    tjt_j
  2. Σ（累加求和）把所有环节耗时加起来，得到从开工到交付的总时间。
    ∑j=1mtj\sum_{j=1}^{m} t_j
  3. m（环节数）流程中包含的环节总数，在推荐工作流中是 6 个。
    mm

竞品与价格

选施工队时，你会同时收到几家公司报价：A 公司便宜但没盖过超高层，B 公司经验丰富但报价高，C 公司什么都接但口碑一般。选型要看性价比，也要看赛道匹配度。Novelcrafter 在 AI 写作工具市场里的位置，正是那个“只做超高层”的专业户。

和它对比的几类工具：通用对话 AI（ChatGPT/Claude 网页版）像万能散工，写短东西好用，但管理不了百万字工程的记忆与一致；文档协作工具（Notion AI）像普通办公物业，能整理文档，但对“小说施工”的专项支持很弱；而 Novelcrafter 专注长篇叙事，把知识库、章节树、角色卡、多模型调度打包成一套完整方案。

价格方面，Novelcrafter 采用订阅制，按档位提供不同额度：Solo 入门档适合个人作者，Pro 进阶档解锁更多字数与高级功能，团队档支持多人协作权限管理（具体报价以官方最新定价为准）。相比“订阅聊天工具 + 自建文档体系 + 自己写脚本管理一致性”的 DIY 拼装成本，它把工程化能力打包出售，贵在省心。适合人群主要是网文作者、剧本策划，以及研究 AI 创作产品形态的产品经理和开发者。

预算有限时，与其请自称“全能”的杂牌施工队，不如把钱花在只盖过超高层的老牌专业户身上。Novelcrafter 的订阅价不是最便宜的，但它卖的是一整套“别让工程塌方”的保障——对认真写长篇的人来说，这钱花得值。

Cunit=PmonthWmonth×u\displaystyle C_{unit} = \dfrac{P_{month}}{W_{month} \times u}
单字成本 = 月订阅费 ÷（月产出字数 × 工具利用率）。如果一个月写 10 万字、但只有一半时间真正用工具，u=0.5，有效产出 5 万字，单字成本就是月订阅费的五万分之一。算清这笔账，才能判断“专业工具 vs 免费拼装”哪个更划算。
  1. P_month（月订阅费）每月固定支付的订阅价格，单位元或美元，是每个月的“固定工程款”。
    PmonthP_{month}
  2. W_month（月产出字数）一个月内实际完成的写作字数，代表“干了多少活”。
    WmonthW_{month}
  3. u（工具利用率）0 到 1 之间的系数，衡量实际使用工具的占比，避免“买了不用”导致的成本虚低。
    uu
  4. 除法（摊薄成本）固定成本除以产出，产出越高、利用率越高，单字成本越低。
    PmonthWmonth×u\dfrac{P_{month}}{W_{month} \times u}

AI 应用场景

网文作者的日更接力

阶段：AI 应用（写作辅助与内容管理）

解决的问题：连载 200 万字的网文作者，手动记设定极易崩人设，逐章核对设定又耗时巨大。Novelcrafter 用世界观知识库 + 角色卡，让 AI 在每次生成时自动引用设定、比对人设，把“记忆”从作者大脑外置到系统。

具体案例：一位番茄小说作者日更 4000 字，开书前先在知识库里建好宗门势力图与地理设定，给每个重要角色建卡。写到第 120 章时，AI 自动发现“三师兄的佩剑颜色与设定不符”，作者一键修正，读者再没吐槽过“人设崩了”。

产品经理的竞品拆解报告

阶段：应用架构设计（竞品分析与需求提炼）

解决的问题：做 AI 创作工具的产品经理，单看对话界面学不到长篇创作的结构化打法。Novelcrafter 把“知识库 + 大纲 + 角色卡 + 多模型调度”拆成了清晰模块，成为一份可抄作业的架构模板。

具体案例：某 AI 写作产品团队用一周时间拆解 Novelcrafter 的 8 大模块，画出用户旅程地图，发现“上下文感知”是用户付费意愿最高的功能，于是调整自家路线图，优先补上设定知识库。

编剧团队的剧本工程

阶段：AI 应用（多模型调度与协同工作流）

解决的问题：长篇剧集人物关系复杂、集与集之间容易“吃设定”，且润色需求量大。Novelcrafter 的章节树帮助管理每集剧情，多模型接入让不同编剧按场景选模型，既保质量又控成本。

具体案例：一个五人编剧工作室用团队版协作，主编剧负责世界观和角色卡，分集编剧各管一个 Notebook，AI 润色统一对白风格。开播后观众发帖：“三十集了，女主的性格居然一点没歪！”

Python 演示

python40 行
class StoryMemory:    """分层上下文管理器：模拟 Novelcrafter 对长篇小说的记忆压缩。"""     def __init__(self, window_chars=90):        self.window_chars = window_chars        self.chapters = []        self.summary = ""     def add_chapter(self, title, content):        # 写入新章节，若溢出则压缩最早的章节        self.chapters.append((title, content))        self._compress()     def _compress(self):        # 当近期章节总字数超过窗口上限时，把最早章节压缩成一句摘要        while sum(len(c) for _, c in self.chapters) > self.window_chars:            if not self.chapters:                break            title, content = self.chapters.pop(0)            head = content.split(".")[0] + "."            self.summary += "[%s]%s" % (title, head)     def build_prompt(self):        # 组合全局摘要与近期全文，作为送入生成模型的上下文        recent = "\n".join(c for _, c in self.chapters)        return "SUMMARY:\n%s\nRECENT:\n%s" % (self.summary, recent)  def main():    mem = StoryMemory(window_chars=90)    mem.add_chapter("ch1_rain", "Lin Wan drew her sword in the rain, right hand gripping the hilt.")    mem.add_chapter("ch2_tavern", "Lin Wan entered the tavern and ordered a pot of hot wine.")    mem.add_chapter("ch3_amnesia", "Lin Wan woke up with amnesia and forgot every swordsmanship move.")    mem.add_chapter("ch4_lefthand", "Lin Wan caught the flying cup with her left hand, all were shocked.")    prompt = mem.build_prompt()    print(prompt)  if __name__ == "__main__":    main()
目的：演示“分层上下文管理”——旧章节被压缩成摘要进入全局记忆，近期章节保留全文，两者拼接成提示词，模拟小说越写越长时 AI 依然“记得”开篇设定。
  1. self.chapters = []近期章节全文存放区，相当于模型窗口内的“新鲜材料”。
  2. while sum(len(c) for _, c in self.chapters) > self.window_chars:近期区总字数超限时触发压缩循环。
  3. title, content = self.chapters.pop(0)把最早的章节从近期区移出，准备压缩。
  4. head = content.split(".")[0] + "."只保留第一句作为摘要，细节信息有选择地丢弃。
  5. self.summary += "[%s]%s" % (title, head)摘要累加到全局记忆，越写越“懂事”。
  6. recent = "\n".join(c for _, c in self.chapters)近期章节保持全文，保证当前剧情细节完整。
  7. return "SUMMARY:\n%s\nRECENT:\n%s" % (self.summary, recent)全局摘要在前、近期全文在后，组装成上下文提示词。
  8. mem = StoryMemory(window_chars=90)窗口设得越小，压缩越频繁，越能看出分层记忆的效果。

常见误区

误区以为 Novelcrafter 是输入一个创意就能自动产出整本小说的工具，作者只需要躺着等成品。

正解它的核心是“工程化辅助”：你仍是决策者和主要作者，AI 负责保证一致性、提供润色与续写。就像施工平台不会自动盖楼，而是帮施工队管理材料、图纸和进度。小说大厦的每一块砖，依然要由作者亲手砌。

为何常见：市面上“一键生成小说”的营销号泛滥，把 AI 写作工具渲染成全自动黑箱，误导了用户预期。

误区觉得只要模型上下文够长（比如 128k tokens），把全书塞进去就行，知识库和摘要都是多余的。

正解窗口长 ≠ 效果好：成本高、检索慢、中间信息会被稀释。工程化方案用“摘要 + 知识库 + 检索”把最该知道的信息放进窗口，在小窗口下达到更稳的效果。就像工地不能只靠工人记忆力，还要有图纸和仓库。

为何常见：厂商宣传动不动就说“百万字上下文”，让用户产生“足够长 = 全能”的错觉，忽略了信息组织的价值。

误区以为角色卡就是一段人设小传，随便写写就行，和 Word 里的人物档案没区别。

正解角色卡是结构化数据（属性、性格、目标、说话风格、关系），AI 靠它做一致性校验和生成约束。非结构化大段文字难检索、难比对，就像一份没有标号的规格书，工人在施工现场根本没法用。

为何常见：人们习惯用散文写人物小传，没意识到“结构化字段”才是让 AI 能自动检查和引用的关键。

误区认为多模型接入的核心是“模型越强越好”，每个 Notebook 都绑最贵最聪明的模型。

正解多模型的价值在“场景适配 + 成本控制”：大纲任务用推理强的，日常润色用便宜的，质量与成本要算性价比（质量分 ÷ 价格）。全用旗舰模型就像让高级工程师去扫马路，效果没提升多少，预算先爆了。

为何常见：追逐最强模型的习惯使然，忽视了不同任务对模型能力的需求差异巨大。

误区以为设定可以后补，先急着把“黄金三章”写出来最重要，世界观边写边编。

正解Novelcrafter 工作流强调“先建世界再写章”。缺少约束时，AI 生成的每章都可能引入矛盾，后期返工成本远高于前期规划。地基不打好就盖楼，封顶时才发现楼是歪的——拆了重来的代价谁都承受不起。

为何常见：网文圈“黄金三章”的流量压力让作者急于开局，把“尽快发书”误当成“必须跳步”。

面试题

Q1. Novelcrafter 最核心要解决长篇小说创作的哪个痛点？

单选题 · easy

  • A.排版美观与出版格式问题
  • B.长期记忆与设定一致问题← 正确答案
  • C.小说封面与插画设计问题
  • D.读者互动与评论管理问题

答案：B。Novelcrafter 的定位是“长篇小说专属”，核心服务长期记忆与设定一致。排版、封面、读者互动都不是它的主战场。就像专业建筑公司不会去接装修小单，它的赛道是超高层施工。

Q2. 世界观知识库的主要功能是什么？

单选题 · easy

  • A.集中沉淀设定素材供引用← 正确答案
  • B.自动生成小说封面图片
  • C.统计每章字数与阅读时长
  • D.将小说翻译成多国语言

答案：A。世界观知识库把地理、历史、势力等设定集中存储，写作时按需引用，好比工地的中央材料仓库。封面生成、字数统计、翻译都不是知识库的职责——分清“仓库”和“加工厂”，才不会混淆模块分工。

Q3. 角色卡最核心的价值是维护什么？

单选题 · mid

  • A.角色的出场顺序与篇幅占比
  • B.角色设定在全书的一致性← 正确答案
  • C.角色的对话语音与配音风格
  • D.角色的粉丝数量与热度高低

答案：B。角色卡的核心价值是约束 AI 生成的内容符合设定，保证人物不崩。出场顺序、配音、粉丝热度都不是角色卡要解决的问题。就像材料规格书只管“材料标号对不对”，不管钢材运到哪个工地。

Q4. 章节大纲生成的前提是先准备好什么？

单选题 · mid

  • A.出版合同与版权登记材料
  • B.世界观设定与角色卡体系← 正确答案
  • C.封面设计与章节插图素材
  • D.营销方案与平台推广文案

答案：B。大纲生成依赖已沉淀的世界观和角色卡作为约束条件，否则剧情会与设定冲突。出版合同、封面、营销属于外围流程，与大纲生成没有直接关系。有了材料和规格书，蓝图才有依据。

Q5. 处理长上下文时，Novelcrafter 更倾向于采用哪种策略？

单选题 · hard

  • A.清空旧内容只保留最新章节
  • B.把全书全文重复输入给模型
  • C.分层摘要与知识库检索结合← 正确答案
  • D.每章重新建立角色关系图

答案：C。长上下文的工程化方案是“分层摘要 + 知识库检索”，而不是全文塞窗口或清空旧内容。窗口有上限、成本有约束，关键是让上下文里始终有“最该知道的信息”。这是 Novelcrafter 与朴素聊天工具的本质区别。

Q6. 多模型接入的主要收益是什么？

单选题 · mid

  • A.一个模型打天下成本最低
  • B.按场景选模型平衡质量成本← 正确答案
  • C.所有模型输出完全相同
  • D.模型越多写作速度越慢

答案：B。多模型接入以场景适配为核心：重推理的任务用强模型，轻量任务用低成本模型，整体平衡质量与成本。一个模型打天下或全用最强模型都不经济——每种施工队干自己最擅长的活，总包才最省钱。

Q7. Novelcrafter 中章节树结构的主要作用是什么？

单选题 · easy

  • A.展示全书章节层级关系← 正确答案
  • B.自动排版生成 PDF 电子书
  • C.统计每章错别字数量
  • D.一键发布到所有小说平台

答案：A。章节树把“卷—章—节”组织成层级结构，核心作用是展示与调整全书结构。排版、错别字统计、平台发布属于编辑发布环节，不是章节树的职责。蓝图的价值在于看清整体，而不是替代施工。

Q8. 以下哪些属于 Novelcrafter 的典型功能？

多选题 · mid

  • A.世界观知识库沉淀设定← 正确答案
  • B.角色卡维护人物一致← 正确答案
  • C.自动写完整本出版图书
  • D.章节大纲与 AI 润色协作← 正确答案

答案：ABD。世界观知识库、角色卡、章节大纲和 AI 润色都是核心功能。“自动写完整本书”是常见误读——Novelcrafter 是工程化辅助工具，作者仍是主导者。多选要区分“辅助”和“替代”的边界。

Q9. 使用 Novelcrafter 的推荐工作流包含哪些环节？

多选题 · hard

  • A.先建世界观再设角色卡← 正确答案
  • B.每章先出大纲再动手写← 正确答案
  • C.全书定稿后再建世界观
  • D.用 AI 润色并人工把关← 正确答案

答案：ABD。推荐工作流是：先建世界观，再设角色卡，然后生成大纲、逐章写作，最后 AI 润色并人工把关。全书定稿后再建世界观是典型的返工灾难。流程顺序的本质是“先定约束再生成内容”。

Q10. 关于长上下文记忆的常见正确理解有哪些？

多选题 · easy

  • A.窗口越长越不需要知识库
  • B.大模型窗口有限需分层管理← 正确答案
  • C.摘要压缩可保留全书关键信息← 正确答案
  • D.人设一致性只依赖模型记忆

答案：BC。长上下文不是万能药：窗口有限时需分层管理，摘要压缩能保留关键信息。窗口越长越不需要知识库、人设只靠模型记忆都是误区。就像工地不能只靠工人记忆，还要图纸和仓库双保险。