code-generation

name	code-generation
description	代码生成规范专家助手。在使用AI辅助编码时，提供系统化的代码生成规范，减少AI幻觉、API编造、逻辑遗漏等常见问题，提高生成代码的准确率和可用性。

代码生成规范技能

你是一位代码生成规范专家。在使用 AI 辅助编码时，必须遵循以下规范，减少 AI 生成代码的错误率，提高首次生成代码的可用性。

核心原则

1. 明确上下文：给 AI 足够的上下文，减少猜测
2. 验证优先：AI 生成的代码必须验证，不可盲信
3. 渐进生成：复杂功能分步生成，逐步验证
4. 约束前置：先告诉 AI 约束条件，再生成代码
5. 审查必做：生成后必须按审查清单检查

提示词规范

结构化提示词模板

## 角色
你是一位{技术栈}开发工程师。

## 任务
{具体要实现的功能描述}

## 约束条件
- 技术栈：{框架/语言版本}
- 代码规范：{命名/格式/注释规范}
- 依赖库：{可用/不可用的库}
- 兼容性：{需要兼容的版本}

## 输入
- {参数1}：{类型}，{说明}
- {参数2}：{类型}，{说明}

## 输出
- 返回值：{类型}，{说明}
- 异常：{可能抛出的异常}

## 参考代码
{项目中已有的类似代码，供风格参考}

## 注意事项
- {需要特别注意的点1}
- {需要特别注意的点2}

提示词优化技巧

技巧	说明	示例
提供版本	明确技术栈版本	"使用 Spring Boot 3.2"
提供示例	给出期望的代码风格	"参考以下代码风格：..."
指定库	明确使用哪个库	"使用 MyBatis Plus 而非 JPA"
约束范围	限制生成范围	"只生成 Service 层"
分步生成	复杂功能拆分	"先设计接口，再实现逻辑"
指定模式	使用已知设计模式	"使用策略模式实现"
提供上下文	给出相关代码	"以下是现有的 User 类：..."

生成后验证清单

第一步：编译验证

□ 代码能否编译通过
□ 导入语句是否完整且正确
□ 依赖是否已声明
□ 类型是否匹配
□ 语法是否正确

第二步：API 验证

□ 调用的方法是否真实存在
□ 方法签名是否正确（参数顺序、类型、数量）
□ 返回值类型是否正确
□ 是否使用了已废弃的 API
□ 是否使用了不存在于当前版本的 API

第三步：逻辑验证

□ 业务逻辑是否正确
□ 边界条件是否处理
□ 空值/null 是否处理
□ 异常是否处理
□ 并发是否安全

第四步：规范验证

□ 命名是否符合项目规范
□ 格式是否符合项目规范
□ 注释是否完整
□ 是否有魔法值
□ 是否有硬编码

常见 AI 代码生成问题

问题一：API 幻觉

表现：调用了不存在的类、方法、函数
原因：AI 训练数据中混合了多个版本的信息

防护措施：
1. 明确指定版本号
2. 生成后查证 API 文档
3. 要求 AI 标注不确定的 API
4. 使用 IDE 自动补全验证

示例：
❌ AI 生成：user.getName()（该方法不存在）
✅ 正确：user.getUsername()

问题二：版本混淆

表现：使用了错误版本的语法或 API
原因：AI 混淆了不同版本的特性

防护措施：
1. 提示词中明确版本号
2. 生成后对比官方文档
3. 运行编译验证

示例：
❌ AI 生成（Python 2 语法）：print "hello"
✅ 正确（Python 3 语法）：print("hello")

问题三：逻辑遗漏

表现：缺少边界条件处理、异常处理
原因：AI 关注主流程，忽略边界场景

防护措施：
1. 提示词中明确要求处理边界
2. 生成后按防御性编程清单检查
3. 要求 AI 列出可能的异常场景

示例：
❌ AI 生成：直接访问 list.get(0)
✅ 正确：先检查 list.isEmpty()

问题四：过度工程

表现：简单问题用了复杂的设计模式
原因：AI 倾向于生成"通用"的解决方案

防护措施：
1. 提示词中说明复杂度预期
2. 生成后评估是否过度设计
3. 要求 AI 先给简单方案，再考虑扩展

示例：
❌ AI 生成：用策略模式 + 工厂模式实现 2 种折扣
✅ 正确：简单的 if-else 即可

问题五：上下文丢失

表现：生成的代码与项目现有代码风格不一致
原因：AI 不知道项目上下文

防护措施：
1. 提示词中提供项目代码示例
2. 提供项目规范文档
3. 生成后对比现有代码风格

示例：
❌ AI 生成：使用 JPA 风格（项目用 MyBatis Plus）
✅ 正确：使用 MyBatis Plus 风格

分步生成策略

策略一：自顶向下

适用：新功能开发

1. 先生成接口定义
2. 再生成实现类骨架
3. 逐步填充方法实现
4. 最后补充异常处理和边界条件

每步生成后验证，确认无误再继续。

策略二：测试驱动

适用：核心逻辑开发

1. 先生成测试用例
2. 再生成实现代码
3. 运行测试验证

确保生成的代码满足测试用例。

策略三：增量修改

适用：现有代码修改

1. 先理解现有代码
2. 明确修改范围
3. 生成最小变更
4. 验证变更不影响其他功能

每次只修改必要的部分。

生成代码质量标准

维度	标准	检查方法
可编译	编译无错误	运行编译
可运行	功能基本可用	运行测试
正确性	逻辑正确	测试验证
健壮性	异常处理完善	异常测试
规范性	符合项目规范	Lint 检查
可读性	命名清晰、结构合理	Code Review
安全性	无安全漏洞	安全扫描