编码规范生成器
版本: 1.0 | 更新: 2026-02-02
本技能用于帮助生成标准化的编程语言开发规范文档。
概述
此 Skill 提供一套标准化的规范编写模板和流程,确保不同语言的规范文档具有一致的结构和质量。
同时要求:通过此 Skill 生成的任何规范类 Skill,都必须明确说明“它做了什么、为什么需要、什么时候必须用”,并把每个知识点写成一眼就懂的简单句,像小学 1+1=2 一样直观。
通用 Skill 方法论(必须遵循)
本质定义(元目标)
Skill = 把一个“技术名词 / 机制 / 选项”,转化为“可稳定做出正确工程决策的能力”。
必须回答的三问
- •它是什么。
- •什么时候该用 / 什么时候不该用。
- •用错的代价是什么。
四层能力模型
| 层级 | 关注点 | 最小输出 |
|---|---|---|
| 语义层(Concept) | 它在解决什么问题 | 一句话目的,不提 API/配置 |
| 行为层(Mechanism) | 系统内部发生了什么 | 执行顺序 + 状态变化 |
| 影响层(Impact) | 它改变了什么 | 至少覆盖一个工程维度 |
| 决策层(Decision) | 如何做选择 | if 条件 + then 建议 + 强度级别 |
标准输出结构(7 部分)
- •问题空间(Problem Space):这个机制出现前的问题与触发规模。
- •核心语义(Core Concept):一句话定义,并说明它不是什么。
- •系统行为(System Mechanism):执行顺序、状态变化、关键分支。
- •影响分析(Engineering Impact):正向收益与负向成本。
- •风险边界(Failure Modes):典型误用与隐性失败场景。
- •决策规则(Decision Rules):适用条件、禁用条件、替代方案。
- •记忆锚点(Mental Model):不超过 20 字的触发句。
落地要求(必须)
关键技术点必须覆盖四层能力模型,并尽量按 7 部分结构组织内容。
适用范围提示
这套方法论与具体技术无关,适用于语言规范、架构决策、中间件选型、性能与安全规则等。
何时使用此 Skill
| 场景 | 触发词 |
|---|---|
| 创建新语言规范 | 创建 Golang 规范、Python 规范、TypeScript 规范 |
| 补充规范内容 | 补充规范、完善规范、添加规范条目 |
| 规范结构咨询 | 规范怎么写、规范模板、规范结构 |
| 参考规范 | 参考阿里巴巴规范、Google 规范 |
规范文档标准结构
目录结构模板
code
.claude/skills/{language}-guidelines/
├── SKILL.md
└── references/
├── naming.md
├── constants.md
├── code-format.md
├── oop.md
├── functional.md
├── coding-style.md
├── error-handling.md
├── logging.md
├── testing.md
├── concurrency.md
├── performance.md
├── security.md
├── database.md
├── api.md
└── project-structure.md
| 文件 | 说明 |
|---|---|
SKILL.md | 主入口文件(必须) |
references/ | 详细规范目录 |
references/naming.md | 命名规范 |
references/constants.md | 常量定义 |
references/code-format.md | 代码格式 |
references/oop.md | OOP/面向对象规约(视语言) |
references/functional.md | 函数式编程规约(视语言) |
references/coding-style.md | 代码风格 |
references/error-handling.md | 错误/异常处理 |
references/logging.md | 日志规范 |
references/testing.md | 测试规范 |
references/concurrency.md | 并发控制 |
references/performance.md | 性能优化 |
references/security.md | 安全规范 |
references/database.md | 数据库规范(后端适用) |
references/api.md | API 设计规范 |
references/project-structure.md | 工程结构规范 |
SKILL.md 模板
markdown
---
name: {language}-guidelines
description: {语言名称} 编码规范最佳实践。涵盖命名约定、代码格式、错误处理、日志规范、测试规范、性能优化、安全规范等。当编写 {语言} 代码或进行代码审查时使用。
metadata:
author: {作者}
version: "1.0"
compatibility: {兼容版本}
---
# {语言名称} 编码规范
> 版本: 1.0 | 更新: {日期}
>
> {规范来源说明}
---
## 概述
{规范适用场景和目标说明}
### 技术栈
| 组件 | 版本 | 说明 |
|------|------|------|
| {语言/框架} | {版本} | {说明} |
## 必须说明(三要素)
- 做了什么:{一句话说明该规范 Skill 提供的能力}
- 为什么需要:{一句话说明它解决的痛点或风险}
- 什么时候必须用:{列出必须使用的具体场景/条件}
---
## 何时使用此 Skill
| 场景 | 触发词 |
|------|--------|
| 编写代码 | 写 {语言}、写函数、写类 |
| 命名咨询 | 怎么命名、变量名、函数名 |
| 代码审查 | 审查代码、code review |
| 最佳实践 | 最佳实践、规范、标准写法 |
---
## 快速参考
### 核心规范速查
| 规范 | 要点 |
|------|------|
| **命名** | {命名规则要点} |
| **格式** | {格式规则要点} |
| **错误处理** | {错误处理要点} |
| **日志** | {日志规则要点} |
### 禁止项速查
| ❌ 禁止 | ✅ 正确做法 |
|--------|-----------|
| {禁止项} | {正确做法} |
---
## 详细规范目录
| 主题 | 文件 | 内容概要 |
|------|------|---------|
| **命名规范** | [naming.md](references/naming.md) | {概要} |
| **代码格式** | [code-format.md](references/code-format.md) | {概要} |
| ... | ... | ... |
---
## 代码评审 Checklist
### 必查项
| 检查点 | 说明 |
|--------|------|
| **命名规范** | 是否符合命名规则 |
| **代码格式** | 是否符合格式要求 |
| **错误处理** | 是否正确处理错误 |
| **日志规范** | 是否有必要的日志 |
| **测试覆盖** | 是否有单元测试 |
---
## 版本历史
| 版本 | 日期 | 变更 |
|------|------|------|
| 1.0 | {日期} | 初始版本 |
各主题规范编写模板
naming.md 模板
markdown
# 命名规范
> {语言} 编码规范 - 命名约定
---
## 基本规则(强制)
### 命名禁则
| 规则 | 说明 | 示例 |
|------|------|------|
| {规则1} | {说明} | ❌ {反例} |
| {规则2} | {说明} | ❌ {反例} |
### 命名风格
| 类型 | 风格 | 示例 |
|------|------|------|
| 变量 | {风格} | `{示例}` |
| 函数/方法 | {风格} | `{示例}` |
| 常量 | {风格} | `{示例}` |
| 类/结构体 | {风格} | `{示例}` |
| 包/模块 | {风格} | `{示例}` |
---
## 详细规则
### 变量命名
{详细规则和示例}
### 函数/方法命名
{详细规则和示例}
### 类/结构体命名
{详细规则和示例}
---
## 命名禁则速查
| ❌ 禁止 | ✅ 正确 | 原因 |
|--------|--------|------|
| {禁止项} | {正确} | {原因} |
规范条目编写格式
表达要求(必须):每条知识点都要用“结论 + 原因”的最简句子说明,避免术语堆叠,保证像“1+1=2”一样一眼就懂。
示例要求(必须):示例代码中禁止行尾注释,说明用独立行注释。
覆盖要求(必须):关键技术点要能映射到语义/行为/影响/决策四层,并给出可执行的 if/then 规则。
每条规范应包含以下要素:
1. 规范级别标识
| 级别 | 标识 | 说明 |
|---|---|---|
| 强制 | 【强制】 | 必须遵守,违反可能导致问题 |
| 推荐 | 【推荐】 | 建议遵守,提升代码质量 |
| 参考 | 【参考】 | 可选遵守,团队可自行决定 |
2. 规范结构
markdown
**【级别】规范内容描述**
> 说明:对规范的解释和扩展说明
```{语言}
// ❌ 反例 - {反例说明}
{反例代码}
// ✅ 正例 - {正例说明}
{正例代码}
code
### 3. 表格速查
每个规范文件末尾应有禁则速查表:
```markdown
## 禁则速查
| ❌ 禁止 | ✅ 正确 | 原因 |
|--------|--------|------|
| {禁止项} | {正确做法} | {原因} |
各语言规范编写要点
Golang 规范要点
| 主题 | 重点内容 |
|---|---|
| 命名 | 驼峰命名、导出规则(大写开头)、包命名 |
| 格式 | gofmt 强制、行长度、空行 |
| 错误处理 | error 返回值、errors.Wrap、panic 使用 |
| 并发 | goroutine、channel、sync 包、context |
| 接口 | 小接口原则、接口放调用方 |
| 项目结构 | /cmd, /internal, /pkg 标准布局 |
Python 规范要点
| 主题 | 重点内容 |
|---|---|
| 命名 | PEP 8 规范、snake_case、UPPER_CASE |
| 格式 | 缩进、行长度、空行、导入顺序 |
| 类型 | Type Hints、Optional、Union |
| 异常 | try-except、自定义异常、异常链 |
| 文档 | docstring 格式、类型注释 |
| 虚拟环境 | venv、requirements.txt、pyproject.toml |
TypeScript 规范要点
| 主题 | 重点内容 |
|---|---|
| 命名 | camelCase、PascalCase、接口前缀 I |
| 类型 | 严格模式、避免 any、类型推断 |
| 格式 | Prettier、ESLint、缩进 |
| 模块 | ES Modules、默认导出、命名导出 |
| 异步 | async/await、Promise、错误处理 |
| 函数式 | 不可变性、纯函数、高阶函数 |
参考资料模板
在规范末尾列出参考来源:
markdown
---
## 参考资料
| 来源 | 说明 |
|------|------|
| [阿里巴巴 Java 开发手册](链接) | 编程规约、异常日志、单元测试等 |
| [Google {语言} Style Guide](链接) | 官方风格指南 |
| [Effective {语言}](链接) | 最佳实践书籍 |
使用流程
创建新语言规范
- •
复制目录结构
codecp -r .claude/skills/java-spring-guidelines .claude/skills/{language}-guidelines - •
修改 SKILL.md
- •更新 name、description
- •更新技术栈信息
- •更新触发词
- •补充“做了什么 / 为什么需要 / 什么时候必须用”三要素
- •
逐个编写 references 下的规范文件
- •按语言特性调整内容
- •保持统一的格式和结构
- •确保有代码示例
- •
验证规范完整性
- •检查所有链接有效
- •检查代码示例正确
- •检查表格格式正确
规范质量检查清单
| 检查项 | 要求 |
|---|---|
| ✅ 结构完整 | 包含所有必要的规范主题 |
| ✅ 三问齐全 | 能回答是什么 / 何时用或不用 / 用错代价 |
| ✅ 三要素清晰 | 明确写出做了什么、为什么需要、什么时候必须用 |
| ✅ 四层覆盖 | 语义/行为/影响/决策层至少各有输出 |
| ✅ 决策可执行 | if/then/强度级别可直接写进规范或 checklist |
| ✅ 风险边界清晰 | 明确误用与失败场景 |
| ✅ 示例无行尾注释 | 示例代码只用独立行注释 |
| ✅ 表述极简 | 每条知识点像 1+1=2 一样直白易懂 |
| ✅ 格式统一 | 使用统一的 Markdown 格式 |
| ✅ 代码示例 | 每条规则有正反例代码 |
| ✅ 表格速查 | 每个文件有禁则速查表 |
| ✅ 链接有效 | 所有引用链接可访问 |
| ✅ 语言准确 | 代码语法正确可运行 |
| ✅ 规范分级 | 明确强制/推荐/参考级别 |