AI编程工具使用实践：从“会用”到“用好”

这是一篇面向研发团队的 AI 编程工具使用分享文档，重点讨论：AI 编程工具到底如何提效、在哪些场景最有价值、怎样通过锚点、参考、Skill、Plan、Spec 等手段把 AI 从“能用”提升到“好用、耐用、可复用”。

一、为什么值得系统性使用 AI 编程工具

在 AI 编程工具普及之前，很多研发人员其实已经在零散地借助 AI 解决工作问题，只是当时的使用方式更像“对话问答”，而不是“深度协作开发”。

常见场景包括：

• 代码优化：给 AI 一段现有代码，让它按照指定设计模式、分层思想或编码规范完成重构。

• SQL 优化：给 AI 一段复杂查询，让它从执行计划、索引、过滤条件、关联顺序等角度提出优化建议。

• 脚本编写：给 AI 一个重复性问题，让它快速生成脚本处理数据迁移、日志分析、表格解析、批量校验等任务。

这类能力在过去已经足以带来局部提效，但真正的变化出现在 AI 编程工具出现之后：AI 不再只是“回答问题”，而是开始进入工程目录、理解项目上下文、分步骤执行任务、修改代码、补充测试，甚至生成说明书和在线文档。

二、在 AI 编程工具出现之前：我们其实已经在使用 AI

1. 代码优化：让 AI 按设计模式重构现有代码

很多老项目中都存在同类问题：业务逻辑堆叠、条件分支过多、扩展困难。过去我们会手工重构；现在可以先让 AI 给出第一版重构方案。

典型案例：将大量 if\-else 业务分支重构为策略模式。

原始诉求：

根据不同渠道类型处理订单创建逻辑，要求后续新增渠道时不再修改主流程。

推荐交付给 AI 的信息包括：

• 当前核心代码片段

• 目标设计模式，例如策略模式、模板方法、责任链

• 约束条件，例如不要改动对外接口、保留现有日志格式、兼容旧参数

• 参考实现，例如项目中已有的某个策略工厂

这样，AI 输出的结果通常不只是“代码能跑”，而是更接近“符合项目风格的可维护实现”。

2. SQL 优化：让 AI 从“能查”走向“查得快”

很多性能问题并不是 SQL 写不出来，而是写出来之后不够稳定、不够快。AI 在 SQL 优化上的价值主要体现在两点：

• 快速识别反模式，例如函数作用在索引列、SELECT \*、低效子查询、模糊过滤失去索引。

• 快速给出多种改写方案，例如改写为预过滤、分步聚合、覆盖索引、减少回表。

典型案例：

SELECT *
FROM order_info o
LEFT JOIN order_item i ON o.id = i.order_id
WHERE DATE(o.create_time) = '2026-05-01'
AND o.status IN (1, 2, 3)
ORDER BY o.create_time DESC;

AI 可以很快指出：

• DATE\(o\.create\_time\) 会导致索引失效

• SELECT \* 增加无效字段读取成本

• 关联前未充分过滤主表，可能放大 Join 成本

• 排序字段需要结合过滤条件考虑联合索引

进一步的高质量提问方式是：

这是 MySQL 8 的查询语句，表数据量 order_info 约 3000 万，order_item 约 1.2 亿。
请你从执行计划、索引命中、回表成本、排序成本四个角度分析，并给出可落地的优化 SQL 和索引建议。

这比只说“帮我优化 SQL”得到的结果通常会更专业。

3. 编写脚本：把重复劳动外包给 AI

脚本类任务是 AI 非常擅长的领域，尤其适合处理：

• 数据迁移与修复

• Excel / CSV / JSON / SQL 文件解析

• 日志批处理与异常数据提取

• 批量接口调用与结果汇总

典型案例：解析一批 Excel 文件，提取客户字段，按规则清洗后导入数据库。

此类需求的关键不是一句话全扔给 AI，而是拆分为多个步骤：

1. 先让 AI 分析需求，列出输入、输出、边界条件。

2. 再让 AI 设计脚本结构，例如读取模块、校验模块、转换模块、写入模块。

3. 最后让 AI 分步骤实现并补充日志、重试、失败记录。

复杂需求不要一次性要求 AI “全部做完”。先拆解，再逐段实现，成功率和可控性会明显提高。

三、AI 编程工具出现之后：从“问答式 AI”进入“协作式 AI”

