代码合规检查Skill：规范与标准检查

一、代码合规检查Skill的设计

代码合规检查Skill的核心目标是自动化检测代码是否遵循预设的编码规范和行业标准，在开发流程早期发现合规问题，减少合规风险。该Skill通过解析代码抽象语法树（AST）、正则匹配、依赖分析等多种技术手段，对代码库进行全方位的合规扫描。

设计原则包括：可扩展性（支持自定义规则）、准确性（降低误报率）、高效性（快速扫描大型代码库）、可集成性（无缝接入CI/CD流水线）。Skill架构通常由规则引擎、扫描器、报告生成器三个核心组件构成。

核心价值：将合规检查左移到开发阶段，避免在代码审查或生产部署时才发现合规问题，大幅降低修复成本和法律风险。

编码风格合规

自动检查PEP8、ESLint等编码规范，确保团队代码风格一致性

行业法规合规

检测代码中对GDPR、PCI-DSS、HIPAA等法规的遵循情况

许可证合规

自动扫描项目依赖的许可证类型，检测冲突和风险

无障碍检查

依照WCAG标准检查Web应用的无障碍访问合规性

二、编码风格合规

编码风格合规是代码合规检查的最基础层级。统一且规范的代码风格不仅提高代码可读性，还能减少因风格差异导致的代码审查争论。代码合规检查Skill集成主流的语言规范检查工具，并提供自定义规则适配能力。

2.1 PEP8/PEP257 Python规范检查

Python社区有成熟的PEP8（代码风格指南）和PEP257（文档字符串约定）规范。Skill可以集成pycodestyle、pydocstyle等工具，自动检查缩进、命名约定、行长度、空白符、文档字符串格式等。示例配置如下：

[pycodestyle]
max-line-length = 100
ignore = E402, W503
exclude = .git, __pycache__, venv, migrations

[pydocstyle]
convention = numpy
add-ignore = D107, D203

检查结果会按严重级别（错误、警告、建议）分类输出，并支持自动修复（如自动格式化、添加文档字符串模板）。

2.2 ESLint/Prettier JavaScript规范检查

对于JavaScript/TypeScript项目，Skill集成ESLint进行静态代码分析，配合Prettier进行代码格式化。ESLint的可插拔架构支持数百种规则，覆盖语法错误、最佳实践、安全漏洞等。典型配置：

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "rules": {
    "no-console": "warn",
    "@typescript-eslint/no-explicit-any": "error",
    "max-len": ["error", { "code": 120 }]
  }
}

2.3 Pylint/flake8集成检查

Pylint提供更深入的代码分析，包括代码复杂度检查、重复代码检测、潜在bug发现。flake8则将pycodestyle、pyflakes和mccabe整合在一起，提供一站式检查。Skill可将这些工具整合为一个统一检查流程：

# 合规检查Skill：Python编码规范一站式检查
def check_python_compliance(file_path):
    checks = [
        ("pycodestyle", run_pycodestyle),
        ("pydocstyle", run_pydocstyle),
        ("pylint", run_pylint),
        ("flake8", run_flake8),
        ("mypy", run_mypy_type_check)
    ]
    results = []
    for name, check_func in checks:
        result = check_func(file_path)
        results.append(format_result(name, result))
    return aggregate_report(results)

2.4 自定义团队编码规则适配

每支团队的编码规范都有独特之处。代码合规检查Skill支持通过YAML或JSON配置文件定义团队自定义规则：

# team_rules.yaml
custom_rules:
  - id: TEAM-001
    description: "禁止使用var声明变量，必须使用let或const"
    language: javascript
    severity: error
    pattern: "\\bvar\\s+"
    message: "请使用 let 或 const 代替 var"

  - id: TEAM-002
    description: "所有API端点必须添加速率限制"
    language: python
    severity: warning
    pattern: "def\\s+(get|post|put|delete)_\\w+"
    message: "API端点建议添加 @rate_limit 装饰器"

最佳实践：自定义规则应遵循由宽到严的演进策略。先在warning级别启用，收集反馈后再逐步提升到error级别，避免一次性引入过多规则导致开发效率下降。

三、行业法规合规检查

行业法规合规是代码合规检查的高阶需求。不同行业和地区的软件产品需遵循特定的法律法规，其中GDPR、PCI-DSS、HIPAA是最常见的三大合规标准。代码合规检查Skill通过静态分析和模式匹配，帮助开发团队在编码阶段就识别潜在的法规风险。

3.1 GDPR合规检查

通用数据保护条例（GDPR）是欧盟的数据保护法规，适用于处理欧盟公民个人数据的任何组织。GDPR合规检查聚焦于以下方面：

个人信息处理检查：检测代码中是否存在未经授权的个人数据收集（如IP地址、Cookie、设备指纹等），确保数据处理有明确的法律依据
数据最小化原则：检查数据采集范围，确保只收集业务必需的数据字段，避免过度采集
用户同意机制：检测是否实现了明确的用户同意获取机制，包括同意确认、撤回同意的功能
数据访问与删除权：检查是否提供了数据下载和数据删除的API端点
数据传输限制：检测是否有将个人数据传输到非欧盟地区的逻辑，确保存在适当保障措施

