工程实践

在 GitHub 上拥有超过 50,000 颗星的 everything-claude-code（以下简称 ECC），其 README 的第一句话就明确写着：“Not just configs”（不仅是配置）。对于大多数初次接触它的开发者来说，这可能是一个令人费解的定义。 通常，开发者使用 Claude Code 或 Codex 的方式非常直观：安装、提问、观察 AI 生成代码、手动修复错误。在这种模式下，AI 只是一个高级的自动补全或交互式脚本工具。ECC 的出现改变了这个逻辑——它不是在 Claude Code 之上堆叠更多的 Prompt 模板，而是试图解决一个更底层的问题：如何让 AI agent 像一个成熟的软件工程师一样，具备可预测、可复用且能持续进化的工程交付能力。 ECC 的本质是一套为 AI agent 量身定制的 harness 操作系统。它将"AI 如何可靠完成工程任务"这一复杂课题，拆解为技能、本能、记忆、验证四个维度，并提供了一套系统化的技术实现框架。 它不是配置包 当你打开 ECC 的代码库，你会发现它并没有提供成千上万行的配置文件。相反，它提供了一套完整的逻辑层，介入了 AI agent 与文件系统、终端命令以及开发者意图之间的每一次交互。 大多数开发者在使用 AI coding 工具时，面临的最大痛点是"随机性"。同一个任务，在不同的 session 中可能会得到完全不同的实现路径。ECC 认为，这种随机性源于 agent 缺乏统一的工程规范和执行框架。ECC 提供的不是"更好的答案"，而是"更好的工作流"——它将 AI 从一个随机应变的聊天机器人，转变为一个遵循特定协议的工程执行单元。这种从"对话驱动"到"协议驱动"的转变，是 ECC 区别于普通配置包的根本原因。 四层体系 ECC 当前包含 28 个专用子代理、116 个技能和 59 个命令，背后是四个相互支撑的层级设计。每一层都解决了 AI agent 在工程化落地中的特定缺陷。 技能（Skills）：这是 ECC 的执行库，116 个标准化工作流定义，覆盖从 TDD、架构分析、自动化安全扫描到内容写作的各个领域。这些技能是原子化的——当 agent 需要执行特定的工程操作时，按需调用相应的技能模块。例如，在进行代码重构前，agent 会先调用"架构分析技能"来识别潜在的副作用，而不是直接开始修改代码。 ...

在使用 Claude Code 进行超过 3 天的持续开发后，你可能会发现它的表现开始下滑：原本能完美遵循的架构规范被无视，它开始频繁回复"I’ll be more concise now"，甚至遗忘半小时前刚刚达成的技术决策。这不是 Claude 的逻辑能力下降了，而是 context window 中充斥了大量过往推理、错误尝试和冗长的文件读写记录，导致注意力的精确度发生了系统性偏移。 这种现象被称为 Context Rot（上下文腐烂）。对于任何试图用 AI 助手构建真实产品而非简单 Demo 的开发者来说，Context Rot 是限制生产力的核心瓶颈。 get-shit-done（以下简称 GSD） 的出现并非为了让 AI 写出更精妙的代码片段，而是为 Claude Code 引入了一个专门的项目管理层。它的核心逻辑只有一句话：通过外部化的状态文件和受限的编排架构，从底层消灭 context 积累，从而彻底解决 Context Rot 问题。 Context Rot 是什么，为什么它是真正的问题 当你在一个 Session 中连续输入超过 50 轮对话，Claude 的 context usage 往往会跳升至 100k token 以上。此时最直观的证据是响应变慢，以及它开始丢失对全局约束的感知。Transformer 架构的注意力机制在处理超长序列时存在权重弥散——模型会更倾向于关注最近几轮对话的细节，忽略初始阶段定义的架构原则。 根本原因是信息密度超载。在原始的 Claude Code Session 中，搜索结果、代码修改记录、测试报错和无关闲聊被线性地堆叠在一起。这些"噪音"占据了宝贵的注意力空间。即使 Claude 有 200k 的窗口，真正有效的注意力和被噪音稀释后的执行质量之间存在着巨大的鸿沟。 GSD 的判断：不要试图管理长 context，而要从架构上消灭它的积累。 它强制要求通过文件来同步状态，而不是通过对话历史。 状态文件体系：将记忆外挂 GSD 要求项目根目录下存在一套标准的机器可读文件，包括 PROJECT.md、STATE.md、REQUIREMENTS.md、ROADMAP.md 和 PLAN.md。这些文件不是写给人类看的文档，而是 Claude 的"外挂硬盘"。 ...

everything-claude-code（ECC）、BMAD-METHOD 和 Superpowers 代表了 AI 编程工具增强的三种不同路径：ECC 是工具链性能层，旨在压榨 Agent 的执行上限；BMAD 是项目管理方法论，将敏捷开发引入 AI 时代；Superpowers 是最小化工作流约束系统，通过强制 TDD 纪律减少随意性。三者解决的问题维度不同，不存在绝对优劣。 三条路，三种答案 当前 AI 编程工具的扩展正处于爆炸期，开发者们不仅在追求更强的模型，更在思考如何通过 skills、agents、hooks 和 workflows 构建更高质量的工程闭环。在这场竞赛中，三个开源项目各代表了不同的演进方向。 ECC (everything-claude-code)：Anthropic Hackathon 获奖项目，76k stars。它通过一套极其复杂的工程化配置，解决了 AI Agent 在长上下文管理、Token 效率和跨 session 记忆方面的痛点。 BMAD-METHOD：40.7k stars，专注于敏捷 AI 开发的方法论。它不只是工具增强，而是一套完整的项目生命周期管理框架，包含从需求分析到部署的标准化流程。 Superpowers：由 Jesse (obra) 发起，已上架官方 Claude 插件市场。主张"流程即法律"，通过自动触发的 Skills 强制执行 TDD 和 Git 工作流。 本文不是评选"冠军"，而是通过系统视角剖析它们的设计哲学，帮助工程师根据自己的项目规模和协作习惯建立选择框架。 三个项目的系统定位 这三个框架在 AI 编程的生态栈中处于不同的层次。 ECC：工具链性能优化层。 它不关心你写的是什么业务，它关心的是"如何让 AI 执行得更稳"。通过内置的 instincts、memory hooks 和 security scan，它为 Claude Code 或 Codex 等 Harness 提供了一个高性能的运行环境。核心价值在于 Token 优化和记忆持久化，解决"Agent 越用越笨"的问题。 ...