说实话，一开始我对“AI 编程”这事儿挺 skeptical 的。 不是觉得它没用，而是太累了——每次让 AI 干点活，都得先当半小时“人肉提示工程师”： “我们返回体叫 Result，不是 Response！” “密码加密用的是 BCrypt，别自己造轮子！” “日志要打 info 级别，别一上来就 error！”
搞得我感觉不是在写代码，是在教一个记性特别差的实习生。
直到上周，我试了飞算的 JavaAI 插件，尤其是它的 「关联上下文」 功能——上传几个项目文件，AI 居然真的“记住”了我们项目的脾气。今天就聊聊两个让我眼前一亮的真实场景。
场景一：让 AI 做了个“新人三天才能搞定”的任务，它 10 分钟交差
我们有个老需求一直拖着没做：订单30分钟未支付自动取消，并发短信提醒用户。
按惯例，这种活会分给刚转正的同事练手——因为涉及定时任务、状态判断、外部调用，还得看懂现有订单服务怎么写的，一般得折腾两三天，外加三次 Code Review 才能合。
这次我决定“偷个懒”，试试飞算的 「智能引导」。
我做了什么？
- 在插件里新建对话，把项目里关键的 10 来个文件拖进去：
Order.java（看状态字段）OrderService.java（看取消逻辑）CommonUtils.java（里面有sendSms()）Result.java、GlobalExceptionHandler.java、application.yml……
- 然后直接打字：“加个定时任务，30分钟没支付的订单自动取消，顺便发个短信。”
它干了啥？
不到一分钟，它吐出一个完整的 OrderAutoCancelTask.java：
@Component
@Slf4j
public class OrderAutoCancelTask {
@Autowired
private OrderService orderService;
@Scheduled(fixedDelay = 1800000)
@Transactional
public void cancelUnpaidOrders() {
List<Order> unpaidOrders = orderService.list(
new LambdaQueryWrapper<Order>()
.eq(Order::getStatus, 0) // 待支付
.lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(30))
);
for (Order order : unpaidOrders) {
try {
orderService.cancelOrder(order.getOrderId()); // 复用已有方法
CommonUtils.sendSms(order.getUserPhone(), "您的订单已超时取消");
log.info("自动取消订单: {}", order.getOrderId());
} catch (Exception e) {
log.error("取消订单失败: {}", order.getOrderId(), e);
}
}
}
}
我惊了：
- 包路径跟我项目一致（
com.xxx.order.task）； - 用的是
LambdaQueryWrapper，不是原生 SQL； - 调的是已有的
cancelOrder()，没重复造轮子； - 短信用
CommonUtils.sendSms()，连模板都照搬我们风格； - 异常被捕获了，没直接抛出去（因为我们全局异常处理器只处理未捕获异常）。
最爽的是——我几乎没改一行，直接跑通了。
这要是以前，光“为什么不用 Result 包装”就得被后端组长问三遍。
场景二：修了个安全漏洞，AI 居然知道我们用 MyBatis-Plus
前几天安全扫描报了个 SQL 注入风险，定位到一段老代码：
String sql = "SELECT * FROM user WHERE email = '" + email + "'";
return jdbcTemplate.queryForObject(sql, User.class);
典型的字符串拼接，危险得很。
我本来打算手动改，但突然想试试 「AI工具箱」里的“Java安全修复器”。
操作很简单：
- 选中这段代码；
- 点插件里的“安全修复”；
- 等它分析（因为它已经加载了上下文）。
结果让我意外：
它没给我甩一句“请使用 PreparedStatement”，而是说：
“检测到项目使用 MyBatis-Plus，建议改用 Service 层的 lambda 查询，避免直接操作 JdbcTemplate。”
然后给了两个选项：
✅ 推荐方案（直接用 MP）：
return this.lambdaQuery().eq(User::getEmail, email).one();
🛠️ 兼容方案（如果非要用 JdbcTemplate）：
return jdbcTemplate.queryForObject(
"SELECT * FROM user WHERE email = ?",
new BeanPropertyRowMapper<>(User.class),
email
);
还贴心备注：“根据 pom.xml，项目已引入 mybatis-plus-boot-starter，推荐使用方案一。”
这哪是 AI？这简直是那个总在 MR 里留言“建议用 MP”的架构师本人。
更绝的是，我顺手点了“生成单元测试”，它居然：
- 继承了我们的
BaseTest； - 用
@MockBean模拟了 mapper； - 测试用例覆盖了“查到用户”和“查不到”两种情况。
说点实在的：它也不是万能的
当然，用下来也发现几个小痛点：
- 大项目上传慢：我们微服务模块一多，首次分析得等半分钟；
- 改了代码得手动刷新上下文：比如我刚重构了
Result类，但 AI 还按旧结构生成，得重新上传； - 前端文件基本看不懂：传了个
.vue文件，它直接忽略。
但这些瑕不掩瑜。最大的价值是：它终于不用我一遍遍解释“我们项目是怎么玩的”了。
最后想说
以前我觉得 AI 编程就是“快一点的 Copilot”。
以前我以为 AI 编程只是“更快一点的 Copilot”。
现在才明白，真正的差距不在速度，而在理解力。
飞算 JavaAI 的「关联上下文」功能，本质上是在说：
“我不是来替你写代码的——我是来加入你团队的。”
如果你也受够了这些 AI 生成的“标准答案”：
- 格式不对、命名随意
- 忽略项目规范
- 忘记统一响应体、漏掉权限校验……
不妨让它先读一读你的代码。
说不定，它比刚入职的实习生更懂你的工程风格。
🎁 现在参与官方「AI 编程炫技赛」，还能赢三重好礼：
京东卡、年货大礼包、专属荣誉证书等你拿！
🔗 活动入口：activity.feisuan.com/
🌐 官网体验：www.feisuanyz.com/home
📘 产品手册：www.feisuanyz.com/docs/langua…
🎥 功能演示 & 场景视频：mp.weixin.qq.com/s/YnVlWB960…
让 AI 真正成为你开发流程中可靠的一环——从“写得快”，到“写得对”。
