为什么你用AI编程反而变慢了？
以前，我跟你一样，用AI编程老是觉得慢。
打开AI工具，敲几句指令。等几秒，代码哗啦啦出来一大堆。我一看，好像对，又好像不对。改改这里，跑不通。再改那里，又出新问题。
折腾半小时，我发现，自己手写代码更快。
这不是我一个人的情况。身边很多做开发的朋友也这样说。
AI明明很强，为什么用起来反而耽误事？
今天，我就说说我踩过的坑。还有后来想明白的几件事。
你把AI当成聊天工具，不是协作伙伴
很多人犯这个错。他们把AI当成搜索引擎。
比如，你跟AI说：“帮我写个用户登录功能。”
然后，你啥也不干，就等着它把代码全吐出来。你拿到代码，复制粘贴。跑一下，如果不行，你就再问一遍。
这不是合作，这跟买彩票差不多。中不中奖，全看运气。
真正高效的做法是：你来做主导，AI帮你干活。
你要告诉它：
- 用什么技术框架。比如，你是用Spring Boot 3，还是用Django 4。
- 版本是多少。Java 17，还是Python 3.10。
- 数据结构长什么样。比如，用户表里有id (Long), username (String), password (String)。
- 出了错怎么处理。比如，登录失败时，要返回什么错误码，或者抛什么异常。
- 你只希望它做哪一部分。比如，我只要登录接口的参数校验代码，其他不要。
你给的上下文越清楚，它给你的代码就越能用。
AI不怕你说得多。它就怕你说得模糊。你越是“你看着办”，它越容易给你一堆没用的东西。
举个例子。
你直接说：“帮我写个用户注册接口。”
AI可能会给你一个很泛泛的代码。可能用它默认的框架，默认的加密方式。也许跟你项目里的其他部分格格不入。
但是，如果你这样说：
“我需要一个用户注册的Java接口。用Spring Boot 3，Java 17。请求体用JSON，包含username和password字段。username要唯一，password需要bcrypt加密。数据库是MySQL。请只生成Controller层和Service层的代码，不要Repository层。Controller接口路径是/api/register。”
这样，AI就会给你一个更具体、更符合你需求的代码。而且，你拿到代码后，也更容易检查。
这就是它的工作原理：你把方向定清楚，它才能帮你准确地执行。
你没习惯拆分大任务
这是第二个大问题。很多人喜欢把一个大任务，直接扔给AI。
比如，你跟AI说：“帮我做个后台管理系统。要有用户管理、角色管理、日志审计这些功能。”
AI会很努力地给你生成一堆代码。但是，你看一下，会发现很多问题：
- 代码里，命名风格可能一会儿是驼峰式，一会儿是下划线。搞得乱七八糟。
- 有些函数写了，但根本没人用。就是个摆设。
- 错误处理可能只写了一半。一旦出问题，程序直接崩溃。
- 数据库表结构和接口定义对不上。数据传进去，发现存不了。
这不是说AI不行。是你给它的任务太大，太粗了。AI没有我们人的全局观。它一次性处理不了那么多复杂的关系。
高手怎么做？他们把大任务切成好几块。切成5到10个小任务。
每个小任务，让AI做一步。你收到结果后，就检查一步。
这就像你带一个新手实习生。他能力很强，但是对整个项目不熟。你不会让他直接去开发一个大模块。
你会告诉他：
- “先帮我写一个用户注册的API接口。”
- “写完后，告诉我。”
- “我检查通过了，你再帮我写用户登录的API接口。”
这样一步步来。你给AI方向，它帮你跑腿。
我来举个具体的例子。
你要做一个“用户管理模块”。
不要直接说：“给我写个用户管理模块，包括增删改查、权限分配。”
这样说，你拿到的是一堆可能互相矛盾的代码。
你应该这样做：
第一步：定义基础。
你对AI说：“我需要一个用户实体类。包含id、username、email、passwordHash、createdAt。字段类型和长度请注明。”
AI会给你这个类的定义。
第二步：写新增用户。
你拿到实体类，再对AI说：“基于上面定义的User实体，帮我写一个创建新用户的API接口。需要检查username是否已存在，passwordHash要用bcrypt加密。返回创建成功的User对象。”
AI给你写完后，你检查这段代码。看看加密对不对，唯一性检查做了没有。
第三步：写查询用户列表。
你接着对AI说：“现在，我需要一个分页查询用户列表的接口。可以按username模糊搜索。返回User对象的列表。”
AI又给你一段代码，你再检查。
第四步：写更新用户。
以此类推，你继续要求AI写“更新用户”和“删除用户”的接口。每次都只针对一个操作。
第五步：处理权限。
最后，你再来处理权限分配的逻辑。比如，“给我一个接口，能给指定用户分配角色。”
这样做，每个小任务都很明确。AI的输出质量会好很多。而且，你也能更容易地检查。
你从不检查AI给的代码
这是最糟糕的一点。很多人直接把AI生成的代码复制到项目里。他们看都不看一眼。
跑通了，就觉得万事大吉。跑不通，就怪AI“不行”。
你想想，如果你的同事提交了一段代码。你不审核，直接就合并到主分支。如果后面出了问题，这个责任算谁的？
AI给的代码，它本质上就是一份**“待审核的PR”**。它还没最终确定。
你至少要做三件事：
- 读一遍核心逻辑。 不用你一行行地看。但是，主要的业务流程你得在脑子里过一遍。AI经常会在边界条件上犯错。比如，空输入、负数、列表为空的情况。它可能考虑不到。
举例来说，AI可能给你一个计算订单总价的函数。它可能忘了考虑优惠券为零，或者商品列表为空的情况。这些你得自己去检查出来。 - 跑一遍测试。 你的项目没有测试？那就先让AI帮你写测试。然后，再让它写功能代码。这个顺序很重要。
比如，你要让AI写一个add(a, b)函数。
你先说：“给我写add(a, b)的单元测试。测试add(1, 2)等于3，add(-1, 1)等于0，add(0, 0)等于0。”
AI会先给你测试用例。
然后，你再让AI写add(a, b)的实现。
这样，它写完实现，你直接用它生成的测试去跑。如果测试通过，说明代码基本没问题。 - 问自己一个问题： “如果这段代码出了bug，我能在5分钟内找到问题吗？”
如果答案是“不能”，说明你对这段代码不熟。不了解它。那你就不应该直接用。你就得花时间去理解它。直到你能自信地说：“我能找到问题。”
别偷懒。代码是跑在你项目里的。出了问题，还是你来背锅。
你只用AI写代码，没用它做其他事
这是很多人没想到的。AI能做的，远不止帮你写函数。
它能做很多事。很多都是那种重复性高，但又不能不做的工作。
- 分析需求。 产品经理给你一份长长的需求文档。你看得头晕。你可以把文档直接扔给AI。让它帮你梳理技术方案。或者让它列出文档里有哪些需要向产品经理确认的问题。
这是它的工作原理：AI能快速阅读和理解文档。它帮你把重点抓出来。这样，你就能更快开始技术设计。 - 定位Bug。 你的代码出错了。报错信息一堆。你盯着屏幕发呆，不知道问题在哪。把报错信息和相关的代码片段一起给AI。它能帮你指出可能的问题在哪。
举个例子，你的程序报了个NullPointerException。你把报错堆栈和涉及到的几行代码给AI。AI可能会告诉你：“看起来你在尝试访问一个空对象的属性，检查一下user对象是不是在某个地方没初始化好。”这样可以帮你更快找到问题。 - 代码审查。 写完代码，让AI帮你审核一遍。它能发现你可能忽略的问题。比如，变量名不规范，或者可能出现空指针的地方。甚至是一些你没注意到的安全漏洞。
你可以这样做：提交你的代码片段，然后问AI：“请帮我审查这段Java代码。重点看看有没有命名不规范，潜在的空指针，以及有没有缺少异常处理。”它会给你反馈。 - 生成文档。 接口文档、变更日志、部署说明。这些写起来很烦，但又不得不写。交给AI。它能帮你快速生成一个初稿。你再自己修改完善。
比如，你写了一个RESTful API。你可以把Controller的代码给AI。然后说：“请根据这段Java Spring Boot代码，生成一份Markdown格式的API文档。包含接口路径、请求方法、请求参数和响应示例。”它能帮你省下很多时间。 - 生成测试用例。 这是一个很好的用法。你先给它函数签名和业务逻辑。让它帮你生成单元测试和边界测试。
举个例子，你写了一个calculateTax(income)函数。
你对AI说：“我有一个calculateTax(double income)函数。它计算税费。当income小于10000时，税率为10%。当income在10000到50000之间时，税率为15%。大于50000时，税率为20%。请帮我生成JUnit 5的单元测试用例。”
AI会给你针对这几个条件的测试用例。这能帮你更快地验证代码。
把AI只当成一个“代码生成器”，这太浪费了。它能帮你做的事多着呢。
你没建立自己的指令库
你用AI用了好几个月。你积累了什么？
如果答案是“没什么”，那每次用AI，你都在从头开始。这就像你每次做饭都要重新学一遍怎么切菜。
真正会用AI的开发者，他们会建立自己的指令库。
指令库是什么？就是你把那些好用的、有效的指令（Prompt）记下来。
这些指令，可能就是你在平时用AI时，发现“这样说，AI最明白”的那些话。
比如：
- 项目初始化用什么指令。
你可以这样写：“用Spring Boot 3、Java 17、Maven，创建一个Web项目。包含Web、JPA、Lombok、Validation这些依赖。配置MySQL数据库连接。” - 代码审查用什么指令。
你可以这样写：“请审查以下Java代码。主要看性能优化、代码风格、异常处理、潜在安全漏洞，并给出具体修改建议。” - 写测试用什么指令。
你可以这样写：“针对下面的Java函数，请根据我提供的业务逻辑，生成JUnit 5的单元测试。要求覆盖正常情况、边界条件和错误处理。” - 排查性能问题用什么指令。
你可以这样写：“我这个Web接口响应很慢。下面是相关代码。请分析可能原因，并给出优化建议。”
这些指令，不是什么高深的东西。它们是你自己在实践中摸索出来的。是你的经验总结。
把它们记下来，整理好。下次需要的时候，直接拿出来用。
这就是你的AI开发资产。别人拿不走。它能让你和AI的合作越来越顺手。
比如说，你经常需要把一个Python函数转成Java。
你第一次可能这样问：“把这段Python代码转成Java。”
AI可能给你一个很简单的翻译，但没有异常处理，也没有考虑Java的特点。
你慢慢发现，这样问更好：
“请将以下Python函数转换为Java方法。转换时，请考虑Java的异常处理机制，使用Optional处理可能为空的值。同时，请保持代码风格符合Spring Boot项目的规范。”
你会把这个更精确、更有效的指令保存下来。下次再转代码时，直接用这个指令。这样，你就省去了每次都重新琢磨怎么问AI的时间。而且，你得到的结果也会更好。
一个简单的自检清单
如果你想知道自己用AI编程的水平怎么样，可以对照下面的清单。给自己打个勾。
- ⬜ 我能在指令里，清楚地描述技术细节（框架、版本、约束条件）。
- ⬜ 我会把大任务拆成小步骤，一步步让AI去完成。
- ⬜ 我会检查AI生成的每一段代码，确认没问题才用。
- ⬜ 我在写代码之外，也用AI做其他事（比如审查代码、写测试、生成文档）。
- ⬜ 我有自己积累的指令模板或工作流程。
- ⬜ 我能感觉出来，AI什么时候给的是好代码，什么时候在瞎编。
- ⬜ 我用了AI以后，我的工作速度确实比以前快了。
如果你能打勾5个以上，说明你已经过了“尝鲜”阶段。你已经进入了真正的人机协作。你懂怎么和AI一起干活。
如果不到3个？那也没事。你知道问题在哪，这就是进步的开始。
最后说几句
AI不会让所有程序员都变强。
它只会让那些愿意改变自己工作方式的人变强。
那些还只会“复制粘贴”的人，三个月后和现在不会有任何区别。他们还是那样写代码。
但是，那些认真想过“怎么跟AI配合最快”的人，他们已经在悄悄地拉开差距了。
别着急，别担心。但是，别停下来。
