31 KiB
我想接入api 去写,以最少人干预写出最优秀的小说,按你上面的流程要怎么设计? 我是要ai自动化流水线工作
可以,应该设计成一个AI 小说自动化流水线系统,不是“一个提示词写到底”。
你要的目标是:
人工只负责输入选题、审核关键关卡、决定是否继续; AI 自动完成选题深化、世界观、人设、卷纲、章纲、正文、润色、质检、上下文记忆更新、伏笔管理。
API 层面建议用结构化输出,不要让 AI 随便返回一大段文本。OpenAI 官方文档里 Structured Outputs 的作用就是让模型输出严格符合你提供的 JSON Schema,适合这种流水线系统做稳定数据交换。(OpenAI 开发者)
一、整体系统架构
你可以把它设计成 12 个 Agent。
不是 12 个模型,而是 12 个不同职责的 AI 调用节点。
用户输入题材
↓
01 选题分析 Agent
↓
02 故事总策划 Agent
↓
03 世界观设定 Agent
↓
04 人物档案 Agent
↓
05 全书结构 Agent
↓
06 分卷细纲 Agent
↓
07 章节卡 Agent
↓
08 正文写作 Agent
↓
09 文风润色 Agent
↓
10 连贯性检查 Agent
↓
11 质量评分 Agent
↓
12 记忆更新 Agent
↓
进入下一章循环
核心原则:
设计类 Agent 输出 JSON。 正文类 Agent 输出 Markdown / 纯文本。 检查类 Agent 输出评分 + 问题 + 修复建议。 记忆类 Agent 输出压缩后的上下文数据。
二、最少人工干预的完整流程
阶段 1:人工只输入一个创作 Brief
用户只填这些:
{
"title_working": "请确认她来过",
"genre": "现实主义悬疑",
"target_words": 50000,
"target_chapters": 30,
"audience": "喜欢现实主义、悬疑、人间观察的读者",
"style": "克制、电影感、认真优雅、深度共鸣",
"for_adaptation": true,
"avoid": ["狗血", "打脸复仇", "豪门虐恋", "低俗猎奇", "强行爽点"],
"core_idea": "AI仿真人视频修复师调查一个系统中不存在的火灾救人女工"
}
然后系统自动跑。
阶段 2:自动生成小说圣经
小说圣经就是全书的最高设定文档。
里面包括:
小说核心; 世界观; 主角; 配角; 反派系统; 情绪主线; 主题表达; 全书结构; 风格规则; 禁用桥段; 伏笔库; 短剧改编方向。
这一阶段最好不要直接写正文。
因为正文还没写,AI 很容易边写边改设定。
阶段 3:自动生成全书粗纲
比如你要 50 章,它先生成:
第 1 卷:发现她不存在,1–10 章
第 2 卷:每个人记忆里的她都不同,11–20 章
第 3 卷:林照是共用身份,21–35 章
第 4 卷:火灾真相与名字确认,36–50 章
这里要控制:
每卷目标; 每卷核心冲突; 每卷反转; 每卷人物成长; 每卷伏笔推进; 每卷结尾爆点。
阶段 4:自动生成当前卷细纲
不要一次生成 300 章细纲。
最稳的是:
全书粗纲一次生成。 每卷细纲分批生成。 每 10 章做一次校准。
这样不会把后面写死,也能防止前后矛盾。
阶段 5:章节自动循环
每一章自动执行下面流程:
读取小说圣经
读取人物档案
读取当前卷纲
读取最近 3–5 章摘要
读取伏笔库
读取本章章节卡
↓
生成正文初稿
↓
文风润色
↓
连续性检查
↓
质量评分
↓
如果评分不达标,自动重写或局部修复
↓
入库正文
↓
更新章节摘要、人物状态、伏笔状态、世界观增量
↓
生成下一章章节卡
人工只需要在这些节点介入:
选题是否通过; 小说圣经是否通过; 每卷大纲是否通过; 每 10 章是否继续; 最终稿是否发布。
三、数据库怎么设计
你这个系统最好不要把内容只写在本地文件里。
建议数据库表这样设计。
1. projects 小说项目表
CREATE TABLE novel_projects (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(255),
genre VARCHAR(100),
target_words INT,
target_chapters INT,
status VARCHAR(50),
style TEXT,
core_idea TEXT,
created_at DATETIME,
updated_at DATETIME
);
2. novel_bible 小说圣经表
CREATE TABLE novel_bible (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
version INT,
bible_json JSON,
bible_text LONGTEXT,
is_active TINYINT DEFAULT 1,
created_at DATETIME
);
这个表保存最高设定。
每次大改都创建新版本,不要覆盖旧版本。
3. characters 人物档案表
CREATE TABLE novel_characters (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
name VARCHAR(100),
role_type VARCHAR(50),
profile_json JSON,
current_state_json JSON,
forbidden_changes_json JSON,
created_at DATETIME,
updated_at DATETIME
);
重点是 current_state_json。
比如人物当前是否知道真相、是否受伤、和主角关系进展到哪里,都放这里。
4. volumes 分卷表
CREATE TABLE novel_volumes (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
volume_no INT,
title VARCHAR(255),
start_chapter INT,
end_chapter INT,
outline_json JSON,
status VARCHAR(50),
created_at DATETIME,
updated_at DATETIME
);
5. chapters 章节表
CREATE TABLE novel_chapters (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
volume_id BIGINT,
chapter_no INT,
title VARCHAR(255),
chapter_card_json JSON,
draft_text LONGTEXT,
polished_text LONGTEXT,
final_text LONGTEXT,
summary_text TEXT,
quality_score DECIMAL(4,2),
status VARCHAR(50),
created_at DATETIME,
updated_at DATETIME
);
正文流程里至少保留三版:
初稿; 润色稿; 终稿。
6. plot_memory 上下文记忆表
CREATE TABLE novel_plot_memory (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
chapter_no INT,
memory_type VARCHAR(50),
memory_json JSON,
memory_text TEXT,
created_at DATETIME
);
memory_type 可以是:
chapter_summary
character_update
world_update
relationship_update
timeline_update
location_update
7. foreshadows 伏笔表
CREATE TABLE novel_foreshadows (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
code VARCHAR(50),
first_chapter INT,
expected_reveal_chapter INT,
actual_reveal_chapter INT,
surface_text TEXT,
hidden_truth TEXT,
status VARCHAR(50),
related_characters JSON,
created_at DATETIME,
updated_at DATETIME
);
status 建议:
planned
introduced
developing
revealed
abandoned
8. quality_reports 质检报告表
CREATE TABLE novel_quality_reports (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
project_id BIGINT,
chapter_no INT,
score_json JSON,
problems_json JSON,
suggestions_json JSON,
pass_status TINYINT,
created_at DATETIME
);
四、API 调用流水线设计
你可以把每个 Agent 做成一个任务节点。
1. generateNovelBible
输入:
{
"project_brief": {},
"market_rules": {},
"style_constraints": []
}
输出:
{
"core_logline": "",
"theme": "",
"worldbuilding": {},
"characters": [],
"plot_structure": [],
"foreshadows": [],
"writing_rules": [],
"forbidden_rules": []
}
这个必须用 JSON Schema 约束。
2. generateVolumeOutline
输入:
{
"novel_bible": {},
"target_volume_no": 1,
"chapter_range": [1, 10],
"previous_volume_summary": ""
}
输出:
{
"volume_title": "",
"volume_goal": "",
"main_conflict": "",
"chapter_outlines": [
{
"chapter_no": 1,
"title": "",
"goal": "",
"main_events": [],
"conflict": "",
"foreshadows_to_introduce": [],
"foreshadows_to_advance": [],
"ending_hook": ""
}
]
}
3. generateChapterCard
输入:
{
"novel_bible_summary": "",
"character_states": [],
"recent_chapter_summaries": [],
"active_foreshadows": [],
"volume_outline": {},
"target_chapter_no": 1
}
输出:
{
"chapter_no": 1,
"title": "",
"target_words": 2500,
"pov": "",
"scenes": [
{
"scene_no": 1,
"location": "",
"time": "",
"characters": [],
"scene_goal": "",
"conflict": "",
"key_actions": [],
"key_dialogue_points": [],
"visual_motifs": []
}
],
"must_happen": [],
"must_not_happen": [],
"ending_hook": ""
}
4. writeChapterDraft
输入:
{
"novel_bible_summary": "",
"style_rules": [],
"character_profiles": [],
"character_current_states": [],
"recent_summaries": [],
"chapter_card": {},
"forbidden_rules": []
}
输出:
{
"chapter_no": 1,
"title": "",
"draft_text": "",
"self_notes": ""
}
5. polishChapter
输入:
{
"draft_text": "",
"style_rules": [],
"target_style": "克制、电影感、认真优雅",
"forbidden_rules": []
}
输出:
{
"polished_text": "",
"changes_summary": []
}
6. continuityCheck
输入:
{
"novel_bible": {},
"characters": [],
"recent_summaries": [],
"foreshadows": [],
"chapter_text": ""
}
输出:
{
"has_conflict": false,
"conflicts": [],
"character_drift": [],
"timeline_errors": [],
"setting_errors": [],
"foreshadow_errors": [],
"fix_suggestions": []
}
7. qualityScore
输入:
{
"chapter_text": "",
"chapter_card": {},
"quality_standard": {
"plot": 20,
"character": 20,
"style": 20,
"emotion": 20,
"adaptability": 20
}
}
输出:
{
"total_score": 86,
"scores": {
"plot": 17,
"character": 18,
"style": 17,
"emotion": 16,
"adaptability": 18
},
"problems": [],
"rewrite_required": false,
"rewrite_plan": []
}
8. updateMemory
输入:
{
"chapter_no": 1,
"chapter_text": "",
"previous_memory": {},
"existing_foreshadows": []
}
输出:
{
"chapter_summary": "",
"character_updates": [],
"world_updates": [],
"relationship_updates": [],
"timeline_update": "",
"location_update": "",
"new_foreshadows": [],
"updated_foreshadows": [],
"next_chapter_must_continue": []
}
五、最关键:自动重写机制
你不能只生成一次就入库。
要有自动质检闭环。
正文初稿
↓
质检评分
↓
如果 score >= 85:通过
如果 75 <= score < 85:局部修复
如果 score < 75:整章重写
如果连续重写 3 次仍不通过:进入人工审核
建议评分标准:
| 项目 | 分数 |
|---|---|
| 剧情推进 | 20 |
| 人物一致性 | 20 |
| 情绪张力 | 20 |
| 文风质量 | 20 |
| 伏笔与结构 | 10 |
| 短剧改编潜力 | 10 |
合格线建议 85 分。
六、上下文怎么自动管理
重点不是把所有正文都塞进 API。
你要做三层记忆。
第一层:永久设定记忆
每次都要带,但要压缩。
包括:
小说一句话核心; 世界规则; 主角核心人设; 主要人物不可改动项; 风格规则; 禁用桥段。
控制在 1500–2500 字。
第二层:近期剧情记忆
每次写新章,带最近 3–5 章摘要。
比如:
第12章:岑青发现旧签到簿中“林照”有五种笔迹……
第13章:姚知知画出五双手……
第14章:陈淑蘅第一次承认林照不是一个人……
控制在 1000–2000 字。
第三层:检索式记忆
不是每次都带全部,而是根据当前章节检索相关内容。
比如本章涉及陈淑蘅,就从数据库取:
陈淑蘅人物档案; 陈淑蘅最近状态; 她相关的伏笔; 她上次出场章节摘要; 她不能说出的秘密。
这部分可以用向量数据库,也可以先用 MySQL 简单检索。
早期版本建议先用 MySQL,不要一开始就复杂化。
七、自动写作主流程伪代码
async function runNovelPipeline(projectId) {
const project = await getProject(projectId);
// 1. 如果没有小说圣经,先生成
if (!project.hasBible) {
const bible = await callAgent("generateNovelBible", {
project_brief: project.brief
});
await saveBible(projectId, bible);
}
// 2. 获取当前章节
const nextChapterNo = await getNextChapterNo(projectId);
// 3. 确保当前卷纲存在
const volume = await ensureVolumeOutline(projectId, nextChapterNo);
// 4. 生成章节卡
const context = await buildChapterContext(projectId, nextChapterNo);
const chapterCard = await callAgent("generateChapterCard", {
novel_bible_summary: context.bibleSummary,
character_states: context.characterStates,
recent_chapter_summaries: context.recentSummaries,
active_foreshadows: context.activeForeshadows,
volume_outline: volume.outline,
target_chapter_no: nextChapterNo
});
await saveChapterCard(projectId, nextChapterNo, chapterCard);
// 5. 写正文 + 自动质检
let finalText = null;
let finalScore = 0;
let attempts = 0;
while (attempts < 3) {
attempts++;
const draft = await callAgent("writeChapterDraft", {
...context,
chapter_card: chapterCard
});
const polished = await callAgent("polishChapter", {
draft_text: draft.draft_text,
style_rules: context.styleRules
});
const check = await callAgent("continuityCheck", {
...context,
chapter_text: polished.polished_text
});
const score = await callAgent("qualityScore", {
chapter_text: polished.polished_text,
chapter_card: chapterCard
});
if (!check.has_conflict && score.total_score >= 85) {
finalText = polished.polished_text;
finalScore = score.total_score;
break;
}
await saveQualityReport(projectId, nextChapterNo, {
check,
score,
attempts
});
}
if (!finalText) {
await markChapterNeedHumanReview(projectId, nextChapterNo);
return;
}
// 6. 保存正文
await saveFinalChapter(projectId, nextChapterNo, finalText, finalScore);
// 7. 更新记忆库
const memoryUpdate = await callAgent("updateMemory", {
chapter_no: nextChapterNo,
chapter_text: finalText,
previous_memory: context.memory,
existing_foreshadows: context.activeForeshadows
});
await updateNovelMemory(projectId, nextChapterNo, memoryUpdate);
// 8. 进入下一章
await markChapterCompleted(projectId, nextChapterNo);
}
八、Agent 调用封装建议
不要在代码里到处写 prompt。
你要建一张 agent_prompts 表。
CREATE TABLE agent_prompts (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
agent_name VARCHAR(100),
version INT,
system_prompt LONGTEXT,
user_prompt_template LONGTEXT,
output_schema JSON,
model_name VARCHAR(100),
temperature DECIMAL(3,2),
max_output_tokens INT,
is_active TINYINT DEFAULT 1,
created_at DATETIME
);
这样以后你调提示词,不用改代码。
每个 Agent 可以有不同模型和温度。
建议:
| Agent | 温度 | 输出 |
|---|---|---|
| 总策划 | 0.7 | JSON |
| 世界观 | 0.5 | JSON |
| 人物档案 | 0.6 | JSON |
| 卷纲 | 0.5 | JSON |
| 章节卡 | 0.5 | JSON |
| 正文写作 | 0.8 | Text |
| 润色 | 0.7 | Text |
| 连贯性检查 | 0.2 | JSON |
| 质量评分 | 0.2 | JSON |
| 记忆更新 | 0.2 | JSON |
设计类要稳。 正文类要有创造力。 检查类要低温度。
九、后台页面怎么设计
你后台需要这些页面。
1. 小说项目列表
显示:
标题; 题材; 目标字数; 当前章节; 总评分; 状态; 最近更新时间。
按钮:
生成圣经; 生成下一章; 自动连写 10 章; 暂停; 人工审核。
2. 小说圣经页面
可查看和编辑:
世界观; 主角; 人物; 卷结构; 风格规则; 禁用规则。
这个页面很重要。 人工主要在这里把方向控死。
3. 章节生产页面
显示:
章节卡; 初稿; 润色稿; 质检报告; 终稿。
按钮:
重写本章; 局部润色; 通过入库; 回滚上一版。
4. 伏笔管理页面
显示:
伏笔编号; 首次出现; 预计回收; 当前状态; 关联人物; 是否逾期未回收。
建议加红色提醒:
“预计第 20 章回收,但当前已写到第 28 章仍未回收。”
5. 人物状态页面
显示每个人:
当前身份; 当前目标; 已知信息; 隐藏秘密; 关系变化; 最后出场章节; 禁止改动项。
这样防止 AI 把人写崩。
6. 质量监控页面
每章评分折线:
剧情推进; 人物一致性; 情绪张力; 文风; 伏笔; 改编潜力。
如果连续 3 章低于 80 分,系统暂停自动写作,进入人工审核。
十、最小可行版本 MVP
你不要一开始做太复杂。
第一版可以只做 6 个 Agent。
1 小说圣经 Agent
2 章节卡 Agent
3 正文写作 Agent
4 质检 Agent
5 修复 Agent
6 记忆更新 Agent
第一版流程:
用户输入题材
↓
生成小说圣经
↓
生成 30 章细纲
↓
循环:
生成章节卡
写正文
质检
不合格修复
保存
更新记忆
第一版数据库只需要:
projects
novel_bible
chapters
characters
foreshadows
plot_memory
quality_reports
agent_prompts
够用了。
十一、最重要的提示词模板设计
你后台每个 Agent 都需要一套固定 Prompt。
下面是可以直接放进系统的核心版本。
1. 小说圣经 Agent Prompt
你是专业长篇小说总策划、网文主编、文学作家、剧作结构师和影视导演。
你的任务不是写正文,而是为一部可长期稳定创作的小说建立“小说圣经”。
你必须输出结构化 JSON,不得输出 JSON 之外的解释文字。
设计要求:
1. 故事必须具备长篇连载能力。
2. 主线清晰,人物弧光明确。
3. 设定不能互相矛盾。
4. 不能使用低级狗血、打脸复仇、无脑爽点、低俗猎奇。
5. 必须设计人物禁止改动项。
6. 必须设计伏笔库。
7. 必须设计分卷结构。
8. 必须考虑后续可改编短剧或视频。
用户创作 Brief:
{{project_brief}}
请输出:
core_logline
theme
worldbuilding
main_characters
supporting_characters
antagonist_system
volume_structure
foreshadow_plan
writing_rules
forbidden_rules
adaptation_notes
2. 章节卡 Agent Prompt
你是长篇小说章节导演。
你的任务是根据小说圣经、当前卷纲、人物状态、最近章节摘要和伏笔库,设计下一章章节卡。
你不得写正文,只能设计本章执行方案。
要求:
1. 本章必须承接上一章。
2. 本章必须推动主线,不能水剧情。
3. 本章至少完成一个剧情推进、一个人物变化或一个伏笔推进。
4. 不得改变人物设定。
5. 不得提前揭露未到时机的秘密。
6. 结尾必须有钩子,但不能狗血。
小说圣经摘要:
{{bible_summary}}
人物当前状态:
{{character_states}}
最近章节摘要:
{{recent_summaries}}
当前伏笔:
{{active_foreshadows}}
目标章节:
{{chapter_no}}
请输出 JSON:
chapter_no
title
chapter_goal
scenes
must_happen
must_not_happen
foreshadows_to_add
foreshadows_to_advance
foreshadows_to_resolve
ending_hook
3. 正文写作 Agent Prompt
你是专业小说家。
请严格根据章节卡创作正文。
必须遵守:
1. 不得修改小说圣经核心设定。
2. 不得改变人物性格和当前状态。
3. 不得提前揭露秘密。
4. 不得新增无关核心势力、境界、人物。
5. 不得用巧合强行推动剧情。
6. 不得写水剧情。
7. 对白必须符合人物身份。
8. 场景必须有画面感。
9. 每一场戏都要推动剧情、人物或伏笔。
10. 文风必须符合指定风格。
小说圣经摘要:
{{bible_summary}}
人物档案:
{{character_profiles}}
人物当前状态:
{{character_states}}
最近章节摘要:
{{recent_summaries}}
章节卡:
{{chapter_card}}
风格要求:
{{style_rules}}
禁止事项:
{{forbidden_rules}}
请创作本章正文,字数 {{target_words}} 字左右。
只输出正文,不要解释。
4. 质检 Agent Prompt
你是严苛的小说主编和连续性审稿人。
你的任务是检查本章是否合格,不负责夸奖。
检查维度:
1. 是否违背小说圣经。
2. 是否人物行为崩坏。
3. 是否时间线冲突。
4. 是否伏笔遗漏或提前暴露。
5. 是否存在水剧情。
6. 是否情绪表达过度狗血。
7. 是否对白不符合人物身份。
8. 是否场景缺乏画面感。
9. 是否本章没有推动主线。
10. 是否适合后续短剧改编。
小说圣经:
{{bible}}
人物状态:
{{character_states}}
伏笔库:
{{foreshadows}}
章节卡:
{{chapter_card}}
本章正文:
{{chapter_text}}
请输出 JSON:
pass
total_score
scores
problems
must_fix
optional_suggestions
rewrite_required
rewrite_strategy
5. 修复 Agent Prompt
你是小说修稿编辑。
请根据质检报告修复本章正文。
要求:
1. 只修复质检指出的问题。
2. 保留原章节中有效的剧情和优秀表达。
3. 不得新增与章节卡无关的大设定。
4. 不得破坏上下文连续性。
5. 修复后必须更符合小说圣经、人设和本章目标。
原正文:
{{chapter_text}}
质检报告:
{{quality_report}}
小说圣经摘要:
{{bible_summary}}
章节卡:
{{chapter_card}}
请输出修复后的完整正文。
6. 记忆更新 Agent Prompt
你是小说连续性档案管理员。
你的任务是根据本章正文更新后续写作需要的记忆库。
你必须准确、简洁,不得加入正文没有发生的内容,不得猜测未来剧情。
本章正文:
{{chapter_text}}
已有伏笔库:
{{foreshadows}}
已有角色状态:
{{character_states}}
请输出 JSON:
chapter_summary
character_updates
relationship_updates
world_updates
timeline_update
location_update
new_foreshadows
updated_foreshadows
resolved_foreshadows
next_chapter_must_continue
forbidden_to_forget
十二、你要做的“上下文拼装器”
这个系统最核心的不是 Agent,而是 Context Builder。
它负责给每次 API 调用拼上下文。
比如写第 18 章,它不能把全部 17 章正文都塞进去,而是拼:
小说圣经摘要
+ 主角档案
+ 本章出场人物档案
+ 最近 5 章摘要
+ 本章相关伏笔
+ 当前卷纲
+ 第 18 章章节卡
+ 禁止规则
伪代码:
async function buildChapterContext(projectId, chapterNo) {
const bibleSummary = await getActiveBibleSummary(projectId);
const volumeOutline = await getVolumeByChapter(projectId, chapterNo);
const chapterPlan = await getChapterPlan(projectId, chapterNo);
const recentSummaries = await getRecentChapterSummaries(projectId, chapterNo, 5);
const sceneCharacters = extractCharactersFromChapterPlan(chapterPlan);
const characterProfiles = await getCharacterProfiles(projectId, sceneCharacters);
const characterStates = await getCharacterStates(projectId, sceneCharacters);
const activeForeshadows = await getRelevantForeshadows(projectId, {
chapterNo,
characters: sceneCharacters,
limit: 20
});
const forbiddenRules = await getForbiddenRules(projectId);
return {
bibleSummary,
volumeOutline,
recentSummaries,
characterProfiles,
characterStates,
activeForeshadows,
forbiddenRules
};
}
十三、自动化程度分三级
L1:半自动
人工确认每章。
AI 写一章 → 人工看 → 通过 → 下一章
适合刚开始测试。
L2:自动 10 章一组
AI 连续写 10 章
每章自动质检
低分章节自动重写
10 章后人工总审
适合稳定后。
L3:全自动长篇生产
AI 自动写完整卷
每 10 章自检
每卷人工审核
自动生成改编剧本、分镜、人物图像提示词
你最终要做到 L3,但第一版建议从 L1/L2 开始。
十四、章节质量评分标准
你后台可以把评分做成固定规则。
{
"plot_progress": {
"weight": 20,
"description": "本章是否有效推动主线"
},
"character_consistency": {
"weight": 20,
"description": "人物行为是否符合既有人设"
},
"emotion_depth": {
"weight": 15,
"description": "是否有真实情绪,不煽情"
},
"style_quality": {
"weight": 15,
"description": "语言是否符合目标文风"
},
"scene_visualization": {
"weight": 10,
"description": "是否适合短剧/视频化"
},
"foreshadow_management": {
"weight": 10,
"description": "伏笔是否合理推进"
},
"continuity": {
"weight": 10,
"description": "是否与前文冲突"
}
}
建议:
90 分以上:精品章节; 85–89:可通过; 75–84:局部修复; 75 以下:重写; 连续 3 次低于 85:暂停人工审核。
十五、最适合你的技术架构
结合你之前做后台、Codex、数据库、AI 系统的习惯,我建议这样:
后端
Node.js / NestJS 或 Python / FastAPI 都可以。
如果你偏后台管理、任务队列、API 编排,建议:
Node.js + NestJS + MySQL + Redis + BullMQ
如果你偏 AI 工作流、文本处理、评估模型,建议:
Python + FastAPI + PostgreSQL/MySQL + Redis + Celery
你之前项目很多 Node.js 和后台任务,我更建议第一版:
Node.js + MySQL + Redis + BullMQ + OpenAI API/国内模型 API
模块结构
novel-system/
src/
modules/
projects/
bible/
characters/
volumes/
chapters/
foreshadows/
memory/
quality/
agents/
workflows/
prompts/
model-provider/
review/
核心服务
AgentService:统一调用模型
PromptService:读取提示词模板
ContextBuilderService:拼装上下文
WorkflowService:编排流水线
QualityService:评分和重写判断
MemoryService:更新上下文记忆
ForeshadowService:伏笔管理
ChapterService:章节生成和版本管理
十六、模型选择策略
不要所有步骤都用最贵模型。
可以分层:
高模型
用于:
小说圣经; 人物档案; 全书结构; 正文写作; 最终润色。
中模型
用于:
章节卡; 记忆总结; 伏笔更新; 分卷细纲。
低模型
用于:
格式转换; 标签提取; 简单摘要; 重复检查。
这样成本会低很多。
十七、最容易翻车的地方
1. 只用一个 Agent 写到底
一定会乱。
必须拆成:
策划、写作、检查、记忆、修复。
2. 不做结构化输出
设计类输出必须 JSON。
否则后面程序无法稳定解析。
3. 不保存版本
每次重写、润色、修复都要保存版本。
否则你不知道哪一版最好。
4. 不做自动停机规则
如果 AI 连续写崩,你不能让它继续自动写。
必须有规则:
连续 3 章低于 80 分 → 暂停
同一章重写 3 次失败 → 暂停
出现核心设定冲突 → 暂停
人物死亡/重大秘密揭露 → 人工审核
5. 让 AI 自己决定所有剧情
全自动不等于完全放任。
正确方式是:
AI 可以自动执行,但不能擅自改主线。
主线、人物命运、重大反转必须由小说圣经和卷纲控制。
十八、给 Codex 的开发任务说明
你可以直接把下面这段给 Codex,让它开始设计系统。
请开发一个 AI 长篇小说自动化生产系统。
目标:
用户输入小说题材 Brief 后,系统自动生成小说圣经、人物档案、分卷大纲、章节卡、正文、润色稿、质检报告、记忆更新和伏笔管理,实现最少人工干预的长篇小说流水线生产。
技术栈:
Node.js + NestJS + MySQL + Redis + BullMQ。
模型供应商需要抽象成 ModelProvider,支持 OpenAI API 和其他兼容 OpenAI 格式的模型 API。
所有 Agent Prompt 存数据库,支持版本管理。
设计类 Agent 必须支持 JSON Schema 结构化输出。
正文类 Agent 输出 Markdown/纯文本。
任务队列使用 BullMQ。
每个章节生成任务必须支持失败重试、质量评分、自动修复和人工审核状态。
核心模块:
1. projects:小说项目管理
2. bible:小说圣经管理
3. characters:人物档案和人物状态管理
4. volumes:分卷大纲管理
5. chapters:章节卡、初稿、润色稿、终稿管理
6. foreshadows:伏笔管理
7. memory:上下文记忆管理
8. quality:章节质检和评分
9. prompts:Agent Prompt 版本管理
10. agents:统一 AI 调用
11. workflows:小说生成流水线编排
12. review:人工审核与回滚
核心流程:
1. 用户创建项目并输入 project_brief。
2. 系统调用 NovelBibleAgent 生成小说圣经。
3. 系统调用 VolumeOutlineAgent 生成当前卷大纲。
4. 系统调用 ChapterCardAgent 生成下一章章节卡。
5. 系统调用 ChapterWriterAgent 生成正文初稿。
6. 系统调用 PolishAgent 润色正文。
7. 系统调用 QualityAgent 做评分。
8. 系统调用 ContinuityAgent 检查上下文冲突。
9. 如果评分 >=85 且无严重冲突,则保存为终稿。
10. 如果评分 75-84,则调用 RepairAgent 局部修复。
11. 如果评分 <75,则重写本章,最多重试 3 次。
12. 如果 3 次仍不通过,标记为 need_human_review。
13. 章节通过后,调用 MemoryUpdateAgent 更新章节摘要、人物状态、伏笔状态、时间线、空间位置。
14. 进入下一章循环。
数据库表:
novel_projects
novel_bible
novel_characters
novel_volumes
novel_chapters
novel_plot_memory
novel_foreshadows
novel_quality_reports
agent_prompts
agent_runs
chapter_versions
后台页面:
1. 小说项目列表
2. 小说圣经编辑页
3. 人物档案页
4. 分卷大纲页
5. 章节生产页
6. 伏笔管理页
7. 质量报告页
8. Agent Prompt 管理页
9. 自动任务队列页
10. 人工审核页
请先输出:
1. 完整系统架构
2. 数据库表结构 SQL
3. NestJS 模块划分
4. API 路由设计
5. BullMQ 任务流程
6. AgentService 和 ModelProvider 代码骨架
7. 第一版 MVP 开发计划
十九、最终建议
你这个系统不要做成“AI 帮我写小说”。
要做成:
AI 主编室 + AI 编剧室 + AI 作家组 + AI 审稿组 + AI 档案管理员
后台真正的核心是:
上下文管理
结构化输出
自动质检
自动修复
版本管理
伏笔管理
人工审核闸门
第一版先做到:
输入题材
→ 生成小说圣经
→ 生成 30 章细纲
→ 自动写单章
→ 自动质检
→ 自动更新记忆
→ 继续下一章
这就已经可以跑通商业化测试了。