用途
CLI Design Framework 是一个以分类优先（classification-first）为核心的 CLI 设计与评审框架。它被定位为一个决策系统，而不是通用的风格指南。其核心规则是：先分类，再设计，最后评审。
该框架适用于以下场景：
- 设计新 CLI，且合适的命令形态尚不明确；
- 评审现有 CLI，其帮助信息、输出或命令树感觉不匹配；
- 判断一个 CLI 主要属于 Capability、Runtime、Environment / Workspace、Workflow、Package / Build 还是 Meta；
- 判断人类可读与机器可读界面是主要界面还是次要界面；
- 判断会话语义（session semantics）是否合理，还是过度设计。
不适用于以下场景：
- CLI 分类已经确定，只需要实现机制；
- 问题仅涉及解析器库、仓库布局或具体标志拼写；
- 任务纯粹是表面文案编辑，没有设计后果。
主要能力
框架提供两种工作模式：
设计模式（Design mode）：创建或完善 CLI 设计方向。目标是明确 CLI 的设计目标，然后产出约束实现的蓝图。工作流包括：从用户请求中提取所有强信号，推断已知信息；只提出最高杠杆的未解决问题；显式分类 CLI；在提出命令之前先陈述设计立场；产出设计蓝图；最后给出方向部分，说明应优化什么、不应优化什么、可接受的模式、类别错误以及 v1 边界与非目标。
评审模式（Review mode）：评估现有 CLI 是否符合框架。目标是检查 CLI 及其源码，反推其设计意图，然后从两个层面进行评审：分类契合度（是否被设计为正确类型的 CLI）和执行质量（在该类型下执行得如何）。工作流包括：先检查再提问；反推设计意图；分两层评审；产出结构化评审。
框架还包含以下参考文件：
- references/taxonomy.md：分类法；
- references/output-templates.md：所需输出形态；
- references/classification-examples.md：分类模糊时的分类锚点；
- examples/design-blueprint-example.md 和 examples/review-example.md：最终形态的具体示例；
- examples/anti-patterns.md：当设计感觉不对但类别错误尚不清晰时使用。
使用方式
核心工作顺序为：
- 用一句话陈述 CLI 目的；
- 分类主要角色/控制面；
- 分类主要用户类型；
- 分类主要交互形式；
- 分类状态性；
- 分类风险画像；
- 显式识别次要界面；
- 推导设计后果。
使用框架时，先从 references/taxonomy.md 和 references/output-templates.md 开始；仅在需要时拉取分类示例、设计蓝图示例、评审示例和反模式。
对于快速请求，可产出压缩版本：目的、分类、简短推理、主要设计后果，以及仅列出可能改变答案的未解决问题。只有在用户明确要求，或模糊性/风险足以支持更长形式时，才使用完整蓝图或完整评审模板。
适用场景
框架适用于设计新 CLI、评审现有 CLI、判断 CLI 分类、判断人机界面主次、判断会话语义是否合理等场景。它强调将现代 CLI 视为多界面系统：一个主要角色、一个主要交互形式、可选的次要界面。
对于混合型 CLI，框架要求先在产品层面分类，确定 CLI 的重心；如果子命令明显分裂为不同角色，则显式说明这种分裂；命名主要角色（定义 CLI 身份和设计约束的角色）；将次要角色命名为次要界面，并带有各自的局部约束。不要对子命令确实服务于不同角色的 CLI 强行施加单一角色。
框架以 Docker 为例：产品级主要角色是 Runtime（重心是容器执行）；docker run、docker exec、docker attach 属于 Runtime 交互；docker image ls、docker volume inspect 属于类 Capability 的资源界面（次要）；docker compose up 属于 Workflow/Orchestration（次要）。
对于演进中的 CLI：如果 CLI 正在从一种类型迁移到另一种类型，应说明当前重心和预期方向；不要仅根据未来目标分类，而应根据当前证据分类并注明轨迹。
限制
框架明确列出常见失败模式，包括：把每个 CLI 都当作 capability CLI；把每个 CLI 都当作 runtime CLI；把 TUI 或 REPL 当作角色而非交互形式；忽略状态性；忽略风险画像；忽略人类优先 CLI 的帮助/可发现性；把自动化适配度当作顶层身份而非设计后果；把人类优先工具强行塞入 agent-only 模式；在没有定义契约的情况下称 JSON 界面“强大”；忽略混合模式 CLI 的次要界面；从分类直接跳到命令树而不陈述设计立场；未能标记 v1 边界和非目标；对子命令确实服务于不同控制面的混合 CLI 强行施加单一角色；对只有持久配置/锁文件副作用但没有真正会话的 CLI 过度设计状态性；根据未来愿景而非当前证据分类 CLI。
框架要求最终输出明确分类、明确分类推理（存在张力或模糊时）、明确证据/置信度/假设、明确设计后果、明确主要与次要界面、在相关时明确可发现性和机器契约、存在变更时明确风险阶梯，并按用户要求的深度缩放，简洁但密集，具有诊断性而非泛泛而谈。避免诸如“改进 UX”或“使其更 agent-friendly”之类的模糊建议，除非将其与具体分类和具体设计后果联系起来。