@minniexcode/codex-switch 0.0.3 → 0.0.5

package/docs/PRD/codex-switch-prd-v0.0.5-to-v0.1.0.md

@@ -0,0 +1,308 @@
+# codex-switch `0.0.5 -> 0.1.0` 演进 PRD
+
+## 文档信息
+
+- 状态：Target PRD
+- 产品名：`codex-switch`
+- CLI 命令名：`codexs`
+- 当前阶段基线：`0.0.5`
+- 目标版本：`0.1.0`
+- 文档定位：定义 `0.0.5` 之后持续演进到 `0.1.0` 的目标规格与路线
+- 当前活跃 PRD：[`codex-switch-prd-v0.1.0.md`](./codex-switch-prd-v0.1.0.md)
+- 历史基线 PRD：[`codex-switch-prd.md`](./codex-switch-prd.md)
+- 对应研究稿：[`../codex-switch-product-research.md`](../codex-switch-product-research.md)
+- 对应技术架构：[`../codex-switch-technical-architecture.md`](../codex-switch-technical-architecture.md)
+- 对应命令设计：[`../codex-switch-command-design.md`](../codex-switch-command-design.md)
+
+## 一句话定义
+
+`codex-switch` 的 `0.1.0` 目标，是从一个已经具备 provider 管理和基础 config consistency 能力的本地 CLI，演进为一套对人类和 AI 都稳定、可初始化、可诊断、可恢复、可结构化管理配置、可持续扩展的发布级命令体系。
+
+## 版本语义
+
+- `0.0.x`：测试 / 验证阶段版本，用于收敛模型、命令面和失败语义
+- `0.1.0`：第一条稳定发布规格线，不要求立即全部完成，但要求边界清晰
+- 本文档描述的是 `0.0.5` 之后继续走向 `0.1.0` 的长期目标
+
+## `0.1.0` 总体目标
+
+`0.1.0` 需要同时满足以下目标：
+
+- 保持 CLI 与 JSON 契约稳定
+- 保持 `setup`、provider registry、备份恢复主线能力不回退
+- 将 `config.toml` 从“可结构化读取与最小受管写入”推进到“稳定受管 provider-linked sections”
+- 让 provider registry 与 linked config sections 的一致性成为默认能力
+- 让备份与回滚继续覆盖所有关键写操作
+- 为未来 auth / extension 集成保留明确边界
+
+## 长期演进守则
+
+后续新增命令统一遵守：
+
+- 不破坏当前 JSON envelope
+- 不复用语义不匹配的错误码
+- 所有写命令默认纳入备份与回滚模型
+
+## 稳定公共契约
+
+### JSON Envelope
+
+`--json` 继续保持统一 envelope：
+
+```json
+{
+  "ok": true,
+  "command": "list",
+  "data": {},
+  "warnings": [],
+  "error": null
+}
+```
+
+约束：
+
+- 顶层 shape 保持不变
+- 后续字段扩展只做加法
+- 详细结果进入 `data`
+- 非致命提示进入 `warnings`
+- 结构化失败信息继续进入 `error`
+
+### 数据模型
+
+#### `providers.json`
+
+`providers.json` 继续是 managed registry 的单一事实源：
+
+```json
+{
+  "providers": {
+    "packycode": {
+      "profile": "packycode",
+      "apiKey": "sk-xxx",
+      "baseUrl": "https://example.com/v1",
+      "note": "primary free model route",
+      "tags": ["free", "daily"]
+    }
+  }
+}
+```
+
+到 `0.1.0` 为止默认不放宽：
+
+- `profile` 仍然必填
+- `apiKey` 仍按完整 managed provider 处理
+- 不引入“半初始化 provider”作为正式稳定状态
+
+#### `config.toml`
+
+到 `0.1.0` 为止，`config.toml` 的定位是“部分受管的 runtime projection”：
+
+- 顶层 active `profile = "..."` 继续受管
+- 与 provider 关联的 `[profiles.<name>]` section 进入受管范围
+- 非 provider 相关的顶层键、section 和注释仍允许存在，但不进入通用编辑器范围
+
+#### `ManagedProfileFields`
+
+`0.1.0` 之前第一批稳定受管 profile 持久化字段先锁定为最小集合：
+
+```json
+{
+  "model": "gpt-5"
+}
+```
+
+约束：
+
+- 第一批正式受管字段只锁 `model`
+- `baseUrl` 等 endpoint 类字段继续只保留在 `providers.json`
+- 后续扩展 profile 字段时，只能做加法
+
+#### `ManagedProfileView`
+
+面向 CLI、AI 和脚本输出的读取视图，与持久化字段分离：
+
+```json
+{
+  "name": "packycode",
+  "model": "gpt-5",
+  "linkedProviders": ["packycode"],
+  "isActive": true,
+  "managed": true
+}
+```
+
+### TOML 处理原则
+
+为了支持结构化 config 管理，`0.1.0` 稳定主线要求：
+
+- 不再以字符串匹配作为唯一 TOML 修改策略
+- 对受管 section 的读取、创建、删除、重命名和字段更新，必须支持可验证的非破坏性结构化读取和修改
+- 修改受管部分时，不应破坏非受管 TOML 内容、顺序、空行和注释
+
+### 错误码演进原则
+
+保留现有领域错误码，并把错误码体系从 MVP 复用模式收紧到语义匹配模式。
+
+现有保留：
+
+- `CONFIG_NOT_FOUND`
+- `PROVIDERS_NOT_FOUND`
+- `PROVIDERS_PARSE_ERROR`
+- `PROVIDER_NOT_FOUND`
+- `PROFILE_NOT_FOUND`
+- `BACKUP_FAILED`
+- `CODEX_LOGIN_FAILED`
+- `ROLLBACK_FAILED`
+- `LOCK_CONFLICT`
+- `LIVE_STATE_DRIFT`
+
+建议新增 / 预留：
+
+- `INVALID_ARGUMENT`
+- `UNKNOWN_COMMAND`
+- `PROMPT_CANCELLED`
+- `CODEX_NOT_INSTALLED`
+- `CODEX_VERSION_UNSUPPORTED`
+- `CODEX_DIR_NOT_FOUND`
+- `CODEX_DIR_AMBIGUOUS`
+- `PROVIDERS_ALREADY_EXISTS`
+- `BACKUP_NOT_FOUND`
+- `CONFIG_PARSE_ERROR`
+- `PROFILE_IN_USE`
+- `MANAGED_PROFILE_FIELDS_MISSING`
+
+## 已落地能力的 `0.1.0` 稳定化要求
+
+### `setup`
+
+`setup` 在 `0.1.0` 主线中的要求是：
+
+- 继续保持从环境检测到 registry 初始化的主流程
+- 继续允许 `overwrite`、`merge` 和交互式补问缺失关键字段
+- 与新的 config 管理能力保持兼容，不写出未来无法被结构化读取的受管状态
+- 对历史遗留不一致状态给出 adopt / repair 建议，而不是静默忽略
+
+### provider registry 命令
+
+`show`、`edit`、`import --merge`、`backups list`、`rollback <backup-id>` 的 `0.1.0` 要求是：
+
+- 保持命令名和基础 JSON 契约稳定
+- 把错误语义继续收紧
+- 让与 `config.toml` 关联的行为更完整
+
+### `import --merge`
+
+`import --merge` 在 `0.1.0` 主线中的要求是：
+
+- 保持“导入侧覆盖本地同名 provider”的默认 merge 语义
+- 不能只更新 `providers.json` 而放任 linked profile sections 漂移
+- 当导入结果引用了缺失 profile 时，必须进入与 `add` / `edit` 一致的受管规则
+- 非交互模式下，如果导入内容不能满足受管 profile 创建条件，应明确失败
+- 交互模式下可以进入 adopt / repair 辅助流，但最终写入结果仍必须满足一致性约束
+
+## `0.1.0` 远期能力域
+
+下面这些方向明确有价值，但不进入 `0.0.5` 当前里程碑，只作为继续走向 `0.1.0` 的能力域。
+
+### 第三方 auth / extension 集成
+
+示例方向：
+
+- 接入 Copilot auth
+- 在本地启动代理服务，使特定上游可在 Codex 中使用
+- 安装和管理第三方依赖
+
+当前定位：
+
+- 作为单独能力域保留
+- 不在当前主 PRD 中锁定具体命令名和交互细节
+- 不进入 `0.1.0` 稳定主线的验收标准
+
+### 更大范围的 profile schema 管理
+
+未来如果需要扩展：
+
+- 可以逐步纳入 `model` 之外的 profile 字段
+- 必须保持增量式 schema 扩展
+- 不能在未定义字段契约前把 `config.toml` 直接提升为 full config manager
+
+## 主题里程碑
+
+从 `0.0.5` 走向 `0.1.0`，建议按能力主题推进：
+
+### 里程碑 A：`0.0.5` / Config Management & Consistency
+
+目标：
+
+- 巩固结构化 TOML 读写
+- 稳定 `config show`、`config list-profiles`
+- 让 provider 管理命令可靠同步 linked profile sections
+- 明确共享 profile、孤儿 section 和 active profile 安全规则
+
+### 里程碑 B：Backup / Recovery Evolution
+
+目标：
+
+- 保持 `backups list` 与指定回滚能力稳定
+- 确保跨 `providers.json` 与 `config.toml` 的双写场景仍可完整恢复
+- 为更复杂的 config 变更继续复用同一事务模型
+
+### 里程碑 C：Error Contract Hardening
+
+目标：
+
+- 收紧错误码语义
+- 区分环境错误、参数错误、配置解析错误和恢复错误
+- 保持 TTY / 非交互模式下的错误结果可预测
+
+### 里程碑 D：Extensions / Auth Integration
+
+目标：
+
+- 评估第三方 auth 与本地代理集成
+- 评估交互式依赖安装与 extension 管理
+- 在不破坏主 CLI 契约的前提下扩展能力边界
+
+## 对实现的要求
+
+从 `0.0.5` 到 `0.1.0` 的所有新增能力，默认遵守：
+
+- 命令帮助必须明确人类模式和 `--json` 模式行为
+- 非交互环境不允许依赖 prompt 才能完成核心自动化流程
+- 所有写命令默认走锁、备份、回滚
+- 所有新增错误码都必须语义清晰
+- 所有新增 JSON 返回都只能扩展 `data` 和 `warnings`
+- 结构化 TOML 写回不能破坏非受管部分
+- 多候选目录发现必须在交互和非交互模式下给出一致且可预测的行为
+
+## `0.1.0` 目标完成标准
+
+达到下面这些条件时，可以认为 `0.1.0` 主线目标基本收敛：
+
+- 用户可以通过 `setup` 完成首次初始化
+- `setup` 在多候选 Codex 目录场景下可交互选择或手动输入，在非交互场景下返回明确歧义错误
+- provider registry 的查看、编辑、导入合并能力完整
+- 用户和 AI 可以通过稳定命令结构化查看受管 `config.toml`
+- `add` / `edit` / `remove` 执行后，`providers.json` 与 linked profile sections 不再出现预期内的一致性漂移
+- 共享 profile 场景不会误删仍被引用的 section
+- active profile 不会因为 provider 删除或 profile 迁移而变成悬空状态
+- 历史 `0.0.4` / `0.0.5` 状态可以被识别，并通过 adopt / repair 路径逐步收敛
+- 历史备份可被显式枚举和恢复
+- CLI 错误码不再存在明显语义复用问题
+- 主 CLI 契约对 AI 和脚本调用保持稳定
+
+## 建议测试场景
+
+至少需要覆盖：
+
+- `config show` 与 `config list-profiles` 的稳定输出
+- 共享 profile 场景下的 `add` / `edit` / `remove` 行为
+- `setup` 在多目录候选下的交互和非交互分支
+- `import --merge` 在缺失 profile / adopt / repair 下的一致性行为
+- 结构化 TOML 修改后，非受管内容、顺序和注释保持稳定
+- 双写失败时 `providers.json` 与 `config.toml` 能整体回滚
+- 历史 workspace、共享 profile、孤儿 profile section、缺失 linked section 都能被 `doctor` / `status` 正确识别
+
+## 结论
+
+`0.1.0` 不是简单把 `0.0.x` 重命名为稳定版，而是在保持当前本地事务式切换模型不变的前提下，进一步收敛 config 管理、错误契约和恢复能力，并为未来更大范围的 auth / extension 集成留出清晰边界。

