给 AI 编程助手装一套工作流程:ECC 的用法与边界

用 AI 写代码，最烦人的事情之一，是反复交代同一套要求。

先看项目里有没有现成实现，别急着新建工具函数；改逻辑前补测试；写完跑检查；这次踩过的坑，下次别再踩。

每句话都合理，但把它们塞进一次对话，并不等于助手以后就会照做。换个会话，规则可能丢了；任务一长，前面的约束也可能被忽略。

awe0 在 X 上推荐的 ECC，讨论的就是这类问题。推文提到技能、本能反射、长期记忆和安全机制。听起来像给 AI 升级了大脑，实际上更值得看的，是它怎样组织模型之外的工作流程。

这篇文章不比较模型能力，也不把 Star 数当成效果证明。我们沿着一次代码修改，看看 ECC 能补上什么，以及哪些事情仍然要自己把关。

一、ECC 放在模型外面，管的是怎么干活

先解释一个词：Agent Harness，可以理解为智能体执行任务的配套环境。模型负责理解和生成，外面的系统则负责工具调用、上下文、权限、检查与状态保存。

ECC 是围绕这些环节组织起来的一套开源工程工具与工作流，采用 MIT 协议。它依附于已有编程助手工作，不是新的基础模型，也不意味着装好后就能无人值守交付软件。项目目前明确说明，Claude Code 是支持较完整的路径，其他工具的适配能力不能默认等同。

理解它，可以先看四类东西：

这些组件可以在仓库的rules、skills、agents和hooks中分别查看。

这里最需要分清的是：模型看到一条规则，与程序真正执行了一次检查，是两回事。

例如“提交前检查代码”是一项要求。钩子实际触发检查、读到错误并按配置阻止提交，才形成了执行约束。但如果钩子只是输出提醒，助手仍可能继续；项目缺少测试脚本，ECC 也不能凭空补出可靠的验收标准。

二、先看一条工作链路，别急着翻完整目录

下面用一个教学场景说明：订单导出接口在没有数据时抛异常，需要改为返回空列表。它不是本文的实测项目，目的是展示如何使用 ECC 的工作流。

先确认问题和已有实现

收到需求后，先找导出接口、错误处理和相近测试，确认“空列表”是否符合现有接口契约。不要直接让助手重写整个导出模块。

ECC 的 search-first 技能强调编码前调研：先明确需求和约束，查找可复用工具或实现，再决定采用、扩展还是自建；搜索渠道不可用时，要明确说明缺了哪部分调查。

对这个小修复，查清项目里的现成模式通常比广泛搜索新依赖更重要。不要为了“走完流程”，给一个简单条件分支引入新框架。

把验收条件写进计划

通过插件安装后，可以在 Claude Code 会话中使用这样的入口：

/ecc:plan 修复订单导出接口在无数据时抛异常的问题，预期返回空列表；保留现有鉴权与正常导出行为，先给计划，不修改业务代码。

plan 的工作是澄清需求、查找代码中的相近模式、列出改动与风险，然后等待确认。当前命令默认可以直接在会话内规划，并不要求必须启动一个规划子智能体。

这一阶段最值得人工确认的是接口契约：究竟应该返回空数组、空文件，还是业务提示？如果这里判断错了，后面的测试越完整，只会把错误需求固定得越牢。

先看到测试失败，再接受修复

确认计划后，让助手使用 tdd-workflow，即测试驱动开发工作流。

在这个例子里，应先加一条“无订单时返回空列表”的测试，实际运行并看到它因当前缺陷失败。随后做最小修复，再运行同一个测试，确认它通过，最后检查正常导出和鉴权是否回归。

ECC 的这份技能要求保留 RED（失败）与 GREEN（通过）的证据。仅仅写好测试文件，或者因为缺依赖而运行失败，都不能算有效的缺陷复现。

它带来的实际变化，是你可以追问：哪条测试证明了原问题？修复前后执行了什么？而不必只接受一句“已经修好”。

交付时看报告，也看报告没覆盖什么

接下来可以使用 verification-loop 做交付验证。它把检查拆成构建、类型检查、代码规范检查、测试与覆盖率、安全检查、差异审查，并输出结果。

命令必须适配项目。仓库没有配置覆盖率脚本，就应报告“未运行及原因”，不能为了凑齐报告编一个通过结果。基础安全扫描也不能替代完整安全审计。

