Geek-skills-xuefeng-method - Claude MCP Skill

# 雪峰方法论：AI-Native 产品开发实战体系

> 核心理念：强模型依赖 × 多专精Agent × 快速校准 × 行为审计
>
> 来源：雪峰——AI-Native连续创业者，深耕AI日历管理等AI驱动产品。
> 核心洞察：穷举是死循环，唯快不破才是AI-native的生存之道。
>
> 与克谦方法论（keqian-method）互为对偶：
> 克谦解决"如何让AI在明确边界内可靠执行"，
> 雪峰解决"当边界本身不确定时怎么办"。

---

## 第零步：产品类型判断（必须先做）

在选择任何开发策略之前，先判断你的产品类型。
**选错方法论比没有方法论更危险。**

| 类型 | 特征 | 关键判断标准 | 推荐方法 |
|------|------|------------|---------|
| **+AI（场景依赖型）** | 用户行为可枚举，AI辅助执行确定性流程 | 能列出所有合法输入输出组合 | → keqian-method |
| **AI-native（强模型依赖型）** | AI驱动核心决策，用户行为开放式 | 用户的下一步操作你无法预测 | → 本skill |
| **混合型** | 核心流程确定，部分环节AI-native | 能拆分出哪些模块是确定的、哪些是开放的 | → 两者结合，按模块选用 |

### 快速判断清单

回答以下问题，如果3个以上答"是"，你大概率是AI-native：

1. 用户的输入是自由文本/语音，而非选择菜单？
2. 同一输入，你希望AI给出不同风格的输出？
3. 用户会因为AI的回答方式而改变自己的后续行为？
4. 你无法为产品写出完整的功能测试用例集？
5. 产品的核心价值在于AI的"判断"而非"执行"？

---

## 第一原则：穷举是死循环

> "穷举意味着：有多少人工，就有多少智能。这是死循环。"

### 为什么在AI-native场景下穷举不可行

在+AI场景下，克谦说"边界内可穷举，单维度选项有限"——**这是对的**。
但AI-native场景的数学不一样：

```
用户行为空间（开放） × 模型输出空间（概率性） × 上下文状态（动态）
= 组合爆炸，不可穷举
```

一个日历管理能有多复杂？答案是：走AI-native路线后，**非常复杂**。
因为用户一旦习惯AI-native交互，就永远回不到传统模式——
你必须持续适应用户不断演化的期望。

### 替代穷举的三个策略

**策略1：行为模式簇（Behavioral Clusters）**

不枚举每个case，而是聚类用户行为模式：

```
原始行为空间（不可穷举）
    ↓ 聚类
行为模式簇（5-15个典型模式）
    ↓ 每个模式簇
设计对应的AI响应策略
    ↓ 边界case
优雅降级到确定性逻辑
```

**策略2：优雅降级（Graceful Degradation）**

AI不确定时，回退到确定性逻辑：

```
AI置信度 > 阈值 → AI决策（快路径）
AI置信度 < 阈值 → 确定性回退（安全路径）
AI置信度极低 → 请求人工介入（慢路径）
```

**策略3：概率性验收（Probabilistic Acceptance）**

不用 `assert output == expected`，而用 `check output ∈ acceptable_set`：

```python
# 传统断言式（克谦适用）
assert response == "会议安排在下午3点"

# 行为属性式（雪峰适用）
assert "下午" in response
assert contains_time(response)
assert tone_is_professional(response)
assert no_hallucinated_contacts(response)
```

---

## 第二原则：多养专精虾

> "多养两只虾，每只都比较专业，只干一种活。出了问题找bug容易。
> 一个全面能干的虾，出了问题找问题非常麻烦。"

### 专精Agent架构

```
               ┌─ 理解Agent（NLU：解析用户意图）
               │
用户输入 → 路由器 ─┼─ 执行Agent（Action：调用API/修改数据）
               │
               ├─ 校验Agent（Verify：检查执行结果）
               │
               └─ 表达Agent（NLG：生成用户可见回复）
```

每只虾**只干一种活**的好处：
- 出bug时，能精确定位是哪只虾的问题
- 单独升级/替换某只虾，不影响其他
- 每只虾可以用最适合它的模型（路由策略）

