关于 coding-standards
coding-standards(Corbat)为编码 Agent 提供团队规范、按技术栈匹配的配置档案和验证反馈,适合希望在单 Agent 或多 Agent 开发流程中统一架构、质量与安全检查的团队。
主要功能
- 01检测项目技术栈并加载配置档案
- 02提供架构与代码质量规则
- 03执行安全导向的检查
- 04依据配置规范验证代码
- 05通过 .corbat.json 自定义规则
适用场景
- 01为新项目设定开发规范
- 02在多 Agent 交付中共享标准
- 03按代码评审要求检查变更
- 04指导遗留代码现代化
MCP 相关
Corbat 是面向编码工具的 MCP 服务,向 MCP 客户端提供规范上下文和验证能力。它检测项目技术栈并提供匹配的规则与反馈;不会修改 AI 生成的输出。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
5收录的工具列表 · 更新于 2 周前
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| task | string | 是 | 你正在实现的内容(例如,“创建支付服务”、“修复登录错误”) |
| project_dir | string | 否 | 用于自动检测的项目目录(可选) |
详细介绍
CORBAT MCP
面向 AI 编码 Agent 的策略与质量引擎
为 Agent 辅助的软件交付提供共享标准、上下文和验证关卡。
专为兼容 MCP 的编码工具和多 Agent 工作流设计。请参阅兼容性说明。
⚡ 30 秒即可试用——只需添加以下配置,即可开始编码。
问题
AI 生成的代码通常能在本地运行,却不符合团队特定的审查要求:
| 使用 Corbat 前 | 使用 Corbat 后 |
|---|---|
| 方法超过 50 行 | 每个方法最多 20 行 |
| 不使用依赖注入 | 使用接口实现适当的 DI |
throw new Error('failed') | 带上下文的自定义异常 |
| 缺少测试或测试过少 | 包含测试,采用 TDD 方法 |
| 上帝类、职责混杂 | SOLID 原则、清晰分层 |
| 仅在本地可运行 | 实现便于审查,并带有明确检查 |
Corbat 会在实现前向 Agent 提供团队标准,并提供验证工具,供审查或交接前使用。
快速开始
1. 添加到 MCP 配置中:
{
"mcpServers": {
"corbat": {
"command": "npx",
"args": ["-y", "@corbat-tech/coding-standards-mcp"]
}
}
}
2. 配置文件位置:
| 工具 | 位置 |
|---|---|
| Cursor | .cursor/mcp.json |
| VS Code | .vscode/mcp.json |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
| JetBrains | 设置 → AI 助手 → MCP |
| Claude Desktop | ~/.config/Claude/claude_desktop_config.json |
| Claude Code | claude mcp add corbat -- npx -y @corbat-tech/coding-standards-mcp |
常见兼容 MCP 的工具请参阅完整设置指南
3. 完成。 Corbat 可以自动检测你的技术栈并返回相应标准。
零开销。 Corbat 在本地运行,检测技术栈耗时约 50 ms。之后,它只会为 AI 提供上下文。
完全可自定义。 不喜欢某条规则?可在
.corbat.json中覆盖。跳转到自定义 →
实际效果
You: "Create a user registration service"
不使用 Corbat,你会得到:
class UserService {
private users: Map<string, User> = new Map();
register(name: string, email: string, password: string) {
if (!name || !email || !password) throw new Error('Invalid input');
const user = { id: crypto.randomUUID(), name, email, password };
this.users.set(user.id, user);
return user;
}
}
// ✗ Hardcoded storage ✗ Password in plain text ✗ Generic error ✗ No tests
使用 Corbat,你会得到:
// Domain
interface UserRepository {
save(user: User): Promise<void>;
findByEmail(email: string): Promise<User | null>;
}
class EmailAlreadyExistsError extends Error {
constructor(email: string) {
super(`Email already registered: ${email}`);
}
}
// Application
class RegisterUserUseCase {
constructor(
private readonly repository: UserRepository,
private readonly hasher: PasswordHasher
) {}
async execute(input: RegisterUserInput): Promise<User> {
const existing = await this.repository.findByEmail(input.email);
if (existing) throw new EmailAlreadyExistsError(input.email);
const user = User.create({
...input,
password: await this.hasher.hash(input.password)
});
await this.repository.save(user);
return user;
}
}
// ✓ Repository interface ✓ Password hashing ✓ Custom error ✓ Testable
// Test included
describe('RegisterUserUseCase', () => {
const repository = { save: vi.fn(), findByEmail: vi.fn() };
const hasher = { hash: vi.fn() };
const useCase = new RegisterUserUseCase(repository, hasher);
beforeEach(() => vi.clearAllMocks());
it('should hash password before saving', async () => {
repository.findByEmail.mockResolvedValue(null);
hasher.hash.mockResolvedValue('hashed_password');
await useCase.execute({ name: 'John', email: '[email protected]', password: 'secret' });
expect(hasher.hash).toHaveBeenCalledWith('secret');
expect(repository.save).toHaveBeenCalledWith(
expect.objectContaining({ password: 'hashed_password' })
);
});
it('should reject duplicate emails', async () => {
repository.findByEmail.mockResolvedValue({ id: '1', email: '[email protected]' });
await expect(
useCase.execute({ name: 'John', email: '[email protected]', password: 'secret' })
).rejects.toThrow(EmailAlreadyExistsError);
});
});
这就是 Corbat 要求 Agent 在交接前考虑的结构。
Corbat 提供的功能
Corbat 会在生成前提供这些护栏,并在迭代过程中执行验证检查:
代码质量
| 规则 | 重要性 |
|---|---|
| 每个方法最多 20 行 | 函数易于阅读、测试且职责单一 |
| 每个类最多 200 行 | 单一职责原则 |
| 名称有意义 | 不使用 data、info、temp、x |
| 不使用魔法数字 | 使用描述性名称的常量 |
架构
| 规则 | 重要性 |
|---|---|
| 依赖使用接口 | 代码可测试,易于模拟 |
| 分层隔离 | 将领域逻辑与基础设施隔离 |
| 六边形/整洁架构模式 | 业务规则不依赖框架 |
错误处理
| 规则 | 重要性 |
|---|---|
| 自定义异常 | 使用 UserNotFoundError,而不是 Error('not found') |
| 错误上下文 | 在错误中包含 ID、值和状态 |
| 不要使用空的 catch 块 | 每个错误都必须处理或向上传播 |
面向安全的检查
| 规则 | 重要性 |
|---|---|
| 输入验证 | 在边界处拒绝无效数据 |
| 不要硬编码密钥 | 仅使用环境变量 |
| 参数化查询 | 防止 SQL 注入 |
| 输出编码 | 防止 XSS |
基准测试结果 v3.0
我们在 6 种语言的 15 个场景中评估了 Corbat。主要基准测试报告的结果不一,应如实看待:按原始汇总分数,Corbat 在 15 个场景中赢得了 1 个;而另一种价值分析则发现,代码精简度和可维护性方面表现更佳。
数据支持的结论
最明显的观察结果是,使用 Corbat 指导生成的输出通常更精简、更聚焦:
| 场景 | 使用 Corbat | 不使用 Corbat | 含义 |
|---|---|---|---|
| Kotlin 协程 | 236 行 | 1,923 行 | 功能相同,维护量减少 8 倍 |
| Java 六边形架构 | 623 行 | 2,740 行 | 实现整洁架构,避免臃肿 |
| Go 整洁架构 | 459 行 | 2,012 行 | 符合 Go 惯用风格,而非用 Go 写 Java |
| TypeScript NestJS | 395 行 | 1,554 行 | 模式恰当,规模合适 |
这不足以证明质量普遍提升,但表明在某些工作流中,标准上下文可以减少过度生成。
价值指标
价值报告对同一数据集进行了重新加权,更侧重效率和可维护性:
| 指标 | 结果 | 含义 |
|---|---|---|
| 代码缩减 | 67% | 需要维护、审查和调试的代码更少 |
| 安全检查 | 100% | 基准测试模式检查未发现问题 |
| 可维护性 | 胜率 93% | 更易于理解和修改 |
| 架构效率 | 胜率 87% | 每行代码包含更好的模式 |
| 认知负担 | -59% | 新开发者上手更快 |
📊 详细价值分析
安全:未发现基准测试模式问题
我们使用受 OWASP Top 10 类别启发的模式检查分析了每个场景。这不能替代 SAST、DAST、依赖项扫描、人工审查或威胁建模。
- 未检测到 SQL/NoSQL 注入模式
- 未检测到 XSS 模式
- 未检测到硬编码凭据
- 边界处存在输入验证模式
- 基准测试样例中的错误消息未暴露堆栈跟踪
测试的语言与模式
| 语言 | 场景 | 模式 |
|---|---|---|
| ☕ Java | 5 | Spring Boot、DDD 聚合、六边形架构、Kafka 事件、Saga |
| 📘 TypeScript | 4 | Express REST、NestJS 整洁架构、React 组件、Next.js 全栈 |
| 🐍 Python | 2 | FastAPI CRUD、仓储模式 |
| 🐹 Go | 2 | HTTP 处理器、整洁架构 |
| 🦀 Rust | 1 | 使用 Repository Trait 的 Axum |
| 🟣 Kotlin | 1 | 协程 + 策略模式 |
内置配置文件
Corbat 会自动检测你的技术栈,并应用相应的规范:
| 配置文件 | 技术栈 | 你将获得 |
|---|---|---|
java-spring-backend | Java 21 + Spring Boot 3 | 六边形架构 + DDD、测试驱动开发(覆盖率 80% 以上) |
kotlin-spring | Kotlin + Spring Boot 3 | 协程、Kotest + MockK |
nodejs | Node.js + TypeScript | 整洁架构、Vitest |
nextjs | Next.js 14+ | App Router 模式、Server Components |
react | React 18+ | Hooks、Testing Library、无障碍组件 |
vue | Vue 3.5+ | Composition API、Vitest |
angular | Angular 19+ | 独立组件、Jest |
python | Python + FastAPI | 异步模式、pytest |
go | Go 1.22+ | 符合 Go 惯用风格的代码、表驱动测试 |
rust | Rust + Axum | 所有权模式、proptest |
csharp-dotnet | C# 12 + ASP.NET Core 8 | 整洁架构 + CQRS、xUnit |
flutter | Dart 3 + Flutter | BLoC/Riverpod、组件测试 |
自动检测: Corbat 会读取 pom.xml、package.json、go.mod、Cargo.toml 等文件。
何时使用 Corbat
| 使用场景 | Corbat 的帮助 |
|---|---|
| 启动新项目 | 从第一天起就采用正确的架构 |
| 多 Agent 交付 | 规划、实现、审查和安全 Agent 共享相同的策略上下文 |
| 经验水平各异的团队 | 规范变得明确且可重复执行 |
| 严格的代码审查标准 | Agent 可在交接前根据审查标准进行验证 |
| 受监管行业 | 安全和文档保持一致 |
| 遗留系统现代化 | 新代码遵循现代模式 |
何时可能不需要 Corbat
- 不在意质量的快速原型
- 写完就会丢弃的一次性脚本
- 希望通过犯错来学习的项目
自定义
选项 1:交互式设置
npx corbat-init
检测你的技术栈,并使用合理的默认值生成 .corbat.json。
选项 2:手动配置
在项目根目录中创建 .corbat.json:
{
"profile": "java-spring-backend",
"architecture": {
"pattern": "hexagonal",
"layers": ["domain", "application", "infrastructure", "api"]
},
"quality": {
"maxMethodLines": 20,
"maxClassLines": 200,
"minCoverage": 80
},
"rules": {
"always": [
"Use records for DTOs",
"Prefer Optional over null"
],
"never": [
"Use field injection",
"Catch generic Exception"
]
}
}
选项 3:使用模板
浏览 14 个可直接使用的模板,涵盖 Java、Python、Node.js、React、Go、Rust 等。
工作原理
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Your Prompt │────▶│ Corbat MCP │────▶│ AI + Rules │
└─────────────┘ └──────┬──────┘ └─────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ 1. Detect │ │ 2. Load │ │ 3. Inject │
│ Stack │ │ Profile │ │ Guardrails │
└────────────┘ └────────────┘ └────────────┘
pom.xml hexagonal max 20 lines
package.json + DDD + interfaces
go.mod + SOLID + custom errors
Corbat 不会修改 AI 的输出。它提供上下文、规范、配置文件和验证反馈,帮助 Agent 符合你的审查预期。
重要提示: 实际代码质量取决于模型、宿主工具、提示词、仓库上下文、测试和人工审查。请将 Corbat 视为策略与验证层,而非生产就绪的保证。
文档
| 资源 | 说明 |
|---|---|
| 设置指南 | 常见 MCP 兼容工具的安装说明 |
| 模板 | 可直接使用的 .corbat.json 配置 |
| 兼容性 | 支持的 AI 工具完整列表 |
| 基准测试分析 | 15 个场景的详细结果 |
| 多 Agent 架构 | Corbat 如何融入规划/审查/安全/发布 Agent 工作流 |
| 安全模型 | 本地执行模型、威胁模型和报告 |
| API 参考 | 工具、提示词和配置选项 |
让 Agent 输出更易于审查。
添加到 MCP 配置中即可完成:
{ "mcpServers": { "corbat": { "command": "npx", "args": ["-y", "@corbat-tech/coding-standards-mcp"] }}}
将 Corbat 用作共享规范上下文和本地质量门禁。
由 corbat-tech 开发
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。