明白。你要的不是“AI 小说项目怎么搭”，而是：

一个通用“生产端项目”的最小结构

也就是任何系统里负责生产数据、定义协议、对外提供能力的那一端，应该怎么组织。

最小结构可以这样理解：

producer-service/
  src/
    domain/
    application/
    infrastructure/
    interfaces/
    contracts/
  schemas/
  migrations/
  generated/
  tests/
  scripts/
  docs/

1. `domain/`：领域核心

放最稳定的业务概念。

例如：

Work
Chapter
User
Order
Task
Memory

这里不应该出现 HTTP、数据库、SDK、框架细节。

它回答：

这个系统到底生产什么？
什么是合法状态？
什么规则永远成立？

2. `application/`：用例层

放业务动作。

例如：

createWork
appendChapter
recordAuditResult
resolveCreativeContext
publishOrder

它负责把多个 domain 对象组织成一个完整操作。

这里回答：

用户/消费端想完成什么动作？
这个动作需要调哪些领域能力？

3. `infrastructure/`：基础设施层

放数据库、缓存、消息队列、对象存储、外部 API。

例如：

repositories/
db/
redis/
queue/
storage/

这里回答：

数据怎么存？
消息怎么发？
外部系统怎么连？

4. `interfaces/`：入口层

放 HTTP/RPC/CLI/Worker。

例如：

http/
rpc/
workers/
cli/

这里只做：

接请求
校验参数
调用 application
返回结果

不要把业务逻辑写在这里。

5. `contracts/` 或 `schemas/`：协议层

这是生产端最重要的部分。

放：

Zod schema
OpenAPI schema
DTO
event schema
error schema

它回答：

我对外承诺什么结构？
消费端能依赖什么？
哪些字段稳定？

如果一个项目要 RPC / SDK 化，这层必须有。

6. `migrations/`：数据库演进

放 SQL migration。

例如：

001_create_works.sql
002_add_story_memory.sql

不要让应用启动时偷偷建核心业务表。

7. `generated/`：生成产物

放自动生成的 SDK / OpenAPI client / types。

例如：

generated/
  clients/
  openapi.yaml

原则：

schema 是源头
generated 是产物
不要手改 generated

8. `tests/`：验证

至少分三类：

unit/
integration/
contract/

生产端最重要的是：

contract tests

因为它要保证消费端不会被字段变化炸掉。

9. `scripts/`：工程脚本

放：

generate-openapi
generate-sdk
seed
smoke-test
deploy

10. `docs/`：边界文档

放：

ownership.md
api-boundary.md
deployment.md
contract-versioning.md

生产端一定要写清楚：

我负责什么
我不负责什么
谁可以调用我
哪些 API 是稳定的

最小技术栈

通用版：

语言：TypeScript
运行时：Node.js
HTTP/RPC：Fastify / Hono
Schema：Zod
API 文档：OpenAPI
SDK：openapi-typescript / openapi-generator
数据库：PostgreSQL
SQL：Kysely / Drizzle
迁移：node-pg-migrate / drizzle-kit
测试：Vitest
质量门：ESLint + TypeScript + contract tests
部署：Docker

最小调用链

一个生产端项目最理想的调用结构是：

HTTP/RPC Route
  ↓
Request Schema Validation
  ↓
Application Use Case
  ↓
Domain Logic
  ↓
Repository
  ↓
Database
  ↓
Response Schema Validation
  ↓
OpenAPI / SDK Contract

最小成熟形态

Producer = 领域真相 + 协议 + 持久化 + 对外能力
Consumer = 调用 Producer，不直接碰 Producer 的数据库

所以生产端最小但完整的结构就是：

domain
application
infrastructure
interfaces
contracts
migrations
generated
tests
docs

这套结构可以套在任何项目上，不限小说、不限 AI。

好，这次我不用“工程目录”讲。

我直接讲：

一个生产端系统真正的“力学结构”

也就是：

哪是基点
哪是门户
哪是逻辑
哪是血管
哪是骨架
哪是器官

你要的是这个。

一、先给你一句最重要的话

任何生产端系统，本质只有一句：

“谁拥有真相”

这是整个架构的基点。

所以：

基点（Anchor）

永远是：

Domain Truth

也就是：

