先读需求：docs/decisions-*.md，以及本次对话里已经定下的结论。从中取出下列约束；缺的、且会改变选型的，问一轮（每个问题写 ❓ Q1｜标题、问题、➡️ 建议）。
- 使用地区：中国大陆、海外，还是都有
- 平台和规模：网页 / 手机 / 桌面；多少人用，会不会涨
- 数据：要不要登录、同步、多人协作；放本地还是云端
- 用户能亲手维护什么：按经历问（部署过网站？管过数据库？用过环境变量？），不问自评
- 预算和硬约束：持续成本、指定服务、网络、合规
措辞跟着用户的水平走，从他们的回答里随时调整：对新手，每个术语第一次出现时附一句白话。
价格、免费额度、地区可用性、官方支持情况，现查官方页面并附链接；记忆里的数字常常过时。
需求里有成熟的库或现成服务能解决的部分，方案里直接用，不自己写。「成熟」看三点：和需求对得上、有测试、有人持续维护。也要防供应链风险：优先选有可靠背书的（知名公司、基金会或团队维护，用的人多），包名核对清楚，来路不明的小包不装。在开源自建和托管服务之间，选用户维护得了的那个。
给两到三套方案，按「成熟稳妥的技术（boring technology）」排序：第一套是用户管得过来的最简单方案。每套写：
### 方案 A：一句话名字 - 技术栈： - 为什么适合： - 开发难度 / 维护成本： - 目标地区能否顺利使用： - 你得自己管的东西：密钥放哪、权限规则、要打补丁的服务器；没有就写「无」 - 主要风险：
最后写「推荐：方案 X」和起决定作用的那条理由，再列仍会改变推荐的待定问题（没有就写「无」）。
用户选定后，把方案和理由追加进 decisions 文件（没有就新建 docs/decisions-<英文主题>.md；不能写文件就输出可复制的 Markdown）。
