1. OpenShell 是什么：从一个“壳”字说起

第一次看到 OpenShell 这个名字，很多人会下意识把它和 Linux 的 shell、终端、命令行工具联系在一起。这个直觉不算错，但也不完全对。OpenShell 的核心定位，是给一个相对开放、可扩展的运行环境套上一层“可控的外壳”——它既可以是命令行交互层，也可以是一个策略执行层、一个插件容器，甚至是一套权限与行为的统一入口。名字里的 Open 代表开放、可插拔、可二次开发，Shell 代表它对外呈现的是一个统一、收敛、可被调用的接口。

我在实际接触这个方向的项目时，最深的感受是：它解决的不是“从零造一个系统”的问题，而是“把一堆零散能力收拢到一个稳定入口”的问题。比如你手里有一批脚本、一批工具、一批内部服务，每个都有自己的调用方式、参数格式、错误码，维护起来像在同时照顾十几个脾气不同的孩子。OpenShell 要做的，就是给这些能力做一个统一的壳，让调用方只面对一套规则，内部怎么变、怎么换、怎么扩展，都由壳来兜底。

这篇文章适合三类人看。第一类是正在做平台化、工具链整合的工程师，你们可能正被“接口不统一、扩展困难、权限失控”折磨；第二类是对命令行工具、插件架构、策略引擎感兴趣的技术爱好者，想理解一个可扩展外壳的设计思路；第三类是做运维、自动化、内部工具建设的朋友，你们需要一套能落地、能复现、能长期维护的方案。我会尽量把设计思路、关键细节、实操步骤和踩坑经验都摊开讲，让你看完能直接照着搭一个最小可用版本。

需要先说明一点：OpenShell 并不是某一个固定产品的专有名词，它更像是一类架构模式的代称。不同团队、不同场景下，它的具体形态可能差别很大。所以下面我讲的内容，是基于这类项目最常见的实践路径来展开的，涉及具体参数和代码的地方，你可以根据自己的技术栈替换。

2. 整体设计与思路拆解：为什么要给能力套一层壳

2.1 核心矛盾：能力越多，入口越乱

任何一个稍微有点规模的项目，都会经历一个“能力膨胀”的阶段。最开始可能只有三五个脚本，调用方式很随意，谁写的谁清楚。等到脚本变成几十个、上百个，参与的人从一个人变成一群人，问题就来了：有人用 Python 写，有人用 Bash 写，有人直接调 HTTP 接口；参数有的用位置参数，有的用 flag，有的用 JSON；返回结果有的打印文本，有的写文件，有的返回退出码。调用方每次接入一个新能力，都要重新读一遍文档、试一遍参数、处理一遍异常。

这种混乱带来的成本是隐性的，但非常致命。它不会让系统立刻崩溃，但会让每一次扩展都变得小心翼翼，让每一次排错都变成考古。OpenShell 这类项目的出发点，就是承认这种混乱是必然的，然后用一个统一的壳把它包起来。壳的内部可以继续乱，但壳的对外接口必须稳定、清晰、可预测。

2.2 方案选型：为什么是“壳”而不是“重写”

面对混乱，最直接的思路是重写——把所有能力用统一的技术栈重新实现一遍。这个方案听起来很爽，但实际落地几乎必死。原因很简单：重写意味着你要理解每一个已有能力的全部逻辑，包括那些没人记得的边界处理、那些为了兼容历史数据打的补丁、那些只有生产环境才会触发的特殊分支。重写的时间成本、风险成本、验证成本，往往比维护现状还高。

OpenShell 选择的路线是“包一层”，而不是“推倒重来”。这背后的逻辑是：已有能力虽然乱，但它们是经过验证的、能跑的、有业务价值的。与其冒着风险重写，不如在它们外面加一个适配层，把差异吸收掉。适配层对外提供统一接口，对内负责把请求翻译成各个能力能听懂的形式，再把结果翻译回统一格式。这样，新能力接入只需要写一个适配器，老能力继续跑不用动，调用方只学一套规则。

这个思路在工程上有个很形象的类比：就像给一堆不同规格的插头配一个万能插排。你不需要把每个电器的插头都剪掉重焊，只需要一个插排，让它们都能插进来，然后插排对外只提供一个标准接口。

2.3 关键设计原则：稳定、可扩展、可观测

