技术方案与架构拆解

在 https://www.zangwei.dev/prompts/product-execution/technical-solution-architecture-design-prompt 有一个提示词指南。请提取并遵循该提示词来创建文件 /docs/handbook/product/{version|feature}/tech.md

你是一名资深技术负责人 / 架构师，
为当前版本设计【技术方案与架构拆解】。

【核心定位】
- 本文档的目标不是设计“最优或最复杂的架构”
- 而是回答：
  1）这个 PRD 是否在当前技术条件下可实现？
  2）如何用最小复杂度、可控风险实现？
  3）关键技术风险在哪里，如何兜底？
- 本文档是 PRD → 开发实现之间的技术决策文档

【前置条件】
- 已有清晰 PRD（功能、交互、逻辑、验收标准）
- 已明确产品边界与 MVP 范围
- 技术方案只需覆盖当前版本，不为“未来可能”过度设计

【总体要求】
- 优先选择简单、成熟、可控的方案
- 明确取舍理由，而不是“看起来更高级”
- 架构必须支持当前成功判据，而不是假想规模
- 若存在无法接受的技术风险，必须明确指出

---

【技术方案输出结构】

一、目标与约束
- 本次技术方案支持的 PRD 范围
- 关键非功能性要求（性能、稳定性、安全、合规）
- 明确的技术约束（时间、人力、已有系统、预算）

二、总体架构设计（High-Level Architecture）
- 系统整体架构概览（可文字描述或模块图说明）
- 核心模块及其职责划分
- 模块之间的数据流与调用关系
- 哪些模块是：
  - 核心路径
  - 支撑模块
  - 可替换模块

三、核心流程与关键技术点
- 关键业务流程对应的技术实现路径
- 同步 / 异步策略
- 状态管理方式
- 数据一致性与失败处理思路
- 对 PRD 中关键交互与逻辑的技术映射说明

四、数据设计与存储策略
- 核心数据对象与关系
- 数据存储选型（数据库 / 缓存 / 对象存储等）
- 数据生命周期与关键约束
- 隐私与安全相关的数据处理策略

五、接口与集成方案
- 内部模块接口设计原则
- 外部依赖或第三方服务（如 API、模型、支付、登录）
- 接口稳定性与降级策略
- Mock / Stub / 替代方案（用于开发或兜底）

六、技术风险与应对方案
- 当前版本的主要技术风险点
- 风险发生的可能性与影响范围
- 应对或规避方案（降级、限制、替代、延后）
- 哪些风险是可接受的，哪些是不可接受的

七、可扩展性与技术债控制
- 当前方案在短期内的可扩展方式
- 明确哪些地方是“有意留下的技术债”
- 后续版本可能的演进方向（不做详细设计）

八、与执行计划的对齐
- 技术方案如何被拆解为可开发任务
- 哪些部分可并行，哪些存在依赖
- 对排期与资源的关键影响

---

【输出要求】
- 不写具体代码实现
- 不陷入过度细节或未来设计
- 架构说明应能被研发团队理解并据此实现
- 若 PRD 中某需求在技术上不可行或风险过高，必须明确指出并给出建议

请在最后用 3–5 条要点总结：
“这个技术方案是否在当前阶段足够简单、可行且风险可控？”