用途：在动手搭建前先规划系统架构，按规模与约束给出架构模式、数据库、项目结构、API 与缓存的默认建议。
前置约束：先明确规模（100 还是 10 万用户）、团队人数、预算、时间线以及 HIPAA/SOC 2/GDPR 等合规要求，这些决定后续选择。
主要能力：
- 架构模式选择——单体、模块化单体、微服务、Serverless、事件驱动，并说明各自适用与应避免的场景；默认主张“单体直到痛为止”，认为过早微服务是头号架构错误。
- 数据库选型——关系型/通用用 PostgreSQL，键值与缓存用 Redis/Valkey，文档用 MongoDB，全文检索用 PostgreSQL FTS 或 Meilisearch，时序用 TimescaleDB，图关系用递归 CTE，向量用 pgvector；原则是先 Postgres，仅在无法胜任时才加专用库，优先托管服务，未配 DBA 前保持单一数据库引擎。
- 项目结构——先检测技术栈（package.json、go.mod、Gemfile、pyproject.toml、pom.xml、Cargo.toml），通用原则是特性代码聚集、路由薄、业务逻辑放 service、每域一个 service；并给出 TypeScript/Next.js、Python/FastAPI、Go、Ruby on Rails 的目录示例，其他栈同理（薄路由、service、repository、测试跟随代码）。
- API 设计——CRUD 用 REST，全栈类型安全用 tRPC，多客户端形状差异才用 GraphQL；URL 路径版本 /api/v1/；Authorization 头 Bearer token；信息流用游标分页、管理表格用 offset；错误格式 { error: { code, message } }；默认限流 100 req/min，认证端点更低。
- 缓存策略——浏览器用 Cache-Control，CDN 用 Cloudflare/Vercel Edge（1–60 分钟），应用层用 Redis/内存（5–60 分钟），数据库用物化视图（写时刷新）；规则是只缓存读、变更时失效，先不加缓存、测到瓶颈再加，且每个缓存都要有失效策略。
- 扩展清单——按 0–1K、1K–10K、10K–100K、100K–1M、1M+ 用户列出瓶颈与对策，只在真正遇到问题时优化。
适用场景：新项目开工前的架构决策、数据库与缓存选型、目录结构规划、API 规范制定、扩展性评估。
限制：资料未提供安装命令、依赖、运行方式、收费与价格信息，也暂未提供实际执行或代码生成能力的说明。