一个能长期活下去的 OpenShell，通常要守住三条原则。

第一条是接口稳定。对外暴露的命令、参数、返回格式，一旦确定就不要轻易改。内部实现可以天天变，但调用方感知不到。这条原则的价值在于，它让调用方敢于依赖你，而不是每次升级都提心吊胆。

第二条是扩展开放。新增一个能力，不应该需要改动核心代码。理想情况下，你只需要按照约定写一个适配器，放到指定目录，注册一下，就能被壳识别和调用。这要求壳在设计之初就把“能力”抽象成一个标准单元，定义清楚它的输入、输出、元信息。

第三条是行为可观测。壳作为统一入口，天然适合做日志、审计、统计。每一次调用是谁发起的、调用了哪个能力、传了什么参数、耗时多少、结果如何，都应该被记录下来。这些数据在排错、容量规划、安全审计时价值极高。很多团队做 OpenShell 的初衷只是统一接口，最后发现最大的收益其实是可观测性。

2.4 适用边界：什么场景适合，什么场景别硬上

OpenShell 不是银弹。它适合的场景是：能力数量多、来源杂、调用方多、需要统一治理。比如内部工具平台、自动化运维系统、插件化应用、多模型调度层。它不适合的场景是：能力只有两三个、调用方只有自己、生命周期很短的一次性脚本。这种情况下加一层壳，纯属给自己找麻烦。

判断标准很简单：如果你觉得“每次接入新东西都要重新解释一遍怎么用”很烦，那就有做壳的价值；如果你觉得“现在这样挺顺的，没必要改”，那就先别动。工程上的过度设计，往往比设计不足更浪费。

3. 核心细节解析与实操要点：壳里面到底装了什么

3.1 能力抽象：把一切统一成“命令”

OpenShell 内部最核心的抽象，通常是一个“命令”或“能力单元”的概念。不管底层是一个脚本、一个二进制、一个 HTTP 服务，还是一个内部函数，到了壳这一层，都被描述成一个命令。这个命令需要具备几个基本属性：名称、描述、参数定义、执行入口、返回格式。

名称是调用方唯一需要记住的东西，所以要短、要语义清晰、要避免歧义。描述是给人看的，用于生成帮助文档。参数定义决定了调用方怎么传值，通常包括参数名、类型、是否必填、默认值、取值范围。执行入口是壳真正去调用底层能力的地方，可以是一个函数引用，也可以是一个子进程调用。返回格式则统一约定为结构化数据，比如 JSON，包含状态码、消息、数据体。

把能力抽象成命令的好处是，壳的核心逻辑变得极其简单：解析输入，找到命令，校验参数，执行，格式化输出。所有复杂性都被推到了适配器里，而适配器是每个能力各自负责的，互不干扰。

3.2 参数解析：别小看这一层，坑最多

参数解析看起来是件小事，实际是 OpenShell 里最容易出问题的地方。原因在于，不同底层能力对参数的期望格式千差万别。有的要--name value，有的要--name=value，有的要位置参数，有的要 JSON 字符串。壳必须把这些差异全部吸收掉，对外只暴露一种风格。

我的建议是，对外统一采用“长选项 + 值”的风格，比如--input file.txt --mode fast。这种风格可读性好，不容易歧义，也方便生成帮助信息。内部适配器负责把它转换成底层需要的形式。对于复杂结构，比如列表或嵌套对象，可以用重复选项或 JSON 字符串，但要在文档里写清楚。

参数校验要在执行之前完成。类型不对、必填缺失、取值越界，都应该在壳这一层拦下来，给出明确错误信息，而不是把错误传给底层能力，让它抛一个莫名其妙的异常。这一点非常重要，因为底层能力的错误信息往往面向开发者，而壳的错误信息应该面向调用方。

注意：参数默认值要谨慎设置。一个看似方便的默认值，可能在调用方不知情的情况下改变行为。凡是涉及数据写入、删除、覆盖的参数，一律不要设默认值，强制调用方显式指定。

3.3 执行隔离：别让一个能力拖垮整个壳

壳作为统一入口，最怕的是被某个底层能力拖死。如果某个能力执行超时、内存泄漏、甚至崩溃，壳不能跟着一起挂。所以执行隔离是必须的。