最初使用 AI 编程工具时，一个非常直观的感受是：它会先在工作目录中大量翻阅代码，然后再开始思考和执行。

这个过程通常包括：

这比纯手工开发已经快很多，因为它天然擅长做两件事：

• 高速阅读：短时间内扫过大量文件并提取关键信息。

• 高速试错：可以快速产出第一版实现，再持续修正。

但在探索阶段也会发现一个问题：如果用户只给一个很笼统的需求，AI 往往会进行大范围扫描，成本高、耗时长，而且不一定总能命中真正关键的位置。

于是，下一步就不再只是“让 AI 干活”，而是开始研究如何让 AI 干得更快、更准、更稳。

四、从“让 AI 自己探索”到“人工介入驱动 AI”

掌握 AI 的工作逻辑之后，就会发现：真正的提效不是把任务完全扔给 AI，而是在关键节点进行人工介入，给 AI 提供高质量输入。

这类人工介入，至少有七个非常实用的方法。

1. 提供锚点：让 AI 聚焦到正确位置

所谓锚点，就是明确告诉 AI：这次任务应该从哪里开始看。

锚点可以是：

• 工程中的某个模块

• 某个目录

• 某个文件

• 某个类、方法、SQL、接口

• 某一段已有实现

例如，不要只说：

帮我给知识库增加权限控制。

更好的说法是：

请在 knowledge 模块里实现权限收口，重点查看 KnowledgeAuthServiceImpl 和知识库保存接口。
目标是把历史 ACL 权限和资源权限统一到一个判断口径中，先阅读相关实现后再给出改造方案。

这样做的价值非常明显：

• 减少全盘扫描

• 缩短上下文建立时间

• 提高实现命中率

• 降低改错文件、改偏逻辑的概率

如果你已经知道需求大概率落在哪个模块，就一定要把模块、文件、方法这些锚点直接告诉 AI。

2. 提供参考：告诉 AI 应该“向谁看齐”

AI 最大的问题之一，不是不会写，而是容易“按自己的理解乱写”。

解决办法就是给参照物。参考物可以来自：

• 官方文档

• 项目中已有实现

• 历史设计文档

• 现有数据库规范

• 接口协议说明

• 编码规范或团队约定

例如做网关路由功能时，可以明确告诉 AI：

请参考现有应用管理模块的 controller、service、repository 分层方式实现。
数据库字段命名遵循现有 gateway_app 表风格。
接口出参统一复用 CommonResponse。

当参考足够明确时，AI 产出的内容会更接近“增量开发”，而不是“重新发明一套系统”。

3. 提供 Skill：把 AI 的能力变成可复用工具链

随着使用深入，会发现 AI 在某些领域特别强，比如：

• 前端页面设计

• 后端接口开发

• 代码审查

• 数据库操作

• 服务器部署

• 文档生产

这个时候就不能只依赖一个通用模型，而要学会给 AI 配 Skill。

Skill 的来源可以是：

• 平台内置能力

• ClawHub、魔搭等平台的现成 Skill

• 团队自己沉淀的工作流和规则

更重要的是，当 AI 经常犯某类错误时，可以在问题解决后，把这次经验沉淀为 Skill。例如：

• 统一接口出参格式

• 统一分页查询写法

• 统一数据库字段命名规则

• 特定框架下的异常处理方式

这会让 AI 从“每次重新教一遍”变成“后续默认按规矩做事”。

4. 制定 Plan：先让 AI 给出方案，再执行

很多人使用 AI 时会遇到一个悖论：

• 想借助 AI 提效

• 但为了让 AI 做得更好，又要花很多时间描述任务

Plan 模式是解决这个悖论的好方法。

做法是：

1、先用较简洁的语言描述目标。

2、让 AI 输出任务计划，而不是直接写代码。

3、人工审阅这个计划，补充遗漏、纠正偏差。

4、确认后，再让 AI 按计划执行。

例如：

请先不要写代码。先输出本次改造计划：包括改动范围、影响点、风险点、验证方式。
我确认计划后，你再开始实施。

Plan 模式特别适合：

• 需求还不够稳定

• 任务涉及多个模块

• 用户自己也想先理清思路

• 希望减少 AI 返工

5. 制定 Spec：面对复杂场景，先写详细说明书

如果 Plan 是施工计划，那么 Spec 更像施工图纸。

在一些较大的业务场景中，直接让 AI 写代码通常会失控。例如实现一个 API 网关模块，往往至少包含：

