2. 三者层级关系（核心）

由底层到上层：

最底层：RPC / HTTP API

真正的服务通信方式
- 对外公开多用 HTTP API
- 内网微服务之间多用 RPC
上层：SDK

把 RPC 或 HTTP API 封装成库

开发者不用管接口地址、请求头、协议，直接调方法就行。

最简层级

plaintext

服务端：提供 API 或 RPC 接口
          ↓
SDK：把接口包装成好用的工具库
          ↓
你业务代码：直接引入 SDK 调用功能

# CLI 是什么？（大白话 + 和 API/SDK/ RPC 的关系）

我给你一次性讲透，你马上就全串起来了！

1. CLI 是什么？

CLI = Command Line Interface

中文：命令行工具 / 终端工具

就是你在 VS Code 终端 / CMD / PowerShell 里敲的命令：

bash

运行

pnpm install
git push
npm run ci

这些全是 CLI。

2. 最简单理解

GUI = 图形界面（你点鼠标用的）
CLI = 命令界面（你敲键盘用的）

CLI 就是给程序员用的「终端版 APP」

3. CLI、API、SDK、RPC 到底什么关系？

我给你画最清晰的关系图：

① API / RPC

= 底层接口（服务提供功能）

② SDK

= 把 API/RPC 包装成代码库，给代码调用

③ CLI

= 把 API/RPC/SDK 包装成终端命令，给人敲命令调用

4. 一句话终极总结

API/RPC：服务提供的功能接口
SDK：给代码调用的封装库
CLI：给人在终端敲命令用的工具

5. 你项目里的真实例子

bash

运行

pnpm run ci

这就是 CLI，它底层调用：

6. 你现在 100% 全懂了！

我把四个概念彻底串成一条线：

服务端提供 API / RPC
封装成 SDK 给代码调用
再包一层做成 CLI 给人敲命令用

你现在把：

2. 最简单理解

GUI = 图形界面（你点鼠标用的）
CLI = 命令界面（你敲键盘用的）

CLI 就是给程序员用的「终端版 APP」

3. CLI、API、SDK、RPC 到底什么关系？

我给你画最清晰的关系图：

① API / RPC

= 底层接口（服务提供功能）

② SDK

= 把 API/RPC 包装成代码库，给代码调用

③ CLI

= 把 API/RPC/SDK 包装成终端命令，给人敲命令调用

4. 一句话终极总结

API/RPC：服务提供的功能接口
SDK：给代码调用的封装库
CLI：给人在终端敲命令用的工具

啥是 RPC？和 HTTP 有啥区别？#编程知识百科_哔哩哔哩_bilibili

rpc相当于将api又封装了一下是吧

1. HTTP API 本质就是

客户端发请求 → 服务端处理 → 返回一大串 JSON 文本 RPC 就是把原始 HTTP API 那一堆麻烦事，又深层封装了一层

rpc是一种方式，完全可以用rpc封装api也完全可以rpc直接封装二进制tcp

你管这破玩意叫TCP？_哔哩哔哩_bilibili

除了 TCP，常用网络协议一口气给你分好类，全是开发必懂的

先记核心：TCP 是可靠流式传输，除此之外还有一大批常用协议

一、传输层两大核心（和 TCP 平级）

1. UDP

无连接、不保证可靠、不重传、不排队
快、开销极小
用途：直播、语音通话、游戏、DNS、短视频
RPC 很多也能跑 UDP 追求极致速度

2. QUIC

基于 UDP 开发的新一代协议
谷歌搞的，HTTP3 底层就是 QUIC
握手更快、弱网体验好、切换网络不断线
现在浏览器、手机 App 大量在用

二、应用层协议（你天天在用）

都是基于 TCP/UDP 封装好的：

HTTP / HTTPS

你所有接口、网页、API 全靠它
HTTPS = HTTP + 加密

WebSocket

基于 TCP，长连接
用途：聊天室、实时推送、在线协作文档

gRPC / Dubbo 私有 RPC 协议

多数底层跑 TCP，自定义二进制格式
就是你刚才理解的 RPC 通信协议

MySQL 协议

数据库专用 TCP 协议，端口 3306

SSH

远程登录服务器、Git 协议之一，基于 TCP

FTP / SFTP

文件传输协议

DNS 协议

域名解析，大多走 UDP

Redis 协议

Redis 自定义 TCP 协议

三、和你前面知识点联动（帮你串起来）

HTTP API：底层大多 TCP
RPC：底层可 TCP / UDP / QUIC
WebSocket：底层 TCP 长连接
DNS、游戏、直播：偏爱 UDP
HTTP3：底层 QUIC（基于 UDP）

