叮~ 产品群里弹出一条消息：
"下个版本上线'送礼连击'功能，参考头部直播平台，越快越好，赶周末大主播专场。"
你扫了一眼需求，觉得"不就是个计数器加个推送吗"。于是建分支、写接口、联调、提测。
周末专场直播开启，在线人数破万，问题接踵而至：
- 主播抱怨："连击数卡住不动了，特效也不飘了，粉丝全在刷屏问怎么回事。"
- 用户投诉："钱扣了礼物没送出去。" "进厅卡成PPT了。"
- 财务对账："礼物送出与后台结算差了1.2%，钱对不上。"
- 监控报警：
Redis CPU 85%MySQL CPU 100%Kafka 消息积压 100万 - 复盘会上，客户端说"连击消息推送太频繁导致厅内卡顿"，测试说"没测大量用户在线的场景"，你说"需求文档只写了加计数器"。
需求拍脑袋，开发拍胸脯，上线拍大腿，复盘拍桌子。
这不是代码质量问题。是需求拆解缺失。
大多数程序员接到需求的第一反应是"How to implement"（怎么实现），忽略了最该问的"What to protect & what to sacrifice"（保什么、舍什么）。
没有需求拆解，交付越快，埋雷越深。
为什么你总在救火？
需求分析不是翻译题，不是把PRD逐字转成CRUD。
不做需求拆解直接写代码，会触发三个连锁反应：
1. 理解偏差。
没有理解需求本质：强上"可牺牲"的高消耗功能，上线后拖垮主功能；对后续迭代判断不足，代码成了维护黑洞。
2. 边界遗漏。
并发边界、时间边界、数值边界、状态边界……这些产品不写、测试不测的隐性需求，最终都会变成线上的客诉与资损。
3. 架构腐烂。
魔法数字、重复代码、多层嵌套、临时方案堆砌。短期能跑，长期变成"谁改谁背锅"的祖传代码。
根本原因：缺少一套结构化的权衡框架。
架构师和普通开发的区别，不在于谁写的代码更优雅，而在于谁能在需求阶段就看清业务本质、评估系统风险、识别功能边界、对齐各方预期。
四问权衡法
接到需求后，别急着建分支。先问自己四个问题。
问一：业务要什么？
不是问"功能是什么"，是问"这个功能解决什么业务问题"。
送礼连击解决的是：拉升礼物营收与主播互动氛围。
核心指标是：人均打赏频次。
明确了这一点，就能区分核心功能和附加功能：
| 分类 | 内容 | 理由 |
|---|---|---|
| 核心功能 | 送礼、扣款、结算 | 错了就是资损，没有退路 |
| 可砍功能 | 实时全厅用户同步 | 观众无强感知，可以延迟 |
| 可降级 | 完整连击数动画 | 中间丢了也能看，最终一致即可 |
| 可延期 | 连击排行榜 | 若时间来不及可放到下个版本 |
知道哪些必须保，哪些该舍弃。
问二：技术怎么做？
功能怎么拆分、异常怎么处理、边界有哪些、瓶颈是什么、有没有技术债要还...
这些都要想清楚。
以连击送礼为例：
功能拆分：
- 核心交易
- 连击计数
- 消息推送
- 排行榜结算
异常处理：
- 核心交易需确保开启事务，扣款、抽成、结算任何一步失败直接回滚并返回错误。
- 连击计数失败/Redis异常需重试，重试超限可直接丢弃（接口需返回成功，因为核心送礼功能已完成，但需记录异常）或触发最终一致保障：连击结束后通过查询送礼记录统计总连击数并推送补偿消息。
- 消息推送失败 处理逻辑同计数失败，丢弃并记录异常或触发最终一致保障。
- 排行榜结算失败可增加定时任务离线聚合。
边界情况：
- 连击窗口3秒，客户端与服务端因网络延迟造成的时间窗口不一致，可通过客户端携带连击标识+服务端延长连击窗口来解决。
- 使用Redis INCR替代GET+SET确保高并发下计数不丢失。
系统瓶颈：
- 大量用户同时在线，多用户并发送礼连击，实时结算导致DB写入QPS过高，全量推送导致网关扛不住、队列消息积压。
- 解决方案：客户端本地聚合批量上报+服务端异步队列扣款结算+结算失败通知客户端回滚计数动画。
- 降级预案：连击消息聚合推送+适当丢弃中间消息保最终一致。
技术债治理：
- 普通送礼逻辑之前留下的一些技术债，这次得还。
- 加入连击会增加送礼函数复杂度，可能要重构。
- 后面预计还要加暴击功能，把可复用逻辑抽象出来方便扩展。
- 这次为了赶进度写下的一些临时方案，得标记出来后续重做。
问三：团队接得住吗？
清楚团队的能力边界与当前系统架构的性能边界在哪。
这个方案需要引入Kafka消息队列？引入分布式事务？
团队有相关运维能力吗？出了故障有人能及时排查处理吗？如果没有，技术方案就得保守。
这个功能消耗太大，大流量冲击下现有系统架构可能扛不住。
有没有应急预案？流量来了能不能快速扩容？如果不能，该砍的功能就得砍，该牺牲的体验就得牺牲。
问四：时间允许吗？
问清楚两个问题：什么时候要上线，以及这次必须交付什么。
如果在硬性deadline之前不能交付完整功能，需优先确保核心功能交付。
定MVP边界与降级预案
不是闭门想当然，要跟产品经理、技术负责人、测试分别聊。
问产品经理：
- 连击动画延迟1~2秒，可以接受吗？
- 流量高峰观众看到的连击计数中间会丢失一些，体验上能容忍吗？
- 跨房连击排行榜是这次必须的吗？能放下一版吗？
问技术负责人：
- 当前Redis能扛多大并发？Kafka有没有现成的队列？
- 幂等框架有现成的吗？还是需要新写？
问测试：
- 高并发送礼的边界测试能覆盖吗？
- 断网重连、网络抖动的用例能排进来吗？
四个问题问完，脑子里会形成一个清晰的MVP边界和降级预案。不是自己想当然，是有依据的。
AI能帮你做什么
AI在这套方法里是一个盲区扫描仪——帮你发现你自己没想到的边界。
固定句式：
【角色】资深后端架构师
【需求】直播间送礼连击功能（V1 MVP）
【当前方案】
- 客户端本地计数 + 聚合批量上报
- 服务端Redis INCR + EXPIRE(3s)维护连击状态
- Kafka异步处理扣款与结算
- 连击UI允许1~2秒延迟
【约束】周末大主播专场，QPS预估5000，资金结算零容忍差异
【任务】
1. 列出这个方案可能漏掉的3个业务/技术边界
2. 针对每个边界，给出低成本验证或兜底策略
3. 不要生成代码，只给决策建议
以这个场景为例，AI会逼你直面这些盲区：
盲区1：网络延迟导致连击中断
AI：客户端与服务端存在网络延迟，可能导致时间窗口内的连击中断。用户以为是自己的问题，实际上是网络延迟。
低成本兜底：首次连击生成combo_session_id下发给客户端，并做为连击计数key，Redis key过期时间设置大于3s；客户端后续连击携带combo_session_id。
盲区2：扣款失败但特效已展示
AI：异步扣款失败（余额不足/风控拦截），但客户端连击计数动画已增加，用户体验割裂——看着加了但没扣钱。
低成本兜底：扣款失败时，服务端主动下发combo_reset指令，前端接收后回滚计数动画并提示"余额不足/网络异常"。
盲区3：排行榜拖垮主链路
AI：主播端连击排行榜若强依赖实时数据，每次连击更新都要写DB+推送，在万人在线的房间里，这个链路会拖垮主服务。
低成本兜底：V1排行榜走T+1离线聚合；V2再接入实时流计算，但要先做性能评估。
核心要点
1. 需求不是翻译题，是权衡题。
拿到需求先问"保护什么，放弃什么"，不是"怎么实现"。送礼连击引发DB雪崩和结算对不上账，根因都是跳过了这个分层。
2. 四问法是框架，不是流程。
四个问题不一定要按顺序问，可以并行问产品、技术、测试。重点是：业务目标、技术约束、团队能力、时间窗口，这四个维度都要有明确的答案才能动手。
3. MVP边界和降级预案是同时输出的。
不是"先做全量，有问题再降级"，是"做之前就想清楚这次交付什么、哪些场景降级、降级成什么"。提前想好降级，上线后遇到问题才不会手忙脚乱。
4. AI是盲区扫描仪，不是需求分析师。
AI能发现技术方案的边界问题，但不能理解业务目标。"核心指标是什么"、"失败长什么样"——这些问题AI回答不了。
📖 下篇预告：《技术选型：没有银弹，只有取舍》
我们会聊：如何摆脱"拍脑袋选型"和"追新踩坑"。给你一套可量化的选型评估矩阵。
