feat: add Chinese (zh-CN) translation for rules/common

- Add rules/zh/ directory with complete Chinese translations
- Translate all 10 common rule files:
  - coding-style.md
  - security.md
  - testing.md
  - git-workflow.md
  - performance.md
  - patterns.md
  - hooks.md
  - agents.md
  - development-workflow.md
  - code-review.md
- Add README.md for the zh directory explaining structure and installation
- Maintain consistent formatting with original English versions
- Keep technical terms and code examples in English where appropriate
This commit is contained in:
xingzihai
2026-03-26 01:38:39 +00:00
parent b5148f184a
commit 3f5e042b40
11 changed files with 552 additions and 0 deletions

102
rules/zh/README.md Normal file
View File

@@ -0,0 +1,102 @@
# 规则
## 结构
规则按**通用**层和**语言特定**目录组织:
```
rules/
├── common/ # 语言无关的原则(始终安装)
│ ├── coding-style.md
│ ├── git-workflow.md
│ ├── testing.md
│ ├── performance.md
│ ├── patterns.md
│ ├── hooks.md
│ ├── agents.md
│ └── security.md
├── zh/ # 中文翻译版本
│ ├── coding-style.md
│ ├── git-workflow.md
│ ├── testing.md
│ ├── performance.md
│ ├── patterns.md
│ ├── hooks.md
│ ├── agents.md
│ ├── security.md
│ └── development-workflow.md
├── typescript/ # TypeScript/JavaScript 特定
├── python/ # Python 特定
├── golang/ # Go 特定
├── swift/ # Swift 特定
└── php/ # PHP 特定
```
- **common/** 包含通用原则 — 无语言特定的代码示例。
- **zh/** 包含 common 目录的中文翻译版本。
- **语言目录** 扩展通用规则,包含框架特定的模式、工具和代码示例。每个文件引用其对应的通用版本。
## 安装
### 选项 1安装脚本推荐
```bash
# 安装通用 + 一个或多个语言特定的规则集
./install.sh typescript
./install.sh python
./install.sh golang
./install.sh swift
./install.sh php
# 同时安装多种语言
./install.sh typescript python
```
### 选项 2手动安装
> **重要提示:** 复制整个目录 — 不要使用 `/*` 展开。
> 通用和语言特定目录包含同名文件。
> 将它们展开到一个目录会导致语言特定文件覆盖通用规则,
> 并破坏语言特定文件使用的 `../common/` 相对引用。
```bash
# 安装通用规则(所有项目必需)
cp -r rules/common ~/.claude/rules/common
# 安装中文翻译版本(可选)
cp -r rules/zh ~/.claude/rules/zh
# 根据项目技术栈安装语言特定规则
cp -r rules/typescript ~/.claude/rules/typescript
cp -r rules/python ~/.claude/rules/python
cp -r rules/golang ~/.claude/rules/golang
cp -r rules/swift ~/.claude/rules/swift
cp -r rules/php ~/.claude/rules/php
```
## 规则 vs 技能
- **规则** 定义广泛适用的标准、约定和检查清单(如"80% 测试覆盖率"、"禁止硬编码密钥")。
- **技能**`skills/` 目录)为特定任务提供深入、可操作的参考材料(如 `python-patterns``golang-testing`)。
语言特定的规则文件在适当的地方引用相关技能。规则告诉你*做什么*;技能告诉你*怎么做*。
## 规则优先级
当语言特定规则与通用规则冲突时,**语言特定规则优先**(特定覆盖通用)。这遵循标准的分层配置模式(类似于 CSS 特异性或 `.gitignore` 优先级)。
- `rules/common/` 定义适用于所有项目的通用默认值。
- `rules/golang/``rules/python/``rules/swift/``rules/php/``rules/typescript/` 等在语言习惯不同时覆盖这些默认值。
- `rules/zh/` 是通用规则的中文翻译,与英文版本内容一致。
### 示例
`common/coding-style.md` 推荐不可变性作为默认原则。语言特定的 `golang/coding-style.md` 可以覆盖这一点:
> 惯用的 Go 使用指针接收器进行结构体变更 — 参见 [common/coding-style.md](../common/coding-style.md) 了解通用原则,但这里首选符合 Go 习惯的变更方式。
### 带覆盖说明的通用规则
`rules/common/` 中可能被语言特定文件覆盖的规则会标记:
> **语言说明**:此规则可能被语言特定规则覆盖,对于某些语言,该模式可能不是惯用的。

50
rules/zh/agents.md Normal file
View File

@@ -0,0 +1,50 @@
# 代理编排
## 可用代理
位于 `~/.claude/agents/`
| 代理 | 用途 | 何时使用 |
|-------|---------|------------|
| planner | 实现规划 | 复杂功能、重构 |
| architect | 系统设计 | 架构决策 |
| tdd-guide | 测试驱动开发 | 新功能、bug 修复 |
| code-reviewer | 代码审查 | 编写代码后 |
| security-reviewer | 安全分析 | 提交前 |
| build-error-resolver | 修复构建错误 | 构建失败时 |
| e2e-runner | E2E 测试 | 关键用户流程 |
| refactor-cleaner | 死代码清理 | 代码维护 |
| doc-updater | 文档 | 更新文档 |
| rust-reviewer | Rust 代码审查 | Rust 项目 |
## 立即使用代理
无需用户提示:
1. 复杂功能请求 - 使用 **planner** 代理
2. 刚编写/修改的代码 - 使用 **code-reviewer** 代理
3. Bug 修复或新功能 - 使用 **tdd-guide** 代理
4. 架构决策 - 使用 **architect** 代理
## 并行任务执行
对独立操作始终使用并行 Task 执行:
```markdown
# 好:并行执行
同时启动 3 个代理:
1. 代理 1认证模块安全分析
2. 代理 2缓存系统性能审查
3. 代理 3工具类型检查
# 坏:不必要的顺序
先代理 1然后代理 2然后代理 3
```
## 多视角分析
对于复杂问题,使用分角色子代理:
- 事实审查者
- 高级工程师
- 安全专家
- 一致性审查者
- 冗余检查者

116
rules/zh/code-review.md Normal file
View File

@@ -0,0 +1,116 @@
# 代码审查标准
## 目的
代码审查确保代码合并前的质量、安全性和可维护性。此规则定义何时以及如何进行代码审查。
## 何时审查
**强制审查触发条件:**
- 编写或修改代码后
- 提交到共享分支之前
- 更改安全敏感代码时(认证、支付、用户数据)
- 进行架构更改时
- 合并 pull request 之前
## 审查检查清单
在标记代码完成之前:
- [ ] 代码可读且命名良好
- [ ] 函数聚焦(<50 行)
- [ ] 文件内聚(<800 行)
- [ ] 无深层嵌套(>4 层)
- [ ] 错误显式处理
- [ ] 无硬编码密钥或凭据
- [ ] 无 console.log 或调试语句
- [ ] 新功能有测试
- [ ] 测试覆盖率满足 80% 最低要求
## 安全审查触发条件
**停止并使用 security-reviewer 代理当:**
- 认证或授权代码
- 用户输入处理
- 数据库查询
- 文件系统操作
- 外部 API 调用
- 加密操作
- 支付或金融代码
## 审查严重级别
| 级别 | 含义 | 行动 |
|-------|---------|--------|
| CRITICAL关键 | 安全漏洞或数据丢失风险 | **阻止** - 合并前必须修复 |
| HIGH | Bug 或重大质量问题 | **警告** - 合并前应修复 |
| MEDIUM | 可维护性问题 | **信息** - 考虑修复 |
| LOW | 风格或次要建议 | **注意** - 可选 |
## 代理使用
使用这些代理进行代码审查:
| 代理 | 用途 |
|-------|--------|
| **code-reviewer** | 通用代码质量、模式、最佳实践 |
| **security-reviewer** | 安全漏洞、OWASP Top 10 |
| **typescript-reviewer** | TypeScript/JavaScript 特定问题 |
| **python-reviewer** | Python 特定问题 |
| **go-reviewer** | Go 特定问题 |
| **rust-reviewer** | Rust 特定问题 |
## 审查工作流
```
1. 运行 git diff 了解更改
2. 先检查安全检查清单
3. 审查代码质量检查清单
4. 运行相关测试
5. 验证覆盖率 >= 80%
6. 使用适当的代理进行详细审查
```
## 常见问题捕获
### 安全
- 硬编码凭据API 密钥、密码、令牌)
- SQL 注入(查询中的字符串拼接)
- XSS 漏洞(未转义的用户输入)
- 路径遍历(未净化的文件路径)
- CSRF 保护缺失
- 认证绕过
### 代码质量
- 大函数(>50 行)- 拆分为更小的
- 大文件(>800 行)- 提取模块
- 深层嵌套(>4 层)- 使用提前返回
- 缺少错误处理 - 显式处理
- 变更模式 - 优先使用不可变操作
- 缺少测试 - 添加测试覆盖
### 性能
- N+1 查询 - 使用 JOIN 或批处理
- 缺少分页 - 给查询添加 LIMIT
- 无界查询 - 添加约束
- 缺少缓存 - 缓存昂贵操作
## 批准标准
- **批准**:无关键或高优先级问题
- **警告**:仅有高优先级问题(谨慎合并)
- **阻止**:发现关键问题
## 与其他规则的集成
此规则与以下规则配合:
- [testing.md](testing.md) - 测试覆盖率要求
- [security.md](security.md) - 安全检查清单
- [git-workflow.md](git-workflow.md) - 提交标准
- [agents.md](agents.md) - 代理委托

48
rules/zh/coding-style.md Normal file
View File

@@ -0,0 +1,48 @@
# 编码风格
## 不可变性(关键)
始终创建新对象,永远不要修改现有对象:
```
// 伪代码
错误: modify(original, field, value) → 就地修改 original
正确: update(original, field, value) → 返回带有更改的新副本
```
原理:不可变数据防止隐藏的副作用,使调试更容易,并启用安全的并发。
## 文件组织
多个小文件 > 少量大文件:
- 高内聚,低耦合
- 典型 200-400 行,最多 800 行
- 从大模块中提取工具函数
- 按功能/领域组织,而非按类型
## 错误处理
始终全面处理错误:
- 在每一层显式处理错误
- 在面向 UI 的代码中提供用户友好的错误消息
- 在服务器端记录详细的错误上下文
- 永远不要静默吞掉错误
## 输入验证
始终在系统边界验证:
- 处理前验证所有用户输入
- 在可用的情况下使用基于模式的验证
- 快速失败并给出清晰的错误消息
- 永远不要信任外部数据API 响应、用户输入、文件内容)
## 代码质量检查清单
在标记工作完成前:
- [ ] 代码可读且命名良好
- [ ] 函数很小(<50 行)
- [ ] 文件聚焦(<800 行)
- [ ] 没有深层嵌套(>4 层)
- [ ] 正确的错误处理
- [ ] 没有硬编码值(使用常量或配置)
- [ ] 没有变更(使用不可变模式)

View File

@@ -0,0 +1,38 @@
# 开发工作流
> 此文件扩展 [common/git-workflow.md](./git-workflow.md),包含 git 操作之前的完整功能开发流程。
功能实现工作流描述了开发管道研究、规划、TDD、代码审查然后提交到 git。
## 功能实现工作流
0. **研究与重用** _(任何新实现前必需)_
- **GitHub 代码搜索优先:** 在编写任何新代码之前,运行 `gh search repos``gh search code` 查找现有实现、模板和模式。
- **库文档其次:** 使用 Context7 或主要供应商文档确认 API 行为、包使用和版本特定细节。
- **仅当前两者不足时使用 Exa** 在 GitHub 搜索和主要文档之后,使用 Exa 进行更广泛的网络研究或发现。
- **检查包注册表:** 在编写工具代码之前搜索 npm、PyPI、crates.io 和其他注册表。首选久经考验的库而非手工编写的解决方案。
- **搜索可适配的实现:** 寻找解决问题 80%+ 且可以分支、移植或包装的开源项目。
- 当满足需求时,优先采用或移植经验证的方法而非从头编写新代码。
1. **先规划**
- 使用 **planner** 代理创建实现计划
- 编码前生成规划文档PRD、架构、系统设计、技术文档、任务列表
- 识别依赖和风险
- 分解为阶段
2. **TDD 方法**
- 使用 **tdd-guide** 代理
- 先写测试RED
- 实现以通过测试GREEN
- 重构IMPROVE
- 验证 80%+ 覆盖率
3. **代码审查**
- 编写代码后立即使用 **code-reviewer** 代理
- 解决关键和高优先级问题
- 尽可能修复中优先级问题
4. **提交与推送**
- 详细的提交消息
- 遵循约定式提交格式
- 参见 [git-workflow.md](./git-workflow.md) 了解提交消息格式和 PR 流程

24
rules/zh/git-workflow.md Normal file
View File

@@ -0,0 +1,24 @@
# Git 工作流
## 提交消息格式
```
<类型>: <描述>
<可选正文>
```
类型feat, fix, refactor, docs, test, chore, perf, ci
注意:通过 ~/.claude/settings.json 全局禁用归属。
## Pull Request 工作流
创建 PR 时:
1. 分析完整提交历史(不仅是最新提交)
2. 使用 `git diff [base-branch]...HEAD` 查看所有更改
3. 起草全面的 PR 摘要
4. 包含带有 TODO 的测试计划
5. 如果是新分支,使用 `-u` 标志推送
> 对于 git 操作之前的完整开发流程规划、TDD、代码审查
> 参见 [development-workflow.md](./development-workflow.md)。

30
rules/zh/hooks.md Normal file
View File

@@ -0,0 +1,30 @@
# 钩子系统
## 钩子类型
- **PreToolUse**:工具执行前(验证、参数修改)
- **PostToolUse**:工具执行后(自动格式化、检查)
- **Stop**:会话结束时(最终验证)
## 自动接受权限
谨慎使用:
- 为可信、定义明确的计划启用
- 探索性工作时禁用
- 永远不要使用 dangerously-skip-permissions 标志
- 改为在 `~/.claude.json` 中配置 `allowedTools`
## TodoWrite 最佳实践
使用 TodoWrite 工具:
- 跟踪多步骤任务的进度
- 验证对指令的理解
- 启用实时引导
- 显示细粒度的实现步骤
待办列表揭示:
- 顺序错误的步骤
- 缺失的项目
- 多余的不必要项目
- 错误的粒度
- 误解的需求

31
rules/zh/patterns.md Normal file
View File

@@ -0,0 +1,31 @@
# 常用模式
## 骨架项目
实现新功能时:
1. 搜索久经考验的骨架项目
2. 使用并行代理评估选项:
- 安全性评估
- 可扩展性分析
- 相关性评分
- 实现规划
3. 克隆最佳匹配作为基础
4. 在经验证的结构内迭代
## 设计模式
### 仓储模式
将数据访问封装在一致的接口后面:
- 定义标准操作findAll、findById、create、update、delete
- 具体实现处理存储细节数据库、API、文件等
- 业务逻辑依赖抽象接口,而非存储机制
- 便于轻松切换数据源,并简化使用模拟的测试
### API 响应格式
对所有 API 响应使用一致的信封:
- 包含成功/状态指示器
- 包含数据负载(错误时可为空)
- 包含错误消息字段(成功时可为空)
- 包含分页响应的元数据total、page、limit

55
rules/zh/performance.md Normal file
View File

@@ -0,0 +1,55 @@
# 性能优化
## 模型选择策略
**Haiku 4.5**Sonnet 90% 的能力3 倍成本节省):
- 频繁调用的轻量级代理
- 结对编程和代码生成
- 多代理系统中的工作者代理
**Sonnet 4.6**(最佳编码模型):
- 主要开发工作
- 编排多代理工作流
- 复杂编码任务
**Opus 4.5**(最深度推理):
- 复杂架构决策
- 最大推理需求
- 研究和分析任务
## 上下文窗口管理
避免在上下文窗口的最后 20% 进行以下操作:
- 大规模重构
- 跨多个文件的功能实现
- 调试复杂交互
上下文敏感度较低的任务:
- 单文件编辑
- 独立工具创建
- 文档更新
- 简单 bug 修复
## 扩展思考 + 规划模式
扩展思考默认启用,为内部推理保留最多 31,999 个 token。
通过以下方式控制扩展思考:
- **切换**Option+TmacOS/ Alt+TWindows/Linux
- **配置**:在 `~/.claude/settings.json` 中设置 `alwaysThinkingEnabled`
- **预算上限**`export MAX_THINKING_TOKENS=10000`
- **详细模式**Ctrl+O 查看思考输出
对于需要深度推理的复杂任务:
1. 确保扩展思考已启用(默认开启)
2. 启用**规划模式**进行结构化方法
3. 使用多轮审查进行彻底分析
4. 使用分角色子代理获得多样化视角
## 构建排查
如果构建失败:
1. 使用 **build-error-resolver** 代理
2. 分析错误消息
3. 增量修复
4. 每次修复后验证

29
rules/zh/security.md Normal file
View File

@@ -0,0 +1,29 @@
# 安全指南
## 强制安全检查
在任何提交之前:
- [ ] 无硬编码密钥API 密钥、密码、令牌)
- [ ] 所有用户输入已验证
- [ ] SQL 注入防护(参数化查询)
- [ ] XSS 防护(净化 HTML
- [ ] CSRF 保护已启用
- [ ] 认证/授权已验证
- [ ] 所有端点启用速率限制
- [ ] 错误消息不泄露敏感数据
## 密钥管理
- 永远不要在源代码中硬编码密钥
- 始终使用环境变量或密钥管理器
- 启动时验证所需的密钥是否存在
- 轮换任何可能已暴露的密钥
## 安全响应协议
如果发现安全问题:
1. 立即停止
2. 使用 **security-reviewer** 代理
3. 在继续之前修复关键问题
4. 轮换任何已暴露的密钥
5. 审查整个代码库中的类似问题

29
rules/zh/testing.md Normal file
View File

@@ -0,0 +1,29 @@
# 测试要求
## 最低测试覆盖率80%
测试类型(全部必需):
1. **单元测试** - 单个函数、工具、组件
2. **集成测试** - API 端点、数据库操作
3. **E2E 测试** - 关键用户流程(框架根据语言选择)
## 测试驱动开发
强制工作流:
1. 先写测试RED
2. 运行测试 - 应该失败
3. 编写最小实现GREEN
4. 运行测试 - 应该通过
5. 重构IMPROVE
6. 验证覆盖率80%+
## 测试失败排查
1. 使用 **tdd-guide** 代理
2. 检查测试隔离
3. 验证模拟是否正确
4. 修复实现,而非测试(除非测试有误)
## 代理支持
- **tdd-guide** - 主动用于新功能,强制先写测试