关于 pol-probe-advisor
面向产品经理的交互式决策技能，根据待验证的假设、风险和资源，推荐合适的 Proof of Life 探针类型，避免验证方法与学习目标错配。
主要功能
- 01按假设与风险匹配探针
- 02涵盖 5 种 PoL 探针类型
- 03结合时间、预算与用户资源
- 04通过自适应提问收集背景
- 05提供验证方式与后续建议
适用场景
- 01为明确的产品假设选择验证方法
- 02在数日内排查特定产品风险
- 03判断应采用测试、叙事或模拟
- 04避免只按熟悉工具制作原型
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/pol-probe-advisor确认已加载。
详细介绍
目的
引导产品经理根据假设、风险和可用资源，选择合适的 Proof of Life（PoL）探测类型（共 5 种）。当你需要排除特定风险或验证一个范围较窄的假设，却不确定该用哪种验证方法时，请使用此工具。这个交互式技能能确保你选择成本最低、却能揭示最严峻事实的原型，而不是你最擅长构建的原型。
这不是一个用来决定是否应该验证的工具（你应该验证）。它是一个决策框架，帮助你选择最有效的验证方式。
输入
最适合提供： 你想验证的假设或想排除的风险。 也有帮助： 你的资源（时间、预算、工程支持）、受众资源，以及失败的代价。
随调用一并提供的任何内容——技能名称后的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已回答的问题。请使用这些信息，并跳过相关问题；不要重复询问。
什么都没准备也没关系。 顾问会先询问你想了解什么，然后从 5 种探测类型中为你匹配合适的一种。
调用示例： Which probe fits? Hypothesis: mid-market HR teams will trust AI-drafted job descriptions enough to publish them; 2 weeks, no eng support.
核心概念
核心问题：方法与假设不匹配
常见失败模式： PM 根据对工具的熟悉程度选择验证方法（“我会用 Figma，所以我来设计一个原型”），而不是根据学习目标来选择。结果：验证了错误的内容，错过了真正的风险。
解决方案： 从假设倒推。问：“我要排除的具体风险是什么？揭示严峻事实的最低成本路径是什么？”
5 种 PoL 探测类型（速查）
| 类型 | 核心问题 | 最适用场景 | 时间安排 |
|---|---|---|---|
| 可行性检查 | “我们能构建这个吗？” | 技术未知项、API 依赖、数据完整性 | 1-2 天 |
| 任务聚焦测试 | “用户能否顺畅完成这项任务？” | 关键 UI 时刻、字段标签、决策点 | 2-5 天 |
| 叙事原型 | “这个工作流能赢得利益相关方的支持吗？” | 讲故事、解释复杂流程、达成共识 | 1-3 天 |
| 合成数据模拟 | “我们能否在不产生生产环境风险的情况下对其建模？” | 边缘案例、未知的未知、统计建模 | 2-4 天 |
| Vibe-Coded PoL 探测 | “这个解决方案经得起真实用户检验吗？” | 与真实交互结合的工作流/UX 验证 | 2-3 天 |
黄金法则： “使用能揭示最严峻事实的最低成本原型。”
反模式（这不是什么）
- 不是“构建你最擅长的原型”： 让方法匹配假设，而不是技能组合
- 不是“根据利益相关方的偏好来选”： 优化学习效果，而非内部政治
- 不是“选择最令人印象深刻的方案”： 令人印象深刻 ≠ 提供有用信息
- 不是“默认选择代码”： 编写代码应该是最后的手段，而不是首选
何时使用此技能
✅ 适用于以下情况：
- 你有明确的假设，但不知道该用哪种验证方法
- 你不确定应该编写代码、制作视频，还是运行模拟
- 你需要在短时间内（几天内）排除特定风险
- 你想避免原型作秀
❌ 以下情况不适用：
- 你还没有假设（请先使用
problem-statement.md或problem-framing-canvas.md） - 你想给高管留下深刻印象（这不算验证）
- 你已经知道答案（确认偏误）
- 你需要发布 MVP（此工具用于 MVP 发布前的侦察）
引导环节的事实来源
默认使用 workshop-facilitation 作为此技能的交互协议。
它定义了：
- 会话提示 + 进入模式（引导式、上下文倾倒、最佳猜测）
- 使用通俗语言提示，每轮只问一个问题
- 进度标签（例如，Context Qx/8 和 Scoring Qx/5）
- 中断处理以及暂停/恢复行为
- 决策点处的编号建议
- 常规问题的快速选择编号选项（适用时包含
Other (specify)）
此文件定义了领域专属的评估内容。如有冲突，请遵循此文件的领域逻辑。
应用
此交互式技能使用自适应提问，根据你的上下文推荐合适的 PoL 探针类型。
步骤 0：收集上下文
Agent 询问：
我们来看看哪种 PoL 探针类型适合你的验证需求。首先，我需要了解一些背景：
1. 你要验证什么假设？ （用一句话描述，或使用“如果我们为 [用户画像] 做 [X]，那么就会产生 [结果]”的格式）
2. 你想消除什么具体风险？ 示例：
- 技术可行性（“我们的 API 能处理实时数据吗？”）
- 用户任务完成情况（“用户能找到‘导出’按钮吗？”）
- 利益相关者达成一致（“领导层会批准这个方向吗？”）
- 边缘情况行为（“系统如何处理重复条目？”）
- 工作流验证（“用户会完成 3 步引导流程吗？”）
3. 你的时间安排是什么？
- 几小时（当天验证）
- 1-2 天（快速试验）
- 3-5 天（中等投入）
- 1 周以上（时间太长——考虑拆分成更小的探针）
4. 你有哪些可用资源？ 示例：
- 工程资源（1 名开发人员投入 1 天）
- 设计工具（Figma、Loom、Sora）
- AI/无代码工具（ChatGPT Canvas、Replit、Airtable）
- 用户资源（等待名单中的 10 名用户、5 名 Beta 客户等）
- 预算（用于 UsabilityHub、Optimal Workshop 等）
步骤 1：确定核心问题
Agent 综合用户输入并询问：
根据你的假设和风险，你真正想回答的是以下哪个核心问题？
提供 5 个选项（对应不同探针类型）：
- “我们能做出这个吗？” — 你不确定技术可行性、API 集成、数据可用性或第三方依赖
- “用户能否顺畅地完成这项任务？” — 你在验证关键 UI 环节、字段标签、导航或决策点
- “这个工作流能否赢得利益相关者的支持？” — 你需要解释复杂流程、让领导层达成一致，或讲述“说服而非测试”的故事
- “我们能否在不承担生产风险的情况下模拟这个？” — 你需要探索边缘情况、模拟用户行为，或安全地测试提示词逻辑
- “这个解决方案能否经受真实用户的检验？” — 你需要让用户与半功能工作流交互，以发现 UX/工作流问题
用户回复：[选择一个编号，或描述是否都不合适]
步骤 2：推荐 PoL 探针类型
根据用户的选择，Agent 推荐匹配的探针类型：
已选择选项 1：“我们能构建这个吗？”
→ 建议的探测方式：可行性检查
说明： 开展为期 1-2 天的快速验证，完成后删除，用于发现技术风险。目的不是给任何人留下深刻印象，而是快速揭示阻碍因素。
方法：
- GenAI 提示词链（测试 AI 能否处理你的用例）
- API 嗅探测试（验证第三方集成是否可用）
- 数据完整性检查（检查你的数据是否支持该功能）
- 第三方工具评估（测试 Zapier/Stripe/Twilio 是否能实现你设想的功能）
时间安排： 1-2 天
工具：
- ChatGPT/Claude（提示词测试）
- Postman/Insomnia（API 测试）
- Jupyter notebooks（数据探索）
- 概念验证脚本（一次性代码）
成功标准示例：
- 通过： API 在 <200ms 内返回预期的数据格式
- 失败： API 超时，或数据结构与我们的架构不兼容
- 收获： 找出具体的技术阻碍因素
清理计划： 记录发现后，删除所有快速验证代码。
下一步： 你希望我生成一份 pol-probe 工件来记录这项可行性检查吗？
已选择选项 2：“用户能否顺畅地完成这项任务？”
→ 建议的探测方式：以任务为核心的测试
说明： 使用专门的测试工具验证关键环节——字段标签、决策点、导航和流失区域。重点关注可观察到的任务完成情况，而非主观意见。
方法：
- Optimal Workshop（树测试、卡片分类）
- UsabilityHub（5 秒测试、点击测试、偏好测试）
- Maze（带热力图的原型测试）
- 使用 Loom 录制任务演练（请用户“边做边说”）
时间安排： 2-5 天
工具：
- Optimal Workshop（$200/月）
- UsabilityHub（$100-300/月）
- Maze（提供免费套餐）
- Loom（基础功能免费）
成功标准示例：
- 通过： 80%+ 的用户在 <2 分钟内完成任务
- 失败： 完成率 <60%，或有 3+ 位用户卡在同一步骤
- 收获： 找出确切的阻碍点（特定字段、按钮等）
清理计划： 归档测试录制内容，记录心得，并删除测试原型。
下一步： 你希望我生成一份 pol-probe 工件来记录这项以任务为核心的测试吗？
已选择选项 3：“这项工作流能否获得利益相关者的认可？”
→ 建议的探测方式：叙事原型
说明： 讲述故事，而不是测试界面。使用视频演示或幻灯片故事板来说明工作流并衡量兴趣。这是“讲述而非测试”——你要验证的是叙事，而非 UI。
方法：
- Loom 演示（带配音的屏幕录制）
- Sora/Synthesia/Veo3（AI 生成的讲解视频）
- 幻灯片故事板（带插图的 PowerPoint/Keynote）
- 故事板草图（使用
storyboard.md组件技能）
时间安排： 1-3 天
工具：
- Loom（免费、快速）
- Sora/Synthesia（文本转视频，付费）
- PowerPoint/Keynote（幻灯片动画）
- Figma（静态故事板画面）
成功标准示例：
- 通过： 10 位利益相关者中有 8 位表示“我会使用这个”或“这解决了问题”
- 失败： 利益相关者询问“我为什么要用这个？”或提出替代方案
- 收获： 找出叙事中哪些部分引起共鸣（或没有）
清理计划： 归档视频，记录反馈，并删除辅助文件。
下一步： 你希望我生成一份 pol-probe 工件来记录这个叙事原型吗？
已选择选项 4：“我们能否在不影响生产环境的情况下对其建模？”
→ 推荐探针：合成数据模拟
内容： 使用模拟用户、合成数据或提示词逻辑测试，在不接触生产环境的情况下探索边缘情况和未知的未知。可以把它想成“风洞测试，比事后复盘更便宜”。
方法：
- Synthea（合成患者数据生成）
- DataStax LangFlow（在不使用真实用户的情况下测试提示词逻辑）
- 蒙特卡洛模拟（对概率结果进行建模）
- 合成用户行为脚本（模拟点击模式、负载测试）
时间线： 2-4 天
工具：
- Synthea（开源，医疗保健）
- DataStax LangFlow（提示词链测试）
- Python + Faker 库（生成合成数据）
- Locust/k6（使用合成用户进行负载测试）
成功标准示例：
- 通过： 系统可处理 10,000 个合成用户，错误率低于 1%
- 未通过： 边缘情况导致崩溃或输出错误
- 收获： 找出会导致系统故障的边缘情况
处置计划： 删除合成数据，归档调查结果，记录边缘情况。
下一步： 是否需要我生成一份记录此合成数据模拟的 pol-probe 文档？
已选择选项 5：“这个解决方案能否经受真实用户的检验？”
→ 推荐探针：Vibe-Coded PoL 探针
内容： 使用一套 Frankensoft 技术栈（ChatGPT Canvas + Replit + Airtable），营造足够逼真的假象，让用户能与半功能工作流进行交互。它并非生产级方案，只需能在 48 小时内捕捉 UX/工作流信号即可。
⚠️ 警告： 这是风险最高的探针类型。它看起来足够真实，容易让人把势头误认为成熟度。只有在需要接触真实用户，且其他方法都不够用时才使用。
方法：
- ChatGPT Canvas（快速生成 UI）
- Replit（托管一次性代码）
- Airtable（虚假数据库）
- Carrd/Webflow（着陆页 + 工作流原型）
时间线： 2-3 天
技术栈示例：
- ChatGPT Canvas：生成表单 UI
- Replit：托管简单的 Flask/Node 应用
- Airtable：收集表单提交
- Loom：录制用户会话，以便事后复盘分析
成功标准示例：
- 通过： 10 位用户中有 8 位完成工作流，且没有出现关键困惑时刻
- 未通过： 用户卡住、询问“这是坏了吗？”或中途放弃
- 收获： 找出用户失去信心的确切步骤
处置计划： 用户会话结束后删除所有代码，归档 Loom 录制内容，记录经验。
下一步： 是否需要我生成一份记录此 Vibe-Coded 探针的 pol-probe 文档？
第 3 步：应用组件技能
Agent 提议：
我建议针对你的假设使用 [所选探针类型]。你希望我：
- 生成完整的
pol-probe文档（使用pol-probe.md模板），包含你的假设、成功标准、时间线和处置计划？ - 逐步讲解此探针类型的执行步骤（工具、方法、用户招募）？
- 在继续之前完善假设（如果它似乎过于宽泛或含糊）？
用户选择选项，Agent 据此执行。
第 4 步：完善或迭代（可选）
如果用户不确定，或假设过于宽泛：
Agent 提问：
你的假设似乎过于宽泛，或一次测试了多个方面。PoL 探针在范围狭窄且可证伪时效果最佳。我来问几个澄清问题：
澄清问题：
- 你可以先测试的最小事项是什么？（隔离一个变量）
- “失败”会是什么样子？（如果你无法描述失败，就无法衡量成功）
- 这是在测试用户行为、技术可行性，还是利益相关方之间的共识？（选择一个重点）
随后，Agent 会根据完善后的假设重新推荐探针类型。
示例
示例 1：选择以任务为重点的测试
用户背景：
- 假设：“用户可以在 3 分钟内完成我们的结账流程”
- **风险：**移动端购物车弃购率高
- **时间线：**3 天
- **资源：**UsabilityHub 账户、等候名单中的 20 位用户
Agent 推理：
- 核心问题：“用户能否毫无阻碍地完成这项任务？”
- 风险在于任务完成情况（可观察的行为），而非技术可行性
- 时间线适合以任务为重点的测试（2–5 天）
**建议：**使用 UsabilityHub 进行以任务为重点的测试
- 方法：使用 Maze 对移动端用户进行原型测试
- 成功标准：80% 以上的用户在 <3 分钟内完成结账
- 处置：分析热图后删除原型
示例 2：选择可行性检查
用户背景：
- 假设：“我们可以使用 GPT-4 自动为支持工单添加标签，错误率低于 5%”
- **风险：**尚不清楚 AI 是否能处理行业特有术语
- **时间线：**1 天
- **资源：**100 条历史支持工单、ChatGPT API 访问权限
Agent 推理：
- 核心问题：“我们能构建这个功能吗？”
- 风险在于技术可行性（AI 能力），而非用户行为
- 时间线很短（1 天，适合进行技术验证）
**建议：**通过提示词工程技术验证进行可行性检查
- 方法：使用 GPT-4 提示词链处理 100 条工单，并测量错误率
- 成功标准：错误分类的工单低于 5%
- 处置：记录发现后删除技术验证代码
**结果：**错误率为 18%。决定不构建该功能。节省了 6 周的开发时间。
示例 3：选择叙事型原型（而非氛围编码）
用户背景：
- 假设：“企业买家会理解我们的多租户安全模型”
- **风险：**复杂的技术概念需要解释
- **时间线：**2 天
- **资源：**Loom、5 位企业潜在客户
Agent 推理：
- 核心问题：“这个工作流能否赢得利益相关者的认同？”
- 风险在于理解和共识，而非任务完成情况
- 构建功能性原型会投入过多（只有 2 天，够用来解释概念）
**建议：**使用 Loom 演示视频制作叙事型原型
- 方法：制作 5 分钟的 Loom 视频，配合图表讲解安全模型
- 成功标准：5 位潜在客户中有 4 位表示“我理解了”，且无需追问
- 处置：完成 5 次演示后归档视频
**为什么不采用氛围编码探针：**你不需要用户操作安全设置，而是需要他们理解这个概念。叙事方式成本更低、速度更快。
示例 4：避免原型作秀
用户背景：
- 假设：“只要展示精致的演示，管理层就会批准预算”
- **风险：**内部政治
- **时间线：**3 周
- **资源：**完整的设计团队
Agent 回复：
⚠️ 这是原型作秀，不是 PoL 探针。
你测试的是内部政治，而非用户行为或技术可行性。PoL 探针旨在消除产品风险，而不是组织风险。
**建议：**完全跳过原型。改为：
- 使用叙事型原型（1 天的 Loom 演示视频）解释概念
- 与5 位目标用户（而非管理层）进行测试，验证假设
- 向管理层展示用户反馈，而非精致的演示
如果管理层需要演示，应在通过真实用户验证假设之后再制作。
常见陷阱
1. 根据对工具的熟悉程度做选择
失败模式：“我会用 Figma，所以我要设计一个 UI 原型”（即使设计并非风险所在）。
**后果：**验证了错误的内容，错过了真正的风险。
**解决方法：*先回答核心问题，再选择方法。如果你需要做可行性检查，但只会用设计工具，就找一位工程师合作 1 天。
2. 默认选择编写代码
失败模式：“我们干脆把它构建出来，看看会怎样。”
**后果：**花 2 周开发后才发现，测试的是错误的假设。
**解决方法：**问问自己：“什么是能揭示最严峻真相的最廉价原型？”通常答案不是代码。
3. 将氛围编程探针误当作 MVP
失败模式： 氛围编程探针“看起来像真的”，因此团队把它当作生产代码。
后果： 范围蔓延、技术债务，以及不愿将其弃用。
解决方法： 在构建前设定弃用日期。氛围编程探针本就设计成 Frankensoft——尽情享受它的粗糙，学到东西后就删除。
4. 一次测试多项内容
失败模式：“我们在一个探针里测试工作流、定价和 UI 吧。”
后果： 结果模糊不清——你无法知道是哪个变量导致了失败。
解决方法： 一个探针，一个假设。如果你有 3 个假设，就运行 3 个探针。
5. 跳过成功标准
失败模式：“到时候我们自然会知道。”
后果： 没有严厉的事实，只有观点和虚荣指标。
解决方法： 在构建前先写好成功标准。定义“通过”“失败”和“学到东西”的阈值。
参考资料
相关技能
- pol-probe（组件）— 记录 PoL 探针的模板
- problem-statement（组件）— 选择验证方法前先界定问题
- problem-framing-canvas（交互式）— 在验证前使用 MITRE 问题界定方法
- discovery-process（工作流）— 在验证阶段使用 PoL 探针
- epic-hypothesis（组件）— 将 Epic 转化为可测试的假设
外部框架
- Jeff Patton — User Story Mapping（精益验证原则）
- Marty Cagan — Inspired（2014 年原型类型框架）
- Dean Peters — Vibe First, Validate Fast, Verify Fit（Dean Peters 的 Substack，2025 年）
按探针类型划分的工具
- 可行性： ChatGPT/Claude、Postman、Jupyter
- 任务导向： Optimal Workshop、UsabilityHub、Maze
- 叙事： Loom、Sora、Synthesia、PowerPoint
- 合成数据： Synthea、DataStax LangFlow、Faker
- 氛围编程： ChatGPT Canvas、Replit、Airtable、Carrd