p12a-contemplation-prerequisite-check

---
name: p12a-contemplation-prerequisite-check
description: 检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
stage: discovery
tags:
  - 正见
  - 前提检查
  - 情境判断
  - 方法重配
source_book: 观照
source_chapter: 第1章 旧方法没有失效
version: 1.0.0
---

# 前提检查 Skill（Prerequisite Check）

## 适用场景
- 过去有效的方法现在似乎失效了
- 沿用行业"最佳实践"但效果不佳
- 团队质疑"为什么这个方法在我们这里不 work"

## 输入
| 字段 | 说明 |
|------|------|
| method_name | 曾有效的方法名称（如"用户访谈""敏捷开发"） |
| context_change | 情境变化描述（用户变了？市场变了？） |
| observed_failure | 观察到的失效表现 |

## 输出
- 失效前提清单（3-5个）
- 新的情境假设
- 方法重配建议

## 工作流程
1. **前提列举**：列出该方法原本依赖的 3-5 个关键前提（如"用户能清晰表达需求""需求稳定"）
2. **前提验证**：逐一检查每个前提在当前情境中是否成立
3. **变化归因**：识别是哪个前提的失效导致了方法整体失效
4. **方法重配**：针对失效前提，提出方法的调整版本或替代方案

## 注意事项
- 避免陷入"方法本身不好"的草率判断——往往是前提变了
- 不要试图恢复失效的前提（如让用户回到过去），而是调整方法适应新前提
- 记录下这些前提，作为后续方法的"使用条件"

## 核心概念

### 1. 方法前提（Method Prerequisites）
- **定义**：一个方法能够生效所依赖的隐含条件和默认假设
- **关键点**：
  - 每个产品方法背后都站着若干默认前提——如"问题边界大体稳定""用户反馈相对稳定""技术迭代节奏还在季度规划可控范围内"
  - 方法本身未必失效，失效的是前提
  - 前提一旦没被看见，方法就不再是罗盘，而更像放大器——把误判做得更完整、更自信

### 2. 情境变化（Context Shift）
- **定义**：产品所处的外部或内部环境发生了根本性改变
- **关键点**：
  - AI 改写的是隐含前提：用户不再总知道自己要什么；技术从"支持产品"变成"改写产品应该长什么样"；竞争变成整个用户预期被外部工具集体抬高
  - 老方法不是突然过时，而是它们所依赖的世界已经没有那么稳定
  - 区分"旧问题优化"和"新问题出现"是关键判断

### 3. 前置校准能力（Pre-calibration Capability）
- **定义**：在方法启动之前，先检查方法所依赖的地面有没有变
- **关键点**：
  - 看地面比赶路更重要
  - AI 时代最危险的不是做得慢，而是在已经移动的地面上继续跑得很快
  - 这不是"丢掉旧方法"，而是先把方法放回情境里重新解释

### 4. 数据降级（Data Demotion）
- **定义**：将数据从"答案"角色降级为"警报器"角色
- **关键点**：
  - 高变化情境中，数据更适合先扮演警报器而不是裁判
  - 数据提醒哪里需要重看，不直接给出答案
  - 不要让一张漂亮图表替代一次更艰难的重新判断

### 5. 小实验验证（Small Experiment Validation）
- **定义**：用可逆、低成本、能验证判断的小实验重建新情境理解
- **关键点**：
  - 不是为了"快速上线一个功能"，而是为了更快知道新问题到底是不是真的成立
  - 前提在变时，不要急着一次性定大方向
  - 小实验的目标是验证判断，不是验证功能

## 深入核心概念

### 1. 方法前提的隐含默认

> "过去那套产品方法之所以有效，背后其实站着几个默认前提。第一，问题边界大体稳定。第二，用户反馈相对稳定。第三，竞争与技术迭代虽然激烈，但还没快到让季度级规划失去意义。"

书稿在第一章指出，AI 改写的恰恰是这些隐含前提。用户不再总知道自己要什么，因为新的可能性每天都在变；技术不再只是"支持产品"，它开始主动改写产品应该长成什么样；竞争也不再只是同行之间的追赶，而是整个用户预期被外部工具集体抬高。老方法并不是突然过时了，而是它们所依赖的世界已经没有那么稳定了。前提是会持续变化的，不是检查一次就永远有效。