package/docs/PRD/codex-switch-prd-v0.1.0.md

@@ -0,0 +1,343 @@
+# codex-switch `0.0.5` PRD
+
+## 文档信息
+
+- 状态：Active PRD
+- 产品名：`codex-switch`
+- CLI 命令名：`codexs`
+- 当前基线版本：`0.0.4`
+- 目标版本：`0.0.5`
+- 文档定位：定义 `0.0.4 -> 0.0.5` 的直接需求范围
+- 历史基线 PRD：[`codex-switch-prd.md`](./codex-switch-prd.md)
+- 后续演进 PRD：[`codex-switch-prd-v0.0.5-to-v0.1.0.md`](./codex-switch-prd-v0.0.5-to-v0.1.0.md)
+- 对应研究稿：[`../codex-switch-product-research.md`](../codex-switch-product-research.md)
+- 对应技术架构：[`../codex-switch-technical-architecture.md`](../codex-switch-technical-architecture.md)
+- 对应命令设计：[`../codex-switch-command-design.md`](../codex-switch-command-design.md)
+
+## 一句话定义
+
+`0.0.5` 的目标不是继续堆命令，而是把 `config.toml` 从“只能浅层切换 active profile”升级为“可以结构化读取、受控维护 provider-linked profiles，并与 `providers.json` 保持一致”。
+
+## 当前基线：`0.0.4`
+
+当前已落地能力：
+
+- `list` / `current` / `status`
+- `switch <provider>`
+- `import <file>` / `import <file> --merge` / `export <file>`
+- `add <provider>` / `edit <provider>` / `show <provider>` / `remove <provider>`
+- `setup`
+- `doctor`
+- `backups list`
+- `rollback` / `rollback <backup-id>`
+
+当前基线已具备的工程特征：
+
+- 本地文件模型围绕 `~/.codex/`
+- `providers.json` 作为 management SSOT
+- `config.toml` 与 `auth.json` 作为 runtime state
+- 写命令统一走备份、锁和失败回滚
+- `--json` 输出固定 envelope
+
+当前主要缺口：
+
+- `config.toml` 仍以轻量字符串匹配方式处理
+- provider 管理命令不能稳定同步 linked profile sections
+- 缺少结构化展示 config 的稳定命令面
+- 历史 profile、共享 profile、缺失 section 的一致性规则还不完整
+
+## `0.0.5` 目标
+
+`0.0.5` 需要完成四件事：
+
+- 引入结构化 TOML 读取与非破坏性修改能力
+- 增加稳定的 config 查看命令，供人类、AI 和脚本消费
+- 让 provider 写命令同步维护 linked profile sections
+- 补齐历史状态、一致性信号和安全删除规则
+
+## 范围
+
+### In Scope
+
+- 顶层 active `profile`
+- `[profiles.<name>]` 受管 section
+- 第一批正式受管字段：`model`
+- `config show`
+- `config list-profiles`
+- `add` / `edit` / `remove` / `setup` / `import --merge` 的 provider-config 一致性
+- `doctor` / `status` 的一致性信号
+
+### Out of Scope
+
+- 整个 `config.toml` 的通用编辑器
+- 任意顶层键的自由增删改
+- 更大 profile schema 的首版正式规格
+- 第三方 auth / extension 集成
+
+## 数据与契约
+
+### JSON Envelope
+
+`--json` 继续保持统一 envelope：
+
+```json
+{
+  "ok": true,
+  "command": "list",
+  "data": {},
+  "warnings": [],
+  "error": null
+}
+```
+
+要求：
+
+- 顶层 shape 不变
+- 新字段只追加到 `data` / `warnings`
+- 错误信息继续进入 `error`
+
+### `providers.json`
+
+`providers.json` 继续是 provider registry 的单一事实源：
+
+- `profile` 必填
+- `apiKey` 仍按完整 managed provider 处理
+- 不引入“半初始化 provider”作为稳定状态
+
+### `config.toml`
+
+到 `0.0.5` 为止，`config.toml` 的受管范围限定为：
+
+- 顶层 active `profile`
+- 与 provider 关联的 `[profiles.<name>]`
+- section 内最小正式字段：`model`
+
+约束：
+
+- `providers.json` 仍是 provider 身份、凭据和管理元数据的 SSOT
+- `config.toml` 只承载运行态投影，不升级为对等事实源
+- 非受管 TOML 内容允许存在，但不进入通用编辑范围
+
+### Managed Profile View
+
+读取命令应围绕稳定视图返回，而不是直接暴露内部持久化细节。最小视图建议包含：
+
+```json
+{
+  "name": "packycode",
+  "model": "gpt-5",
+  "linkedProviders": ["packycode"],
+  "isActive": true,
+  "managed": true
+}
+```
+
+## Config Management 规则
+
+### 受管与非受管
+
+- managed profile：被至少一个 provider 引用，允许被写命令同步维护
+- unmanaged profile：存在于 `config.toml`，但当前没有任何 provider 引用，默认只读展示
+- orphaned managed reference：`providers.json` 引用了 profile，但 `config.toml` 缺失对应 section，属于不一致状态
+
+### 共享 profile
+
+多个 provider 指向同一个 profile 在 `0.0.5` 继续合法：
+
+- profile section 不归单个 provider 独占
+- 只有当没有任何 provider 引用时，才允许删除对应 section
+- `remove` / `edit` 不能因单个 provider 操作误删共享 profile
+
+### TOML 处理原则
+
+- 不再以字符串匹配作为唯一修改策略
+- 对受管 section 的读取、创建、删除、字段更新必须可验证
+- 修改受管部分时，不应破坏非受管内容、顺序、空行和注释
+
+## 新增命令
+
+### `codexs config show`
+
+用途：
+
+- 展示结构化 config 视图
+- 同时服务人类和 AI / 自动化读取
+
+输入：
+
+```bash
+codexs config show [profile] [--json] [--codex-dir <path>]
+```
+
+最小返回要求：
+
+- `activeProfile`
+- `profiles`
+- `includedProfiles`
+
+`profiles[]` 中每项至少包含：
+
+- `name`
+- `managed`
+- `isActive`
+- `linkedProviders`
+- `managedFields`
+- `source`
+
+### `codexs config list-profiles`
+
+用途：
+
+- 列出当前 `config.toml` 中的 profile 视图
+- 明确显示 profile 与 provider 的关联关系
+
+输入：
+
+```bash
+codexs config list-profiles [--json] [--codex-dir <path>]
+```
+
+`data.profiles[]` 至少包含：
+
+- `name`
+- `managed`
+- `isActive`
+- `linkedProviders`
+- `model`
+
+## 现有写命令升级
+
+### `codexs add <provider>`
+
+新增或锁定：
+
+- `--model <name>`
+- `--create-profile`
+
+规则：
+
+- 当目标 profile 已存在时，允许直接建立映射
+- 当目标 profile 不存在时，只有显式传入 `--create-profile --model <name>` 才允许创建 section
+- 缺少最小受管字段时，返回 `MANAGED_PROFILE_FIELDS_MISSING`
+
+### `codexs edit <provider>`
+
+新增或锁定：
+
+- `--profile <name>`
+- `--model <name>`
+- `--create-profile`
+
+规则：
+
+- `edit --profile <missing>` 且未传 `--create-profile` 时失败
+- `edit --profile <missing> --create-profile` 但未传 `--model` 时失败
+- 旧 profile 若仍被其他 provider 引用，则保留
+- 旧 profile 若已无引用且不是 active profile，则可以删除
+- 不隐式 rename 或 copy 旧 section 到新 profile
+
+### `codexs remove <provider>`
+
+新增或锁定：
+
+- `--switch-to <profile>`
+
+规则：
+
+- 删除 provider 记录后，若 profile 仍被其他 provider 引用，则保留 section
+- 若 profile 已无任何引用，则允许删除 section
+- 若该 profile 仍是当前 active 且最后一个引用，必须先 `switch` 或显式传 `--switch-to`
+- 不允许把 active profile 留成悬空状态
+
+### `codexs switch <provider>`
+
+- 继续只负责切换顶层 active profile
+- 不负责修复 profile section 内容
+- 执行前提仍是目标 profile section 必须存在且可识别
+
+## `setup` 升级
+
+`setup` 在 `0.0.5` 需要与新一致性模型兼容：
+
+- 支持扫描多个候选 Codex 目录
+- 多候选下，TTY 允许选择或手动输入目录
+- 非交互模式下，多候选且未显式传 `--codex-dir` 时返回 `CODEX_DIR_AMBIGUOUS`
+- 未发现任何候选目录时，TTY 可手动输入；非交互返回 `CODEX_DIR_NOT_FOUND`
+- 对从现有 `config.toml` 发现的 profile，允许 adopt 为受管 profile
+- 不制造新的 registry-config 不一致
+
+## Write Result Contract
+
+下列写命令成功时，建议在 JSON `data` 中稳定返回结果字段：
+
+- `add`
+- `edit`
+- `remove`
+- `setup`
+- `import --merge`
+
+建议字段：
+
+- `provider`
+- `profile`
+- `createdProfileSections`
+- `deletedProfileSections`
+- `keptSharedProfiles`
+- `switchedActiveProfile`
+- `adoptedProfiles`
+- `repairedProfiles`
+
+## 事务与回滚
+
+所有可能同时修改 `providers.json` 和 `config.toml` 的命令，默认遵守：
+
+- 单次锁
+- 单次备份
+- 单次失败整体回滚
+
+不能接受的结果：
+
+- `providers.json` 已更新但 `config.toml` 未同步
+- `config.toml` 已更新但 `providers.json` 未同步
+- active profile 指向已不存在的 section
+
+## 迁移与诊断
+
+需要识别的历史状态：
+
+- `providers.json` 可用，但 `config.toml` 中只有手工维护 profile
+- `providers.json` 引用了 profile，但对应 section 不存在
+- `config.toml` 存在历史 profile，但没有任何 provider 引用
+- 当前 active profile 指向 unmanaged profile
+
+迁移原则：
+
+- 不要求用户先手工清空历史状态
+- `setup`、`import --merge`、`doctor`、`status` 必须能识别这些状态
+- 可安全 adopt 的 unmanaged profile，允许纳入受管
+- 对悬空引用或缺失 section，默认不静默修复，必须告知用户下一步建议
+
+`doctor` / `status` 至少需要覆盖：
+
+- orphaned profile reference
+- unmanaged active profile
+- shared profile reference count
+- orphaned profile section
+- destructive remove blocked
+
+## 验收标准
+
+达到以下条件时，`0.0.5` 可以认为完成：
+
+- `config show` 在文本和 `--json` 模式下返回稳定结构
+- `config list-profiles` 能稳定展示 `managed`、`isActive`、`linkedProviders` 和 `model`
+- `add` / `edit` / `remove` 会同步维护 linked profile sections
+- 共享 profile 场景不会误删仍被引用的 section
+- active profile 不会因删除 provider 或迁移 profile 而悬空
+- 历史 `0.0.4` 状态可被识别，并通过 adopt / repair 路径收敛
+- 结构化 TOML 修改后，非受管内容、顺序和注释保持稳定
+- 双写失败时 `providers.json` 与 `config.toml` 能整体回滚
+
+## 结论
+
+`0.0.5` 是 `codex-switch` 从 provider registry 工具走向 config-aware CLI 的第一步。它的重点不是扩张命令面，而是建立稳定的 config 管理、一致性事务和可诊断能力，为后续 `0.0.5 -> 0.1.0` 演进打基础。

