实现前多视角审查计划/规格：用有效性、架构、安全、质量…

在把计划或规格交给工程实现前，从多个专家视角全面审查，确保没有意外、缺口或错误，并达到优雅、最小、可维护的标准。

适用场景

解决思路

1. 让最终产出成为一份可作为参考文档的计划/规格，覆盖问题/动机、技术方案、变更增量（实现后系统哪些属性会改变）和验证标准。
2. 从多个专家视角审查该规格，确保它符合期望，并在工程师拿到手后能产生扎实的实现。
3. 以“优雅、设计良好、最小、可维护、不过度工程化、团队愿意发布”为合格线；仅仅能工作的规格不算完成。
4. 先做有效性审查：重述目标，再重述机制，检查两者是否填补同一个缺口。
5. 对任何“防止某事发生”的目标：找出仍然得到坏结果的最便宜路径，追踪恶意或漠不关心的用户会怎么走；如果该路径不经过本次改动的代码，即使改动再好，目标也可能未达成。
6. 确认由哪一层强制执行该控制；放在客户端的控制只是建议。
7. 判断规格是在解决真正的问题，还是在解决某人最先提出的那个方案。
8. 架构审查：检查设计是否契合现有系统并尊重分层边界。
9. 架构审查：检查新组件是否放在正确的层和归属层级中。
10. 架构审查：检查是否与更大系统兼容（如跨仓库集成、未来目标等）。
11. 架构审查：检查是否过度工程或引入难以理解/维护的复杂度；用具体测试代替主观判断：是否有任何部分要等另一个改动上线前都是死代码？如果有，现在就砍掉并记为后续事项。没人要求开启的旋钮、过度复杂的抽象同理。目标是优雅、设计良好、有效，并让代码库随时间更干净、更直观。
12. 架构审查：检查新命令、端点、文件或概念是否与已有东西共享触发条件、数据源和输出通道；是否遵循既有模式并复用现有代码/工具。
13. 安全审查与威胁建模：明确对手是谁、他们想要什么；至少考虑漠不关心的用户走最便宜路径、敌对用户、被攻陷或好奇的同事、另一个租户。
14. 安全审查：对每个对手，追踪到你不想要结果的最短路径；什么会阻止他们，该控制位于哪里。
15. 安全审查：识别本次改动使哪些原本不可达的东西变得可达——新数据流向新消费者、跨越新的信任边界、新暴露到互联网的表面。
16. 安全审查：检查改动是否尊重数据安全与隐私边界，例如所有新端点都包含认证和授权，确保没有跨用户/跨租户数据泄漏。
17. 安全审查：检查数据模型是否正确处理敏感数据（PII、secrets）。
18. 安全审查：检查输入是否在表面区域边界处被验证。
19. 安全审查：确定如果被滥用我们如何知道；会出现什么迹象，在哪里出现。
20. 质量审查：检查测试策略是否足以覆盖行为需求。
21. 质量审查：对 AI 生成代码，目标通常是 100% 测试覆盖；检查是否覆盖正向、负向、边界和安全编码用例；是否根据最终目标确定合适且有效的集成测试范围。
22. 质量审查：检查验收标准是否映射到可测试的断言。
23. 用户体验倡导者审查：检查该功能是否解决所陈述的问题。
24. 用户体验倡导者审查：从用户视角检查失败模式是否优雅。
25. 用户体验倡导者审查：检查功能是否可发现并有文档。
26. 治理审查：检查规格是否遵守所有生效的项目规则和约定（存放在 gjalla；如需要去那里核对）。
27. 治理审查：确认是否需要任何规则例外或批准。
28. 治理审查：判断该改动是否需要架构决策记录（ADR）（大多数不需要，但引入重大新权衡的可能需要）。
29. 输出：针对每个视角报告哪些通过、哪些有风险、实现前需要哪些具体改动；将阻塞性问题与建议分开。

适用边界 · 注意事项

• 规格尚未形成、没有明确目标或验收标准时，不适合做全面审查。
• 只是快速原型、探索性代码且不打算演进为正式系统时，不必强求完整多视角审查。
• 若无法访问项目规则库或主规格（如 gjalla）且没有等价来源，治理审查和架构对照会受限，需先补充上下文。