• 网关总览

• 应用管理

• 路由管理

• 鉴权配置

• 访问日志

• 运行监控

这种情况下，最佳实践不是直接开干，而是先让 AI 输出完整 Spec，包括：

说明项	典型内容
背景与目标	为什么做、解决什么问题
范围定义	本次做什么、不做什么
角色与权限	管理员、应用负责人、普通用户的边界
数据模型	核心表结构、字段约束、索引建议
API 设计	入参、出参、错误码、幂等要求
页面与交互	页面模块、筛选条件、操作流程
风险与回滚	兼容性、灰度策略、回滚方案
验证方案	自测清单、联调点、验收标准

Spec 模式的价值在于：它把“模糊需求”变成“结构化蓝图”，让 AI 后续的实现更稳定。

五、AI 能做的事情，远不止写代码

很多团队低估了 AI 的边界，实际上它已经可以参与完整的软件交付链路。

1. 写文档

例如本次场景，就是直接通过飞书 MCP 让 AI 创建在线文档、组织章节结构、补充案例和图表，而不是先在本地写完再复制粘贴。

这种方式特别适合：

• 技术方案文档

• 项目复盘总结

• 操作手册

• 周报、汇报材料

• 培训材料

2. 安装本地工具与环境

AI 可以帮助完成本地环境初始化，例如：

• 安装 Java / Node.js / Python 运行环境

• 安装数据库客户端和构建工具

• 配置环境变量

• 排查依赖冲突

3. 部署服务器环境

如果具备 SSH、终端或自动化工具能力，AI 可以协助部署：

• MinIO

• Redis

• MySQL

• Nginx

• Java 服务

• Docker 与 Docker Compose 环境

高质量的提示方式不是“帮我部署”，而是：

目标服务器是 CentOS 7，请部署 MinIO 和 Nginx。
MinIO 监听 9000/9001，数据目录 /data/minio；
Nginx 反向代理到本地 8080 服务；
请先给出部署步骤和配置文件草稿，我确认后再执行。

4. 搭建 Jenkins 流水线

AI 非常适合根据工程结构生成 Jenkinsfile，尤其当你能补充以下信息时：

• 分支策略

• 构建命令

• 测试命令

• 制品位置

• 发布方式

• 回滚方式

5. 构建一键部署方案

对于中小型系统，AI 可以快速生成 docker\-compose\.yml，把应用、数据库、缓存、中间件串起来，形成可复用的一键部署方案。

当你把 AI 从“代码助手”升级为“交付助手”后，它的价值会成倍提升。

六、多元化使用 AI 工具和模型：不要死磕单一选手

不同模型的优势并不相同，真正高阶的用法，是让不同模型承担不同职责。

一个比较实用的思路是按任务类型拆分：

任务类型	更适合的模型特征
规格说明、方案设计、验收优化	上下文理解强、推理稳定、表达完整
后端实现、逻辑推演、复杂重构	逻辑处理强、结构感好、代码一致性高
前端页面、交互生成、长链条任务	长线任务稳定、组件组织能力强
UI/视觉设计	审美与布局能力强、能处理设计语言

一个典型的协作式分工如下：

1、用综合能力强的模型输出 Spec 或验收标准。

2、用逻辑能力强的模型实现后端核心代码。

3、用长任务稳定的模型实现前端页面与交互。

4、最后再用更强的模型做审查、验收、优化。

这种“多模型接力”比“一个模型从头做到尾”更容易得到高质量结果。

七、四个高价值实战案例

案例一：代码优化重构

场景：订单处理服务中，渠道分支越来越多，修改一个渠道逻辑会影响主流程。

推荐提问方式：

下面是订单创建代码，请按策略模式重构。
要求：
1. 对外接口不变；
2. 保留现有日志字段；
3. 新增渠道时无需修改主流程；
4. 参考项目内 PaymentStrategyFactory 的实现风格；
5. 先给出重构计划和类关系，再输出代码。

高质量结果通常会包含：

• 策略接口定义

• 渠道实现类拆分

• 策略工厂或注册中心

• 主流程简化后的调用方式

• 单元测试补充点

案例二：SQL 优化

场景：列表查询在大表下响应慢，线上偶发超时。

推荐提问方式：

