AI编程实用场景及小技巧分享写作背景这两年在完成业务需求之余在做AI编程的探索与实践，最近两个月还算顺利（主要是Cla

本文档整理了在AI辅助编程过程中的实用技巧、原理分析和最佳实践，帮助开发者更高效地使用AI工具。

写作背景

这两年在完成业务需求之余在做AI编程的探索与实践，最近两个月还算顺利（主要是Claule 4、4.5 的横空出世吧😂，一些想法有了AI算力的支撑得到了验证）完成AI协同编程案例的落地，今天正好在公司内部做了AI协同编程分享，也正好是1024，笔耕不辍，就把分享内容中的平时积累的编程小技巧脱密后分享给大家，希望能给对AI编程有兴趣的同学有所帮助与启发。

1. 需求文档精准投喂策略

问题：产品需求文档通常包含多系统功能、背景信息等，全量投喂会导致AI理解偏差。

解决方案：

方式一：在AI IDE（作者公司所用AI IDE 支持这种方式）中引用文档的指定章节内容

方式二：人工将文档下载，对需求内容进行裁剪（例：需求文档中包含了购物车、订单内容，而你负责购物车中台的开发，只需要将需求中购物部分内容保留）

提取与当前开发任务直接相关的功能点，将需求文档与本项目相关的内容复制到项目目录下，直接引用经过裁剪的文档

2. 提示词迭代优化

最佳实践：

初版提示词完成后，让AI进行优化建议
关注提示词的结构化、明确性和完整性
验证AI对需求的理解是否准确

3. 会话管理策略

核心原则：不同类型任务使用独立会话

适用场景：

生成不同模块的代码
切换不同的开发阶段（设计→编码→测试）
处理不相关的功能需求

原因：避免上下文污染，确保AI专注当前任务

4. 工作空间精准定位

原因

明确告知AI当前工作范围，避免分析无关代码，提高响应速度和准确性。

使用技巧

文件级定位

@src/main/java/com/example/service/UserService.java
请优化这个服务类的性能

目录级定位

@src/main/java/com/example/controller/
分析所有Controller的异常处理是否规范

模块边界声明

当前任务范围：
- 包含：@com.example.order.*
- 排除：@com.example.payment.*（已完成，无需关注）

技巧要点：

使用 @ 符号明确引用文件或目录
大型项目先说明目录结构，再定位具体位置
明确排除不相关的代码区域
结合 .gitignore 思想，告知AI忽略的范围

5. 分步骤任务拆解

原因

复杂任务一次性完成容易出错且难以调试，拆分后可逐步验证，降低风险。

最佳实践

任务拆解示例：实现导出功能

步骤1：数据查询

任务：实现订单数据查询方法
- 输入：查询条件（时间范围、状态）
- 输出：List<OrderDTO>
- 要求：支持分页，优化SQL性能

步骤2：数据转换

任务：将OrderDTO转换为Excel行数据
- 输入：List<OrderDTO>
- 输出：List<Map<String, Object>>
- 要求：字段映射、格式化（日期、金额）

步骤3：文件生成

任务：使用EasyExcel生成文件
- 输入：List<Map<String, Object>>
- 输出：ByteArrayOutputStream
- 要求：添加表头、样式设置

步骤4：接口集成

任务：封装为HTTP接口
- 路径：/api/orders/export
- 响应：文件下载
- 要求：异常处理、日志记录

技巧要点：

按依赖关系排序（先底层后上层）
每步都有明确的输入输出定义
可独立测试每个步骤
步骤间通过接口（而非实现细节）耦合

6. 代码/文档生成好后，先让AI自检

原因

AI生成的代码可能存在潜在问题，自检能在提交前发现并修复大部分缺陷。

最佳实践

自检Checklist

请对生成的代码进行自检，并给出评估报告：

1⃣ 安全性
- [ ] 是否有SQL注入风险
- [ ] 是否有XSS攻击风险
- [ ] 敏感数据是否加密
- [ ] 权限校验是否完整

2⃣ 性能
- [ ] 是否存在N+1查询
- [ ] 是否有内存泄漏风险
- [ ] 循环中是否有重复计算
- [ ] 数据库索引是否合理

3⃣ 规范性
- [ ] 命名是否符合规范
- [ ] 注释是否完整
- [ ] 异常处理是否规范
- [ ] 日志记录是否合理

