能力承载面选择¶
在判断某项能力应放在规则、技能、MCP 服务器还是普通 CLI/API 工作流中时，将此作为路由指南。
ECC 并不将这些承载面视为可互换。目标是将每项能力放入最窄的承载面，同时保持正确性、控制 Token 成本，并避免带来不必要的运行时或供应链拖累。
简短版本¶
rules/用于确定性的、始终生效的约束，当路径或事件匹配时应被注入。skills/用于按需工作流、更丰富的操作手册，以及 Token 开销较大、仅在相关时加载的指导。MCP用于交互式结构化能力，这类能力受益于跨会话或客户端的长生命周期工具/资源承载面。- 本地
CLI或仓库脚本用于简单的确定性操作，这类操作不需要持久化服务器。 - 技能内部的直接
API调用用于狭窄的远程操作，此时完整的 MCP 服务器会比问题本身更重。
决策顺序¶
按顺序提出以下问题：
- 是否每次路径或事件匹配时都应发生，且不涉及模型判断？
- 使用
rule。 - 这是否主要是操作手册、工作流或建议层，且只应在任务实际需要时加载？
- 使用
skill。 - 该能力是否需要结构化的交互式工具/资源接口，供多个运行框架或客户端反复调用？
- 使用
MCP。 - 它是否是一个简单的本地操作，可以以脚本形式运行，而无需保持服务器存活？
- 使用本地
CLI入口点或仓库脚本，必要时再用技能包装它。 - 它是否只是更大工作流中的一个狭窄远程集成步骤？
- 从技能或脚本中直接调用外部
API。
按承载面指南¶
Rules¶
将规则用于：
- 路径范围内的编码不变量
- 安全底线和权限约束
- 应始终适用的运行框架/运行时约束
- 不应依赖模型自由裁量的确定性提醒
不要将规则用于：
- 会膨胀每次匹配编辑的大型操作手册
- 可选工作流
- 昂贵且只在部分时间重要的领域上下文
Skills¶
将技能用于：
- 多步骤工作流
- 判断密集型指导
- 昂贵到只能按需加载的领域操作手册
- 跨脚本、API、MCP 工具和相邻技能的编排
不要将技能用作真正需要确定性路由的静态不变量的堆放地。
MCP¶
当能力受益于以下情况时，使用 MCP：
- 结构化的工具输入/输出
- 可复用的资源或 Prompt
- 跨客户端的重复使用
- 应跨 Claude Code、Codex、Cursor、OpenCode 及相关运行框架工作的稳定接口
- 长生命周期服务器进程值得其运维开销
在以下情况下避免使用 MCP：
- 任务是一次性本地命令
- 服务器唯一要做的事情是执行一次 shell 命令
- 服务器带来的安装/运行时负担超过产品价值
CLI / 仓库脚本¶
在以下情况下优先使用本地脚本或 CLI：
- 操作是确定性的
- 启动成本低
- 工作流主要是本地的
- 暴露持久化工具/资源承载面没有好处
这通常是以下场景的正确选择：
- lint/test/build 包装器
- 本地转换
- 小型安装器
- 每次调用运行一次的内容生成
直接 API 调用¶
在以下情况下，优先在现有技能或脚本内部使用直接 API 调用：
- 集成范围狭窄
- 远程操作是更大工作流的一部分
- 你尚不需要可复用的传输承载面
如果同一远程集成变得核心、重复且多客户端，那就是将其升级为 MCP 承载面的信号。
成本与可靠性偏好¶
当两个选项都可行时：
- 优先选择更小的运行时承载面
- 优先选择更低的 Token 开销
- 优先选择外部活动部件更少的路径
- 优先选择 ECC 原生打包，而不是引入另一个第三方依赖
除非该能力明显值得其维护、安全和安装负担，否则不要将外部插件或包依赖规范化为一等 ECC 承载面。
仓库策略¶
从外部仓库引入想法时：
- 复制底层想法，而不是外部依赖
- 将其重新打包为 ECC 原生规则、技能、脚本或 MCP 承载面
- 如果功能已为 ECC 实质性扩展或重塑，请重命名它
- 除非该依赖是有意为之、经过审计且对工作流至关重要，否则避免发布要求用户安装无关第三方包的说明
示例¶
- 一个应始终适用于
api/**编辑的后端认证不变量： rule- 更深入的 API 设计和分页操作手册：
skill- 跨多个运行框架使用的可复用远程搜索承载面：
MCP- 一次性仓库分析器，读取本地文件并写入报告：
- 本地
CLI或脚本，可选地由skill包装 - 更广泛客户运营工作流中的单个计费门户会话创建步骤：
- 工作流内部的直接
API调用
实用经验法则¶
如果你不确定，请从小处开始：
- 从
rule开始处理确定性不变量 - 从
skill开始处理指导/工作流 - 从脚本开始处理一次性执行
- 只有当结构化服务器边界明显物有所值时，才将其提升为
MCP
本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 ev/ECC