在产品实践中，这意味着每次重大方法启动前都应该做一次前提检查。例如"用户访谈"这个方法，默认了"用户能清晰表达需求"——但在 AI 时代，用户自己也在摸索 AI 能做什么，这个前提需要被重新审视。把前提清单记录为方法的"使用条件"，定期更新，才能避免在一个已经移动的地面上继续跑得很快。

### 2. 数据从答案降级为警报器

> "数据当然重要，但在高变化情境里，数据更适合先扮演警报器，而不是裁判。它提醒你哪里需要重看，哪些行为说明用户预期变了，哪些异常信号意味着旧解释不够用了。"

书稿提出"数据降级"的概念：高变化情境中，数据更适合先扮演警报器而不是裁判。数据提醒哪里需要重看，不直接给出答案。不要让一张漂亮图表替代一次更艰难的重新判断。很多团队把"数据驱动"误当成"数据替我判断"，结果是数据上升不等于方向正确——前提变了，同样的数据可能意味着不同的东西。

在产品决策中，当搜索质量指标在提升但搜索量持续下降时，数据本身不告诉你"搜索做得不够好"还是"用户行为前提已变"。数据只是警报器，提醒你"这里值得重看"。真正该做的是把搜索量下降当作用户行为前提变化的信号，而不是搜索质量不够的证据。这种"数据降级"的思维方式，能帮助团队避免被漂亮图表误导。

### 3. 前置校准能力的建立

> "团队真正要建立的不是一套新技巧，而是一种前置校准能力。每次方法启动之前，先看一眼方法所依赖的地面有没有变。看地面，比赶路更重要。"

书稿在第一章总结中强调：AI 时代最危险的不是做得慢，而是在一个已经移动的地面上继续跑得很快。前置校准能力不是"丢掉旧方法"，而是先把方法放回情境里重新解释。需求分析还做，但不再只问"用户要什么"，还要问"用户的工作流是不是已经被 AI 改写"；数据仍然看，但把数据当作提醒；流程仍然保留，但流程要服务变化，不把团队锁死在旧节奏里。

在产品工作中，建立前置校准能力意味着将"前提检查"变成团队的固定动作。可以是在需求评审前先列出方法的隐含前提，或在数据复盘前先区分"旧问题优化"和"新问题出现"。这个停顿看似打断了惯性的顺滑感，但正是这一下停顿，决定了后面的努力是修正还是加速偏离。

## 分步执行

### 第 1 步：方法前提列举
1. 明确当前正在使用的方法（如"用户访谈""A/B 测试""敏捷开发""数据驱动决策"）
2. 列出该方法依赖的 3-5 个关键前提
3. 前提举例：
   - "用户知道自己要什么"（用户研究方法的前提）
   - "问题边界稳定"（需求分析的前提）
   - "技术是约束条件而非改写问题的力量"（技术评估的前提）
   - "数据越多越清楚"（数据分析的前提）

### 第 2 步：前提逐一验证
1. 对每个前提，检查它在当前情境中是否仍然成立
2. 标记为：✅ 仍然成立 / ⚠️ 部分成立 / ❌ 已经失效
3. 特别关注 AI 带来的前提变化：用户预期被抬高、技术能力改写产品定义、竞争边界模糊

### 第 3 步：变化归因
1. 识别是哪个前提的失效导致了方法整体效果下降
2. 判断这是"暂时波动"还是"趋势逆转"
3. 区分"旧问题没做够"和"新问题已经出现"

### 第 4 步：方法重配
1. 针对失效前提，提出方法的调整版本或替代方案
2. 需求分析还做，但不再只问"用户要什么"，还要问"用户的工作流是不是已经被 AI 改写"
3. 数据仍然看，但把数据当作提醒：哪些前提值得重查
4. 流程仍然保留，但流程要服务变化，不把团队锁死在旧节奏里

### 第 5 步：记录前提清单
1. 将验证过的关键前提记录为方法的"使用条件"
2. 标注哪些条件已变化、需要持续监测
3. 作为后续方法调用的前置参考

## 示例 1：Notion AI 转型中的方法前提变化

