القائمة
在投入完整开发前，用最小成本验证假设时使用。适用于高不确定需求、新功能想法、有风险的方案。优先使用 5 种 PoL Probe 类型选择最合适的验证方式。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill pol-probeيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | pol-probe |
| description | 在投入完整开发前，用最小成本验证假设时使用。适用于高不确定需求、新功能想法、有风险的方案。优先使用 5 种 PoL Probe 类型选择最合适的验证方式。 |
参考来源：deanpeters/Product-Manager-Skills 的 pol-probe skill
PoL = Proof of Learning，目标不是证明方案"能做"，而是证明方案"该做"。
1. 验证假设，不是验证方案
错：测试"语义搜索是否能做出来"
对：测试"用户是否真的因为找不到商品而流失"
2. 最小成本，最大信息量
能 30 分钟解决的不要花 3 小时
3. 验证失败 ≠ 失败
失败的实验也是有价值的发现
4. 提前定义成功标准
不能事后凑数据
问题：技术上能不能做到？
适用：
做法：
示例：
假设：能用现有数据训练出准确率 > 80% 的推荐模型
实验：用历史数据跑一次，看准确率
成功标准：准确率 ≥ 75%
失败后：放弃方案 / 换数据源 / 换算法
问题：用户能不能完成操作？
适用：
做法：
示例：
假设：用户能在 3 分钟内完成新版下单流程
实验：5 个用户测试，记录耗时和卡点
成功标准：4/5 用户在 3 分钟内完成
失败后：简化流程 / 重新设计
问题：用户是否理解价值主张？
适用：
做法：
示例：
假设：用户对"AI 智能推荐"的接受度高于"个性化推荐"
实验：两个落地页 A/B 测试，对比转化率
成功标准：A 版转化率 > B 版 20%
失败后：调整价值主张
问题：数据是否支持假设？
适用：
做法：
示例：
假设：每月有 2000+ 用户因为找不到商品而流失
实验：分析最近 30 天的搜索失败 + 退出率数据
成功标准：数据支持月均 1500+
失败后：重新评估机会优先级
问题：端到端能不能跑通？给用户的感觉对不对？
适用：
做法：
示例：
假设：用 AI 推荐 + 现有商品库，能产生让用户感兴趣的商品流
实验：用 AI 生成一个原型 demo，给 10 个用户试用
成功标准：6/10 用户表示"会再来用"
失败后：调整方向或放弃
问题类型？
├─ 技术能不能做 → Feasibility
├─ 用户能不能用 → Task
├─ 用户买不买账 → Narrative
├─ 数据支不支持 → Data
└─ 整体感觉对不对 → Vibe-Coded
成本预算？
├─ 30 分钟内 → Data / Narrative
├─ 1 小时左右 → Feasibility / Task
└─ 半天 → Vibe-Coded
风险等级？
├─ 低（可逆） → Vibe-Coded（快速做）
└─ 高（不可逆） → Data + Task 双重验证
## PoL Probe: [实验名称]
**类型**：Feasibility / Task / Narrative / Data / Vibe-Coded
**待验证假设**：
如果 [条件]，那么 [结果]
**验证方式**：
[具体怎么测，包括工具/数据/对象]
**成功标准**：
[必须是可观察、可量化的指标]
**失败后行动**：
- 如果失败：[放弃 / 调整 / 重新设计]
- 如果部分成功：[继续验证 / 缩小范围]
**时间预算**：
[最多花多少时间]
**所需资源**：
[需要哪些数据/工具/人员]
**实验记录**：
- 开始时间：
- 结束时间：
- 实际耗时：
- 结果数据：
- 结论：
- 后续行动：
1. 识别需要验证的假设（来自 OST 或 PRD）
↓
2. 选择 PoL Probe 类型（用决策树）
↓
3. 设计实验（用模板）
↓
4. 设定成功标准（可量化、可观察）
↓
5. 设定时间预算（不超过预算就停）
↓
6. 执行实验
↓
7. 记录结果（成功/失败/部分成功）
↓
8. 决策：继续/调整/放弃
↓
9. 沉淀到 field-journal
□ 实验类型是否选对了？（不要用 Feasibility 验证用户接受度）
□ 假设是否具体可测试？（不是"用户喜欢"而是"用户点击率 > X%"）
□ 成功标准是否提前定义？（不能事后凑数据）
□ 失败后行动是否提前规划？（避免"再做一个实验"的循环）
□ 时间预算是否合理？（PoL 不应该比正式开发还久）
□ 是否最小成本？（能 Data 就不 Vibe-Coded）
templates/pol-probe-template.md — 实验设计模板templates/probe-result-template.md — 实验结果记录模板上游：
opportunity-tree → 提供需要验证的假设
平行：
user-story → 验证某个用户故事的核心假设
prioritization → 验证高分但低置信度的方案
下游：
实验通过 → mvp-scoping 进入 MVP 范围
实验失败 → 调整 OST 或放弃
实验沉淀 → field-journal