BLOG

三仓库分工

2026/05/13 7 min read BLOG 三仓库分工

可以。按你的风格，目标不是“多加功能”，而是把它变成一个强边界、强可编辑、强可追踪、AI provider 可替换、模拟人类创作流程的内容操作系统。

你现在已有基础：DataBase 可查作品/章节/语义单元/风格合同，ContentBase 有章节生成/质检/修复/发布 API，MyBlog 是 Astro 静态投影面；但 SDK、workflow engine、文章生成、MyBlog 发布、job status、public projection package 还没完全平台化。

一句话总架构

DataBase = 领域真源 / 知识库 / 引用库 / 账号与作品映射
ContentBase = 创作工作流运行时 / AI provider 编排 / 质检修复发布
MyBlog = 公开投影面 / 阅读展示 / 搜索索引 / 证据库展示

不要三仓互相长器官。

1. 先规范三仓身份

DataBase 负责“世界是什么”

它应该 own：

作品
章节
书籍
作者画像
账号
平台书籍映射
风格合同
语义单元
知识条目
引用来源
证据链
人物/地点/概念
禁用词/当用词
发布目标
Obsidian 投影

DataBase 应该提供：

OpenAPI
generated client
MCP adapter
public projection package
knowledge/reference query API
account/book mapping API

ContentBase 负责“怎么创作”

它应该 own：

生成 workflow
清洗 workflow
质检 workflow
修复 workflow
发布 workflow
AI provider routing
job status
run trace
draft versions

它不应该 own：

作品定义
章节定义
作者画像定义
语义单元定义
账号真源
平台书籍真源

MyBlog 负责“怎么展示”

它应该 own：

Astro content collections
public pages
search index
evidence library UI
reading UX
static build/deploy

它只吃：

public projection artifacts
generated md/mdx
public-data json
search index

2. 加功能的正确顺序

别从 UI 开始，也别从 AI 开始。

按这个顺序：

Domain Spec
↓
API Contract
↓
Generated Client
↓
Workflow Runtime
↓
Projection Export
↓
UI / Console

也就是任何新功能都必须先问：

这个东西是谁的真源？
谁消费？
是否可生成 client？
是否可追踪？
是否可重放？
是否能 dryRun？

3. 你需要补的核心 Domain 模块

A. Book / Work 模块

用于“添加书籍”。

DataBase 增加 canonical 模型：

Book
Work
Volume
Chapter
ChapterOutline
CanonicalContentPart
PlatformBookBinding

添加书籍不要让 ContentBase 直接造。

正确链条：

POST /writes/create-work
POST /writes/create-book-structure
POST /writes/import-outline
POST /writes/append-chapter-outline

输入可以来自：

手写
Obsidian
CSV/JSON
AI 清洗结果
平台扫描结果

但写入必须走 DataBase write API。

B. Knowledge Base 模块

模拟人类创作，不能只是 RAG 文档库。你需要拆成：

KnowledgeItem      知识条目
ReferenceSource    引用来源
EvidenceFragment   证据片段
Concept            概念
Claim              可引用论断
SceneFact          场景事实
WorldRule          世界观规则
StyleExample       风格样例
ReadingNote        读书笔记

人类写作不是“搜一段塞进 prompt”，而是：

阅读
摘录
理解
分类
形成概念
形成观点
引用证据
转化为表达

所以你的链条应该是：

source ingest
↓
clean / chunk
↓
extract claims / concepts / evidence
↓
human editable review
↓
canonicalize into DataBase
↓
retrieve for generation
↓
cite in draft trace

LlamaIndex 已有 Knowledge Graph RAG 查询引擎示例，可以作为知识图谱/RAG 的成熟参考。(Developer Documentation)

C. Reference Library 模块

引用库不能和知识库混在一起。

引用库应该 own：

sourceId
sourceType: book/article/web/archive/video/obsidian
title
author
publisher
publishedAt
url/isbn/fileHash
citationStyle
fragments
claimLinks
usageHistory

然后 ContentBase 生成时不直接“编引用”，而是：

evidenceQuery
↓
DataBase returns evidence bundle
↓
ContentBase uses it
↓
draft trace records used references

D. Account / Platform Mapping 模块

“怎么匹配账号”要放 DataBase，不要放 ContentBase。

DataBase own：

PlatformAccount
PlatformWorkBinding
PlatformChapterBinding
PublishTarget
CredentialRef
SessionStateRef

ContentBase 只执行：

publish(workId, chapterNumber, publishTargetId)

匹配逻辑应该是：

workId
↓
DataBase 查 PlatformWorkBinding
↓
拿到 platform=fanqie, accountId, remoteBookId
↓
ContentBase dryRun 检查候选
↓
真实 publish
↓
回写 publish event/status

ContentBase 不应该自己维护“哪个账号对应哪本书”。

E. AI Provider 模块

生成或清洗数据的 AI 提供方必须可替换。

DataBase 可以存 provider policy，但 ContentBase 执行 provider routing。

建议模型：

AIProvider
AIModel
PromptProfile
TaskProfile
ProviderPolicy
RunTrace
CostRecord

ContentBase capability 输入不要写死 OpenAI/Claude/Gemini，而是：

{
  "taskProfileId": "fiction.chapter.generate",
  "providerPolicyId": "creative-default",
  "fallbackPolicy": "none",
  "input": {}
}