常见的隔离手段有三种。第一种是子进程隔离，每个能力调用都起一个独立进程，设置超时时间，超时直接杀掉。这种方式隔离性最好，但启动开销大。第二种是线程隔离，用线程池执行，设置超时和异常捕获。开销小，但隔离性弱，一个能力把进程搞崩，壳也保不住。第三种是容器隔离，每个能力跑在独立容器里，隔离性最强，但运维复杂度最高。

对于大多数内部工具场景，子进程隔离是性价比最高的选择。实现上，壳负责拼命令行、起进程、读输出、等退出、处理超时。超时时间建议按能力配置，默认给一个保守值，比如 30 秒，特殊能力单独调大。

3.4 结果格式化：让调用方不用猜

底层能力的输出格式五花八门，有的打印人类可读文本，有的输出 JSON，有的只返回退出码。壳的职责是把这些统一成一种格式。推荐统一为 JSON，因为它是结构化的、跨语言的、易于解析的。

一个典型的返回结构可以包含这几个字段：status表示成功或失败，message表示人类可读的说明，data表示实际数据，meta表示耗时、来源等附加信息。调用方只需要判断status，读data，不用关心底层到底返回了什么。

对于确实只输出文本的能力，适配器要负责把文本包装进这个结构。对于输出已经是 JSON 的能力，适配器要做字段映射，确保最终结构一致。这一步看似繁琐，但它是壳价值的直接体现——调用方从此不用为每个能力写不同的解析逻辑。

3.5 注册机制：新能力怎么接进来

扩展开放的关键，是有一套清晰的注册机制。最简单的做法是约定一个目录，比如commands/，里面每个文件对应一个能力。壳启动时扫描这个目录，加载所有适配器，读取它们的元信息，注册到命令表里。

适配器文件需要暴露一个约定好的接口，比如一个register()函数，返回命令的元信息和执行函数。壳调用这个函数，拿到元信息后存入命令表，执行时再调用执行函数。这样，新增能力只需要在目录里加一个文件，重启壳即可生效，完全不用改核心代码。

更进一步的机制是热加载，壳运行期间监听目录变化，发现新文件自动加载。这个功能很酷，但实现复杂度高，容易引入状态不一致问题。我的建议是，内部工具场景用重启加载就够了，别为了热加载引入不必要的风险。

4. 实操过程与核心环节实现：从零搭一个最小可用壳

4.1 环境准备与技术栈选择

搭一个最小可用的 OpenShell，技术栈选择上以“够用、好维护”为原则。语言方面，Python 和 Go 是最常见的选择。Python 生态丰富、写适配器快，适合能力以脚本为主的场景；Go 编译成单二进制、部署简单、并发处理好，适合能力以服务为主的场景。下面我以 Python 为例，因为它的可读性最好，方便你理解思路后迁移到其他语言。

环境上，你需要一个 Python 3.8 以上的运行环境，标准库就够用，不需要额外依赖。目录结构建议这样组织：openshell/放核心代码，commands/放适配器，logs/放日志，config/放配置。核心代码里，main.py是入口，registry.py管命令注册，executor.py管执行隔离，formatter.py管结果格式化。

这个结构的好处是职责清晰，每个文件只干一件事。后续要换执行方式、换日志格式、换配置来源，都只改对应文件，不影响其他部分。

4.2 命令注册表的实现

注册表的核心是一个字典，键是命令名，值是命令的元信息和执行函数。启动时，壳遍历commands/目录，导入每个模块，调用约定的register()函数，把返回的信息存入字典。

# registry.py import importlib.util import os class Registry: def __init__(self, commands_dir): self.commands_dir = commands_dir self.commands = {} def load_all(self): for filename in os.listdir(self.commands_dir): if not filename.endswith('.py') or filename.startswith('_'): continue path = os.path.join(self.commands_dir, filename) spec = importlib.util.spec_from_file_location(filename[:-3], path) module = importlib.util.module_from_spec(spec) spec.loader.exec_module(module) if hasattr(module, 'register'): meta = module.register() self.commands[meta['name']] = meta def get(self, name): return self.commands.get(name) def list_all(self): return list(self.commands.values())

这段代码的关键点是动态导入。它不依赖固定的模块名，而是扫描目录，按文件加载。这样新增能力只需要加文件，不用改任何配置。register()函数返回的元信息里，至少要包含name、description、params、handler四个字段。

4.3 一个适配器的完整写法

