从 Vibe Coding 到 Harness Engineering：GitHub 195k ECC (Everything Claude Code) 项目详解

摘要：AI 辅助编程已经从"试试看能不能跑通"进入"需要可持续的工程质量"阶段。Claude Code 通过 Hook、Subagent、Skill、Rules、MCP、Plugin 等九种扩展机制，为开发者提供了一套完整的可编程接口。本文将这一方法论定义为 Harness Engineering——将工程纪律（安全检查、代码规范、测试流程、知识复用、跨会话记忆）编码为 AI 助手可执行的系统化行为。我们以 ECC（Everything Claude Code）为参考实现，拆解它如何用 61 个 Subagent、246 个 Skill、45 个 Hook 和一套 SQLite 状态存储，将 Claude Code 从一个"好用的命令行工具"升级为团队级工程底座，并从中提炼出四条可直接迁移到任何项目的实践原则。

来自 Anthropic 黑客马拉松获胜者的完整 Claude Code 配置集合。

版本说明：本文中 ECC 的组件数量（61 个 Subagent、246 个 Skill 等）和具体实现细节均基于 v2.0.0-rc.1 版本，后续版本可能有所变化。Claude Code 扩展机制的行为描述基于 2026 年 5 月的官方文档。

项目地址：https://github.com/affaan-m/ECC#

1. 引言：从 Vibe Coding 到 Harness Engineering

"Vibe Coding"和"Harness Engineering"代表了 AI 辅助编程的两种范式——前者依赖人类的即时判断和口头提醒，后者将工程纪律编码为 AI 的系统化行为。本章先拆解 Vibe Coding 在规模扩大后的四类失效模式，再给出 Harness Engineering 的定义和四条核心主张，最后介绍 ECC 作为参考实现的定位。

1.1 Vibe Coding 的困境

"Vibe Coding"——凭感觉编程，对着 AI 助手描述需求，看它生成代码，跑通了就提交，跑不通就换个说法再试。这种工作方式在原型阶段效率极高：一个下午能出三个 MVP 候选，每个都"看起来能跑"。

但当项目超过 2000 行、团队成员超过 3 人、或者代码需要维护超过两周时，Vibe Coding 的裂缝开始显现：

• • 每次对话从零开始。上次的技术决策、踩过的坑、选型理由全部丢失，每轮对话开头都要重复上下文。
• • 工程质量靠人肉记忆。"别忘了写测试""别用 var""提交前跑一遍 lint"——每次口头重复，漏一次债就累积一次。
• • 安全审查形同虚设。催促 AI "快把功能做出来"时，它不会主动提醒 SQL 注入风险或 OAuth redirect_uri 白名单校验。
• • 知识无法跨项目复用。项目 A 的 Django 最佳实践、项目 B 的数据库迁移教训，到了项目 C 归零重来。

这些问题的本质不是 AI 不够聪明，而是工程纪律没有被系统化。在传统软件工程中，我们通过 CI 流水线、code review 制度、编码规范文档、on-call 手册等方式把纪律固定下来。但在 AI 辅助编程中，我们把这些全部交给了人类的自觉性——每次对话手工提醒、每次提交手工检查。

1.2 Harness Engineering 的定义

Harness Engineering 是这一问题的解。它的核心思想很简单：将工程纪律编码为 AI 助手可执行的系统化行为。

• • 不是"每次提醒 AI 不要用 var"，而是把这条规则写入 Rules，让 AI 每时每刻都能看到。
• • 不是"手工审查每个 PR 的安全风险"，而是定义 security-reviewer Subagent，在提交前自动启动独立审查。
• • 不是"记下这次的决定下次再说一遍"，而是 Stop Hook 自动保存关键决策，SessionStart Hook 自动恢复。
• • 不是"每次新项目重新配置一遍"，而是打包成 Plugin，一键安装，全团队共享。

