背景

作为一个5年游戏后端经验的程序员，面对如今ai的变化，有点猝不及防。即使学了claude code开发，但是目前基本上都是依赖ai写出CLAUD.md。到现在并不知道合格的ai开发能力应该是怎样的。

带来失控感的原因

• 生成代码多了，Review 不过来，质量心里没底。Vibecoding 最大的坑不是 AI 写得差，而是人从"我在写"变成了"我在审"，而审的又是自己没从头构思过的东西。

• 经验不够，不知道 AI 给的方案是不是工业级的

• 不知如何真正上手ai开发

怎么解决这种感觉

解决审核不了的感觉

• 定契约，AI 填实现：协议（Protobuf/消息定义）、模块边界、数据流向、错误码语义——这些你自己写或至少自己审完再让 AI 填 handler / 业务逻辑 / 配表解析。AI 填 100 行业务逻辑的 Review 成本，远低于 AI 从 main 开始糊 500 行。

• 让 AI 自己写测试，你审测试用例而不是实现：AI 写单测 / 场景测试的覆盖率比写实现还强。你看"它覆盖了哪些边界"比看"它怎么实现的"更快能判断靠不靠谱。游戏后端尤其要测并发（匹配、结算、道具扣除这些）——让 AI 写压测脚本你跑。

• 关键路径手动写一遍：核心循环（比如战斗结算、拍卖行事务、跨服匹配）你自己写第一版，旁边让 AI 写个对照版，对比差异。差异点就是你的学习素材——为什么 AI 用了个你没想到的锁粒度？为什么它选了 Redis Lua 而不是分布式锁？

用一个实现兑换码的功能来感受

什么叫"你定骨架，AI 填肉

❌ Vibecoding 式（你现在的痛点来源）

“帮我写个兑换码功能，Go + Redis + MySQL，玩家输入 code 领奖励。”

AI 会给你吐 400 行：从 HTTP handler 到 Redis 操作到 DB 到发奖励全糊一起。你 review 的时候：

• 锁用的是 SETNX还是 Redlock？它没说清

• 奖励发放是同步调背包 RPC 还是异步？它随手写了个同步

• code 校验和扣减是不是原子？它可能分了两步

• 你心里没底，但又懒得逐行抠，只能"跑通了先，上线再说"​ → 埋雷

✅ 骨架法（你要转的方向）

1. 你自己出"骨架文件"，只写契约 + 关键决策，不写实现。

你创建一个 readme.md或直接在代码里留骨架，内容大概这样（5-10 分钟能写完）：

// === 兑换码子系统骨架 ===

// 1. 接口
// POST /redeem  {code: string} -> {err_code, rewards[]}

// 2. 错误码（你自己定，不是让AI猜）
// ERR_CODE_INVALID = 1001  // code不存在/过期
// ERR_CODE_USED = 1002     // 已使用
// ERR_CODE_CONCURRENT = 1003  // 并发冲突，客户端重试
// ERR_CODE_BAG_FULL = 1004

// 3. 数据层
// - MySQL: redeem_code (code, status, player_id, used_at)  -- 持久化
//   （这里故意不一开始就用Redis存全量code，百万级MySQL顶得住，
//    热点code才上Redis，这个决策你自己做，不交给AI）
// - Redis: 不发全量code，只用 SETNX {code}:{player_id} NX EX 300 做并发锁

// 4. 关键决策（这些是你"架构味"的体现）
// - 幂等：同 player+code 重复请求直接返回已使用，不发奖
// - 一致性优先级：code 扣成功 > 奖励发成功（宁可补发，不能多发）
// - 不发奖走补偿队列，不全同步阻塞

2. 让 AI 按骨架填肉

"按上面骨架实现 Readme 接口的 handler + service 层，MySQL 用 GORM，Redis 用 go-redis。注意：

• 并发锁用 Redis SETNX，锁 key 是 redeem:{code}:{player_id}
• code 校验 + 状态更新必须在同一个 MySQL 事务里
• 调背包 RPC 失败不要回滚 code 状态，记补偿表 async_compensate，返回客户端 ERR_CODE_BAG_FULL
• 给我写单元测试覆盖：重复提交 / 同 code 两人并发 / 背包满"

AI 出来的代码review 什么？不用逐行——你只看：

• 事务是不是包住了 SELECT FOR UPDATE + UPDATE status？（一致性）

• SETNX 的 EX 设的多少？300 够不够？（生产细节）

• 补偿表有没有落？（兜底）

• 单元测试那三个场景是不是真测了？（边界）

关键逻辑

你手动写"兑码核心事务"这一段（大概 30-50 行）

// 你就手写这部分，别的（HTTP handler、校验 format、查配置）让 AI 写
func (s *RedeemService) Redeem(ctx context.Context, playerID int64, code string) (*Reward, error) {
    // 1. Redis SETNX 防并发
    lockKey := fmt.Sprintf("redeem:%s:%d", code, playerID)
    ok, err := s.redis.SetNX(ctx, lockKey, "1", 300*time.Second).Result()
    // ...
    
    // 2. MySQL 事务：校验 + 扣 code
    // SELECT status FROM redeem_code WHERE code = ? FOR UPDATE
    // if status != 0 -> return ERR_USED
    // UPDATE redeem_code SET status=1, player_id=? WHERE code=?
    
    // 3. 调背包 RPC 发奖
    // 4. 失败落补偿表
}

