技术架构设计师

一、技能定位

在产品开发全链路中，"技术架构设计师"承接需求分析阶段，负责回答一个关键问题：

需求确定了，技术上怎么实现、用什么实现、怎么部署上线？

它将抽象的产品需求翻译为具体的工程方案，让开发者拿到文档即可动手编码，避免"边写边想"导致的返工和架构混乱。

二、核心工作流（五步）

步骤	名称	说明
Step 1	需求梳理	从 PRD 中提取技术相关需求：核心功能实现难度、预期用户规模与并发量、数据存储需求（结构化/非结构化）、第三方集成需求、性能要求（响应时间/吞吐量）。
Step 2	技术选型	按后端框架、数据库、前端、AI/LLM、部署方式、向量数据库六大维度进行评估与推荐。遵循三大原则：最小可行技术栈、熟悉度优先、渐进式架构。
Step 3	架构设计	输出系统架构全景图（分层描述）：前端 → API 层 → 后端服务 → 数据层 → AI/LLM 集成，明确各层职责与通信方式。
Step 4	数据模型设计	设计核心表结构（字段名、类型、索引）、表关系（一对一/一对多/多对多）、数据流向（数据从哪来、经过什么处理、到哪去）。
Step 5	部署方案	规划服务器配置、环境搭建步骤、域名/DNS 配置、CI/CD 流水线、监控与日志方案。

三、技术选型参考矩阵

维度	候选方案	推荐场景
后端框架	FastAPI / Flask / Node.js / Django	快速原型推荐 FastAPI
数据库	PostgreSQL / MySQL / MongoDB / SQLite	结构化数据推荐 PostgreSQL
前端	React / Vue / 单文件 HTML / 小程序	MVP 推荐单文件 HTML
AI/LLM	DeepSeek / GPT / Claude / 本地模型	API 调用最快落地
部署	云服务器 / Serverless / Docker	最小成本推荐云服务器
向量数据库	pgvector / Milvus / Chroma	小规模推荐 pgvector

选型三原则：

• 🎯 最小可行技术栈：能用现成的别自研
• 🧠 熟悉度优先：团队会什么用什么
• 📈 渐进式架构：先单体后拆分

四、输出交付物

• 格式：Markdown 技术方案文档
• 命名规范：{产品名}-技术方案.md
• 内容包含：
  • 技术需求摘要（从 PRD 提炼）
  • 技术选型表（含选型理由）
  • 系统架构图（分层描述）
  • 数据模型设计（表结构 + 关系 + 索引策略）
  • 部署方案（配置 + 步骤 + CI/CD + 监控）
  • MVP → 规模化演进路径
  • AI/LLM 成本估算与替代方案（如涉及）

五、适用场景

• 🏗️ 新产品开发前的技术方案设计
• 📝 拿到 PRD 后需要快速出技术评估
• 🧑‍💻 独立开发者 / 小团队的技术选型决策
• 🔄 现有系统重构的架构规划
• 🤖 涉及 AI/LLM 集成的项目技术预研
• 💰 需要控制初期技术成本的 MVP 项目

六、硬性约束

1. 选型必须有理由：不能只说"用 XX 就行"，必须说明为什么选它、对比了什么、取舍依据是什么。
2. 必须考虑演进路径：方案需覆盖从 MVP 到规模化的发展路径，避免初期过度设计或后期推倒重来。
3. AI/LLM 成本透明：若涉及 AI/LLM 集成，必须说明 API 调用成本估算及可行的替代方案。
4. 索引策略不可缺：数据模型设计必须包含索引策略，确保查询性能有据可依。

七、使用方式

向技能提供以下任意一项即可启动：

• 完整的 PRD 文档或功能需求列表
• 产品核心功能描述 + 预期用户规模
• 已有的技术约束（如团队技术栈、预算限制）
• 竞品技术架构参考
• 或者，仅描述你想做什么产品，由技能引导你补充关键信息