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

# 传统断言式（克谦适用）
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+）
├── 自动检查行为属性（格式、安全、一致性）
├── 人工抽检（关键决策质量）
├── 漂移检测（输出分布与基线对比）
└── 生成审计报告 → 决定是否触发校准

漂移检测信号

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

1. 输出分布偏移：同类输入的输出风格/长度/结构发生变化
2. 用户投诉增加：满意度指标下降
3. 异常行为增多：超时、拒答、幻觉增加
4. 上下游不一致：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 校验