"Harness"一词在英语中本义为马具或安全绳——将力量转化为可控的、定向的运动。软件工程中已有类似隐喻：CI/CD harness 指构建和测试的自动化承载框架，test harness 指测试的自动化执行环境。Harness Engineering 延用这层语义：将 AI 助手这个"力量源"纳入可控的工程框架中，让它不仅强大，而且可预测、可审计、可持续。

Harness Engineering 和传统 DevOps 在方法论上是同构的：把人的判断变成机器的执行，把一次性操作变成可复用的流水线，把隐性知识变成显性规则。区别只在于操作的对象——传统 DevOps 操作的是容器、网络、部署脚本；Harness Engineering 操作的是 AI 的上下文、工具调用、知识注入和工作流编排。

在概念地图上，它与几个相邻术语的区分是：Prompt Engineering 关注单次对话的提示词设计，Harness Engineering 关注系统化的行为编码；AgentOps 关注智能体在生产环境中的监控与运维，Harness Engineering 关注开发阶段的质量保障；LLMOps 关注模型的训练、部署和版本管理，Harness Engineering 在模型之上的应用层操作。简言之，如果 LLMOps 是"管模型的"，AgentOps 是"管智能体运行时的"，Harness Engineering 就是"管 AI 怎么干活的"。

1.3 ECC 作为 Harness Engineering 的参考实现

ECC（Everything Claude Code）是目前 Harness Engineering 在 Claude Code 生态中最完整的参考实现。它是一个 MIT 开源的 Claude Code 插件，包含 61 个专业 Subagent、246 个 Skill 定义、45 个 Hook 脚本、76 个 Command shim 和 12 种语言的 Rules 集合。它的核心贡献不是单个功能有多好用，而是系统化地展示了如何用 Claude Code 的扩展机制把一套完整的工程纪律编码进 AI 助手的"本能"。

本文以 ECC 为例，先梳理 Claude Code 的扩展机制全景（背景），再介绍 ECC 解决了哪些问题（What），然后逐一解释 ECC 如何用这些机制实现每个功能（How），最后提炼四条可供任何项目直接应用的 Harness Engineering 实践原则。

2. Claude Code 的扩展体系

要理解 ECC 如何工作，首先需要理解 Claude Code 提供了哪些"积木"。这些机制本身不构成 Harness Engineering——它们只是接口。关键在于知道每种机制解决哪类问题，才能在第 4 章中看清 ECC 的组合逻辑。

Claude Code 不是黑盒。它提供了 9 种第三方可扩展的机制，按功能层级可分为五类：

2.1 Hook：在工具调用链上注入自动化

Hook 是 Claude Code 的事件驱动拦截器。每当 Claude Code 准备执行或完成一个工具调用（Read、Edit、Bash），Hook 引擎在对应的生命周期节点上执行开发者预定义的脚本，根据退出码决定是否继续。

可拦截的事件覆盖一次工具调用的完整生命周期：PreToolUse（工具调用前，可阻断）、PostToolUse（调用成功后，自动格式化、日志记录）、SessionStart（新会话启动，注入历史上下文）、Stop（会话结束，保存状态）、PreCompact（上下文压缩前，提取关键决策）、Notification（外部通知到达，如 CI 完成、PR 更新）。

Hook 脚本通过 stdin 接收 JSON 载荷，通过 exit 0（放行）或 exit 2（阻止并通知模型调整行为）表达决策。关键约束有三条：阻断型 Hook 必须在 200ms 内完成；非关键错误必须 exit 0 放行；避免网络调用。

2.2 Subagent：让 AI 学会"分工"

Subagent 是带有独立工具权限、独立系统提示词和可选独立模型的子智能体。主会话将任务委派给 Subagent 在独立上下文中执行，然后回收结果。它解决了 AI 对话中两个核心矛盾：上下文窗口有限（200K 会被海量知识撑爆）和泛化与专精的矛盾（一个通用助手无法在所有领域都做出专业判断）。

Subagent 以 Markdown 文件定义（agents/ 目录），YAML frontmatter 声明名称、描述、工具权限（tools: Read, Grep, Glob, Bash）和可选模型（model: opus）。tools 字段决定了 Subagent 的能力边界——审查者只能读代码不能改，避免了"边审边改"的混乱。