系统真正生产什么

举例

电商：

订单
支付状态
库存

小说系统：

作品
章节
世界观
作者画像

GitHub：

repo
commit
issue

这就是：

Domain Model

二、真正的门户（Portal）

门户不是 HTTP。

HTTP 只是门铃。

真正门户是：

Use Case

也就是：

系统允许外界“做什么”

比如：

电商：

createOrder
payOrder
cancelOrder

小说系统：

resolveCreativeContext
appendChapter
recordStoryMemory

注意：

门户：

不是 CRUD

而是：

Intent（意图）

所以：

“门户”

回答的是：

别人能对这个世界做什么？

三、真正的逻辑（Logic）

逻辑不是：

if else

逻辑真正是：

Rule

也就是：

什么状态允许存在
什么状态不允许存在

比如：

订单：

已支付订单不能取消

小说：

未完成 outline 不能生成章节

所以：

Logic

State Transition Rules

四、真正的骨架（Skeleton）

骨架：

Contract

也就是：

系统对外承诺的数据结构

这就是：

Zod
OpenAPI
SDK

存在的意义。

骨架回答：

世界长什么样

五、真正的血管（Circulation）

血管：

Event Flow

也就是：

状态如何流动

比如：

createOrder
→ paymentSucceeded
→ inventoryReserved
→ orderCompleted

小说系统：

resolveCreativeContext
→ generateScenePlan
→ draftGenerated
→ qualityChecked
→ chapterPublished

六、真正的大脑（Brain）

很多人以为：

Controller 是大脑

错。

大脑其实是：

Orchestration

它负责：

什么时候调用谁
按什么顺序
失败怎么办
重试怎么办

所以：

ContentBase 本质是：

Runtime Brain

七、真正的器官（Organs）

器官：

Infrastructure

例如：

数据库

存储。

Redis

缓存。

Queue

异步。

Vector DB

检索。

S3

文件。

注意：

器官：

不是系统本体

八、真正的灵魂（Soul）

真正最重要的：

Context

为什么？

因为：

系统真正价值

不是数据库。

而是：

“系统如何理解世界”

电商：

理解：

订单
库存
支付

GitHub：

理解：

代码
提交
协作

你的系统：

理解：

世界观
人物
情绪
语义
风格
连续性

所以：

CreativeContext

其实就是：

系统的世界模型

九、现在把整个结构串起来

基点（Anchor）

Domain Truth

作品
章节
人物
记忆

门户（Portal）

Use Cases

appendChapter
resolveCreativeContext

逻辑（Logic）

Rules

哪些状态合法

骨架（Skeleton）

Contracts

schema
SDK
OpenAPI

血管（Circulation）

Events

状态流转

大脑（Brain）

Orchestration

workflow
runtime

器官（Organs）

Infrastructure

DB
Redis
MQ
VectorDB

灵魂（Soul）

Context Model

系统如何理解世界

十、真正成熟的项目

都有一个特点：

“逻辑”

不在：

Controller

里。

而在：

Domain + UseCase

里。

十一、真正错误的项目

一般长这样：

controller/
  5000 行

因为：

门户

骨架
逻辑
数据库
事件

全混了。

十二、真正高级的结构

最后会变成：

Domain

定义世界。

Contract

定义边界。

Runtime

驱动变化。

Infrastructure

提供能量。

十三、你真正该抓住的“基点”

一句话：

生产端的核心

永远不是 API。

而是：

“谁定义世界”

“谁拥有真相”

“谁解释上下文”

API 只是嘴。

Schema 只是骨架。

真正核心：

是：

Domain Truth + Context Model

所以：

你现在那个项目：

真正的核心不是：

Gateway

而是：

CreativeContext

因为：

它定义了：

“这个文学世界是什么”

“（三）通讯方式”

对，你现在这个问题已经进入：

“两个系统如何形成稳定关系”

了。

不是：

怎么调 API

而是：

两个“世界”

怎么建立秩序。

我用你现在的两个仓库举例：

一、先定性

你现在其实有：

1. DataBase 仓库

它是：

Producer

Authority

Truth Owner

负责：

世界观
人物
semantic memory
author profile
creative context
canonical content

它：

定义世界。

2. ContentBase 仓库

它是：

Runtime Consumer