四、最简单一句话区分

TCP：稳、可靠、不丢包，适合接口、数据库、网页
UDP：快、不管丢包，适合直播、游戏、语音
QUIC：新一代，继承 UDP 优点又更稳，未来主流
其余 HTTP/WebSocket/SSH/ 数据库协议都是在 TCP/UDP 上面包一层应用规则

要不要我给你做一张极简对照表：TCP vs UDP vs QUIC 适用场景一眼分清？

你真正应该做的是：

“外部 RPC，内部 application service”

结构应该像：

console-web    |    | HTTP/tRPC    vContentBase    |    | in-process application calls    vNovelApplicationService    |    | RPC    vDataBase

这是最健康的。

你这个阶段，其实已经不是“要不要 RPC”了。

而是：

你正在把 DataBase 从“数据库仓库”演化成：

“内容领域平台（Content Domain Platform）”

这是非常关键的定位变化。

你现在的 DataBase 已经具备：

canonical content
semantic units
author modeling
publication targets
generated client
gateway contract

这已经明显不是：

ORM + migration

而是：

domain platform

所以：

你接下来要做的不是“把数据库 RPC 化”

而是：

“把领域能力平台化”

RPC 只是 transport。

我先给你最终建议

“领域平台服务（Domain Platform Service）”

ContentBase：

做成：

“产品编排层（Product Orchestration Layer）”

console-web：

做成：

“控制台/BFF 前端”

这是最关键的结构

                     ┌────────────────────┐
                     │   console-web      │
                     │  (control panel)   │
                     └─────────┬──────────┘
                               │
                         HTTP / tRPC
                               │
                     ┌─────────▼──────────┐
                     │    ContentBase     │
                     │ product layer      │
                     │ orchestration      │
                     └─────────┬──────────┘
                               │
                    Canonical Gateway RPC
                               │
              ┌────────────────▼────────────────┐
              │            DataBase             │
              │ content domain platform         │
              │ canonical contracts             │
              │ semantic / style / vocab        │
              └────────────────┬────────────────┘
                               │
                        MySQL / storage

这才是你真正的目标形态。

一、DataBase 不应该继续叫“数据库层”

这是第一件事。

你现在的 DataBase：

已经：

有 canonical model
有 author style
有 semantic units
有 publication target
有 gateway contract

这意味着：

它已经不是 persistence layer

而是：

domain authority

建议你未来甚至考虑改名：

例如：

ContentDomain
CanonicalCore
StoryDomain
CreativeDomain

因为：

DataBase 这个名字会误导未来架构。

别人会以为：

可以随便直连 SQL

但实际上：

canonical gateway 才是真源。

二、RPC 化的核心原则

“只暴露 canonical capability”

不要暴露：

CRUD table RPC

这是最重要的。

错误方向（很多人会做）

例如：

getChapterById()
updateChapter()
insertSemanticUnit()
deletePublicationTarget()

这是：

数据库 RPC 化

不是：

领域平台化。

正确方向

应该暴露：

“领域能力 API”

例如：

canonical content

resolveWork()
resolveChapter()
resolvePublicationTargets()

semantic

resolveSemanticContext()
buildSemanticMaterial()
resolveCreativeMemory()

author modeling

resolveAuthorStyleProfile()
resolveVocabularyConstraints()
resolveForbiddenVocabulary()

publication

resolvePublishTargets()
resolvePlatformBindings()

注意：

都是“resolve/build/query”

不是：

insert/update/delete

因为：

DataBase 应该是领域服务，不是 remote repository。

三、不要把 DataBase 做成“万能后端”

这个特别重要。

很多系统后期会变成：

Everything -> DataBase RPC

然后：

DataBase 变成超级耦合中心。

你一定要避免。

正确职责边界

DataBase 负责：

canonical truth

例如：

作品
章节
风格
semantic units
publication targets
vocabulary
constraints

ContentBase 负责：

orchestration

例如：

生成
workflow
prompt build
审核
发布
retry
provider orchestration
generation state

一个极重要原则

“DataBase 不参与 workflow”

不要：

generateChapter()
publishToFanqie()

进入 DataBase。

否则它会退化成：

巨型业务后端。

四、推荐的 RPC 架构

我强烈建议：

API-first + generated client

你现在已经有 generated client。

这是非常对的。

继续强化。

我建议：

transport：

优先：

HTTP JSON RPC

不要急着 gRPC。

原因：

前后端生态更舒服
调试简单
contract 演进容易
browser 兼容
AI workflow 更灵活

我甚至建议：

contract 用 zod-first

例如：

const ResolveChapterRequestSchema = z.object({...})

然后：

