你是不是也经历过这种崩溃？
上周五晚上十一点，你让AI帮你写一个订单分表的分页查询。它信心满满吐出来一段SQL，你一跑——全表扫描，数据量一过十万直接卡死。你骂了一句，自己重写。
又或者，你把一个跑得好好的服务丢给AI"优化一下"，它把你的异步回调改成了同步，整条链路挂了，你花了两小时才回滚。
这两年我身边做开发的朋友，十个有八个在用AI编码工具。但大家普遍陷进两个误区：要么觉得"AI写的我不用看直接贴"，要么觉得"AI写的都是垃圾不如自己来"。两种态度，都在吃亏。
今天这篇，不聊虚的。我把自己和几个一线同事这大半年摸索出来的实战方法，拆给你看。
一、三个能直接照搬的高效技巧
1.1 角色锚定 + 约束前置：别让AI自由发挥
很多人打开工具就打一句"帮我写个接口"。这等于让一个刚入职的实习生在没需求文档的情况下干活——它只能猜。
操作步骤：
- 先写一句角色定义："你是一个有5年经验的Go后端工程师，熟悉gin框架和gorm"
- 再加约束条件："不要用第三方分页库，用原生SQL，表结构是……"
- 最后给输出格式："只输出代码，不要解释"
真实案例： 我们团队做日志采集服务时，我用这套提示词让AI生成Elasticsearch的bulk写入逻辑。之前它总给我用官方高层客户端，而我们项目里用的是底层resty直调。加了"使用resty库，兼容项目现有的http client封装"这条约束后，一次过。
【金句：AI编程的第一步不是提问，是画圈——把它限制在你的技术栈和工程规范里。】
1.2 分块投喂，而不是一次性丢整段需求
你有没有试过把一个500行的模块丢给AI让它重构？结果它给你"优化"完，函数名全变了，调用关系乱了，你根本没法diff。
正确做法： 按函数粒度拆，一次只喂一个函数的上下文。比如先喂接口签名 + 入参结构 + 依赖的dao层方法，让它只改这个函数内部逻辑。
真实案例： 有个同事重构支付回调处理逻辑，原来一个200行的大函数。他拆成4个小函数分别让AI处理，每个都附上单元测试的期望输入输出。最终重构完跑通了全部case，只花了一个下午。
1.3 用测试用例反向校验，比你肉眼review靠谱十倍
AI写完代码别急着合。先自己写两组边界测试（空值、超长字符串、并发场景），丢回去让它跑。它自己报错自己改，比你逐行看快得多。
【金句：让AI写代码是体力活，让AI测自己写的代码才是技术活。】
二、五个最容易踩的坑
坑1：幻觉引用——它会编不存在的函数名
现象： AI给你用了一个看起来很专业的函数，比如 utils.DeepCloneMap()，你一搜，标准库里根本没有。
危害： 编译直接报错，浪费排查时间。
规避： 凡是涉及具体函数/方法名的输出，你都去官方文档里对一遍。或者在提示词里加"只使用Go标准库和已确认存在的包"。
坑2：上下文污染——它把你A项目的代码风格带到B项目
现象： 你在对话里前面对话是另一个Python项目，现在切到Java项目，它偶尔冒出Python的写法习惯。
危害： 代码风格不统一，review时别人以为你复制粘贴了别的项目。
规避： 每次新项目开新对话窗口，别在旧对话里接着聊。
坑3：安全盲区——它不会主动提醒SQL注入
现象： 你让它写查询接口，它直接字符串拼接SQL，没做任何过滤。
危害： 上线就是漏洞。
规避： 提示词里明确写"所有数据库操作必须使用参数化查询，不允许字符串拼接"。
坑4：过度封装——把三行能解决的事搞成三层抽象
现象： AI特别喜欢"设计模式"，一个简单的CRUD它给你套上Repository、Service、Factory三层。
危害： 你的小项目变成了Enterprise Java开发，维护成本飙升。
规避： 在提示词里加"保持简单，不要过度设计，优先直出实现"。
坑5：改坏原有工程——它不理解你的全局依赖
现象： 你让它改一个工具函数，它顺手把调用这个函数的三个地方也改了，而且改的逻辑跟你原意不符。
危害： 牵一发动全身，回归测试全挂。
规避： 明确告诉它"只改这个文件，不要动其他文件"，改完自己diff一遍。
【金句：AI给你的代码，是草稿不是终稿——你不review，线上就替你review。】
三、完整案例复盘：用AI搞定一个复杂的多租户权限模块
背景： 我们一个SaaS项目，需要做一套基于RBAC的多租户权限系统，涉及角色、权限、租户隔离三层逻辑，原有代码是去年仓促写的，硬编码一堆。
第一步：投喂上下文
我先把现有的权限表结构、中间件代码、用户模型贴进去，然后写了这段提示词：
"基于现有代码结构，帮我设计一个支持多租户隔离的RBAC权限模块。要求：1）租户ID通过中间件从JWT解析 2）角色和权限存储用现有MySQL表 3）提供一个中间件函数，在请求进入handler前完成鉴权 4）返回403时带明确错误码。用Go语言，使用gin框架。"
中间问题： AI第一版输出把租户ID存到context里但没做隔离，所有租户共享角色表。我追了一句"每个租户的角色数据必须物理隔离或通过tenant_id字段过滤，不能跨租户访问"，它修正了。
第二个问题：它生成的SQL有一处没加租户过滤条件。我把报错信息贴回去，它自己补上了。
最终成果： 一套完整的中间件 + service + dao层代码，包含单元测试。我花了大约3小时做review和微调，如果从零手写，估计要两天。
四、落地行动清单
说句实话，AI编码工具现阶段还是个"半自动"——它能帮你省60%的重复劳动，但剩下40%的架构判断、边界处理、安全审查，还得你自己来。别指望它替你思考，它替你打字就不错了。
你现在就能做的三件事：
- 今天打开你的AI工具，找一个你最近手写超过50行的函数，拆成3个小块分别让它重写，对比你自己的版本哪个更清晰。
- 给你的提示词模板加两条硬约束："只用项目现有依赖"和"输出后附上你改了哪里的diff"。
- 本周挑一个小功能模块，用"写代码→自己写测试→丢回去让AI自测"的流程走一遍，记录节省的时间。
觉得有用可以收藏转发，也欢迎在评论区聊聊你用AI编码踩过最离谱的坑——我猜你的故事比我精彩。