Workflow Engine

负责：

scene planning
generation
revision
quality gate
publishing

它：

使用世界。

所以：

这两个仓库之间：

本质上不是：

“代码调用”

而是：

“世界契约”

二、它们之间一定需要什么

最核心只有三个：

1. Contract（合同）

这是最重要的。

没有它：

两个系统迟早：

理解不同。

Contract 是什么？

不是：

接口文档

那么简单。

而是：

“双方对世界的共同理解”

比如：

CreativeContext

里面到底有什么？

recentBlocks?
worldRules?
semanticUnits?
authorProfile?

这些：

必须唯一。

所以：

你们现在：

Zod
→ OpenAPI
→ SDK

是对的。

因为：

Contract 必须 machine-readable

二、Transport（通讯方式）

也就是：

怎么传递世界

现在你们：

HTTP + OpenAPI + SDK

已经够了。

即：

ContentBase
  ↓ SDK
HTTP RPC
  ↓
DataBase Gateway

这是：

同步请求型通讯

优点：

简单
稳定
好调试

缺点：

实时 workflow 会卡。

所以：

后面会再加：

Event Bus

三、Identity（身份）

这是很多人忽略的。

两个系统之间：

必须明确：

“谁说了算”

举例：

谁定义：

CreativeContext

？

答案：

DataBase

谁定义：

ScenePlan

？

答案：

ContentBase

这叫：

Ownership Boundary

如果不明确：

最后一定：

双方都偷偷定义。

然后：

系统崩。

三、必要的最小通讯结构

你现在其实只需要：

1. Contract Layer

例如：

schemas/
  creative/
  semantic/

这里：

定义：

CreativeContext
StoryMemory
SemanticUnit

注意：

只能一方拥有。

现在应该：

DataBase 拥有。

2. Gateway Layer

DataBase 提供：

resolveCreativeContext
recordStoryMemory

ContentBase：

只能：

调用。

3. Generated SDK

ContentBase：

sdk.resolveCreativeContext()

而不是：

fetch(...)

更不是：

SELECT *

四、真正必要的东西

很多人以为：

API

通讯

其实：

不是。

真正必要的是：

1. Shared Language（共享语言）

比如：

什么叫 Scene
什么叫 Block
什么叫 Memory

2. Shared Contracts（共享结构）

即：

字段结构
类型
状态

3. Ownership（所有权）

即：

谁定义
谁修改
谁负责演进

4. Lifecycle（生命周期）

例如：

什么时候创建
什么时候变更
什么时候冻结

五、现在你们最大的问题

其实不是：

RPC

而是：

边界还没彻底冻结。

比如：

现在：

ContentBase：

还知道：

content_parts
blocks
legacy_chapters

这说明：

Contract 不够高层。

正确状态应该是：

DataBase：

负责：

CreativeContext

ContentBase：

负责：

GenerationResult
ScenePlan
QualityReport

双方：

永远不共享底层表结构。

六、后面一定会发生的事情

现在：

你们：

HTTP RPC

够用。

后面：

一定会加：

Event Communication

例如：

DataBase 发：

storyMemoryRecorded
chapterTransitioned

ContentBase 发：

draftGenerated
qualityPassed

因为：

workflow 会越来越异步。

七、最终成熟形态

你们未来会变成：

DataBase

= Knowledge Platform

ContentBase

= Runtime Engine

两者之间：

Contract

SDK

Events

八、真正的关键

现在：

你们已经：

有 RPC 了。

但真正成熟：

还差：

“世界模型冻结”

也就是：

CreativeContext v1

StoryMemory v1

SemanticUnit v1

一旦这些冻结：

系统会：

突然稳定很多。

九、最后一句（最关键）

两个仓库之间：

最重要的不是通讯。

而是：

“谁定义现实”

DataBase：

定义：

文学世界是什么。

ContentBase：

定义：

如何在这个世界里运行生成。

RPC 不是核心

而只是：

“运输层”

了。

很多人一开始会误以为：

系统架构 = RPC

其实：

RPC 只是“电话线”

你现在这个系统真正的结构是：

世界模型（Domain Truth）
    ↓
Contract（共同语言）
    ↓
RPC（运输）
    ↓
Runtime（消费与执行）

