在多个方案都合理但优化目标不同、选择依赖上下文时…

当成本/延迟、简单/功能等合法优先级冲突且不同部署会做不同选择时，用配置、并行实现或文档化权衡保留选项。

适用场景

解决思路

1. 先按核心原则执行：保留能揭示上下文依赖的张力，仅在必要时强制解决。
2. 识别生产性张力：检查两种方案是否分别优化不同的合法优先级（如成本 vs 延迟、简单 vs 功能）。
3. 识别生产性张力：检查“更好”的选择是否取决于部署上下文，而不是技术上的绝对优越。
4. 识别生产性张力：检查不同用户或部署是否会做出不同选择。
5. 识别生产性张力：检查权衡是否真实存在，且不会因巧妙工程而消失。
6. 识别生产性张力：检查利益相关者是否有相互冲突但都合理的关切。
7. 判断张力是否需要解决：检查同时保留两者的实现成本是否过高。
8. 判断张力是否需要解决：检查两种方案是否根本冲突、无法共存。
9. 判断张力是否需要解决：检查当前特定用例是否存在明确技术优势。
10. 判断张力是否需要解决：检查是否是一扇单向门（选择会锁定架构）。
11. 判断张力是否需要解决：检查同时保留两者是否只增加复杂度而没有价值。
12. 若可采用配置模式：把选择做成配置而不是写死进架构，例如 Config.mode: Literal["optimize_cost", "optimize_latency"]。
13. 配置模式适用时：两种方案在架构上兼容，切换是运行时决策。
14. 若可采用并行实现模式：维护两个独立干净模块并共享契约，例如 processor/batch.py 优化成本、processor/stream.py 优化延迟，二者都实现 def process(data) -> Result。
15. 并行实现模式适用时：方案差异显著但共享同一接口。
16. 若无法在代码中同时保留两者，采用文档化权衡模式：在文档或决策记录中明确记录张力。
17. 文档化格式包含：张力名称、上下文、选项 A 的方案/优化目标/权衡/最佳适用场景、选项 B 的方案/优化目标/权衡/最佳适用场景、保留策略、解决触发条件。
18. 文档化权衡模式适用时：无法在代码中保留两者，但需要记录该选择是有意为之。
19. 监控强制解决的红色信号：当两者都合理时仍在问“哪个最好？”。
20. 红色信号：没有解释原因就说“我们必须选一个”。
21. 红色信号：依据自己的偏好而不是用户上下文做选择。
22. 红色信号：为了“取得进展”而解决张力，而保留张力本身就是进展。
23. 红色信号：在多样性有价值时强制达成共识。
24. 出现任一红色信号时：STOP，考虑保留张力。
25. 需要强制解决时执行：实现成本过高，即同时构建/维护两者会显著拖慢开发，团队没有带宽做并行方案。
26. 需要强制解决时执行：方案根本冲突，即做出互相矛盾的架构假设，无法清晰分离关注点。
27. 需要强制解决时执行：存在明确技术优势，即某方案在此特定上下文中客观更好，不是“我偏好 X”，而是“X 解决我们的约束，Y 不能”。
28. 需要强制解决时执行：属于单向门，即选择锁定架构，迁移成本昂贵。
29. 需要强制解决时执行：简单性要求选择，即同时保留确实增加复杂度；YAGNI：只需要一个就不要构建两个。
30. 在决定前明确询问：“Should I pick one, or preserve both as options?”。
31. 对“优化成本还是延迟？”这类生产性张力：做成可配置，因为不同部署需要不同权衡。
32. 对“SSE 还是 WebSockets？”这类技术决策：若只需要单向通信，选择 SSE，因为实现更简单。
33. 对“是否支持离线模式？”这类业务决策：不要保留两者，让利益相关者基于用户需求决定。
34. 记住并应用：有效优先级之间的张力是特性，不是缺陷。
35. 记住并应用：过早共识会破坏宝贵灵活性。
36. 记住并应用：在合理时，配置化优于强制选择。
37. 记住并应用：明确记录权衡。
38. 记住并应用：有正当理由时，解决也可以。

适用边界 · 注意事项

• 当同时保留两种方案成本过高，或团队没有带宽维护并行实现时，不应保留张力，应强制解决。
• 当两种方案根本冲突、存在明确技术优势、属于单向门，或保留只会增加无价值复杂度（YAGNI）时，不应保留张力。
• 当这是需要业务方基于用户需求拍板的业务决策，而不是需在代码或架构中保留的技术张力时，不应保留张力。