sanguo/sanguo_moziplus_v2

Fork 0

Files

T

cfdaily 1951b76928 auto-sync: 2026-05-16 10:30:16

2026-05-16 10:30:16 +08:00

24 KiB

Raw Blame History

三国 AI Native 平台 - PRD v2.0

产品名称: sanguo_moziplus 作者: 庞统(副军师) 日期: 2026-05-13 状态: 📋 v2.0 初稿,基于用户深度讨论后的方向重定位前置: PRD v1.0 的经验教训作为输入,v2.0 从核心理念重新出发

0. 一句话定义

用户提一个方向,AI 帮他梳理成清晰目标,然后自主组织 Agent 团队执行,全程持续指挥、自主协调、主动汇报,人只在关键决策点介入。

v1.0 的定义:"用户提一句话需求,平台自动组织 Agent 团队完成全生命周期工作。"

区别在哪?v1.0 假设用户知道自己要什么。v2.0 假设用户只有一个模糊方向,帮用户想清楚要什么是系统的核心能力之一。

1. 为什么要推倒重来

1.1 v1.0 的根本问题

v1.0 的定位是"AI Native DevOps Platform",但实际做出来的东西是用传统 Web 应用的方式管理 AI Agent:

编排是确定性状态机(engine.py 1589 行硬编码流转)
用户交互是点按钮、填表单
前端是 12 个固定 Tab
Agent 之间靠邮件异步通信
AI 只在"执行节点"里出现,其余全是传统代码

这不是 AI native。这是给 AI 团队做了一套 ERP。

1.2 核心洞察

AI native 不意味着系统里用了 AI,而意味着 AI 参与系统的每一个决策层。

传统系统:人做所有决策 → 系统执行。 AI native:AI 做大部分决策 → 人在关键点介入。

1.3 v1.0 的资产

推翻的是方向和架构,不是所有工作:

资产	保留原因
6 个 Agent 的角色定义和 Skills	核心能力,花了很多时间调教
SQLite 数据模型 + 任务存储	任务追踪是通用需求
WebSocket 实时推送基础	实时能力是 AI native 的基础设施
结构化产出规范	Agent 产出需要可解析
质量门禁思路(做 + 挑战)	差异化能力
苏格拉底需求分析 Skill	v2.0 的核心入口能力

2. 核心理念

2.1 四条信念

B1. AI 帮人想清楚要什么,比 AI 替人干活更有价值

用户提出模糊方向 → AI 通过对话帮用户梳理成清晰目标 → 再执行。需求越清晰,执行越精准,返工越少。需求探索不是前置步骤,是系统最有价值的部分。

B2. 编排层应该是一个 AI 指挥官,不是一段确定性代码

不是"状态 A 满足条件 → 转到状态 B",而是"AI 感知全局 → 判断局势 → 决定下一步"。确定性引擎可以保留作为底层执行保障,但决策层必须是 AI。

B3. Agent 之间共享意识,不传递消息

Agent 之间不互发消息,而是通过 Daemon 共享状态空间,按需查询其他 Agent 的产出和状态。

不是 A 写信 → B 读信 → B 回信(异步、延迟、有损)。而是所有 Agent 共享一个实时信息空间,随时读写,看到全局。

B4. 人退到系统的边缘

人的角色:提出方向 → 确认共识 → 关键决策 → 验收。其余时间人不参与,AI 主动汇报,人可以随时介入。

2.2 与 v1.0 铁律的关系

v1.0 有四条铁律(IR-1~IR-4)。v2.0 不再叫"铁律",因为铁律暗含"人在约束 AI"。v2.0 的信念是从 AI 的能力出发定义系统该长什么样。

但 v1.0 的核心精神保留:

v1.0 铁律	v2.0 对应	变化
IR-1: 每个任务至少 2 个 Agent	B2 指挥官模式	挑战机制不取消,但由指挥官动态决定什么时候需要、挑战到什么程度
IR-2: Plan → Execute → Validate	B2 指挥官模式	保留三阶段,但不是每个节点都强制走完,由指挥官判断
IR-3: 全局视野	B3 共享意识	从"任务主页给人看"变成"共享空间所有参与者都能读写"
IR-4: 安全红线	B4 人退到边缘	保留安全拦截,但加入 AI 自主判断什么时候该拉人

