“植耕大师”AI小说创作平台 - 公理设计文档 (ADD)

文档版本: 1.0
创建日期: 2025年6月14日
分析对象: 《“植耕大师”AI小说创作平台 - 用户需求文档 (URD)》 V1.1
撰写人: “植耕大师”程序员

1. 文档引言

1.1 设计目标

本设计的核心目标是将URD中定义的用户需求（即客户属性 CAs），系统性地映射到功能需求（FRs），并进一步分解为相互独立的、信息量最小的设计参数（DPs）。最终，我们将为每一个DP定义其实现所需的具体过程变量（PVs）。

1.2 设计哲学与原则

本次设计将严格遵循以下四大指导原则：

公理设计 (Axiomatic Design):
- 独立公理 (Independence Axiom): 确保功能需求（FRs）与设计参数（DPs）之间的映射关系是解耦的或非耦合的。即，一个DP的调整只影响一个FR。这是保证系统可维护性、可扩展性的基石。
- 信息公理 (Information Axiom): 在所有满足独立公理的设计方案中，选择信息量最少（即最简洁、最高效）的方案。这与奥卡姆剃刀原则不谋而合。
函数式编程 (Functional Programming):
- 我们将倾向于将核心逻辑（尤其是AI处理部分）设计为纯函数 (Pure Functions)。即，给定相同输入，永远返回相同输出，且无任何可观察的副作用。这使得系统行为高度可预测、易于测试和并行化。
- 数据结构将是不可变的 (Immutable)。任何修改都将返回一个新的数据副本，而非在原地修改。URD中的全局修订报告快照机制已体现此思想。
测试驱动开发 (Test-Driven Development, TDD):
- 每一个设计参数（DP）在定义时，都必须是内在地、明确地可测试的。我们将为关键DP预先定义其测试用例的核心逻辑，确保设计直接服务于质量保证。
奥卡姆剃刀 (Occam's Razor):
- “如无必要，勿增实体”。此原则将贯穿始终，用以削减不必要的复杂性。如果一个简单的设计能满足FR，绝不采用更复杂的。这直接服务于信息公理。

2. 设计域映射与分解 (Domain Mapping & Decomposition)

我们将采用自顶向下的分层分解方法，从系统最高层级开始，逐层深入。

2.1 层级 0: 系统级定义

客户属性 (CA₀): 用户需要一个能将创作哲学（建筑师+园丁）付诸实践，以“冲突”为核心，高效、结构化地辅助小说创作的软件工具。
功能需求 (FR₀): 提供一个集成了奠基、构架、耕植、审校四大创作阶段的AI辅助小说创作环境。
设计参数 (DP₀): “植耕大师”集成软件平台。这是一个单一的、整体的应用程序。

2.2 层级 1: 核心模块分解

FR₀可被分解为URD中定义的四个核心模块FR。

FRs (功能需求):
- FR₁: 奠基 (Foundation) - 管理故事的核心DNA（全局设定、概念、角色、世界、冲突）。
- FR₂: 构架 (Architecture) - 搭建故事的结构性骨架（大纲、章节规划）。
- FR₃: 耕植 (Generation) - 在框架内进行单章节的有机创作。
- FR₄: 审校 (Review) - 对作品进行全局审核与最终完稿。
DPs (设计参数):
- DP₁: 项目数据核心 (Project Data Core) - 一个统一的数据管理模块，负责所有项目文件的存储、读取和版本控制。它包含ProjectConfig、CharacterDB、WorldDB等数据实体。
- DP₂: 结构化规划器 (Structural Planner) - 一个交互式工具集，用于生成和编辑大纲与章节结构。
- DP₃: 沉浸式写作环境 (Immersive Writing Environment) - 集成了上下文检索、AI生成和编辑功能的单章节创作界面。
- DP₄: 全局分析引擎 (Global Analysis Engine) - 一个执行深度分析任务的后台服务，用于生成修订报告。
层级 1 设计矩阵分析:

	DP₁ (数据核心)	DP₂ (规划器)	DP₃ (写作环境)	DP₄ (分析引擎)
FR₁ (奠基)	X	0	0	0
FR₂ (构架)	x	X	0	0
FR₃ (耕植)	x	x	X	0
FR₄ (审校)	x	0	0	X

矩阵解读:
- X 代表强映射关系（该DP直接实现该FR）。
- x 代表弱依赖关系（该FR的实现需要从该DP获取数据）。
- 此矩阵是一个下三角矩阵。这表明我们的设计是一个解耦设计 (Decoupled Design)。例如，要实现FR₂（构架），需要DP₂（规划器），同时DP₂需要从DP₁（数据核心）读取数据。这种顺序依赖是符合逻辑且健康的。这满足了独立公理。

3. 层级 2: 功能级分解与DP/PV详述

现在，我们对每个一级FR/DP对进行进一步分解。

3.1 FR₁: 奠基 (Foundation) -> DP₁: 项目数据核心 (Project Data Core)

子功能需求 (Sub-FRs):
- FR₁.₁: 管理项目全局设定。
- FR₁.₂: 管理核心概念（一句话/一段话）。
- FR₁.₃: 管理深度角色档案。
- FR₁.₄: 管理世界观设定集。
- FR₁.₅: 分析并生成冲突矩阵。
子设计参数 (Sub-DPs):
- DP₁.₁: ProjectConfigService - 一个状态管理服务，负责处理项目配置的CRUD操作。
- DP₁.₂: ConceptGeneratorModule - 一个包含Writer_AI调用的模块，用于生成或验证CoreConcept数据。
- DP₁.₃: CharacterGeneratorModule - 包含Writer_AI调用的模块，用于生成和管理CharacterProfile数据。
- DP₁.₄: WorldAnvilModule - 包含Writer_AI调用的模块，用于生成和管理WorldSetting数据。
- DP₁.₅: ConflictAnalyzerFunction - 一个纯函数，由Editor_AI实现，接收角色和世界数据，返回冲突矩阵。
层级 2 设计矩阵分析 (奠基模块):

	DP₁.₁ (配置)	DP₁.₂ (概念)	DP₁.₃ (角色)	DP₁.₄ (世界)	DP₁.₅ (冲突)
FR₁.₁	X	0	0	0	0
FR₁.₂	x	X	0	0	0
FR₁.₃	x	x	X	0	0
FR₁.₄	x	x	0	X	0
FR₁.₅	0	0	x	x	X

矩阵解读: 同样是一个解耦的下三角矩阵。例如，生成角色（FR₁.₃）需要核心概念（DP₁.₂）和项目配置（DP₁.₁）。分析冲突（FR₁.₅）则需要角色（DP₁.₃）和世界（DP₁.₄）数据。设计逻辑清晰，满足独立公理。
DP₁.₅: ConflictAnalyzerFunction 详细规约:
- 函数式设计: 此DP是实现Editor_AI逻辑的核心。它被设计为一个无副作用的纯函数。
- 函数签名 (PV):
```
function analyzeConflicts(
    characters: Immutable.List<CharacterProfile>,
    world: Immutable.Map<string, any>
): ConflictMatrix;
```
- 过程变量 (PVs):
  - PV₁.₅.₁: 内部冲突识别算法: 遍历characters列表，对于每个character，比较其desire属性与fear属性，生成内在冲突条目。
  - PV₁.₅.₂: 外部冲突识别算法: 遍历characters列表，对于每个character，比较其goal属性与world中的rules和constraints，生成外部冲突条目。
  - PV₁.₅.₃: 角色间冲突识别算法: 对characters列表进行笛卡尔积配对，比较每对角色的values和goals，生成角色间冲突条目。
  - PV₁.₅.₄: 数据结构定义: ConflictMatrix、CharacterProfile、WorldSetting的JSON Schema定义。
- TDD 测试用例:
  - test_internal_conflict: 输入一个desire与fear明显对立的角色，断言返回的ConflictMatrix的internalConflicts字段包含预期条目。
  - test_no_conflict_on_harmonious_pair: 输入两个价值观完全一致的角色，断言interCharacterConflicts字段为空。
  - test_immutability: 断言函数执行后，传入的characters和world对象未被修改。

3.2 FR₂: 构架 (Architecture) -> DP₂: 结构化规划器 (Structural Planner)

FR₂.₁: 生成结构化大纲。 | DP₂.₁: OutlineGeneratorModule
FR₂.₂: 细化章节规划。 | DP₂.₂: ChapterPlannerModule
DP₂.₁: OutlineGeneratorModule 详细规约:
- 函数式设计: 这是一个数据转换模块。输入是ConflictMatrix和模板，输出是StoryOutline。
- 函数签名 (PV):
```
function generateOutline(
    conflicts: ConflictMatrix,
    template: OutlineTemplate
): StoryOutline;
```
- 过程变量 (PVs):
  - PV₂.₁.₁: 模板库: 一个可配置的JSON/XML文件集合，存储“三幕式”、“救猫咪”等模板结构。允许用户自定义是关键。
  - PV₂.₁.₂: 冲突填充逻辑: 根据模板节点（如“激励事件”、“中点”）的元数据标签，从conflicts中智能选择最匹配的冲突项进行填充。
- TDD 测试用例:
  - test_inciting_incident_generation: 输入一个包含强烈“外部冲突”的ConflictMatrix，使用“三幕式”模板，断言生成大纲的“激励事件”节点内容与该冲突相关。

3.3 FR₃: 耕植 (Generation) -> DP₃: 沉浸式写作环境

FR₃.₁: 提供集成的写作界面。 | DP₃.₁: MainEditorComponent (UI组件)
FR₃.₂: 自动检索上下文信息。 | DP₃.₂: ContextRetrieverFunction (RAG_AI)
FR₃.₃: 生成章节样章。 | DP₃.₃: DraftGeneratorFunction (Writer_AI)
FR₃.₄: 提供一致性警报。 | DP₃.₄: ConsistencyCheckerFunction
DP₃.₄: ConsistencyCheckerFunction 详细规约:
- 奥卡姆剃刀应用: 此功能只做一件事：检查文本与核心设定的偏离。它不负责修正，只负责提示，保持功能单一、简洁。
- 函数式设计: 纯函数，输入文本和角色设定，输出一个警报列表。
- 函数签名 (PV):
```
function checkConsistency(
    text: string,
    profile: CharacterProfile
): Array<ConsistencyAlert>;
```
- 过程变量 (PVs):
  - PV₃.₄.₁: 关键词匹配逻辑: 在text中搜索与profile中“最大恐惧”、“核心信条”等相关的关键词或语义。
  - PV₃.₄.₂: 警报数据结构: 定义ConsistencyAlert的结构，包含警报级别、位置和提示信息。
- TDD 测试用例:
  - test_fear_of_heights_alert: 输入一个恐高角色和一段描述他“站在悬崖边”的文本，断言返回的警报列表中包含相关提示。

3.4 FR₄: 审校 (Review) -> DP₄: 全局分析引擎

FR₄.₁: 执行全局审核并生成报告。 | DP₄.₁: GlobalReviewerFunction (Editor_AI)
FR₄.₂: 导出作品。 | DP₄.₂: ExportService
DP₄.₁: GlobalReviewerFunction 详细规约:
- 函数式设计与不可变性: 此函数是整个流程中最复杂的分析函数。它接收整个故事的文本和所有设定数据，返回一份不可变的ReviewReport。每次调用都生成一份新的报告，完美体现了函数式思想。
- 函数签名 (PV):
```
function generateGlobalReview(
    allChapters: Immutable.List<string>,
    projectData: ProjectDataCore
): ReviewReport;
```
- 过程变量 (PVs):
  - PV₄.₁.₁: 逻辑一致性检查器: 跨章节追踪关键实体（如角色生死、物品位置）的状态。
  - PV₄.₁.₂: 角色弧光分析器: 提取主角在关键节点（开头、中点、结尾）的行为和对话，与CharacterProfile中的“顿悟”目标进行语义相似度比较。
  - PV₄.₁.₃: 主题意象追踪器 (Motif Tracker): 使用NLP技术，追踪核心主题词和相关意象在全书中的词频、分布和情感色彩，生成可视化数据。
- TDD 测试用例:
  - test_dead_character_speaks_error: 输入一个角色在第一章死亡、第五章发言的文本集，断言报告的logicErrors字段包含此错误。
  - test_character_arc_completion: 输入一个完整的故事，主角完成了从“懦弱”到“勇敢”的转变，断言报告的characterArc分析结果为“正面”或“完成”。

4. 结论

通过公理设计的系统性分解，我们已成功将《“植耕大师”AI小说创作平台》的全部用户需求，转化为一个逻辑自洽、完全解耦、高度可测试且简洁优雅的设计方案。

满足独立公理: 我们的分层设计矩阵（无论是模块级还是功能级）均呈现为下三角形式，证明了这是一个健壮的解耦设计。每个设计参数（DP）都有其明确且单一的功能职责，为并行开发和未来维护奠定了坚实基础。
满足信息公理: 通过拥抱函数式编程的纯函数和不可变性，以及遵循奥卡姆剃刀原则，我们设计的每个组件都力求功能单一、接口清晰，极大地降低了系统的认知复杂度和信息熵。
内建可测试性: TDD的思想贯穿始终，每个核心DP都附带有明确的测试规约，确保了从设计之初就将软件质量置于最高优先级。

此公理设计文档（ADD）已完成从“需求”到“实现蓝图”的转化。下一步，工程团队即可依据此文档中定义的DPs和PVs，进入具体的模块开发与单元测试编码阶段。整个系统架构清晰、稳定，已为后续的“植耕”工作备好了良田。

植耕大师”程序员
2025年6月14日