适配器是壳和底层能力之间的桥梁。下面是一个调用外部脚本的适配器示例，假设底层有一个backup.sh，接受源目录和目标目录两个参数。

# commands/backup.py import subprocess def register(): return { 'name': 'backup', 'description': '备份指定目录到目标位置', 'params': [ {'name': 'source', 'type': 'str', 'required': True}, {'name': 'target', 'type': 'str', 'required': True}, {'name': 'compress', 'type': 'bool', 'required': False, 'default': False}, ], 'handler': handle, } def handle(args): cmd = ['bash', 'scripts/backup.sh', args['source'], args['target']] if args.get('compress'): cmd.append('--compress') result = subprocess.run(cmd, capture_output=True, text=True, timeout=300) if result.returncode != 0: return {'status': 'error', 'message': result.stderr.strip(), 'data': None} return {'status': 'ok', 'message': '备份完成', 'data': {'output': result.stdout.strip()}}

这个适配器做了几件事：声明命令名和参数，把壳传来的参数字典翻译成底层脚本能接受的命令行，执行并捕获输出，把结果包装成统一格式。注意超时设置成了 300 秒，因为备份可能耗时较长。这个值应该按能力实际情况调整，不能一刀切。

4.4 参数解析与校验的实现

参数解析的目标是把命令行输入变成结构化的字典，同时完成校验。下面是一个简化实现，支持--key value和--flag两种形式。

# parser.py def parse_args(raw_args, param_defs): result = {} i = 0 while i < len(raw_args): token = raw_args[i] if not token.startswith('--'): raise ValueError(f'意外的参数: {token}') key = token[2:] definition = next((p for p in param_defs if p['name'] == key), None) if definition is None: raise ValueError(f'未知参数: {key}') if definition['type'] == 'bool': result[key] = True i += 1 else: if i + 1 >= len(raw_args): raise ValueError(f'参数 {key} 缺少值') result[key] = raw_args[i + 1] i += 2 for p in param_defs: if p['required'] and p['name'] not in result: raise ValueError(f'缺少必填参数: {p["name"]}') if p['name'] not in result and 'default' in p: result[p['name']] = p['default'] return result

校验逻辑分两步：解析时检查未知参数和缺失值，解析后检查必填项和填充默认值。错误信息要具体，告诉调用方哪个参数出了问题，而不是笼统地说“参数错误”。

4.5 执行入口与日志记录

入口负责把前面几部分串起来：解析命令行，找到命令，校验参数，执行，格式化输出，记录日志。

# main.py import sys import json import time from registry import Registry from parser import parse_args def main(): registry = Registry('commands') registry.load_all() if len(sys.argv) < 2: print(json.dumps({'status': 'error', 'message': '请指定命令'})) return name = sys.argv[1] meta = registry.get(name) if meta is None: print(json.dumps({'status': 'error', 'message': f'未知命令: {name}'})) return try: args = parse_args(sys.argv[2:], meta['params']) except ValueError as e: print(json.dumps({'status': 'error', 'message': str(e)})) return start = time.time() try: result = meta['handler'](args) except Exception as e: result = {'status': 'error', 'message': f'执行异常: {e}', 'data': None} elapsed = round(time.time() - start, 3) result.setdefault('meta', {})['elapsed'] = elapsed log_entry = {'command': name, 'args': args, 'result': result['status'], 'elapsed': elapsed} with open('logs/openshell.log', 'a') as f: f.write(json.dumps(log_entry) + '\n') print(json.dumps(result, ensure_ascii=False)) if __name__ == '__main__': main()

这段代码里，日志记录是重点。每次调用都记一条，包含命令名、参数、结果状态、耗时。这些日志在排错时非常有用，比如某个命令突然变慢，翻日志就能看到耗时变化趋势。日志格式用 JSON，方便后续用工具分析。

4.6 参数计算与超时设置的实际考量

超时时间不能拍脑袋定。我的做法是，先给一个保守的默认值，比如 30 秒，然后观察日志里的实际耗时分布。如果某个命令的 P99 耗时是 20 秒，那超时设 60 秒比较合理，留出缓冲。如果某个命令偶尔会跑几分钟，那要么单独调大超时，要么考虑把它改成异步任务。

