看到 ECC 和 Spec Kit，我首先想到的是同一个问题：它们都给 AI 编程加上了计划、规则和验证，为什么要分成两个项目？
更有意思的是热度。2026 年 10 月 17 日查询 GitHub API，ECC 有 281,559 Star，Spec Kit 有 141,571 Star，前者约为后者的 1.99 倍。ECC 的仓库创建于 2026 年 1 月，Spec Kit 创建于 2025 年 8 月。一个更晚创建的社区项目，Star 已经超过 GitHub 组织下的项目。
这个数字值得关注，但它只反映收藏规模，不能直接证明使用人数、交付质量或生产采用率。单次快照也无法确定两者何时发生反超。
要读懂这个现象，需要先看清它们分别把什么交给开发者。
定位确实重叠，但重心不同
ECC 的历史名称是 Everything Claude Code。当前仓库已经用 ECC 作为名称，定位也从 Claude Code 配置扩展到多种编程代理。
当前 README 把它描述为一套协调工程工作的系统和工具箱。理解这套工具时，会遇到 agent harness 这个词，可以把它理解为模型外围的执行环境：怎样发现技能、调用工具、触发检查、保留上下文，以及组织多个代理。
因此，ECC 主要关注的是：让代理以什么方式工作，才能少犯重复错误，并把有效做法保存下来？
Spec Kit 的经典入口是规范驱动开发，也就是 SDD：先明确要做什么、为什么做，再形成技术计划和任务，最后据此实现和验证。它主要关注的是：一个需求怎样经过明确的中间产物，变成可以验收的实现？
不过，拿今天的 ECC 对比早期印象中的 Spec Kit，会低估后者。当前 Spec Kit 已经把自身描述为提供结构化流程、可复用模板和有记录结果的工具包。SDD 在核心中交付，缺陷修复和想法评估则通过按需安装的扩展提供；另外还有预设、工作流和组件包。
所以，两者都有规则、技能和流程，也都在扩展边界。更准确的比较，是看它们默认从哪里切入，以及把什么作为主要交付物。
用“导出订单”这个需求看区别
假设我要为一个后台增加订单 CSV 导出。
一句“帮我加个导出按钮”留下了很多空白：谁能导出？导出当前筛选结果还是全部数据？时间使用哪个时区？十万条订单能否同步下载？包含手机号时如何处理？
Spec Kit 先把约定变成可检查的产物
在 Spec Kit 的 SDD 流程中，项目先确定 constitution，也就是项目原则。每个功能再经过 specify、plan、tasks、implement、converge。当前官方流程要求在实现与收敛检查之间迭代，直到报告收敛。
对应到订单导出，规范阶段应先明确权限、字段和验收场景。计划阶段再决定同步请求还是异步任务、怎样分页读取数据，以及如何测试。任务阶段把这些决定拆成可执行工作。
这些内容仍需要人审阅。代理生成了一份规范，不代表已经发现所有业务边界；但它把原本藏在对话里的假设，变成了团队能指出、修改和追踪的对象。
例如，“普通员工不能导出手机号”如果只留在某次聊天中，后续很容易遗漏。把它写进规范和验收条件，代码评审就有了明确的检查依据。
ECC 把常用工程做法装进代理环境
ECC 更像是为执行这些任务准备一套工程工具。
它的规则可以约束编码和测试习惯；技能提供按步骤执行的方法；专职代理可以负责计划、代码审查或安全检查；钩子则在工具调用或会话事件发生时执行脚本。
还是订单导出这个功能：写接口时使用项目规则，测试时调用测试相关技能，提交前执行验证流程，再用相对独立的审查上下文检查权限、异常处理和敏感数据。
这里的重点是工作方式。即使没有采用一套完整的 SDD 文档流程，也可以使用这些能力修复一个测试、检查一段代码或整理一次会话。
先看下图的纵向关系：上方蓝色区域保留项目约定，下方绿色区域围绕代理执行组织工具。中间的箭头表示约定进入实现；这是一种职责划分示意，并非两个项目已经提供了官方集成。
项目约定指导代理执行，两类能力可以互补。
ECC 的关键，不只是技能数量
ECC 的目录很大，但理解它不必从记住全部技能开始。更有用的是区分四种机制。
规则决定默认要求。 例如怎样组织代码、如何处理错误、什么情况下需要测试。它们能减少重复说明，但自然语言规则仍依赖代理理解和遵守，不能代替可执行检查。
技能提供具体操作步骤。 ECC 的 verification-loop 技能依次组织构建、类型检查、lint、测试、安全扫描和 diff 审查，最后输出验证报告。这比一句“检查一下代码”更明确。
但技能中的示例命令和阈值需要适配项目。仓库没有配置某个检查工具时，照抄命令不会自动得到有效验证；简单的字符串扫描，也不能当作完整安全审计。
钩子把部分行为接到事件上。 模型记得调用某个技能，与执行环境在匹配事件后启动脚本，是不同的触发机制。ECC 的钩子配置包含工具调用前后的观察与检查入口，具体运行哪些内容还受配置、钩子档位和宿主能力影响。
因此，“支持钩子”不等于“每个操作都会被可靠拦截”，更不等于“错误已经被阻止”。脚本失败、超时、事件支持差异和安装重复，都需要排查。
记忆与持续学习保存可复用经验。 ECC 的 continuous-learning-v2 描述了一条路径：观察会话，从纠正和重复模式中提取小规则，为规则记录触发条件、行动、证据和置信度，再把相关规则整理成可复用能力。这些小规则被称为 instinct。
比如，我多次纠正代理：“这个项目用指定的数据库测试夹具，不要直接创建全局连接。”这类重复纠正可以成为候选规则，而不必每次重新解释。
图中绿色回路强调了经验重新进入后续执行的路径。中间的橙色“审阅与整理”不能省略：提取出的习惯可能过时，也可能只适用于某个项目。
持续学习通过外部记录影响后续执行，候选经验仍需要审阅和整理。
这种学习主要发生在文件、记录和提示上下文中，通常不涉及重新训练底层模型。项目级隔离可以减少经验混用，但不能保证提取出的规则一定正确。置信度也是系统记录的信号，不是经过校准的正确概率。
为什么 ECC 能获得更多 Star？
我更倾向于从采用方式解释这个现象。不过，下面是根据产品形态作出的判断，不是经过用户调查验证的增长归因。
第一，ECC 可以从很小的需求开始用。 我可以只想要代码审查、测试方法或会话整理，不必先接受完整开发流程。这让更多日常任务成为入口。
Spec Kit 的完整 SDD 路径则要求开发者愿意先澄清需求、审阅规范和计划。这些投入在复杂功能上可能很有价值，但收益往往要到后续协作和验收时才更明显。与此同时，它现在也提供独立的缺陷修复入口，不能把所有使用场景都视为完整 SDD。
第二，ECC 把很多零散的配置工作集中起来了。对已经使用编程代理的人来说，规则、审查、验证、记忆都很容易对应到已有痛点。收藏一个仓库，就能保留多个将来可能用到的入口。
第三，ECC 从 Claude Code 场景扩展到更多工具，增加了潜在受众。不过，“能安装”与“能力相同”要分开看。当前支持说明把 Claude Code 列为主要稳定目标，其他适配存在不同限制。例如，GitHub Copilot Chat 主要是指令层支持，没有适配 ECC 钩子。
这些特点可以解释它为什么容易吸引关注，却不能证明它比 Spec Kit 更适合某个团队。Star 多，也不意味着应当安装更多组件。
反过来看，GitHub 的组织身份能带来可见度和信任基础，但不会自动消除流程成本。开发者仍会根据眼前的问题，判断哪种工具值得投入时间。
两者各自要付出什么成本？
ECC 的主要成本是配置和持续维护。
组件越多，越要知道哪些规则已加载、哪些技能会被发现、哪些钩子会执行，以及哪些后台操作会增加模型调用或等待时间。当前文档也提示，完整插件会把目录能力信息暴露给模型；如果在意上下文占用，应考虑选择性安装。
记忆还会引入新的维护工作：错误经验怎样删除？项目约定变化后，旧规则怎样失效？观察记录保留了什么？这些都不是“安装一次”就永久解决的问题。
Spec Kit 的主要成本是维护约定与实际实现的一致性。
如果规范写完就不再更新，计划和任务只会变成另一套过时文档。对于范围很小、验收条件明确的修复，完整 SDD 路径也可能投入过多；应选择与任务匹配的入口。
它们还有一个共同边界：代理写出了检查清单，不代表检查已经执行；报告显示通过，也需要确认检查覆盖了真正的验收条件。关键发布门槛仍应落实到项目测试、CI、权限控制和人工评审。
我会怎样选择？
如果当前最困扰我的是“代理总忘记项目约定”“每次都要重复提醒测试”“长会话之后上下文丢失”，我会先选取 ECC 中的一小组能力。以一个项目、一个任务类型开始，观察它是否真的减少纠正和返工。
如果问题是“团队对需求理解不一致”“实现完成后才发现权限和边界没谈清”，我会先尝试 Spec Kit。把规范、计划和验收结果作为需要认真评审的项目产物。
两种问题同时存在，也可以尝试组合，但不要直接把两套默认流程全部叠加。
一个可行的做法是：由 Spec Kit 维护功能规范、技术计划和任务；从 ECC 选择需要的审查或验证能力，并明确这些能力必须读取哪些项目文件。谁更新任务状态、谁维护验收结论，也要约定清楚。这里描述的是使用方案，尚未进行两者联合安装和兼容性实测。
对于订单导出，我会先把权限、字段、数据量和验收条件谈清，再让代理按项目规则实现，最后对照同一份约定检查结果。工具可以换，需求依据与验证结果必须对得上。
ECC 的热度提醒我，开发者很需要能直接改善代理日常工作的工具。Spec Kit 则强调了另一项同样具体的工作：在实现之前，把大家究竟同意了什么写清楚。选型时，先找出返工发生在哪一步，比比较仓库排名更有用。