名称: pol-probe-advisor 描述: 基于假设、风险和资源选择正确的Proof of Life (PoL)探针。使用此技能将验证方法与真实学习目标匹配，而不是工具舒适度。 类型: 交互式
目的
引导产品经理选择正确的Proof of Life (PoL)探针类型（共5种风味），基于他们的假设、风险和可用资源。当您需要消除特定风险或测试狭窄假设，但不确定使用哪种验证方法时使用此技能。这个交互式技能确保您将最便宜的模型匹配到最严酷的真相——而不是您最舒适构建的模型。
这不是一个决定是否应该验证的工具（您应该验证）。它是一个选择如何最有效验证的决策框架。
关键概念
核心问题：方法-假设不匹配
常见失败模式： 产品经理基于工具舒适度（“我会Figma，所以我会设计一个原型”）选择验证方法，而不是学习目标。结果：验证错误的东西，错过实际风险。
解决方案： 从假设反向工作。问：“我消除的具体风险是什么？通向严酷真相的最便宜路径是什么？”
5种PoL探针风味（快速参考）
| 类型 | 核心问题 | 最适合 | 时间线 |
|---|---|---|---|
| 可行性检查 | “我们能构建这个吗？” | 技术未知、API依赖、数据完整性 | 1-2天 |
| 任务聚焦测试 | “用户能无摩擦地完成这项工作吗？” | 关键UI时刻、字段标签、决策点 | 2-5天 |
| 叙事原型 | “这个工作流程能获得利益相关者支持吗？” | 讲故事、解释复杂流程、对齐 | 1-3天 |
| 合成数据模拟 | “我们能否在不冒生产风险的情况下建模这个？” | 边缘情况、未知的未知、统计建模 | 2-4天 |
| 氛围编码PoL探针 | “这个解决方案能在真实用户接触中存活吗？” | 工作流程/UX验证与真实交互 | 2-3天 |
黄金规则： “使用最便宜的模型，讲述最严酷的真相。”
反模式（这什么不是）
- 不是"构建您最舒适的模型"： 将方法匹配到假设，而不是技能集
- 不是"基于利益相关者偏好选择"： 优化学习，而不是内部政治
- 不是"选择最令人印象深刻的选项"： 令人印象深刻≠信息丰富
- 不是"默认编码"： 编写代码应该是您的最后手段，而不是首选
何时使用此技能
✅ 使用此时：
- 您有清晰的假设但不知道使用哪种验证方法
- 您不确定是否构建代码、创建视频或运行模拟
- 您需要快速消除特定风险（几天内）
- 您想避免原型剧场
❌ 不使用此时：
- 您还没有假设（首先使用
problem-statement.md或problem-framing-canvas.md） - 您试图打动高管（那不是验证）
- 您已经知道答案（确认偏误）
- 您需要发布MVP（这是预MVP侦察）
促进真相来源
使用workshop-facilitation作为此技能的默认交互协议。
它定义：
- 会话提示+进入模式（引导式、上下文转储、最佳猜测）
- 单问题轮次与简明语言提示
- 进度标签（例如，上下文Qx/8和评分Qx/5）
- 中断处理和暂停/恢复行为
- 决策点的编号推荐
- 常规问题的快速选择编号响应选项（当有用时包括
其他（指定））
此文件定义特定领域评估内容。如有冲突，遵循此文件的领域逻辑。
应用
此交互式技能使用自适应提问基于您的上下文推荐正确的PoL探针类型。
步骤0：收集上下文
代理问：
让我们找出哪种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：识别核心问题
代理综合用户输入并问：
基于您的假设和风险，您真正试图回答哪个核心问题？
提供5个选项（与探针类型对齐）：
- “我们能构建这个吗？” — 您不确定技术可行性、API集成、数据可用性或第三方依赖
- “用户能无摩擦地完成这项工作吗？” — 您正在验证关键UI时刻、字段标签、导航或决策点
- “这个工作流程能获得利益相关者支持吗？” — 您需要解释复杂流程、对齐领导或"讲述vs.测试"故事
- “我们能否在不冒生产风险的情况下建模这个？” — 您需要探索边缘情况、模拟用户行为或安全测试提示逻辑
- “这个解决方案能在真实用户接触中存活吗？” — 您需要用户与半功能工作流程交互以捕获UX/工作流程问题
用户响应： [选择一个数字，或描述如果不适合]
步骤2：推荐PoL探针类型
基于用户选择，代理推荐匹配的探针类型：
选项1选择：“我们能构建这个吗？”
→ 推荐探针：可行性检查
这是什么： 一个1-2天的冲刺-删除测试，以揭示技术风险。不是要打动任何人—是要快速揭示障碍。
方法：
- GenAI提示链（测试AI能否处理您的用例）
- API嗅探测试（验证第三方集成工作）
- 数据完整性扫描（检查您的数据是否支持功能）
- 第三方工具评估（测试Zapier/Stripe/Twilio是否如您所想）
时间线： 1-2天
工具：
- ChatGPT/Claude（提示测试）
- Postman/Insomnia（API测试）
- Jupyter笔记本（数据探索）
- 概念验证脚本（可丢弃代码）
成功标准示例：
- 通过： API在<200毫秒内返回预期数据格式
- 失败： 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选择：“这个工作流程能获得利益相关者支持吗？”
→ 推荐探针：叙事原型
这是什么： 讲述故事，不要测试界面。使用视频演练或幻灯片故事板解释工作流程并衡量兴趣。这是"讲述vs.测试"—您正在验证叙事，而不是UI。
方法：
- Loom演练（屏幕录制与语音解说）
- Sora/Synthesia/Veo3（AI生成的解释视频）
- 幻灯片故事板（PowerPoint/Keynote与插图）
- 故事板草图（使用
storyboard.md组件技能）
时间线： 1-3天
工具：
- Loom（免费、快速）
- Sora/Synthesia（文本到视频、付费）
- PowerPoint/Keynote（幻灯片动画）
- Figma（静态故事板帧）
成功标准示例：
- 通过： 8/10利益相关者说"我会用这个"或"这解决了问题"
- 失败： 利益相关者问"为什么我会用这个？"或建议替代方法
- 学习： 识别叙事中哪部分引起共鸣（或不）
处理计划： 存档视频，记录反馈，删除支持文件。
下一步： 您希望我生成一个pol-probe工件记录此叙事原型吗？
选项4选择：“我们能否在不冒生产风险的情况下建模这个？”
→ 推荐探针：合成数据模拟
这是什么： 使用模拟用户、合成数据或提示逻辑测试探索边缘情况和未知的未知，而不触及生产。想想"风洞测试，比事后分析更便宜。"
方法：
- Synthea（合成患者数据生成）
- DataStax LangFlow（测试提示逻辑而无真实用户）
- 蒙特卡洛模拟（模型概率结果）
- 合成用户行为脚本（模拟点击模式、负载测试）
时间线： 2-4天
工具：
- Synthea（开源、医疗）
- DataStax LangFlow（提示链测试）
- Python + Faker库（生成合成数据）
- Locust/k6（合成用户负载测试）
成功标准示例：
- 通过： 系统处理10,000名合成用户，错误率<1%
- 失败： 边缘情况导致崩溃或错误输出
- 学习： 识别哪些边缘情况破坏系统
处理计划： 删除合成数据，存档发现，记录边缘情况。
下一步： 您希望我生成一个pol-probe工件记录此合成数据模拟吗？
选项5选择：“这个解决方案能在真实用户接触中存活吗？”
→ 推荐探针：氛围编码PoL探针
这是什么： 一个弗兰肯软件堆栈（ChatGPT Canvas + Replit + Airtable），创建足够幻象让用户与半功能工作流程交互。不是生产级—只够在48小时内捕获UX/工作流程信号。
⚠️ 警告： 这是最冒险的探针类型。它看起来足够真实，可能混淆势头与成熟度。仅当您需要真实用户接触且其他方法不足时使用。
方法：
- ChatGPT Canvas（快速UI生成）
- Replit（托管可丢弃代码）
- Airtable（假数据库）
- Carrd/Webflow（落地页+工作流程模型）
时间线： 2-3天
堆栈示例：
- ChatGPT Canvas：生成表单UI
- Replit：托管简单Flask/Node应用
- Airtable：捕获表单提交
- Loom：记录用户会话用于事后分析
成功标准示例：
- 通过： 8/10用户完成工作流程，0关键困惑时刻
- 失败： 用户卡住、问"这个坏了吗？"、或中途放弃
- 学习： 识别用户失去信心的确切步骤
处理计划： 用户会话后删除所有代码，存档Loom记录，记录学习。
下一步： 您希望我生成一个pol-probe工件记录此氛围编码探针吗？
步骤3：应用组件技能
代理提供：
我推荐使用**[选定探针类型]** 进行您的假设。您希望我：
- 生成一个完整的
pol-probe工件（使用pol-probe.md模板）包含您的假设、成功标准、时间线和处理计划？ - 逐步执行此探针类型的执行步骤（工具、方法、用户招募）？
- 在继续之前优化假设（如果看起来太宽泛或模糊）？
用户选择选项，代理相应执行。
步骤4：优化或迭代（可选）
如果用户不确定或假设太宽泛：
代理问：
您的假设看起来宽泛或同时测试多个事物。PoL探针在狭窄和可证伪时效果最佳。让我问几个澄清问题：
澄清问题：
- 您能先测试的最小事情是什么？（隔离一个变量）
- "失败"会是什么样子？（如果您无法描述失败，就无法衡量成功）
- 这测试用户行为、技术可行性还是利益相关者对齐？（选择一个焦点）
代理然后基于优化假设重新推荐探针类型。
示例
示例1：选择任务聚焦测试
用户上下文：
- 假设： “用户能在3分钟内完成我们的结账流程”
- 风险： 移动端高购物车放弃率
- 时间线： 3天
- 资源： UsabilityHub账户，20名等待列表用户
代理推理：
- 核心问题：“用户能无摩擦地完成这项工作吗？”
- 风险是任务完成（可观察行为），而不是技术可行性
- 时间线适合任务聚焦测试（2-5天）
推荐： 使用UsabilityHub的任务聚焦测试
- 方法：与移动用户的Maze原型测试
- 成功标准：80%+在<3分钟内完成结账
- 处理：分析热图后删除原型
示例2：选择可行性检查
用户上下文：
- 假设： “我们能使用GPT-4自动标记支持票，错误率<5%”
- 风险： 未知AI是否能处理行业特定术语
- 时间线： 1天
- 资源： 100张历史支持票，ChatGPT API访问
代理推理：
- 核心问题：“我们能构建这个吗？”
- 风险是技术可行性（AI能力），而不是用户行为
- 时间线短（1天=冲刺领域）
推荐： 使用提示工程冲刺的可行性检查
- 方法：通过GPT-4提示链运行100张票，测量错误率
- 成功标准：<5%错误分类票
- 处理：记录发现后删除冲刺代码
结果： 错误率是18%。决定不构建功能。节省6周开发时间。
示例3：选择叙事原型（不是氛围编码）
用户上下文：
- 假设： “企业买家会理解我们的多租户安全模型”
- 风险： 复杂技术概念需要解释
- 时间线： 2天
- 资源： Loom，5名企业潜在客户
代理推理：
- 核心问题：“这个工作流程能获得利益相关者支持吗？”
- 风险是理解/对齐，而不是任务完成
- 构建功能原型会过度投资（2天=只需解释它）
推荐： 使用Loom演练的叙事原型
- 方法：5分钟Loom用图表解释安全模型
- 成功标准：4/5潜在客户说"我理解这个"无后续问题
- 处理：5次会话后存档视频
为什么不是氛围编码探针： 您不需要用户与安全设置交互—您需要他们理解概念。叙事更便宜、更快。
示例4：避免原型剧场
用户上下文：
- 假设： “高管会批准预算，如果我们展示一个抛光演示”
- 风险： 内部政治
- 时间线： 3周
- 资源： 完整设计团队
代理响应：
⚠️ 这是原型剧场，不是PoL探针。
您正在测试内部政治，而不是用户行为或技术可行性。PoL探针消除产品风险，而不是组织风险。
推荐： 完全跳过原型。相反：
- 使用叙事原型（1天Loom演练）解释概念
- 用5名目标用户（不是高管）测试以验证假设
- 向高管展示用户反馈，而不是抛光演示
如果高管需要演示，在您用真实用户验证假设后构建它。
常见陷阱
1. 基于工具舒适度选择
失败模式： “我会Figma，所以我会设计UI原型”（即使设计不是风险）。
后果： 验证错误的东西；错过实际风险。
修复： 先回答核心问题，然后选择方法。如果您需要可行性检查但只懂设计工具，与工程师配对1天。
2. 默认编码
失败模式： “让我们构建它，看看发生什么。”
后果： 2周开发后才发现您测试了错误假设。
修复： 问：“最便宜的模型，讲述最严酷的真相是什么？” 通常不是代码。
3. 混淆氛围编码探针与MVP
失败模式： 氛围编码探针"看起来真实"，所以团队将其视为生产代码。
后果： 范围蔓延、技术债务、抵制处理。
修复： 构建前设置处理日期。氛围编码探针设计为弗兰肯软件—庆祝杂乱，学习后删除。
4. 同时测试多个事物
失败模式： “让我们在一个探针中测试工作流程、定价和UI。”
后果： 模糊结果—您不会知道哪个变量导致失败。
修复： 一个探针，一个假设。如果您有3个假设，运行3个探针。
5. 跳过成功标准
失败模式： “我们看到了就知道了。”
后果： 没有严酷真相—只有意见和虚荣指标。
修复： 构建前编写成功标准。定义"通过"、"失败"和"学习"阈值。
参考
相关技能
- pol-probe （组件） — 记录PoL探针的模板
- problem-statement （组件） — 在选择验证方法前框定问题
- problem-framing-canvas （交互式） — 验证前MITRE问题框定
- discovery-process （工作流程） — 在验证阶段使用PoL探针
- epic-hypothesis （组件） — 将史诗转化为可测试假设
外部框架
- Jeff Patton — 用户故事映射（精益验证原则）
- Marty Cagan — 启发（2014原型风味框架）
- Dean Peters — 氛围优先、验证快速、验证适合 （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