pol-probe

目的

定义并记录一种 生命迹象证明（PoL）探针——一种轻量、一次性的验证产物，旨在昂贵开发开始前揭示严峻事实。当你需要消除特定风险或验证范围狭窄的假设，而不构建生产级软件时，就可以使用它。PoL 探针是侦察任务，不是 MVP——它们的设计目的是被删除，而不是被扩展。

这个框架可以避免原型作秀（耗资不菲、能打动利益相关者却毫无收获的演示），并迫使你让验证方法与实际学习目标相匹配。

输入

最适合提供： 你需要验证的假设或风险。 也很有帮助： 什么证据会改变你的想法、可用时间和资源，以及你已经验证过的内容。

调用时附带的任何内容——技能名称后面的文本、粘贴的上下文信息，或附加的 ARGUMENTS: 行——都视为已提供的答案。请使用这些信息，并跳过其中已涵盖的问题；不要重复询问。

两手空空也没关系。 这项技能会在设计探针前询问假设及其中风险最高的前提。

调用示例： Define a PoL probe: we believe restaurant managers will photograph invoices daily if it auto-updates food costs.

核心概念

什么是 PoL 探针？

生命迹象证明（PoL）探针是一种有意设计、可一次性使用的验证实验，旨在以尽可能低的成本和最快的速度回答一个特定问题。它不是产品，不是 MVP，也不是试点——它是一项有针对性的求真任务。

起源： 该术语由 Dean Peters（Productside）创造，基于 Marty Cagan 2014 年关于原型类型的研究，以及 Jeff Patton 的原则：“测试想法最昂贵的方式，就是构建生产级软件。”

---

5 个基本特征

每个 PoL 探针都必须符合以下标准：

特征	含义	重要性
轻量	投入的资源极少（几小时／几天，而非几周）	如果成本高昂，当数据表明应停止时，你就会不愿放弃
一次性	明确计划将其删除，而非扩展	避免沉没成本谬误和范围蔓延
范围狭窄	验证一个特定假设或风险	宽泛的实验会产生模糊不清的结果
直面真相	揭示严峻事实，而非虚荣指标	委婉的数据毫无用处
小而聚焦	侦察任务，绝不是 MVP	表面积小 = 学习周期更快

反模式： 如果你的“原型”精致到让你舍不得删除，那它就不是 PoL 探针，而是原型作秀。

---

PoL 探针与 MVP 的区别

维度	PoL 探针	MVP
目的	通过验证范围狭窄的假设来降低决策风险	为想法提供依据，或为路线图方向辩护
范围	一个问题，一个风险	可发布的最小产品增量
生命周期	几小时到几天，然后删除	几周到几个月，然后迭代
受众	内部团队 + 小范围用户样本	生产环境中的真实客户
保真度	足以捕捉信号的最低限度假象	生产级（或接近生产级）
结果	了解什么行不通	了解什么行得通（并将其发布）

关键区别： PoL 探针是 MVP 前的侦察工作。运行探针是为了决定是否应该构建 MVP，而不是为了发布某个东西。

---

5 种原型类型

根据假设选择探测类型，而不是根据你熟悉的工具选择。

类型	核心问题	时间安排	工具/方法	适用场景
1. 可行性检查	“我们能构建它吗？”	1-2 天	GenAI 提示词链、API 测试、数据完整性检查、用后即删的探索性代码	技术风险尚不明确；第三方依赖情况不明
2. 任务导向测试	“用户能否顺畅地完成这项任务？”	2-5 天	Optimal Workshop、UsabilityHub、任务流程	需要验证关键环节（字段标签、决策点、流失区域）
3. 叙事型原型	“这个工作流能否赢得利益相关方的支持？”	1-3 天	Loom 演示视频、Sora/Synthesia 视频、幻灯片故事板	你需要“讲述而非测试”——分享故事，衡量兴趣
4. 合成数据模拟	“我们能否在不产生生产环境风险的情况下建模？”	2-4 天	Synthea（用户模拟）、DataStax LangFlow（提示词逻辑测试）	探索边缘情况；发现未知的未知问题
5. Vibe 编码 PoL 探测	“这个解决方案能否经受真实用户的检验？”	2-3 天	ChatGPT Canvas + Replit + Airtable = “Frankensoft”	你需要用户对工作流/UX 提供反馈，但不需要生产级代码

黄金法则： “使用成本最低、却能揭示最严酷真相的原型。如果它不会让你感到刺痛，那它很可能只是在演戏。”

---

何时使用 PoL 探测

✅ 在以下情况下使用 PoL 探测：