然后让 AI “按同样接口和骨架，给我一版完整实现”，拿出来对比。

对比的时候你盯的不是"谁对谁错"，是这几件事：

1. AI 有没有比你多考虑了你漏的边界

   比如你忘了"code 格式非法直接返回，不走 Redis 锁"——AI 加了，那你学这一条：前置校验提前 return 省一次 Redis。你 5 年没碰过架构，但这种"少一次 IO"的嗅觉就是架构感，看 AI 的差异比看教程学得快。

2. AI 用的锁 / 事务粒度跟你不一样 → 这是你查资料的入口

   比如你用的 SETNX EX 300，AI 用了 SET key uuid NX PX 300（带 uuid 防误释放）——你一查，哦原来 SETNX 单命令没问题但释放时得校验 value，这是 Redis 锁的经典坑。你手动写的那版可能就漏了，AI 对照版帮你暴露了。

3. AI 犯的蠢你要能识别 → 这就是"判断力"的训练

AI 很可能干这种事：

• 把 code 校验放事务外面，先 UPDATE 再 SELECT（顺序反了，并发会多发）

• 补偿表落了但没建索引，以后补发脚本扫全表

• 错误码返回 500 而不是你定义的 1003，前端重试逻辑崩

你能识别出"这行 AI 写傻了"，你就已经超过一半的 vibecoder 了。​ 而且识别次数多了，你下次手写就会避开——这就是"5 年长出 8 年判断力"的具体路径。

4. 对照版 = 你下次的骨架素材

   AI 这版里写得好的（比如它处理"背包 RPC 超时后怎么判定要不要回滚"的逻辑比你周全），你直接吸收进你下一版的骨架 convention 里。相当于 AI 是你的"高级同事"，你抄它好的，改它蠢的——但前提是你自己先写过一版，才有"对比"的锚点。

经验不足，如何判断ai的方案是否合理

游戏后端设计功能时常要思考的几个方面，在ai给出方案时，都要针对以下几个方面“拷打”

并发

• 这玩意儿跨不跨进程？要不要分布式锁？

• 玩家断线重连 / 服务器宕机，状态怎么恢复？

• 有没有竞态？举个例子：背包加物品和 兑换码兑换同时打到会不会多发？

• 数据库和缓存的一致性怎么保？（写穿？删缓存？延迟双删？）

AI 给的方案你拿这几个问题反问它，它的回答比原方案更值钱——因为你会看到它什么时候开始含糊、开始加"在生产环境建议…"这种套话，那就是它心虚的地方，你得自己再查。

性能 & 规模感

• 让 AI 帮你做容量估算：这个数据结构内存占多少？这个 RPC 在 1w 人同时在线时 QPS 多少？

• 让它给你列业界同类玩法的常见方案对比（比如 MMO 副本管理：进程模型 vs 协程池 vs actor），它列得出来说明这方案真在工业界存在，列不出来基本就是它编的。

可观测性 & 运维

• 这个模块挂了怎么告警？

• 日志能不能定位到单个玩家的行为链？

• 有没有灰度 / 热更 / 回滚路径？

AI 几乎不会主动考虑这些，但它答得上来说明方案老练。你可以主动让 AI “以资深架构师的身份 review 你这段设计，重点关注生产故障场景”，它扮演这个角色比写代码还像样。

掌握ai工作流

1. 选一个你熟悉的、但还没用 AI 深度参与过的子系统

别选新项目，别选你没接触过的领域。从你已经理解业务逻辑、但觉得"写起来烦"的模块入手。比如：

• 邮件/通知推送服务

• 成就系统（条件触发 + 奖励发放）

• 好友关系（添加/删除/黑名单/在线状态）

• 每日签到/月卡续费

目的：让你能把注意力放在"怎么和 AI 配合"上，而不是"这个业务逻辑是什么"上。

2. 花 15 分钟写一份"项目级 AI 协作公约"
   这份文件就是你和 AI 之间的"宪法"。之后每次开启新对话或新任务，都把它贴在 prompt 开头（或者放到项目根目录让工具自动读取）。AI 会严格遵循这些规则输出，你就不需要每次都重复说"错误码用 xxx"。
3. 执行"骨架 + 填充 + 对照"循环
4. 让ai输出完整的实现和测试代码。然后把 AI 的实现复制到本地的文件中，运行测试。
5. 对比AI和自己编写的骨架之间有哪些差异
   • AI 有没有引入你没预料到的依赖？
   • 它的事务范围比你想象的大还是小？
   • 它的错误处理是否符合你的公约？
   • 它的测试用例是否真的覆盖了并发场景？
     每发现一个差异，就是一个学习点。把它记下来，要么更新公约，要么下次你在骨架里写得更细。