并发数也是类似。壳本身通常不需要限制并发，因为调用方自己会控制。但如果壳要对外提供服务，就需要考虑线程池大小。一个经验值是 CPU 核数的 2 到 4 倍，具体要看任务是 IO 密集还是 CPU 密集。IO 密集可以大一些，CPU 密集就接近核数。

5. 常见问题与排查技巧实录

5.1 命令找不到：注册失败的三类原因

最常见的问题是新增了适配器，但壳说“未知命令”。原因通常有三类。第一类是文件名或路径不对，壳扫描的目录和实际放的目录不一致。第二类是适配器模块导入时报错，比如语法错误、依赖缺失，导致register()没被调用。第三类是register()返回的元信息里name字段缺失或拼写不一致。

排查方法很简单：在load_all()里加一行打印，看看实际加载了哪些文件、注册了哪些命令。如果文件没被加载，检查目录和扩展名；如果加载了但没注册，检查register()是否存在、是否抛异常；如果注册了但名字不对，检查name字段。

提示：适配器文件不要用数字开头，也不要用和标准库同名的名字，否则动态导入可能出问题。这个坑我踩过，排查了半天才发现是文件名冲突。

5.2 参数传不进去：类型和格式的隐形陷阱

参数问题的表现是底层能力收到的值和预期不符。常见原因有：布尔参数被当成字符串传下去，导致底层把"False"当成真值；列表参数没有正确拆分，整个字符串被当成一个元素；路径参数包含空格，拼命令行时被截断。

解决办法是在适配器里做显式转换。布尔值转成底层认识的 flag，列表用循环展开，路径用引号包裹或直接用参数列表形式传给subprocess，避免 shell 解析。subprocess.run传列表形式时，每个元素是一个独立参数，不会被 shell 拆分，这是最安全的方式。

5.3 执行卡死：超时和僵尸进程处理

壳最怕的是某个能力卡死，把整个调用链拖住。表现是命令一直不返回，调用方超时，但壳进程还在。原因是底层能力没有超时机制，或者超时后没有正确清理。

处理办法是在壳这一层强制超时。subprocess.run的timeout参数会在超时后杀掉子进程，但要注意，它杀的是直接子进程，如果底层能力又起了孙子进程，可能杀不干净。更稳妥的做法是用进程组，超时后杀掉整个组。Python 里可以用start_new_session=True配合os.killpg实现。

5.4 输出乱码：编码问题的统一处理

底层能力输出的编码可能五花八门，有的 UTF-8，有的 GBK，有的带 BOM。壳如果不统一处理，调用方拿到的就是乱码。解决办法是在捕获输出时指定编码，并加错误处理策略。

result = subprocess.run(cmd, capture_output=True, timeout=60) stdout = result.stdout.decode('utf-8', errors='replace') stderr = result.stderr.decode('utf-8', errors='replace')

errors='replace'会把无法解码的字节替换成占位符，保证不抛异常。虽然会丢失部分信息，但比整个调用失败要好。如果对编码有严格要求，可以在适配器里单独指定。

5.5 常见问题速查表

5.6 独家避坑经验

第一个经验是，适配器里不要做业务逻辑。适配器只负责翻译和包装，业务逻辑留在底层能力里。这样壳保持轻薄，底层能力保持独立，两边都好维护。我见过把业务逻辑写进适配器的项目，最后壳变得无比臃肿，改一个业务规则要动壳的核心代码，完全违背了初衷。

第二个经验是，命令命名要有前缀或分类。能力多了以后，命令名容易冲突或混淆。用db.backup、file.clean这种带命名空间的名字，比backup、clean清晰得多。壳在解析时按点号拆分，也方便做权限控制。

第三个经验是，一定要有--help。调用方不可能记住所有命令和参数，一个能列出所有命令、显示每个命令参数的帮助功能，能极大降低使用门槛。实现上，壳拦截--help，从注册表里读元信息，格式化输出即可。

6. 扩展方向与长期维护建议

6.1 权限控制：谁能调用什么

壳作为统一入口，天然适合做权限控制。可以在命令元信息里加一个roles字段，声明哪些角色可以调用。壳在执行前检查调用方角色，不匹配就拒绝。角色来源可以是环境变量、配置文件、或者外部认证服务。

这个机制的价值在于，它把权限收拢到一处，而不是散落在各个底层能力里。新增能力时，权限声明和命令定义写在一起，不容易遗漏。审计时，看壳的日志就知道谁在什么时候调用了什么，比翻各个能力的日志高效得多。