4⃣ 架构原则
- [ ] 是否遵循单一职责原则
- [ ] 是否违反分层架构
- [ ] 依赖关系是否合理

5⃣ 并发问题
- [ ] 是否有线程安全问题
- [ ] 分布式环境下是否正确
- [ ] 是否需要加锁或使用事务

请逐项检查并给出改进建议。

技巧要点：

使用标准化的检查清单
要求AI给出具体问题位置和改进代码
可以分类检查（先安全后性能）
检查结果要有优先级（严重/一般/建议）

7. 避免信息过载

原因

提供过多无关信息会稀释关键上下文，导致AI响应偏离重点或超出token限制。

最佳实践

❌ 不好的做法

请优化性能。
[粘贴整个项目的所有代码文件]

✅ 好的做法

请优化以下接口的性能：
接口：@OrderService.getOrderList()
问题：响应时间超过3秒
性能监控数据：
- SQL执行：2.5s（慢查询）
- 数据转换：0.3s
- 其他：0.2s

请重点分析SQL性能问题。

信息筛选原则

只提供与当前任务直接相关的代码
用摘要代替全文
提供问题现象和数据，而非全部日志
使用引用而非粘贴（如"参考Spring官方文档的事务管理章节"）

技巧要点：

问问自己："这个信息对AI完成任务是必需的吗？"
分层提供信息：先概览，需要时再提供细节
使用"按需加载"：AI询问时再补充

8. 明确边界条件

原因

明确告知AI哪些功能不需要实现，避免过度设计和无关代码。

最佳实践

【需求】实现用户登录功能

【包含功能】
✅ 用户名密码登录
✅ 生成JWT Token
✅ 登录失败次数限制（5次）

【不包含功能】
❌ 第三方登录（微信、QQ等）- 后续迭代
❌ 短信验证码登录 - 不在本期范围
❌ 图形验证码 - 使用现有组件
❌ 记住密码功能 - 产品未确认

【外部依赖】
- Redis：使用已有连接配置
- 短信服务：调用 SmsService.send()，无需实现

技巧要点：

说明不实现的原因（后续迭代/不在范围/已有实现）
明确外部依赖的调用方式
避免AI自作主张添加功能

9. 保持一致性

在同一会话中保持术语和概念的一致性
使用项目统一的命名规范

10.AI规则设置

每次会话时不需要每次都添加规则
用户规则：整个用户维度，可跨工程使用
工程规则：只适用于当前工程

用户规则

每个工程都需要添加的规则，存储在用户规则 user_rule.md
工程中通用的代码规范，手动存储在 .local 目录下或其它不可变目录


## 重要
 1. 使用简洁、直接的技术性回复
 2. 最小化输出token，避免冗余表达
 3. 专注解决具体问题，不提供无关信息
 4. 不使用表情符号（除非用户要求）
 5. 遵循现有代码规范和项目模式
 6. 编辑文件前必须先读取内容
 7. 生成的代码必须可立即运行
 8. 多工具调用按顺序执行，失败则停止

工程规则

当前工程会话内使用


## 重要规范
 1. 根据业务要求，自动识别遵循规范
 2. 只能访问当前项目内的文件和代码。
 3. 回答需用中文
 4. 生成类时，每个类单独用代码块
 5. 文件名和路径需用反引号包裹
 6. 代码生成需先简要说明，再输出代码
 7. 回答需优先结合用户当前工作区、活跃文件和上下文。
 8. 代码生成需先简要说明，再输出代码，文档使用Markdown格式。
 9. 不主动提出后续问题或建议。
 10. 安全第一：绝不执行恶意代码或暴露敏感信息
 11. 遵循现有代码规范和项目模式
 12. 优先使用targeted编辑而非重写大文件
 13. 编辑文件前必须先读取内容
 14. 使用grep搜索代码库而非bash命令
 15. 多工具调用按顺序执行，失败则停止
 16. 仅在当前工作目录内操作文件
 17. 删除操作需要用户确认

11.外网网页/API文档读取

参考前面的博文 blog.csdn.net/weixin_4258… 这个文档，在本地装个 playwright MCP，这样ai就能通过MCP工具读到接口平台的api文档，效果如下（假装有图片，截图涉密没放🐶）：

12. 反思模式：双智能体协作

原因

单一AI容易产生"认知偏差"，生成的代码可能存在逻辑漏洞或不符合最佳实践。通过引入"生产者-批评者"模式，能显著提升代码质量。

工作流程

