作者：AI技术观察员 | 首发：小鹏哥
GitHub上有一个项目，用两年时间从0冲到18万星，成为AI编程助手生态中现象级的存在——它就是affaan-m/everything-claude-code（以下简称ECC）。这个项目并非简单的提示词合集，而是一套完整的AI编程助手性能优化系统，涵盖Skills技能库、Instincts直觉引擎、Memory记忆机制、Security安全体系四大核心模块。
今天，我们来深度解剖这套系统的技术架构与实现原理。
一、Skills系统：229个可复用任务模板
ECC的Skills系统是其核心资产。项目包含229个精心编写的技能模板，覆盖前端、后端、移动端、AI、安全、数据库等几乎所有开发领域。
1.1 技能的组织结构
每个技能都是一个独立的工作流模板，文件名即技能名，例如coding-standards、security-review、tdd-workflow、continuous-learning等。技能的元数据定义在文件开头的YAML Frontmatter中：
---
description: Detect the project build system and incrementally fix build/type errors with minimal safe changes.
---
技能的内容采用Markdown格式，包含详细的步骤指引、决策树、最佳实践和代码示例。以build-fix技能为例，它定义了一套完整的”检测→分组→修复→验证”循环：
## Step 1: Detect Build System
| Indicator | Build Command |
|-----------|---------------|
| package.json with build script | npm run build |
| tsconfig.json (TypeScript) | npx tsc --noEmit |
| Cargo.toml | cargo build 2>&1 |
| pom.xml | mvn compile |
| go.mod | go build ./... |
## Step 2: Parse and Group Errors
1. Run the build command and capture stderr
2. Group errors by file path
3. Sort by dependency order
4. Count total errors for progress tracking
## Step 3: Fix Loop (One Error at a Time)
For each error:
1. Read the file — 10 lines around error
2. Diagnose root cause
3. Fix minimally — smallest change resolving error
4. Re-run build — verify no new errors introduced
5. Move to next error
1.2 技能的分类体系
技能按领域分为多个类别：
- 开发流程类：tdd-workflow、git-workflow、code-review、continuous-learning
- 安全类：security-review、security-scan、security-bounty-hunter、llm-trading-agent-security
- 架构类：architecture-decision-records、hexagonal-architecture、api-design
- 语言专项类：golang-patterns、python-patterns、rust-patterns、kotlin-patterns
- AI工程类：agentic-engineering、mcp-server-patterns、context-budget、prompt-optimizer
技能的调用遵循”工作流优先”原则：ECC规定所有新技能贡献必须先进入skills/目录，commands/目录仅为兼容性保留。这意味着整个系统的长期演进方向是技能化、工作流化的。
1.3 Skills的技术实现
技能在执行层面通过ECC的Agent系统调度。每个技能都有明确的tools和model声明：
---
name: planner
description: Expert planning specialist for complex features and refactoring
tools: ["Read", "Grep", "Glob"]
model: opus
---
这种声明式配置让ECC能够在任务分派时自动选择合适的模型和工具集。大型复杂任务分配给Opus模型，常规代码审查分配给Sonnet模型，实现了性能与成本的精确平衡。
二、Instincts系统：让AI拥有”直觉”响应
ECC最具创新性的设计之一是Instincts（本能）系统。这个系统模拟人类开发者的”直觉反应”，当AI遇到特定模式时，会自动触发预定义的响应策略，而无需显式调用技能。
2.1 Instincts的数据结构
每个本能项包含以下字段：
---
id: prefer-functional-style
trigger: "when writing new functions"
confidence: 0.8
domain: code-style
source: session-observation
scope: project
project_id: a1b2c3d4e5f6
project_name: my-app
---
# Prefer Functional Style
## Action
Use functional patterns over classes.
关键字段解析：
- trigger：触发条件，定义何时激活该本能
- confidence：置信度（0-1），高于阈值的本能才会被应用
- domain：领域分类，如code-style、testing、security等
- scope：作用域，project（项目级）或global（全局）
- source：来源，session-observation表示从会话中学习得到
2.2 Instincts的导出与共享
ECC提供完整的本能管理命令。/instinct-export命令可以将本能导出为可分享的YAML文件：
/instinct-export # 导出所有个人本能
/instinct-export --domain testing # 仅导出测试领域本能
/instinct-export --min-confidence 0.7 # 仅高置信度本能
/instinct-export --scope project --output team-instincts.yaml
导出的格式标准化后，可以轻松在团队间共享，实现团队级别的”AI行为规范”。
2.3 本能的学习机制
Instincts并非一成不变的静态规则，它们会通过持续学习机制不断进化。ECC的continuous-learning技能定义了本能的更新流程：观察会话中的成功模式，提炼为本能项，评估置信度，必要时更新或废弃旧的本能。
三、Memory系统：解决上下文记忆的核心难题
AI编程助手最大的技术瓶颈之一是”上下文记忆”——如何在长时间会话中保持对项目结构、决策历史、技术债等信息的持续认知。ECC通过一套多层记忆系统优雅地解决了这个问题。
3.1 分层记忆架构
ECC的记忆系统分为三个层次：
- 工作记忆（Working Context）：当前会话中的即时信息，通过正常的上下文窗口管理
- 项目记忆（Project Memory）：存储在
.claude/目录下的项目特定信息，包括项目规则、团队规范、架构决策等 - 持久记忆（Persistent Memory）：跨会话的长期学习成果，以结构化格式存储在本地
3.2 记忆的持久化机制
ECC的hooks系统中的memory-persistence模块负责记忆的持久化：
// hooks.json 中的 PreToolUse hook 示例
{
"matcher": "*",
"hooks": [{
"type": "command",
"command": "node scripts/hooks/observe-runner.js",
"async": true,
"timeout": 10
}]
}
这个hook在每次工具调用前异步运行观察者，捕获关键操作并将其写入持久化存储。观察内容包括：代码修改模式、错误修复经验、团队偏好等。
3.3 上下文预算管理
context-budget技能定义了ECC的上下文管理策略：
## Context Budget Management
- 避免在上下文窗口的最后20%进行大型重构
- 复杂多文件功能应分阶段执行
- 低敏感度任务（单次编辑、文档、简单修复）可容忍更高利用率
- 大型重构任务应在上下文利用率达到80%前启动压缩
这套机制确保AI在处理复杂任务时，不会因为上下文耗尽而”失忆”或产生质量下降。
3.4 规则系统的分层设计
ECC的规则系统（rules/）采用了语言无关规则+语言专项规则的二层结构：
rules/
├── common/ # 所有语言共享的规则
│ ├── security.md
│ ├── coding-style.md
│ ├── git-workflow.md
│ ├── testing.md
│ └── performance.md
├── typescript/ # TypeScript 专项规则
├── python/ # Python 专项规则
├── golang/ # Go 专项规则
├── rust/ # Rust 专项规则
└── zh/ # 中文规则
这种设计保证了规则的可维护性——通用规则只需编写一次，特定语言规则独立演进。
四、Security系统：AI编程助手安全审计框架
2026年2月，Check Point Research披露了Claude Code的两个高危漏洞（CVE-2025-59536和CVE-2026-21852），让AI编程助手的安全问题正式进入公众视野。ECC的安全体系正是在这样的背景下发展成熟的。
4.1 安全指南的完整体系
ECC的the-security-guide.md是一份详尽的AI Agent安全白皮书，覆盖了：
- 攻击向量分类（邮件附件、PDF嵌入、GitHub PR评论、聊天消息等）
- CVSS 8.7级漏洞的原理与防护
- MCP服务器的OWASP Top 10风险
- 沙箱隔离的最佳实践
- 内存污染攻击的防御
4.2 安全规则（rules/common/security.md）
所有代码变更必须通过安全检查：
# Security Guidelines
## Mandatory Security Checks
Before ANY commit:
- [ ] No hardcoded secrets (API keys, passwords, tokens)
- [ ] All user inputs validated
- [ ] SQL injection prevention (parameterized queries)
- [ ] XSS prevention (sanitized HTML)
- [ ] CSRF protection enabled
- [ ] Authentication/authorization verified
- [ ] Rate limiting on all endpoints
- [ ] Error messages don't leak sensitive data
## Secret Management
- NEVER hardcode secrets in source code
- ALWAYS use environment variables or a secret manager
- Validate that required secrets are present at startup
- Rotate any secrets that may have been exposed
4.3 Security-Reviewer Agent
ECC的安全审查Agent是自动化安全审计的典范。它遵循严格的置信度过滤机制：
## Pre-Report Gate
Before writing a finding, answer all four questions. If any answer is "no" or
"unsure", downgrade severity or drop the finding.
1. Can I cite the exact line?
2. Can I describe the concrete failure mode?
3. Have I read the surrounding context?
4. Is the severity defensible?
对于HIGH/CRITICAL级别的问题，Agent必须提供：精确代码片段、行号、具体失败场景，以及为何现有防护无法捕获。这种量化标准大幅减少了安全报告的噪音。
4.4 沙箱隔离配置
ECC推荐使用Docker Compose进行工作空间隔离：
services:
agent:
build: .
user: "1000:1000"
working_dir: /workspace
volumes:
- ./workspace:/workspace:rw
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
networks:
- agent-internal
networks:
agent-internal:
internal: true
关键安全配置解读：
cap_drop: ALL——移除所有Linux能力，防止特权升级no-new-privileges——防止子进程获取更高权限internal: true——容器网络与外网隔离
五、Agent编排系统：60个专业Agent的协同
ECC定义了60个专业Agent，形成了一个分层协作的Agent网络。
5.1 Agent的分类
| Agent | 职责 | 触发时机 |
|---|---|---|
| planner | 复杂功能规划 | 功能实现、架构变更 |
| architect | 系统设计 | 架构决策 |
| tdd-guide | TDD流程指导 | 新功能、Bug修复 |
| code-reviewer | 代码质量审查 | 代码编写/修改后 |
| security-reviewer | 安全漏洞检测 | 提交前、敏感代码 |
| build-error-resolver | 构建错误修复 | 构建失败时 |
| e2e-runner | 端到端测试 | 关键用户流程 |
| loop-operator | 自主循环监控 | 长时间运行任务 |
5.2 Agent的编排哲学
ECC遵循”Agent-First”原则：
## Agent Orchestration
Use agents proactively without user prompt:
- Complex feature requests → planner
- Code just written/modified → code-reviewer
- Bug fix or new feature → tdd-guide
- Architectural decision → architect
- Security-sensitive code → security-reviewer
- Autonomous loops / loop monitoring → loop-operator
- Harness config reliability and cost → harness-optimizer
Use parallel execution for independent operations —
launch multiple agents simultaneously.
5.3 治理捕获Hook
ECC的hooks系统还包含治理捕获机制：
{
"matcher": "Bash|Write|Edit|MultiEdit",
"hooks": [{
"type": "command",
"command": "node scripts/hooks/governance-capture.js",
"timeout": 10
}]
}
该hook在关键操作前触发，用于捕获治理事件（秘密泄露检测、政策违规、审批请求），为合规审计提供完整的操作日志。
六、开发工作流：从研究到提交的完整闭环
ECC定义了清晰的开发工作流，强调”先研究、再计划、后执行”：
## Feature Implementation Workflow
0. **Research & Reuse** (mandatory before any new implementation)
- GitHub code search first
- Library docs second
- Exa only when the first two are insufficient
1. **Plan First**
- Use planner agent to create implementation plan
- Generate planning docs before coding
2. **TDD Approach**
- Write tests first (RED)
- Implement to pass tests (GREEN)
- Refactor (IMPROVE)
- Verify 80%+ coverage
3. **Code Review**
- Use code-reviewer agent immediately after writing code
- Address CRITICAL and HIGH issues
4. **Commit & Push**
- Detailed commit messages
- Follow conventional commits format
结语
everything-claude-code的18万星并非偶然。它构建了一套可工程化、可审计、可进化的AI编程助手优化框架——Skills提供可复用的工作流模板，Instincts让AI形成直觉响应，Memory解决上下文持久化问题，Security保障全流程安全。
在AI编程助手从”新奇玩具”走向”生产工具”的2026年，这套框架的工程化思路值得所有AI开发者研究借鉴。
GitHub：https://github.com/affaan-m/everything-claude-code
评论区