目标
代码评审擅长抓实现错误，抓方向错误却很贵：错误的依赖方向能完美运行，代价是一个季度来拆。轻量架构门——触发清单、一页纸设计注记、固定问题集——在方向还便宜时拦住它。门必须比绕行更轻，否则人们会把变更伪装成例行走捷径。
步骤要点
- 定义触发门槛：列出什么进架构门——新的跨服务依赖、跨团队共享 schema、新基础设施组件、修改已发布契约，确保普通 PR 不会误触。
- 要求一页纸设计注记：触发变更提交短注记，覆盖问题、所选形态、被否的备选与影响半径，评审者十分钟能读完。
- 用固定问题集评审：每次都问同样的问题——依赖方向是否符合地图、新数据归谁、十倍规模下如何演进、错了怎么回退。
- 决议绑定代码评审：批准的注记链接进后续 PR，代码评审者核验实现符合已评审形态而不是重新辩论。
- 审计门自身的重量：跟踪门的时延与翻案率，保持轻到人们愿意走门而不是绕门。
排错提示
方向错误在代码评审里被夸实现好是常态，跨团队契约类变更必须先过门；门要排三周队就会有人把变更拆小伪装成例行事，盯中位时延；PR 里重新吵架构议题是注记没绑定，批准文档要显式链接并被引用。
适用边界
门的判断质量依赖评审者的系统视野，小组要轮转防止认知固化；触发清单需随架构演进维护，新型耦合要能被补进清单。
代码示例
trigger list (what goes to the gate):
new dependency between services
schema shared across >1 team
new infrastructure component (db, queue, cache)
change to a published contract/API
design note (1 page):
problem / chosen shape / rejected alternatives
+ blast radius + reversal path
gate questions (fixed):
Q1 dependency direction fits the map?
Q2 who owns the new data, lifecycle?
Q3 how does this evolve at 10x?
Q4 what reverts if this is wrong?
PR #5210 header: "gate note #88 approved 10-21"
reviewer verifies shape, not re-argues it