ECC (Everything Claude Code) 是一个为 AI 编码代理（Agent）设计的性能优化系统与操作层。它并非模型或 IDE，而是在 Claude Code、Codex、Cursor 等代理工具之上，提供的一套包含技能、记忆、安全与工作流的完整工程系统。
项目概述
ECC 由 Affaan Mustafa 维护，源自其超过 10 个月在真实产品中每日使用 Claude Code 的实践经验。项目采用 MIT 许可，开源部分永久免费。截至 2026 年 9 月，它在 GitHub 上已获得超过 211.9K 星标和 32.5K Fork，拥有 230+ 位贡献者，并支持 12 种以上的语言生态。
介绍
一个开发者把自己用了十个月的Claude Code配置丢进黑客松，八小时拿了冠军，然后他把整套系统开源了！
这套配置现在叫ECC，GitHub星标破了二十万，两千多人给它提过代码，MIT协议永久免费，它做的事情只有一件——让AI写完代码之后，换一双眼睛重新看一遍！
很多人觉得AI编程工具越强，程序员就越省事，但真实情况恰恰相反，工具越强，你需要审的代码就越多，你花在“读别人写的代码”上的时间，正在超过你自己写代码的时间。ECC不是在帮你写代码，它是在帮你管理一支隐形的工程团队，而这支团队的运作规则，才是真正值钱的东西。
ECC全称Everything Claude Code，是一个给AI编码代理用的性能优化系统。它背后是一整套完整的工程操作系统，包含六十八个专业智能体、两百八十五项按需加载的技能，以及一套叫AgentShield的安全扫描器。它的作者Affaan Mustafa用了一年多在真实产品里每天跑Claude Code的经验，把一整套工程流程固化成了六十八个专业代理、两百八十五项技能和九十四项命令，全部MIT协议开源。
本文深度拆解Loop Engineering核心逻辑，详解ECC工具如何补齐Claude Code原生短板，落地真正可用的无人值守AI工作流，理清2026年AI编程最核心的范式跃迁，避开所有自动化陷阱。
ECC最大的野心藏在它的循环架构里
Claude Code官方在二〇二六年六月定义了四种循环类型：回合制循环是你手动发一条提示词；目标循环用/goal跑到条件满足才停；时间循环用/loop按固定间隔重复运行；主动型循环把所有东西叠在一起。这四个类型讲的是概念，从概念到真正能跑、能停、能救回来的工程系统，中间隔着一整套脚手架，而ECC做的事情就是把这套脚手架全部搭好。
Claude Code 底层原语（运行时）：
- /goal：条件驱动循环，内置独立评估模型，回合结束判定是否达成目标；会话级、单会话只能一个活跃 goal。
- /loop：时间调度循环，本地会话 cron 调度，7 天过期；会话绑定，关闭终端停止。
- Stop‑Hook：每轮回合结束触发，/goal底层就是基于 Stop‑Hook 实现。
- Skill（SKILL.md）：可复用工作单元。
- MCP 工具：Cron 调度工具、文件读写、Playwright 浏览器、Git Worktree 隔离工作区。
ECC 不会改写上面底层原语，而是封装上层模式、模板、约束、状态层，解决原生能力的短板：缺少持久状态、缺少独立校验 Agent、缺少子 Agent 编排、跨会话记忆缺失、缺少防失控保护。原生短板：
- /goal评估器只能读取会话文本，不能独立执行命令；
- /loop会话销毁全部丢失；
- 用户需要手写 Gate 校验、状态文件、子 Agent、终止上限，很容易写出 “自欺式 Ralph‑Wiggum 循环”（Agent 自我判定完成实际没做完）。
绝大多数人对AI循环自动化的理解全是错的
所有人都在追捧AI自动化，觉得只要设置定时任务，让AI重复干活，就是高级循环工程！
这是最致命的认知误区，也是无数人做AI自动化失败的核心原因。
普通的定时任务只是机械重复动作，不会判断结果好坏，不会修正错误，不会保存进度，和真正的Loop Engineering没有半点关系！
传统的AI使用模式，全程离不开人的参与。我们手动输入提示词、等待AI输出、人工检查结果、发现问题再手动改指令、重新执行，人类始终卡在AI工作流程的闭环里，一刻都不能脱身。
哪怕你设置了每分钟、每小时自动触发AI任务，本质还是人工驱动的单次对话叠加，只是省去了手动点击的步骤！
一旦AI输出错误、代码报错、任务卡壳，定时脚本只会无脑重复无效操作，持续消耗算力，完全不会主动终止、复盘、优化，这就是市面上90%自动化AI工具的真实现状！
然而Loop Engineering的核心逻辑完全相反，它彻底把人类从执行循环中剔除，只保留顶层规则设计的权限！
它不靠人监督每一轮执行，不靠人判断结果对错，不靠人接续中断的任务，而是搭建一套完整自运转系统，让AI自主完成执行、校验、纠错、存进度、续任务的全流程！
这也是2026年AI行业最大的范式变革，从人写提示词驱动AI，升级为人设计系统驱动AI自主迭代！
很多人分不清普通定时自动化和循环工程的区别，最终耗费大量时间搭建流程，换来的只有低效重复和算力浪费，这就是行业普遍存在的认知盲区！
还有一类开发者，会直接拿 ZCode 来搭建 AI 循环，他们以为两个工具能实现一样的无人值守效果，但是两者底层的循环架构完全不一样，不能直接互换使用！
ZCode 的循环机制，是把循环逻辑写在脚本代码内部，所有迭代规则硬编码在程序里，一旦你想修改校验标准、调整终止条件，就必须修改源码并且重新部署，灵活性很差。
ECC 完全走了另一条路，循环规则全部放在技能文件和状态账本里，不需要修改底层代码，只需要修改文本配置，就能更换校验闸门、调整迭代上限，这就是二者最核心的区别！
Loop Engineering四层架构，重构AI工作逻辑
想要搞懂ECC的落地原理，首先要吃透AI工程的四层递进架构，这四层架构层层叠加、互不替代，完整定义了AI工作的所有模式。
最基础的一层是提示词工程，它只负责处理单条对话消息，核心解决的问题是我该告诉模型什么内容。这是所有人入门AI都会接触的方式，门槛最低，局限性也最大，每一条指令、每一次调整，都需要人工手动操作，没有任何自主能力。
第二层是上下文工程，它的处理单元是单次会话窗口，核心解决哪些信息需要带入对话、哪些内容需要精简清空的问题。它能优化AI的理解精度，避免上下文冗余导致的输出偏差，但依旧依赖人工开启会话、推进任务，无法脱离人力持续运行。
第三层是调度工程，它的处理单元是单次任务运行，核心定义AI可用的工具、权限范围、任务完成标准。这一层能规范AI的执行行为，减少无效操作，但依旧存在致命短板，单次任务结束就会终止，无法自主开启下一轮迭代，没有持续运转的能力。
最高级的第四层，就是Loop Engineering循环工程，它搭建在调度工程之上，处理单元是持续运转的工作系统，核心解决AI如何无人值守、反复迭代、自主完成复杂任务的问题！
四层架构的核心差异，在于人力参与的程度。前三层所有工作模式，都默认有人守在电脑前指挥AI干活，一旦离开人力，任务就会停滞。
唯独循环工程，彻底推翻了这个前提，它让AI系统拥有自驱动能力，不用人工触发、不用人工校验、不用人工接续，真正实现设计一次，长期运行！更关键的是，四层架构的故障风险完全不同，层级越高，错误的隐蔽性越强，造成的损失越大！
低级的提示词错误，几秒就能发现并修正；上下文和调度的问题，单次任务就能暴露；但循环工程的错误，会在夜间持续累积，一周都未必能被察觉！
这也是为什么绝大多数人做不好AI自动化，只懂底层三层操作，完全不懂顶层循环系统的设计逻辑！
ZCode 也能搭建到第四层循环工程，但是它的状态存储和校验模块耦合在一起，一旦校验逻辑改动，状态读写逻辑也需要同步改动，修改成本很高。
ECC 做了解耦设计，状态账本、触发器、校验闸门、终止条件是四个互相独立的模块，你可以单独替换校验脚本，而完全不改动状态存储的读写逻辑，这让迭代维护轻松很多！
真正AI循环的五大核心必备组件
所有稳定可用的AI自主循环，不管依托什么工具、什么模型，都必须包含五个核心模块，缺一即废，这是Loop Engineering的底层铁律！
第一个模块是触发器，它负责启动每一轮AI任务，常见的触发方式有定时触发、事件触发、手动触发、接口触发。触发器的核心价值，是彻底替代人工启动任务的动作，让系统自主掌控工作节奏，没有触发器，所有自动化都是空谈！
第二个模块是工作执行单元，这是AI的核心干活模块，负责收集任务上下文、调用工具、执行具体操作、获取执行结果。这个模块决定了AI的工作效率，也是我们日常优化AI技能的核心落点，但它只是执行层，无法自主把控任务质量。
第三个模块是校验闸门，这是整个循环工程最关键、最容易被忽略的核心！校验闸门是一套完全客观的判定标准，不依赖AI主观判断，不掺杂人工主观喜好，只以固定结果判定任务是否合格。
代码编译是否成功、测试用例是否全部通过、性能指标是否达标、文件是否无报错，这些客观标准，就是合格的校验闸门！没有校验闸门的AI循环，一定会出现自我欺骗的问题，AI会自我判定任务完成、输出合格，实则产出一堆半成品、错误代码！
第四个模块是持久状态存储，它负责保存每一轮任务的进度、结果、报错信息、待办事项，独立于AI会话之外。普通AI会话关闭后，所有进度、记录都会清零，下次运行只能从零开始，这是传统自动化最大的痛点！持久状态存储可以让AI跨会话接续任务，今天没干完的工作，明天可以精准接续，彻底解决会话清零、进度丢失的问题！
第五个模块是终止条件，包含业务终止标准和硬性上限双重规则。业务终止标准是任务达标就自动停止，硬性上限是最大迭代次数、最大算力消耗，哪怕任务没完成，到达上限也必须终止！没有终止条件的AI循环，一定会陷入无限死循环，整夜疯狂消耗算力，产生巨额账单，这是自动化最常见的重大漏洞！
五个模块协同运转，才是完整的Loop Engineering体系，缺一就会出现自动化失效、算力浪费、产出无效内容的问题！
ZCode 的持久状态，主要保存在程序内存或者数据库中，读取状态需要调用数据库接口，新手配置数据库会增加大量额外工作量。
ECC 直接用本地文件作为状态账本，用 git 管理版本，不需要额外部署数据库，开发者打开项目文件夹，就能直接查看每一轮迭代记录，上手门槛更低！
ECC补齐Claude Code原生循环的致命短板
Claude Code原生自带循环相关功能，包含/goal目标循环、/loop定时循环、钩子触发机制，但原生能力存在大量致命缺陷，完全无法落地生产级自动化！
Claude Code原生的/goal指令，只能依靠模型读取会话文本判断任务是否完成，无法执行真实命令校验，没有客观判定能力！简单来说，原生目标循环的对错，全靠AI自己说了算，很容易出现自我满意、实则出错的情况，也就是业内典型的拉尔夫·威格姆无效循环！
同时，原生/loop定时循环绑定本地会话，电脑关机、会话关闭，所有自动化任务直接终止，根本做不到夜间无人值守运行！
最关键的是，Claude Code原生没有持久化状态存储，所有任务进度、迭代记录、报错日志，全部保存在临时会话中，会话结束直接清零，无法接续迭代！
除此之外，原生循环没有算力管控、迭代上限、卡死检测机制，一旦出现代码死循环、任务卡死，会整夜空跑消耗算力，造成无意义的资金损耗！而ECC（Everything-Claude-Code）的核心价值，就是不改写Claude Code底层能力，只做上层工程化封装，精准补齐所有原生短板！
ECC是适配全AI编程工具的工程化系统，兼容Claude Code、Cursor、OpenCode、Gemini等主流平台，内置完整的循环工程落地模板！它针对Claude Code原生缺陷，做了全方位的能力补强，让原本脆弱的原生循环，变成稳定、可控、可落地的生产级自动化工作流！
ECC首先重构了校验闸门体系，摒弃AI主观判定模式，采用确定性硬校验+独立对抗评审双机制！
一方面自动执行代码编译、单元测试、代码检测、安全扫描等客观命令，以程序退出码作为唯一合格标准，杜绝主观误判；
另一方面启用独立子Agent评审，不用执行任务的AI自查自纠，彻底规避自我美化、自我欺骗的问题！
这一点，直接解决了90%AI自动化产出无效内容的核心痛点！
其次，ECC搭建了专属持久化账本系统，自动将每一轮迭代的进度、报错、修改记录、经验总结，写入本地文件并纳入版本管理！不管会话关闭、电脑重启、跨设备运行，系统都能自动读取历史进度，精准接续未完成的任务，真正实现全天候不间断迭代！同时，ECC新增多层风控机制，设置最大迭代轮次、单日算力上限、单次任务消耗阈值，还能自动检测任务卡死、无进展空转的情况，主动终止异常循环！
这就彻底杜绝了原生循环无限空跑、恶意耗损算力的问题，让AI自动化完全可控！
除此之外，ECC封装了多套成熟的循环工作模板，涵盖顺序流水线、持续PR迭代、多智能体并行开发、CI故障自动巡检等场景！
普通用户无需从零搭建循环架构，直接调用ECC内置技能，两分钟就能落地一套标准的Loop Engineering工作流！
更重要的是，ECC实现了本地循环和云端调度的双重适配，本地/loop负责日常实时任务，新版Hermes Operator云端调度负责关机无人值守任务！完美解决了Claude Code原生循环依赖本地会话、无法离线运行的短板，真正实现人睡觉，AI持续干活的终极自动化效果！
ZCode 也支持多 Agent 并行开发，但它缺少原生的 Git 工作树隔离机制，多 Agent 同时修改同一个仓库文件，很容易出现代码冲突，需要手动编写冲突处理逻辑。
ECC 内置 Git worktree 作为默认隔离方案，每个子 Agent 分配独立工作目录，不同 Agent 的修改天然隔离，合并代码的逻辑直接封装在技能模板里面，开发者不用自己写冲突处理代码！
ECC落地Loop Engineering的四大核心工作模式
ECC基于Claude Code原生原语，封装了四种适配不同场景的标准循环模式，覆盖所有AI自动化开发场景，每一种都对应专属的工程化逻辑。
第一种是回合制循环，适配日常单次迭代优化场景，核心依托Claude Code原生提示词能力+ECC校验技能运行。
这种模式适合需求探索、细节优化类任务，ECC会把人工校验标准固化为标准化技能，每一轮迭代结束后，自动完成端到端校验，杜绝AI提前收尾、敷衍完工的问题。
前端页面优化、代码格式整改、文案迭代优化，都适合用这种轻量循环模式，简单高效、零算力浪费！
第二种是目标制循环，基于Claude Code/goal指令深度优化，适配有明确达标标准的固定任务。
原生/goal只能文本判定，ECC为其绑定了可执行的客观校验规则，比如页面性能分数达标、测试用例全过、代码无报错等硬性条件。
系统会自主迭代、自主纠错、自主判定达标，无需人工干预，适合性能优化、代码修复、功能完善等标准化开发任务！
第三种是时间制循环，优化原生/loop和/schedule指令，适配周期性重复工作。
ECC区分了本地定时和云端定时，本地定时适配电脑开机状态下的高频巡检、代码核查任务，云端调度适配夜间、周末无人值守的周期性工作。
项目依赖巡检、CI故障排查、工单汇总、日志整理，这类重复枯燥的工作，都可以通过该模式完全自动化！
第四种是主动式多智能体循环，这是ECC最高阶的能力，适配复杂大型项目开发。
它整合了云端触发器、目标判定、并行工作区、对抗评审四大能力，支持多Agent分工协作，一个Agent负责开发、一个负责纠错、一个负责安全审计、一个负责结果验收。
同时依托Git工作树实现环境隔离，多个AI同时工作互不干扰，避免代码冲突、文件覆盖的问题，适合大型功能迭代、项目批量优化、全仓库代码整改等复杂场景！
四种模式层层递进，从简单单次迭代到复杂多任务并行，完整覆盖个人开发、团队协作、项目运维的所有自动化需求！
ZCode 的多 Agent 循环，更多是单进程内的任务分发，Agent 之间共享同一个文件环境，一旦某个 Agent 修改全局配置，其他 Agent 会直接受到影响。
ECC 的多智能体循环，每一个 Agent 都拥有独立的工作树，各个 Agent 的文件环境完全隔离，只有到合并阶段才会把变更汇总到主仓库，大幅降低并行开发的风险！
AI循环工程隐藏的四大隐性成本与规避方案
绝大多数人只看到AI自动化省时省力的优势，完全忽略了Loop Engineering背后的四大隐性账单，这也是很多团队自动化落地后反而效率下降、成本飙升的原因！
第一个账单是复核债务，也就是未被及时校验的劣质输出持续堆积！
没有完善校验闸门的AI循环，会不断产出半成品、瑕疵代码、逻辑漏洞，这些问题不会自动消失，只会层层叠加，最后集中爆发导致项目故障！
ECC的规避方案十分清晰，全程采用独立评审Agent+确定性命令校验，每一轮输出必须通过双重校验，才能进入下一环节，从源头杜绝劣质输出堆积！
第二个账单是理解衰减，也就是开发者逐渐脱离项目真实代码逻辑！
AI长期自主迭代项目，开发者不再手动写代码、查报错、改漏洞，慢慢会丧失对项目架构、代码逻辑的认知，最终变成自己项目的旁观者！
ECC自带进度复盘机制，会自动记录每一轮迭代的修改逻辑、踩坑经验、优化思路，生成标准化复盘文档，开发者每周只需简单复盘，就能持续掌握项目全貌！
第三个账单是认知放弃，也就是过度依赖AI，彻底丧失自主判断能力！
长期使用自动化循环后，很多人会无条件信任AI的所有输出，不再主动核查、不再独立判断，一旦AI出现隐蔽错误，就会直接导致项目崩盘！
想要规避这个问题，必须坚守一条核心原则，AI可以接管所有执行工作，但最终决策权永远留在人类手中，关键节点必须人工复核确认！
第四个账单是算力爆炸，也就是不可预测的Token消耗，导致成本失控！
AI循环会不断重试、重读、迭代，遇到复杂问题会无限空转，普通用户没有任何管控机制，月度算力账单会出现断崖式暴涨！
ECC内置全方位成本管控能力，支持自定义单轮算力上限、每日总预算、最大重试次数，提前锁定成本上限，彻底杜绝算力失控问题！
除此之外，ECC还内置安全风控体系，自动完成代码审计、密钥扫描、依赖漏洞检测，避免AI自动化带来的供应链安全风险！
ZCode 同样可以设置 token 预算，但是预算配置写在代码里面，每次调整预算都要修改源码，需要重新部署程序。
ECC 直接把算力预算、迭代上限写在技能配置文件，文本编辑即可修改，不需要重新部署任何程序，调试成本更低！
普通人落地AI循环自动化的最简实操步骤
不用复杂架构设计，不用专业开发能力，普通人按照六步流程，就能用ECC搭建属于自己的稳定AI循环工作流！
第一步，先把人工流程跑通，确保手动操作可以稳定产出合格结果。
自动化的前提是流程可复现，任何不稳定、靠运气的人工操作，都无法实现自动化，先手动完成3-5次完整任务，固化操作逻辑！
第二步，将人工流程封装为标准化ECC技能文件。
把操作步骤、校验标准、注意事项、异常处理方案，全部写入技能文档，让AI可以精准复刻人工操作，避免执行偏差！
第三步，创建持久化状态文件，记录任务进度与迭代日志。
依托ECC状态存储能力，生成项目进度账本，记录每一次执行的进度、报错、优化内容，实现跨会话、跨设备接续任务！
第四步，搭建校验闸门与硬性终止上限。
绑定测试命令、编译校验、性能检测等客观标准，设置最大迭代次数、算力上限，让循环拥有自我纠错、自我终止的能力！
第五步，先本地试运行，再开启云端无人值守调度。
先用本地/loop试运行，观察多轮迭代效果，排查卡顿、报错、无效迭代的问题，流程稳定后，再开启云端/schedule无人值守模式！
第六步，接入独立评审子Agent，完成双层校验闭环。
配置专属评审Agent，采用不同模型、不同校验逻辑，对AI产出内容做二次核查，彻底杜绝自我评审的漏洞！
这套流程完全贴合Loop Engineering核心原理，也是目前行业内最稳妥、零风险的自动化落地方式！
很多开发者会拿这套步骤直接套用到 ZCode，但是第三步和第二步会卡住，ZCode 没有技能文件体系，所有任务规则都要写在代码内，新手很难快速修改任务流程。
ECC 的技能文件就是纯文本 markdown，不用编译，不用写程序，任何人都可以直接修改任务规则，这也是它面向个人开发者最大的优势！
Subagent 目录：让写代码的人和挑刺的人物理隔离
打开 ECC 的仓库，你会看到一个叫 .claude/agents 的文件夹。里面装着一堆 Markdown 文件，每个文件描述一个「子代理」（Subagent，可以理解成一个有专属人格的 AI 分身）。
这里有个反直觉的设计：ECC 不让一个 AI 同时写代码和审查代码。它硬性拆成两个角色，各自有独立的指令、独立的上下文、甚至可以用不同的模型。
写代码的那个叫 developer 或者 coder，它的指令偏向「快速实现、高效试错」。这个角色的目标是把功能跑起来，容忍中间的粗糙。它可能用响应更快、单价更低的模型，因为它要频繁试错，成本必须压住。
审查代码的那个叫 code-reviewer 或者 qa-evaluator，它的指令写得极其苛刻。ECC 会在这个代理的系统提示词里明确写：「预设代码已经损坏，找出所有可能的问题。」它不接受任何「看起来还行」的判断，只接受「运行结果为零错误」的证据。
为什么必须物理隔离？这里有个语言层面的陷阱，值得掰开讲讲。
一个 AI 在写代码的时候，它的上下文窗口里塞满了「为什么这样写」的理由：为什么选这个变量名、为什么用这个循环、为什么忽略那个边界条件。这些理由在生成代码时是合理的辅助信息，但在审查代码时会变成毒药。因为当同一个 AI 回头看自己的代码，它看到的不是代码本身，而是脑子里那份「我当时是这么想的」的记忆。它审查的是「我的意图」，不是「代码的现实」。
这跟人类作家改自己稿子是一模一样的。你写完一段话，重读时脑子里自动脑补出你想表达的意思，看不到读者眼里那段话有多别扭。要真正挑出问题，得请一个从没读过草稿的人来看。
ECC 的双 Subagent 结构，就是把这个「从没读过草稿的人」制度化。审查代理启动时是零上下文，它只看 Git Diff（代码差异），只看测试结果，只看 Linter（代码风格检查工具）的退出码。它不知道也不关心你为什么这么写，它只判断代码有没有问题。
SKILL.md：把「做完了」翻译成机器能验证的动作
光有审查代理还不够。审查代理得有个客观标准，才能判断代码到底行不行。这个标准写在哪里？写在 .claude/skills 文件夹里的 SKILL.md 文件中。
SKILL 是 Claude Code 的一个官方机制，允许你把一套操作流程封装成可复用的技能，就像 Excel 里的宏。ECC 大量使用这个机制，把「什么叫做完」这件事，从模糊的自然语言，翻译成具体的、可执行的步骤序列。
举个例子，ECC 里有个 TDD（测试驱动开发，Test-Driven Development）循环技能，它的核心逻辑长这样：
Markdown
--- |
看到关键点了吗？每一步都能被机器验证。不是「代码看起来对不对」，而是「退出码是不是 0」、「有没有新增告警」、「测试有没有从红变绿」。
这跟很多同类工具的做法完全不一样。以 Cursor 为例，它的对话式编程强调的是「你和 AI 讨论着改」，验证环节主要靠你自己肉眼看。而 ECC 的思路是把验证环节完全交给命令行工具，AI 只是执行者，退出码才是裁判。
这里有个哲学层面的差异值得注意。「做完了」这三个字，在日常语言里是个非常主观的概念。你觉得做完了，我可能觉得没做完，我们各有各的标准。但在 ECC 的世界里，「做完了」有一个铁打的定义：所有指定的验证命令，退出码全是 0。多一个警告都不算做完。
这种把主观判断压缩成客观信号的做法，是 ECC 能实现无人值守的根本前提。
STATE.md：给 AI 装一个外挂脑子
现在你有了自动触发的循环，有了写代码的代理，有了审查代码的代理，有了客观的验证标准。还差一件东西：记忆。
Claude Code 的每一次对话，都有一个上下文窗口。这个窗口是有大小限制的，一般是 20 万 Token 左右，装满了就得清空重来。也就是说，如果你的循环跑了几十轮，中间的历史记录会被逐步挤出去。第 40 轮的时候，AI 已经不记得第 5 轮发生了什么。
这对长周期任务是致命的。假设一个 Bug 修复需要跑 30 轮，AI 在第 10 轮发现了一个关键线索，如果这个线索没被记下来，到第 25 轮就丢了，AI 会重新兜圈子，白白烧掉一堆 Token。
ECC 的解法是外挂状态文件。它规定项目根目录必须有几个特定文件，分别承担不同层级的记忆：
CLAUDE.md 装的是长期规则，比如项目的架构约束、命名规范、绝对不能碰的安全红线。这个文件几乎不改，是所有代理的共同「宪法」。
ACTIVE_PLAN.md 装的是当前任务的战术地图，包括大目标是什么、拆成了哪些阶段、每个阶段的里程碑。这个文件在任务开始时写好，中途不变，用来防止 AI 迭代到第 20 轮时忘了原本要干嘛。
STATE.md 装的是动态状态，也就是「上一轮干了啥、这一轮打算干啥、有哪些遗留问题」。这个文件每一轮都会被更新，是 AI 跨会话记忆的物理载体。
一个典型的 STATE.md 长这样：
Markdown
# Loop state · ci-triage |
这个文件受 Git 版本控制，可以 diff，可以回滚，可以团队共享。它把 AI 的「记忆」从飘忽不定的上下文窗口，搬到了稳定可靠的磁盘上。
跟 Cursor 那种把历史记录塞在对话框里的方式相比，STATE.md 的优势是显著的：它不占上下文窗口，不受 Token 限制，可以被多个 Subagent 共同读写，还能在人类介入时被直接编辑。这就是 ECC 的第二个不可替代之处。
Git Worktree 隔离：并行不撞车的物理保证
讲到这里，你可能会问一个问题：如果 ECC 让 AI 并行跑好几个任务，它们改的是同一个代码库，会不会撞车？
会。而且会撞得很难看。
两个 AI 同时修改同一个文件的同一段代码，就跟两个程序员不打招呼直接往主分支推代码一样，最后必然产生冲突。轻则丢失一部分修改，重则把整个仓库搞成一团乱麻。
ECC 的解法叫 Git Worktree，这是 Git 自带的一个功能，允许你把同一个仓库的不同分支，同时检出到不同的文件夹里。每个 Worktree 都是一个独立的工作区，有自己的文件、自己的分支状态，互不干扰。
具体操作是这样的：ECC 启动一个新任务前，会先运行 git worktree add ../project-fix-auth fix/auth-issue，这会在上级目录创建一个叫 project-fix-auth 的新文件夹，检出 fix/auth-issue 分支。然后这个 Subagent 就只在这个文件夹里干活，跟其他 Subagent 完全隔离。
任务完成后，ECC 会把这个 Worktree 的改动合并到主分支，然后删除 Worktree。如果任务失败，直接删除 Worktree 就行，主分支毫发无损。
这个设计有多重要？我举个例子你就明白了。假设 ECC 启动了三个并行任务：一个在修 A Bug，一个在改 B 功能，一个在优化 C 性能。如果没有 Worktree，三个 AI 挤在同一个工作区，只要有两个改到相邻的文件，就会互相覆盖。有了 Worktree，三个任务在三个物理隔离的文件夹里各干各的，谁失败了都不影响别人。
这跟 GitHub Copilot Workspace 那种「在浏览器里操作虚拟环境」的方式相比，Worktree 的好处是它是本地的、原生的、可调试的。你随时可以 cd 进去看看这个 AI 到底改了啥，甚至手动介入调整。
Headless 模式和调度：让循环真的能通宵跑
前面讲的一切，都还需要一个前提：Claude Code 得能在没有人盯着的情况下跑起来。
这就要用到 Headless 模式（无头模式，指没有交互界面、纯命令行运行的模式）。ECC 在仓库里提供了一批脚本，把 Claude Code 包装成可以被 cron 或者 GitHub Actions（GitHub 的自动化流水线）调用的命令行工具。
比如 ECC 里有个典型的调度脚本，逻辑长这样：
Bash
# 每晚 2 点触发 CI 修复循环 |
看几个关键参数：
--print 让 Claude Code 不启动交互界面，直接执行完退出；
--max-turns 20 硬性限制最多跑 20 轮，防止死循环；
--budget-usd 5 设定单次运行最多花 5 美元 Token，超支自动熔断。
这几个熔断机制，是 ECC 敢让循环通宵跑的底气。没有这些熔断，一个逻辑错误就能让 AI 在夜里疯狂重试，早上你收到的不是修好的代码，而是一封几百美元的账单。
跟 Aider（另一款开源 AI 编程工具）这类工具相比，ECC 的调度配置是内置的、成体系的，而不是让用户自己拼凑 Shell 脚本。这大大降低了「循环工程」的落地门槛。
一次完整的夜间循环：从触发到收工的 6 小时
讲了这么多组件，来看一次真实的循环怎么跑完全程。
场景：某创业公司的后端仓库，晚上 10 点关灯下班，第二天早上 9 点上班。ECC 在这 11 个小时里做了什么？
晚上 10 点 30 分，cron 触发第一轮循环。ECC 读取 CI 系统的错误日志，发现有 5 个测试失败，涉及 3 个不同模块。它按模块分组，创建 3 个 Git Worktree，每个 Worktree 对应一个 Subagent。
11 点，第一个 Subagent 在处理认证模块的 Bug。它调用 tdd-cycle 技能，先写了一个复现 Bug 的测试，跑了一下，红灯确认。然后开始改代码。
12 点，认证模块的代码改完了，测试从红变绿。这时候审查代理启动，用一个完全干净的上下文，审查这份 Diff。它调用 Playwright（浏览器自动化测试工具）实际打开登录页面，点了一次登录按钮，截图对比，检查 Console 有无新增错误。
12 点 15 分，审查代理发现修复没有覆盖 Token 过期的边界情况，一票否决，退回给写代码的代理。
凌晨 1 点，写代码的代理补齐边界逻辑，再次提交。审查代理这次通过。ECC 把这个 Worktree 的改动整理成 PR，推送到 GitHub，同时更新 STATE.md，记录下这个任务已完成。
凌晨 2 点到 4 点，第二个 Subagent 处理数据库模块的 Bug。中间经历了 4 轮红绿循环，最终失败——因为这个 Bug 涉及生产环境的数据迁移策略，AI 判断不了该用哪种方案。ECC 触发升级机制，把这个任务写进 STATE.md 的 Escalated 区域，标记为「需要人工决策」。
凌晨 5 点，第三个 Subagent 处理支付模块的 Bug。这个 Bug 比较简单，一轮就修好了，PR 顺利推送。
早上 9 点，你打开电脑，看到 GitHub 上有 2 个待审的 PR，STATE.md 里有 1 个升级到人工的任务。你花 30 分钟看完 PR 点了 Approve，花 1 小时思考那个升级任务的方案。原本 3 小时的活，压缩到 1.5 小时。
这个循环里，最关键的一步是凌晨 2 点到 4 点那个失败的任务。ECC 没有硬撑着让 AI 瞎改，而是识别出边界并主动升级。这个「知道自己不知道」的能力，是很多同类工具做不到的。
为什么 ECC 敢让 AI 自我审查而 Cursor 不敢
到这里，你可能已经看出 ECC 跟主流 AI 编程工具的核心差异了。
Cursor、Windsurf、GitHub Copilot 这类工具，本质上还是「你 + AI」的协作模式。你敲一下，它响一下。你不敲，它不动。它们不做「AI 自己给自己打分」这件事，因为一旦这么做，主观判断的偏差会立刻暴露。
ECC 敢做，是因为它想清楚了两件事：一是绝不让写代码的 AI 自我评估，必须用独立的审查 Subagent；二是审查的标准必须是命令行退出码，不能是 AI 的主观描述。
这两个约束合在一起，就构成了 ECC 最不可替代的机制：结构化的对立审查。写代码的角色和审查代码的角色，在指令、上下文、模型、验证工具上全部隔离，形成一个类似银行「双人复核」的制衡结构。
这个机制的价值，在长周期任务里会指数级放大。跑一轮循环，双方对立的价值有限。跑 30 轮循环，如果每一轮都让同一个 AI 自我评估，误差会累积到不可收拾的程度。而 ECC 的对立结构，每一轮都在压制这种累积。
有人会问，那我用 Cursor 手动做双 Agent 审查不行吗？理论上行，实际上非常痛苦。你得手动开两个对话窗口，手动复制代码过去，手动比对反馈，手动更新状态。这种手动流程根本没法长期维持，两天你就放弃了。ECC 的价值就在于把这个流程从「你的手」里彻底解放出来，塞进配置文件，一次配置永久使用。
三条你今晚就能落地的行动
讲了这么多，最后落到你能干什么上。
你要做的第一件事，是打开你自己的项目，找出那件每天早上都要重复干的活。可能是 CI 修复，可能是依赖升级，可能是文档同步。挑一件重复了至少一个月的，写下来。这件事必须满足两个条件：一是有客观的验收标准（能用命令行判断成没成），二是失败了不会毁掉生产环境。
你要做的第二件事，是照着 ECC 的目录结构，在你的项目里建一个 .claude 文件夹，先做最简版本：一个 CLAUDE.md 装项目规则，一个 SKILL.md 装那件重复工作的操作步骤，一个 STATE.md 装当前状态。先不搞 Subagent，也不搞 Worktree，就用最原始的 Claude Code 命令行手动跑一次，跑通了再自动化。
你要做的第三件事，是在跑通手动流程之后，加上一个审查 Subagent。它不需要多复杂，就一个要求：预设代码是坏的，找出所有问题，找不到问题就用工具运行代码看退出码。这一个 Subagent 加进去，你的循环就从「AI 单打独斗」升级到了「AI 自我制衡」。
跑通这三步，你就已经在做循环工程了。至于要不要用完整的 ECC 仓库，那是后话。核心的思维方式，比任何具体工具都重要。
顺便说个还没有定论的事：ECC 目前对 Anthropic 之外的模型支持有限，因为它深度依赖 Claude Code 的 Subagent 和 SKILL 机制。有社区讨论说要不要出一个模型无关的版本，用 LiteLLM（一个多模型统一接口的开源库）做适配层，但目前还没落地。也就是说，如果你想用 GPT 或者 Gemini 跑同样的循环，暂时得自己动手改。这个坑什么时候能填上，仓库的 Issue 区里还在吵。
AI循环工程的终极真相
所有AI自动化工具，本质都是能力放大器，而不是能力替代者！
ECC可以完美补齐Claude Code的循环短板，搭建稳定、高效、可控的无人值守AI工作流，帮你省去80%的重复机械工作，让AI整夜自主迭代优化！
但ECC和Loop Engineering永远无法替代人类的核心价值！
AI可以无限迭代、无限试错、无限产出内容，但它只能基于现有规则执行，无法判断方向对错、无法权衡业务价值、无法规避深层风险！
你设计的循环规则、校验标准、风控边界，最终决定了AI自动化的上限，这也是AI时代开发者不可替代的核心竞争力！
无数人盲目跟风搭建AI自动化循环，却不懂底层工程逻辑，最终要么无效空转、要么成本失控、要么产出劣质内容！
真正的AI自动化革命，从来不是让AI代替人干活，而是让人从重复劳动中彻底解放，专注做AI做不到的决策、设计、创新工作！
2026年AI行业的核心差距，早已不是会不会用AI，而是会不会设计AI自主运转的循环系统！
很多开发者测试ECC循环时，都遇到一个奇怪现象，校验脚本全部通过，合并代码上线之后，线上依旧爆出隐藏bug，这个矛盾至今没有简单统一的解释。