这是 MySQL 8 的查询 SQL，请帮我从执行计划角度优化。
背景：
- 主表 3000 万数据；
- 关联表 1.2 亿数据；
- 当前接口超时阈值 3 秒；
- 可接受增加联合索引，但不能影响现有写入太多。
请输出：
1. 当前 SQL 的性能问题；
2. 优化版 SQL；
3. 索引建议；
4. 如何验证优化有效。

这样的提问会强迫 AI 从“数据库工程”视角思考，而不只是“语法改写”。

案例三：脚本编写

场景：需要批量解析多个 Excel 文件，清洗客户数据，并迁移到新表。

推荐分步方式：

1、先让 AI 输出数据处理流程图。

2、再让 AI 定义字段映射和异常规则。

3、再实现解析脚本。

4、最后补充日志、失败重试、结果汇总。

推荐提问方式：

请帮我设计一个 Python 脚本，处理多个 Excel 文件并导入数据库。
先不要直接写完整代码，请先完成：
1. 输入输出分析；
2. 字段映射设计；
3. 异常数据处理策略；
4. 脚本模块划分。
我确认后你再逐步实现。

案例四：大型模块交付

场景：要实现一个 API 网关模块，包含总览、应用管理、路由管理、访问日志等内容。

推荐方式是分三段推进：

1、先让 AI 写 Spec。

2、再按 Spec 逐模块实现。

3、最后让 AI 对照 Spec 逐项验收。

这个流程的优势是：

• 避免中途需求漂移

• 避免前后端理解不一致

• 避免做到后面才发现数据模型有问题

八、几组可直接复用的提示词模板

1. 锚点型提示词

请在指定锚点附近完成需求，不要全盘扫描：
- 模块：xxx
- 文件：xxx
- 方法：xxx
- 目标：xxx
请先阅读这些位置及其直接依赖，再给出你的理解和实施计划。

2. 参考型提示词

请参考以下内容实现需求：
- 官方文档：xxx
- 项目已有实现：xxx
- 设计文档：xxx
约束：命名风格、分层方式、异常处理、日志格式均与参考实现保持一致。

3. Plan 型提示词

先不要写代码。
请输出本次需求的实施计划，包括：
1. 改动范围
2. 关键设计点
3. 风险点
4. 测试与验证方式
等我确认后再执行。

4. Spec 型提示词

这是一个复杂需求，请先输出详细说明书，而不是直接实现。
说明书至少包含：
- 背景与目标
- 业务范围
- 功能列表
- 数据模型
- API 设计
- 权限与异常
- 风险与回滚
- 验收标准

九、常见误区

1. 一句话丢需求，期待 AI 自动理解一切

AI 可以补全信息，但不能替代业务上下文。需求越模糊，返工概率越高。

2. 不给约束条件

不告诉 AI 技术栈、框架版本、目录结构、编码规范，结果往往就是“看起来能用，实际上难落地”。

3. 不做计划，直接开写

任务越复杂，越应该先做 Plan 或 Spec。否则 AI 很容易在中途偏航。

4. 把 AI 当成一次性工具，而不是可迭代协作者

真正高效的方式，是持续纠偏、持续沉淀规则、持续把经验转成 Skill。

十、给团队落地 AI 编程工具的建议

1. 建立统一提示模板

把锚点、参考、约束、输出格式、验证要求沉淀成团队模板，减少每个人重复摸索。

2. 建立常用 Skill 目录

例如：

• 后端开发 Skill

• 前端页面 Skill

• SQL 优化 Skill

• 文档编写 Skill

• 部署运维 Skill

• Code Review Skill

3. 让 AI 参与完整流程，而不是只写代码

从需求分析、技术方案、编码实现、测试建议、部署方案，到文档产出，都可以纳入 AI 协作范围。

4. 鼓励“多模型分工”

不要用同一模型做所有事情。让合适的模型承担合适的任务，整体效果更好。

十一、结语

AI 编程工具真正带来的，不只是“写代码更快”，而是软件研发方式的变化。

它把很多原本依赖个人经验、重复劳动和时间堆积的工作，逐渐转变为一种新的协作模式：

• 人负责定义目标、提供约束、审核结果

• AI 负责快速理解、生成、迭代和执行

当你学会提供锚点、提供参考、配置 Skill、先做 Plan、再做 Spec，并在更广泛的交付链路中使用 AI 时，AI 才真正从一个“聪明的补全工具”，进化成一个“高效率的研发搭档”。

一句话总结：不是 AI 替代人写代码，而是会使用 AI 的人，将重新定义高效率研发。