乐于分享
好东西不私藏

AI写代码的边界在哪?我踩过的个坑

AI写代码的边界在哪?我踩过的个坑
你可能听过这种说法:"AI写的代码比新手强、语法完美、风格统一"。在我踩坑后发现:AI写的代码边界,比你想象的要窄。这篇文章不是告诉你AI有多厉害,而是告诉你AI在哪会翻车、为什么会翻车,以及如何绕过这些坑。

看下面的数据就知道目前AI代码质量有怎样的离谱

Sonar在2025年8月发布的报告(基于4442个Java任务)揭露了一个残酷事实:所有主流LLM生成的代码中,60%-70%的安全漏洞是最高严重等级(BLOCKER),90%存在代码异味(Code Smells)。
CodeRabbit的《2025年度AI与人类代码生成现状报告》更直观:分析了470个真实GitHub PR后,他们发现AI参与的代码问题数量是人类的1.7倍(10.83 vs 6.45 per 100 PR)。
问题类型
AI vs 人类
严重程度
逻辑错误
+75%
高(执行时才暴露)
安全漏洞
+174%(2.74倍)
极高(BLOCKER级别)
可读性问题
+215%(3.15倍)
中(影响维护)
错误处理缺失
+近2倍
所以,你以为AI帮你省了review时间,实际上它把bug换了个地方藏着——藏在你更难发现的地方。

AI擅长的:目前这些场景可以放心用

1. 标准库API调用

当你想用Array.prototype.reduce但记不清签名时,AI几乎不会出错。
// 场景:把 [{name, score}, ...] 转成 {name: score, ...}const students = [ { name'Alice'score92 }, { name'Bob'score85 }];// AI几乎完美完成这个任务const scoreMap = Object.fromEntries( students.map(s => [s.name, s.score]));// 结果:{ Alice: 92, Bob: 85 }
为什么几乎完美:因为在训练的数据中有大量的标准库使用示例,概率最高的用法被反复强化。

2. 简单算法的确定性实现

排序、二分查找、链表操作——只要题目不涉及边界条件,AI的正确率很高。

3. 代码模板生成

React/vue/angular等组件骨架、Express路由脚手架、测试用例等模板框架。AI能把样板代码写得比大多数新手整洁。

AI不擅长的:踩坑示例

坑1:边界条件漏掉