2.3 Skill：可复用的知识与工作流

Skill 是 Markdown 格式的领域知识包，本质是 prompt 编排 + 操作手册。它告诉 Claude Code "什么时候该用、怎么做、做出来应该什么样"。Skill 不会创建新上下文——它被注入到当前会话，为主会话或 Subagent 提供知识和操作指南。

Skill 有两种加载路径：Claude Code 在会话开始时扫描所有 Skill 的 description 字段，当用户请求匹配时自动引用；用户也可以通过 /skill-name 显式激活。

一个关键区分：需要"按清单做"用 Skill，需要"换个人做"用 Subagent。同样是审查 PR 安全风险，Skill 在当前会话中逐项对照 OWASP 检查清单，过程可见；Subagent 让独立的安全专家完整审查后返回报告，过程黑盒。

2.4 Rules：始终生效的行为约束

Rules 是存放在 .claude/rules/ 中的 Markdown 文件，在每次会话启动时无条件完整加载到系统提示词中。与 Skill 的"按需匹配"不同，Rules 不依赖触发——它始终在那里，AI 每时每刻都能看到。

直觉区分：Skill 是工具箱里的工具（需要时才拿出来用），Rule 是写在墙上的守则（一直看得见，不得不遵守）。"永远不要用 var"是 Rule 的典型案例——简单、不可协商、每次都要遵守。"怎么写 TDD 工作流"则适合 Skill——内容复杂，只有需要时才加载。

2.5 MCP、LSP 与 Plugin

MCP（Model Context Protocol）是 Anthropic 定义的开放协议，让 LLM 应用安全地调用外部工具和数据源。通过 .mcp.json 配置，Claude Code 启动时拉起 MCP Server 进程，将其 tools 注入 LLM 的工具列表——LLM 可以像调用内置工具一样调用 GitHub API、数据库、搜索引擎等外部服务。一个关键约束：保持活跃 MCP tool 总数少于 80 个，超出会严重挤占上下文窗口。

LSP（Language Server Protocol）是 IDE 生态的标准协议。截至本文撰写时（2026 年 5 月），Claude Code 通过 .lsp.json 配置文件支持连接已有的 Language Server（如 typescript-language-server、gopls、rust-analyzer），获得编译级别的代码语义理解——跳转到定义、查找引用、诊断类型错误。与 MCP 提供"外部工具"不同，LSP 提供的是"代码本身的语义信息"。

Plugin 是上述所有机制的打包与分发载体。一个 Plugin 就是包含 plugin.json 清单和对应组件目录的文件夹，用户通过 /plugin install 一键安装，组件自动注册。Plugin 解决的是"怎么分享"，而 Hook/Skill/Subagent/MCP 解决的是"具体做什么"。

