Appearance
Capture捕获层——收集和验证信息
前提与结论
在逻辑学中，任何结论都需要前提支撑。
前提1：所有人都会死
前提2：苏格拉底是人
结论：苏格拉底会死前提不充分，结论就不可靠。
信息收集的本质，就是为你的分析收集充分的前提。
很多人的分析出问题，不是分析能力不行，而是信息不够就开始分析。
信息的三种类型
不是所有信息都能作为可靠的前提。
你需要区分三类信息：
事实（Fact）
可以验证的客观陈述。
"这个接口响应时间是2秒" —— 可以测量，是事实
"服务器部署在北京机房" —— 可以核实，是事实
"用户量是10万" —— 可以统计，是事实事实可以直接作为分析的前提。
观点（Opinion）
主观判断，依赖于标准和立场。
"这个接口太慢了" —— 取决于你对"慢"的标准
"这个设计不好看" —— 主观审美
"我觉得用户会喜欢" —— 主观猜测观点不能直接作为前提，需要转化为事实。
怎么转化？问："你说太慢，具体是多少？标准是什么？"
推断（Inference）
基于事实的推测，但未经验证。
"接口慢可能是因为数据库查询" —— 是推测
"用户流失可能是因为加载太慢" —— 是推测推断需要被验证后才能作为前提。
判断信息类型
| 类型 | 特征 | 能否作为前提 |
|---|---|---|
| 事实 | 可验证、客观 | ✅ 可以 |
| 观点 | 主观、依赖标准 | ❌ 需转化为事实 |
| 推断 | 推测、未验证 | ❌ 需验证 |
信息质量四问
收集到信息后，用四个问题检验其质量：
问题一：来源可靠吗？
一手信息 > 二手信息 > 传闻
官方文档 > 博客文章 > 随口说说
数据报表 > 个人估计 > 听说示例：
可靠：监控系统显示接口响应时间2秒
不可靠：同事说"好像是2秒左右"问题二：有证据支撑吗？
有数据支撑 > 有案例支撑 > 纯粹断言示例：
有证据："根据日志，过去7天平均响应时间2.3秒"
无证据："接口响应很慢"问题三：时效性如何？
信息会过时。
最新数据 > 上周数据 > 上个月数据 > 去年数据示例：
有时效："今天的监控数据显示..."
可能过时："去年优化过一次，当时是..."问题四：立场是什么？
每个信息提供者都有立场。
需要问：这个人为什么这么说？他的立场是什么？示例：
产品经理说"这个功能很简单"
—— 他的立场是希望快点上线
后端说"这个需要两周"
—— 他的立场是留足buffer理解立场不是说信息一定有偏差，而是帮你更全面地理解信息。
信息收集的四个渠道
渠道一：直接观察
自己去看、去测、去试。
- 自己打开页面测量加载时间
- 自己查看日志和监控
- 自己复现问题优点：第一手信息，最可靠 缺点：耗时，可能有盲区
渠道二：主动询问
向相关人提问。
- 问产品：这个需求的背景是什么？
- 问后端：这个接口的逻辑是怎样的？
- 问测试：这个问题的复现步骤是什么？提问技巧：
- 问具体的问题，不问模糊的问题
- 问事实，不只问观点
- 确认你的理解是否正确
渠道三：查阅文档
查看现有的文档和数据。
- 技术文档
- 需求文档
- 监控数据
- 日志记录注意：文档可能过时，需要验证时效性。
渠道四：外部资源
查阅外部的知识和案例。
- 官方文档
- 技术博客
- 社区讨论
- 类似案例注意：外部信息需要适配你的具体情况。
什么时候信息"够了"
这是一个常见问题：我怎么知道信息收集够了，可以开始分析了？
标准一：关键问题都有答案
回顾5W2H，每个维度都有明确的答案了吗？
□ What - 具体是什么问题？【有答案】
□ Why - 为什么要解决？【有答案】
□ Who - 谁受影响？【有答案】
□ Where - 在哪里发生？【有答案】
□ When - 什么时候？【有答案】
□ How - 怎么发生的？【有答案】
□ How much - 影响多大？【有答案】标准二：信息能支撑初步判断
你能基于现有信息，形成一个初步假设吗？
"基于收集的信息，我初步判断问题是因为X，
理由是Y和Z。"
如果你能这样说，信息基本够了。标准三：边际收益递减
新收集的信息是否还能带来新的认知？
如果继续收集的信息都是重复的，
或者对分析没有帮助，
说明可以开始分析了。标准四：时间约束
现实中，信息收集要平衡充分性和时效性。
紧急问题：快速收集关键信息，80%够用就开始
常规问题：可以收集更充分实例演示
场景：测试报了一个Bug——"用户点击购买按钮后页面卡住了"
信息收集过程：
markdown
## 渠道一：直接观察
自己复现：
- 打开页面，点击购买按钮
- 确实卡住了，控制台有报错
- 报错信息：Cannot read property 'id' of undefined
记录：
- 事实：控制台报错 Cannot read property 'id' of undefined
- 类型：事实（可验证）
## 渠道二：主动询问
问测试：
- 问："每次都能复现吗？"
- 答："不是每次，大概3次里1次"
- 问："是所有用户还是特定用户？"
- 答："好像是新注册的用户比较容易出现"
记录：
- 事实：复现概率约33%
- 事实：新注册用户更容易出现
## 渠道三：查阅文档/日志
查看后端日志：
- 发现：新注册用户的某个字段可能为null
记录：
- 事实：后端日志显示某字段返回null
## 信息汇总
事实：
1. 点击购买按钮后页面报错
2. 报错：Cannot read property 'id' of undefined
3. 复现概率约33%
4. 新注册用户更容易出现
5. 后端日志显示某字段返回null
推断（待验证）：
- 可能是前端没有处理后端返回null的情况检查点：信息充足性检验
markdown
□ 关键信息完整
- 5W2H都有答案
- 没有明显的信息缺口
□ 信息类型清晰
- 区分了事实、观点、推断
- 事实有来源，推断有标记
□ 信息质量可靠
- 来源可靠
- 有证据支撑
- 时效性OK
- 理解了立场
□ 能支撑初步判断
- 可以形成初步假设
- 有足够信息开始分析常见错误
错误一：信息不足就开始分析
❌ 听到"页面卡住了"就开始猜测原因
✅ 先收集更多信息：报错是什么？能复现吗？什么情况下出现？错误二：只收集支持自己假设的信息
❌ 已经觉得是前端的问题，只查前端相关信息
✅ 同时检查后端、数据、网络等可能性这叫确认偏误，是常见的认知偏差。
错误三：把观点当事实
❌ "同事说这个接口很慢"就当成事实
✅ 追问："具体多慢？有数据吗？"转化为事实本章小结
核心观点：
- 结论需要前提支撑，信息收集就是收集前提
- 区分三种信息：事实、观点、推断
- 只有事实可以直接作为前提
信息质量四问：
- 来源可靠吗？
- 有证据支撑吗？
- 时效性如何？
- 立场是什么？
信息够了的标准：
- 关键问题都有答案
- 能支撑初步判断
- 边际收益递减
检查点：
□ 关键信息完整
□ 信息类型清晰
□ 信息质量可靠
□ 能支撑初步判断下一章，我们进入Process处理层——如何分类问题并选择合适的分析工具。