Xuefeng Method

雪峰方法论：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：

• 用户的输入是自由文本/语音，而非选择菜单？
• 同一输入，你希望AI给出不同风格的输出？
• 用户会因为AI的回答方式而改变自己的后续行为？
• 你无法为产品写出完整的功能测试用例集？
• 产品的核心价值在于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：

# 传统断言式（克谦适用）
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模型，直接切通用模型就行了。"

> "慢点就慢点，但牢靠，不啰嗦。"

模型路由决策树、dumb zone 防护和多模型协作细节见 references/model-routing.md。

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

> 克谦用严格门禁 → 缓存命中飞轮。这在确定性输出场景有效。

> AI-native输出是概率性的，需要不同的质量策略。

质量策略对比

| 维度 | 克谦门禁（确定性） | 雪峰审计（概率性） |

|------|-------------------|-------------------|

| 测试方式 | assert output == expected | check output ∈ acceptable_set |

| 失败处理 | 自动修复 → 升级人工 | 分析漂移原因 → 调整策略 |

| 质量指标 | 缓存命中率 | 用户满意度 + 模型一致性 |

| 迭代触发 | 门禁不通过 | 用户反馈 + 漂移检测 |

| 成本模型 | 高缓存命中 = 低成本 | 路由到合适模型 = 可控成本 |

行为审计实施

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

漂移检测信号

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

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

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

> "AI-native的代价很大，就是一切以用户为中心。"

> "用户一旦用惯了AI-native，就再也回不到传统模式了。"

用户适应性飞轮

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

管理用户期望

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

验收标准（按本方法论执行的任务，交付前自查）

• [ ] 第零步已做：产品类型判断（+AI / AI-native / 混合）有明确结论并据此选了方法
• [ ] Agent 分工遵循"每只虾只干一种活"，每个 Agent 的职责一句话说得清
• [ ] 上线/交付带行为审计方案：知道怎么发现模型行为漂移，而不是等用户投诉
• [ ] 没有为追求"校准到 95%"而无限延期——快速上线 + 快速校准的节奏有体现
• [ ] 模型选择有路由依据（成本/能力/延迟），不是全用最贵的

实战与协作模板

实战工作流、日常运维节奏、与 keqian-method 的互补关系，以及心法总结已集中到 references/operating-playbook.md。入口文件只保留判断、原则和导航，避免主文档继续膨胀。

参考资料

更多细节请查阅：

• references/behavioral-clusters.md — 行为模式簇设计方法
• references/drift-detection.md — 模型漂移检测与校准协议
• references/model-routing.md — 模型选择、上下文阈值和智能路由
• references/operating-playbook.md — 实战工作流、运维节奏和方法论互补关系
• evals/routing-evals.json — 触发边界回归用例（含与 keqian-method 的互斥镜像），改动 description 后用仓库根 scripts/run_routing_evals.py 校验