执行：生产者智能体完成初始代码生成
评估：批评者智能体审查代码（准确性、规范性、完整性）
反思：根据反馈优化代码
迭代：重复流程直到达标

最佳实践

第一步：生产者角色

【角色】你是一位Java后端开发工程师

【任务】实现用户注册接口
- 参数校验
- 密码加密（BCrypt）
- 数据库存储
- 返回JWT Token

第二步：批评者角色

【角色】你是一位资深软件架构师和代码审查专家

【任务】审查上述用户注册代码，从以下维度评估：
1. 安全性（密码强度校验、SQL注入防护）
2. 性能（数据库索引、缓存策略）
3. 规范性（命名规范、异常处理）
4. 可维护性（代码复杂度、注释完整性）
5. 边界条件（重复注册、并发问题）

给出具体改进建议。

技巧要点：

为两个角色设置明确的系统提示（Prompt）
批评者要有明确的评审标准（Checklist）
迭代2-3次通常能达到较好效果
可以使用两个不同的agent（或者同一agent选不同模型）在同一个会话中模拟两个角色，效果会更好

13. 分隔符使用技巧

原因

清晰的结构能帮助AI准确理解指令、上下文、示例和输入的边界，减少误解和幻觉。

最佳实践

使用三重反引号

请总结以下代码的核心逻辑：
```java
public class UserService {
    // 代码内容
}

使用XML标签

<instruction>
生成单元测试代码
</instruction>

<context>
被测类：UserService
测试框架：JUnit 5 + Mockito
</context>

<code>
[粘贴代码]
</code>

使用分隔线

--- 指令 ---
生成Dockerfile

--- 环境要求 ---
Java 17
Spring Boot 3.0
MySQL 8.0

--- 参考配置 ---
[现有配置文件]

技巧要点：

复杂任务优先使用XML标签，最清晰
代码块必须用三重反引号包裹
多段内容用分隔线（---）区分
避免不同部分内容混在一起

14. 对话轮次控制

原因

长时间对话会导致上下文被压缩，AI可能"遗忘"早期指令或产生幻觉，代码质量反而下降。

最佳实践

轮次上限：单个会话不超过10轮对话
重启会话时机：
- 话题偏离原始需求
- AI开始重复或矛盾
- 需要切换到新任务模块
上下文总结：会话结束前要求AI总结关键决策和代码要点

示例

我们已经进行了8轮对话，请总结：
1. 已完成的功能模块
2. 关键技术决策
3. 待解决的问题
4. 下一步工作计划

总结后我将开启新会话继续。

技巧要点：

设置对话轮次提醒（第7-8轮开始准备收尾）
重要信息在新会话开始时重新声明
使用文档记录跨会话的决策链

最佳实践

完整上下文示例

【角色】资深Java开发工程师

【项目背景】
电商平台订单系统，日订单量10万+，要求高可用和高性能

【技术栈】
Spring Boot 3.0 + MyBatis-Plus + Redis + MySQL

【当前问题】
订单查询接口响应慢（平均2.5s），需要优化到500ms以内

【性能数据】
- SQL执行：2.2s（主要耗时）
- 数据转换：0.2s
- Redis缓存未启用

【相关代码】
@OrderService.java
@OrderMapper.xml

【约束条件】
- 不能修改数据库表结构（已上线）
- 需要保持接口兼容性
- 优先使用缓存而非改SQL

【任务】
给出优化方案和代码实现

技巧要点：

分层组织上下文（角色→背景→数据→约束→任务）
优先提供业务上下文，再提供技术细节
包含定量数据（性能指标、数据规模）
明确约束条件，避免不可行方案
使用工具自动化上下文收集（如日志分析、性能监控）

16. 结构化输出

原因

结构化输出便于后续处理、减少幻觉、易于集成到自动化流程中。

常用格式

1️⃣ JSON格式

请分析以下代码的复杂度，以JSON格式返回：
{
  "file": "文件名",
  "complexity": "复杂度等级（低/中/高）",
  "metrics": {
    "cyclomaticComplexity": 数值,
    "linesOfCode": 数值,
    "numberOfMethods": 数值
  },
  "issues": [
    {
      "line": 行号,
      "type": "问题类型",
      "description": "问题描述",
      "severity": "严重程度"
    }
  ],
  "suggestions": ["改进建议1", "改进建议2"]
}

2️⃣ Markdown表格

请对比以下两种方案，以表格形式输出：

| 对比维度 | 方案A | 方案B | 推荐 |
|---------|------|------|-----|
| 性能 | | | |
| 可维护性 | | | |
| 开发成本 | | | |
| 扩展性 | | | |

3️⃣ YAML配置

生成Spring Boot配置文件（YAML格式）：
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/db
    username: root
    password: ${DB_PASSWORD}

4️⃣ 代码+注释

/**
 * 用户服务接口
 * @author AI Generated
 * @date 2025-01-22
 */
public interface UserService {
    /**
     * 根据ID查询用户
     * @param userId 用户ID
     * @return 用户信息
     * @throws UserNotFoundException 用户不存在时抛出
     */
    User getUserById(Long userId);
}

最佳实践

明确格式要求

请分析数据库表结构，并以以下格式输出：

格式：JSON Schema
必需字段：tableName, columns, indexes, constraints
示例：
{
  "tableName": "user",
  "columns": [
    {"name": "id", "type": "BIGINT", "nullable": false, "comment": "主键"}
  ],
  "indexes": [
    {"name": "idx_username", "columns": ["username"], "unique": true}
  ]
}

技巧要点：

优先使用标准格式（JSON、XML、YAML）
提供Schema或示例，确保格式准确
对于复杂数据，要求JSON格式便于程序解析
对于人类阅读，使用Markdown表格
明确字段必填性和数据类型
要求验证输出格式的有效性

进阶技巧

1. 使用AI生成测试数据或单元测试

生成10条用户测试数据（JSON格式）：
- 姓名：符合中文命名习惯
- 手机号：13/15/18开头的11位号码
- 邮箱：真实格式
- 年龄：18-60之间
- 注册时间：2024年1月1日到现在

2. 性能分析报告

分析以下代码的性能瓶颈，生成报告：
1. 识别热点代码（高频调用）
2. 计算时间复杂度和空间复杂度
3. 给出优化建议（缓存、异步、索引等）
4. 提供优化后的代码对比

3. 依赖关系分析

分析@com.example.order包的依赖关系：
- 对外暴露的接口
- 依赖的外部服务
- 循环依赖检测
- 生成依赖图（Mermaid格式）

4. 代码反向生成系统概要设计文档

原因

现有系统往往缺少完整的设计文档，通过AI分析代码可以快速重建系统架构视图，帮助新成员理解系统或为重构提供依据。

最佳实践（🐶）

技巧要点：

指定关注的核心目录，避免分析无关代码
要求分层次输出（宏观架构 → 模块详情 → 核心流程）
可以要求生成Mermaid图表代码，便于可视化
分阶段确认，先生成大纲再逐步细化

5. 指定接口分析

原因

深入理解某个关键接口的实现逻辑、依赖关系和潜在问题，有助于调试、优化或重构。

最佳实践

请详细分析以下接口的实现逻辑：
接口：@UserService.getUserProfile()

分析要点：
1. 方法调用链路（上下游依赖）
2. 数据库查询逻辑和SQL分析
3. 异常处理机制
4. 性能瓶颈点（如N+1查询、循环调用）
5. 安全风险（如SQL注入、权限校验）
6. 优化建议

技巧要点：

使用方法签名精确定位（包名.类名.方法名）
分点列出分析维度，确保全面覆盖
要求提供调用时序图或流程图
可以要求对比最佳实践，给出改进方案

常见陷阱与避免方法

陷阱1：过度依赖AI

表现：不理解AI生成的代码，直接复制粘贴

危害：生产环境Bug、安全漏洞

避免：必须理解每行代码，并进行Code Review

陷阱2：上下文污染

表现：在同一会话中处理多个不相关任务

危害：AI混淆需求，代码质量下降

避免：严格遵循会话管理策略

陷阱3：忽略边界条件

表现：只考虑正常流程，不考虑异常情况

危害：系统脆弱，容错性差

避免：明确要求AI考虑边界情况和异常处理

陷阱4：信息过载

表现：一次性粘贴大量无关代码

危害：AI响应慢、偏离重点、超出token限制

避免：精准定位，只提供必要信息

陷阱5：缺少验证

表现：AI说什么就是什么，不验证

危害：AI幻觉导致错误方案

避免：使用自检机制和人工Review

最后

最近在整理提示词编写的相关技巧，整理好后分享给大家☺️

如果这篇文章对你有帮助，欢迎点赞、收藏和分享！

作者：Mario

创作日期：2025-10-24