技术方案研究 Skill：从问题建模到路线比较与决策
8月 11, 2026
AI 参与说明（Agent：Codex）：本文根据作者提出的技术选型调研需求，由 Codex 协助抽象、整理和撰写。内容是一套通用研究方法，不对应任何特定公司、产品、代码库或商业决策；其中的结论模板必须结合当时的官方资料、实际工作负载和验证结果使用。
先给结论#
技术方案研究不是收集功能清单，也不是问“产品 A 是否比产品 B 更好”。它的目标是：在明确的产品边界、约束与时间点下，选出最小、可验证、可维护且可退出的系统组合。
一份可靠的研究结论至少要把四类内容分开：
- 已证实的事实：官方文档、价格页、SLA、发布日志、代码或可复现实验能够支持的内容。
- 合理推断：根据事实得出的架构含义，必须说明推断链条和前提。
- 偏好与取舍：团队主动选择的复杂度、速度、成本或控制权，不能伪装成客观事实。
- 尚未确定的未来：路线图、预览功能和管理层愿景，只能作为方向信号，不能当成已交付能力。
下面是一套可复用的 Research Skill，尤其适合比较数据库、BaaS、实时系统、云平台、框架和基础设施服务。
flowchart TD
question["把模糊问题改写成决策问题"] --> boundary["确认产品边界、数据主权与硬约束"]
boundary --> model["画出候选方案的真实调用与授权拓扑"]
model --> evidence["按证据层级收集当前事实"]
evidence --> compare["比较语义、运维、成本、退出与路线"]
compare --> validate["用最小验证消除高风险假设"]
validate --> decision["给出条件化决策与复审触发条件"]1. 先把产品名问题改写成决策问题#
“要不要换成某个平台”通常不是好问题，因为它把结论预先限制在厂商名上。研究开始前，应把问题改写为可裁决的陈述：
在既定产品和运行环境中，哪种数据与实时架构能满足一致性、权限、交互和运维要求，同时不引入不必要的第二套主数据源？
然后写下四项输入：
| 输入 | 要回答的问题 |
|---|---|
| 业务对象 | 哪些数据是用户编辑的、关系型的、事件型的、临时的？ |
| 正确性要求 | 哪些操作必须原子、顺序化、幂等，或受严格权限控制？ |
| 运行边界 | 哪些逻辑必须在浏览器、边缘 Worker、长连接服务或数据库内执行？ |
| 不可变约束 | 已确定的认证、对象存储、公开 API、合规、地区、团队能力和产品边界是什么？ |
这一步能防止“功能更多”被误认为“更适合”。一个服务即使同时提供认证、存储、实时和函数，也不代表这些能力都应该替换系统中已有且职责清晰的部分。
2. 比较真实拓扑，而不是比较 SDK 名称#
同一个产品常常同时提供 HTTP API、数据库直连、浏览器 SDK、服务端 SDK、实时频道和函数运行时。它们不是一条路径。
研究时应为每个候选方案画出至少三条链路：
浏览器读写：Browser -> 身份令牌 -> 数据 API / SDK -> 数据库
服务端读写：Worker / Server -> 驱动 / 连接池 -> 数据库
实时连接：Browser -> 频道 / WebSocket -> 广播或权威协调器随后逐条回答：
- 这条链路的鉴权发生在哪里？令牌是否真的传到了数据层？
- 行级权限、服务端授权与数据库角色是否是同一套语义？
- 多步骤写入能否在一个短事务中完成？
- 订阅的是“事件”，还是“自动重算后的业务查询结果”？
- 断线、重连、重放、顺序和幂等由谁负责？
一个很常见的误判是：看到某个浏览器 SDK，就以为它也能通过服务端连接池；或者看到“Realtime”，就以为它等同于业务查询的自动响应式更新。只有把调用路径画出来，才能识别实际增加的是能力，还是第二套授权、缓存和状态同步。
3. 用数据语义划分 owner，而不是按技术栈划分目录#
选型的最小单位不是“整个项目”，而是一个数据域。每个业务对象必须有一个 canonical owner。
| 数据或交互形态 | 常见优先方案 | 关键原因 |
|---|---|---|
| owner-scoped、写后多端自动更新的产品数据 | 响应式应用数据层 | 订阅直接得到查询结果，减少前端同步逻辑 |
| 多表关联、复杂聚合、强约束、批量导出 | PostgreSQL + 服务端事务 | SQL、约束和事务模型更直接 |
| 在线、光标、typing、短暂通知 | 频道 Broadcast / Presence | 它们是临时信号，不应成为主数据 |
| 房间状态、顺序命令、租约、限流、断线恢复 | 权威协调器 | 需要一个服务端裁决下一状态 |
| 文件、媒体和大对象 | 专门对象存储 | 与关系数据和临时信号分开管理 |
最重要的规则是：同一个字段或业务对象不要同时由两套实时系统推送，也不要在两个数据库之间以“双写”维持主状态。
如果确实需要跨域投影，应明确：源是谁、投影是否可重建、延迟是否可接受、失败如何补偿。没有这四项定义，就不应把“同步”当作架构方案。
4. 建立证据阶梯，并标注时间#
技术服务的功能、价格、限制和路线变化很快。调研应优先使用一手资料，并记录检索日期。
建议的证据优先级如下：
- 官方产品文档、参考 API、SLA、价格页、状态页和安全说明。
- 官方 changelog、发布公告、GitHub release、公开 roadmap。
- 可运行的最小实验、公开源代码和复现结果。
- 厂商案例、技术博客、演讲和采访。
- 第三方媒体、社区经验和评测，仅用于发现线索或验证边缘体验。
每一项关键结论应附上三种标记：
事实：某能力当前已发布，官方文档说明适用范围。
推断：因此可以减少某一类浏览器接入代码，但不能替代服务端事务。
决策：当前产品不使用该能力，因为已有边界覆盖了同一职责。这样写的好处是，后续读者能快速判断：需要更新的是事实、推断，还是团队选择。
5. 调研“未来路线”时，比较方向而不是宣传页#
路线研究的目标不是预测谁会胜出，而是识别未来一两年可能改变架构成本的力量。可以按下面五层收集：
| 层次 | 研究问题 | 可信度 |
|---|---|---|
| 核心产品 | 厂商持续加码的成熟能力是什么？ | 高 |
| 明确承诺 | 有时间、范围或正式状态的公开计划是什么？ | 中高 |
| Alpha / Beta | 能否试用？是否允许成为生产依赖？ | 中低 |
| 战略方向 | 收购、融资、生态合作后，资源会流向哪里？ | 中低 |
| 营销愿景 | “将成为一站式平台”等表述是否有交付边界？ | 低 |
比较双方路线时，重点不是列出“都在做 AI、实时、分支、分析”，而是追问：
- 新能力是在补强已有核心，还是把公司推向新的平台边界？
- 它是成熟主线，还是需要客户试用的预览功能？
- 收购、云厂商绑定或新融资会增加工程资源，还是会改变产品优先级？
- 这条路线会降低当前系统复杂度，还是与已有认证、存储、计算、实时层重叠？
- 如果它延期、改价或取消，当前架构还能否正常工作？
因此，路线图只能影响“未来复审条件”，不应替代对今天已交付能力的验收。
6. 成本研究要用工作负载，而不是起步价格#
“每月起”几乎从来不是决策答案。至少应准备三档工作负载：
| 档位 | 需要代入的变量 |
|---|---|
| 开发与预览 | 闲置时间、分支数量、测试数据、环境寿命 |
| 小规模生产 | 常驻计算、数据库大小、备份、出口流量、连接数 |
| 增长后 | 活跃用户、第三方身份用户、实时消息、峰值连接、读副本、日志和恢复窗口 |
对于每个候选方案，写出可解释的成本表达式，而不是只给一个总价：
月成本 = 基础订阅 + 常驻或按量计算 + 存储 + 出口流量
+ 备份 / 恢复 + 实时消息与连接 + 身份用户 + 预览环境还应单独检查两类“反转项”：
- 闲置时是否会缩容或暂停；这会改变低流量和大量预览环境的结论。
- 是否存在新的计量维度，例如外部身份用户、实时峰值连接、数据 API、恢复窗口或 branch compute。
成本结论必须带有工作负载前提。不同 CPU、内存、地域、可用性等级和连接模型不能只用单价直接比较。
7. 用最小验证处理最高风险假设#
调研不应止于阅读。把所有“如果不成立就会推翻方案”的假设列出来，然后设计最小验证。
| 高风险假设 | 最小验证 |
|---|---|
| 浏览器 token 能正确触发行级权限 | 用两个用户和一条禁止访问的记录做端到端测试 |
| 服务端事务能够承载关键写入 | 实现一次包含约束冲突和回滚的短事务 |
| 实时通道能满足交互 | 测试断线、重连、重复消息、权限撤销和高频信号 |
| 预览环境可用于现有迁移工具 | 在独立分支中真实运行 migration、seed 和回收流程 |
| SSR / 边缘运行时可访问数据 | 验证首屏、后续导航、缓存头和服务端私密逻辑边界 |
验证的目的不是做一个完整 POC，而是尽快否定错误假设。一次半天的可重复实验，通常比几十页功能对比更有决策价值。
8. 输出条件化决策，而不是伪精确评分#
除非指标能被稳定量化，否则不建议用“功能 8.5 分、生态 7.2 分”这类评分。更可靠的输出结构是：
- 当前选择：在现有约束下采用什么，为什么。
- 明确不选什么：哪些能力看似丰富，但会重复已有职责或引入第二条关键链路。
- 例外 profile：满足哪些产品条件时，允许使用另一种方案。
- 禁止组合：哪些数据或实时语义不能双 owner。
- 复审触发器：达到什么规模、出现什么功能需求、某个预览能力 GA 后，再重新评估。
例如：
默认：使用服务端 PostgreSQL 处理关系型强约束数据。
例外：当产品明确需要浏览器直接受行级权限保护的关系数据，
且实时信号是辅助能力时，采用对应的 BaaS profile。
禁止：同一业务实体不同时进入响应式数据层和关系型 BaaS 作为主状态。
复审：浏览器直连需求成为多项产品的共同前提，或候选服务的 Beta 能力 GA 后。这种结论的价值在于可执行、可审阅，也允许未来在条件变化后自然调整。
9. 可直接复用的研究模板#
# <决策主题>
整理日期：YYYY-MM-DD
## 决策问题
## 范围与不可变约束
## 数据 owner 与关键调用拓扑
## 候选方案
## 对比维度
- 数据模型与事务
- 浏览器 / 服务端授权路径
- 实时语义与失败恢复
- SSR / 边缘运行时
- 运维、可观测性与合规
- 成本模型与环境策略
- 可迁移性与供应商锁定
- 当前成熟度与未来路线
## 证据台账
| 结论 | 类型（事实 / 推断 / 决策） | 来源 | 整理日期 | 适用条件 |
## 最小验证
## 当前决策、例外与禁止组合
## 复审触发器最后检查清单#
- 问题已经从产品名之争改写为决策问题。
- 每个核心对象只有一个 canonical owner。
- 浏览器、服务端和实时链路被分别画出并检查授权。
- 事实、推断、偏好和路线图没有混写。
- 当前功能与 Alpha / Beta / 愿景被明确区分。
- 价格按实际工作负载建模，而非只比较起步价。
- 最高风险假设已有最小可复现验证。
- 结论包含例外、禁止组合和复审触发条件。
当这些条件满足时，技术研究就不再是“谁的功能多”的争论，而是一份能帮助系统长期演进、也能在新事实出现后被安全修订的决策记录。