⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/AI-xiededaimaniganshangxianma/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

30 秒生成的代码，我犹豫了 30 分钟

前几天改一个 BO → VO 转换器，打开 Cursor，把字段对齐的需求描述了一遍——30 秒，代码出来了。结构清楚、命名合理、连注释都有。

我当时第一反应不是「哇好牛」，而是：这个能直接合上去吗？

老实说，我自己也没把握。盯着这段代码看了 30 分钟，才把它合进去。结果某天客户在群里炸了——他登录后台看到了别人的订单。排查了大半天才发现：AI 在自动对齐字段时，把 userId 也写到了 tenantId 上——跨租户数据泄露，P0 事故。

回过头看，这是一笔典型的”历史债撞上 AI 幻觉“事故：

这个项目 3 年前从单租户改成多租户，userId 字段在改造前是事实上的”租户主键”——老代码里部分 tenant_id 直接复用了 user_id 的语义。这种历史债 AI 不知道、读 schema 也读不出来，它只看名字像就连上了——这就是 AI 幻觉最容易翻车的场景。

就是这次踩坑，让我把”AI 写代码该怎么用”这件事重新梳理了一遍。

Cursor + Claude Code，已经成了我的两条腿

不假装这是新鲜玩意。Cursor 写页面、Cursor Tab 补代码、Claude Code 做跨文件重构，这套组合拳打下来效率提升是真实的。

我自己的体感：

以前需要半天的功能，现在大概一两个小时出初版；
CRUD、表单校验、工具函数这类重复活，几乎可以让 Cursor Tab 一边补一边写完，我只管 review；
跨文件大重构（比如把一个老模块拆出去）扔给 Claude Code，它能跨 20 多个文件一次改完。

你从「一行一行写」变成了「出题考 AI」——这种感觉确实挺爽。

但爽归爽，在公司用 AI 写代码，有几件事很多人入坑前没想清楚。

真凶分析：看起来没问题，才是最危险的

为什么 AI 写的代码风险这么大？因为它太擅长满足人类大脑的”快速判断三件套”：

结构 OK ✅；
命名合理 ✅；
跑起来不报错 ✅。

三个条件满足，人脑就自动放行了。但 AI 生成的代码问题往往藏在边界条件、异常处理、并发场景、跨租户隔离里——你不主动去想，根本看不出来。

AI 写的代码不是「错很多」，是「偶尔错，但错得很深」。

平时这种问题完全暴露不出来。一旦触发，就是一片连锁反应——错得很深的代码上了线，爆出来时往往已经是事故级别。

公司场景下还有 3 层非技术风险（按真实严重度排）

个人项目翻车了大不了重来。公司项目翻车，那是真的会背锅的。而且还有一类风险是纯技术之外的——按真实可能踩到的概率 + 严重程度重新排序：

⚠️ 风险 1：漏洞注入（破坏力最大、CVE 已发生）

2025 年安全圈有个新词：Prompt Injection。

有人在 GitHub PR 标题或 Issue 描述里埋恶意指令——当开发者用 Copilot Chat / Cursor / Claude Code 总结这个 PR 时，AI 会被诱导去扫描私有仓库里的密钥或凭证。CVE 编号已经有了（CVE-2025-59145），CVSS 9.6，紧急级别。

不光是 GitHub。还有这些已知场景：

在 issue 评论里植入 prompt，让 AI 自动 push 一段恶意代码到 PR；
在文档 README 里埋 prompt，让接入文档的 AI 把数据库连接串吐到日志；
在 Slack 历史消息里埋 prompt，AI 总结时被诱导泄露内部 token。

⚠️ 风险 2：代码外泄（已经发生过，仍在发生）

把核心业务逻辑粘到 Cursor / Claude Code Chat 里问问题——这段代码就可能上传到第三方服务器。大部分公司用的是公共服务，没有隔离版本。

真实案例：