package/docs/{codex-switch-prd.md → PRD/codex-switch-prd.md}

@@ -1,15 +1,19 @@
 # codex-switch PRD
 
+> 状态说明：
+> 这份文档保留为 `0.0.x` / MVP 阶段的历史 PRD 基线。
+> 从 `0.0.3` 继续走向 `0.1.0` 的目标规格，请参考 [`codex-switch-prd-v0.1.0.md`](./codex-switch-prd-v0.1.0.md)。
+
 ## 文档信息
 
-- 状态：Draft
+- 状态：Historical Baseline
 - 产品名：`codex-switch`
 - CLI 命令名：`codexs`
 - 版本范围：MVP / CLI First
-- 文档定位：正式 PRD
-- 对应研究稿：[`codex-switch-product-research.md`](./codex-switch-product-research.md)
-- 对应技术架构：[`codex-switch-technical-architecture.md`](./codex-switch-technical-architecture.md)
-- 对应命令设计：[`codex-switch-command-design.md`](./codex-switch-command-design.md)
+- 文档定位：`0.0.x` / MVP 阶段历史 PRD
+- 对应研究稿：[`../codex-switch-product-research.md`](../codex-switch-product-research.md)
+- 对应技术架构：[`../codex-switch-technical-architecture.md`](../codex-switch-technical-architecture.md)
+- 对应命令设计：[`../codex-switch-command-design.md`](../codex-switch-command-design.md)
 
 ## 一句话定义