对这个示例，合格的交付至少应说明：改了哪些文件，原缺陷如何复现，修复后哪些检查通过，还有哪些路径未验证。涉及重要业务时，仍要保留人工代码审查和持续集成检查。

三、“本能”和“记忆”究竟记住了什么

推文里最容易让人产生想象的，是“本能反射”。

ECC 的 continuous-learning-v2 文档把 Instinct 描述为一条小型行为记录：包含触发条件、动作、置信度、来源证据和适用范围。它通过会话观察提取重复模式，再把相关模式整理成更完整的技能或其他工作单元。

举个假设：你多次纠正助手，说明当前项目新增接口必须走统一错误处理中间件。系统可以把这一模式整理为候选经验，供后续任务使用。

这不是更新模型权重，也不能把置信度理解成正确概率。一次特殊处理可能被误学成普遍约定，旧项目的经验也可能不适合新项目。因此，项目级隔离、人工检查和过期清理都很重要。

另一类记忆解决的是任务交接。

ECC 的 unified-memory 使用本地 Markdown 保存可检查的上下文，让不同会话或工具交接进展。例如记录“修复已完成，回归测试通过，但上线审批尚未完成”，比保存整段聊天更容易接着干活。

不过，安装技能或 Claude 插件，并不自动意味着 Memory Vault 的命令行运行时已经可用；相关运行时需要单独安装。记忆内容也应视为未经复核的上下文，重要结论要回到代码、测试和正式文档确认，不能因为“以前记过”就直接升级成项目规则。

会话观察还涉及数据边界。启用前要检查记录哪些提示与工具信息、保存在哪里、谁能读取；团队记忆尤其不能混入密钥、客户数据或私人对话。

四、第一次接入，先跑通一个小任务

如果你已经在使用 Claude Code，可以从测试项目或可恢复的分支开始。先备份已有助手配置，查看安装器将写入的范围，再决定是否确认。

按 2026 年 11 月 1 日核对的项目 README，示例安装路径要求 Node.js 18+、Git 和 Claude Code 2.1+，当前列出的固定版本入口是：

node --versiongit --versionclaude --versionnpx ecc-universal@2.2.3 setup

安装完成后，开启新的 Claude Code 会话，执行 /plugin list，确认 ecc@ecc 已启用。固定版本便于复现，但不等于经过安全审计；运行前仍需核对官方来源与版本。

不要把插件安装和一整套手工配置叠加使用，也不要刚装好就导入所有规则、连接全部外部工具。先用上面的修复流程，确认计划、测试和验证确实能工作。

Codex、Cursor、OpenCode 用户则应先查对应适配说明，不能把这里的 Claude Code 命令和钩子行为原样照搬。

安全方面，ECC 提供了基于 AgentShield 的配置扫描，检查范围包括提示文件、权限设置、MCP 配置、钩子和智能体定义。MCP 是让助手连接外部工具与数据的协议，这些连接本身也需要审查。

这类扫描有助于发现风险，但不是隔离沙箱。安装代码、连接服务、允许写文件和执行命令，仍然需要明确授权。

结语：先检查流程有没有留下证据

ECC 更适合已经反复使用 AI 编程、开始被流程不稳定拖累的人。如果你只是偶尔改一段脚本，几条清晰规则和可靠测试可能就够了。

第一次尝试，不必以“装了多少技能”为目标。选一个能复现的小缺陷，看看助手能否先解释计划，留下失败测试，完成最小修复，并如实报告验证结果。

如果这些环节确实减少了返工，再逐步加入记忆与自动检查。多了一套配置，也就多了一套需要维护的系统；它得用真实任务的结果来证明价值。

参考资料

• awe0 的 ECC 推荐推文

  https://x.com/awe0_io/status/2116146779746107486

• ECC 官方仓库与安装说明

  https://github.com/affaan-m/ECC

• 编码前调研 search-first

  https://github.com/affaan-m/ECC/blob/main/skills/search-first/SKILL.md

• 测试驱动开发 tdd-workflow

  https://github.com/affaan-m/ECC/blob/main/skills/tdd-workflow/SKILL.md

• 交付验证 verification-loop

  https://github.com/affaan-m/ECC/blob/main/skills/verification-loop/SKILL.md

• 持续学习 continuous-learning-v2

  https://github.com/affaan-m/ECC/blob/main/skills/continuous-learning-v2/SKILL.md

• 统一记忆 unified-memory

  https://github.com/affaan-m/ECC/blob/main/skills/unified-memory/SKILL.md