结合OpenSpec 与 Everything-Claude-Code (ECC) 的构建团队工作流程

一、两者定位本质差异

这两个项目解决的是 AI 辅助开发流程中完全不同层面的问题，理解这一点是最关键的。

OpenSpec 解决的是 "做什么"（What） 的问题 ------ 它是一个规格驱动开发（Spec-Driven Development）框架。核心理念是：在 AI 写代码之前，先让人和 AI 就需求规格达成共识。它通过 proposal → specs → design → tasks 的制品（artifact）依赖图来管理每一个变更的完整生命周期。

ECC 解决的是 "怎么做"（How） 的问题 ------ 它是一个AI 编码助手的配置工具箱。核心理念是：提供一整套生产就绪的 agents、skills、hooks、commands、rules 和 MCP 配置，让 Claude Code（以及 Cursor/OpenCode/Codex）的执行能力最大化。

打个比方：OpenSpec 相当于项目经理的需求管理系统，ECC 相当于开发者的瑞士军刀。

二、核心机制对比

OpenSpec 的核心机制

OpenSpec 的核心是一个 制品依赖图引擎（Artifact DAG）。每个变更（change）被组织为一个独立文件夹，包含四类制品：

proposal.md 记录意图和范围，specs/ 通过 Delta 格式（ADDED/MODIFIED/REMOVED）描述行为变化，design.md 记录技术方案和架构决策，tasks.md 则是带复选框的实施清单。这些制品形成有向无环图的依赖关系，状态通过文件系统存在性自动检测（BLOCKED → READY → DONE）。

它的 OPSX 工作流打破了传统线性阶段的限制，采用流动式操作：你可以在实施过程中随时回头修改设计，不存在阶段门禁。同时它支持 24+ AI 编码工具（Claude Code、Cursor、Windsurf、Gemini CLI、GitHub Copilot、Kiro 等），做到了真正的工具无关性。

特别值得一提的是它的 Delta Spec 概念 ------ 不是重写整个规格，而是描述变化量，这对存量项目（brownfield）极其友好。变更完成后通过 archive 操作将 delta 合并回主规格，形成持续演进的系统行为文档。

ECC 的核心机制

ECC 是一套模块化的配置组件库，包含 13 个专用子代理（planner、architect、tdd-guide、code-reviewer、security-reviewer 等），56 个 skills 覆盖前后端模式、持续学习、安全审计等领域，32 个斜杠命令（/plan、/tdd、/code-review、/e2e 等），以及 hooks 系统实现会话记忆持久化、自动格式化、战略性上下文压缩等自动化行为。

它的 Instinct 持续学习系统（v2）是亮点：自动从会话中提取模式，赋予置信度评分，支持跨团队导入导出，并可通过 /evolve 命令将相关直觉聚合为技能。

此外 ECC 的 AgentShield 安全扫描器（1282 个测试、102 条规则）可以扫描你的 AI 配置（CLAUDE.md、hooks、MCP 等）中的漏洞和注入风险，甚至支持三个 Opus 代理的红队/蓝队/审计流水线。

三、各自优缺点

OpenSpec

优点： 工具无关性是它最大的战略优势。支持 24+ AI 工具意味着团队不会被锁定在某个特定 IDE 或 AI 提供商上，前端用 Cursor、后端用 Claude Code 的团队可以共享同一套规格流程。Delta Spec 机制为存量项目提供了优雅的增量规格管理。自定义 schema 能力让团队可以定义自己的制品类型和依赖关系，比如加入 research 步骤。作为 npm 包分发（openspec init 一条命令初始化）降低了团队推广门槛。同时，制品文件夹结构天然支持 Git 版本控制和代码评审。

缺点： 它不涉及代码执行层面的优化，不提供 agent、hook 或 coding skill。对于小型快速迭代任务（hotfix、小 bug）流程可能显得重。需要团队养成写规格的习惯，存在文化适配成本。它也没有 token 优化、上下文管理、会话持久化等运行时增强能力。

ECC

优点： 开箱即用的生产级配置经过了实际产品构建的验证（Anthropic 黑客松获奖作品）。token 优化策略具体且实用（模型选择、thinking token 限制、compaction 阈值），能显著降低成本。多语言 rules 架构（common/ + typescript/ + python/ + golang/）适配不同技术栈。Instinct 学习系统让团队经验可以积累和传承。AgentShield 安全扫描填补了 AI 配置安全性的空白。同时跨平台支持（Claude Code、Cursor、Codex CLI、OpenCode）也相当完善。

缺点： 以 Claude Code 为主要目标，对其他工具的支持虽在扩展但存在功能差距。缺少需求-设计-实施的结构化流程管理，/plan 命令只是调用 planner agent 生成蓝图，不像 OpenSpec 那样有制品依赖图和生命周期管理。配置项繁多（56 skills + 32 commands），新用户需要时间理解哪些组件适合自己。Rules 无法通过插件自动分发（Claude Code 平台限制），需要手动安装。

四、最佳实践姿势

OpenSpec 最佳实践

适合的场景是中大型功能、跨团队协作、需要需求对齐的工作。推荐的流程是：对于明确需求用 /opsx:propose 快速启动然后 /opsx:apply 实施；对于模糊需求先用 /opsx:explore 探索再决定方案；保持每个 change 聚焦于一个逻辑单元；archive 前用 /opsx:verify 验证实现与规格的一致性。

命名规范也很重要：用 add-dark-mode、fix-login-redirect 这种描述性名称，避免 feature-1、wip 这种模糊命名。

ECC 最佳实践

token 管理是关键：默认使用 sonnet，只在复杂架构推理时切换 opus；将 MAX_THINKING_TOKENS 设为 10000，CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 设为 50；MCP 服务器保持 10 个以内，工具总数 80 以内。

工作流模式上：新功能用 /plan → /tdd → /code-review 三步走；修复 bug 先用 /tdd 写失败测试再修复；发布前用 /security-scan + /e2e + /test-coverage 三重验证。任务之间用 /clear 重置上下文，逻辑断点处用 /compact 压缩。

五、面向公司前后端团队的整合方案

基于对两者的深入分析，我推荐的整合策略是 OpenSpec 做流程骨架 + ECC 做执行引擎，两者互补而非替代。

第一层：需求与规格管理（OpenSpec）

在项目根目录执行 openspec init 初始化，所有非 trivial 的功能开发都从 /opsx:propose 或 /opsx:explore 开始。前端和后端开发者在同一个 openspec/changes/ 目录下协作，但各自维护各自领域的 specs（如 specs/api/、specs/ui/）。利用 OpenSpec 的工具无关性，让用不同 IDE 的团队成员共享同一套规格流程。

第二层：编码执行增强（ECC）

在每个开发者的环境中安装 ECC 插件并配置对应语言的 rules（前端装 common/ + typescript/，后端根据栈选择 python/ 或 golang/）。利用 ECC 的 agents 体系：planner 和 architect 辅助 OpenSpec 的 proposal 和 design 阶段，tdd-guide 和 code-reviewer 在 /opsx:apply 实施阶段提供质量保障。配置 token 优化策略统一降本。

第三层：质量与安全闭环

实施完成后，用 /opsx:verify 验证规格一致性（OpenSpec），同时用 ECC 的 /security-scan、/test-coverage、/e2e 进行技术层面验证。用 AgentShield 定期扫描团队的 AI 配置安全性。

第四层：知识积累与传承

利用 ECC 的 Instinct 系统自动学习团队模式，定期 /instinct-export 导出分享。OpenSpec 的 archive 机制自动积累系统行为规格，新人 onboard 时直接阅读 openspec/specs/ 了解系统当前行为。