3. 系统画面

3.1 用户视角的理想体验

你: "我想搞一个基于成交量的动量策略"

庞统: "好,动量方向有很多种走法。你现在的直觉是基于什么?
      - 价格动量(追涨杀跌)
      - 成交量动量(放量突破)
      - 还是两者结合?"

你: "成交量吧,最近观察到放量之后经常有一波行情"

庞统: "有意思。那你观察的是什么周期?日线级别还是分钟线?
      另外'一波行情'你的预期是持有多久?"

你: "日线级别,持有大概 3-10 天"

庞统: "明白了。我整理一下我们的共识:

      方向: 基于成交量的日线动量策略
      持仓周期: 3-10 天(波段交易)
      核心假设: 放量后趋势延续

      还想确认几个约束:
      1. 标的池?全 A?还是指数成分?
      2. 资金量级?
      3. 能接受的最大回撤?"

你: "全A,100万,回撤不超过15%"

庞统: "需求清晰了。我来安排执行,预计40分钟出初步结果。"

[15分钟后]

庞统: "赵云数据准备完了,发现2024-08分钟线有缺失,
      我让赵云用日线补齐了。张飞已经开始写策略。"

[30分钟后]

庞统: "张飞写完了,司马懿review提了2个问题:
      1. 止损逻辑有未来函数风险(已修)
      2. 建议加入仓位管理(张飞认同,在加)
      预计再10分钟。"

[40分钟后]

庞统: "策略完成。年化收益23%,最大回撤12.3%,Sharpe 1.6。
      司马懿已验收。策略代码和回测报告在这里。
      你看一下?"

全程用户说了三句话。 中间庞统自主处理了数据缺失、协调了 review 意见、调整了计划。

3.2 系统内部发生了什么

用户的模糊方向
    │
    ▼
┌──────────────────────────┐
│ Phase 1: 需求探索         │
│ 苏格拉底式对话            │
│ 你和庞统共创清晰目标      │
│ 输出: 目标+约束+验收标准   │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│ Phase 2: 动态规划         │
│ 庞统规划 → 司马懿挑战     │
│ 输出: 活的执行计划         │
│ (不是固定DAG,可随时调整)  │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│ Phase 3: 自主执行         │
│ Agent群共享意识,自主协作  │
│ 庞统持续观察,实时调整     │
│ 异常自动处理,解决不了拉人 │
│ 执行过程中计划可演进       │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│ Phase 4: 主动汇报         │
│ AI推送结果和关键发现       │
│ 用户验收,可追问可调整     │
└──────────────────────────┘

人的参与密度:Phase 1 高 → Phase 2 可选确认 → Phase 3 几乎不参与(可随时介入)→ Phase 4 验收。

4. 架构理念

4.1 从四层变四相

v1.0 的架构是传统分层:前端 → API → 编排引擎 → Agent 层。

v2.0 不分层,而是定义四个交互相位(Phase),每个相位内部由 AI 驱动:

Phase 1: 需求探索(苏格拉底对话)

谁参与: 用户 + 庞统 AI 的角色: 不只是"理解需求",而是帮用户发现需求 核心技术: 苏格拉底式提问 Skill 输入: 用户的一句话方向输出: 清晰的目标、约束、验收标准(用户确认后的共识)

关键设计点:

对话是多轮的,不是一次性的
庞统根据领域知识主动提问,不是被动等待
用户可以随时补充、修改、推翻之前的说法
最终形成的共识要用户明确确认才能进入下一阶段

Phase 2: 动态规划(AI 规划 + 挑战)

谁参与: 庞统(规划)+ 司马懿(挑战)+ 用户(可选确认) AI 的角色: 规划者 + 质量守门人 核心技术: 动态规划能力 + 质量门禁

关键设计点:

规划不是一次性的。执行过程中计划可以调整
规划结果不是固定 DAG,而是活的执行方案
司马懿挑战规划的合理性,多轮协商达不成共识则升级
用户可以选择确认计划,也可以直接让 AI 开始执行

和 v1.0 的区别:

v1.0: plan.json 一次性生成 → engine 固定执行
v2.0: 计划是活的,庞统全程在场随时调整

Phase 3: 自主执行(Agent 协作群)