### 拆分决策矩阵

| 条件 | 拆分？ | 原因 |
|------|:------:|------|
| 功能正交，输出互不依赖 | ✅ | 并行执行，互不干扰 |
| 各自有独立的验证标准 | ✅ | 单独eval，精确定位 |
| 失败时只影响局部 | ✅ | 局部重试，不整体报废 |
| 有上下文依赖链 | ❌ | 合并时容易出不一致 |
| 你无法精确控制上下文注入 | ❌ | 注入什么、多少都要精确控制 |
| 合并结果需要复杂对齐 | ❌ | 合并成本可能超过收益 |

### 与克谦方法的差异

| 维度 | 克谦（单agent极致） | 雪峰（多专精agent） |
|------|-------------------|-------------------|
| 默认选择 | 顺序执行 | 并行分工 |
| 适用场景 | 有依赖链的长程任务 | 功能正交的独立模块 |
| 出错定位 | 在长链中回溯 | 直接定位出错的虾 |
| 风险 | 链越长概率乘越低 | 合并时可能不一致 |

**不是对错，是产品类型不同。** 同一产品内也可以混用。

---

## 第三原则：唯快不破

> "无法预知上线后用户反馈和喜好，只能唯快不破。"

### AI-Native快速迭代循环

```
Phase 1: 行为属性测试（上线前）
├── 不是断言式测试，是属性检查
├── "输出合理吗？" 而非 "输出等于X吗？"
└── 通过 = 可以上线，不通过 = 还不够稳

Phase 2: 快速上线（MVP心态）
├── 不追求完美，追求"可接受"
├── 95%校准极难，先追求80%
└── 剩下的靠用户反馈补

Phase 3: 用户反馈 + 漂移检测
├── 收集：用户满意度、异常行为、投诉
├── 检测：模型输出分布是否偏移
└── 预警：漂移超过阈值 → 触发校准

Phase 4: 快速校准
├── 提示词迭代（最快）
├── 模型切换/升级（中等）
├── 微调/RLHF（最慢但最持久）
└── 下一轮上线 → 回到Phase 3
```

### 迭代速度 > 单次质量

| 策略 | 单次质量 | 迭代速度 | AI-native适用性 |
|------|---------|---------|---------------|
| 一次做到95% | 极高 | 极慢 | ❌ 不现实 |
| 先80%上线再迭代 | 中等 | 快 | ✅ 推荐 |
| 60%就上 | 低 | 极快 | ⚠️ 风险大，慎用 |

---

## 第四原则：模型选择实战

> "如果不是纯coding，尽量不要用xxx-codex模型，直接切通用模型就行了。"
> "慢点就慢点，但牢靠，不啰嗦。"

### 模型路由决策树

```
任务类型？
├── 纯代码编写 → codex系列
├── 代码+推理混合 → 通用旗舰模型（GPT-5.x / Claude Opus）
├── 自然语言理解/生成 → 通用模型
├── 多模态 → 专用多模态模型（如GLM-5V-Turbo）
└── 简单执行 → 轻量模型（省成本）
```

### Dumb Zone防护

模型在长上下文中会"降智"，不同模型的阈值不同：

| 模型类别 | 进入dumb zone的阈值 | 应对策略 |
|---------|-------------------|---------|
| 国际Top2（GPT/Gemini） | 上下文窗口*0.7~0.8 | 0.7时compact |
| 国模（GLM-5.1等） | 上下文窗口*0.4~0.5 | 0.5时compact |

**铁律：** 达到阈值就`/compact`，不要等到降智再补救。

### 智能路由架构（多模型协作）

```
用户请求 → 复杂度评估器
              ↓
    ┌─ 简单请求 → 轻量模型（低成本）
    ├─ 中等请求 → 通用模型（平衡）
    └─ 复杂请求 → 旗舰模型（高质量）
```

好处：大部分请求用轻量模型，少数复杂请求用旗舰模型，总成本可控。

---

## 第五原则：行为审计替代质量门禁

> 克谦用严格门禁 → 缓存命中飞轮。这在确定性输出场景有效。
> AI-native输出是概率性的，需要不同的质量策略。

### 质量策略对比