注意：按你的风格，不是 fallback 自动兜底。应该是：

primary provider failed
↓
run status = blocked_provider_failed
↓
除非 task policy 明确允许 alternate provider

也就是“可替换”，但不是“偷偷兜底”。

4. 成熟服务形态

你最终要的是这些 API/capability。

DataBase

GET  /openapi.yaml
GET  /content/works
POST /writes/create-work
POST /writes/import-book
POST /writes/project-obsidian-markdown
 
GET  /knowledge/items
POST /writes/import-reference-source
POST /writes/extract-evidence-review
GET  /references/query
 
GET  /creative/context
GET  /creative/style-contract
 
GET  /platform/accounts
GET  /platform/work-bindings
POST /writes/bind-platform-work

ContentBase

GET  /api/runtime/capabilities
 
POST /api/runtime/jobs
GET  /api/runtime/jobs/:id
POST /api/runtime/jobs/:id/cancel
 
POST /api/content/runtime/generate/article
POST /api/novel/runtime/generate/chapter
 
POST /api/content/runtime/clean/source
POST /api/content/runtime/extract/knowledge
POST /api/content/runtime/quality/check
POST /api/content/runtime/repair/draft
 
POST /api/content/runtime/publish/myblog
POST /api/novel/fanqie/publish-chapter

你现在已经有小说章节生成、规则检查、质量检查、修复、番茄发布等 API；短板正是 ContentBase SDK、文章生成、MyBlog 发布、job status、ContentBase OpenAPI/generated client。

MyBlog

npm run build
public-data/evidence-library.json
public-data/search-index.json
generated md/mdx

不要让它变成 runtime API 服务。

5. 链条如何保持畅通且可编辑

关键是每一步都有 artifact，而不是黑盒一把梭。

Import Source
↓
Raw Artifact
↓
Cleaned Artifact
↓
Extracted Knowledge Draft
↓
Human Review Patch
↓
Canonical DataBase Write
↓
Creative Context Bundle
↓
Generation Draft
↓
Quality Report
↓
Repair Patch
↓
Publish Candidate
↓
Publish Event
↓
Public Projection

每一步都要有：

id
owner
input hash
output hash
provider
prompt profile
model
cost
status
human editable fields
source references

这就是“像人一样创作”的骨架。

6. 成熟轮子怎么用

OpenAPI / generated SDK

用 hey-api/openapi-ts 或 OpenAPI Generator。

hey-api/openapi-ts 可以从 OpenAPI 生成 TypeScript SDK、Zod schema、TanStack Query hooks 等。(GitHub)

用途：

DataBase OpenAPI → database client
ContentBase OpenAPI → runtime client

Temporal

ContentBase 的生成、清洗、质检、修复、发布都应该走 workflow engine。

Temporal 是分布式、可扩展、持久化、高可用的 orchestration engine，TypeScript SDK 用来写 workflow/activity。(GitHub)

用途：

generateChapterWorkflow
generateArticleWorkflow
cleanSourceWorkflow
extractKnowledgeWorkflow
publishFanqieWorkflow
publishMyBlogWorkflow

Backstage

三仓 catalog、ownership、API、文档入口用 Backstage。Backstage 是开源 developer portal，核心是 centralized software catalog，用于统一服务、基础设施和文档。(GitHub)

用途：

DataBase provides API
ContentBase consumes DataBase API
MyBlog consumes public projection

7. 最重要的稳定性规则

不允许隐式兜底

provider failed = blocked
schema mismatch = blocked
missing account binding = blocked
projection stale = blocked

除非显式 policy 允许：

allowedAlternates: ["providerB"]

不允许重复定义

ContentBase 不定义 Work/Chapter/AuthorProfile
MyBlog 不定义 Domain Truth
DataBase 不定义 Workflow State

不允许私有 runtime 泄漏到公开站点

MyBlog 禁止 fetch private DataBase / ContentBase runtime

所有 AI 输出都先进入 draft/review

AI output ≠ canonical truth
AI output = proposal artifact

这点非常符合你的“宁可错不兜底”风格。

8. 最小落地路线

Phase 1：三仓身份定型

每仓只补一个 canonical identity surface：

catalog-info.yaml
project.json
README 的 Architecture Boundary 段

不新建散文档。

Phase 2：DataBase contract 平台化

/openapi.yaml
generated TS client
knowledge/reference/account/book binding API

Phase 3：ContentBase workflow 平台化

job API
workflow run id
provider policy
run trace
generate.article
clean.source
extract.knowledge

Phase 4：MyBlog projection-only

public projection package
generated mdx
evidence-library
search-index
static build

Phase 5：Backstage catalog

三仓关系统一投影，不手写散表。

最终形态

人类/Obsidian/书籍/网页/平台数据
↓
DataBase ingest + canonicalize
↓
知识库 / 引用库 / 作品库 / 账号映射
↓
ContentBase workflow
↓
AI 生成 / 清洗 / 质检 / 修复 / 发布
↓
DataBase 记录结果与证据
↓
MyBlog / Fanqie / 其他平台投影

你要的成熟服务不是“AI 写文章工具”。

而是：

Creative Domain Control Plane
+
AI Workflow Runtime
+
Public Projection Shell

这才是强稳定、强模块化、低耦合、可长期演化的形态。