案例:我要一个解析URL参数的函数。
// AI生成的代码(看似正确)function parseParams(url) { const query = url.split('?')[1]; const params = {}; query.split('&').forEach(pair => { const [key, value] = pair.split('='); params[key] = value; }); return params;}// 测试:parseParams('https://example.com/?name=Alice'); // 报错!// query是 undefined,undefined.split('&') 报错
问题:没有处理无查询参数的URL,也没有处理空值情况。
正确写法
function parseParams(url) { const queryString = url.split('?')[1]; if (!queryString) return {}; return queryString.split('&').reduce((params, pair) => { const [key, value = ''] = pair.split('='); // 解码URL编码 params[decodeURIComponent(key)] = decodeURIComponent(value); return params; }, {});}
踩坑教训:每次让AI写解析函数,必须测试:空输入、空值、URL编码、重复key。

坑2:并发暴露的安全问题

案例:用户列表缓存,用Map存储。
// AI生成的缓存(危险!)const userCache = new Map();async function getUser(id) { if (userCache.has(id)) { return userCache.get(id); } // 这之间可能有其他请求也在查同一个id const user = await fetchUser(id); userCache.set(id, user); // 可能重复请求 return user;}
问题:高并发下,同一id的多个请求会同时触发fetchUser,而不是复用缓存。
正确写法
const userCache = new Map();const pendingRequests = new Map(); // 存储 Promiseasync function getUser(id) { if (userCache.has(id)) { return userCache.get(id); } // 如果已有请求在 pending时,直接复用 if (pendingRequests.has(id)) { return pendingRequests.get(id); } const promise = fetchUser(id).then(user => { userCache.set(id, user); pendingRequests.delete(id); return user; }); pendingRequests.set(id, promise); return promise;}
踩坑教训:涉及缓存、Map、数组修改的场景,必须考虑并发问题。这类bug在开发环境测不出来,在生产环境下,如果存在高并发时才暴露。

坑3:业务逻辑缺少情绪规则

案例:订单金额计算,AI给折扣。
// 场景:订单金额满1000减100或9折,订单数量大于5时减50// AI生成的折扣逻辑function calculateDiscount(order) { let discount = 0; if (order.total > 1000) { discount += order.total * 0.1// 1000以上打9折 } if (order.items.length > 5) { discount += 50// 超过5件减50 } return discount;}
问题:两个折扣叠加使用,而业务规则是"满1000减100或9折,取最优",且不能超过订单金额的30%。
踩坑教训:业务规则必须明确写出约束,AI不懂业务情绪中的潜规则。

坑4:安全漏洞

Sonar的数据显示,AI生成的代码安全漏洞是人类的2.74倍。常见模式:
硬编码密文
// AI会这样写const API_KEY = 'sk-1234567890abcdef';const DB_PASSWORD = 'admin123';// 正确做法如下const API_KEY = process.env.API_KEY;const DB_PASSWORD = process.env.DB_PASSWORD;if (!API_KEY) { throw new Error('API_KEY environment variable is required');}
SQL注入
// AI生成的(危险,有sql注入风险)const query = `SELECT * FROM users WHERE name = '${name}'`;// 正确做法:参数化查询const query = 'SELECT * FROM users WHERE name = $1';await db.query(query, [name]);
踩坑教训:所有涉及外部输入的地方,必须要亲自检查一遍安全。

坑5:API版本和依赖幻觉

//AI生成的(2025年了还在用旧API)import { getServerSideProps } from 'next';// Next.js 15 App Router早就废弃了这个// AI说这个库版本存在,但我用npm install失败import { something } from 'fancy-library@99.99.99'// 根本不存在// 正确import { cookies } from 'next/headers';export async function GET() { const cookieStore = cookies(); const token = cookieStore.get('token'); // ...}
踩坑教训:AI的训练数据有截止日期,不是所有模型都是实时与世界时间、知识同步,2025年初的模型不知道2025年底发布的库版本。

SWE-bench:AI真实能力的天花板

SWE-bench是业界最权威的AI编程评测基准,用真实GitHub Issue测试模型。2025年的数据:
模型
SWE-bench Verified
实际场景估计
Claude 4.5 Sonnet
77.2%
30-50%
GPT-5.2 Codex
74.1%
25-45%
Gemini 3 Pro
68.3%
20-40%
为什么实际场景估计比基准低这么多?
因为SWE-bench测试的是独立问题,而真实开发中:

需要理解整个代码库的隐式约定、用户群体、业务规则.....

跨多个代码仓的修改

处理CI/CD、部署、监控、体积等工程等问题

SWE-bench Pro(更难)最高分只有23.3%,说明现实世界比基准难3-4倍

当前的边界图:什么时候用AI,什么时候自己写

┌─────────────────────────────────────────────────────────────┐│ AI适合的场景 │├─────────────────────────────────────────────────────────────┤│ • 标准库/框架API调用 ││ • 简单算法实现(排序、查找) ││ • 代码模板和脚手架 ││ • 解释现有代码逻辑 ││ • 生成测试用例骨架 ││ • 重构模式匹配(如class → hooks) │└─────────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────────┐│ 人类主导的场景 │├─────────────────────────────────────────────────────────────┤│ • 边界条件复杂的状态逻辑 ││ • 并发/异步竞态问题 ││ • 业务规则和领域逻辑 ││ • 安全敏感代码(认证、支付、数据处理) ││ • 跨模块架构决策 ││ • 性能优化和内存管理 │└─────────────────────────────────────────────────────────────┘

总结:

测试空输入——AI永远假设happy path(理想路径),先测空值、null、undefined
加并发注释——涉及Map/Array修改时,要问AI"高并发下会怎样"
安全盲查——所有外部输入都是攻击面,用AI生成时要手动过一遍安全
版本锁定——明确写出框架/库版本,不要让AI猜
业务逻辑review——AI不懂啥的折扣规则、复合流程条件、审核流程、权限模型
先跑再合——AI代码必须本地运行一遍,不能简单review就合并

总之AI写代码的优势是速度和广度,劣势是深度和边界。用它生成初稿、模板、标准操作,然后用自己的经验过滤bug——这是当前AI编程的正确姿势。把AI当实习生看:能干活,但要review,不能放任。