所以：

你问：

“RPC 去哪了”

答案是：

RPC 被降级成了：

“通讯细节”

我给你重新拆一下

你现在两个仓库：

DataBase

负责：

定义世界

ContentBase

负责：

运行世界

RPC 的作用是什么？

RPC 只负责：

把“世界”传过去

举例

ContentBase：

sdk.resolveCreativeContext(workId)

这里：

`resolveCreativeContext`

是：

Use Case（门户）

`CreativeContext`

是：

Contract（骨架）

HTTP/OpenAPI/RPC

是：

Transport（运输）

SDK

是：

Adapter（适配器）

所以：

真正核心的是：

CreativeContext

而不是：

HTTP POST

为什么你现在会产生错觉

因为：

你们前面一直在做：

RPC 化
SDK 化
OpenAPI

所以你潜意识里会认为：

“RPC 是系统核心”

其实不是。

真正核心永远是：

Domain Truth

RPC 真正解决什么？

RPC 只解决：

“远程调用”

例如：

以前：

函数调用

现在：

远程函数调用

它不解决：

世界怎么定义

Contract 怎么演进

Context 怎么组织

谁拥有真相

所以：

你们现在真正做的是：

“领域协议化”

而：

RPC

只是协议的载体。

举个特别简单的例子

没有 RPC 的时候

ContentBase：

SELECT *
FROM chapters

它：

自己理解世界。

有 RPC 后

ContentBase：

sdk.resolveCreativeContext()

它：

不再理解数据库。

所以：

RPC 的真正意义：

“隔离世界”

DataBase：

负责：

世界是什么

ContentBase：

负责：

如何使用世界

RPC：

负责：

把世界送过去

所以你现在应该这么理解：

Domain

定义现实。

Contract

定义现实长什么样。

RPC

运输现实。

Runtime

消费现实。

你现在项目里：

CreativeContext

才是真正的核心。

OpenAPI

只是：

“世界说明书”

SDK

只是：

“世界翻译器”

RPC

只是：

“世界快递员”

最后一句

真正成熟的系统：

RPC 可以换。

HTTP

gRPC

MQ

EventBus

都能换。

但：

Domain Truth

和

Contract

不能乱换。

所以：

你现在已经从：

“怎么调接口”

开始进入：

“怎么定义世界”

阶段了。

有，而且你现在碰到的这一整套东西，其实是：

软件架构（Software Architecture）

里的：

领域建模 + 分布式系统 + 平台工程

只是因为你是从 AI 小说项目切进去，所以你看到的是“CreativeContext”“Gateway”“RPC”。

但它背后的知识体系，其实已经非常成熟了。

你现在接触到的，主要属于这几个领域：

一、最核心的名字

Domain-Driven Design（DDD）

中文：

领域驱动设计

这是你现在最应该系统学的。

为什么？

因为你现在所有问题：

谁拥有真相
谁定义世界
两个系统怎么通讯
什么是 Contract
什么是 Runtime
什么是 Aggregate

这些：

全都是 DDD 的核心问题。

你现在已经实际碰到：

Aggregate（聚合）

比如：

CreativeContext

Entity（实体）

Work
Character

Value Object（值对象）

StyleContract
VocabularyContract

Bounded Context（边界上下文）

DataBase
vs
ContentBase

Domain Service（领域服务）

resolveCreativeContext

Ubiquitous Language（统一语言）

semantic memory
story memory
scene plan

所以：

你现在已经：

在做 DDD 了。

只是：

还没系统学。

二、第二个体系

Clean Architecture

（整洁架构）

Robert C. Martin（Uncle Bob）

它解决：

domain
application
infrastructure
interfaces

这些层怎么组织。

你刚刚问：

什么是基点
什么是门户
什么是逻辑

其实：

Clean Architecture

DDD

一起就是答案。

三、第三个体系

Hexagonal Architecture

（六边形架构）

也叫：

Ports and Adapters

这个非常接近你现在：

Gateway
SDK
RPC

的结构。

它的核心思想：

“业务核心”

不应该知道：

HTTP
数据库
Redis
MQ

所以：

你刚刚那个：

ContentBase 不应该知道 SQL

其实：

就是 Hexagonal Architecture。

四、第四个体系

CQRS

