作为一个后端开发，我用AI写代码也有三个月了。
刚开始那阵子，感觉自己像个傻子——问10次有8次答非所问。
直到我憋出这套框架，才突然开窍：原来不是AI笨，是我不会"下指令"。
今天就把这套让我效率翻10倍的RBTRO框架分享出来，全是后端开发的真实场景。
一、我是怎么从"瞎试"到"有框架"的
刚开始用AI时，我的对话是这样的：
我："帮我写个线程池"
AI：给出一个最基础的ThreadPoolExecutor示例
我：不对，我要能动态调整大小的
AI：给出一个稍微复杂点的
我：还是不对，我要带监控和拒绝策略的
AI：...（来回七八次）
后来我发现，这跟我给实习生派活一个道理：不说清楚背景和要求，对方只能猜。
于是我把平时写需求文档的思路搬到AI上，憋出了这套框架。
二、RBTRO框架：后端开发的"AI需求文档"
这5个字母，对应我们写需求时的5个必填字段：
R - Role（角色）
让AI扮演什么？资深架构师？JDK源码贡献者？还是线上救火工程师？
B - Background（背景）
什么场景？QPS多少？数据量多大？有啥特殊限制？
T - Task（任务）
具体干啥？写代码？review？设计架构？分析日志？
R - Requirements（要求）
性能指标？代码规范？异常处理？注释风格？
O - Output（输出格式）
直接可运行的代码？架构图描述？还是表格对比？
三、后端实战：改造前后的天壤之别
场景1：写个生产级线程池
❌ 改造前：帮我写个线程池
✅ 改造后：
角色：JDK并发包核心开发者
背景：电商系统，峰值QPS 5000，任务执行时间100ms-2s不等
任务：设计一个动态线程池
要求：1.支持动态调参 2.有监控指标输出 3.拒绝策略自定义 4.符合阿里巴巴规范
输出：完整Java类+注释+使用示例
效果：从基础demo → 直接能上线的生产代码
场景2：分析线上OOM日志
❌ 改造前：看看这个堆栈
✅ 改造后：
角色：JVM调优专家，处理过100+线上故障
背景：生产环境凌晨3点OOM，dump文件5GB，重启后恢复
任务：分析堆栈日志，定位根因
要求：1.给出最可能的原因TOP3 2.每点配证据 3.提供应急方案 4.给出长期优化建议
输出：markdown格式，【根因分析】【应急方案】【优化建议】三部分
效果：从"可能是内存泄漏" → 精准定位到"ThreadLocal未清理+连接池配置不当"
场景3：设计秒杀系统
❌ 改造前：设计一个秒杀系统
✅ 改造后：
角色：电商大促架构师，经历过双11
背景：100万库存，10万QPS，要求不超卖，响应<200ms
任务：设计整体方案
要求：1.包含缓存、队列、DB三层设计 2.防刷策略 3.降级方案 4.成本可控
输出：架构图文字描述+核心代码+风险清单
效果：从概念性描述 → 可直接评审的完整方案
场景4：理解Raft协议
❌ 改造前：解释下Raft
✅ 改造后：
角色：分布式系统资深讲师，擅长打比方
背景：团队要从主从切换自研方案，需评估Raft
任务：讲解Raft核心原理
要求：1.用"选班长"做比喻 2.讲清楚Leader选举、日志复制、安全性 3.对比ZAB 4.避免数学公式
输出：markdown，【比喻故事】【核心机制】【对比表格】
效果：从死记硬背 → 真正理解并能给团队培训
场景5：写技术方案文档
❌ 改造前：写个方案
✅ 改造后：
角色：技术文档工程师，熟悉Spring Cloud生态
背景：将订单服务从单体拆分出来，用DDD重构
任务：写技术方案文档
要求：1.包含上下文图、领域模型 2.接口契约 3.迁移步骤 4.回滚预案 5.符合架构评审规范
输出：markdown，4级目录结构
效果：从流水账 → 架构评审能过的专业文档
四、后端专用prompt模板库（直接复制）
模板1：Code Review
角色：阿里巴巴Java开发手册编写者
背景：这是支付核心模块，刚入职同事写的代码
任务：做Code Review
要求：找出3个潜在bug，2个性能问题，1个可维护性问题，引用规范条款
输出：表格【问题类型】【位置】【严重程度】【修改建议】【规范引用】
模板2：生成单元测试
角色：JUnit框架贡献者
背景：这是一个并发扣款逻辑，对数据一致性要求极高
任务：生成单元测试
要求：1.覆盖正常、异常、并发三种场景 2.使用参数化测试 3.有性能基准测试 4.测试名称清晰
输出：完整测试类+测试数据工厂
模板3：设计缓存方案
角色：Redis内核开发者
背景：用户中心QPS 2万，数据变更频繁，允许秒级延迟
任务：设计缓存更新策略
要求：1.对比Cache Aside、Write Through等5种方案 2.给出选型理由 3.包含伪代码 4.说明缓存穿透、击穿、雪崩应对方案
输出：对比表格+架构描述+核心代码
五、我的踩坑总结
这三个月，我还发现几个反直觉的点：
不是说得越多越好：背景要精准，别写废话。我曾把业务历史全倒出来，AI反而抓不住重点。
角色比你想的重要：指定"JDK源码贡献者"比"Java工程师"得到的代码深很多。
输出格式要具体：说"表格"不如"3列8行的markdown表格，列分别是..."来得准。
一次只解决一个问题：别把写代码+写文档+设计架构全塞给一个prompt，会互相干扰。
六、最后的话
这套框架，本质上就是把我们写给人的需求文档，换个对象写给AI。
后端开发天天写PRD、写技术方案、写接口文档，这套思维模式我们本来就有。只是之前没意识到，AI也需要同样清晰的输入。
现在，我把这个"啊哈时刻"分享给你。希望你也少走点弯路。
