程序员如何借助 AI 把重复开发工作自动化

一、先认清 AI 的能力边界，才能用好它

讨论自动化之前，需要先明确一个基本判断：当前的大模型更适合做“局部增强”，而不是“全局替代”。

早期语音助手给人留下的印象普遍是理解能力不足，很多指令执行结果都像“人工智障”。直到新一代对话模型出现，机器第一次表现出较强的语义理解、上下文跟随和代码生成能力。与此同时，智能编程助手也能根据注释、函数名和上下文补全代码，这让不少开发者产生被替代的焦虑。

但从实际工程角度看，问题远没有这么简单。大模型目前最明显的限制之一，是上下文长度仍然有限。无论模型卡片上标注的上下文窗口有多大，真实业务系统的代码规模通常都会超出这个范围。一个中小型应用的核心模块可能就有几万到十几万行代码，如果把配置、脚本、接口定义、数据库结构、部署文件全部纳入，上下文需求会更大。

这意味着，当模型无法完整读取一个系统的领域模型、调用链路、异常约定和部署环境时，就不能指望它独立完成需求拆解、方案设计、代码实现和验证上线。它可能会生成看起来很完整的代码，但未必符合当前项目的工程约束。

因此，更合理的定位是：把 AI 当成一个需要明确输入、明确边界和明确验收标准的执行助手。

二、让 AI 自动生成重复度高的代码

程序员日常工作中，存在大量“逻辑不复杂，但写起来很繁琐”的代码。这种工作非常适合交给 AI 完成。

1. 接口响应转语言对象

开发者经常需要对接各类开放接口，把 JSON 响应转换成 Java、Go、Python 等语言的结构体或类。例如一个对话接口返回如下结构：

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gpt-3.5-turbo",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 9,
    "completion_tokens": 12,
    "total_tokens": 21
  }
}

人工手写对应的 Java 类，需要考虑字段映射、嵌套类、可选字段、默认值、序列化注解等，耗时很容易超过半小时。把这段 JSON 交给大模型，并补充目标语言、命名风格、是否需要 Lombok、是否需要 Jackson 注解等约束，它通常可以在几十秒内生成一套基本可用的类定义。

开发者的后续工作不是重新编写，而是检查字段类型是否正确、嵌套结构是否完整、命名是否符合团队规范。这种方式减少的不是思考难度，而是机械输入成本。

2. 生成标准 CRUD 代码

很多业务模块都包含类似结构：数据库表、实体类、数据访问层、服务层、接口层、参数校验、分页查询、更新字段白名单等。虽然每家公司框架不同，但同一项目内部通常有固定模板。

只要给 AI 提供表结构、字段说明和已有代码样例，它就能按模板批量生成新的 CRUD 模块。特别是当团队已有统一基类、统一返回结构和统一异常处理时，AI 生成的结果往往比人工复制粘贴再修改更一致。

3. 编写转换与映射逻辑

业务系统里常见的 DTO、VO、DO 转换，枚举映射，状态机转换，报表字段拼接，导出格式整理等，都属于规则清晰但代码量大的工作。把输入结构、输出结构和映射规则描述清楚后，AI 可以快速生成转换函数。

这类任务很适合自动化，因为验收标准明确：输入输出字段是否对齐、类型是否匹配、异常分支是否覆盖。

三、让 AI 成为命令行里的自动化脚本生成器

除了业务代码，开发过程还存在大量临时脚本需求，例如：

• 批量重命名文件；
• 解析日志并提取指定字段；
• 扫描目录查找包含特定模式的文件；
• 统计接口耗时分布；
• 从数据库中导出数据并生成报告；
• 检查配置文件缺失项；
• 转换编码或格式化数据。

这些脚本如果人工去查 API、处理边界、调试正则表达式，经常耗费大量时间。AI 的优势在于，它能根据自然语言描述快速生成一版可运行脚本。

