这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事上“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本30 秒生成的代码我犹豫了 30 分钟Cursor Claude Code已经成了我的两条腿真凶分析看起来没问题才是最危险的公司场景下还有 3 层非技术风险按真实严重度排3 类代码 × 风险矩阵哪类不能 AI 直接上我现在用 AI 的 5 个习惯Cursor 还是 Claude Code看场景分我的判断写得快不是终点会规划 会自测才是30 秒生成的代码我犹豫了 30 分钟前几天改一个 BO → VO 转换器打开 Cursor把字段对齐的需求描述了一遍——30 秒代码出来了。结构清楚、命名合理、连注释都有。我当时第一反应不是「哇好牛」而是这个能直接合上去吗老实说我自己也没把握。盯着这段代码看了 30 分钟才把它合进去。结果某天客户在群里炸了——他登录后台看到了别人的订单。排查了大半天才发现AI 在自动对齐字段时把userId也写到了tenantId上——跨租户数据泄露P0 事故。回过头看这是一笔典型的历史债撞上 AI 幻觉事故这个项目 3 年前从单租户改成多租户**userId字段在改造前是事实上的租户主键** ——老代码里部分tenant_id直接复用了user_id的语义。这种历史债 AI 不知道、读 schema 也读不出来它只看名字像就连上了——这就是 AI 幻觉最容易翻车的场景。就是这次踩坑让我把AI 写代码该怎么用这件事重新梳理了一遍。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/Cursor Claude Code已经成了我的两条腿不假装这是新鲜玩意。Cursor 写页面、Cursor Tab 补代码、Claude Code 做跨文件重构这套组合拳打下来效率提升是真实的。我自己的体感以前需要半天的功能现在大概一两个小时出初版CRUD、表单校验、工具函数这类重复活几乎可以让 Cursor Tab 一边补一边写完我只管 review跨文件大重构比如把一个老模块拆出去扔给 Claude Code它能跨 20 多个文件一次改完。你从「一行一行写」变成了「出题考 AI」——这种感觉确实挺爽。但爽归爽在公司用 AI 写代码有几件事很多人入坑前没想清楚。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/真凶分析看起来没问题才是最危险的为什么 AI 写的代码风险这么大因为它太擅长满足人类大脑的快速判断三件套结构 OK ✅命名合理 ✅跑起来不报错 ✅。三个条件满足人脑就自动放行了。但 AI 生成的代码问题往往藏在边界条件、异常处理、并发场景、跨租户隔离里——你不主动去想根本看不出来。AI 写的代码不是「错很多」是「偶尔错但错得很深」。平时这种问题完全暴露不出来。一旦触发就是一片连锁反应——错得很深的代码上了线爆出来时往往已经是事故级别。公司场景下还有 3 层非技术风险按真实严重度排个人项目翻车了大不了重来。公司项目翻车那是真的会背锅的。而且还有一类风险是纯技术之外的——按真实可能踩到的概率 严重程度重新排序⚠️ 风险 1漏洞注入破坏力最大、CVE 已发生2025 年安全圈有个新词Prompt Injection。有人在 GitHub PR 标题或 Issue 描述里埋恶意指令——当开发者用 Copilot Chat / Cursor / Claude Code 总结这个 PR 时AI 会被诱导去扫描私有仓库里的密钥或凭证。CVE 编号已经有了CVE-2025-59145CVSS 9.6紧急级别。不光是 GitHub。还有这些已知场景在 issue 评论里植入 prompt让 AI 自动 push 一段恶意代码到 PR在文档 README 里埋 prompt让接入文档的 AI 把数据库连接串吐到日志在 Slack 历史消息里埋 promptAI 总结时被诱导泄露内部 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-mcpAI 自己开浏览器走 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 能力比以前更重要了不是更不重要。欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*