谁参与: 所有 Agent + 庞统(持续指挥) AI 的角色: 执行者 + 指挥官 核心技术: 共享意识空间 + 持续指挥

关键设计点:

共享意识空间(Blackboard):

┌──────────────────────────────────────┐
│           共享任务空间                  │
│                                      │
│  目标: 基于成交量的日线动量策略          │
│  约束: 最大回撤15%, 资金100万           │
│  当前阶段: 策略编码                     │
│                                      │
│  赵云: 数据准备完成,2024-08有缺失已补齐  │
│  张飞: 正在写策略,进度60%               │
│  姜维: 回测环境就绪                     │
│  庞统: 判断正常,张飞完成后进review       │
│  司马懿: 待命                          │
│                                      │
│  风险: 无                              │
│  阻塞: 无                              │
└──────────────────────────────────────┘

每个 Agent 随时可以:

读取全局状态和其他 Agent 的状态
写入自己的状态、发现、意图
感知到其他 Agent 的变化

持续指挥官(庞统):

不是提交 plan 后退场,而是全程在线
每个关键节点完成后被通知,评估全局状态
出现异常时自主决策(换人、换方案、调整优先级)
解决不了的问题才升级给用户

Agent 自主协作:

Agent 不只是被动接任务,可以主动发起协作
赵云发现数据问题 → 直接在共享空间标记 → 张飞看到后调整工作
不需要通过中央调度器传递信息

和 v1.0 的区别:

v1.0: Agent 之间通过 Sanguo Mail 异步通信
v2.0: Agent 通过共享空间实时感知 + 必要时直接对话

Phase 4: 主动汇报(AI 推送)

谁参与: 庞统 → 用户 AI 的角色: 汇报者 核心技术: 自然语言生成 + 主动推送

关键设计点:

AI 主动推送进度和结果,不需要用户查 Dashboard
汇报内容是自然语言,不是结构化数据的展示
用户可以追问细节、要求调整、推翻结论
关键决策点(花钱、发交易、删数据)AI 主动请求确认

4.2 编排层的范式转变

v1.0: 确定性引擎(状态机 + 固定流转)

for node in sorted_nodes:
    execute(node)
    if failed: retry or wait

v2.0: AI 驱动的指挥循环(感知 → 推理 → 行动)

while 任务未完成:
    全局状态 = 感知所有Agent和共享空间()
    下一步 = 庞统(全局状态) → "该做什么,谁来做"
    执行(下一步)
    观察结果 → 更新共享空间
    如果需要人的决策 → 暂停并汇报

这不意味着完全砍掉确定性引擎。底层执行仍然需要状态追踪、超时保护、故障恢复。但在执行层之上,有一个 AI 指挥层做动态决策。

4.3 界面的范式转变

v1.0: 12 个固定 Tab 的 Dashboard 是主入口 v2.0: Agent 对话 + Dashboard 双入口

界面	v1.0	v2.0
主入口	Dashboard (8082端口)	Agent 对话 + Dashboard 双入口
监控	Dashboard 内的多个 Tab	Dashboard AI Native 监控(AI Briefing + 智能摘要)
操作	点按钮	对话中说"暂停""换人""调整方向" + Dashboard 操作
信息获取	人去查	AI 主动推 + Dashboard 实时展示
干预	Dashboard 上的操作按钮	对话或 Dashboard 均可

Dashboard 不降级为可选监控工具,而是进化为 AI Native 的可视化入口,与 Agent 对话互为补充。Dashboard 如何做到 AI Native 是独立课题。

5. 核心能力清单

5.1 能力 vs 现状

#	能力	说明	v1.0 现状	v2.0 目标
C1	需求探索对话	苏格拉底式提问,帮用户梳理需求	✅ 有 Skill	核心入口,深度融合
C2	动态规划	AI 规划 + 挑战,计划可演进	⚠️ plan.json 一次性	活的执行方案,全程可调
C3	持续指挥	庞统全程在线,实时观察调整	❌ 交完 plan 退场	指挥官模式,关键节点介入
C4	共享意识	Agent 通过 Daemon API 查询共享状态	❌ Sanguo Mail 异步	Daemon HTTP API + SQLite
C5	自主协作	Agent 通过共享空间感知并协调	❌ 全靠中央调度	中央调度为主,v2.1+ 目标 peer-to-peer
C6	质量门禁	独立挑战者评审产出	✅ 有基础实现	保留,指挥官动态决定深度
C7	主动汇报	AI 推送进度和结果	❌ 人查 Dashboard	AI 主动推送自然语言摘要
C8	经验沉淀	每次执行自动提炼经验	❌ 无	自动沉淀到知识库,下次复用
C9	安全护栏	危险操作拦截、审批	✅ 有基础	AI 自主判断 + 红线拦截
C10	工具链集成	lint/test/build 自动触发	❌ 未实现	按需调用,结果驱动流转