但需要注意，脚本运行可能涉及文件删除、数据库写操作、批量提交等风险动作。因此，自动化流程必须增加确认环节，例如先打印将要处理的文件列表，或先执行 dry-run 模式。AI 生成的脚本应当被当作初稿，而不是可直接信任的最终产物。

四、用 AI 补全测试代码和测试数据

测试是开发者最容易想自动化、但又总被业务节奏打断的部分。AI 可以在多个测试环节中分担工作。

1. 根据函数生成单元测试

给定一个函数的签名、入参结构、返回值和边界条件，AI 可以生成基础测试用例。尤其是参数校验、异常路径、空值判断等分支，人工编写容易遗漏，AI 反而更容易按规则枚举。

2. 构造模拟数据

接口联调时，经常需要符合业务约束的假数据。比如生成长度合法、格式正确的手机号、身份证号、订单号、时间区间、嵌套结构等。把这些规则写成提示词，AI 可以批量生成 JSON 或 CSV 数据。

3. 生成接口测试用例

基于接口文档或示例请求，AI 可以自动补充不同参数组合、缺失字段、非法枚举值等用例。这类工作与代码生成类似，关键是开发者明确输入和断言标准。

五、把重复性排查工作改造成自动流程

开发者每天还要处理很多“不是写新功能，而是找出哪里出问题”的工作。AI 也可以在排查环节提供效率提升。

1. 日志摘要与异常归类

将一段日志交给大模型，让它提取错误类型、首次出现时间、关联请求 ID、关键堆栈信息，并给出可能原因。这样开发者不必从大量日志中人工定位问题。

2. 接口报错辅助分析

当接口返回错误码时，可以把请求参数、响应体、相关配置片段和日志摘要一并交给 AI，让它分析常见原因。虽然最终判断仍需开发者确认，但能显著缩小排查范围。

3. 生成排查记录

每次问题处理后，可以让 AI 根据排查过程自动整理成模板化记录，包括现象、根因、处理步骤、预防措施。这部分内容既可用于团队知识沉淀，也能减少后续重复排查。

六、自动化落地的关键：不是“让 AI 自由发挥”

从实践来看，能否把 AI 真正纳入日常工作流，取决于是否建立了清晰的边界和验收机制。

1. 把任务拆小

“帮我实现一个订单系统”是不可靠的提示方式。更有效的是“根据以下表结构生成订单实体的 Java 类，包含字段校验注解，使用驼峰命名”。任务越小，上下文越明确，AI 输出质量越高。

2. 提供真实样例

当团队已有固定代码风格时，不要只描述规则，而应提供一两个真实样例。样例比自然语言约束更有效，AI 更容易模仿结构、命名、异常处理和注释风格。

3. 保留人工审查节点

AI 生成的代码必须经过编译、静态检查、单元测试和人工评审。即使生成的代码看起来正确，也可能在并发、事务、安全、性能等方面存在问题。自动化的目标是减少重复劳动，不是移除工程责任。

4. 沉淀提示词模板

对于反复出现的任务，例如“根据 JSON 生成 Java 类”“根据表结构生成 CRUD”“根据接口文档生成测试用例”，可以把提示词整理成模板。团队成员复用统一模板后，输出风格更一致，新成员也能更快上手。

七、未来可能进一步自动化的方向

随着大模型能力、上下文窗口、工具调用和代码执行能力的演进，AI 在开发流程中的参与度会继续提升。可以预见的是，未来更多自动化会出现在以下环节：

• 根据需求描述生成接口草案和数据模型；
• 从已有代码中提取业务规则并生成文档；
• 自动分析代码变更影响范围；
• 根据运行日志生成可复现用例；
• 在代码评审中自动发现风格不一致和明显缺陷。

但即使如此，自动化仍然需要开发者定义目标、确认输入、验证输出和控制风险。与其说 AI 会完全替代程序员，不如说它会把程序员从大量重复、繁琐、低信息量的工作中解放出来。

真正值得投入的方向，不是等待一个“全能自动编程系统”，而是现在就能把那些已经足够明确、可以验证、重复出现的任务，一点点交给 AI 完成。