把产品当作系统阅读：一种技术产品调研方法

技术产品调研很容易变成功能表：是否支持某模型、有没有插件、能否离线、价格分几档。这样的表格适合快速筛选，却很难支持产品决策。功能只告诉我们某个版本“有什么”，系统视角则继续追问：它为什么以这种方式存在，依赖什么机制，又牺牲了什么。

把产品当作系统阅读，意味着把界面、运行时、商业模式和组织能力放进同一条因果链，而不是分别写成四章互不相干的材料。

从可重复观察开始

调研的第一层不是评价，而是可复现的行为。选择几个代表性任务，记录输入、操作路径、等待时间、权限提示、失败反馈和恢复方式。同一结论至少要能指向一个具体观察，而不是“感觉更流畅”。

把这四层分开，可以避免把推断写成事实，也能让后来出现的新证据只修改链路中的一段，而不是推翻整份报告。

沿体验反推责任边界

一个看似简单的“继续任务”按钮，背后可能涉及身份、会话状态、执行进程、文件版本和权限恢复。研究时可以沿着可见行为逐层提问：

1. 哪些状态跨设备或跨进程保存；
2. 哪些动作在本地发生，哪些必须经过远端；
3. 用户在哪些副作用前拥有确认权；
4. 中断后系统从哪个一致性点恢复；
5. 成本、延迟和隐私分别落在哪个边界。

这些问题不要求拿到对方全部源码。公开文档、实际操作、网络与进程行为、错误提示和产品限制都可以形成证据，但必须标明证据级别。

产品叙事可以提供假设，不能直接充当机制证明。观察、推断和判断需要使用不同语气。

比较架构选择，不只比较结果

两个产品都能完成同一任务，路径可能完全不同。一个把执行放在用户设备上，强调现有环境与即时控制；另一个把执行放在托管环境中，强调一致性与远程可达。不存在脱离目标的绝对优劣。

更有用的比较维度包括：状态所有权、执行位置、扩展边界、权限模型、失败恢复和成本结构。先比较这些结构，再解释功能差异，才能判断某个优势是短期实现领先，还是由整体架构持续产生。

好的产品研究不是宣布谁赢了，而是说明在什么约束下，哪种系统选择更值得采用。

最终交付一条决策链

一份可执行的调研结论应该包含四部分：已验证的事实、仍需验证的假设、与自身目标相关的权衡，以及下一步可以低成本验证的实验。推荐或反对某条路线时，还要写清适用条件；条件改变，结论也应允许改变。

这种方法会让报告少一些热闹的功能截图，多一些边界与机制，但它更接近产品工作的真实问题：我们不是在复制一个界面，而是在选择要承担哪些约束、建立哪些能力，并接受由此产生的长期形状。阅读产品，最终也是在阅读一个组织如何构造系统。