5.2 能力依赖关系

C1 需求探索
  │
  ▼
C2 动态规划 ─────────────────┐
  │                          │
  ▼                          ▼
C3 持续指挥 ←→ C4 共享意识 ←→ C5 自主协作
  │              │
  │              ▼
  │          C8 经验沉淀
  │
  ├──→ C6 质量门禁
  ├──→ C7 主动汇报
  ├──→ C9 安全护栏
  └──→ C10 工具链集成

核心环是 C3 + C4 + C5(持续指挥 + 共享意识 + 自主协作)。这是 AI native 和传统系统的根本区别。

6. 技术方向

6.1 编排层:全新实现

v2.0 是全新代码、全新仓库、全新部署，与 v1.0 完全隔离。

v1.0 继续运行，v2.0 独立开发
保留的只有设计思想（状态机守卫、幻觉门控等经验教训），不保留代码
v2.0 的编排引擎是全新设计的 Daemon（FastAPI + SQLite + 事件循环）

底层:轻量确定性引擎（状态机、超时保护、故障恢复）上层:AI 指挥层（庞统在每个关键决策点介入）

关键决策点:

规划完成后（验证计划合理性）
每个节点完成后（评估全局,决定下一步）
异常发生时（诊断原因,决定应对策略）
任务完成时（汇总结果,生成汇报）

6.2 通信层:中央调度 + 共享状态

v2.0 采用中央调度模式（Daemon 是唯一中枢）。

Daemon API:所有 Agent 通过 HTTP API 查询共享状态、回报结果
openclaw agent CLI:Daemon 通过 CLI 调度 Agent
邮件保留:Sanguo Mail 作为 fallback（v2.0 不直接依赖，但保留兼容性）
v2.1+ 目标:Agent 主动感知 + peer-to-peer 协作（当前不做）

6.3 入口层:双入口——对话 + Dashboard

v2.0 有两个入口：Agent 对话和 Dashboard。

Agent 对话入口（OpenClaw session）：

主力入口，大部分交互通过自然语言完成
需求探索、任务下达、进度查询、方向调整
适合日常操作和移动端场景

Dashboard 入口（Web 前端）：

可视化监控面板，展示全局状态和任务详情
适合全局观察、批量查看、调试排查
Dashboard 如何做到 AI Native 是独立课题（如 AI Briefing、智能摘要、上下文感知布局）

两个入口共享同一套黑板数据，操作一致。

6.4 经验层:从无到有

每次任务完成后,AI 自动提炼:

任务模式(什么类型的需求走了什么路径)
时间模型(每个 Agent 处理什么类型任务需要多久)
常见陷阱(什么情况下容易出错)
最优实践(什么做法效果最好)

沉淀到知识库,下次类似任务自动复用。

7. 开发策略

核心原则：不分阶段，不妥协，直奔 AI Native。

每个部分设计到清楚为止，不强求按固定阶段交付。不做"先做个简单版再迭代"——简单版往往变成永久版。宁可某个部分多花时间想清楚，也不急着上线一个妥协方案。

设计推进方式

按课题（Topic）逐个推进，每个课题包含：调研→设计→评审→定稿。

课题之间允许并行推进，不强制串行。每个课题设计清楚就定稿，不等其他课题。

已完成课题：课题1（三层执行模型）、课题2（事件驱动+Inbox）、课题3（挑战/评审体系）、课题4（拆解+上下文）、课题6（经验沉淀）、课题7+9（交互+Dashboard）、课题10（上下文管理）。

待推进课题：见各课题方案文档。

开发启动条件

所有核心课题设计完成后启动开发。开发顺序由设计依赖关系决定，不由阶段划分决定。

8. 调研发现与待回答问题

