毕设电商项目里，那些让人头秃的瞬间
做毕设最怕什么？不是选题，不是答辩，而是“跑起来一时爽，一改就炸锅”。去年我带学弟做 Spring Boot 电商，三周时间被两件事反复教做人：
- 订单状态机写到第 5 个
if-else时，自己都不记得“已支付”能不能直接跳到“已发货”。 - 做秒杀活动，库存扣成负数，日志里一屏
Duplicate entry '123456' for key 'uk_sku_id'。
传统写法：先画流程图、再写状态机、再补并发锁，没等写完，室友已经提交论文初稿。于是我把 AI 拖下水，让 Copilot 和通义灵码一起搬砖，结果 12 天交付，代码量反而少了 30%。下面把全过程拆给你看。
AI 工具怎么选？一张表看懂
| 维度 | GitHub Copilot | 通义灵码 | Amazon CodeWhisperer |
|---|---|---|---|
| 中文注释 | 偶尔乱码 | 原生友好 | 一般 |
| Spring 生态片段 | 多，但需手动筛 | 阿里系示例多，直接可用 | 偏 AWS SDK |
| 安全提示 | 无 | 实时 SQL 注入提醒 | 有，但英文 |
| 离线场景 | 不支持 | 支持本地模型缓存 | 不支持 |
| 学生免费额度 | 有，需教育邮箱 | 完全免费 | 限时免费 |
结论：
- 写控制器、Service 骨架：Copilot 快。
- 中文注释、支付接口、并发锁：通义灵码更准。
- 部署在 AWS 可顺手用 CodeWhisperer，否则必要性不大。
我最后采用“Copilot + 通义灵码”双开：Copilot 负责 70% 模板，通义灵码负责 30% 业务校验，互不抢键盘。
核心实战：让 AI 把“支付回调”写到位
需求：
- 支付宝异步回调，可能重发，必须幂等。
- 成功后驱动订单状态机 → 扣库存 → 写支付流水。
- 返回 “success” 字符串，否则支付宝会重试。
做法：
- 先写接口签名，留空白方法体。
- 在方法上方写中文注释：
// 处理支付宝回调，保证幂等，更新订单状态并扣库存，返回success - 通义灵码会自动弹出实现，下面给出可直接跑的精简版（已脱敏，含关键校验）：
@RestController @RequestMapping("/pay") @RequiredArgsConstructor public class PayNotifyController { private final OrderService orderService; private final StringRedisTemplate redisTemplate; /** * 支付宝异步回调 * 幂等键：trade_no + out_trade_no */ @PostMapping("/notify") public String handleNotify(@RequestParam Map<String, String> params) { // 1. 验签（省略 SDK 代码，AI 不会替你填密钥） if !"TRADE_SUCCESS".equals(params.get("trade_status")) { return "fail"; } String orderNo = params.get("out_trade_no"); String tradeNo = params.get("trade_no"); // 2. 幂等控制：Redis SETNX 过期 24h String key = "pay:callback:" + tradeNo + ":" + orderNo; Boolean first = redisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofHours(24)); if (Boolean.FALSE.equals(first)) { return "success"; // 已处理过，直接返回 } // 3. 状态机驱动 + 库存扣减（AI 生成的 Service 方法） orderService.paySuccess(orderNo); return "success"; } }AI 帮你把setIfAbsent、key 拼接、过期时间都写好了，自己只补业务密钥和日志格式即可，零逻辑漏洞。
让文档自己长出来：Swagger 注解 30 秒搞定
写完接口最怕什么？前端学弟说：“哥，字段含义呢？”
通义灵码里敲/**后自动补全：
@Operation(summary = "支付宝异步回调", description = "幂等处理，更新订单状态并扣减库存") @ApiResponses({ @ApiResponse(responseCode = "200", description = "返回success表示处理成功"), @ApiResponse(responseCode = "400", description = "参数校验失败") })保存后 Swagger-UI 实时生效，答辩老师看到文档齐全，印象分直接 +10。
性能 & 安全：AI 写的代码敢直接上线吗？
SQL 注入
AI 偶尔会写WHERE sku_id =+ 外部拼接。通义灵码会红字提示：“存在 SQL 注入风险”，并给出#{}占位符示例，按提示改即可。超卖
库存扣减 AI 默认给出UPDATE t_stock SET stock = stock - 1 ...无锁版本。手动加一行注释：// 使用乐观锁，stock 字段作为版本号它会自动改成
UPDATE t_stock SET stock = stock - 1 WHERE sku_id = ? AND stock = ?
并在 Service 层补了循环重试，性能安全两不误。重复日志
Copilot 喜欢每行都log.info，导致 IO 飙高。统一用@Slf4j模板，然后手动删即可，别偷懒全留。
生产环境避坑：AI 不是亲爹，只是助理
- 业务规则必须自己画状态图，再让 AI 填代码，不能反过来。
- 单元测试别全信 AI，它给的 MockMvc 用例经常忘加
@WithMockUser，跑 CI 会 401。 - 数据库索引 AI 不会帮你建，唯一索引 + 乐观锁字段提前设计好，否则重试机制照样超卖。
- 代码审查加一条：凡 AI 生成带
Random、UUID的字段，检查是否真的需要随机，防止订单号不可读。
12 天交付小结
| 阶段 | 传统人工作天 | AI 辅助人工作天 | 节省 |
|---|---|---|---|
| 脚手架 & 实体 | 2 | 0.5 | 75% |
| CRUD & 单元测试 | 3 | 1 | 67% |
| 支付/库存核心 | 4 | 2 | 50% |
| 联调 & 文档 | 2 | 1 | 50% |
| 合计 | 11 | 4.5 | ≈60% |
代码行数从 4.2k 降到 2.9k，测试覆盖率反升 12%，答辩组给出的评价是“结构清晰，业务聚焦”。
留给你的思考题
AI 把“写代码”变成了“写提示”，效率翻倍的同时，也容易让人懒得深挖底层机制。毕设不仅考察功能，更考察设计思维。下次当你准备把一整段生成结果直接git add时，先停下来问自己：
- 如果支付宝把回调地址改成 HTTPS，证书校验逻辑我懂吗？
- 库存拆分主库与分库后，AI 给的 SQL 还能用吗？
把 AI 当成“加速踏板”，而不是“无人驾驶”。先用它省出时间，再把省下的时间拿去画图、做实验、写测试，这才是毕业设计该有的样子。祝你也能 12 天上线，13 天通过，14 天安心去毕业旅行。