三星 2023 年：员工用 ChatGPT 调试代码，不小心把芯片源代码传了上去——三星直接禁了全公司的外部 AI 工具；
Apple、Amazon：同样禁止员工往 Cursor / Copilot 里粘内部代码；
国内多家大厂：工程师把核心算法粘到 ChatGPT 让 AI 优化，被风控告警 + HR 谈话。

⚠️ 风险 3：版权问题（潜伏期长但风险真实）

AI 生成的代码可能”参考”了 GPL 协议的开源代码。直接用到公司项目里，理论上有被追诉的可能。

针对 GitHub 的集体诉讼到现在还在打——没什么定论，但风险是真实存在的。一旦判决形成先例，企业被反向追溯的成本极高。

这些风险在个人开发者身上几乎不用考虑，但在公司环境里，每一条都可能是一个审计问题或安全事故。

3 类代码 × 风险矩阵：哪类不能 AI 直接上

类型	代表场景	AI 介入边界	翻车代价
🟢 低风险	UI 组件、工具函数、样板代码、CRUD	大胆用 AI 直接生成	最多显示异常
🟡 中风险	业务逻辑、DTO 转换、状态管理、报表统计	AI 写，但必须自己过一遍	业务异常，可回滚
🔴 高风险	分布式锁、缓存策略、鉴权 / 多租户隔离、风控分数、核心架构	AI 提建议，但不能直接用结果	真的会背锅

判断标准：「我能不能把这段代码每一步跟别人讲清楚」——讲不清楚就不上线。

愚钝如我，有时候还会拿 AI 生成的高风险代码直接合上去，然后在半夜被告警拉醒。踩过一次就老实了。

我现在用 AI 的 5 个习惯

习惯 1：让 AI 做 Reviewer，不只是 Writer

我现在经常反过来用——Claude Code 写代码、Codex 来评审。两个不同模型互相挑刺，比单一模型自审客观得多：

这段代码有什么潜在问题？
高并发场景下会怎样？
有没有边界情况没考虑到？
跨租户场景下会不会数据泄露？

实际跑下来，Codex 经常能挑出 Claude Code 自己看不出的边界条件 / 隐式契约问题——一种”AI 之间互相 cross-check”的玩法。相当于多了一个免费的 code review 层——也会漏，但比什么都不问强。

习惯 2：「二次建模」+「让 AI 当我的私教」

AI 写完之后，我在脑子里重新过一遍：数据怎么流动？状态在哪儿改变？哪里可能出错？

讲不清的地方，直接拿去问 AI——「这段为什么用乐观锁不用悲观锁」「这个 lambda 闭包捕获了什么」「这里为什么要加 synchronized」。让 AI 帮我把它生成的代码讲明白，但最终我自己得能复述一遍。

AI 是私教，不是替身——它帮你建模、帮你查漏，但「我懂这段代码」这个状态，最后只能落在你自己脑子里。讲不清楚，就不上线。

习惯 3：拆小任务 + Git 高频提交

不要一次性让 AI 生成太复杂的东西。任务越复杂，上下文越长，越容易出错，也越难 review。

我现在的节奏是「每跑通一个小步骤，立刻 commit 一次」——保证工作区永远是干净的。这条对配合 AI 工具尤其重要：

AI 改飞了——git reset --hard HEAD 一秒回到干净状态；
AI 改对了 80%——git add -p 把对的部分 stage，剩下的扔掉重新让 AI 改；
阶段性写岔了想撤回——commit 颗粒小，回退不会牵连其他工作。

「AI 写得快」的最大风险是「错得也快」——Git 高频提交是你给自己留的安全网。

习惯 4：让 AI 写测试 + AI 跑自动化 + AI 自总结，但自己 review 报告

不是说要搞完整的测试体系，至少写几个核心路径的测试。

我自己现在的玩法是：

AI 写单测——根据业务方法直接生成 JUnit + Mockito 用例，覆盖 happy path + 边界 + 异常；
AI 跑前端自动化——配合 chrome-devtools-mcp，AI 自己开浏览器走 SOP（登录 / CRUD / 关键路径），DOM 异常 / Console 报错自己抓；
AI 写测试报告总结——跑完后让 AI 出一份「通过率 / 失败 case 分类 / 可疑点」，但我自己一定要 review 这份报告——AI 写的报告也可能漏标关键失败。

