ChatGPT 出来之后，我的写代码方式变了

一、第一次用 AI 辅助写代码

2023 年初，我在做一个数据导出功能，需要把一个嵌套的 JSON 结构展平成 Excel 表格，字段对应关系大概有二十几列，逻辑不复杂但很啰嗦。

以前这种活，我会先找类似的代码复制一份改一改，或者去 Stack Overflow 搜一下有没有现成的写法。那次我想着试一试，把需求描述给 ChatGPT，大意是「把这个 JSON 结构转换成以下表头的 Excel，用 EasyExcel」，附上了 JSON 样例和字段映射表。

它给出的代码大概对了 80%，剩下 20% 是字段名对不上和日期格式不对。但即便如此，我节省了大概一个小时的手写时间。从那之后，这类有明确规律但需要大量重复劳动的任务，我都会先问 AI。

二、现在哪几类任务会优先用 AI

用了快一年之后，沉淀下来有几类任务是真实在用的：

写 SQL：特别是复杂的聚合查询（多表 JOIN + GROUP BY + HAVING）。我描述清楚需求和表结构，AI 给草稿，我来验证逻辑和加索引考虑。AI 给的 SQL 草稿大约有 70% 可以直接用，30% 需要调整。时间节省最明显。

看不懂的老代码：接手历史项目时，遇到没有注释的复杂逻辑，直接贴给 AI 让它解释意图。它能把「这段代码在干什么」说得相当清楚，比我自己从头读要快。

写单元测试的用例框架：给定方法签名和一两个例子，让 AI 生成测试用例清单（正常路径、边界情况、异常情况），我再逐条实现。省的不是写 assert 的时间，是「我需要测哪些场景」的思考时间。

写注释和文档：给复杂方法写 JavaDoc，或者给接口写 Swagger 注解，这类「知道要写什么但懒得写」的活，AI 比我有耐心。

三、哪类任务 AI 帮倒忙

有一次我在用 ChatGPT 给一个推荐算法做优化，描述了需求之后，它给了一段看起来很合理的代码，用了一个我不熟悉的 API 调用方式。我没有仔细看，直接合并进去，在本地简单跑了几个 case 都过了。

上线后第二天，线上出现了一个低频但稳定复现的 NPE。追查下来，是 AI 使用的那个 API 在某个边界情况下会返回 null，而它给的代码里没有做 null 检查——这是那个版本的 API 文档里有说明的，但 AI 用的知识是旧的，没有包含这个注意事项。

那次之后我建立了一个习惯：AI 给的代码，凡是我不熟悉的 API 调用，必须去查一遍官方文档，尤其是边界行为和版本差异。AI 写的代码语法大多是对的，但对特定版本 API 的行为不可靠。

四、这对「程序员的核心价值」意味着什么

用了将近一年 AI 编程工具之后，我对这件事有了一个相对稳定的判断：

AI 擅长的是把已知的模式快速实例化。写 CRUD、生成样板代码、翻译需求到代码框架——这些在技术上有标准答案的事，AI 比我快。

AI 不擅长的是判断「这个需求是否应该被满足」、「这个设计在这个业务上下文里合不合理」。它可以帮你把一个需求实现出来，但它不知道这个需求背后的业务约束，不知道你们团队的技术债，不知道上线后会不会被运营投诉。

在 AI 工具已经很好用的情况下，最重要的能力不是「写代码」，而是定义清楚要解决什么问题、判断方案的合理性，以及对输出结果负责。这三件事，AI 帮不了多少。