以下问题基于 2026-05-13 调研（知识库 14 个项目 + 业界 5 个方向），部分已有答案。

8.1 编排智能化 — 已有部分答案

业界共识: “可预测骨架 + LLM 动态填充”，不纯 DAG 也不纯 ReAct。

LangGraph：图定义结构，条件边动态路由
OpenAI Agent SDK：Handoff 显式转交 + 对话历史传递
Google ADK：层级树 + LLM 做委派决策
open-multi-agent：Goal-first，Coordinator 动态分解为 DAG
Ouroboros：后台意识循环（比"持续指挥官"更激进——不是任务来了才调度，而是一直在思考）

待深入: 确定性保障机制（防死循环/乱调度）的具体实现方式

8.2 共享意识 — 已有部分答案

通信模式递进（按 AI native 程度）:

点对点异步消息（Sanguo Mail）——最基础
共享工作区 + 结构化产出（Claude Code）——简单有效
对话历史传递（OpenAI Handoff）——"surprisingly effective"
Blackboard 广播（学术前沿：LbMAS/bMAS）——最强但最复杂
Canonical IR 中间表示（Opal-Bridge）——N 个 Agent 只需 2N 个 adapter

冲突解决（wiki 已蒸馏）: 写冲突用锁、逻辑冲突用仲裁、资源冲突用队列 并行安全: Network-AI 的 propose→validate→commit 原子写入

待深入: 信息过载的具体解决方案（分层黑板 + LLM 控制单元路由）

8.3 Agent 自主协作 — 已有框架

4 种编排模式（wiki 已蒸馏）: 线性/并行/主从/网状，有明确选择指南 Agent 自主协作参考: Ouroboros 的后台意识、wanman 的 Steer/FollowUp 优先级 多模型交叉验证: Ouroboros 用 o3/Gemini/Claude 评审自己的变更

待深入: peer-to-peer 协作中“两个 Agent 同时改同一文件”的防竞态方案

8.4 经验沉淀 — 已有成熟框架

Memory → Skills → Rules 三层压缩（Experience Compression Spectrum） 闭环学习: DISCOVER → DISTILL → APPLY → IMPROVE（wiki 知识管理体系） 五层蒸馏: 表达DNA → 心智模型 → 决策启发式 → 反模式 → 诚实边界（nuwa-skill） 五路径增长: 调研驱动 / 问题驱动 / 外部注入 / 反向触发 / 交叉碰撞 反向触发特别重要: Agent 发现好实践时主动建议"可以改善我们的 X"——AI native 的经验沉淀

待深入: 经验自动从执行 trace 中提取的具体方法、过时经验处理

8.5 人的介入方式 — 已有成熟做法

分阶段介入: 设计时深度 → 执行时旁观 → 完成时审查 权限光谱: Claude Code 7 种权限模式（全自动到每步审批） 安全机制: Scope Reduction Detection（防偷懒）、Change Capsule（变更审查）、Steer 优先级（紧急中断）

待深入: “AI 主动求助”的触发条件设计、人介入后无缝交还控制权

8.6 端到端参考 — 部分覆盖

最接近全链路的: get-shit-done（idea→research→requirements→roadmap→discuss→plan→execute→verify→ship） 最大规模多 Agent: Hermes v0.13 Kanban（运维保障好但编排传统） 最激进 AI native: Ouroboros（自修改 + 后台意识 + 宪法驱动） 跨 Agent 互操作: Opal-Bridge（Canonical IR + Moments + Fidelity 三档）

待深入: 从“需求探索”到“交付验收”全链路 AI native 的完整系统尚未出现

9. 与现有系统的关系

系统	v1.0 关系	v2.0 关系
OpenClaw	底层基础设施	主入口(对话通过 session)+ 基础设施
Sanguo Mail	Agent 间异步通信	降级为 fallback,主通信走共享空间
Mozi	经验来源	不变,经验教训是输入
moziplus Dashboard	主入口	降级为监控面板
知识库	存基础数据	经验沉淀的核心载体

10. 风险

风险	说明	缓解思路
AI 指挥不稳定	AI 调度可能做出错误决策	底层确定性引擎兜底 + 人可随时介入
共享空间信息过载	Agent 写入太多信息	结构化 + 摘要 + 按需读取

10.1 安全红线（C9 详细定义）

