with one click
with one click
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p12a-contemplation-prerequisite-check |
| description | 检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法 |
| stage | discovery |
| tags | ["正见","前提检查","情境判断","方法重配"] |
| source_book | 观照 |
| source_chapter | 第1章 旧方法没有失效 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| method_name | 曾有效的方法名称(如"用户访谈""敏捷开发") |
| context_change | 情境变化描述(用户变了?市场变了?) |
| observed_failure | 观察到的失效表现 |
"过去那套产品方法之所以有效,背后其实站着几个默认前提。第一,问题边界大体稳定。第二,用户反馈相对稳定。第三,竞争与技术迭代虽然激烈,但还没快到让季度级规划失去意义。"
书稿在第一章指出,AI 改写的恰恰是这些隐含前提。用户不再总知道自己要什么,因为新的可能性每天都在变;技术不再只是"支持产品",它开始主动改写产品应该长成什么样;竞争也不再只是同行之间的追赶,而是整个用户预期被外部工具集体抬高。老方法并不是突然过时了,而是它们所依赖的世界已经没有那么稳定了。前提是会持续变化的,不是检查一次就永远有效。
在产品实践中,这意味着每次重大方法启动前都应该做一次前提检查。例如"用户访谈"这个方法,默认了"用户能清晰表达需求"——但在 AI 时代,用户自己也在摸索 AI 能做什么,这个前提需要被重新审视。把前提清单记录为方法的"使用条件",定期更新,才能避免在一个已经移动的地面上继续跑得很快。
"数据当然重要,但在高变化情境里,数据更适合先扮演警报器,而不是裁判。它提醒你哪里需要重看,哪些行为说明用户预期变了,哪些异常信号意味着旧解释不够用了。"
书稿提出"数据降级"的概念:高变化情境中,数据更适合先扮演警报器而不是裁判。数据提醒哪里需要重看,不直接给出答案。不要让一张漂亮图表替代一次更艰难的重新判断。很多团队把"数据驱动"误当成"数据替我判断",结果是数据上升不等于方向正确——前提变了,同样的数据可能意味着不同的东西。
在产品决策中,当搜索质量指标在提升但搜索量持续下降时,数据本身不告诉你"搜索做得不够好"还是"用户行为前提已变"。数据只是警报器,提醒你"这里值得重看"。真正该做的是把搜索量下降当作用户行为前提变化的信号,而不是搜索质量不够的证据。这种"数据降级"的思维方式,能帮助团队避免被漂亮图表误导。
"团队真正要建立的不是一套新技巧,而是一种前置校准能力。每次方法启动之前,先看一眼方法所依赖的地面有没有变。看地面,比赶路更重要。"
书稿在第一章总结中强调:AI 时代最危险的不是做得慢,而是在一个已经移动的地面上继续跑得很快。前置校准能力不是"丢掉旧方法",而是先把方法放回情境里重新解释。需求分析还做,但不再只问"用户要什么",还要问"用户的工作流是不是已经被 AI 改写";数据仍然看,但把数据当作提醒;流程仍然保留,但流程要服务变化,不把团队锁死在旧节奏里。
在产品工作中,建立前置校准能力意味着将"前提检查"变成团队的固定动作。可以是在需求评审前先列出方法的隐含前提,或在数据复盘前先区分"旧问题优化"和"新问题出现"。这个停顿看似打断了惯性的顺滑感,但正是这一下停顿,决定了后面的努力是修正还是加速偏离。
Notion 团队在 2019 年看到 GPT-3 演示时并未被打动,因为模型会一本正经地编造答案。到了 2022 年拿到 GPT-4 早期访问后,团队第一次明显感觉到"事情变了"。一次 offsite 后,创始人 Ivan Zhao 和 Simon Last 多留三天在酒店房间里把原型硬做出来。他们知道 AI 会给用户带来价值,却不知道到底该做什么、怎么做、UI 要长什么样。
method_name: "产品迭代方法(需求分析→设计→开发→发布)"
context_change: "AI 模型能力从'自动补全'跃迁到'参与写作、组织和表达'"
observed_failure: "团队过去的方法、设计能力和工程推进能力都还在,但无法回答'AI 入口放在哪里''默认开启还是关闭''预设指令和自由输入怎么平衡'这些新问题"
=== 前提检查报告 ===
【失效前提清单】
1. "产品还是原来那种产品" → 已失效。产品边界从信息组织工具扩展到 AI 参与的工作流
2. "技术是约束条件" → 已失效。技术本身成了不断改写问题定义的力量
3. "用户能稳定表达需求" → 部分失效。用户自己也在摸索 AI 的可能性
【新的情境假设】
- 产品定义正在被 AI 能力重新书写
- 用户需要的不只是功能,而是"AI 如何自然进入工作流"的答案
- 交互模式和入口设计没有行业惯例可参考
【方法重配建议】
1. 需求分析从"用户要什么"扩展到"用户的工作流正在被怎样改写"
2. 用可逆小实验(3天原型)快速验证新情境理解
3. 将"AI 入口/默认开关/预设 vs 自由输入"作为新维度纳入设计评审
一个搜索团队持续优化关键词召回、排序逻辑和结果页体验,但搜索量持续下降。团队困惑:"我们的搜索质量在提升,为什么用户用得越来越少?"
method_name: "搜索优化方法(召回率提升、排序逻辑优化、结果页体验改进)"
context_change: "用户开始习惯让 AI 直接理解意图,不再愿意自己组织关键词"
observed_failure: "搜索质量指标在提升,但搜索量和搜索频率持续下降"
=== 前提检查报告 ===
【失效前提清单】
1. "用户会主动组织关键词" → 已失效。用户期望系统直接理解意图
2. "搜索是信息获取的主要方式" → 部分失效。对话式/引导式获取正在崛起
3. "搜索质量=召回率+排序" → 需扩展。用户感知的"搜索质量"已包含意图理解能力
【新的情境假设】
- 用户需要的不是更好的搜索框,而是一个会澄清、会引导、会帮助收敛选择的助手
- "搜索问题"可能实际是"决策引导问题"
【方法重配建议】
1. 从"搜索优化"扩展到"意图理解+引导式信息获取"
2. 用小实验验证:AI 辅助的搜索引导 vs 传统搜索优化,哪个用户满意度更高
3. 将搜索量下降从"质量指标"重新定义为"用户行为前提变化的警报信号"
| 方法类型 | 常见隐含前提 | AI 时代可能失效的情况 |
|---|---|---|
| 用户访谈 | 用户能清晰表达需求 | 用户自己也在摸索 AI 能做什么 |
| A/B 测试 | 问题边界稳定,变量可隔离 | AI 改变了用户行为模式,旧基线失效 |
| 数据驱动决策 | 数据越多越清楚 | 数据越多噪音越大,短期信号和投机信号一起放大 |
| 竞品分析 | 竞争格局短期内稳定 | 整个用户预期被外部 AI 工具集体抬高 |
| 敏捷迭代 | 小步快跑能逼近正确方向 | 方向本身在移动,跑得越快偏离越大 |
| 需求优先级排序 | 需求相对稳定 | 需求本身被技术能力重新定义 |
| 用户画像 | 用户行为模式相对稳定 | AI 正在改写用户的工作方式和期望 |
| 维度 | 前提检查 | 正见 |
|---|---|---|
| 关注点 | 方法的隐含前提是否成立 | 问题是否被正确看见 |
| 触发时机 | "以前有效的方法现在不灵了" | "问题定义模糊/争论不休" |
| 输出 | 失效前提清单 + 方法重配建议 | 三层分析 + 修正后的问题陈述 |
| 典型场景 | 搜索量下降但搜索质量在提升 | 同一现象不同角色叫成不同问题 |
| 两者关系 | 前提检查确认"地面还在不在" | 正见确认"问题看对了没有" |
第一种用法:让 AI 列出当前方法的隐含前提。 把你的方法(如"用户访谈""A/B 测试""敏捷迭代")描述给 AI,让它列出该方法默认成立的所有前提。前提一旦被写明,团队才知道自己到底站在什么地面上。
第二种用法:让 AI 同时给出两种解释。 把用户行为变化、数据异常交给它,让它同时给出"旧问题优化"和"新问题出现"两套解释。真正有价值的不是它替你选答案,而是它能逼团队别太快只相信第一种解释。
第三种用法:让 AI 生成低成本验证实验。 让 AI 帮你生成几组低成本验证实验,例如该先验证新的工作流分工、还是先验证用户对 AI 参与边界的不安。AI 可以帮你扩选项,但最后该做哪个实验,仍然要由人来判断。