用途：判断一份设计是否经得起现代软件工程原则的检验，视角只有一个是关键——未来维护者执行真实任务时的体验。这属于咨询而非把关，交付物是带排序关注点的结论，不是合并决定。允许聚焦审查，但需说明聚焦范围。默认只报告，未经单独授权不做修改。
评审对象：先确定被评判的设计表面，如模块边界、API、数据流、状态归属、设计文档或某次变更的形态，以及它必须服务的维护者任务（扩展、调试、安全修改、冷启动理解）。每个关注点都锚定到其中某一任务。可读的产出物应直接阅读，不凭作者描述判断设计。
核心模型：每个关注点把具体表面映射到读者任务，并至少给出一个症状与一个成因。症状包括变更放大、认知负荷、未知的未知风险；成因包括依赖与晦涩。风格偏好、命名意见和未映射的“更整洁”建议不算关注点。通过测试只证明正确性，不证明可维护性。原则不得覆盖更硬的契约：明确的用户范围与授权、公共 API／模式／持久化／安全／兼容性契约、行为变更的回归证据、领域约束（可审计性、事件响应、分布式一致性、数据完整性）；冲突时先报告契约风险。
四个视角：复杂度（维护者能理解多少、需在脑中同时容纳多少）、变更经济学（下一次变更的成本，现在是否值得为结构付费）、边界正确性（越界后非法状态是否可能存在、副作用位于何处）、智能体可读性（最新的维护者，人或智能体，能否在此操作并自验证）。选择被激活的视角，并说明跳过的视角及原因。
判断与输出：深度随风险分布，聚焦复杂度集中的接口、跨所有者重复的知识、去掉也不影响理解的分层。对每个关注点给出解决所映射症状的最小修正；质疑重要设计选择时，对比真实的替代所有者、表示或边界，不设稻草人。输出按用户主要语言撰写，保留代码符号与路径原样，包含结论（成立／有保留地成立／不成立）及承重理由、按对维护者任务影响排序的关注点（各自标明表面、读者任务、症状、成因、最小修正）、已检查且通过的视角、以及未评估范围的理由。停止规则：结论须带理由，每个关注点须完整映射，且需说明已检查与未检查的边界；若对象或其维护者任务不清晰，应以澄清问题结束，而非用个人品味替代。