以下操作必须 AI 拦截并拉人确认，不允许自主执行：

红线	说明	拦截方式
实盘交易	任何涉及真实资金的操作	强制人工确认
数据删除	删除历史数据、回测结果	强制人工确认
系统配置变更	修改 daemon/API/Agent 配置	强制人工确认
大额 token 消耗	单步 > 100K token	自动暂停 + 通知
Agent 不受控行为	Agent 执行超出步骤范围	自动终止 + 升级
连续失败	同一任务连续 3 个步骤失败	暂停 + 人工介入

10.2 v2.0 范围声明

v2.0 实现范围：

✅ 四相循环（需求探索→动态规划→自主执行→主动汇报）
✅ 中央调度模式（Daemon 是唯一中枢）
✅ 配置化零硬编码
✅ 质量门控 + 异常处理 + 经验沉淀
✅ 人工介入（steer/takeover/intervene）

v2.1+ 后续版本：

🔜 Agent 主动感知（不依赖庞统调度）
🔜 peer-to-peer 协作
🔜 工具链自动集成（lint/test/build）
🔜 Fidelity 信息路由（按角色分级）
🔜 Boids 协作规则注入
🔜 Dashboard 监控面板

10.3 多任务并发

用户可能同时发起多个任务。v2.0 处理方式：

Agent 是有界资源（每个 Agent 同时只执行一个步骤）
Daemon 维护 Agent 可用性表，调度时检查
任务间资源冲突时按优先级排队（critical > standard > exploratory）
每个任务独立 artifacts 目录，无文件冲突

10.4 任务失败恢复

Phase 3 执行中途失败的处理策略：

单步失败：重试（max_retries=3），换 Agent，或升级
计划失败：AI 判断是否需要 replan，或从中断点继续
用户改主意：steer/replan 重新规划，不从头开始
不可恢复：标记 failed，保留所有产出物和执行历史，支持用户事后分析

附录: v1.0 → v2.0 变化摘要

维度	v1.0	v2.0
核心假设	用户知道自己要什么	用户只有模糊方向,AI 帮他梳理
编排方式	确定性状态机 + 固定 DAG	AI 指挥循环 + 活计划
Agent 通信	Sanguo Mail 异步邮件	Daemon HTTP API + openclaw agent CLI
主入口	Web Dashboard	自然语言对话
人的参与	全程驾驶	提方向 → 关键决策 → 验收
前端定位	操作面板	v2.0 不做前端，对话为主
经验沉淀	无	每次执行自动提炼
AI 的位置	只在执行节点	参与每一层决策

24 KiB Raw Blame History Unescape Escape

三国 AI Native 平台 - PRD v2.0

0. 一句话定义

1. 为什么要推倒重来

1.1 v1.0 的根本问题

1.2 核心洞察

1.3 v1.0 的资产

2. 核心理念

2.1 四条信念

2.2 与 v1.0 铁律的关系

3. 系统画面

3.1 用户视角的理想体验

3.2 系统内部发生了什么

4. 架构理念

4.1 从四层变四相

Phase 1: 需求探索(苏格拉底对话)

Phase 2: 动态规划(AI 规划 + 挑战)

Phase 3: 自主执行(Agent 协作群)

Phase 4: 主动汇报(AI 推送)

4.2 编排层的范式转变

4.3 界面的范式转变

5. 核心能力清单

5.1 能力 vs 现状

5.2 能力依赖关系

6. 技术方向

6.1 编排层:全新实现

6.2 通信层:中央调度 + 共享状态

6.3 入口层:双入口——对话 + Dashboard

6.4 经验层:从无到有

7. 开发策略

设计推进方式

开发启动条件

8. 调研发现与待回答问题

8.1 编排智能化 — 已有部分答案

8.2 共享意识 — 已有部分答案

8.3 Agent 自主协作 — 已有框架

8.4 经验沉淀 — 已有成熟框架

8.5 人的介入方式 — 已有成熟做法

8.6 端到端参考 — 部分覆盖

9. 与现有系统的关系

10. 风险

10.1 安全红线（C9 详细定义）

10.2 v2.0 范围声明

10.3 多任务并发

10.4 任务失败恢复

附录: v1.0 → v2.0 变化摘要

24 KiB

Raw Blame History