规则系统与多语言分层
规则系统与多语言分层
学习目标
本章要解决什么问题：理解 ECC 如何在 12 种语言生态系统中保持规则的一致性，同时允许语言特化。
读完本章后，你将了解：
- 规则分层架构（Common + Per-Language）
- Prompt Defense 基线的注入策略
- 按需安装的规则模块裁剪
- 规则与技能的边界定义
前置知识
本章涉及提示工程的基础知识，建议先阅读：
- 系统提示组装策略 — Prompt Defense 基线模式
项目实践
规则分层架构
ECC 的规则系统分为两层：
rules/├── common/ # 通用规则（所有语言共享）│ ├── agents.md # Agent 使用指南│ ├── code-review.md # 代码审查标准│ ├── coding-style.md # 编码风格│ ├── development-workflow.md│ ├── git-workflow.md│ ├── hooks.md│ ├── patterns.md│ ├── performance.md│ ├── security.md│ └── testing.md└── {language}/ # 语言特定规则（按需安装） ├── typescript/ ├── python/ ├── golang/ ├── java/ ├── kotlin/ ├── rust/ ├── cpp/ ├── csharp/ ├── dart/ ├── fsharp/ ├── perl/ ├── php/ └── ...加载顺序：Common 规则始终加载，语言规则按安装配置加载。这意味着 TypeScript 项目的 Agent 会加载 rules/common/*.md + rules/typescript/*.md。
语言规则的内容结构
每种语言的规则目录通常包含：
rules/typescript/├── coding-standards.md # TypeScript 编码标准├── testing.md # TypeScript 测试策略├── security.md # TypeScript 安全注意事项└── patterns.md # TypeScript 设计模式每个语言规则文件顶部都注入 Prompt Defense 基线，确保即使文件被单独使用，安全上下文仍然存在。
按需安装
规则模块支持按语言裁剪安装：
# 只安装 TypeScript 规则bash install.sh --target claude --modules rules-typescript
# 安装 TypeScript + Python 规则bash install.sh --target claude --modules rules-typescript,rules-python这使得不需要多语言支持的用户可以减少安装的文件数。
规则 vs 技能的边界
ECC 明确区分规则和技能的职责：
| 维度 | 规则（Rules） | 技能（Skills） |
|---|---|---|
| 触发方式 | Always-on（始终生效） | On-demand（按需激活） |
| 内容 | 编码风格、安全指南、工作流约束 | 具体工作流、模式、示例 |
| 格式 | Markdown 指令 | SKILL.md（When to Use + How It Works + Examples） |
| 安装 | rules/ 目录 | skills/ 目录 |
| 示例 | ”函数 <50 行”、“不可变操作" | "TDD 工作流步骤”、“React 组件测试模式” |
为什么不在每个 SKILL.md 中重复语言规则？ 规则是 always-on，技能是 on-demand。如果在每个技能中重复语言规则，会导致：
- 维护负担：修改规则需要更新所有技能
- 不一致：技能可能使用过时的规则版本
- 上下文浪费：每次加载技能都携带重复的规则
.claude/rules/ 中的项目级规则
除了 rules/ 目录中的可安装规则，ECC 自身也通过 .claude/rules/ 定义了项目级规则：
.claude/rules/├── node.md # Node.js 项目特定规则├── everything-claude-code-guardrails.md # 自动生成的护栏└── ...这些规则是 ECC 项目开发过程中的约定，不是通用的可安装规则。
AGENTS.md 中的核心原则
ECC 的根目录 AGENTS.md 定义了五个核心原则，这些原则作用于所有代理：
- Agent-First — 委托给专业代理处理领域任务
- Test-Driven — 实现前先写测试，80%+ 覆盖率
- Security-First — 安全不妥协，验证所有输入
- Immutability — 始终创建新对象，不修改现有对象
- Plan Before Execute — 复杂功能先规划再实现
这些原则通过 AGENTS.md 的加载机制（Claude Code 自动读取）注入到所有会话中。
问题与规避
规则冲突
问题：Common 规则和 Language 规则可能冲突（如 Common 规定函数 <50 行，Language 规定 <100 行）。
ECC 的规避：
- Common 规则定义最低标准，Language 规则可以更严格但不能更宽松
- 冲突时以更具体的规则为准（Language > Common）
- CI 检查规则文件中的明显冲突
规则过时
问题：语言/框架更新后规则可能过时。
规避方案：
- 规则文件标注
versionDate - 社区 PR 可以更新特定语言的规则
- 规则更新遵循 CONTRIBUTING.md 中的 PR 模板
Prompt Defense 重复注入
问题：每个规则文件顶部都重复注入 Prompt Defense Baseline，导致文件变大。
ECC 的权衡：
- 优势：防止文件被单独提取后丢失安全上下文
- 代价：文本重复
- 结论：安全上下文比文件大小更重要
设计取舍
为什么用 Markdown 而非 JSON Schema 定义规则？
规则定义为 Markdown 文件：
- 优势：LLM 直接理解自然语言，人类也可阅读和编辑
- 代价：无法用 Schema 自动验证规则的一致性
- 替代方案：JSON/YAML 结构化规则 + LLM 翻译。ECC 选择 Markdown 因为自然语言指令对 LLM 更有效
Common + Per-Language 两层 vs 单层
ECC 选择两层规则架构：
- 优势：Common 层保持一致性，Language 层允许特化
- 代价：需要维护两套文件，安装时需要正确组合
- 替代方案：单层 + 所有规则混在一起。ECC 认为两层更清晰，且支持按需安装
参考来源
- 源码验证:
rules/目录结构 — Common + Per-Language 分层 - 源码验证:
rules/common/中 10 个通用规则文件 - 源码验证:
rules/typescript/,rules/python/等 12 种语言规则 - 源码验证:
AGENTS.md— 五个核心原则 - 源码验证:
.claude/rules/node.md— 项目级规则 - 系统提示组装策略 — Prompt Defense 基线注入