我 (Claude Opus 4.6 ) 在 架构设计分析 方面的能力和边界。

---

🟢 我擅长的部分

1. 代码级架构理解

• 给我一个代码库，我可以快速梳理出 模块依赖关系、分层结构、数据流向。
• 能识别常见架构模式（MVC、事件驱动、插件系统、管道模式 等）并判断其使用是否合理。
• 擅长从零散的文件结构中还原出 “设计者的意图”。

2. 设计模式识别与建议

• 能识别代码中已有的设计模式，也能在合适的场景推荐模式（Strategy、Observer、Factory、Decorator 等）。
• 能分析 某个设计选择的 trade-off：为什么选 A 而不选 B，各自的代价是什么。

3. 重构与演进分析

• 能识别架构中的 “坏味道”（过度耦合、God Class、循环依赖 等）。
• 能提出 渐进式重构 路径，而不是推倒重来。
• 对 技术债务 的定位与优先级排序有较好的判断。

4. 系统级概念讨论

• 分布式系统的基本概念（CAP 定理、一致性模型、消息队列、微服务拆分）。
• API 设计（RESTful、GraphQL、gRPC 的选型分析）。
• 数据库选型（关系型 vs 文档型 vs 图数据库的场景适配）。

---

🟡 我能做但有局限的部分

5. 大规模系统设计（System Design）

• 我可以给出 结构合理的高层设计方案（比如设计一个 URL 短链服务、一个聊天系统），但我的方案更偏 “教科书式”—— 缺少在真实生产环境中踩过的坑和经验直觉。
• 涉及到 具体的容量规划、硬件选型、成本估算 时，我的数据可能不够精确。

6. 特定云平台的深度架构

• 我了解 AWS / GCP / Azure 的主要服务和常见架构模式，但不如专职云架构师深入。
• 对于特定服务的 最新定价、限制、隐藏陷阱，最好还是查官方文档。

🔴 我不擅长的部分

7. 组织与团队维度的架构决策

• 架构设计很大程度上受团队规模、技术栈偏好、业务节奏等 人为因素 影响（康威定律）。这些 “软信息” 我无法感知。

8. 性能调优的最后一公里

• 我可以指出 “这里可能有性能瓶颈”，但真正的 profiling、热点定位、JVM 调参等，需要在实际运行环境中做。

💡 我的最佳使用方式

场景	怎么用我
已有代码库，想理解架构	让我读代码，我帮你画出模块关系图
设计新系统，想讨论方案	给我需求，我给你 2-3 个候选架构 + trade-off 分析
重构决策	让我分析当前架构的问题，给出演进路径
面试准备 / System Design	给我题目，我帮你走一遍完整的设计流程
技术选型犹豫	告诉我约束条件，我帮你做决策矩阵

---

一句话总结：我更像一个 读过大量架构书、看过大量开源项目的高级工程师 ——在 “分析” 和 “讨论” 层面很强，但缺少 “在凌晨三点被 P0 事故叫醒后积累的直觉”。