// GDPR合规检查示例：检测个人数据处理
function checkGDPRCompliance(codeAST) {
  const violations = [];

  // 检测未授权的数据采集
  if (detectDataCollectionWithoutConsent(codeAST)) {
    violations.push({
      type: 'GDPR-001',
      severity: 'critical',
      message: '发现未获取用户同意的数据采集逻辑'
    });
  }

  // 检测数据最小化违规
  if (detectExcessiveDataCollection(codeAST)) {
    violations.push({
      type: 'GDPR-002',
      severity: 'high',
      message: '发现超出必要范围的数据采集'
    });
  }

  return violations;
}

3.2 PCI-DSS合规检查

支付卡行业数据安全标准（PCI-DSS）适用于处理信用卡/借记卡信息的系统。Skill的PCI-DSS检查覆盖以下关键领域：

支付数据处理：检测代码中是否明文处理信用卡号、CVC、PIN等敏感数据，确保使用tokenization或加密方式
加密存储：检查敏感数据的存储是否使用强加密算法（如AES-256），是否存在明文存储的路径
访问控制：检测支付相关接口是否有适当的身份认证和授权机制，防止未授权访问
日志记录：检查日志系统中是否无意中记录了完整的信用卡号或敏感认证信息
安全传输：确保支付相关API强制使用TLS 1.2+加密传输，检查是否为HTTP明文传输

重要提示：PCI-DSS合规检查应定期执行（至少每季度一次），并保留检查记录用于合规审计。任何不合规代码必须在部署到生产环境前修复。

3.3 HIPAA合规检查

健康保险便携性和责任法案（HIPAA）适用于处理受保护健康信息（PHI）的系统。HIPAA合规检查要点：

健康数据处理：检测代码中是否有对PHI（如病历、诊断结果、社保号）的不当处理逻辑
审计日志：检查是否对所有PHI访问操作进行了完整的审计日志记录，包括谁、何时、为何访问
加密传输：确保所有包含PHI的数据传输使用端到端加密，检测是否存在未加密的传输通道
最小必要原则：检查代码是否遵循最小必要原则，只访问完成特定任务所需的最少健康信息
数据备份与灾备：检查是否有PHI数据的加密备份机制和灾难恢复计划

关键要点：GDPR、PCI-DSS、HIPAA三大合规体系有重叠也有区别。代码合规检查Skill应区分不同场景启用不同的检查规则集，避免不必要的性能开销。例如，支付相关项目检查PCI-DSS规则，医疗健康项目检查HIPAA规则，面向欧盟用户的项目检查GDPR规则。

四、开源许可证合规

开源许可证合规是软件项目容易被忽视但风险极高的合规领域。代码合规检查Skill通过依赖分析自动扫描项目使用的所有开源组件，识别许可证类型、检测许可证冲突、生成合规审计报告。

4.1 检查项目依赖的许可证类型

Skill扫描项目的依赖清单文件（如package.json、requirements.txt、pom.xml、go.mod等），解析每个依赖的许可证信息：

# 依赖许可证扫描输出示例
Dependency Scan Report
======================
Package                  Version    License           Risk
----------------------------------------------------------
express                  4.18.2     MIT               Low
lodash                   4.17.21    MIT               Low
chart.js                 4.4.0      MIT               Low
gpl-library              3.0.1      GPL-3.0           High
agpl-tool                2.1.0      AGPL-3.0          Critical
commons-codec            1.15       Apache-2.0        Low
----------------------------------------------------------
高风险依赖: 2
合规状态: 不合格 (请立即处理GPL/AGPL依赖)

4.2 识别传染性许可证

某些开源许可证（如GPL、AGPL）具有"传染性"——如果项目使用了这些许可证的代码，项目本身可能也需要以相同许可证开源。Skill自动标记这些风险，并根据项目的主许可证给出兼容性建议：

项目许可证	GPL兼容	AGPL兼容	说明
MIT	是（静态链接需谨慎）	否	AGPL要求整个项目以AGPL开源
Apache 2.0	是（v2兼容）	否	需注意专利条款的差异
GPL v3	是	否	GPL v3与AGPL不直接兼容
商业闭源	否（动态链接需评估）	否	商业闭源项目应避免使用GPL/AGPL

4.3 许可证冲突检测

当项目中同时存在多个不兼容许可证的依赖时，Skill会抛出冲突警告。常见冲突场景包括：

GPL v2 + Apache 2.0（GPL v2与Apache 2.0不兼容）
AGPL + 任何非AGPL开源许可证（AGPL要求整个项目AGPL）
GPL + 商业闭源许可证（GPL要求衍生作品也GPL）
自定义许可证 + 标准开源许可证（自定义条款可能与标准许可证冲突）

合规建议：对于商业闭源项目，优先选择MIT、Apache 2.0、BSD等宽松许可证的依赖库。当需要使用GPL/AGPL库时，考虑：①寻找功能等效的宽松许可证替代库；②将GPL库隔离为独立进程通过IPC通信；③联系版权方获取商业授权。

4.4 生成合规报告用于审计

Skill可生成多种格式的合规审计报告（JSON、HTML、PDF、Markdown），内容包括：许可证清单、风险等级评估、冲突检测结果、修复建议、历史检查记录等。适合提交给法务团队或合规审计部门。

# 生成审计报告命令示例
skill compliance --report --format html --output compliance-report.html
skill compliance --report --format json --output compliance-report.json

实践建议：将许可证合规检查集成到CI/CD流水线中，每次构建时自动执行。设置合规门禁（Quality Gate），当检测到高风险许可证或严重冲突时，阻止构建通过并通知相关负责人。