• 你有一个具体且可证伪的假设要测试
• 某个特定风险阻碍了你的下一步决策（技术可行性、用户任务完成情况、利益相关方支持）
• 你需要尽快得知严酷的真相（几天内，而不是几周内）
• 构建生产软件还为时过早，或会造成浪费
• 在开始之前，你能清楚描述什么情况算作“失败”

❌ 在以下情况下不要使用 PoL 探测：

• 你想给高管留下深刻印象（这就是原型表演）
• 你已经知道答案，只是想要确认（这就是确认偏误）
• 你无法清楚描述假设或处置计划
• 学习目标过于宽泛（“客户会喜欢这个吗？”）
• 你用它来逃避艰难的决策

---

应用

使用 template.md 获取完整的填空模板。

PoL 探测模板

使用此结构记录你的探测：

# PoL Probe: [Descriptive Name]

## Hypothesis
[One-sentence statement of what you believe to be true]
Example: "If we reduce the onboarding form to 3 fields, completion rate will exceed 80%."

## Risk Being Eliminated
[What specific risk or unknown are you addressing?]
Example: "We don't know if users will abandon signup due to form length."

## Prototype Type
[Select one of the 5 flavors]
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [x] Vibe-Coded PoL Probe

## Target Users / Audience
[Who will interact with this probe?]
Example: "10 users from our early access waitlist, non-technical SMB owners."

## Success Criteria (Harsh Truth)
[What truth are you seeking? What would prove you wrong?]
- **Pass:** 8+ users complete signup in under 2 minutes
- **Fail:** <6 users complete, or average time exceeds 5 minutes
- **Learn:** Identify specific drop-off fields

## Tools / Stack
[What will you use to build this?]
Example: "ChatGPT Canvas for form UI, Airtable for data capture, Loom for post-session interviews."

## Timeline
- **Build:** 2 days
- **Test:** 1 day (10 user sessions)
- **Analyze:** 1 day
- **Disposal:** Day 5 (delete all code, keep learnings doc)

## Disposal Plan
[When and how will you delete this?]
Example: "After user sessions complete, archive recordings, delete Frankensoft code, document learnings in Notion."

## Owner
[Who is accountable for running and disposing of this probe?]

## Status
- [ ] Hypothesis defined
- [ ] Probe built
- [ ] Users recruited
- [ ] Testing complete
- [ ] Learnings documented
- [ ] Probe disposed

---

质量检查清单

启动 PoL 探测前，请确认：

• 轻量： 你能在 1-3 天内构建它吗？
• 可处置： 你是否已确定处置日期？
• 范围狭窄： 它是否只测试一个假设？
• 足够诚实： 如果你错了，数据是否会让你难受？
• 精简聚焦： 它是否比 MVP 更小？
• 可证伪： 你能描述什么情况算作“失败”吗？
• 负责人明确： 是否有一人负责执行并处置它？

如果任何一项回答为“否”，请修改你的探测，或重新考虑是否需要进行探测。

---

示例

完整的 PoL 探测示例请参见 examples/sample.md。

迷你示例摘录：

**Hypothesis:** Users can distinguish "archive" vs "delete"
**Probe Type:** Task-Focused Test
**Pass:** 80%+ correct interpretation

常见误区

• 开展宽泛的“用户会喜欢这个吗？”实验，而不是测试一个可证伪的假设
• 把 PoL 探测当作原型 MVP，并拒绝处置它
• 使用回避不舒适真相的虚荣指标
• 在测试开始前跳过预先定义的失败阈值
• 先选工具，再定假设

参考资料

相关技能

• pol-probe-advisor（交互式）— 用于选择原型类型的决策框架
• discovery-process（工作流）— 在验证阶段使用 PoL 探测
• problem-statement（组件）— 创建 PoL 探测前定义问题
• epic-hypothesis（组件）— 使用 PoL 探测测试前构建假设

外部框架

• Jeff Patton — 用户故事地图（精益验证原则）
• Marty Cagan — Inspired（2014 年提出的原型类型框架）
• Dean Peters — 先感受氛围、快速验证、检验契合度（Dean Peters 的 Substack，2025 年）

提及的工具

• **可行性：**GenAI（ChatGPT、Claude）、API 测试工具
• **任务导向：**Optimal Workshop、UsabilityHub
• **叙事：**Loom、Sora、Synthesia、Veo3（文本转视频）
• **合成数据：**Synthea（患者模拟）、DataStax LangFlow
• **氛围编码：**ChatGPT Canvas、Replit、Airtable、Carrd