附注：Commands 是 Claude Code 最早期的斜杠命令机制（commands/*.md），已被 Skill 取代。新开发直接用 Skill 格式，Commands 仅为存量兼容。

3. ECC 全景：Harness Engineering 的参考实现

ECC 正是基于上述九种 Claude Code 扩展机制构建的完整工程底座。它本质是一套 Claude Code 插件，但更重要的是它展示了如何将这些"积木"组合成系统化的工程纪律。

3.1 ECC 是什么

ECC（Everything Claude Code）是一个 MIT 开源的 Claude Code 插件（npm: ecc-universal，市场标识: ecc@ecc，版本 2.0.0-rc.1）。它的核心差异化不在于组件数量，而在于三个独特的架构设计：

• • 选择性安装引擎：通过 manifest 驱动的两阶段流水线，按需将组件分发到 11 种 AI harness 目标，而非全量塞入用户目录。
• • Hook 运行时 profile 分级：minimal/standard/strict 三级控制 Hook 执行范围，用户按场景选严格度，无需编辑配置。
• • 技能进化流水线：从 Hook 观察采集 → Subagent 后台分析 → 评估晋升 → 版本管理的自动化闭环，让一次性经验沉淀为可复用知识。

3.2 ECC 解决的四类问题

ECC 能力可以归纳为四类，每类对应一组 Harness Engineering 的核心诉求：

3.3 一个场景：安装 ECC 前后的日常开发流

用一个 TypeScript 项目的一天，对比装上 ECC 前后的变化。

安装 ECC（30 秒）：

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc
mkdir -p ~/.claude/rules/ecc
cp -r rules/common ~/.claude/rules/ecc/
cp -r rules/typescript ~/.claude/rules/ecc/

安装完成后，ECC 的 61 个 Subagent、246 个 Skill、45 个 Hook 和 Rules 即处于可用状态。Skill 和 Subagent 由 Claude Code 自动发现并注册，Hook 在对应事件触发时自动执行，无需额外配置。

装上之前：

早上：打开 Claude Code，继续昨天的登录功能开发。

  你："还记得上次我们在 login.ts 里做的改动吗？"
  Claude Code："抱歉，这是新会话，我没有上次对话的上下文。"
  你：（翻 git log）"...我们改了 OAuth token 的存储方式，用了 PKCE 流程"
  Claude Code："好的，我已了解。需要我做什么？"

  你："给 login 加个新功能：支持 Google OAuth"
  Claude Code：“好的。” 开始写代码。它用了 `var oauthConfig = ...`。

  你："别用 var！用 const。还有，写之前先写测试。"
  Claude Code："明白。" 补了一个测试，修了 var。

  你："审查一下安全性"
  Claude Code：（在当前会话中）"看起来没问题，token 存入了 localStorage。"
  你：（自己查了一下）"localStorage 有 XSS 风险，应该用 httpOnly cookie。改掉。"
  Claude Code："已修正。"

晚上：你关掉终端。什么都没留下。明天又是新的一天，又从 "你还记得..." 开始。

装上之后：

早上：打开 Claude Code，继续昨天的登录功能开发。

  SessionStart Hook 自动读取上次的会话摘要，注入系统提示词。
  Claude Code 已经知道：login.ts 用 PKCE 流程、OAuth token 存 httpOnly cookie、团队禁止 var。

  你："给 login 加个新功能：支持 Google OAuth"

  Rules 无条件生效 → Claude Code 自动用 const，没有 var。
  Skill 自动匹配 tdd-workflow → Claude Code 先写 describe('GoogleOAuth', ...)，确认测试失败。
  Hook 拦截 PreToolUse(Bash: npm test) → 安全性检查通过，放行。测试通过后，Hook 自动格式化代码。

  你："审查一下安全性"
  Claude Code 委派 security-reviewer Subagent（Opus，只读权限）。
  security-reviewer 在自己的上下文中审查 → 返回："Google OAuth 的 redirect_uri 需要白名单校验，当前接受任意 URI。"

  你："修掉。"
  Claude Code 修改代码。PostToolUse Hook 再次自动格式化。PreToolUse Hook 检测到首次编辑 auth.ts → GateGuard 阻断，要求先调查 import 链和数据 schema → 确认理解正确后放行。

晚上：你关掉终端。
  Stop Hook 提取今天的决策："Google OAuth 采用授权码模式，redirect_uri 必须白名单校验" → 写入 SQLite。
  明天早上，Claude Code 自动知道这些。你不用再说一遍。

两栏对照下来，同一个 "加 Google OAuth 支持" 的任务，Vibe Coding 版本有 3 次人肉纠正，且 redirect_uri 白名单校验这个安全隐患完全未被发现；Harness Engineering 版本纠正次数为 0，且 security-reviewer 自动发现了该隐患——所有纪律都由 Rules、Hooks、Skills、Subagents 自动执行。

4. ECC 如何基于 Claude Code 扩展机制实现

ECC 的六个关键子系统覆盖了 Harness Engineering 的完整链路：Hook 门控（4.1）提供运行时基础设施，选择性安装（4.2）解决分发问题，智能体编排（4.3）实现任务委派，技能进化（4.4）让经验沉淀为可复用知识，记忆管理（4.5）架起跨会话的连续性，安全门控（4.6）在工具调用前后建立多层防线。每个子系统都回答了同一个核心问题：用了 Claude Code 的哪个机制、具体怎么用的。

4.1 Hook 运行时门控：用 profile 分级管理 Hook 行为

用到的 Claude Code 机制：PreToolUse、PostToolUse、Stop、SessionStart、PreCompact Hook 事件。

ECC 的实现：ECC 的 45 个 Hook 脚本不是直接挂在 Claude Code 的 Hook 事件上的。它们统一通过 run-with-flags.js 门控包装器执行。

Claude Code Hook 事件 → plugin-hook-bootstrap.js → run-with-flags.js → 具体 Hook 脚本

这个门控层提供了三个核心能力：

1. 1. Profile 分级。通过 ECC_HOOK_PROFILE 环境变量（minimal/standard/strict）控制 Hook 执行范围。minimal 下只运行内存持久化和基础格式检查，strict 下额外开启 gateguard fact-forcing 和 governance capture。用户根据自己的场景选择严格度，不需要编辑 Hook 配置。
2. 2. 按 ID 禁用。通过 ECC_DISABLED_HOOKS=pre:bash:tmux-reminder,post:edit:typecheck 精确禁用某个 Hook，而不影响其他。
3. 3. 性能优化。门控器检查 Hook 脚本是否导出 run(rawInput) 函数——如果是，通过 require() 直接内联调用（节省约 50-100ms 的子进程启动开销）；如果不是，降级到 spawnSync 子进程方式。无论哪种路径，门控器永远 exit 0 以避免阻塞用户操作。

设计启示：Hook 不是越多越好。ECC 的 profile 分级模式提供了一种"可控的激进"——默认只开核心 Hook，需要时逐步升级到 strict。任何项目都可以借鉴这个模式：先用 minimal 解决"无记忆"的基本问题，确认稳定后再叠加格式化和安全检查。

4.2 选择性安装引擎：manifest 驱动的两阶段安装

ECC 的选择性安装引擎基于 Claude Code 的 Plugin 打包分发机制（plugin.json + marketplace.json），但更进一步：ECC 不是把所有 246 个 Skills 一股脑塞进用户目录，而是实现了一套 manifest 驱动的两阶段安装流水线：

1. 1. 计划阶段（install-plan.js）：读取 manifests/install-modules.json（将 246 个 Skills 按 baseline/language/framework/capability/agent/skill/locale 七大家族分类），解析用户选择的 profile 或模块组合，计算出哪些文件需要复制到哪个目标路径。
2. 2. 执行阶段（install-apply.js）：根据计划执行文件复制，写入 install-state JSON 记录安装状态，支持 --dry-run 预览和 --json 机器可读输出。

这套引擎同时支持 11 个 AI harness 目标（Claude Code、Cursor、Codex、OpenCode、Gemini、Copilot 等），每个目标通过 scripts/lib/install-targets/ 下的适配器处理路径映射差异。

设计启示：不要把扩展组件当作"全集安装或全不安"的二选一。ECC 的选择性安装意味着一个新用户可以只安装 TypeScript 相关的 Rules 和 Skills，而一个 Django 用户可以在不触碰 Rust 审查员的情况下获得完整 Django 工作流支持。在自己的项目中，你可以用同样的 manifest 思路管理 Skills 和 Rules。

4.3 智能体编排：61 个专业 Subagent 的树形委派

ECC 的 61 个 Subagent 直接基于 Claude Code 的 Subagents 机制（agents/*.md 定义文件），但在组织和委派模式上做了系统化设计。它们按功能分为七类：

表格仅列代表，ECC 实际包含 61 个 Subagent，覆盖 TypeScript、Python、Go、Java、Kotlin、Rust、C++、Swift、F#、PHP、Perl、HarmonyOS 等 12+ 语言和框架。

每个 Subagent 的 tools 字段精确限定权限：审查员只能 Read/Grep/Glob/Bash（不能 Edit），确保"审查者不碰代码"。

委派采用树形结构：主会话将需求交给 planner 分解为任务列表 → planner 分别调用 architect（设计决策）和对应语言的审查员 → 审查结果汇总给用户。子任务在独立上下文中执行，互不干扰，也互不污染主会话的上下文。

设计启示：Subagent 的价值不只是"换一个 prompt"，而是上下文隔离和权限最小化。为每个 Subagent 只分配它真正需要的工具，不要把 Write 权限给一个审查员。

4.4 技能进化流水线：从观察到版本管理的自动化闭环

这是 ECC 最具创新性的子系统，它同时串联了 Hook 和 Subagent 两种机制——Hook 在工具调用时采集观察数据，Subagent 在后台异步分析——实现了"观察 → 评估 → 改进 → 版本管理"的完整闭环：

1. 1. 观察捕获：scripts/hooks/observe-runner.js 在每次 PreToolUse/PostToolUse 事件触发时记录工具调用的完整快照（输入、输出、耗时），追加写入 observations.jsonl（append-only，不含源代码）。
2. 2. 后台分析：Observer Agent（以 Haiku 模型运行的 Subagent）异步读取 observations.jsonl，进行模式检测，生成带 0.3~0.9 信心评分的"本能"（Instinct）候选。
3. 3. 评估与晋升：evaluate.js 对候选 Instinct 验证——是否与现有 Skill 冲突、模式重复频率、用户显式反馈。通过阈值（默认 0.7，基于内部实验数据，团队可按需调整）的 Instinct 被 amendify.js 写入 state-store 并更新对应 SKILL.md。修改后的 Skill 文件以新版本号保存（旧版本保留完整回滚链路），但自动生成的 Skill 内容仍建议在使用前经过人工审核——持续学习系统提供的是"候选改进"，最终采纳权在开发者。
4. 4. 版本管理：versioning.js 为每次改进生成 SHA-256 内容哈希，保留完整回滚链路。

设计启示：Hook 不只能做格式化和安全检查——它是 Harness Engineering 的"传感器"。在工具调用的每个生命周期节点上采集数据，用 Subagent 做异步分析，就能将一次性经验转化为可复用的知识。

4.5 跨会话记忆管理：SQLite 状态存储 + session-bridge

CC 内置的 Auto Memory 是黑盒——第三方无法自定义保存逻辑。ECC 利用 SessionStart 和 Stop 两个 Hook 事件，通过两层结构实现了完全可控的跨会话记忆：

1. 1. 文件级 bridge：session-bridge.js 在 /tmp 维护轻量 JSON 文件（ecc-metrics-{sessionId}.json），供 statusline、metrics-bridge、context-monitor 三个模块共享会话状态。写入使用 pid + random nonce 临时文件 + fs.renameSync() 原子替换，对 Windows 的 MoveFileExW 并发限制实现了指数退避重试。
2. 2. SQLite 状态存储：scripts/lib/state-store/ 提供基于 sql.js（WASM 编译的 SQLite）的关系型持久化，存储 7 种实体：sessions（会话）、skill_runs（技能执行记录）、skill_versions（技能版本历史）、decisions（关键决策）、install_state（安装状态）、governance_events（治理事件）、work_items（工作项）。

会话生命周期完全自动化：Stop Hook 提取决策、代码模式和偏好，写入 SQLite；SessionStart Hook 读取上次会话的摘要和决策，注入为新会话的系统提示词。

设计启示：AI 助手的"记忆力"不需要依赖厂商内置功能。Hook + SQLite 的组合提供了完全可控的跨会话状态管理，团队可以根据自己的数据结构定制记忆模型。

4.6 质量门禁与安全门控

本节是 4.1 节 Hook 门控机制在上层安全策略中的具体应用，同样基于 PreToolUse 和 PostToolUse 事件。

ECC 在工具调用的前后建立了多层安全检查：

• • PreToolUse 层：pre-bash-dev-server-block.js 阻止在非 tmux 环境中启动 dev server；pre-bash-git-push-reminder.js 提醒 push 前检查；block-no-verify.js 阻止 --no-verify 跳过 git hooks；config-protection.js 阻止 AI 修改 linter/formatter 配置（强迫"修复代码而非弱化配置"）。
• • PostToolUse 层：post-edit-format.js 自动格式化修改后的文件；post-edit-console-warn.js 检测遗留的 console.log；quality-gate.js 跑完整的质量门禁（lint + typecheck + test）。
• • GateGuard：ECC 最激进的安全机制——当 AI 首次编辑任何文件时，Hook 强制阻断并要求 AI 先调查该文件的导入者、数据 schema 和用户意图，确认理解正确后才允许修改。这是一个"慢下来以求正确"的设计。代价是频繁打断交互流，每次首次编辑新文件都会增加一个"调查 → 确认"的回合。建议在高安全要求项目（金融、医疗）或新手团队中启用，快速原型阶段可在 minimal profile 下关闭。

设计启示：安全门控应该分层部署。PreToolUse 做"是否允许执行"的判断（阻断型），PostToolUse 做"执行质量如何"的检查（告警型）。阻断型 Hook 必须极快（<200ms），只做简单的模式匹配；复杂分析留给 PostToolUse 或异步 Subagent。

以上六个子系统并非孤立的功能模块，而是形成了三组互补关系：Hook 门控（4.1）提供运行时基础设施，记忆管理（4.5）和安全门控（4.6）在其上构建应用；选择性安装（4.2）解决"组件怎么到用户手里"的分发问题；智能体编排（4.3）和技能进化（4.4）则分别从"委派专门任务"和"从经验中学习"两个维度提升 AI 行为的质量。三者共同构成 Harness Engineering 的完整闭环：分发安装 → 运行时执行 → 学习进化。

5. 总结：Harness Engineering 的四条实践原则

从 ECC 的实现中可以提炼出四条可迁移到任何项目的原则。

5.1 底线约束用 Rules，工作流用 Skills

• • Rules 解决"始终知道什么"：编码规范、安全红线、命名约定。内容精炼（3-5 条），无条件注入，每次会话都生效。
• • Skills 解决"在需要时知道什么"：TDD 流程、Django ViewSet 最佳实践、部署检查清单。按需匹配，需要时才加载，避免持续占用上下文。

5.2 横切自动化用 Hook，保持轻量

Hook 是 Harness Engineering 中的横切关注点（cross-cutting concern）机制。格式化、安全检查、记忆保存这些"每次都要做"的操作，通过 Hook 覆盖到所有工具调用上，对 AI 和用户都透明。关键是保持 Hook 轻量：阻断型 200ms 以内，非关键错误始终放行，网络调用留给异步路径。

5.3 专精任务用 Subagent，保护主上下文

当任务需要"换个人做"时——独立的安全审查、深度的架构分析、语言特定的代码审查——委派给 Subagent。Subagent 的核心价值不在 prompt 差异，而在上下文隔离（独立窗口，不污染主会话）和权限最小化（只给需要的工具）。

5.4 先本地验证，再 Plugin 打包分发

所有的 Hook、Skill、Subagent、Rules 都应该先在本地项目中用对、用稳，确认有效后再打包成 Plugin。Plugin 解决的是"怎么分享"的问题，但分享的前提是内容本身已经被验证。ECC 本身的开发流程就是这一原则的体现：每个机制先在 .claude/ 下以 standalone 形式测试，成熟后才纳入 Plugin 清单。

6. 总结

Vibe Coding 让 AI 编程变得触手可及，Harness Engineering 让 AI 编程变得可持续。Claude Code 的九种扩展机制提供了"积木"，ECC 展示了如何用这些积木搭出完整的工程底座。起点不需要是 61 个 Subagent 和 246 个 Skill——从一个 Rule 约束开始，从一个 Hook 自动化开始，从第一次不用口头提醒就让 AI 自动格式化代码开始。每叠加一层，AI 助手的"本能"就多靠近工程纪律一步。