6.2 异步任务：长耗时能力的处理

有些能力天生耗时长，比如大数据导出、批量处理。让调用方同步等待不现实。壳可以支持异步模式：调用时返回一个任务 ID，调用方凭 ID 查询进度和结果。

实现上，壳维护一个任务表，异步执行能力，把结果存起来。查询命令根据任务 ID 返回状态。这个模式会增加复杂度，但对长耗时场景是必要的。建议只在确实需要的能力上启用，不要全局异步化。

6.3 配置管理：让壳适应不同环境

壳的行为在不同环境下可能不同，比如开发环境用本地脚本，生产环境调远程服务。这些差异应该通过配置管理，而不是改代码。配置文件可以用 YAML 或 JSON，按环境分节，壳启动时根据环境变量加载对应配置。

配置项包括：命令目录、日志路径、默认超时、并发数、权限规则等。配置和代码分离的好处是，部署时不用改代码，只改配置，降低了出错概率。

6.4 监控与告警：让壳自己说话

壳的日志是金矿，但光有日志不够，还需要监控和告警。可以定期统计每个命令的调用次数、成功率、平均耗时，发现异常时告警。比如某个命令成功率突然下降，或者耗时突然飙升，都值得关注。

实现上，可以在日志基础上加一个统计模块，定期汇总，输出到监控系统。简单场景下，一个定时脚本读日志、算指标、发通知就够了。复杂场景可以接入专业的监控平台。

6.5 版本兼容：接口变更的平滑过渡

壳的接口一旦对外，就不能随便改。但需求总会变，怎么办？答案是版本化。命令名可以带版本，比如backup.v1、backup.v2，老版本继续可用，新版本逐步推广。等所有调用方都迁移完，再下线老版本。

这个策略的关键是给足迁移时间，并且在新版本里保持老版本的语义兼容。如果实在无法兼容，要在文档里明确说明差异，并提供迁移指南。接口变更最怕的是突然袭击，调用方毫无准备，信任一旦破坏就很难修复。

6.6 文档自动生成：让元信息发挥价值

适配器里的元信息，除了给壳用，还可以用来生成文档。写一个脚本，遍历注册表，把每个命令的名称、描述、参数、示例输出成 Markdown 或 HTML，就是一份永远和代码同步的文档。这比手写文档靠谱得多，因为手写文档总会过期，而自动生成的不会。

文档里最好包含每个命令的实际调用示例，这个可以从元信息里的示例字段读，也可以从日志里提取真实调用记录。真实示例比编造的示例更有参考价值。

7. 我在这类项目里踩过的坑和真实体会

做 OpenShell 这类项目，最大的体会是：壳的价值不在于技术多先进，而在于约定多清晰。技术选型可以很朴素，Python 标准库就够，但约定必须严格——命令怎么命名、参数怎么传、结果怎么返回、错误怎么报，这些约定一旦定下来，就要像法律一样执行。我见过太多项目，壳搭得很漂亮，但约定松散，最后调用方还是各写各的，壳形同虚设。

第二个体会是，别追求大而全。一开始就想支持所有能力类型、所有参数格式、所有执行模式，结果就是复杂度爆炸，维护不动。正确的做法是先支持最常见的一两种，跑起来，用起来，再根据实际需求扩展。最小可用版本能解决 80% 的问题，剩下的 20% 等真遇到了再说。

第三个体会是，日志和错误信息要舍得花时间。这两样东西平时不起眼，出问题时就是救命稻草。错误信息要具体到哪个参数、哪个值、期望什么、实际什么。日志要包含足够上下文，能还原调用现场。我在排一个诡异问题时，就是靠日志里记录的完整参数和耗时，才发现是某个参数在特定值下触发了底层的一个隐藏分支。

最后一个体会是，壳的边界要清晰。壳只做统一入口该做的事：解析、校验、调度、格式化、记录。业务逻辑、数据存储、复杂计算，都不该进壳。边界清晰了，壳才能保持轻薄，才能长期活下去。一旦壳开始膨胀，就是它走向衰败的开始。

如果你正准备做类似的东西，我的建议是先用一个下午搭个最小版本，跑通一个真实能力，然后拿给同事用。真实反馈比任何设计文档都有价值。用起来之后，该加什么、该改什么，自然就清楚了。