回到 DTO 转换器那个 case，如果当时让 AI 顺手写一个「跨租户不能拿到对方数据」的测试，就能提前发现。两行代码，但管用。

习惯 5：加可观测性

对于关键逻辑，无论谁写的——加 log、加监控、加错误上报。你无法完全预判 AI 生成的代码，那就让它运行时「讲话」。

Cursor 还是 Claude Code？看场景分

不同场景适合不同工具，别一把梭。

Cursor：实时副驾驶

在 IDE 里补全代码、提示下一步、Cursor Tab 多行预测——几乎无感。写样板代码、做单元测试，速度和集成度好，日常开发的标配。

Claude Code：自主行动的代理

可以读你整个项目、跨文件理解上下文，能执行「把这个模块从 Webpack 迁移到 Vite 并修复所有报错」这种多步骤任务——不用一步一步操作。

但 Claude Code 的”自主”是双刃剑。有记录在案的案例：

2025 年底：开发者给 Claude Code 发了一个指令——因为描述不够清晰，它自己判断后删掉了 200GB 历史文件；
某团队：让 Claude Code 跑 test-fix 循环——它陷入逻辑死循环，几个小时消耗了几千美元 API 额度；
某外包公司：Claude Code 自己 commit 了一段调用付费 API 的代码——月底账单出来才发现额外多了一千多美金。

这不是说 Claude Code 不好——能力越强，边界就越重要。

我的真实用法（顺序很重要）：

先用 Claude Code 把功能”先跑通”——把需求描述清楚，让它跨文件实现一个能编译、能跑通核心 case 的版本，速度优先于优雅；
再用 Cursor + Cursor Tab 做”精雕”——把 Claude Code 写的代码逐行 review，命名、抽函数、补边界、改注释、调日志——Cursor Tab 的多行预测在重构阶段比生成阶段更香；
最后让 Codex 来”挑刺”——如习惯 1 所说，让另一个模型扫一遍，看看 Claude Code 漏了什么。

Claude Code 适合”从 0 到 1 跑通”，Cursor Tab 适合”从 70 分到 95 分”——顺序反过来用，效率会大打折扣。给 Claude Code 的指令一定要写得具体，不给模糊任务。

我的判断：写得快不是终点，会规划 + 会自测才是

我现在依然大量使用 AI，甚至比以前更多。但我给自己设了一条底线：

我可以不写代码，但我不能不理解代码。

理解不代表每行都要自己写，是「我能解释这段代码在干什么、为什么这么干、可能在哪儿出问题」。讲不清楚就不提交，先搞懂再说。

但光理解还不够。真正决定你工程师段位的是这两件事：

🎯 写 prompt 前先做规划——别上来就敲「帮我写个 XXX」。先把数据流、状态、边界、异常路径在脑子里跑一遍，prompt 才能写得精准。AI 是放大器——你的规划清晰，它才能写对；
🧪 写完后必须自己自测——核心路径的测试用例自己写。别只跑 happy path，至少补三类：
- 边界（空值、超长字符串、负数、并发）；
- 异常（网络超时、DB 失败、缓存 miss）；
- 跨租户 / 跨权限（多租户系统必测）。

守住这条线，AI 是加速器；守不住，它就是放大器——把风险放大。

AI 时代的工程师段位：从「会写代码」转向「会规划 + 会自测 + 会 review」。

那究竟用还是不用？用，但要管好它——就像用任何一个新来的同事一样：可以交任务，但要 review、要验证、要理解。只不过这个”新同事”写代码比任何人都快，所以你的 review 能力比以前更重要了，不是更不重要。

芋道源码 —— 纯源码解析博客

Claude Code / Cursor 写的代码，你敢直接上线吗？我踩过一次坑，再也不敢