### 场景描述
Notion 团队在 2019 年看到 GPT-3 演示时并未被打动，因为模型会一本正经地编造答案。到了 2022 年拿到 GPT-4 早期访问后，团队第一次明显感觉到"事情变了"。一次 offsite 后，创始人 Ivan Zhao 和 Simon Last 多留三天在酒店房间里把原型硬做出来。他们知道 AI 会给用户带来价值，却不知道到底该做什么、怎么做、UI 要长什么样。

### 用户输入
```
method_name: "产品迭代方法（需求分析→设计→开发→发布）"
context_change: "AI 模型能力从'自动补全'跃迁到'参与写作、组织和表达'"
observed_failure: "团队过去的方法、设计能力和工程推进能力都还在，但无法回答'AI 入口放在哪里''默认开启还是关闭''预设指令和自由输入怎么平衡'这些新问题"
```

### 执行流程
1. **前提列举**：
   - 前提1：技术是支持产品的约束条件 → ❌ AI 开始主动改写产品应该长什么样
   - 前提2：用户能稳定表达需求 → ⚠️ 用户自己也在摸索 AI 能做什么
   - 前提3：问题边界相对稳定 → ❌ 产品边界被重新定义（从"信息组织工具"到"AI 参与的工作流"）
   - 前提4：交互模式和功能入口有行业惯例可参考 → ❌ 无现成模式
2. **变化归因**：核心前提是"产品还是原来那种产品"——模型能力一变，这个默认直接松动
3. **方法重配**：
   - 不是丢掉产品方法，而是把方法放回新情境
   - 用小实验重建理解：先做 AI 写作原型验证"AI 如何自然进入工作流"
   - 数据从答案降级为警报器：用户反馈不直接给出功能设计答案，而是提醒哪些新问题值得追问

### 输出结果
```
=== 前提检查报告 ===

【失效前提清单】
1. "产品还是原来那种产品" → 已失效。产品边界从信息组织工具扩展到 AI 参与的工作流
2. "技术是约束条件" → 已失效。技术本身成了不断改写问题定义的力量
3. "用户能稳定表达需求" → 部分失效。用户自己也在摸索 AI 的可能性

【新的情境假设】
- 产品定义正在被 AI 能力重新书写
- 用户需要的不只是功能，而是"AI 如何自然进入工作流"的答案
- 交互模式和入口设计没有行业惯例可参考

【方法重配建议】
1. 需求分析从"用户要什么"扩展到"用户的工作流正在被怎样改写"
2. 用可逆小实验（3天原型）快速验证新情境理解
3. 将"AI 入口/默认开关/预设 vs 自由输入"作为新维度纳入设计评审
```

## 示例 2：搜索工具面临用户行为根本变化

### 场景描述
一个搜索团队持续优化关键词召回、排序逻辑和结果页体验，但搜索量持续下降。团队困惑："我们的搜索质量在提升，为什么用户用得越来越少？"

### 用户输入
```
method_name: "搜索优化方法（召回率提升、排序逻辑优化、结果页体验改进）"
context_change: "用户开始习惯让 AI 直接理解意图，不再愿意自己组织关键词"
observed_failure: "搜索质量指标在提升，但搜索量和搜索频率持续下降"
```

### 执行流程
1. **前提列举**：
   - 前提1：用户会主动输入关键词来表达需求 → ❌ 用户开始习惯用自然语言或让 AI 理解意图
   - 前提2：搜索结果质量是用户满意度的核心驱动 → ⚠️ 仍然重要，但"搜索体验"本身的定义在变
   - 前提3：优化搜索是提高信息获取效率的主要手段 → ❌ AI 对话式获取正在替代搜索
2. **变化归因**：核心前提是"用户仍然愿意自己组织关键词"——AI 让用户预期变成了"系统应该理解我"
3. **方法重配**：
   - 不是搜索做得不够好，而是新问题已经出现：用户想要的是 guidance（引导），不只是 results（结果）
   - 搜索优化仍然做，但要同时探索"AI 辅助的意图理解"和"对话式信息获取"
   - 把搜索量下降当作警报器——提醒用户行为前提已变，而非搜索质量不够

