什么是CLI Design Framework
CLI Design Framework 是一个专为命令行界面（Command-Line Interface, CLI）设计与评审而构建的分类优先框架。它并非通用的风格指南，而是一套决策系统，旨在帮助开发者在面对命令结构、用户类型、交互形式、状态性和风险概况等方面的不确定性时，做出清晰的设计选择。该框架的核心原则是‘分类先行，设计其次，评审第三’，要求首先明确 CLI 的单一目的，然后依次确定其主控制面、主用户类型、主交互形式、状态性、风险轮廓以及次要表面，从而推导出具体的设计约束与后果。框架适用于设计新 CLI 时命令形态不明确、评审现有 CLI 时发现帮助信息或命令树不匹配、或决定 CLI 应属于能力型、运行时型、环境/工作区型、工作流型还是元工具型等场景。它强调区分主次表面，避免将 TUI、REPL 或 JSON 输出笼统视为重要功能，而应明确其角色；同时要求对机器可读表面的契约进行明确定义，而非仅泛泛而谈‘脚本友好’。 框架提供两种操作模式：设计模式和评审模式。在设计模式中，系统会推断已知信息，提出高杠杆率的未决问题，明确分类，陈述设计立场，并产出蓝图以约束后续实现。在评审模式中，则通过检查帮助输出、文档、代码和测试，反向推断设计意图，并从分类契合度和执行质量两个层面进行结构化评估。对于混合型 CLI（如 Docker），框架建议从产品级中心重力出发进行分类，并允许子命令承担不同的角色，但需明确主次角色及其约束。整个框架特别警惕常见失败模式，例如将所有 CLI 都视为能力型或运行时型、忽略状态性或风险轮廓、忽视人类用户的可发现性、或将自动化适配度误认为顶层身份。最终输出要求明确、证据充分、诊断性强，避免空泛建议。
核心功能特点
- 采用分类优先的决策系统，而非通用风格指南，确保设计方向清晰
- 支持两种核心操作模式：设计模式用于创建或优化 CLI 设计，评审模式用于评估现有 CLI 的结构合理性
- 强制区分主次表面，明确主控制面与次要交互形式（如 TUI、JSON 输出），避免功能混淆
- 要求显式定义机器可读表面的契约，包括输出格式、字段稳定性、退出码等，而非泛泛而谈‘脚本友好’
- 建立风险阶梯模型，对低、中、高风险操作分别设定预期防护措施，杜绝模糊的‘小心’提示
- 提供 v1 边界界定机制，明确版本初期应包含与排除的功能，防止过早抽象
适用场景
CLI Design Framework 最适用于那些在 CLI 设计初期就面临方向不确定性的场景。当团队需要设计一个新的命令行工具，但不确定其命令结构应以能力为中心、运行时为重心，还是更偏向工作流或环境管理时，此框架能引导他们通过分类过程锁定核心目标。例如，一个用于资源编排的工具可能需要在‘Workflow’与‘Runtime’之间做出抉择，框架能帮助判断其中心重力所在。另一个典型应用场景是对现有 CLI 进行重构评审，尤其是当其帮助文档、命令树或输出格式让用户感到困惑或不一致时，框架可通过逆向工程分析其设计意图，并指出是否存在分类错配或执行质量问题。此外，当团队需要决定是否引入会话语义、状态管理或复杂风险防护机制时，框架的风险阶梯与状态模型提供了结构化评估依据。对于混合型 CLI（如 Kubernetes 或 Docker），框架允许子命令承担不同角色，但仍需明确产品级的中心重力，避免强行统一所有命令的行为模式。总之，任何涉及 CLI 战略定位、多表面协调或长期演进规划的项目，都能从此框架中获得清晰的决策路径与实施约束。