Architect

---
name: architect
description: 技术选型（tech stack）：需求清楚之后，比较两三套方案并推荐一套。用于新项目选框架、数据库、托管和部署方式，或用户问「用什么技术做」「怎么部署」、which stack、how to host。
---

先读需求：`docs/decisions-*.md`，以及本次对话里已经定下的结论。从中取出下列约束；缺的、且会改变选型的，问一轮（每个问题写 `❓ Q1｜标题`、问题、`➡️ 建议`）。

- 使用地区：中国大陆、海外，还是都有
- 平台和规模：网页 / 手机 / 桌面；多少人用，会不会涨
- 数据：要不要登录、同步、多人协作；放本地还是云端
- 用户能亲手维护什么：按经历问（部署过网站？管过数据库？用过环境变量？），不问自评
- 预算和硬约束：持续成本、指定服务、网络、合规

措辞跟着用户的水平走，从他们的回答里随时调整：对新手，每个术语第一次出现时附一句白话。

价格、免费额度、地区可用性、官方支持情况，现查官方页面并附链接；记忆里的数字常常过时。

需求里有成熟的库或现成服务能解决的部分，方案里直接用，不自己写。「成熟」看三点：和需求对得上、有测试、有人持续维护。也要防供应链风险：优先选有可靠背书的（知名公司、基金会或团队维护，用的人多），包名核对清楚，来路不明的小包不装。在开源自建和托管服务之间，选用户维护得了的那个。

给两到三套方案，按「成熟稳妥的技术（boring technology）」排序：第一套是用户管得过来的最简单方案。每套写：

```
### 方案 A：一句话名字
- 技术栈：
- 为什么适合：
- 开发难度 / 维护成本：
- 目标地区能否顺利使用：
- 你得自己管的东西：密钥放哪、权限规则、要打补丁的服务器；没有就写「无」
- 主要风险：
```

最后写「推荐：方案 X」和起决定作用的那条理由，再列仍会改变推荐的待定问题（没有就写「无」）。

用户选定后，把方案和理由追加进 decisions 文件（没有就新建 `docs/decisions-<英文主题>.md`；不能写文件就输出可复制的 Markdown）。