OpenAPI 自动生成
TS client 自动生成
runtime validation
typed client

非常适合你。

五、DataBase 最重要的未来能力

你接下来真正应该建设的：

“Creative Context Resolution”

这是你未来最核心的壁垒。

你现在已经有：

semantic units
style
vocabulary
forbidden words
publication targets

下一步：

不要让 ContentBase 自己拼 prompt context。

而应该：

DataBase 返回：

ResolvedCreativeContext

例如：

{
  work,
  chapter,
  styleProfile,
  vocabularyPreferences,
  forbiddenVocabulary,
  semanticContext,
  narrativeConstraints,
  worldviewContext,
  characterMemory,
}

然后：

ContentBase
    ↓
Prompt Builder

只负责 orchestration。

这是巨大架构升级。

因为：

“创作知识” 会统一沉淀在 DataBase。

六、真正推荐的 RPC 分层

1. Query Layer（重点）

负责：

resolve*
query*
build*

这是核心。

2. Mutation Layer（谨慎）

只允许：

canonical mutation

例如：

bindPublicationTarget()
upsertSemanticUnit()

不要开放随意 CRUD。

3. Workflow Layer（不要）

不要：

generate*
publish*
review*

进入 DataBase。

这些属于 ContentBase。

七、你后面一定会需要的东西

1. Versioned contract

例如：

/v1/canonical
/v2/canonical

一定要早点做。

因为：

AI schema 演进极快。

2. capability-based gateway

例如：

canonical
semantic
creative
publication

而不是：

work
chapter
author

否则会越来越 CRUD 化。

3. snapshot context

未来：

resolveGenerationContext()

应该返回：

generation snapshot

因为：

prompt 要可重现
发布要可审计
rerun 要稳定

这个特别重要。

八、最危险的坑

不要让 ContentBase 重新定义领域模型

你已经开始做 canonical 统一了。

一定坚持。

否则后面会：

database work
contentbase work
publish work
fanqie work

全部漂移。

九、最终推荐架构（非常适合你）

DataBase

定位：

Domain Platform

负责：

canonical truth
semantic memory
author modeling
publication metadata
creative constraints
generated contracts

不负责：

generation orchestration
publishing workflow
retry
queue
provider execution

ContentBase

定位：

Product Backend

负责：

workflow orchestration
generation
review
publish
UI state
execution logs
task pipeline

SDK是什么 RPC是什么 api是什么

2. 三者层级关系（核心）

最简层级

# CLI 是什么？（大白话 + 和 API/SDK/ RPC 的关系）

1. CLI 是什么？

2. 最简单理解

3. CLI、API、SDK、RPC 到底什么关系？

① API / RPC

② SDK

③ CLI

4. 一句话终极总结

5. 你项目里的真实例子

6. 你现在 100% 全懂了！

你现在把：

2. 最简单理解

3. CLI、API、SDK、RPC 到底什么关系？

① API / RPC

② SDK

③ CLI

4. 一句话终极总结

1. HTTP API 本质就是

除了 TCP，常用网络协议一口气给你分好类，全是开发必懂的

一、传输层两大核心（和 TCP 平级）

1. UDP

2. QUIC

二、应用层协议（你天天在用）

HTTP / HTTPS

WebSocket

gRPC / Dubbo 私有 RPC 协议

MySQL 协议

SSH

FTP / SFTP

DNS 协议

Redis 协议

三、和你前面知识点联动（帮你串起来）

四、最简单一句话区分

你真正应该做的是：

“外部 RPC，内部 application service”

你正在把 DataBase 从“数据库仓库”演化成：

“内容领域平台（Content Domain Platform）”

domain platform

你接下来要做的不是“把数据库 RPC 化”

“把领域能力平台化”

我先给你最终建议

推荐路线（非常适合你现在）

DataBase：

做成：

“领域平台服务（Domain Platform Service）”

ContentBase：

做成：

“产品编排层（Product Orchestration Layer）”

console-web：

做成：

“控制台/BFF 前端”

这是最关键的结构

一、DataBase 不应该继续叫“数据库层”

它已经不是 persistence layer

domain authority

DataBase 这个名字会误导未来架构。

canonical gateway 才是真源。

二、RPC 化的核心原则

“只暴露 canonical capability”

错误方向（很多人会做）

数据库 RPC 化

领域平台化。

正确方向

“领域能力 API”

canonical content

semantic

author modeling

publication

都是“resolve/build/query”

DataBase 应该是领域服务，不是 remote repository。

三、不要把 DataBase 做成“万能后端”

DataBase 变成超级耦合中心。

正确职责边界

DataBase 负责：

canonical truth

ContentBase 负责：

orchestration