🎯 学什么：不是"这个代码对不对"，而是"这个设计在技术上成立吗"。从系统边界、数据架构、技术选择、失败模式、可扩展性五个维度审查架构，在实现前捕获结构性缺陷。核心洞察：(1) "今天不需要的抽象今天不建"可能是架构评审里最重要的原则——很多系统不是被需求压垮的，是被过度抽象拖垮的；(2) 跨模型审查的妙处在于"盲点互补"——一个模型认为明显的，另一个可能质疑；(3) 失败设计要求每个组件回答三个问题——怎么失败、怎么恢复、用户什么体验。 💡 难易度：⭐⭐⭐⭐ | ⏱️ 预计时间：45 分钟
[!quote]- 📖 原Skill精要 技能名称：plan-eng-review 核心功能：工程经理模式计划评审。锁定执行计划——架构、数据流、图表、边缘案例、测试覆盖、性能。以有主见的建议交互式遍历问题，在实现前捕获架构问题。 所属体系：gstack 虚拟工程团队 协作关系：受益于 [[L6-01-创业门诊室|office-hours]] 的前置诊断
1. 课程概览
💡 白话小课堂：工程架构评审就像盖楼前的"结构审核"——不管你装修得多漂亮，地基和承重墙必须对。工程评审关注架构层面的正确性，不关注代码风格（留给 code review）和视觉设计（留给 design review）。
2. 工程评审的范围
Engineering Review Scope
plan-eng-review 关注架构层面的正确性：
✅ 系统边界是否清晰？ ✅ 数据流是否合理？ ✅ 技术选择是否适合？ ✅ 可扩展性是否考虑？ ✅ 失败模式是否被处理？
不关注： ❌ 代码风格（留给 /review） ❌ 视觉设计（留给 /plan-design-review） ❌ 战略价值（留给 /plan-ceo-review）
3. 评审框架
Review Framework
系统边界
→ 模块之间的接口是否清晰定义？ → 依赖方向是否正确？（高层→低层，不能循环） → API 契约是否显式声明？
数据架构
→ 数据从哪里来、到哪里去、在哪里存？ → 数据一致性如何保证？ → 哪些数据需要事务、哪些可以最终一致？
技术选择
→ 选择的技术是否适合问题的规模和约束？ → 是否引入了不必要的复杂度？ → 团队是否有能力维护这个技术栈？
失败模式
→ 如果这个服务挂了，影响什么？ → 降级策略是什么？ → 有没有单点故障？
可扩展性
→ 数据量增长 10 倍，设计还成立吗？ → 并发增加 10 倍，瓶颈在哪里？
4. 工程原则
Engineering Principles
简单优先
能用一个服务解决的不用两个 能用一个表解决的不用两个 今天不需要的抽象今天不建
显式优于隐式
API 契约 → 写出来 错误路径 → 标注出来 假设 → 文档化
失败设计
每个系统组件都要回答： → 它可能怎样失败？ → 失败后如何恢复？ → 失败时用户体验是什么？
可观测性内建
不是后来"加上"监控 日志、指标、追踪从设计阶段就考虑
⚠️ 避坑指南："今天不需要的抽象今天不建"可能是架构评审里最重要的原则。很多系统不是被需求压垮的，是被"为了未来的扩展性"造的过度抽象拖垮的。
5. 跨模型审查
Cross-Model Review
plan-eng-review 支持可选的跨模型审查：
→ 使用 Codex（OpenAI）或 Claude 子代理 → 独立 AI 审查同一份计划 → 对比不同 AI 的审查意见
跨模型审查的价值： → 不同模型有不同的"盲点" → 一个模型认为明显的，另一个可能质疑 → 交叉验证降低确认偏误
但注意： → 跨模型同意只是推荐，不是决定 → 最终决定权在人类
🔑 核心秘诀：跨模型审查的妙处在于"盲点互补"。
6. 产出物
Deliverables
工程评审产出： → 架构评审报告：发现的优势和问题 → 技术决策记录：关键技术选择及理由 → 风险矩阵：可能性 × 影响 → 建议优先级：哪些问题必须在开发前解决
评审结果分为： APPROVED → 架构合理，可以开始实现 APPROVED_WITH_CONCERNS → 有已知风险，需要跟踪 NEEDS_REVISION → 有结构性缺陷，需要重新设计
7. 结构拆解：工程架构评审 Skill 模板
工程架构评审型 Skill 模板
核心特征
→ 管理对象 = 系统架构方案的技术正确性 → 核心原则 = 简单优先 + 显式优于隐式 + 失败设计 → 关键设计 = 五维度评审 + 跨模型可选审查 + 三级评审结果
通用结构
Five Review Dimensions（五个评审维度）
- System Boundaries：接口清晰、依赖方向、API 契约
- Data Architecture：数据流、一致性、事务 vs 最终一致
- Tech Choices：规模适配、不必要复杂度、可维护性
- Failure Modes：服务挂了影响什么、降级策略、单点故障
- Scalability：数据 10×、并发 10× 的瓶颈
Engineering Principles（工程原则）
- 简单优先：能一个服务/表解决的不用两个
- 显式优于隐式：API/错误/假设写出来
- 失败设计：每个组件回答"怎么失败/怎么恢复/用户什么体验"
- 可观测性内建：日志/指标/追踪从设计开始
Cross-Model Review（跨模型审查）
- 不同模型盲点互补，交叉验证降低确认偏误
- 最终决定权在人类
Deliverables & Results（产出与评级）
- 架构报告 / 技术决策记录 / 风险矩阵 / 优先级
- APPROVED / APPROVED_WITH_CONCERNS / NEEDS_REVISION
8. 电商案例：工程评审——秒杀系统架构
🛒 实战案例：一家中型电商平台（日均订单5万单）计划上线"限时秒杀"频道，目标在双11当天支撑10万QPS的瞬时并发。工程团队提出了"Redis Cluster做库存扣减 + Kafka异步同步到MySQL + Nginx+Lua网关层限流"的三层架构方案。
plan-eng-review从四个维度穿透评审：
- 系统边界审查：发现库存服务直接调用了订单服务的内部RPC
/order/internal/create——这构成了循环依赖。当订单服务发布时，库存服务的单元测试会假绿（mock了接口，但实际协议已变）。修复方案：库存服务扣减成功后通过Kafka Topicinventory.deducted发布事件，订单服务消费事件创建订单，方向变为库存→订单单向依赖。- 数据一致性审查：方案用Redis DECR做原子扣减，策略是"先扣Redis再异步发Kafka消息持久化到MySQL"。问题：如果Redis DECR成功后进程crash，Kafka消息未发出，库存数据永久丢失（Redis中扣了100件，MySQL中仍是200件）。修复方案：DECR成功后立即写本地WAL日志，进程重启后回放WAL补发Kafka。另外发现"15分钟超时释放"与"用户刚好在14:59支付"的竞态——修复方案：释放定时任务加一道支付状态查询，已支付则跳过释放。
- 失败模式分析：三个关键依赖——Redis Cluster宕机→秒杀全部不可用但普通下单正常（有降级路径）；Kafka宕机→Redis扣减仍可执行但数据无法同步MySQL（降级策略：Redis中库存数据标为draft状态等Kafka恢复）；秒杀服务单实例宕机→全局不可用。修复：秒杀服务从1实例扩为K8s Deployment 3副本+HPA自动扩缩，QPS达8万时自动扩容到5个Pod。
- 技术选择验证：Redis DECR原子操作确实适合秒杀场景（单机10万+QPS），团队有运维经验。但方案中引入了一个"分布式排号令牌管理器"——设计者想用令牌机制做秒杀排队，这实则是过度设计，因为Redis DECR本身已天然串行化扣减操作。删除令牌管理器后，架构从7个模块精简到5个，代码量预估减少1200行。
评审结果：APPROVED_WITH_CONCERNS。P0修复项——秒杀服务多实例（防单点）、WAL+重放机制（防库存丢失）、解除循环依赖（拆耦合）。P1修复项——删除令牌管理器（简化架构）。最终压测结果：10万QPS下P99延迟从初始方案的380ms降到修复后的62ms，超卖率0%，库存数据一致性从99.2%提升到99.98%。
🔑 启示：架构评审不是裁判打分——是帮团队看到"方案可行但隐含着四个生产级隐患"。工程师最擅长功能实现，但最容易忽略的是模块间的依赖方向和失败模式。
9. 掌握检验
Q1：工程评审中，如果发现两个模块之间存在循环依赖，这违反了哪个评审维度的原则？
- A) 数据架构
- B) 失败模式
- C) 系统边界
- D) 可扩展性
Q2：在"失败设计"原则中，每个系统组件必须回答三个问题。以下哪个不是这三个问题之一？
- A) 它可能怎样失败？
- B) 失败后如何恢复？
- C) 谁为这次失败负责？
- D) 失败时用户体验是什么？
Q3：工程评审中的三种结果（APPROVED / APPROVED_WITH_CONCERNS / NEEDS_REVISION）分别对应什么场景？请用秒杀架构案例中的具体问题来说明。
Q4：在秒杀架构案例中，为什么 Redis DECR 原子操作本身已经解决了并发排队问题？请解释为什么在此之上再加"分布式锁管理器"是过度设计。
Q5：如果数据量增长 10 倍，但你的设计中有一个定时任务"每分钟扫全表"，这个设计为什么会在工程评审中被判定为有问题？它属于哪个评审维度？
Q6："今天不需要的抽象今天不建"——请举一个你实际项目中的例子（或假设一个），描述一个"为了未来的扩展性"造的过度抽象，并说明它带来了什么具体代价。
10. 答案
点击查看答案
Q1：C —— 系统边界审查的核心要求是：模块间接口清晰、依赖方向正确（高层→低层）、无循环依赖。
Q2：C —— 失败设计的三个问题是"怎么失败 / 怎么恢复 / 用户什么体验"，不追究"谁负责"。
Q3：APPROVED = 架构合理可立即实现；APPROVED_WITH_CONCERNS = 有已知风险但可跟踪（如秒杀服务单点——已计划多实例但尚未实施）；NEEDS_REVISION = 有结构性缺陷必须重新设计（如循环依赖）。秒杀案例被评为 APPROVED_WITH_CONCERNS，因为已知风险（Redis 崩溃恢复、单点故障）有缓解方案但需要开发中跟踪。
Q4：Redis DECR 是单线程原子操作——每个并发请求按到达顺序依次执行，天然串行化，不需要额外排队。分布式锁管理器会在 Redis 之外再创建一个排队机制——两次排队解决一个排队问题，增加了系统复杂度、故障点和延迟，却没有任何额外收益。这就是过度设计："给一个不需要排队的问题加排队"。
Q5：数据量增长 10 倍后，"每分钟扫全表"意味着扫描量也增长 10 倍——可能从 1 万行/分钟变成 10 万行/分钟，定时任务可能在 1 分钟内无法扫描完毕，堆积导致雪崩。这属于"可扩展性"维度。修复方案：不用全表扫描，改用 Redis Sorted Set 做延迟队列——只扫描需要处理的行。
Q6：示例参考——一个简单的用户登录项目构建了"可扩展的权限引擎"，支持 RBAC + ABAC + 自定义策略，但实际上只有 3 种用户角色且半年内不变。代价：3 周开发时间、800 行代码维护负担、新同事需要 2 天才能看懂权限调用链。
（5/6 通过）
11. 延伸阅读
- [[L6-04-自动全流程计划|下一课：自动全流程计划 —— 从想法到完整开发计划一键生成]]
评论区
共 0 条评论