P12a contemplation prerequisite check

前提检查 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 可以帮你扩选项，但最后该做哪个实验，仍然要由人来判断。