| 维度 | 克谦门禁（确定性） | 雪峰审计（概率性） |
|------|-------------------|-------------------|
| 测试方式 | `assert output == expected` | `check output ∈ acceptable_set` |
| 失败处理 | 自动修复 → 升级人工 | 分析漂移原因 → 调整策略 |
| 质量指标 | 缓存命中率 | 用户满意度 + 模型一致性 |
| 迭代触发 | 门禁不通过 | 用户反馈 + 漂移检测 |
| 成本模型 | 高缓存命中 = 低成本 | 路由到合适模型 = 可控成本 |

### 行为审计实施

```
定期（每日/每周）
├── 采样模型输出（N=100+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准
```

### 漂移检测信号

以下信号出现时，说明模型可能在漂移：

1. **输出分布偏移**：同类输入的输出风格/长度/结构发生变化
2. **用户投诉增加**：满意度指标下降
3. **异常行为增多**：超时、拒答、幻觉增加
4. **上下游不一致**：Agent间的输出格式或语义不对齐

---

## 第六原则：一切以用户为中心

> "AI-native的代价很大，就是一切以用户为中心。"
> "用户一旦用惯了AI-native，就再也回不到传统模式了。"

### 用户适应性飞轮

```
用户使用AI-native产品
  → 用户期望提高（不接受传统交互）
  → 产品必须持续进化
  → 需要更强的模型 / 更好的校准
  → 用户体验提升
  → 用户期望进一步提高
  → …（正向循环，但也是成本螺旋）
```

### 管理用户期望

- **不要过度承诺**：AI-native不是万能的，明确能力边界
- **设计优雅降级**：AI不确定时给用户选择权，而非强行给答案
- **透明度**：让用户知道AI在做什么，建立信任
- **反馈闭环**：让用户的反馈真正影响产品迭代

---

## 实战工作流模板

### 启动AI-Native新项目

```
Phase 1: 产品定义（30%时间）
├── 判断产品类型（+AI / AI-native / 混合）
├── 定义行为模式簇（5-15个典型用户模式）
├── 设计优雅降级策略
└── 选择初始模型组合

Phase 2: 多专精Agent搭建（30%时间）
├── 拆分Agent职责（每只虾一种活）
├── 设计Agent间通信协议
├── 每只Agent独立eval
└── 集成测试（行为属性式）

Phase 3: 快速上线（10%时间）
├── MVP上线，不追求完美
├── 先覆盖80%的行为模式簇
└── 剩余20%用优雅降级兜底

Phase 4: 持续校准（30%时间，持续进行）
├── 用户反馈收集
├── 漂移检测 + 行为审计
├── 模型切换/提示词迭代
└── 下一轮上线
```

### 日常运维节奏

```
每日：
  - 查看漂移检测报告
  - 处理用户反馈中的高优问题
  
每周：
  - 行为审计（采样+属性检查+人工抽检）
  - 评估是否需要模型切换或提示词迭代
  
每月：
  - 回顾行为模式簇是否需要更新
  - 评估新模型是否值得切换
  - 成本分析（路由策略优化）
```

---

## 与克谦.skill的互补关系

两个skill不冲突，**可以在同一产品的不同模块分别使用**：

| 产品模块 | 特征 | 推荐skill |
|---------|------|----------|
| 后端API | 确定性输入输出 | keqian-method |
| 数据处理管线 | 可穷举的转换规则 | keqian-method |
| AI对话引擎 | 用户输入开放式 | xuefeng-method |
| AI推荐系统 | 输出概率性 | xuefeng-method |
| CI/CD管线 | 确定性流程 | keqian-method |
| 模型路由/编排 | 动态决策 | xuefeng-method |

---

## 心法总结

```
"多养两只虾，每只只干一种活" — 专精分工，出bug好找
"穷举是死循环" — 用行为模式簇替代穷举
"唯快不破" — 先上线再校准，不追求一次完美
"慢点就慢点，但牢靠" — 模型选择，稳定优先
"AI-native的代价很大" — 一切以用户为中心，没有退路
"做过就知道了" — 理论和实操差距巨大，动手验证
```

---

## 参考资料

更多细节请查阅：
- `references/behavioral-clusters.md` — 行为模式簇设计方法
- `references/drift-detection.md` — 模型漂移检测与校准协议