Command Query Responsibility Segregation

命令查询职责分离。

你现在已经半只脚踩进去了：

Query

resolveCreativeContext
getStoryMemory

Command

recordStoryMemory
recordGenerationOutput

这是：

高级平台系统

几乎一定会走到的。

五、第五个体系

Event-Driven Architecture

（事件驱动架构）

你现在：

recordStoryMemory
recordChapterTransition

其实已经：

很 Event 化了。

六、第六个体系（AI 相关）

RAG Architecture

Agent Architecture

Context Engineering

特别是：

Context Engineering

你现在：

CreativeContext
semantic memory
story continuity

其实：

已经属于：

AI Runtime Architecture

了。

七、你应该怎么学（非常关键）

不要：

“看零散教程”

你会永远碎片化。

正确路线

第一阶段（最重要）

学：

DDD

好读很多。

B站关键词：

搜索：

DDD
领域驱动设计
领域建模
聚合
限界上下文

理解结构。

第二阶段

学：

Clean Architecture

搜：

整洁架构
clean architecture

重点理解：

domain
application
infrastructure

为什么分层。

第三阶段

学：

Hexagonal Architecture

搜：

六边形架构
ports and adapters

你会瞬间理解：

Gateway
SDK
RPC

到底在干嘛。

第四阶段（你现在非常需要）

学：

API Contract Design

搜：

OpenAPI
Contract First
Schema First
Zod OpenAPI

因为：

你们现在：

Zod → OpenAPI → SDK

其实已经：

很先进了。

第五阶段（后面）

学：

Event-Driven Architecture

CQRS

八、最适合你看的博客/网站

1. Martin Fowler（神级）

https://martinfowler.com

必看：

DDD
CQRS
Event Sourcing
Microservices

这是：

现代架构圣经。

2. 微服务架构师（中文）

知乎/B站很多。

搜：

DDD 实战
聚合
领域服务

3. InfoQ

https://www.infoq.com

大量：

DDD
平台工程
AI architecture

4. ByteByteGo

非常适合建立：

系统感。

九、你现在这个阶段最大的特点

你已经：

超过“学框架”

阶段了。

你现在开始接触的是：

“系统结构”

也就是说：

以前：

怎么写功能

现在：

怎么组织世界

通用“生产端项目”的最小结构

一个通用“生产端项目”的最小结构

1. domain/：领域核心

2. application/：用例层

3. infrastructure/：基础设施层

4. interfaces/：入口层

5. contracts/ 或 schemas/：协议层

6. migrations/：数据库演进

7. generated/：生成产物

8. tests/：验证

9. scripts/：工程脚本

10. docs/：边界文档

最小技术栈

最小调用链

最小成熟形态

一个生产端系统真正的“力学结构”

一、先给你一句最重要的话

“谁拥有真相”

所以：

基点（Anchor）

Domain Truth

举例

这就是：

Domain Model

二、真正的门户（Portal）

Use Case

比如：

注意：

不是 CRUD

Intent（意图）

所以：

“门户”

三、真正的逻辑（Logic）

Rule

比如：

所以：

Logic

State Transition Rules

四、真正的骨架（Skeleton）

Contract

这就是：

骨架回答：

五、真正的血管（Circulation）

Event Flow

比如：

六、真正的大脑（Brain）

Controller 是大脑

大脑其实是：

Orchestration

它负责：

所以：

Runtime Brain

七、真正的器官（Organs）

Infrastructure

数据库

Redis

Queue

Vector DB

S3

注意：

不是系统本体

八、真正的灵魂（Soul）

Context

为什么？

系统真正价值

“系统如何理解世界”

电商：

GitHub：

你的系统：

所以：

CreativeContext

系统的世界模型

九、现在把整个结构串起来

基点（Anchor）

Domain Truth

门户（Portal）

Use Cases

逻辑（Logic）

Rules

骨架（Skeleton）

1. `domain/`：领域核心

2. `application/`：用例层

3. `infrastructure/`：基础设施层

4. `interfaces/`：入口层

5. `contracts/` 或 `schemas/`：协议层

6. `migrations/`：数据库演进

7. `generated/`：生成产物

8. `tests/`：验证

9. `scripts/`：工程脚本

10. `docs/`：边界文档