Files
everything-claude-code/docs/zh-CN/AGENTS.md
zdoc.app abcf38b085 docs(zh-CN): sync Chinese docs with latest upstream changes (#341)
* docs(zh-CN): sync Chinese docs with latest upstream changes

* docs(zh-CN): update link

---------

Co-authored-by: neo <neo.dowithless@gmail.com>
2026-03-07 14:48:02 -08:00

5.7 KiB
Raw Blame History

Everything Claude Code (ECC) — 智能体指令

这是一个生产就绪的 AI 编码插件,提供 13 个专业智能体、50+ 项技能、33 条命令以及用于软件开发的自动化钩子工作流。

核心原则

  1. 智能体优先 — 将领域任务委托给专业智能体
  2. 测试驱动 — 先写测试再实现,要求 80%+ 覆盖率
  3. 安全第一 — 绝不妥协安全;验证所有输入
  4. 不可变性 — 总是创建新对象,永不修改现有对象
  5. 先规划后执行 — 在编写代码前规划复杂功能

可用智能体

智能体 目的 何时使用
planner 实施规划 复杂功能、重构
architect 系统设计与可扩展性 架构决策
tdd-guide 测试驱动开发 新功能、错误修复
code-reviewer 代码质量与可维护性 编写/修改代码后
security-reviewer 漏洞检测 提交前、敏感代码
build-error-resolver 修复构建/类型错误 构建失败时
e2e-runner 端到端 Playwright 测试 关键用户流程
refactor-cleaner 清理无用代码 代码维护
doc-updater 文档和代码地图更新 更新文档
go-reviewer Go 代码审查 Go 项目
go-build-resolver Go 构建错误 Go 构建失败
database-reviewer PostgreSQL/Supabase 专家 模式设计、查询优化
python-reviewer Python 代码审查 Python 项目

智能体编排

主动使用智能体,无需用户提示:

  • 复杂功能请求 → planner
  • 刚编写/修改的代码 → code-reviewer
  • 错误修复或新功能 → tdd-guide
  • 架构决策 → architect
  • 安全敏感代码 → security-reviewer

对于独立操作使用并行执行 — 同时启动多个智能体。

安全指南

在任何提交之前:

  • 没有硬编码的密钥API 密钥、密码、令牌)
  • 所有用户输入都经过验证
  • 防止 SQL 注入(参数化查询)
  • 防止 XSS已清理的 HTML
  • 启用 CSRF 保护
  • 已验证身份验证/授权
  • 所有端点都有限速
  • 错误消息不泄露敏感数据

密钥管理: 绝不硬编码密钥。使用环境变量或密钥管理器。在启动时验证所需的密钥。立即轮换任何暴露的密钥。

如果发现安全问题: 停止 → 使用 security-reviewer 智能体 → 修复 CRITICAL 问题 → 轮换暴露的密钥 → 审查代码库中的类似问题。

编码风格

不可变性(关键): 总是创建新对象,永不修改。返回带有更改的新副本。

文件组织: 许多小文件优于少数大文件。通常 200-400 行,最多 800 行。按功能/领域组织,而不是按类型组织。高内聚,低耦合。

错误处理: 在每个层级处理错误。在 UI 代码中提供用户友好的消息。在服务器端记录详细的上下文。绝不静默地忽略错误。

输入验证: 在系统边界验证所有用户输入。使用基于模式的验证。快速失败并给出清晰的消息。绝不信任外部数据。

代码质量检查清单:

  • 函数小巧(<50 行),文件专注(<800 行)
  • 没有深层嵌套(>4 层)
  • 适当的错误处理,没有硬编码的值
  • 可读性强、命名良好的标识符

测试要求

最低覆盖率80%

测试类型(全部必需):

  1. 单元测试 — 单个函数、工具、组件
  2. 集成测试 — API 端点、数据库操作
  3. 端到端测试 — 关键用户流程

TDD 工作流(强制):

  1. 先写测试RED — 测试应该失败
  2. 编写最小实现GREEN — 测试应该通过
  3. 重构IMPROVE — 验证覆盖率 80%+

故障排除:检查测试隔离 → 验证模拟 → 修复实现(而不是测试,除非测试是错误的)。

开发工作流

  1. 规划 — 使用 planner 智能体,识别依赖项和风险,分解为阶段
  2. TDD — 使用 tdd-guide 智能体,先写测试,实现,重构
  3. 审查 — 立即使用 code-reviewer 智能体,解决 CRITICAL/HIGH 问题
  4. 提交 — 约定式提交格式,全面的 PR 摘要

Git 工作流

提交格式: <type>: <description> — 类型feat, fix, refactor, docs, test, chore, perf, ci

PR 工作流: 分析完整的提交历史 → 起草全面的摘要 → 包含测试计划 → 使用 -u 标志推送。

架构模式

API 响应格式: 具有成功指示器、数据负载、错误消息和分页元数据的一致信封。

仓储模式: 将数据访问封装在标准接口findAll, findById, create, update, delete后面。业务逻辑依赖于抽象接口而不是存储机制。

骨架项目: 搜索经过实战检验的模板,使用并行智能体(安全性、可扩展性、相关性)进行评估,克隆最佳匹配,在已验证的结构内迭代。

性能

上下文管理: 对于大型重构和多文件功能,避免使用上下文窗口的最后 20%。敏感性较低的任务(单次编辑、文档、简单修复)可以容忍较高的利用率。

构建故障排除: 使用 build-error-resolver 智能体 → 分析错误 → 增量修复 → 每次修复后验证。

项目结构

agents/          — 13 specialized subagents
skills/          — 50+ workflow skills and domain knowledge
commands/        — 33 slash commands
hooks/           — Trigger-based automations
rules/           — Always-follow guidelines (common + per-language)
scripts/         — Cross-platform Node.js utilities
mcp-configs/     — 14 MCP server configurations
tests/           — Test suite

成功指标

  • 所有测试通过且覆盖率 80%+
  • 没有安全漏洞
  • 代码可读且可维护
  • 性能可接受
  • 满足用户需求