{"id":"9ac6e536-aedb-49e0-bfc3-72eaaf906e97","shortId":"6CJpyS","kind":"skill","title":"p12a-contemplation-prerequisite-check","tagline":"检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法","description":"# 前提检查 Skill（Prerequisite Check）\n\n## 适用场景\n- 过去有效的方法现在似乎失效了\n- 沿用行业\"最佳实践\"但效果不佳\n- 团队质疑\"为什么这个方法在我们这里不 work\"\n\n## 输入\n| 字段 | 说明 |\n|------|------|\n| method_name | 曾有效的方法名称（如\"用户访谈\"\"敏捷开发\"） |\n| context_change | 情境变化描述（用户变了？市场变了？） |\n| observed_failure | 观察到的失效表现 |\n\n## 输出\n- 失效前提清单（3-5个）\n- 新的情境假设\n- 方法重配建议\n\n## 工作流程\n1. **前提列举**：列出该方法原本依赖的 3-5 个关键前提（如\"用户能清晰表达需求\"\"需求稳定\"）\n2. **前提验证**：逐一检查每个前提在当前情境中是否成立\n3. **变化归因**：识别是哪个前提的失效导致了方法整体失效\n4. **方法重配**：针对失效前提，提出方法的调整版本或替代方案\n\n## 注意事项\n- 避免陷入\"方法本身不好\"的草率判断——往往是前提变了\n- 不要试图恢复失效的前提（如让用户回到过去），而是调整方法适应新前提\n- 记录下这些前提，作为后续方法的\"使用条件\"\n\n## 核心概念\n\n### 1. 方法前提（Method Prerequisites）\n- **定义**：一个方法能够生效所依赖的隐含条件和默认假设\n- **关键点**：\n  - 每个产品方法背后都站着若干默认前提——如\"问题边界大体稳定\"\"用户反馈相对稳定\"\"技术迭代节奏还在季度规划可控范围内\"\n  - 方法本身未必失效，失效的是前提\n  - 前提一旦没被看见，方法就不再是罗盘，而更像放大器——把误判做得更完整、更自信\n\n### 2. 情境变化（Context Shift）\n- **定义**：产品所处的外部或内部环境发生了根本性改变\n- **关键点**：\n  - AI 改写的是隐含前提：用户不再总知道自己要什么；技术从\"支持产品\"变成\"改写产品应该长什么样\"；竞争变成整个用户预期被外部工具集体抬高\n  - 老方法不是突然过时，而是它们所依赖的世界已经没有那么稳定\n  - 区分\"旧问题优化\"和\"新问题出现\"是关键判断\n\n### 3. 前置校准能力（Pre-calibration Capability）\n- **定义**：在方法启动之前，先检查方法所依赖的地面有没有变\n- **关键点**：\n  - 看地面比赶路更重要\n  - AI 时代最危险的不是做得慢，而是在已经移动的地面上继续跑得很快\n  - 这不是\"丢掉旧方法\"，而是先把方法放回情境里重新解释\n\n### 4. 数据降级（Data Demotion）\n- **定义**：将数据从\"答案\"角色降级为\"警报器\"角色\n- **关键点**：\n  - 高变化情境中，数据更适合先扮演警报器而不是裁判\n  - 数据提醒哪里需要重看，不直接给出答案\n  - 不要让一张漂亮图表替代一次更艰难的重新判断\n\n### 5. 小实验验证（Small Experiment Validation）\n- **定义**：用可逆、低成本、能验证判断的小实验重建新情境理解\n- **关键点**：\n  - 不是为了\"快速上线一个功能\"，而是为了更快知道新问题到底是不是真的成立\n  - 前提在变时，不要急着一次性定大方向\n  - 小实验的目标是验证判断，不是验证功能\n\n## 深入核心概念\n\n### 1. 方法前提的隐含默认\n\n> \"过去那套产品方法之所以有效，背后其实站着几个默认前提。第一，问题边界大体稳定。第二，用户反馈相对稳定。第三，竞争与技术迭代虽然激烈，但还没快到让季度级规划失去意义。\"\n\n书稿在第一章指出，AI 改写的恰恰是这些隐含前提。用户不再总知道自己要什么，因为新的可能性每天都在变；技术不再只是\"支持产品\"，它开始主动改写产品应该长成什么样；竞争也不再只是同行之间的追赶，而是整个用户预期被外部工具集体抬高。老方法并不是突然过时了，而是它们所依赖的世界已经没有那么稳定了。前提是会持续变化的，不是检查一次就永远有效。\n\n在产品实践中，这意味着每次重大方法启动前都应该做一次前提检查。例如\"用户访谈\"这个方法，默认了\"用户能清晰表达需求\"——但在 AI 时代，用户自己也在摸索 AI 能做什么，这个前提需要被重新审视。把前提清单记录为方法的\"使用条件\"，定期更新，才能避免在一个已经移动的地面上继续跑得很快。\n\n### 2. 数据从答案降级为警报器\n\n> \"数据当然重要，但在高变化情境里，数据更适合先扮演警报器，而不是裁判。它提醒你哪里需要重看，哪些行为说明用户预期变了，哪些异常信号意味着旧解释不够用了。\"\n\n书稿提出\"数据降级\"的概念：高变化情境中，数据更适合先扮演警报器而不是裁判。数据提醒哪里需要重看，不直接给出答案。不要让一张漂亮图表替代一次更艰难的重新判断。很多团队把\"数据驱动\"误当成\"数据替我判断\"，结果是数据上升不等于方向正确——前提变了，同样的数据可能意味着不同的东西。\n\n在产品决策中，当搜索质量指标在提升但搜索量持续下降时，数据本身不告诉你\"搜索做得不够好\"还是\"用户行为前提已变\"。数据只是警报器，提醒你\"这里值得重看\"。真正该做的是把搜索量下降当作用户行为前提变化的信号，而不是搜索质量不够的证据。这种\"数据降级\"的思维方式，能帮助团队避免被漂亮图表误导。\n\n### 3. 前置校准能力的建立\n\n> \"团队真正要建立的不是一套新技巧，而是一种前置校准能力。每次方法启动之前，先看一眼方法所依赖的地面有没有变。看地面，比赶路更重要。\"\n\n书稿在第一章总结中强调：AI 时代最危险的不是做得慢，而是在一个已经移动的地面上继续跑得很快。前置校准能力不是\"丢掉旧方法\"，而是先把方法放回情境里重新解释。需求分析还做，但不再只问\"用户要什么\"，还要问\"用户的工作流是不是已经被 AI 改写\"；数据仍然看，但把数据当作提醒；流程仍然保留，但流程要服务变化，不把团队锁死在旧节奏里。\n\n在产品工作中，建立前置校准能力意味着将\"前提检查\"变成团队的固定动作。可以是在需求评审前先列出方法的隐含前提，或在数据复盘前先区分\"旧问题优化\"和\"新问题出现\"。这个停顿看似打断了惯性的顺滑感，但正是这一下停顿，决定了后面的努力是修正还是加速偏离。\n\n## 分步执行\n\n### 第 1 步：方法前提列举\n1. 明确当前正在使用的方法（如\"用户访谈\"\"A/B 测试\"\"敏捷开发\"\"数据驱动决策\"）\n2. 列出该方法依赖的 3-5 个关键前提\n3. 前提举例：\n   - \"用户知道自己要什么\"（用户研究方法的前提）\n   - \"问题边界稳定\"（需求分析的前提）\n   - \"技术是约束条件而非改写问题的力量\"（技术评估的前提）\n   - \"数据越多越清楚\"（数据分析的前提）\n\n### 第 2 步：前提逐一验证\n1. 对每个前提，检查它在当前情境中是否仍然成立\n2. 标记为：✅ 仍然成立 / ⚠️ 部分成立 / ❌ 已经失效\n3. 特别关注 AI 带来的前提变化：用户预期被抬高、技术能力改写产品定义、竞争边界模糊\n\n### 第 3 步：变化归因\n1. 识别是哪个前提的失效导致了方法整体效果下降\n2. 判断这是\"暂时波动\"还是\"趋势逆转\"\n3. 区分\"旧问题没做够\"和\"新问题已经出现\"\n\n### 第 4 步：方法重配\n1. 针对失效前提，提出方法的调整版本或替代方案\n2. 需求分析还做，但不再只问\"用户要什么\"，还要问\"用户的工作流是不是已经被 AI 改写\"\n3. 数据仍然看，但把数据当作提醒：哪些前提值得重查\n4. 流程仍然保留，但流程要服务变化，不把团队锁死在旧节奏里\n\n### 第 5 步：记录前提清单\n1. 将验证过的关键前提记录为方法的\"使用条件\"\n2. 标注哪些条件已变化、需要持续监测\n3. 作为后续方法调用的前置参考\n\n## 示例 1：Notion AI 转型中的方法前提变化\n\n### 场景描述\nNotion 团队在 2019 年看到 GPT-3 演示时并未被打动，因为模型会一本正经地编造答案。到了 2022 年拿到 GPT-4 早期访问后，团队第一次明显感觉到\"事情变了\"。一次 offsite 后，创始人 Ivan Zhao 和 Simon Last 多留三天在酒店房间里把原型硬做出来。他们知道 AI 会给用户带来价值，却不知道到底该做什么、怎么做、UI 要长什么样。\n\n### 用户输入\n```\nmethod_name: \"产品迭代方法（需求分析→设计→开发→发布）\"\ncontext_change: \"AI 模型能力从'自动补全'跃迁到'参与写作、组织和表达'\"\nobserved_failure: \"团队过去的方法、设计能力和工程推进能力都还在，但无法回答'AI 入口放在哪里''默认开启还是关闭''预设指令和自由输入怎么平衡'这些新问题\"\n```\n\n### 执行流程\n1. **前提列举**：\n   - 前提1：技术是支持产品的约束条件 → ❌ AI 开始主动改写产品应该长什么样\n   - 前提2：用户能稳定表达需求 → ⚠️ 用户自己也在摸索 AI 能做什么\n   - 前提3：问题边界相对稳定 → ❌ 产品边界被重新定义（从\"信息组织工具\"到\"AI 参与的工作流\"）\n   - 前提4：交互模式和功能入口有行业惯例可参考 → ❌ 无现成模式\n2. **变化归因**：核心前提是\"产品还是原来那种产品\"——模型能力一变，这个默认直接松动\n3. **方法重配**：\n   - 不是丢掉产品方法，而是把方法放回新情境\n   - 用小实验重建理解：先做 AI 写作原型验证\"AI 如何自然进入工作流\"\n   - 数据从答案降级为警报器：用户反馈不直接给出功能设计答案，而是提醒哪些新问题值得追问\n\n### 输出结果\n```\n=== 前提检查报告 ===\n\n【失效前提清单】\n1. \"产品还是原来那种产品\" → 已失效。产品边界从信息组织工具扩展到 AI 参与的工作流\n2. \"技术是约束条件\" → 已失效。技术本身成了不断改写问题定义的力量\n3. \"用户能稳定表达需求\" → 部分失效。用户自己也在摸索 AI 的可能性\n\n【新的情境假设】\n- 产品定义正在被 AI 能力重新书写\n- 用户需要的不只是功能，而是\"AI 如何自然进入工作流\"的答案\n- 交互模式和入口设计没有行业惯例可参考\n\n【方法重配建议】\n1. 需求分析从\"用户要什么\"扩展到\"用户的工作流正在被怎样改写\"\n2. 用可逆小实验（3天原型）快速验证新情境理解\n3. 将\"AI 入口/默认开关/预设 vs 自由输入\"作为新维度纳入设计评审\n```\n\n## 示例 2：搜索工具面临用户行为根本变化\n\n### 场景描述\n一个搜索团队持续优化关键词召回、排序逻辑和结果页体验，但搜索量持续下降。团队困惑：\"我们的搜索质量在提升，为什么用户用得越来越少？\"\n\n### 用户输入\n```\nmethod_name: \"搜索优化方法（召回率提升、排序逻辑优化、结果页体验改进）\"\ncontext_change: \"用户开始习惯让 AI 直接理解意图，不再愿意自己组织关键词\"\nobserved_failure: \"搜索质量指标在提升，但搜索量和搜索频率持续下降\"\n```\n\n### 执行流程\n1. **前提列举**：\n   - 前提1：用户会主动输入关键词来表达需求 → ❌ 用户开始习惯用自然语言或让 AI 理解意图\n   - 前提2：搜索结果质量是用户满意度的核心驱动 → ⚠️ 仍然重要，但\"搜索体验\"本身的定义在变\n   - 前提3：优化搜索是提高信息获取效率的主要手段 → ❌ AI 对话式获取正在替代搜索\n2. **变化归因**：核心前提是\"用户仍然愿意自己组织关键词\"——AI 让用户预期变成了\"系统应该理解我\"\n3. **方法重配**：\n   - 不是搜索做得不够好，而是新问题已经出现：用户想要的是 guidance（引导），不只是 results（结果）\n   - 搜索优化仍然做，但要同时探索\"AI 辅助的意图理解\"和\"对话式信息获取\"\n   - 把搜索量下降当作警报器——提醒用户行为前提已变，而非搜索质量不够\n\n### 输出结果\n```\n=== 前提检查报告 ===\n\n【失效前提清单】\n1. \"用户会主动组织关键词\" → 已失效。用户期望系统直接理解意图\n2. \"搜索是信息获取的主要方式\" → 部分失效。对话式/引导式获取正在崛起\n3. \"搜索质量=召回率+排序\" → 需扩展。用户感知的\"搜索质量\"已包含意图理解能力\n\n【新的情境假设】\n- 用户需要的不是更好的搜索框，而是一个会澄清、会引导、会帮助收敛选择的助手\n- \"搜索问题\"可能实际是\"决策引导问题\"\n\n【方法重配建议】\n1. 从\"搜索优化\"扩展到\"意图理解+引导式信息获取\"\n2. 用小实验验证：AI 辅助的搜索引导 vs 传统搜索优化，哪个用户满意度更高\n3. 将搜索量下降从\"质量指标\"重新定义为\"用户行为前提变化的警报信号\"\n```\n\n## 前提检查速查表\n\n| 方法类型 | 常见隐含前提 | AI 时代可能失效的情况 |\n|---------|------------|-------------------|\n| 用户访谈 | 用户能清晰表达需求 | 用户自己也在摸索 AI 能做什么 |\n| A/B 测试 | 问题边界稳定，变量可隔离 | AI 改变了用户行为模式，旧基线失效 |\n| 数据驱动决策 | 数据越多越清楚 | 数据越多噪音越大，短期信号和投机信号一起放大 |\n| 竞品分析 | 竞争格局短期内稳定 | 整个用户预期被外部 AI 工具集体抬高 |\n| 敏捷迭代 | 小步快跑能逼近正确方向 | 方向本身在移动，跑得越快偏离越大 |\n| 需求优先级排序 | 需求相对稳定 | 需求本身被技术能力重新定义 |\n| 用户画像 | 用户行为模式相对稳定 | AI 正在改写用户的工作方式和期望 |\n\n## 常见误区\n\n### 误区 1：\"方法不好所以换了\"\n- 真正的原因往往是前提变了，不是方法本身有问题\n- 用户访谈方法本身没问题，但\"用户能清晰表达需求\"这个前提在 AI 时代需要重新审视\n- 不要丢掉方法，要更新前提\n\n### 误区 2：\"把失效的前提恢复回去\"\n- 不要试图让用户回到过去（如\"让用户重新学会自己想关键词\"）\n- 应该调整方法适应新前提（如\"让系统理解用户的自然语言意图\"）\n- 前提变了就是变了，要顺势而为\n\n### 误区 3：\"只看数据不看前提\"\n- 数据告诉你\"是什么\"，前提告诉你\"为什么这样\"\n- 数据上升不等于方向正确——前提变了，同样的数据可能意味着不同的东西\n- 把数据当警报器，不当裁判\n\n### 误区 4：\"一次检查就够了\"\n- 前提是会持续变化的，不是检查一次就永远有效\n- 重大方法启动前都应该做一次前提检查\n- 把前提清单记录为方法的\"使用条件\"，定期更新\n\n## 与正见 Skill 的区别\n\n| 维度 | 前提检查 | 正见 |\n|------|---------|------|\n| 关注点 | 方法的隐含前提是否成立 | 问题是否被正确看见 |\n| 触发时机 | \"以前有效的方法现在不灵了\" | \"问题定义模糊/争论不休\" |\n| 输出 | 失效前提清单 + 方法重配建议 | 三层分析 + 修正后的问题陈述 |\n| 典型场景 | 搜索量下降但搜索质量在提升 | 同一现象不同角色叫成不同问题 |\n| 两者关系 | 前提检查确认\"地面还在不在\" | 正见确认\"问题看对了没有\" |\n\n## AI 辅助前提检查\n\n### 推荐用法\n\n**第一种用法：让 AI 列出当前方法的隐含前提。**\n把你的方法（如\"用户访谈\"\"A/B 测试\"\"敏捷迭代\"）描述给 AI，让它列出该方法默认成立的所有前提。前提一旦被写明，团队才知道自己到底站在什么地面上。\n\n**第二种用法：让 AI 同时给出两种解释。**\n把用户行为变化、数据异常交给它，让它同时给出\"旧问题优化\"和\"新问题出现\"两套解释。真正有价值的不是它替你选答案，而是它能逼团队别太快只相信第一种解释。\n\n**第三种用法：让 AI 生成低成本验证实验。**\n让 AI 帮你生成几组低成本验证实验，例如该先验证新的工作流分工、还是先验证用户对 AI 参与边界的不安。AI 可以帮你扩选项，但最后该做哪个实验，仍然要由人来判断。","tags":["p12a","contemplation","prerequisite","check","native","product","agent","skills","gmaxxxie","agent-skills","ai-agent","ai-native"],"capabilities":["skill","source-gmaxxxie","skill-p12a-contemplation-prerequisite-check","topic-agent-skills","topic-ai-agent","topic-ai-native","topic-ai-product","topic-methodology","topic-product-management","topic-product-methodology","topic-product-thinking","topic-skills"],"categories":["ai-native-product-agent-skills"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/gmaxxxie/ai-native-product-agent-skills/p12a-contemplation-prerequisite-check","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add gmaxxxie/ai-native-product-agent-skills","source_repo":"https://github.com/gmaxxxie/ai-native-product-agent-skills","install_from":"skills.sh"}},"qualityScore":"0.478","qualityRationale":"deterministic score 0.48 from registry signals: · indexed on github topic:agent-skills · 56 github stars · SKILL.md body (6,847 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-05-18T18:57:28.089Z","embedding":null,"createdAt":"2026-05-01T01:02:54.644Z","updatedAt":"2026-05-18T18:57:28.089Z","lastSeenAt":"2026-05-18T18:57:28.089Z","tsv":"'-3':400 '-4':407 '-5':42,51,307 '1':47,78,170,293,296,323,342,358,381,390,455,499,526,572,618,644,701 '2':56,97,213,304,320,326,344,361,384,477,505,531,545,589,622,650,714 '2019':397 '2022':404 '3':41,50,59,119,252,306,309,331,339,349,369,387,483,509,535,596,627,657,725 '3天原型':533 '4':62,136,355,373,737 '5':152,378 'a/b':300,672,781 'ai':104,130,182,203,206,261,272,333,367,392,422,438,449,459,464,472,489,491,503,513,517,521,537,564,577,587,593,608,652,665,670,676,686,697,709,771,776,785,791,804,807,811,813 'calibr':123 'capabl':124 'chang':32,437,562 'check':5,13 'contempl':3 'context':31,99,436,561 'data':138 'demot':139 'experi':155 'failur':37,445,568 'gpt':399,406 'guidanc':601 'ivan':415 'last':419 'method':25,80,429,555 'name':26,430,556 'notion':391,395 'observ':36,444,567 'offsit':412 'p12a':2 'p12a-contemplation-prerequisite-check':1 'pre':122 'pre-calibr':121 'prerequisit':4,12,81 'result':604 'shift':100 'simon':418 'skill':11,746 'skill-p12a-contemplation-prerequisite-check' 'small':154 'source-gmaxxxie' 'topic-agent-skills' 'topic-ai-agent' 'topic-ai-native' 'topic-ai-product' 'topic-methodology' 'topic-product-management' 'topic-product-methodology' 'topic-product-thinking' 'topic-skills' 'ui':426 'valid':156 'vs':541,654 'work':21 'zhao':416 '一个搜索团队持续优化关键词召回':548 '一个方法能够生效所依赖的隐含条件和默认假设':83 '一次':411 '一次检查就够了':738 '三层分析':761 '不再愿意自己组织关键词':566 '不只是':603 '不当裁判':735 '不把团队锁死在旧节奏里':278,376 '不是丢掉产品方法':485 '不是为了':162 '不是搜索做得不够好':598 '不是方法本身有问题':704 '不是检查一次就永远有效':194,740 '不是验证功能':168 '不直接给出答案':150,228 '不要丢掉方法':711 '不要急着一次性定大方向':166 '不要让一张漂亮图表替代一次更艰难的重新判断':151,229 '不要试图恢复失效的前提':71 '不要试图让用户回到过去':716 '与正见':745 '丢掉旧方法':134,265 '两套解释':799 '两者关系':766 '个':43 '个关键前提':52,308 '为什么用户用得越来越少':553 '为什么这个方法在我们这里不':20 '为什么这样':730 '书稿在第一章总结中强调':260 '书稿在第一章指出':181 '书稿提出':222 '争论不休':757 '事情变了':410 '交互模式和入口设计没有行业惯例可参考':524 '交互模式和功能入口有行业惯例可参考':475 '产品定义正在被':516 '产品所处的外部或内部环境发生了根本性改变':102 '产品边界从信息组织工具扩展到':502 '产品边界被重新定义':468 '产品还是原来那种产品':480,500 '产品迭代方法':431 '仍然成立':328 '仍然要由人来判断':816 '仍然重要':581 '从':469,645 '他们知道':421 '以前有效的方法现在不灵了':755 '优化搜索是提高信息获取效率的主要手段':586 '会帮助收敛选择的助手':639 '会引导':638 '会给用户带来价值':423 '传统搜索优化':655 '但':582,706 '但不再只问':268,363 '但在':202 '但在高变化情境里':216 '但把数据当作提醒':275,371 '但搜索量和搜索频率持续下降':570 '但搜索量持续下降':550 '但效果不佳':18 '但无法回答':448 '但最后该做哪个实验':815 '但正是这一下停顿':289 '但流程要服务变化':277,375 '但要同时探索':607 '但还没快到让季度级规划失去意义':180 '低成本':159 '作为后续方法的':75 '作为后续方法调用的前置参考':388 '作为新维度纳入设计评审':543 '使用条件':76,210,383,743 '例如':197 '例如该先验证新的工作流分工':809 '信息组织工具':470 '修正后的问题陈述':762 '先做':488 '先检查方法所依赖的地面有没有变':127 '先看一眼方法所依赖的地面有没有变':257 '入口':538 '入口放在哪里':450 '关注点':751 '关键点':84,103,128,146,161 '典型场景':763 '写作原型验证':490 '决定了后面的努力是修正还是加速偏离':290 '决策引导问题':642 '分步执行':291 '列出当前方法的隐含前提':777 '列出该方法依赖的':305 '列出该方法原本依赖的':49 '创始人':414 '判断这是':345 '到':471 '到了':403 '前提1':457,574 '前提2':461,579 '前提3':466,585 '前提4':474 '前提一旦没被看见':92 '前提一旦被写明':787 '前提举例':310 '前提列举':48,456,573 '前提变了':235,732 '前提变了就是变了':722 '前提告诉你':729 '前提在变时':165 '前提是会持续变化的':193,739 '前提检查':10,281,749 '前提检查报告':497,616 '前提检查确认':767 '前提检查速查表':662 '前提逐一验证':322 '前提验证':57 '前置校准能力':120 '前置校准能力不是':264 '前置校准能力的建立':253 '区分':114,350 '却不知道到底该做什么':424 '参与写作':442 '参与的工作流':473,504 '参与边界的不安':812 '发布':435 '变化归因':60,341,478,590 '变成':109 '变成团队的固定动作':282 '变量可隔离':675 '只看数据不看前提':726 '召回率':629 '召回率提升':558 '可以帮你扩选项':814 '可以是在需求评审前先列出方法的隐含前提':283 '可能实际是':641 '同一现象不同角色叫成不同问题':765 '同时给出两种解释':792 '同样的数据可能意味着不同的东西':236,733 '后':413 '和':116,286,352,417,610,797 '哪个用户满意度更高':656 '哪些前提值得重查':372 '哪些异常信号意味着旧解释不够用了':221 '哪些行为说明用户预期变了':220 '因为新的可能性每天都在变':185 '因为模型会一本正经地编造答案':402 '团队困惑':551 '团队在':396 '团队才知道自己到底站在什么地面上':788 '团队真正要建立的不是一套新技巧':254 '团队第一次明显感觉到':409 '团队质疑':19 '团队过去的方法':446 '在产品决策中':237 '在产品实践中':195 '在产品工作中':279 '在方法启动之前':126 '地面还在不在':768 '场景描述':394,547 '多留三天在酒店房间里把原型硬做出来':420 '失效前提清单':40,498,617,759 '失效的是前提':91 '如':28,53,86,298,717,720,779 '如何自然进入工作流':492,522 '如让用户回到过去':72 '字段':23 '它开始主动改写产品应该长成什么样':188 '它提醒你哪里需要重看':219 '定义':82,101,125,140,157 '定期更新':211,744 '对每个前提':324 '对话式':625 '对话式信息获取':611 '对话式获取正在替代搜索':588 '将':536 '将搜索量下降从':658 '将数据从':141 '将验证过的关键前提记录为方法的':382 '小实验的目标是验证判断':167 '小实验验证':153 '小步快跑能逼近正确方向':689 '工作流程':46 '工具集体抬高':687 '已包含意图理解能力':634 '已失效':501,507,620 '已经失效':330 '市场变了':35 '带来的前提变化':334 '帮你生成几组低成本验证实验':808 '常见误区':699 '常见隐含前提':664 '年拿到':405 '年看到':398 '应该调整方法适应新前提':719 '建立前置校准能力意味着将':280 '开发':434 '开始主动改写产品应该长什么样':460 '引导':602 '引导式信息获取':649 '引导式获取正在崛起':626 '当搜索质量指标在提升但搜索量持续下降时':238 '往往是前提变了':70 '很多团队把':230 '快速上线一个功能':163 '快速验证新情境理解':534 '怎么做':425 '情境变化':98 '情境变化描述':33 '意图理解':648 '我们的搜索质量在提升':552 '或在数据复盘前先区分':284 '才能避免在一个已经移动的地面上继续跑得很快':212 '执行流程':454,571 '扩展到':529,647 '技术不再只是':186 '技术从':107 '技术是支持产品的约束条件':458 '技术是约束条件':506 '技术是约束条件而非改写问题的力量':315 '技术本身成了不断改写问题定义的力量':508 '技术能力改写产品定义':336 '技术评估的前提':316 '技术迭代节奏还在季度规划可控范围内':89 '把你的方法':778 '把前提清单记录为方法的':209,742 '把失效的前提恢复回去':715 '把搜索量下降当作警报器':612 '把数据当警报器':734 '把用户行为变化':793 '把误判做得更完整':95 '排序':630 '排序逻辑优化':559 '排序逻辑和结果页体验':549 '推荐用法':773 '描述给':784 '提出方法的调整版本或替代方案':65,360 '提醒你':244 '提醒用户行为前提已变':613 '搜索优化':646 '搜索优化仍然做':606 '搜索优化方法':557 '搜索体验':583 '搜索做得不够好':240 '搜索工具面临用户行为根本变化':546 '搜索是信息获取的主要方式':623 '搜索结果质量是用户满意度的核心驱动':580 '搜索质量':628,633 '搜索质量指标在提升':569 '搜索量下降但搜索质量在提升':764 '搜索问题':640 '支持产品':108,187 '改写':273,368 '改写产品应该长什么样':110 '改写的恰恰是这些隐含前提':183 '改写的是隐含前提':105 '改变了用户行为模式':677 '敏捷开发':30,302 '敏捷迭代':688,783 '数据上升不等于方向正确':731 '数据仍然看':274,370 '数据从答案降级为警报器':214,493 '数据分析的前提':318 '数据只是警报器':243 '数据告诉你':727 '数据异常交给它':794 '数据当然重要':215 '数据提醒哪里需要重看':149,227 '数据更适合先扮演警报器':217 '数据更适合先扮演警报器而不是裁判':148,226 '数据替我判断':233 '数据本身不告诉你':239 '数据越多噪音越大':681 '数据越多越清楚':317,680 '数据降级':137,223,249 '数据驱动':231 '数据驱动决策':303,679 '整个用户预期被外部':685 '新的情境假设':44,515,635 '新问题出现':117,287,798 '新问题已经出现':353 '方向本身在移动':690 '方法不好所以换了':702 '方法前提':79 '方法前提列举':295 '方法前提的隐含默认':171 '方法就不再是罗盘':93 '方法本身不好':68 '方法本身未必失效':90 '方法的隐含前提是否成立':752 '方法类型':663 '方法重配':63,357,484,597 '方法重配建议':45,525,643,760 '无现成模式':476 '旧基线失效':678 '旧问题优化':115,285,796 '旧问题没做够':351 '早期访问后':408 '时代':204 '时代可能失效的情况':666 '时代最危险的不是做得慢':131,262 '时代需要重新审视':710 '明确当前正在使用的方法':297 '是什么':728 '是关键判断':118 '暂时波动':346 '更自信':96 '曾有效的方法名称':27 '最佳实践':17 '本身的定义在变':584 '标注哪些条件已变化':385 '标记为':327 '核心前提是':479,591 '核心概念':77 '检查它在当前情境中是否仍然成立':325 '检查方法使用的前提是否成立':6 '模型能力一变':481 '模型能力从':439 '正在改写用户的工作方式和期望':698 '正见':750 '正见确认':769 '步':294,321,340,356,379 '每个产品方法背后都站着若干默认前提':85 '每次方法启动之前':256 '比赶路更重要':259 '沿用行业':16 '注意事项':66 '流程仍然保留':276,374 '测试':301,673,782 '深入核心概念':169 '演示时并未被打动':401 '特别关注':332 '理解意图':578 '生成低成本验证实验':805 '用可逆':158 '用可逆小实验':532 '用小实验重建理解':487 '用小实验验证':651 '用户不再总知道自己要什么':106,184 '用户仍然愿意自己组织关键词':592 '用户会主动组织关键词':619 '用户会主动输入关键词来表达需求':575 '用户反馈不直接给出功能设计答案':494 '用户反馈相对稳定':88,177 '用户变了':34 '用户开始习惯用自然语言或让':576 '用户开始习惯让':563 '用户想要的是':600 '用户感知的':632 '用户期望系统直接理解意图':621 '用户画像':695 '用户的工作流是不是已经被':271,366 '用户的工作流正在被怎样改写':530 '用户知道自己要什么':311 '用户研究方法的前提':312 '用户能清晰表达需求':54,201,668,707 '用户能稳定表达需求':462,510 '用户自己也在摸索':205,463,512,669 '用户行为前提变化的警报信号':661 '用户行为前提已变':242 '用户行为模式相对稳定':696 '用户要什么':269,364,528 '用户访谈':29,198,299,667,780 '用户访谈方法本身没问题':705 '用户输入':428,554 '用户需要的不只是功能':519 '用户需要的不是更好的搜索框':636 '用户预期被抬高':335 '的区别':747 '的可能性':514 '的思维方式':250 '的概念':224 '的答案':523 '的草率判断':69 '直接理解意图':565 '看地面':258 '看地面比赶路更重要':129 '真正有价值的不是它替你选答案':800 '真正的原因往往是前提变了':703 '真正该做的是把搜索量下降当作用户行为前提变化的信号':246 '短期信号和投机信号一起放大':682 '示例':389,544 '竞争与技术迭代虽然激烈':179 '竞争也不再只是同行之间的追赶':189 '竞争变成整个用户预期被外部工具集体抬高':111 '竞争格局短期内稳定':684 '竞争边界模糊':337 '竞品分析':683 '第':292,319,338,354,377 '第一':174 '第一种用法':774 '第三':178 '第三种用法':802 '第二':176 '第二种用法':789 '答案':142 '系统应该理解我':595 '组织和表达':443 '结果':605 '结果是数据上升不等于方向正确':234 '结果页体验改进':560 '维度':748 '老方法不是突然过时':112 '老方法并不是突然过时了':191 '而不是搜索质量不够的证据':247 '而不是裁判':218 '而是':520 '而是一个会澄清':637 '而是一种前置校准能力':255 '而是为了更快知道新问题到底是不是真的成立':164 '而是先把方法放回情境里重新解释':135,266 '而是在一个已经移动的地面上继续跑得很快':263 '而是在已经移动的地面上继续跑得很快':132 '而是它们所依赖的世界已经没有那么稳定':113 '而是它们所依赖的世界已经没有那么稳定了':192 '而是它能逼团队别太快只相信第一种解释':801 '而是把方法放回新情境':486 '而是提醒哪些新问题值得追问':495 '而是整个用户预期被外部工具集体抬高':190 '而是新问题已经出现':599 '而是调整方法适应新前提':73 '而更像放大器':94 '而非搜索质量不够':614 '背后其实站着几个默认前提':173 '能做什么':207,465,671 '能力重新书写':518 '能帮助团队避免被漂亮图表误导':251 '能验证判断的小实验重建新情境理解':160 '自动补全':440 '自由输入':542 '要更新前提':712 '要长什么样':427 '要顺势而为':723 '观察到的失效表现':38 '角色':145 '角色降级为':143 '触发时机':754 '警报器':144 '让':775,790,803,806 '让它列出该方法默认成立的所有前提':786 '让它同时给出':795 '让用户重新学会自己想关键词':718 '让用户预期变成了':594 '让系统理解用户的自然语言意图':721 '记录下这些前提':74 '记录前提清单':380 '设计':433 '设计能力和工程推进能力都还在':447 '识别情境变化':7 '识别是哪个前提的失效导致了方法整体失效':61 '识别是哪个前提的失效导致了方法整体效果下降':343 '误区':700,713,724,736 '误当成':232 '说明':24 '质量指标':659 '趋势逆转':348 '跃迁到':441 '跑得越快偏离越大':691 '转型中的方法前提变化':393 '辅助前提检查':772 '辅助的意图理解':609 '辅助的搜索引导':653 '输入':22 '输出':39,758 '输出结果':496,615 '过去有效的方法现在似乎失效了':15 '过去那套产品方法之所以有效':172 '还是':241,347 '还是先验证用户对':810 '还要问':270,365 '这不是':133 '这个停顿看似打断了惯性的顺滑感':288 '这个前提在':708 '这个前提需要被重新审视':208 '这个方法':199 '这个默认直接松动':482 '这些新问题':453 '这意味着每次重大方法启动前都应该做一次前提检查':196 '这种':248 '这里值得重看':245 '适用场景':14 '逐一检查每个前提在当前情境中是否成立':58 '避免陷入':67 '部分失效':511,624 '部分成立':329 '重大方法启动前都应该做一次前提检查':741 '重新定义为':660 '重配适用方法':9 '针对失效前提':64,359 '问题定义模糊':756 '问题是否被正确看见':753 '问题看对了没有':770 '问题边界大体稳定':87,175 '问题边界相对稳定':467 '问题边界稳定':313,674 '需扩展':631 '需求优先级排序':692 '需求分析':432 '需求分析从':527 '需求分析的前提':314 '需求分析还做':267,362 '需求本身被技术能力重新定义':694 '需求相对稳定':693 '需求稳定':55 '需要持续监测':386 '预设':540 '预设指令和自由输入怎么平衡':452 '验证假设前提':8 '高变化情境中':147,225 '默认了':200 '默认开关':539 '默认开启还是关闭':451","prices":[{"id":"1d28bbb5-deec-4ee0-b4da-6ac399abba38","listingId":"9ac6e536-aedb-49e0-bfc3-72eaaf906e97","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"gmaxxxie","category":"ai-native-product-agent-skills","install_from":"skills.sh"},"createdAt":"2026-05-01T01:02:54.644Z"}],"sources":[{"listingId":"9ac6e536-aedb-49e0-bfc3-72eaaf906e97","source":"github","sourceId":"gmaxxxie/ai-native-product-agent-skills/p12a-contemplation-prerequisite-check","sourceUrl":"https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p12a-contemplation-prerequisite-check","isPrimary":false,"firstSeenAt":"2026-05-01T01:02:54.644Z","lastSeenAt":"2026-05-18T18:57:28.089Z"}],"details":{"listingId":"9ac6e536-aedb-49e0-bfc3-72eaaf906e97","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"gmaxxxie","slug":"p12a-contemplation-prerequisite-check","github":{"repo":"gmaxxxie/ai-native-product-agent-skills","stars":56,"topics":["agent-skills","ai-agent","ai-native","ai-product","methodology","product-management","product-methodology","product-thinking","skills"],"license":null,"html_url":"https://github.com/gmaxxxie/ai-native-product-agent-skills","pushed_at":"2026-05-06T07:19:36Z","description":"AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.","skill_md_sha":"71557990e9c439241851d14275f3458344f74045","skill_md_path":"skills/p12a-contemplation-prerequisite-check/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p12a-contemplation-prerequisite-check"},"layout":"multi","source":"github","category":"ai-native-product-agent-skills","frontmatter":{"name":"p12a-contemplation-prerequisite-check","description":"检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法"},"skills_sh_url":"https://skills.sh/gmaxxxie/ai-native-product-agent-skills/p12a-contemplation-prerequisite-check"},"updatedAt":"2026-05-18T18:57:28.089Z"}}