### 输出结果
```
=== 前提检查报告 ===

【失效前提清单】
1. "用户会主动组织关键词" → 已失效。用户期望系统直接理解意图
2. "搜索是信息获取的主要方式" → 部分失效。对话式/引导式获取正在崛起
3. "搜索质量=召回率+排序" → 需扩展。用户感知的"搜索质量"已包含意图理解能力

【新的情境假设】
- 用户需要的不是更好的搜索框，而是一个会澄清、会引导、会帮助收敛选择的助手
- "搜索问题"可能实际是"决策引导问题"

【方法重配建议】
1. 从"搜索优化"扩展到"意图理解+引导式信息获取"
2. 用小实验验证：AI 辅助的搜索引导 vs 传统搜索优化，哪个用户满意度更高
3. 将搜索量下降从"质量指标"重新定义为"用户行为前提变化的警报信号"
```

## 前提检查速查表

| 方法类型 | 常见隐含前提 | AI 时代可能失效的情况 |
|---------|------------|-------------------|
| 用户访谈 | 用户能清晰表达需求 | 用户自己也在摸索 AI 能做什么 |
| A/B 测试 | 问题边界稳定，变量可隔离 | AI 改变了用户行为模式，旧基线失效 |
| 数据驱动决策 | 数据越多越清楚 | 数据越多噪音越大，短期信号和投机信号一起放大 |
| 竞品分析 | 竞争格局短期内稳定 | 整个用户预期被外部 AI 工具集体抬高 |
| 敏捷迭代 | 小步快跑能逼近正确方向 | 方向本身在移动，跑得越快偏离越大 |
| 需求优先级排序 | 需求相对稳定 | 需求本身被技术能力重新定义 |
| 用户画像 | 用户行为模式相对稳定 | AI 正在改写用户的工作方式和期望 |

## 常见误区

### 误区 1："方法不好所以换了"
- 真正的原因往往是前提变了，不是方法本身有问题
- 用户访谈方法本身没问题，但"用户能清晰表达需求"这个前提在 AI 时代需要重新审视
- 不要丢掉方法，要更新前提

### 误区 2："把失效的前提恢复回去"
- 不要试图让用户回到过去（如"让用户重新学会自己想关键词"）
- 应该调整方法适应新前提（如"让系统理解用户的自然语言意图"）
- 前提变了就是变了，要顺势而为

### 误区 3："只看数据不看前提"
- 数据告诉你"是什么"，前提告诉你"为什么这样"
- 数据上升不等于方向正确——前提变了，同样的数据可能意味着不同的东西
- 把数据当警报器，不当裁判

### 误区 4："一次检查就够了"
- 前提是会持续变化的，不是检查一次就永远有效
- 重大方法启动前都应该做一次前提检查
- 把前提清单记录为方法的"使用条件"，定期更新

## 与正见 Skill 的区别

| 维度 | 前提检查 | 正见 |
|------|---------|------|
| 关注点 | 方法的隐含前提是否成立 | 问题是否被正确看见 |
| 触发时机 | "以前有效的方法现在不灵了" | "问题定义模糊/争论不休" |
| 输出 | 失效前提清单 + 方法重配建议 | 三层分析 + 修正后的问题陈述 |
| 典型场景 | 搜索量下降但搜索质量在提升 | 同一现象不同角色叫成不同问题 |
| 两者关系 | 前提检查确认"地面还在不在" | 正见确认"问题看对了没有" |

## AI 辅助前提检查

### 推荐用法

**第一种用法：让 AI 列出当前方法的隐含前提。**
把你的方法（如"用户访谈""A/B 测试""敏捷迭代"）描述给 AI，让它列出该方法默认成立的所有前提。前提一旦被写明，团队才知道自己到底站在什么地面上。

**第二种用法：让 AI 同时给出两种解释。**
把用户行为变化、数据异常交给它，让它同时给出"旧问题优化"和"新问题出现"两套解释。真正有价值的不是它替你选答案，而是它能逼团队别太快只相信第一种解释。

**第三种用法：让 AI 生成低成本验证实验。**
让 AI 帮你生成几组低成本验证实验，例如该先验证新的工作流分工、还是先验证用户对 AI 参与边界的不安。AI 可以帮你扩选项，但最后该做哪个实验，仍然要由人来判断。